[gstreamer-bugs] [Bug 600787] playbin2 has a problem with Ogg stream with "info"
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Sat Nov 14 06:20:25 PST 2009
https://bugzilla.gnome.org/show_bug.cgi?id=600787
GStreamer | gst-plugins-base | 0.10.25
--- Comment #10 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2009-11-14 14:20:19 UTC ---
(In reply to comment #7)
I'll do that changes. Thanks for the review.
(In reply to comment #8)
> (In reply to comment #5)
>
> > The problem is that the new pads of oggdemux have a multiqueue that is on
> > prerolling state, so it will only block on the 2MB limit, unfortunately the
> > stream causes oggdemux to switch pads again before it is reached.
>
> I guess a better approach would be to block oggdemux somehow to prevent it
> switching to new groups before the previous are finished. Not sure how...
Can't think of a 'nice' way to do this
>
> By setting those limits different the switching could still happen right?
> Although it's less likely
Yes, it would happen and we'd have the same problem if the switching happened
in less than 5 buffers or even some more, because queue2 would not set it back
to playing as more space would be created and it would never fill enough.
(In reply to comment #9)
> Or maybe set the limits different not after EOS but after the group is ready to
> be exposed (if the active group would be finished). This would still break if
> less than 5 buffers are in the new group though, right?
We could block the pads of multiqueue if the group already is completed
(received no-more-pads) and is not exposed yet. Because it does not need to
preroll anymore as it already knows all its pads.
--
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.
More information about the Gstreamer-bugs
mailing list