[Bug 787300] basesink: Add property to handle seamless-seek by sink

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from Edward Hervey <bilboed at bilboed.com> ---
To clarify one point: The type of segment changes we want to handle are those
such that:
* The data stream in itself isn't broken (i.e. you are not changing the
direction and the buffers remain contiguous (i.e. no DISCONT)).
* The running time just before and just after the new SEGMENT remains the same


> 2.1
> An out-of-band segment event (non-serialized) it feasible, though every
> single element will need to be updated. Were things gets hairy is for
> baseclass that offers direct access to the segment, assuming it will always
> be protected by the stream-lock (single threaded access). Good care will be
> needed for the locking.

  Well spotted, so 2.1 also means locking issues everywhere. Oh, and I forgot
another con: this breaks apart completely with 3rd party elements which don't
understand this new event yet.

> 
> I know you understand this pretty well (probably better then me in some
> ways), but the way it's written make us believe that only the "rate" field
> need to be updated (this apply to rate change only in the seek of course).
> So just to set the expectation, elements driving the pipeline will need for
> push forward the base of the new segment too. This is because the rate for
> the portion of time that passed was at at different rate then the portion we
> are going to play. Running Time is scaled with the rate, and base is a value
> of running time. For other elements, forwarding is all you have to do. So I
> expect loads or trivial patches. I hope base-transform and other base
> classes will be able to hide this up well.

  Yes, in any situation the seek handler would have to properly update the base
value to guarantee running_time continuity. This is part of what I meant in
issue [1] in comment #3.

> 
> 2.2
> Doing it that way around is hard, since each element may endup with a
> different base (they have different buffers in hand). You expect the new
> base to adjust to where the demuxer is, so that if frame-dropping is needed,
> it is smooth out by having some data queued. It's much simpler to add a new
> event, as you can pass the segment that downstream can trivially use in most
> cases. So to me, the Cons is quite big. It will be extra hard to debug, but
> might work as well.

  Well .. not *each* element. Since the segment update is in-band and we
respect the running_time continuity, that wouldn't be an issue.

  *BUT* ... I just realized one issue which would break all of this. This is
having two different segments when switching. The temporary one in the sink,
and the final one which will replace it.

Take the following (simplified) example:
We play for 10s a stream, then do a switch to 2x rate. The queueing between the
demuxer (seek handler) and sink is of 2s.
* Playback for 10s
  Initial segment will result in following values:
     Position: 0s -> 10s
     Running time : 0s -> 10s
* Create a 2x rate segment
* Sink creates a provisional segment with a base of 10s (the current position)
and a rate of 2x
* Sink sends seek event upstream to demuxer
* Demuxer is at a position of 12s, and creates/pushes a new segment with a base
of 12s and a rate of 2x
* Before the sink receives the new segment, it will receive buffers from 10s to
12s, resulting in the following values:
     Position : 10s -> 12s
     Running time : 10s -> 11s
* The sink receives the new segment and buffers from 12s, resulting in:
     Position : 12s -> ...
     Running time : 12s -> ... *BOOOM*

We end up having a "gap" of 1s where playback will be "paused".

One way we could circumvent this is to allow seek handlers to provide the
base/position they will use, so that the provisional segment that the sink
creates ends up being contiguous. But either way it's going to be tricky.

Need to think some more about this.

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