[Bug 704331] Clock estimation (aka: Forward QoS)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704331
  GStreamer | gstreamer (core) | git

Olivier Crete (Tester) <olivier.crete> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olivier.crete at ocrete.ca

--- Comment #3 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2013-07-29 07:34:16 UTC ---
It may be interesting to have some measure of the "stability" of the rate in
the event (so that a downstream element could ignore it until the rate
stabilizes enough). 

I would assume that the first to do clock estimation is probably best placed,
so for example if you have mpeg-ts in RTP, the RTP one should be used.

I guess for example, the mpeg-ts muxer would need to "apply" the correction, or
we could have an element that just applies the rate correction (ie modifies the
timestamps according to the long term rate).

Another question is what happens to the current upstream QoS message, how does
that interact with this? Is upstream QoS supposed to just be sent as if there
was no forward-qos message ?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.