[Bug 736318] qtdemux: reset qtdemux parsing state on buffer discontinuity

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=736318
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #5 from Matthieu Bouron <matthieu.bouron at collabora.com> 2014-09-09 14:27:44 UTC ---
(In reply to comment #4)
> It's not clear to me that any element should reset anything when it receives a
> GAP event, it seems like an abuse of the event at first glance.

You're right, according to the documentation the GAP event is used to notify
downstream that there will be no data for a certain amount of time and *not*
that there is a discontinuity in the bytestream.

To clarify a bit the issue, here is what's happening.

Let's say our dash stream as 2 audios streams and 1 video stream.

1. When dashdemux exposes its pad, we link a new qtdemux element for each pad.

2. When the qtdemux elements exposes their pad, we link one video pad and one
audio pad, so one of the qtdemux src pad is left unlinked.

At this point, all the qtdemux has received the fragment headers and we have
the following pipeline.

            [qtdemux0] [videodecoder0] [videosink0] 
[dashdemux] [qtdemux1] [audiodecoder0] [audiosink0]
            [qtdemux2]


3. The pipeline starts playing, all qtdemux elements receive the first
fragment.

4. dashdemux receives not-linked on the pad related to the qtdemux2 element and
it stops the related download task.

5. The pipeline plays fine and we decide to switch our audio stream to the one
related to qtdemux2. We remove the branch (decoder+sink) related to qtdemux1.

6. When the src pad of qtdemux2 is linked, a reconfigure event is sent
upstream, and dashdemux decides to restart the related download task and
download the segment (+ headers) corresponding to the current position. It also
sends a gap event which is not correct since the gap event is supposed to tell
that no data will arrrive for a certain amount of time.

7. qtdemux2 receives data but it expects the data to be the continuation of the
old fragment (step 3).

So when we restart the download task and push the new fragment, we need to find
a way to tell downstream to reset its internal state to be able to parse
properly the new segment.

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