[Bug 657794] Playback does not start or is poor if pipeline is started before packets start arriving

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=657794
  GStreamer | don't know | 0.10.34

--- Comment #17 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> 2011-09-08 15:18:58 UTC ---
Created an attachment (id=196004)
 View: https://bugzilla.gnome.org/attachment.cgi?id=196004
 Review: https://bugzilla.gnome.org/review?bug=657794&attachment=196004

mpegtsdemux: send an element message after an input stall

When streaming off a UDP source, if the backend switches
channels, we won't know about it. No new segment, no flushes,
etc. We will get a PAT from the new channel, but it will have
the same PID and probably version 0 as well, so we'll think
it's all fine. However, we won't be getting buffers for the
old PIDs (or only some of them), and will be getting buffers
for new PIDs, which will be ignored as not part of the current
program.

Attempts at righting this wrong led to Big Cans of Worms,
especially the playbin2 one.

However, we can detect this is happening by observing gaps
gaps in input timestamps (since the UDP source is live, it
will timestamp incoming buffers with current pipeline time).
If we don't receive anything for half a second, we will send
an element message with name 'input-stall', which can then
be interpreted by the player as a request to restart the
pipeline, and playbin2 will then properly pick up the stream.

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