[Bug 680262] [0.11] decodebin: 3gp preroll regression caused by pad blocking changes

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=680262
  GStreamer | gst-plugins-base | 0.11.x

Edward Hervey <bilboed> changed:

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

--- Comment #3 from Edward Hervey <bilboed at gmail.com> 2012-07-20 16:36:15 UTC ---
The problem is due to blocking on CAPS event, which blocks decoder streaming
threads, which then blocks the ALLOCATION queries from demuxers and therefore
making the demuxer streaming thread block.

I tried a variant where I would mark a stream as completed (and potentially
exposing the group) when we see a CAPS event, but then letting the event
through (i.e. not blocking the streaming thread). This could be interesting for
speeding up pre-rolling, since you don't need to wait for data to arrive on all
final pads, but only caps.

The problem is that it still potentially lets ALLOCATION queries go through
unlinked pads and fail for the first buffer.

If the audio stream sends CAPS event before the video stream sends ALLOCATION
queries, then you have the optimal scenario. Else it'll be the same as
previously.

I'd much prefer to figure out the ideal solution where it never ends up doing
an ALLOCATION query on an unlinked pads.... but it seems hard with the current
decodebin/playbin design and interaction

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