[Bug 646327] [h264parse] add property to drop buffers until codec-data has been determined

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Mar 31 06:34:03 PDT 2011

  GStreamer | gst-plugins-bad | git

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
                 CC|                            |mnauw at users.sourceforge.net

--- Comment #4 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-03-31 13:33:59 UTC ---
One could keep those buffers and then send them (even as baseparse
functionality), but they are probably only useful if they happen to start with
an IDR-frame, in which case there is also a good chance codec-data is also
around from the start (depending on alignment).  That is not to say some
GST_BASE_PARSE_FLOW_DELAY (and corresponding mechanics) are useful.

So, assuming a typical case with codec-data and IDR around from the start,
downstream (muxer) caps should already arrange proper behaviour (since
arranging for alignment=au implies that SPS/PPS are aggregated into the first
unit and therefore full codec-data is in caps by the first output buffer).

In remaining more exotic cases, one "should know more what one is doing",
though it might not hurt to have this enabled by default.  However, having it
as a property is useful so h264parse can at least still be used for debugging
purposes to see what is happening with NAL units (rather than hard-coded
discarding some).

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