Closed phloxic closed 2 years ago
robwalch
commented
2 years ago Could this be an issue with your stream's byte-ranges? Or is it a WebCrypto issue in most browsers? Only certain segments throw "OperationError" exceptions from subtle.decrypt so the issue must be with the input.
phloxic
commented
2 years ago Could this be an issue with your stream's byte-ranges? Or is it a WebCrypto issue in most browsers? Only certain segments throw "OperationError" exceptions from
subtle.decryptso the issue must be with the input.
subtle.decrypt? Can't spot that anywhere.
Stream issue is of course always possible. However:
phloxic
commented
2 years ago @robwalch - can you point me to a sample stream with AES-128 encrypted fmp4 which works with hls.js?
mtoczko
commented
2 years ago Hi @phloxic I tested your stream on other players (theoplayer, bitmovin, shaka), none played the stream correctly in the chrome. FFplay:
[hls @ 0x7f9fddd8eb00] Opening 'https://phloxic.productions/test/bed3b76bcc9e/720p1.key' for reading
[https @ 0x7f9fe1b55e80] HTTP error 416 Requested Range Not Satisfiable
[hls @ 0x7f9fddd8eb00] Unable to open key file https://phloxic.productions/test/bed3b76bcc9e/720p1.keyOnly certain segments throw "OperationError" exceptions from subtle.decrypt so the issue must be with the input.
subtle.decrypt? Can't spot that anywhere.
It's the same code and the same input running in both browsers. Works in Safari but throws in Chrome. Our SoftwareAES does not work in either because the number of bytes input does not match the expected range (802 vs 800). We could point the finger in either direction. Filing issues with Chromium and Feedback Assistant would be a good way to get some answers.
phloxic
commented
2 years ago Thanks. Fwiw it's also not working in Firefox.
@mtoczko - yes, doesn't work with video.js' vhs engine either. @robwalch, Firefox error RangeError: buffer length for Int32Array should be a multiple of 4 seems to point in same direction.
I still would be interested to actually see a sample stream working outside Safari, I haven't found one. If I find time, I'll try first a couple of other segmentation scenarios.
phloxic
commented
2 years ago I think the issue can be confined to AES-128 encrypted fmp4 byte-range (single file) assets. Without byte-range it seems to work (example).
mtoczko
commented
2 years ago I would see the problem here, the bit ranges are not divisible by 4
#EXT-X-MAP:URI="360p.mp4",BYTERANGE="802@0"#EXT-X-MAP:URI="270p.mp4",BYTERANGE="801@0"#EXT-X-MAP:URI="108p.mp4",BYTERANGE="799@0"Thanks @mtoczko, yes, I am aware of that. But I guess I'm still having a hard time wrapping my head around the fact that these tags have the same values in the clear streams which play fine.
At the moment I understand that Safari's decrypter can handle these init segments, whereas webcrypto expects ranges divisible by 4 for init segments as well - I made a few calculations, and the remaining actual segment ranges seem to be all divisible by 4.
robwalch
commented
2 years ago Widening the byte-range for AES-128 encrypted segments is described in https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-08#section-6.3.6 (applies to I-frames and init segments)
robwalch
commented
2 years ago I put up a PR (#4941) against the DRM branch I've been working on scheduled for next month (v1.3.0). If you need this fix earlier, feel free to open a PR against master indicating that you'd like the change in a patch (v1.2.5) because the lack of support is blocking your workflow.
phloxic
commented
2 years ago Widening the byte-range for AES-128 encrypted segments is described in https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-08#section-6.3.6 (applies to I-frames and init segments)
@robwalch - thanks for that link; I failed to find that passage.
phloxic
commented
2 years ago I put up a PR (#4941) against the DRM branch I've been working on scheduled for next month (v1.3.0). If you need this fix earlier, feel free to open a PR against master indicating that you'd like the change in a patch (v1.2.5) because the lack of support is blocking your workflow.
@robwalch - brilliant. No rush from my side.
phloxic
commented
2 years ago @robwalch - according to my local testing the fix does the job. Thank you.
What version of Hls.js are you using?
v1.2.3, but happened also before
What browser (including version) are you using?
all browsers except (most versions) of macOS Safari
What OS (including version) are you using?
macOS 10.15.7
Test stream
https://hls-js.netlify.app/demo?src=https%3A%2F%2Fd12zt1n3pd4xhr.cloudfront.net%2Fdev%2Ffmp4-aes-en-nif.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
It plays in Safari, both with hls.js and natively. Note however, there is/was a bug with some Safari versions 13.x and 14.x: https://developer.apple.com/forums/thread/131625 but it seems to be fixed.
Expected behaviour
Stream plays.
What actually happened?
Stream hangs.
Console output