[gstreamer-bugs] [Bug 606662] h264: add stream-format to output caps

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Jan 17 03:04:42 PST 2010


https://bugzilla.gnome.org/show_bug.cgi?id=606662
  GStreamer | gst-plugins-ugly | git

--- Comment #18 from Felipe Contreras <felipe.contreras at gmail.com> 2010-01-17 11:04:38 UTC ---
(In reply to comment #17)
> ffdec_h264 most definitely handles non-parsed bytestream h.264.

That's because ffdec_h264 is wrongly adding a parser (only on byte-stream
mode), see gst_ffmpegdec_open(). It is possible to generate a muxed clip that
contains trimmed access-units, it would play fine on totem, but not ffplay
(mplayer, vlc, and pretty much everything out there).

It is wrong to add an unnecessary parser because:
a) the demuxer already generates the right format
b) the deplayloader should generate the right format
c) if a parser is needed for whatever reason, it should be determined by the
caps, and certainly not based on the stream-format

This is precisely the reason why rtph264dec+ffdec_h264 only works on bytestream
mode:

/* FIXME, non-bytestream handling is freaking out ffmpeg. Apparently we need to
 * group all NAL units belonging to one frame together */

The proper solution would be:
 * remove the extra parser in ffdec_h264
 * add slice_mode=TRUE to the caps (or similar)
 * let rtph264dec buffer full access-units when such mode is on

Then both avc and byte-stream formats will work correctly.

> And since these decoders all have internal parsers, you can send them
> individual slices instead of entire pictures.  Some even decode correctly if
> you send corrupted slices or skip some slices completely.
> 
> It is my opinion that you are designing API based on faulty assumptions.

Note that when I say "decoder" I meant the actual decoder (FFmpeg's), not the
"decoder wrapper" (gst-ffmpeg).

IMO you are making assumptions based on gst-ffmpeg, and not the real decoders.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list