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

Fix AES-128 in streams with alt-audio tracks #3782

Merged
merged 2 commits into from Apr 16, 2021

Conversation

robwalch
Copy link
Collaborator

@robwalch robwalch commented Apr 15, 2021

This PR will...

Fix a regression in AES key loading that causes the main and audio stream controllers to load each others' fragments on KEY_LOADED.

Why is this Pull Request needed?

Prior to v1.0, onKeyLoaded would set the stream controllers' state to IDLE (even if it was the other controller/level/track fragment's key that was loaded), but this wasn't a show stopper (at worst I guess it would result in keys being requested more than once).

In v1.0 the fragment is requested as soon as the key is loaded and parsed, rather than waiting for the next tick. This was done in an effort to improve the performance of AES streams. Our test samples do not include an encrypted stream with separate tracks like the one found in #3772 so this one slipped through.

Resolves issues:

Fixes #3772

Checklist

  • changes have been done against master branch, and PR does not conflict

@robwalch robwalch added this to the 1.0.2 milestone Apr 15, 2021
@robwalch robwalch requested a review from itsjamie April 15, 2021 18:02
@robwalch robwalch merged commit c1da9cb into master Apr 16, 2021
@robwalch robwalch deleted the bugfix/aes-in-audio-stream-controller branch April 16, 2021 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"TS packet did not start with 0x47" on AES-128 HLS (with AAC sound)
1 participant