[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