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

Error alert box for 2-keys encrypted livesim2 content #4651

Closed
tobbee opened this issue Dec 13, 2024 · 1 comment · Fixed by #4657
Closed

Error alert box for 2-keys encrypted livesim2 content #4651

tobbee opened this issue Dec 13, 2024 · 1 comment · Fixed by #4657
Labels
Milestone

Comments

@tobbee
Copy link
Contributor

tobbee commented Dec 13, 2024

Environment
Steps to reproduce
  1. Play the URL
Observed behavior

An error alert box with the message

Error Dash.js; 36
All possible Adaptation Sets have an invalid key status

This does not happen on 4.7.4 or for the corresponding asset with one key:

https://livesim2.dashif.org/livesim2/drm_EZDRM-1-key-cbcs/testpic_2s/Manifest.mpd

Expected behavior

There should be no error alert box

@tobbee tobbee added the Bug label Dec 13, 2024
@dsilhavy dsilhavy added this to the 5.0.0 milestone Jan 6, 2025
@dsilhavy dsilhavy mentioned this issue Jan 6, 2025
@dsilhavy
Copy link
Collaborator

dsilhavy commented Jan 6, 2025

This will be fixed with #4657.

The problem was that the current testvectors either used the same key id for audio and video or returned all keys within a single license request.
The LiveSim2 content uses two key ids one for audio and one for video. Two license requests are required to get the required keys for both tracks.

With the previous implementation, we were checking the key status map after the first license request. This lead to a missing status for the audio key id and dash.js concluding that the audio track is not playable.

I changed the implementation and added a new flag hasTriggeredKeyStatusMapUpdate for each media key session. Only when a media key session has updated the key status map the corresponding track might get filtered based on the status of the key.

For implementation details, refer to #4657. I am open for suggestions on how to handle this issue differently.

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

Successfully merging a pull request may close this issue.

2 participants