[Bug 678465] Some live MPEG TS streams are very slow to start playing

[GStreamer (bugzilla.gnome.org)]

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

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED

--- Comment #4 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-10-18 12:47:59 UTC ---
Ok, thanks for testing. It's a bit odd that you only have
'legacympegvideoparse' but then not 'mpegvideoparse' from the videoparsersbad
plugin - I assume you just don't build it?

Given the last pipeline starts in ~2 seconds, I would guess that there's
something going on/wrong with the TS demuxer and the multiqueue in
uridecodebin/decodebin2, possibly related to the lack of no-more-pads emission
and all that. I wonder if it could be because of some stream that doesn't carry
data very often - multiqueue will then expand until it's got data for all
streams or until it's full, or something like that (bug #597195 might be
related).

Truth is, however, that it's unlikely anyone is going to look at this much more
in a 0.10 context I'm afraid, so I don't really know what to do about this.

FWIW, Fedora 18 is going to ship with 1.0.x. You still have chances to get
bug-fixes into that now. And for development you need a custom setup with fixes
anyway, no (rather than rely on the distro versions)?

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