shaka-player: A/V sync regression after dynamic ad break on HLS stream
Have you read the FAQ and checked for duplicate open issues? yes
What version of Shaka Player are you using? nightly
Can you reproduce the issue with our latest release version? yes, 4.2.2
Can you reproduce the issue with the latest code from main?
yes
Are you using the demo app or your own custom app? demo app
If custom app, can you reproduce the issue using our demo app?
What browser and OS are you using? Chrome, macOS
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
What are the manifest and license server URIs?
Will send in separate email
What configuration are you using? What is the output of player.getConfiguration()?
default demo app config
What did you do?
Add custom content, play, wait until ad break is over (there will be a timestamp on screen when the “real” program is playing)
Observe A/V sync
What did you expect to happen? A/V to be in sync after ad break
What actually happened?
Audio and video are out of sync, and will get more out of sync after successive ad breaks.
We were hoping the issues would be solved by https://github.com/shaka-project/shaka-player/issues/4308 but unfortunately this doesn’t seem to be the case.
Using an older version ( https://v3-3-11-dot-shaka-player-demo.appspot.com/demo/ ) A/V are still in sync after the ad break. Using the nightly version ( https://nightly-dot-shaka-player-demo.appspot.com/demo/ ) A/V are out of sync after the ad break.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 46 (43 by maintainers)
Commits related to this issue
- fix(HLS): Fix AV sync over ad boundaries If server-side ad segments aren't aligned, AV could get out of sync by accumulating errors in the timestampOffset of the SourceBuffers. This fixes the issue ... — committed to joeyparrish/shaka-player by joeyparrish 2 years ago
- fix(HLS): Fix AV sync over ad boundaries (#4824) If server-side ad segments aren't aligned, AV could get out of sync by accumulating errors in the timestampOffset of the SourceBuffers. This impro... — committed to shaka-project/shaka-player by joeyparrish 2 years ago
- fix(HLS): Fix AV sync over ad boundaries (#4824) If server-side ad segments aren't aligned, AV could get out of sync by accumulating errors in the timestampOffset of the SourceBuffers. This improves... — committed to shaka-project/shaka-player by joeyparrish 2 years ago
- fix(HLS): Fix AV sync over ad boundaries (#4824) If server-side ad segments aren't aligned, AV could get out of sync by accumulating errors in the timestampOffset of the SourceBuffers. This impro... — committed to shaka-project/shaka-player by joeyparrish 2 years ago
- fix: Fix parsing error on Chromecast when resyncing HLS (#4869) Setting the timestampOffset requires an abort() in some cases on Chromecast. Issue #4589 — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix(HLS): Fix discontinuity tracking (#4881) Discontinuity tracking was broken and test coverage was insufficient to catch this. This fixes the parsing and counting of discontinuities, and replaces... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Fix potential duplicate segments, AV sync issues Make SegmentIndex robust against rounding errors so that we don't end up with duplicate segments on merge. In sequence mode, this would cause a ... — committed to joeyparrish/shaka-player by joeyparrish a year ago
- fix: Make encoding problem detection more robust Before, tiny segments (~33ms in practice) and overwritten segments (sometimes necessary) would register as encoding problems. This makes the logic mo... — committed to joeyparrish/shaka-player by joeyparrish a year ago
- fix: Fix potential AV sync issues after seek or adaptation After seeking or adaptation, StreamingEngine will create a new SegmentIterator. However, if the buffered ranges are different enough from t... — committed to joeyparrish/shaka-player by joeyparrish a year ago
- fix: Fix potential AV sync issues after seek or adaptation (#4886) After seeking or adaptation, StreamingEngine will create a new SegmentIterator. However, if the buffered ranges are different enoug... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Make encoding problem detection more robust (#4885) Before, tiny segments (~33ms in practice) and overwritten segments (sometimes necessary) would register as encoding problems. This makes the... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Fix potential duplicate segments, AV sync issues (#4884) Make SegmentIndex robust against rounding errors so that we don't end up with duplicate segments on merge. In sequence mode, this would ... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Sync each segment against EXT-X-PROGRAM-DATE-TIME (#4870) Closes #4589 — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Fix parsing error on Chromecast when resyncing HLS (#4869) Setting the timestampOffset requires an abort() in some cases on Chromecast. Issue #4589 — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix(HLS): Fix discontinuity tracking (#4881) Discontinuity tracking was broken and test coverage was insufficient to catch this. This fixes the parsing and counting of discontinuities, and replaces... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Fix potential AV sync issues after seek or adaptation (#4886) After seeking or adaptation, StreamingEngine will create a new SegmentIterator. However, if the buffered ranges are different enoug... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Make encoding problem detection more robust (#4885) Before, tiny segments (~33ms in practice) and overwritten segments (sometimes necessary) would register as encoding problems. This makes the... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Fix potential duplicate segments, AV sync issues (#4884) Make SegmentIndex robust against rounding errors so that we don't end up with duplicate segments on merge. In sequence mode, this would ... — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Sync each segment against EXT-X-PROGRAM-DATE-TIME (#4870) Closes #4589 — committed to shaka-project/shaka-player by joeyparrish a year ago
- fix: Fix parsing error on Chromecast when resyncing HLS (#4869) Setting the timestampOffset requires an abort() in some cases on Chromecast. Issue #4589 — committed to shaka-project/shaka-player by joeyparrish a year ago
I ran out of time to work on this before the holidays. I’ll be back on this in January. Thanks!
And I’ve seen these ad breaks so many times now, I really want to watch “Marko & Irma”.
Perfectly in sync after 45 minutes with the latest fixes and
yo.pdt=sync.Thanks! I’ll try it out.
I’ve just started the release process for v4.3.3 and v4.2.7 which will include all the fixes tracked in this issue.
The production stream has the same problem as I observed on the test stream. After an ad break, the PDT values for the main content are out of sync. In the break I just watched, the video and audio ad segments differed in length by 5ms. After the break, the PDT values for the main content differed by 5ms for video and audio. If I rejoin with a new session, the same segments have synced PDT values again.
The same is true of the updated test stream. In that case, the first ad break put the main content out of sync by 38ms.
The PDT values in your content are different for the same segments in different sessions, which makes them unreliable for AV sync. The “align pdt” setting you mentioned in your email does not appear to have any effect on the stream.
This needs to be resolved in the ad stitcher, I believe, before the player can make use of the information. If we stay in a session with your content long-term, all available information from the manifest (PDT, segment durations) would direct us to play out of sync. The player can’t create the correct information from any source.
I believe the config for the test url has been updated now, might take a few minutes for the change to take effect
Good news! I’ve watched this several times, and my Swedish is improving. 🇸🇪
It appears that desync increases by roughly 50-100 ms per ad. Joining mid-ad-break results in less desync that joining during the main program and sitting through an entire ad break.
This content appears to be a loop of the same program and ad content each time. Each ad break seems to add to the desync by a little more than 1 second.
I’m now experimenting with a change that resynchronizes the SourceBuffers across discontinuity bounds, so that we don’t accumulate errors in
timestampOffsetover time. It should be fairly obvious if the fix is working, since 1) the effect is so pronounced and 2) the effect can be measured in the debug console.Having done some bisecting, these are my findings:
36d0b5484fad68dc1d640fbddf2fae3e1eb7169b- this commit has audio in sync, but recurring bufferings as shaka will jump to catch up with seek rangec438e857f2f122eb45899148e067d68ffec3477c- this commit will fix the buffering from the above commit, but audio will be out of sync after the ad breakI’ll see if I can find out more