Playback failing on device when moving from 4.7.15 to 4.8.0

[MikeKav]

Have you read the Tutorials?
Yes

Have you read the FAQ and checked for duplicate open issues?
Yes

If the question is related to FairPlay, have you read the tutorial?
N/A

What version of Shaka Player are you using?
Last working: 4.7.15
Unworking: 4.8.0 and 4.9.0

What browser and OS are you using?
EE/YouView TV Box Pro Set Top Box (https://www.bt.com/help/tv/learn-about-tv/bt-tv-boxes), Sagemcom hardware running WPE browser version 2.42.5 (slightly higher versions available soon)
YouViewHTML/1.0 AppleWebKit/605.1.15 (Sagemcom; RTIW387; RTIW387.002.X; CDS/0.10.116; API/4.0.0; PS/4.1.144) (+DVR+HTML+IPCMC+UHD+DASH+DRM+MSE)

Please ask your question
We've had a issue that playback on this STB has worked from 4.2.10 until 4.7.15, but we are experiencing failure to see/hear video/audio content with DASH/PlayReady material. Clear DASH has continued to work on both 4.8.0 and 4.9.0.

The same code is playing video and audio on Edge on all three of the above versions.

Console output seems to indicate the functionality is semi-working: There is a lot of output on setup, but then the player gets stuck in a loop repeating the below constantly:
[Debug] (video:8) – "timeNeeded=10" (shaka-player.compiled.debug.js, line 143)
[Debug] (video:8) – "update_:" – "presentationTime=0" – "bufferedAhead=10" (shaka-player.compiled.debug.js, line 143)
[Debug] (video:8) – "buffering goal met" (shaka-player.compiled.debug.js, line 143)
[Debug] (video:8) – "updating in 0.5 seconds" (shaka-player.compiled.debug.js, line 143)
[Debug] (audio:2) – "timeNeeded=10.005333333333333" (shaka-player.compiled.debug.js, line 143)
[Debug] (audio:2) – "update_:" – "presentationTime=0" – "bufferedAhead=10.005333" (shaka-player.compiled.debug.js, line 143)
[Debug] (audio:2) – "buffering goal met" (shaka-player.compiled.debug.js, line 143)
[Debug] (audio:2) – "updating in 0.5 seconds" (shaka-player.compiled.debug.js, line 143)

We do have AppleWebKit in our user agent string, but have not patched in an is[Device] API as used in platform.js as we have until now been able to use configuration switches to set behavior to a working approach.

Up until 4.7.14 the only changes we've needed have been
player.configure('streaming.useNativeHlsOnSafari', false); << This was used originally in 4.2.10 to switch our devices DASH streaming from native engine to MSE/EME
and currently for audio track switching where codecs are different we now need to add:
player.configure('mediaSource.codecSwitchingStrategy', shaka.config.CodecSwitchingStrategy.RELOAD)

We'd appreciate any ideas for areas to look at to find the problem, we've done a comparison of the new fields in config between 4.7.15 and 4.8.0 and tried a few varying settings with no visible change to behaviours

Results from https://shaka-player-demo.appspot.com/support.html:

YouViewHTML/1.0 AppleWebKit/605.1.15 (Sagemcom; RTIW387; RTIW387.002.X; CDS/0.10.116; API/4.0.0; PS/4.1.144) (+DVR+HTML+IPCMC+UHD+DASH+DRM+MSE)
v4.9.5

{
"manifest": {
"application/dash+xml": true,
"video/vnd.mpeg.dash.mpd": true,
"application/x-mpegurl": true,
"application/vnd.apple.mpegurl": true,
"application/vnd.ms-sstr+xml": true,
"application/x-offline-manifest": true
},
"media": {
"video/mp4; codecs="avc1.42E01E"": true,
"video/mp4": true,
"video/mp4; codecs="avc3.42E01E"": true,
"video/mp4; codecs="hev1.1.6.L93.90"": true,
"video/mp4; codecs="hvc1.1.6.L93.90"": true,
"video/mp4; codecs="hev1.2.4.L153.B0"; eotf="smpte2084"": true,
"video/mp4; codecs="hvc1.2.4.L153.B0"; eotf="smpte2084"": true,
"video/mp4; codecs="vp9"": false,
"video/mp4; codecs="vp09.00.10.08"": true,
"video/mp4; codecs="av01.0.01M.08"": false,
"video/mp4; codecs="dvh1.20.01"": false,
"audio/mp4; codecs="mp4a.40.2"": true,
"audio/mp4": true,
"audio/mp4; codecs="ac-3"": true,
"audio/mp4; codecs="ec-3"": true,
"audio/mp4; codecs="ac-4.02.01.01"": false,
"audio/mp4; codecs="opus"": true,
"audio/mp4; codecs="flac"": false,
"audio/mp4; codecs="dtsc"": false,
"audio/mp4; codecs="dtse"": false,
"audio/mp4; codecs="dtsx"": false,
"video/webm; codecs="vp8"": false,
"video/webm": true,
"video/webm; codecs="vp9"": false,
"video/webm; codecs="vp09.00.10.08"": true,
"audio/webm; codecs="vorbis"": false,
"audio/webm": true,
"audio/webm; codecs="opus"": true,
"video/mp2t; codecs="avc1.42E01E"": true,
"video/mp2t": true,
"video/mp2t; codecs="avc3.42E01E"": true,
"video/mp2t; codecs="hvc1.1.6.L93.90"": true,
"video/mp2t; codecs="mp4a.40.2"": true,
"video/mp2t; codecs="ac-3"": true,
"video/mp2t; codecs="ec-3"": true,
"text/vtt": true,
"application/mp4; codecs="wvtt"": true,
"application/mp4": true,
"application/ttml+xml": true,
"application/mp4; codecs="stpp"": true,
"audio/aac": true,
"audio/ac3": true,
"audio/ec3": true,
"audio/mpeg": true
},
"drm": {
"org.w3.clearkey": null,
"com.widevine.alpha": null,
"com.microsoft.playready": {
"persistentState": false,
"encryptionSchemes": [
"cenc",
"cbcs"
],
"videoRobustnessLevels": [
"150",
"2000",
"3000"
],
"audioRobustnessLevels": [
"150",
"2000",
"3000"
]
},
"com.microsoft.playready.recommendation": null,
"com.chromecast.playready": null,
"com.apple.fps.1_0": null,
"com.apple.fps": null
},
"hardwareResolution": {
"width": null,
"height": null
},
"offline": true
}

[avelad]

We do not have that device, I recommend that you look at the recent commit history in DrmEngine (https://github.com/shaka-project/shaka-player/commits/main/lib/media/drm_engine.js) and if you find the commit that fails, we will be able to help you... Sorry!

[MikeKav]

Hi, I tried a few versions!

Using:
#5897 (feat: Add preload system to player)
git checkout -b test-branch-489b11a 489b11a
python3 build/all.py --force
PlayReady Content fails to play

#6189 (feat!: Remove com.adobe.primetime keysystem)
git checkout -b test-branch-47602c6 47602c6
python3 build/all.py --force
PlayReady Content plays

To check I didn't make an error I then:
git checkout test-branch-489b11a
python3 build/all.py --force
PlayReady Content fails to play

The version numbers reported seemed a bit broken, but I assume from this test it's something in the changes in #5897 that is causing the issue for me?

[MikeKav]

I'll also add that I had not yet moved to using the player.attach() method, but now I have, with the same results

[avelad]

The PR is huge, but there is no change that affects the drm.

[MikeKav]

I took a look and it did seem quite big. Would you have any further recommendations for narrowing down the issue or to break down the PR changes to test? It seems to be an issue that has been introduced and into new versions moving forward so preventing us from moving off the 4.7 branch

[avelad]

The change is very big, if you can debug more, and find where the error is, we are happy to fix it :)

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.

[MikeKav]

@shaka-bot reopen

I've not had time to work on this until now, today I've tried the newer versions as released since I first posted.
4.17.15 (/)
4.8.0 (x), 4.8.20 (x)
4.9.0 (x), 4.9.19 (x)
4.10.0 (x), 4.10.7 (x)

[avelad]

@MikeKav We do not have that device, we can leave the issue open, but you will have to debug the error yourself, sorry!

[MikeKav]

Hi @avelad , I do understand (as a matter of interest, do you have a UK based lab?). I've re-opened to provide some further details, hopefully someone might see something I'm doing and be able to help advise.
I have checked some different content types, and can replicate the issue on public available content and keys, which is:
"url": "https://media.axprod.net/TestVectors/v7-MultiDRM-SingleKey/Manifest_1080p.mpd",

                "drm": {
                    "servers": {
                        "com.microsoft.playready":"https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:9eb4050d-e44b-4802-932e-27d75083e266,contentkey:FmY0xnWCPCNaSpRG+tUuTQ==,sl:150)"
                    }
                }, 

[avelad]

@theodab can you help here? Thanks!

[shaka-bot]

@MikeKav Does this answer all your questions? If so, would you please close the issue?

[MikeKav]

Hi, I've looked into the code differences (running uncompiled 4.8.0) and running Edge side by side with my device.

I do see this error:
[Warning] Error installing polyfill! (log.js, line 148)
ReferenceError: Can't find variable: EncryptionSchemePolyfills
install — encryption_scheme.js:26
installAll — all.js:25
(anonymous function) — ui.js:286
scanPageForShakaElements_ — ui.js:284

This is different on Edge:
log.js:148 Error installing polyfill! ReferenceError: EncryptionSchemePolyfills is not defined
at Object.install [as callback] (encryption_scheme.js:26:5)
at shaka.polyfill.installAll (all.js:25:18)
at HTMLDocument.initApp (myapp.js:41:20)

I believe Edge uses native EME, whereas for my device it's probably safe to use the polyfill? (and it is set up this way in media_capabilities.js) so I'm not sure if the error matters as the playback still works on Edge

At this point in the code on my device

const mediaKeys = await mediaKeySystemAccess.createMediaKeys();
mediaKeys has no properties, but on Edge, this seems to be defined and have some functions attached to it:

Does this look like it could be an issue? I think my next step is to see if the working version for my device (4.7.15) has similar code and if that object is correctly defined.

[MikeKav]

On device the code mediaKeySystemAccess.createMediaKeys() appears to be asserting this

// TODO(vaage): Look into the assertion below. If we do not have any drm
// info, we create drm info so that content can play if it has drm info
// later.
// However it is okay if we fail to initialize? If we fail to initialize,
// it means we won't be able to play the later-encrypted content, which is
// not okay.

// If the content did not originally have any drm info, then it doesn't
// matter if we fail to initialize the drm engine, because we won't need it
// anyway.
return hadDrmInfo ? p : p.catch(() => {});

This is a little out of my experience area, but it seem the polyfill is not doing the right thing, I have tried using native mediaCapabilities but that does not work on my device

[MikeKav]

Part of this currently seems to be a red herring, debugging 4.7.14 I can see that
const mediaKeys = await mediaKeySystemAccess.createMediaKeys();
mediaKeys has no properties as per 4.8.0

[MikeKav]

debug log up to just past player.load() looks ok as far as I can tell: debug log from device pretty much matches Edge

[MikeKav]

After further debugging It seems like in 4.8.0 the video element doesn't get beyond loadedmetadata on device. Not sure why this is the case.

I spent some time reviewing: onKeyStatusesChange_ in drm_engine.js as on device the session where simple numbers compared to Edge. However the code looked to be functioning correctly in there

On device: Key status changed for session 2
On Edge: Key status changed for session BzBfqjxFy6Dj1SEQreP9mg==

[Iragne]

Look we had to revert back our PS4 and 5 we are checking it. hope we will find the reason

[Iragne]

not in 4.8.20 but in 4.9.0
still work on the sha:20df1a0a88182c6589d2657f8794fa025650cb5e
between the previous and this one e0eeb5b

[MikeKav]

Hi @Iragne I'm not working on PlayStation myself (not since 2021), but it would be interesting to know of any areas to look that might be similar to the issue here.

I have been on holiday but we have had some time to look a little more, I have not found anything at ShakaPlayer level yet, but looking at device firmware logs we can see that the PlayReady license looks to be requested ok, and we can see what seems to be a correct license with the expected content id being stored and made ready for use in the license store.

The device uses gstreamer under the hood, there is a first-pts callback fired which normally results in an event haveEnoughData which should fire the loadedmetadata JavaScript event during loading. when using 4.7.15 this callback does occur, in 4.8.0 it doesn't. At the low level our assumption at the moment is that this means the video buffer is not being injected into the gstreamer pipeline. We don't know what would cause this difference yet

We do have a couple of hosted links that we could PM someone, however the links are geofiltered to the UK.

Unfortunately it will take a little time to have some gstreamer debugging completed, so I am going to look a little more at the ShakaPlayer differences in the preload system in 4.8.0

[Iragne]

On our side we had to set the stream.cleardecodingcache to false
@MikeKav it completely solved ps4 and ps4 we have also the or associated to the issue but the or should solved PlayStation issue but in fact it created the issue

FYI we had been able to point to the commit that induce our issue #6678

I'm really curious about it, what are the circumstance where the "streaming.clearDecodingCache" should be true or false @tykus160
BTW the issue is maybe not releated to what Mike Kav is facing but error was really similar drm playready crash log quite the same

[Iragne]

@MikeKav let me know if it works

[tykus160]

@Iragne streaming.clearDecodingCache is set to true by default only on PlayStation devices, so probably setting it explicitly to false won't help in the issue @MikeKav is facing (but I encourage experimenting with that).
It's been introduced because reusing of MediaKeySystemAccess objects is problematic on those devices and after several playbacks (i.e. due to bingewatching) they are not able to create MediaKeys object anymore (shaka starts to throw 6002 FAILED_TO_CREATE_CDM error). Clearing decoding cache after every session helped us to solve the issue on PlayStation 5.

[Iragne]

@tykus160 I was going to say the same. but we should maybe open a different bug report for PS5 and PS4.
The streaming.clearDecodingCache is set to true Clearly break the playback on our stream.
ISsue was really similar so we though it was related. We understand the patch but the reality is that it's not working on our stream AWS stream mpv2 dash. we are quite puzzle witht he next steps now happy to talk in private for that

[avelad]

@Iragne any update?

[Iragne]

@avelad we just change the config to use the streaming.clearDecodingCache and it unblock our playback. we will share shortly information about it

[avelad]

@Iragne any update?

[Iragne]

Today we are using streaming.clearDecodingCache to false

[MikeKav]

I've not yet tried the above, but I did notice that streaming.clearDecodingCache was implemented at a later version of player than we have been having issues with.

Stepping through today I did note that mediaKeys looks to be null. Is this ever an expected case?

[Boubalou]

We also set the clearDecodingCache to false on our end as well. This issue we are currently investigating might be of interest to you if you work on PS4 and PS5: #7325

[MikeKav]

I've tried testing this:

var config = [{
    videoCapabilities: [{
      contentType: 'video/mp4; codecs="avc1.640028"'
    }]
  }];

for (let i = 0; i < 30; i++) {
    console.log(i);
  console.log('Requesting PlayReady system access...');
    let mksa = await navigator.requestMediaKeySystemAccess(
        "com.microsoft.playready", config
    );
    console.log(mksa);
    mksa = null;
    await new Promise((resolve) => setTimeout(resolve, 2000));
}

This works for me on Edge, but does not work for me on the device I am using, reporting an error:
SyntaxError: Unexpected identifier 'navigator'. Expected ';' after variable declaration.

However avoiding the await functions this works

var config = [{
    videoCapabilities: [{
      contentType: 'video/mp4; codecs="avc1.640028"'
    }]
  }];

let resolvedCount = 0;  // Counter to track resolved promises

for (let i = 0; i < 240; i++) {
  console.log(i);
  console.log('Requesting PlayReady system access...');
  
  navigator.requestMediaKeySystemAccess('com.microsoft.playready', config)
  .then(mediaKeySystemAccess => {
    console.log(mediaKeySystemAccess);
    mediaKeySystemAccess.createMediaKeys();
    resolvedCount++;  // Increment the count for each successful promise resolution
    console.log('Number of resolved promises: ' + resolvedCount);  // Log the current count
  })
  .catch(error => {
    console.log('Argh! ' + error);
  });
}

[joeyparrish]

await can only be used inside an async function or in some debuggers. If you wrap the first version in an async function, it might work:

async function test() {
  // ... your code here
}
test();

[MikeKav]

Thanks @joeyparrish

That was the issue, this works fine on device:

async function test() {

  var config = [{
    videoCapabilities: [{
      contentType: 'video/mp4; codecs="avc1.640028"'
    }]
  }];

let resolvedCount = 0;  // Counter to track resolved promises

for (let i = 0; i < 240; i++) {
    console.log(i);
  console.log('Requesting PlayReady system access...');
    let mksa = await navigator.requestMediaKeySystemAccess(
        "com.microsoft.playready", config
    );
    console.log(mksa);
    mksa.createMediaKeys();
    resolvedCount++;  // Increment the count for each successful promise resolution
    console.log('Number of resolved promises: ' + resolvedCount);  // Log the current count
    mksa = null;
    await new Promise((resolve) => setTimeout(resolve, 100));
}

}
test();

Seems this part is ok for me

[MikeKav]

Hi @joeyparrish

Do you have any hints on the code areas I could look at to verify that the PlayReady license request has been parsed correctly and passed into media decoding for keyid and contentkey?

[joeyparrish]

lib/media/drm_engine.js is where most DRM code lives. Hope that helps!

[MikeKav]

I've created a sample that demonstrates the issue on my device, if anyone has time to test this on other devices to see if it works it would be appreciated. This works for me on Edge with any version number
Usage

• Unpack to web server, then use via https://yourdomain.com/index-simple.html?version=x.x.x
  simple.zip

Working version 4.7.14, anything after 4.8.0 fails:

[MikeKav]

This simple sample on my device using 4.7.14 results in:
[Log] [Shaka Player] manifest request (myapp-simple.js, line 222)
[Log] [Shaka Player] The video has now been loaded! (myapp-simple.js, line 228)
[Log] [Shaka Player] PR license request (myapp-simple.js, line 218)
[Log] [Shaka Player] loadedmetadata received (myapp-simple.js, line 137)
[Log] [Shaka Player] loadeddata received (myapp-simple.js, line 133)
[Log] [Shaka Player] canplay received, starting playback (myapp-simple.js, line 112)
[Log] [Shaka Player] canplaythrough received (myapp-simple.js, line 117)
[Log] [Shaka Player] play received (myapp-simple.js, line 121)

This simple sample on my device using 4.8.0+ results in:
[Log] [Shaka Player] manifest request (myapp.js, line 325)
[Log] [Shaka Player] The video has now been loaded! (myapp.js, line 332)
[Log] [Shaka Player] PR license request (myapp.js, line 321)
[Log] [Shaka Player] loadedmetadata received (myapp.js, line 166)

The sample originally called play() on receiving canplay, but changing that to loadedmetadata had no effect.

[joeyparrish]

Could you please log JSON.stringify(player.getBufferedInfo())?

[MikeKav]

I will look at that, is there any particular point in the code or execution that would be most useful?