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

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=646327
  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.