Widevine DRM Requests are sent twice #6636
Comments
Benny739
added
Bug
Needs Triage
|
HI @Benny739, License requests are made for each "license-request" event from EME. The reason there are four requests instead of two is that two key sessions are generated instead of one. The first is for the KEY URI in the playlist, and the second is for the key ID extracted from the "encrypted" event data. There is an expectation that these match. When that is not met, a second session is started (as seen in the logs above): The keyId found in the media from the "encrypted" event (456f...) does not match the parsed playlist KEY URI (3162...). Since no match is found ( Here is where eme-controller handles the "encrypted" event: hls.js/src/controller/eme-controller.ts Lines 544 to 622 in dd14360 I'm not sure if the mismatch is unintentional or an issue in
Other player libraries may ignore playlist keys and only integrate with EME using the data in "encrypted" events. HLS.js has access to the playlist key data in advance and uses them to generate sessions on segment load. The encrypted event is to be reconciled later (or the reverse in the case of "clear-lead" where the KEY tag shows up after some number of clear segments with boxes that produce the "encrypted" event). We could add an option to determine if both sources should be reconciled as they are now, or if only one (playlist or encrypted event keys) should be used. I prefer that the eme-controller be able to resolve this. You can work around this by filtering which sessions are generated by adding a a (working example forked from above https://codepen.io/robwalch/pen/yLdvQbL) var hls = new Hls({
debug: true,
enableWorker: true,
emeEnabled: true,
drmSystems: {
'com.widevine.alpha': {
licenseUrl: "https://drm-widevine-licensing.axtest.net/AcquireLicense",
generateRequest: (initDataType, initData, keyContext) => {
// Only generate sessions for playlist KEY-URIs.
// Change filter to 'ISO-23001-7' to only allow "encrypted" event initData.
if (keyContext.decryptdata.method === 'SAMPLE-AES') {
return { initDataType, initData };
} else {
return { initDataType, initData: null };
}
}
}
},
licenseXhrSetup: (
xhr,
url,
keyContext,
licenseChallenge,
) => {
if (licenseChallenge.length > 10) {
xhr.open('POST', url, true);
xhr.setRequestHeader('x-axdrm-message', '...');
}
}
});Another option would be to remove the "encrypted" event listener on if (keyContext.decryptdata.method = 'SAMPLE-AES') {
hls.media.removeEventListener('encrypted', hls.emeController.onMediaEncrypted);
} |
…D extraction for playlist match Fixes #6636
robwalch
added
Confirmed
and removed
Needs Triage
|
Hi @Benny739, I got to the bottom of it and have a fix in #6640. If everything checks out I'll cherry-pick it into patch/v1.5.x and cut a patch (v1.5.15) so that you don't need a workaround to avoid the redundant session/license requests. Thanks for reporting the issue and providing an example. It was a great help! |
robwalch
changed the title
#6640) * Parse multiple pssh from "encrypted" init data and fix Widevine key ID extraction for playlist match Fixes #6636 * Logging and assertion improvements per @cjpillsbury's review * Logging and assertion improvements per @cjpillsbury's review (cherry picked from commit a960251)
|
@Benny739 We've release v1.15.15 with a fix for this issue. Let me know if that works for you. If you're able to I'd also like to verify that PlayReady is working with your asset if you could share the license URL. You can reach out directly on video-dev slack if you like. Thanks! |
|
It works perfectly now, thank you for your help. |
What version of Hls.js are you using?
1.5.14
What browser (including version) are you using?
128
What OS (including version) are you using?
MacOs 14.6.1
Test stream
https://codepen.io/benny739/pen/gONvBbw
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
2 Requests are sent
What actually happened?
4 requests sent
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: