Unable to play some streams in Edge browser on RxPlayer v3.30.0 #1289
Comments
|
We have collected logs for this issue: |
|
Thank you. So it seems there are two issues, the I guess Edge is telling us the first time that initialization didn't work and the second time with a safer strat that initialization cannot be retried as it was already performed! Some usual EME shenanigans :P. Like for the issue you linked, the fact that we're first calling Just some initial checks to ensure the RxPlayer is able to tell these are mp4 segments (I guess they are). Are the audio If no, then the most probable base issue could be that first the RxPlayer doesn't extract the PSSH as it doesn't know those are mp4 segments, and then when Edge does it, it does not announce (or does but differently than expected) that it is in the If yes, then I'm very curious of what that The two situations would have different work-arounds. |
|
Manifest Full Manifest: |
|
OK, so it does have it... Well, we may want to see what those encrypted events are about. We could add our own event listener in a console that just output the given data here, can you write in the console before playback something like: const base64abc = [
"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/",
];
function bytesToBase64(bytes) {
let result = "";
let i;
const length = bytes.length;
for (i = 2; i < length; i += 3) {
result += base64abc[bytes[i - 2] >> 2];
result += base64abc[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
result += base64abc[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
result += base64abc[bytes[i] & 0x3F];
}
if (i === length + 1) { // 1 octet yet to write
result += base64abc[bytes[i - 2] >> 2];
result += base64abc[(bytes[i - 2] & 0x03) << 4];
result += "==";
}
if (i === length) { // 2 octets yet to write
result += base64abc[bytes[i - 2] >> 2];
result += base64abc[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
result += base64abc[(bytes[i - 1] & 0x0F) << 2];
result += "=";
}
return result;
}
document.querySelector("video").addEventListener("encrypted", function (evt) {
console.log("Stringified encrypted event:", JSON.stringify(evt));
console.log("Base64-encoded init Data:", bytesToBase64(new Uint8Array(evt.initData)));
});
Basically it logs first the JSON-encodable format of the encrypted event linked to that issue, and then encode in a copy-pastable way the communicated data. I want to see if the latter are the expected PSSH boxes (in which case the RxPlayer did not already see them for whatever reason) or something else. |
|
We have added this code, but there are no logs for |
|
Thanks!
Weird it does not change much between v3.30.0 and v3.29.0 on this matter and the For the Is there an So the weirdness of having an Strangely, that event is seen by the browser after we're pushing a media segment (and not just after the initial initialization segment like what we would expect). So I guess that the "pssh" (which is a "box" of an MP4 file, basically a part of the mp4, announcing information on the wanted key) is inside a "moof" box, and not a "moov" box like we would expect normally (I see no documentation about it being set in a "moof" although I will have to see if other players check for that possibility). You can use an mp4 prober (e.g. mine: https://peaberberian.github.io/AISOBMFFWVDFBUTFAII/) to see in your loaded MP4 segments (both init and media segments) if the "pssh" is inside a "moof" or a "moov" box, or both. I guess the way your contents are packaged is unusual, though I don't know if it's compliant to the specification because I cannot seem to find in which specification this "pssh" box is defined - also sadly, I don't have access to many media-related specifications and a good chunk of them is not free. Now the last important question is why the thing breaks in v3.30.0 but not in the v3.29.0. For some reasons, in the This is a second mystery we have to resolve here... I have to think a little more about what can happen here for that one. |
I can confirm, we have checked this independently, me and @wioletta-dreszler and neither of us has
I filtered the logs, it looks like this: [Encrypted debug] Stringified encrypted event: {"isTrusted":true} |
|
@peaBerberian is there something which can either be done on RxPlayer-side or client-side for this issue? We would like to update to latest 3.x rxplayer version; but due to this issue we currently put this on-hold. |
|
Sorry, I didn't take the time to understand what may happen here. First there is something weird that seems to happen at the content-level with pssh information in media segments. If you can remove those to only have them on the initialization segment, as generally expected, it might fix the issue. In any case this might theoretically be work-arounded uglily by ensuring in our case that the const originalGenerateRequest = MediaKeySession.prototype.generateRequest;
MediaKeySession.prototype.generateRequest = function() {
const initDataType = arguments[0];
if (initDataType === undefined) {
arguments[0] = "cenc",
}
return originalGenerateRequest.apply(this, arguments);
}But I get that you might not want to add such ugly patch in your codebase. I'm also not completely sure of the final effect of that work-around here, we might have two license requests for the same license instead of just one (it shouldn't break playback though). |
|
@peaBerberian We have rechecked it using version 3.32.1, and it seems to be working fine. Were there any significant changes between version 3.30 and 3.32.1? |
|
I looked around and did not see why this would be the case, so, that's fortunate and worrying at the same time! This release did include some DRM code refactoring to help us debug DRM issues (as the majority of our issues are linked to DRM), so maybe a change there prevented a race condition that was previously happening? Let's hope it won't break again :s |
|
Just FYI, We met similar issue on MS Edge + Windows 11, turns out there's something wrong with |
|
Hi @KunXi-Fox , thanks for the information. Is it the same issue than the one from this issue? We've recently (after a Microsoft update) encountered PlayReady SL3000 issues on edge and windows 11 which led on a few devices to a black screen, where moving the window containing the media player fixes the issue until the next content starts. We've communicated the bug to Microsoft a few weeks ago but no answer for now. |
Issue observed on
Micosoft Edgebrowser, when running on Windows 11.After updating the RxPlayer form
v3.2.9tov3.3.0there seems to be an issue with streaming using Flussonic or VSPP platform.The stream does not play and the following errors appear:
rx-player.js:5263 Compat: error while calling 'generateRequest' with an empty initialization data type. Retrying with a default "cenc" value. TypeError: Failed to execute 'generateRequest' on 'MediaKeySession': The initDataType parameter is empty.rx-player.js:53355 API: The player stopped because of an error EncryptedMediaError: EncryptedMediaError (KEY_GENERATE_REQUEST_ERROR) InvalidStateError: Failed to execute 'generateRequest' on 'MediaKeySession': The session is already initialized.I noticed that similar error message has been already reported (but different case): #1259
The text was updated successfully, but these errors were encountered: