[Bug 728324] h264parse: wait for resolution to be known before pushing

[GStreamer (bugzilla.gnome.org)]

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

Nicolas Dufresne <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #10 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-04-27 14:30:04 UTC ---
For anything *not* H264, this information (the number of reference frames) is
stored in the container (if stored at all). The use case I see is:

  demux ! parser ! decocder ! converter

If the converter wants to provide a pool to the decoder, the decoder will be
responsible to request enough buffers. For the H264 case, the decoder could
parse the SPS/PPS and will find the information, for other formats it can't
guess (though many will simply hardcode a value). Though, I must agree that
demuxer (or parser) may pass this information along with the buffers (even
though this means duplication). In that use case, this information is not
actually negotiated but informative.

My interest in having that information in general is to be able to provide a
pool with sufficient amount of buffers in v4l2. Since most driver can't grow
the queue size after streaming has started. Currently I need to prevent libav
from using fixes size pools and do copies to make it work (this is v4l2sink and
upcoming v4l2transform).

-- 
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.