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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #34 from Edward Hervey <bilboed at bilboed.com> ---
(In reply to Thiago Sousa Santos from comment #32)
> This has become more evident with adaptive demuxers where group switches are
> frequent. The smaller the fragments, the more it happens.
> 
> Here is an idea I had for implementation:
> 
> Keep the removed group around

  I'm a bit confused as to what you mean by "removed group". If it's still got
data (i.e. EOS hasn't been seen on the source pads of that group), then it
needs to stay around. If it received EOS and there's a pending group... there's
no reason to keep it around ?

> and attach probes to the sink pads

  Having probes on the sink pads is definitely something we need to not "lose"
events/queries that are travelling upstream.

  But I'd say we should put those immediately before unlinking the demuxer
source pads (i.e. to handle events/queries travelling upstream between the
moment we unlink from demuxer and the moment we un-expose that group).

>, then push
> a dummy custom upstream event/query to flow through the branch and only
> remove the group after it has reached the probe.

  At what moment do you intend to push that custom upstream event ? When
un-exposing the group ?

> 
> Events received in this probe should be forwarded to the new group

(In reply to Duncan Palmer from comment #33)
> A question; if we implement a solution along the lines that Thiago has
> described, does anyone know how decodebin2 will behave when it receives a
> FLUSH_START event from the upstream element which has now received the SEEK
> event? I think we would want it to destroy the new groups (which are not yet
> linked downstream), and push the event into the old linked group (which is
> linked downstream).

  Until now this bug was looking at not losing events/queries coming from
downstream, But you are indeed right that there is some special handling
required for events coming from upstream.

  In the case of FLUSH_START I would propose the following:

  In group event probes (whether linked or unlinked) if we see a FLUSH_START we
should forward that to *all* other groups. The rationale behind this is that
upstream (the demuxer) asked us to flush, therefore we should flush everything
downstream from that... which includes all the groups.
  By doing so we:
  1) Ensure all groups are flushed
  2) Downstream of decodebin gets the FLUSH_START event (there is at least one
group exposed which will push that through decodebin's current source pads)
  Once that is done, we should also expose the latest group (which is the one
currently linked to the demuxer) and remove the previous ones.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.