[gstreamer-bugs] [Bug 606382] [decodebin2] Upstream events (seek, qos) get lost when switching groups/chains

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Jan 28 11:08:23 PST 2010


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

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at gmail.com
            Summary|[oggdemux] error when       |[decodebin2] Upstream
                   |seeking in chained ogg      |events (seek,qos) get lost
                   |                            |when switching
                   |                            |groups/chains

--- Comment #25 from Edward Hervey <bilboed at gmail.com> 2010-01-28 19:08:16 UTC ---
What seems to happen is that :
* oggdemux detects a new chain therefore
 * oggdemux emits no-more-pads
   * current decodebin group is marked as closed, but data is still going out
(multiqueue isn't empty)
 * oggdemux removes the old source pads
   * current decodebin group isn't linked to anything upstream anymore
 * oggdemux adds new pads
   * decodebin creates a new group with multiqueue/decoder.
 * oggdemux pushes data from the second chain
   * the data goes into the new decodebin2 group which will only be exposed
when the first group is drained.

The problem is that:
* the first group is still pushing out data, but isn't linked to oggdemux
anymore
* the second group (i.e. where we want to seek) isn't exposed yet

The seek arrives through the first group... which isn't linked anymore... and
therefore oggdemux never gets the seek :(

So basically... we need to have a way for upstream events (SEEK but also QOS
would be good) coming from outside decodebin2 to make their way up to the
demuxer.

I'll think about how this can be fix... but feels quite tricky.

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