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

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #4 from Edward Hervey <bilboed at gmail.com> 2013-08-13 15:37:26 UTC ---
(In reply to comment #3)
> 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'm tempted to say it's up to the emitter of the event to handle that.

> 
> 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.

  That would make sense, though only testing will prove whether that's correct
or not :) Both elements will need to have the code for estimation/emission
anyway.

> 
> 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).

  Tricky.

  If all streams coming into the muxer have the same clock estimation then it
means they all belong to the same "time realm". In that case the muxer only
needs to forward the estimation events downstream and it uses the incoming
timestamps as if no estimation/correction was to be applied.

  If they belong to different domains ... should it correct everything at that
point (and essentially "swallow and apply" those estimations and not forward
estimations downstream) ? 


> 
> 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 ?

  The time-realm for upstream QoS message would need to remain "uncorrected"
running-time.

-- 
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.