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

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #4 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
I'd like to drop some thought too. In general the proposed approach made sense.
But there is some difficult aspects considering our distributed model of
segments.

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.

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.

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.

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