[Bug 796648] Add support for instantaneous rate changes

[GStreamer (GNOME Bugzilla)]

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

Edward Hervey <bilboed at bilboed.com> changed:

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

--- Comment #2 from Edward Hervey <bilboed at bilboed.com> ---
(In reply to Olivier Crête from comment #1)
> Why not just have the demuxer do a downstream query, that would fail if any
> of the sinks don't support instant-seek, then put the running time in the
> event? Wouldn't that be more simple?
> 
> The current API/code seems overly complex to achieve the goal.
> 

  Apart from the fact that a query is blocking (which would hinder the goal of
switching as-soon-as-possible), there is more to it.

  You want to switch as fast-as-possible... and you could potentially have
multiple seek handlers in the pipelines ... and you could have some seek
handlers that don't *reliably* handle SEEK_TYPE_NONE seeking (which is
essential to having proper rate switching working).

opt-in API:
* Only seek handlers which we know can reliably handle SEEK_TYPE_NONE seeking
send the out-of-band event

easy API:
* The only thing seek handlers need to do is send a downstream event with the
same seqnum as the seek event. So 3 lines ?

complex API:
* Actually the only thing which is "tricky" is doing the runtime-shifting (i.e.
applying a different rate in all synchronizing elements which is different from
the view that upstream has). But at least it is essentially concentrated in one
location (GstBaseSink) and not that big (code is actually in the design doc if
other runtime-based elements want to handle it themselves)
* The rest of the API is:
  * Creating and sending a simple EVENT downstream in seek handlers.
  * Sending a message upstream in GstBaseSink when they receive that event
  * GstPipeline sending an event upstream when all sinks have sent that message
  * GstBaseSink handling it

Deciding the *optimal* runtime at which to switch:
* The initial version we tried did what you proposed (i.e. use a runtime in
seek handlers). The problem is that you can only do a best-effort in the seek
handlers at guessing when to switch. If you query it downstream you'd be
blocking (slowwww). If you have multiple seek handlers you'd get different
values (goodbye A/V sync).
* So that's why the most reasonable solution was to "accumulate" at the
pipeline level all the requests to switch to a different rate. And as soon as
we have requests from all sinks, we send the current switching runtime.
 => Not too early (where sinks wouldn't be ready)
 => Not too late (where it wouldn't be as-fast-as-possible)

> Are the segnums really always meant to be increasing? They corresponds to
> when the seek event was created, so I'm not sure we can compare the numbers
> in a valid way without changing the API.

gst_util_seqnum_next() is what's used whenever a new event/message is created
by default. Yes, it's always increasing. No, there's no reason whatsoever to
override that seqnum as an application.

> 
> 
> Also, the latex comments in the markdown are really ugly, can we not do that
> please?

Read the document in a markdown viewer and it'll be fine. Markdown sadly
doesn't have a decent table support.

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