Open el-gringo opened 1 year ago
After further investigation, I found we are comparing keyIds filled with zero.
Added debug logs in KeySessionRecord.isCompatibleWith
KeySessionRecord.isCompatibleWith areAllKeyIdsContainedIn(keyIds, this._keyIds) false keyIds 4cfc3e42a7a261dde12942df0ed35ee4, 00000000000000000000000000000000 this._keyIds 4cfc3e42a7a261dde12942df0ed35ee4, 580d1c7034d8e8182374fe77c47749a0, 12a3fa84d5168ba4eb24ccf5e1149701, 1fbaec395d013374e6cb207107dd1b0a, c78f56d837307cc2346ecab5efc583c8 [key_session_record.js:142:17](http://localhost:5173/@fs/home/cbosse/Workspaces/player/rx-player/dist/_esm5.processed/core/decrypt/utils/key_session_record.js?t=1669204874185)
KeySessionRecord.isCompatibleWith areAllKeyIdsContainedIn(keyIds, this._initializationData.keyIds) false keyIds 4cfc3e42a7a261dde12942df0ed35ee4, 00000000000000000000000000000000 this._initializationData.keyIds 4cfc3e42a7a261dde12942df0ed35ee4, 580d1c7034d8e8182374fe77c47749a0, 12a3fa84d5168ba4eb24ccf5e1149701, 1fbaec395d013374e6cb207107dd1b0a, c78f56d837307cc2346ecab5efc583c8
I have found 2 issues so far.
keyId
comes from our MP4 init fragment. KeySessionRecord.associateKeyIds
happens after the next ContentDecryptor.onInitializationData
I have added a check about the keyId
. But I am not sure how to delay onInitializationData
after keyIds have been associated to the current session.
Hi,
Sorry for the late response. If I follow correctly, you have a content with two keys, one for video and one for audio, yet the RxPlayer re-ask for a key it should already have? Does it stops after a time (for example, once every qualities have been switched to)?
And you think that this is due to the key-id containing all 0
? For which PSSH, widevine? That's possible, but I'm unsure of why for now.
The MPD also does not list any key-id set to 0
and the RxPlayer does not parse the PSSH for DASH contents, so I'm unsure of how it can know about that 0
key-id before creating a MediaKeySession
here.
You're right to look around the KeySessionRecord
concept as it is the element storing which key(s) a MediaKeySession
is linked to. If MediaKeySession
are re-created, it should be because an old one was thought to be incompatible with it and we find out this mainly by checking its KeySessionRecord
's isCompatibleWith
method.
The zero keyId doesn't come from PSSH from DASH, but from the init MP4 segment.
Yes we have keyId for each AdaptationSet type. RxPlayer doesn't ask for a for a key but plays fine now that I have fixed the zero filled keyId issue. However it triggers 3 license-request
to our Widevine server instead of 1, same forlicence-renewal
.
My understading is that we have to discover all manisfest keyIds before trying to create a new session.
Have you set singleLicensePer
to "content"
in loadVideo()
keySystems
options ? If not, it defaults to "init-data"
and you get one license request per content key, here 2. Of the 3 license requests, the 1st one occurring may be the initial request for a Widevine service certificate, which you can avoid I think by setting it statically through the serverCertificate
option.
Yes I tried it, and it leads me to another issue: API: The player stopped because of an error TypeError: chosenRepFromBandwidth is undefined
.
I have not investigated further.
Hello,
Since release 3.27.0, the player creates many temporary DRM sessions, triggering many calls to our license server.
It seems that the current algorithm creates a new DRM session for each keyId instead of re-using an already created session. We are using DASH + Widevine.
Here are the logs of a DRM session :
The kind of manifest we use :
La payload de notre
loadVideo
: