[Bug 764396] Add GST_EVENT_LATENCY_CHANGED

[GStreamer (GNOME Bugzilla)]

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

--- Comment #4 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
Thanks for input!

I really see this as a useful "puzzle piece", not as a complete implementation
in itself. Like, some elements maintain an internal "upstream_latency" variable
(like the jitterbuffer), upon receiving this event, it would always be a good
idea to re-query for the new value here.

As Olivier points out, this is not going to solve anything by itself, but the
fact that you now will know which sinks are directly affected by the
latency-change, from the pure novelty that they are the ones connected to the
element that have changed its latency, seems very useful to me as a piece in a
perhaps new and more focused way of doing latency in a pipeline.

As an idea, if we now added a property to base-sink, "group-id", upon receiving
the latency-changed event, base sink could now emit a signal to the pipeline,
and that could now resync all the sinks with the same group-id as the one that
emitted the signal.
Note how if one were to attempt the same thing with todays bus-approach, the
application would need to keep a map of which elements (with the potential of
changing their latency) are connected to which sinks. The latency-changed event
basically keeps the information localized by utilizing the pipeline itself.

I am sure there are other approaches as well, but I strongly feel that leaving
the bus out of something so "pipline-internal" as the latency-calculation
really is, is a right way forward, and that we then can allow for bigger
complexities, like having multiple "groups" etc.

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