[gstreamer-bugs] [Bug 600787] playbin2 has a problem with Ogg stream with "info"

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Nov 13 05:01:37 PST 2009


https://bugzilla.gnome.org/show_bug.cgi?id=600787
  GStreamer | gst-plugins-base | 0.10.25

Thiago Sousa Santos <thiago.sousa.santos> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2009-11-13 13:01:34 UTC ---
It seems to boil down to the fact that oggdemux doesn't set timestamps on its
output buffers. Details follow:

when oggdemux receives this 'info' thingy (I don't know ogg enough to know what
it is) it creates and adds new pads, and pushes EOS and removes the old pads.
When it adds the new pads, multiqueue is requested a new pad and creates a new
internal single-queue empty of buffers, oggdemux will quickly push buffers
through this new pad and make queue2 drain quickly. Queue2 thinks it is time to
buffer and posts a message, causing the pipeline to pause and the sink to block
along with the thread pushing the remaining old pads data (including the EOS).

If this pause happens before the EOS leaves decodebin2, the new pads are not
exposed and are blocked (just before leaving decodebin2), buffers pushed
through the new oggdemux pad will end up in multiqueue. multiqueue will only be
filled and block receiving buffers when it reaches about 10MB of data, or 2
secs. As oggdemux doesn't timestamp its output buffers, it might be a long time
before the pipeline gets playing again.

Hope I've made myself clear. I'll attempt to put timestamps on oggdemux
buffers.

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