[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

--- Comment #5 from Tvrtko Ursulin <tvrtko.ursulin at onelan.co.uk> 2012-10-18 13:25:27 UTC ---
665814(In reply to comment #4)
> 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?

Not explicitly via configure, no, only if it can decide to disable itself for
some reason. I haven't looked into this to tell you what actually happens.

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

Ah.. that rings a bell.. possibly consequences of bug #665814? There were
multiple fixes done to the old demuxer (and related components) for us by
Vincent. Some got merged, some did not, and then some like this one got
reverted. 

> 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)?

If 0.10 is abandoned I don't see you can do anything other than close this one
as well.

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