[Bug 764396] New: Add GST_EVENT_LATENCY_CHANGED

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 764396
           Summary: Add GST_EVENT_LATENCY_CHANGED
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: havard.graff at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: gstreamer at pexip.com
     GNOME version: ---

Created attachment 325055
  --> https://bugzilla.gnome.org/attachment.cgi?id=325055&action=edit
suggested implementation

clipped from #gstreamer:

Lets start with some history:
Back in 2008 we needed a dynamic jitterbuffer.
After discussing back and forth with wtay, we came to the conclusion that
the proper way to do this was to:
1. Change the latency property on the jitterbuffer
2. The jb would then post a latency message on the bus
3. in the bus-handler (in the application), this msg would be picked up,
and wtay added a new method gst_bin_recalculate_latency that the
application could emit on the main pipeline to have the whole pipeline
query its latency again (each sink sending upstream latency queries etc).

Now this has worked ok for us ever since, in Pexip we terminate the
latency in the mixers, not in the sinks, but other then that it works
exactly the same way as before. But lately we have discovered that this
has some horrific side-effects, in that with many participants connecting,
and latency changing often, we in fact, using this method,
are recalculating EVERYONES latency when we only want to reconfigure that
of a single participant. or more specifically the jitterbuffers with the
same cname belonging to that participant.

Now, I know the idea of "groups of sinks" have been mentioned before,
but we are at a stage now where we really need to be able to re-calculate
latency only for the affected sinks / mixers, and this is where I have a
concrete suggestions: a downstream "latency-changed" event that in turn
can trigger an upstream latency query, either from a sink or from a mixer.

If this was emitted from the jitterbuffer in the same place the
latency-message is emitted, it would mean all affected downstream
mixers/sinks would know "directly" that latency had changed somewhere
upstream from them, and could make decisions based on this.

For us it would mean re-sending latency-queries upstream from the mixers
that received this event, and then using this new latency in the mix.
For this sink-case, it would be the same way, only that with using
this "mode" the sinks would get their new latency "independent" of the
pipeline latency, and the "grouping" would then happen from whichever
sources decided to send this event.

So in the case of rtpbin, you are already changing latency for all the
jitterbuffers with the same cname as one "group", and hence all of them
would also be sending the latency event, ensuring lipsync at the
mixers/sinks.

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