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

[GStreamer (GNOME Bugzilla)]

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

Edward Hervey <bilboed at bilboed.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at bilboed.com

--- Comment #3 from Edward Hervey <bilboed at bilboed.com> ---
Thought about that issue some time ago. The way I see it, in order to get fast
trick-mode switching we need to solve two issues:

[1] Segment changes that do not "break" the stream, but only change timing
information, should be handled as quickly/smoothly as possible in various
elements (demuxers, parsers, decoders, ..). These would be segment changes that
you mention (ex: only change would the rate field).
   I have this feeling quite a few elements reconfigure themselves when they
get a new segment, instead of just checking whether they need to store/forward
the updated segment. This would need to be checked/fixed.

[2] Applying such (seek) changes as quickly as possible throughout the
pipeline. The problem with your proposal is that the segment is no longer
consistent throughout various elements. Elements upstream that use
gst_segment_to_running_time() will return inconsistent values. That alone would
break QoS handling (where the diff value is provided in running time).
  Two solutions:
   2.1. Having an out-of-band segment event that could propagate such segment
updates
   2.2. Having an "eventually consistent" segment propagation.

2.1: Pros: changes would apply as quickly as possible
     Cons: Requires a new API

2.2: The idea would be to have the sink apply the rate change *before* sending
the seek event upstream. If the seek fails, it obviously resets it to the
previous segment. Otherwise it keeps it.
   Pros: Change happens as fast as can be, no new API needed, every element
gets the segment update. The pipeline is "eventually" consistent from a segment
pov
   Cons: That small window where segments are inconsistent, but could be worked
around.


  Thoughts ?

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