You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 'liveDelay' and 'liveCatchUpPlaybackRate' are very useful APIs that keep the player at a consistent latency behind live in a low latency playback scenario. However they always apply, even if the end user wants to seek back within the stream. Consider the case of a live sports event with a 3hr DVR window. The user watches at the live edge 3s behind live for most of the game, but then wants to seek back 60s to rewatch the goal that was scored. Although the seek() APi will take the playhead there, the live delay function will then accelerate playback to the maximum allowed (0.5 by default) until the user is brought back to 3s behind live. This is not a good user experience.
One solution to this problem is for the live delay target to only be active within a certain threshold range behind live. A reasonable threshold might be twice the live target that is set. So if livedelay is set to 3000ms, then anytime the playhead is within 0-6000ms, the live delay feature will be active. However, if the user seeks back beyond the 6000ms delay, then livedelay would be deactivated, allowing the user to watch the DVR content at a standard playback rate. If the user seeks back to live via their UI scrub-bar, it would bring them back to within the 6000ms threshold, and then live delay would be re-enabled.
These thresholds and in fact this solution are just suggestions. The implementers may have a better idea of how to enable DVR seekback while still supporting a live delay target.
The text was updated successfully, but these errors were encountered:
The 'liveDelay' and 'liveCatchUpPlaybackRate' are very useful APIs that keep the player at a consistent latency behind live in a low latency playback scenario. However they always apply, even if the end user wants to seek back within the stream. Consider the case of a live sports event with a 3hr DVR window. The user watches at the live edge 3s behind live for most of the game, but then wants to seek back 60s to rewatch the goal that was scored. Although the seek() APi will take the playhead there, the live delay function will then accelerate playback to the maximum allowed (0.5 by default) until the user is brought back to 3s behind live. This is not a good user experience.
One solution to this problem is for the live delay target to only be active within a certain threshold range behind live. A reasonable threshold might be twice the live target that is set. So if livedelay is set to 3000ms, then anytime the playhead is within 0-6000ms, the live delay feature will be active. However, if the user seeks back beyond the 6000ms delay, then livedelay would be deactivated, allowing the user to watch the DVR content at a standard playback rate. If the user seeks back to live via their UI scrub-bar, it would bring them back to within the 6000ms threshold, and then live delay would be re-enabled.
These thresholds and in fact this solution are just suggestions. The implementers may have a better idea of how to enable DVR seekback while still supporting a live delay target.
The text was updated successfully, but these errors were encountered: