-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Hls.js requesting the same AES-128 decryption key twice for audio tracks #3900
Comments
The audio-stream-controller and stream-controller are responsible for loading keys and segments in their respective playlists. They don't share any information about what has been loaded or has the same URL across files so keys in each playlist with the same URL are loaded once per playlist. |
Hello robwatch, my point is that this should be mimicking the iOS and Safari behavior as that might be the most wildly used HLS player our there - not counting HLS.js. Please let us know if you plan to work on this improvement or if it might take a while. Thanks, |
Hi @foliovision,
Agreed.
I have no plans to work on this. I have provided information on why a key listed in two playlists is loaded twice. If this issue is important to you, and you use HLS.js, consider making a contribution to open-source. |
Fixed by #4861 scheduled for v1.3.0. |
Hello @robwalch I compiled HLS.js from the master branch where your fix was already merged. I tested it and I see no difference in the way our HLS streams load - it's the same with HLS.js 1.2.3 and the current master branch: So it seems your improvement did not change anything in our case. Also, this issue is about the difference of how Safari plays the HLS natively (one request for decryption key) and how HLS.js plays it (once request for video and one for audio). Unfortunately that was not improved either. |
Perfect, it works! Only one request for the decryption key, just like when playing in Safari or on iPhone. |
This fix has been released in v1.3.0. |
What version of Hls.js are you using?
v1.0.3
What browser and OS (including versions) are you using?
macOS 10.14.6 with Safari 13.1.1 and Chrome 90.0.4430.212
Test stream:
https://foliovision.com/hls/master.m3u8
Configuration:
Checklist
Steps to reproduce
That's because the HLS is supported natively.
Expected behavior
Since https://foliovision.com/hls/key.bin was loaded once for the stream, I would expect the second load to not happen.
Otherwise the HLS.js behavior is different from what you get in devices with native HLS support where HLS.js cannot be used - like the iPhones.
Actual behavior
The https://foliovision.com/hls/key.bin file is loaded twice, lowering the security of the encrypted stream.
We limit the access to the AES-128 decryption key and because of this flaw we have to treat iPhone users differently from other browsers which can use HLS.js.
In Hls.js 0.11.0 it used to only request to decryption key once.
Console output
The text was updated successfully, but these errors were encountered: