[Bug 659924] GStreamer fails to play certain MPEG-2 transport streams containing audio and private data

[GStreamer (bugzilla.gnome.org)]

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

Vincent Penquerc'h <vincent.penquerch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |647769

--- Comment #16 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> 2011-09-29 12:59:10 UTC ---
Another solution is to tweak the queue size limits in decodebin2.
Currently, the time limits are unbounded, with a size limit of 2 MB.
For a radio only stream, this means quite a long time before that limit is
reached (see #584104).
Moreover, reaching that limit triggers decodebin2 to go ahead, assuming no data
will be forthcoming from pads which have stayed without data so far. This is
the same kind of approach I used in my previous patch, but relying on
decodebin2 avoids having two thresholds.
However, for non seekable streams, there is currently no limit, but this is a
bug and should be changed shortly (see #647769, marking as dependency). Fixing
this makes the sample audio stream attached above preroll and play.
However, since there can be some largeish time gap between streams, that
default threshold should not be too small. Setting it too large (currently 10
seconds for seekable streams) means that, for a streamed stream where we have
to read at "live" speed, there will be, eg, 10 seconds of waiting while the
queue fills up before deciding to go ahead. This may be too much. If it's a
problem for your case, I could make this time threshold a property so it can be
set before prerolling.

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