-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
'trackschanged' event not fired after a license request is denied for an HD track #4874
Comments
I've dug a bit deeper and found out that the commit that introduces the change of behavior (only one 'trackschanged' event fired instead of two) is this one : c046081 |
Also I've asked EZDRM support whether or not this blank response was OK from their side, and here is their answer :
Is there anything I could do in a responseFilter so that the |
There might be better solutions, but in the meantime:
|
Since :
... I am not sure I can use this solution :(
I am not sure I can determine which variant is being refused in the response filter ? Thanks for the suggestions though! |
My bad, I assumed the documentation I looked at was for the variants returned by
True. I can't think of a way to do that, so that workaround would only work if you knew in advance that it would always be the highest bitrate. |
Can the shaka player development team give me their opinion about this problem? I think this piece of code should still be executed when if (metadata) {
if (metadata.updatePromise) {
metadata.updatePromise.resolve();
}
// In case there are no key statuses, consider this session loaded
// after a reasonable timeout. It should definitely not take 5
// seconds to process a license.
const timer = new shaka.util.Timer(() => {
metadata.loaded = true;
if (this.areAllSessionsLoaded_()) {
this.allSessionsLoaded_.resolve();
}
});
timer.tickAfter(
/* seconds= */ shaka.media.DrmEngine.SESSION_LOAD_TIMEOUT_);
} Just like By the way, has anyone else using EZDRM experienced this same problem? If so, I'd be interested to know how they solved or worked around it! |
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
4.3.1
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from
main
?Yes
Are you using the demo app or your own custom app?
Both
If custom app, can you reproduce the issue using our demo app?
Yes
What browser and OS are you using?
Chrome or Firefox on Linux Ubuntu
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A
What are the manifest and license server URIs?
https://shaka-player-demo.appspot.com/demo/#audiolang=fr;textlang=fr;uilang=fr;asset=https://dpk3dq0d69joz.cloudfront.net/origin/HLS_140672_0-VO-cenc.ism/stream.mpd;license=https://widevine-dash.ezdrm.com/proxy?pX=BA5EDC&contentId=HLS_140672_0-VO&[email protected];panel=CUSTOM%20CONTENT;build=uncompiled
What configuration are you using? What is the output of
player.getConfiguration()
?Result of running the following code in the demo app :
What did you do?
Hello !
I am currently experiencing problems with shaka-player version 4.3.1.
Our DRM provider is EZDRM and one of our programs is streamed using MPEG-DASH with the following tracks and keys:
Shaka player is configured to use ABR, loads the manifest and makes 3 license requests for the 3 keys. The first 2 requests are granted but the third one is denied. This is normal, since this is what we want: to deny the playback of the 720p stream in the browser.
EZDRM (ou DRM provider) returns an empty response (0 bytes) for the 3rd license request (I don't know if this is normal, but we always got an empty response in this case from EZDRM, it reminds me of this ticket comment), which triggers an error 6008 (Failed to execute 'update' on 'MediaKeySession': The response parameter is empty) on the client side (shaka player). I don't know if it's normal to get this 6008 error, but we always got it in this case.
The problem is that you can't play the movie (or play it only for a few seconds, until ABR figures out that the network is good and it can switch to 720p).
What did you expect to happen?
The movie should be playable with ABR, and 720p track not available.
What actually happened?
While debugging further, I found out that :
By analyzing our code with
git bisect
, I found that it was the update of shaka player from version 2.3.0 to version 3.2.9 that introduced the problem on our side, then by dichotomizing the versions of shaka player between 2.3.0 and 3.2.9, I found that it was version 2.4.4 that introduced the problem.I'm having trouble seeing in the contents of 2.4.4 what could cause this...
So my questions are:
Thanks in advance for your answers and help! (and for the great work with shaka player ;)
The text was updated successfully, but these errors were encountered: