[Bug 606382] decodebin: Upstream events (seek,qos) get lost when switching groups/chains

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sat Aug 15 09:55:44 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=606382

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|NONE                        |1.5.3

--- Comment #46 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit eaf9ca90c7000f5c7156d13969b9135f7273fa79
Author: Edward Hervey <edward at centricular.com>
Date:   Mon May 4 11:19:28 2015 +0200

    decodebin2: Handle flushing with multiple decode groups

    When an upstream element wants to flush downstream, we need to take
    all chains/groups into consideration.

    To that effect, when a FLUSH_START event is seen, after having it
    sent downstream we mark all those chains/groups as "drained" (as if
    they had seen a EOS event on the endpads).

    When a FLUSH_STOP event is received, we check if we need to switch groups.
    This is done by checking if there are next groups. If so, we will switch
    over to the latest next_group. The actual switch will be done when
    that group is blocked.

    https://bugzilla.gnome.org/show_bug.cgi?id=606382

commit 2d3743e37dd13d2211e4ec2c596c5a420e944d18
Author: Edward Hervey <edward at centricular.com>
Date:   Wed Apr 29 15:56:39 2015 +0200

    decodebin2: Forward event/queries for unlinked groups

    When upstream events/queries reach sinkpads of unlinked groups (i.e.
    no longer linked to the upstream demuxer), this patch attempts to find
    the linked group and forward it upstream of that group.

    This is done by adding upstream event/query probes on new group sinkpads
    and then:
    * Checking if the pad is linked or not (has a peer or not)
    * If there is a peer, just let the event/query follow through normally
    * If there is no peer, we find a pad to which to proxy it and return
      GST_PROBE_HANDLED if it succeeded (allowing the event/query to be
properly
      returned to the initial called)

    Note that this is definitely not thread-safe for the time being

    https://bugzilla.gnome.org/show_bug.cgi?id=606382

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