[gstreamer-bugs] [Bug 550472] [flutsdemux] Fails to demux video/mpeg, mpegversion=4 streams

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=550472

  GStreamer | gst-plugins-bad | Ver: HEAD CVS

vanista changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanista at gmail.com




------- Comment #2 from vanista  2008-11-19 13:48 UTC -------
I think I have the same issue although it's somewhat generalized to all codecs
in my case. I was able to track down the problem to the PID / PID type the
muxer sets for the data streams.

If you take a look at gst_fluts_demux_parse_stream, there is a switch case for
the PID type (which I believe is derived from the PID). The audio/video streams
are expected to be "PID_TYPE_ELEMENTARY", and I saw that an output TS with
H.264 and AAC has PID types 1 and 3 for PIDs 0x0001 and 0x0000 respectively.
Therefore the demux sees those streams as PID_TYPE_CONDITIONAL_ACCESS and
PID_TYPE_PRIVATE_SECTION, and simply drops them.

I'm not sure why FFMPEG demuxes the streams, maybe it doesn't rely on PID for
content type.

Investigating the mux to see where these values come from...


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=550472.