Multi-period DASH SSAI live streams no longer start at live edge since v4.13.0 #9556
Description
Have you read the FAQ and checked for duplicate open issues?
Yes
If the problem is related to FairPlay, have you read the tutorial?
NA
What version of Shaka Player are you using?
4.16.12
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from main?
Yes
Are you using the demo app or your own custom app?
Custom app
If custom app, can you reproduce the issue using our demo app?
Yes
What browser and OS are you using?
Chrome and All Web TV platforms
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
NA
What are the manifest and license server URIs?
If required we will share via email.
What configuration are you using? What is the output of player.getNonDefaultConfiguration()?
'{\n "drm": {\n "retryParameters": {\n "maxAttempts": 11,\n "timeout": 10000,\n "stallTimeout": 30000,\n "connectionTimeout": 30000\n },,\n "advanced": {\n "com.widevine.alpha": {\n "distinctiveIdentifierRequired": false,\n "persistentStateRequired": false,\n "sessionType": "",\n "serverCertificateUri": "",\n "individualizationServer": ""\n }\n }\n },\n "manifest": {\n "retryParameters": {\n "maxAttempts": 11,\n "timeout": 10000,\n "stallTimeout": 30000,\n "connectionTimeout": 30000\n },\n "enableAudioGroups": false,\n "dash": {\n "ignoreMinBufferTime": true\n }\n },\n "streaming": {\n "retryParameters": {\n "maxAttempts": 11,\n "timeout": 10000,\n "stallTimeout": 30000,\n "connectionTimeout": 30000\n },\n "rebufferingGoal": 6,\n "bufferingGoal": 30,\n "inaccurateManifestTolerance": 0,\n "lowLatencyMode": false,\n "dontChooseCodecs": true\n },\n "abr": {\n "useNetworkInformation": false,\n "defaultBandwidthEstimate": 2500000\n },\n "cmcd": {\n "sessionId": "45b4b25f-0f24-47e0-94dd-667a6969a1ce"\n }\n}'
What did you do?
Attempted to play a multi-period DASH live stream with server-side ad insertion (SSAI), such as streams delivered via AWS MediaTailor or Google IMA DAI, using Shaka Player (v4.13.0 and above).
What did you expect to happen?
Multi-period dash assets to play from the live edge i.e: (live DVR seek range end) position instead of live DVR seek range start.
What actually happened?
For multi-period DASH SSAI live assets, playback no longer starts at the live edge (end of the DVR seekable range).
Starting with Shaka Player v4.13.0, the player consistently initializes playback at the beginning of the live DVR window, rather than at the live edge. This results in a progressive live-edge drift, even when playback is well within the time-shift buffer.
We traced this regression to the following change introduced in v4.13.0: PR: #7905
When this change #7905 is reverted, Playback correctly starts at the live edge and DVR restart behavior also working as expected. Live-edge drift is no longer observed.
Earlier (Jan' 2024), we had proposed explicit support for live streams with an infinite duration (Issue #6205):
That approach was later removed, and Shaka transitioned to an MSE-based live seekable range model, where the effective live window is determined using:
MediaSource.prototype.setLiveSeekableRange
MediaSource.prototype.clearLiveSeekableRange
This approach shift appears to have altered the initial playback start-position logic, causing Shaka to prefer the start of the live DVR window rather than the end (live edge) for multi-period live DASH streams.
A related mitigation was later introduced via: PR #8575
This added the configuration: streaming.returnToEndOfLiveWindowWhenOutside
While this option mitigates cases where playback falls behind the live window particularly on slower devices.
And can force playback to start at the live edge when the initial start position is detected to be outside the live seekable range, it operates as a fallback mechanism and does not fundamentally resolve the underlying regression in the initial live-edge determination logic for multi-period live DASH assets.
Please refer: A similar symptom was previously reported, especially on slower devices: PR: #8175
Are you planning to send a PR to fix it?
No