Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable synchronization through tighter rate control #2693

Closed
wilaw opened this issue Jul 6, 2018 · 0 comments
Closed

Enable synchronization through tighter rate control #2693

wilaw opened this issue Jul 6, 2018 · 0 comments

Comments

@wilaw
Copy link
Member

wilaw commented Jul 6, 2018

There are many solutions coming to market which use synchronized playback between clients as a differentiating factor. For betting and gambling applications, having tight sync between clients is a legal requirements to avoid giving an advantage to a subset of users who may be ahead of others. We would like dash.js to be able to offer a simple syncrhonization feature

Goal: synch clients to within 250ms of each other

Approach: The current 2.8.0 release features a catch-up feature, in which playback rate can be accelerated up to 20% faster than real-time in order to return the playhead to a target latency. This behavior seems to have some tolerance (perhaps 500ms) before it activates. By tightening this tolerance and raising the maximum catch up rate to 50%, as well as developing an algorithm to both accelerate and retard the playhead around the target latency, we feel that a simple level of synchronization can be achieved.

Proposed algorithm:

  1. Define a target latency in seconds of T. This is set by the application using setLiveDelay()
  2. Define M = latency tolerance in seconds at which max distortion is applied (1s)
  3. On a fast loop during playback
    var L = getCurrentLiveLatency(),
    var D = (L - T)*5/M
    var S= sigmoid function of D = 1/(1+e^-D)
    playback rate R = 0.5 + S

You may prefer a linear function as opposed to this sigmoid one. Irrespective of the algorithm used, goal is for the latency to rapidly & stably converge on the target. You may also wish to define a small window of allowable drift before the rate is corrected away from 1, as I am not sure of the long-term effects of playing back a stream at a rate != 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants