HDCP error not returned on Low Latency channel in non-HDCP compliant monitor

[rajeevgupta39-hub]

FAQ

• I have read the FAQ and checked for duplicate open issues

If the problem is related to FairPlay, have you read the tutorial?

Not applicable

What version of Shaka Player are you using?

4.14.9

Can you reproduce the issue with our latest release version?

Yes

Can you reproduce the issue with the latest code from main?

Not tested

Are you using the demo app or your own custom app?

Both

What browser and OS are you using?

Chrome

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

N/A

What are the manifest and license server URIs?

CH 5 -
"licenseURL": "https://udrmv3.kaltura.com/cenc/widevine/license?custom_data=eyJjYV9zeXN0ZW0iOiJodHRwczovL3Jlc3QtYXMub3R0LmthbHR1cmEuY29tL2FwaV92My9zZXJ2aWNlL2Fzc2V0RmlsZS9hY3Rpb24vZ2V0Q29udGV4dD9rcz1kako4TVRRM2ZJQ2VHWWowdFA5NFBkTnR0ZnRMeXNfLU0wM2VVU0twUHhuU3AzU1V2Smp5c2xwd2J1eHAwY0c2WDdUTDFETGRnMUVZUlItcmExbG5CS3RET19MU1N0SElUcko1UENPRkVuUXNjZXJMeFdOaW1QVUo0aFJvLXdhRnNfaUVMS1ZlUTBNX2Y0YV9BYUZVY1BOUVFPc0RURDAzbEtMdHREbDlpbHV4YUNTckFtMmNqMlpGb2ZCbnNXdS0yZkJKd2QxSzQ5SEhCY0JQMDZaMldVRGxEUHdIaElPa2dTUEdNZGo2UEVkT1R2VmV5NWY5MEhFVkdlMFRNWjg5S3dpbEpRdFR4b0trVWdsVUFCdi1ra1llZF9SN3ZQbjhWWWVJUlo0aW9mSzRYWFQ5SUdPZ0daTlRpWE90ZU1Fa0dsTl9FSm5QSmNnQldHRDZWRFpTS3ZfVVVab0VXaU9YU0NNTi0wWDh3a2Zfa0Y4WTI3X3Z1blNWQ3N5VEVRdFAtMVNnaTRaNzBuZ0VHQTVtRC1BcG4wa1JDbVl2X0sxMVNQQk5xQmo0RjlocE4wMDFveHZTUDZNbzRPajVTZlkyTGZrOWdqQThTUmJXNUtOVElZMkxVUUxyNnpfVGI2Z09hRUNqVlJRTzJWd3FwYzM5R09oTXRGTzJJX0d1VF8xNmdLeWoyb21OeFhHd3BEaVllNHpjek90Z21xSEJfcWhhSm5KazJmNWtfZEE3NWhtQlBjSUNVWUdKRHNvNDZNREVscEYxOS05Zy1RPT0mY29udGV4dFR5cGU9bm9uZSZpZD0xMDkzODE1MCIsImFjY291bnRfaWQiOjIwODIzMTEsImNvbnRlbnRfaWQiOiJsbF9mdGFfY2g1X2NtYWZfZGFzaDA2IiwiZmlsZXMiOiIiLCJ1c2VyX3Rva2VuIjoiZGpKOE1UUTNmSUNlR1lqMHRQOTRQZE50dGZ0THlzXy1NMDNlVVNLcFB4blNwM1NVdkpqeXNscHdidXhwMGNHNlg3VEwxRExkZzFFWVJSLXJhMWxuQkt0RE9fTFNTdEhJVHJKNVBDT0ZFblFzY2VyTHhXTmltUFVKNGhSby13YUZzX2lFTEtWZVEwTV9mNGFfQWFGVWNQTlFRT3NEVEQwM2xLTHR0RGw5aWx1eGFDU3JBbTJjajJaRm9mQm5zV3UtMmZCSndkMUs0OUhIQmNCUDA2WjJXVURsRFB3SGhJT2tnU1BHTWRqNlBFZE9UdlZleTVmOTBIRVZHZTBUTVo4OUt3aWxKUXRUeG9La1VnbFVBQnYta2tZZWRfUjd2UG44VlllSVJaNGlvZks0WFhUOUlHT2dHWk5UaVhPdGVNRWtHbE5fRUpuUEpjZ0JXR0Q2VkRaU0t2X1VVWm9FV2lPWFNDTU4tMFg4d2tmX2tGOFkyN192dW5TVkNzeVRFUXRQLTFTZ2k0WjcwbmdFR0E1bUQtQXBuMGtSQ21Zdl9LMTFTUEJOcUJqNEY5aHBOMDAxb3h2U1A2TW80T2o1U2ZZMkxmazlnakE4U1JiVzVLTlRJWTJMVVFMcjZ6X1RiNmdPYUVDalZSUU8yVndxcGMzOUdPaE10Rk8ySV9HdVRfMTZnS3lqMm9tTnhYR3dwRGlZZTR6Y3pPdGdtcUhCX3FoYUpuSmsyZjVrX2RBNzVobUJQY0lDVVlHSkRzbzQ2TURFbHBGMTktOWctUT09IiwidWRpZCI6ImNmMWU5ZDAxLWI0OWQtNGUxMC04ZDQzLWRmYjIyMmE3NzBhNyIsImFkZGl0aW9uYWxfY2FzX3N5c3RlbSI6MTQ3fQ%3d%3d&signature=hdILQWddG2Pm1Qk%2fxJ%2f%2fJkP1O9Q%3d&sessionId=9f5ca5c1-6552-5a86-d801-516bdc2dbd1c:b5b001cd-80ef-fd52-22c5-4dbc41f0fd1f&clientTag=html5:v3.17.72&referrer=aHR0cHM6Ly93d3cubWV3YXRjaC5zZy9jaGFubmVscy9jaGFubmVsLTUvOTcwOTg=",

CH 8 -
"licenseURL": "https://udrmv3.kaltura.com/cenc/widevine/license?custom_data=eyJjYV9zeXN0ZW0iOiJodHRwczovL3Jlc3QtYXMub3R0LmthbHR1cmEuY29tL2FwaV92My9zZXJ2aWNlL2Fzc2V0RmlsZS9hY3Rpb24vZ2V0Q29udGV4dD9rcz1kako4TVRRM2ZJQ2VHWWowdFA5NFBkTnR0ZnRMeXNfLU0wM2VVU0twUHhuU3AzU1V2Smp5c2xwd2J1eHAwY0c2WDdUTDFETGRnMUVZUlItcmExbG5CS3RET19MU1N0SElUcko1UENPRkVuUXNjZXJMeFdOaW1QVUo0aFJvLXdhRnNfaUVMS1ZlUTBNX2Y0YV9BYUZVY1BOUVFPc0RURDAzbEtMdHREbDlpbHV4YUNTckFtMmNqMlpGb2ZCbnNXdS0yZkJKd2QxSzQ5SEhCY0JQMDZaMldVRGxEUHdIaElPa2dTUEdNZGo2UEVkT1R2VmV5NWY5MEhFVkdlMFRNWjg5S3dpbEpRdFR4b0trVWdsVUFCdi1ra1llZF9SN3ZQbjhWWWVJUlo0aW9mSzRYWFQ5SUdPZ0daTlRpWE90ZU1Fa0dsTl9FSm5QSmNnQldHRDZWRFpTS3ZfVVVab0VXaU9YU0NNTi0wWDh3a2Zfa0Y4WTI3X3Z1blNWQ3N5VEVRdFAtMVNnaTRaNzBuZ0VHQTVtRC1BcG4wa1JDbVl2X0sxMVNQQk5xQmo0RjlocE4wMDFveHZTUDZNbzRPajVTZlkyTGZrOWdqQThTUmJXNUtOVElZMkxVUUxyNnpfVGI2Z09hRUNqVlJRTzJWd3FwYzM5R09oTXRGTzJJX0d1VF8xNmdLeWoyb21OeFhHd3BEaVllNHpjek90Z21xSEJfcWhhSm5KazJmNWtfZEE3NWhtQlBjSUNVWUdKRHNvNDZNREVscEYxOS05Zy1RPT0mY29udGV4dFR5cGU9bm9uZSZpZD0yMTIxMjkxOSIsImFjY291bnRfaWQiOjIwODIzMTEsImNvbnRlbnRfaWQiOiJmdGFfY2g4X3YyX2Q0YzU2ZDE2X2Rhc2hfc3NhaSIsImZpbGVzIjoiIiwidXNlcl90b2tlbiI6ImRqSjhNVFEzZklDZUdZajB0UDk0UGROdHRmdEx5c18tTTAzZVVTS3BQeG5TcDNTVXZKanlzbHB3YnV4cDBjRzZYN1RMMURMZGcxRVlSUi1yYTFsbkJLdERPX0xTU3RISVRySjVQQ09GRW5Rc2Nlckx4V05pbVBVSjRoUm8td2FGc19pRUxLVmVRME1fZjRhX0FhRlVjUE5RUU9zRFREMDNsS0x0dERsOWlsdXhhQ1NyQW0yY2oyWkZvZkJuc1d1LTJmQkp3ZDFLNDlISEJjQlAwNloyV1VEbERQd0hoSU9rZ1NQR01kajZQRWRPVHZWZXk1ZjkwSEVWR2UwVE1aODlLd2lsSlF0VHhvS2tVZ2xVQUJ2LWtrWWVkX1I3dlBuOFZZZUlSWjRpb2ZLNFhYVDlJR09nR1pOVGlYT3RlTUVrR2xOX0VKblBKY2dCV0dENlZEWlNLdl9VVVpvRVdpT1hTQ01OLTBYOHdrZl9rRjhZMjdfdnVuU1ZDc3lURVF0UC0xU2dpNFo3MG5nRUdBNW1ELUFwbjBrUkNtWXZfSzExU1BCTnFCajRGOWhwTjAwMW94dlNQNk1vNE9qNVNmWTJMZms5Z2pBOFNSYlc1S05USVkyTFVRTHI2el9UYjZnT2FFQ2pWUlFPMlZ3cXBjMzlHT2hNdEZPMklfR3VUXzE2Z0t5ajJvbU54WEd3cERpWWU0emN6T3RnbXFIQl9xaGFKbkprMmY1a19kQTc1aG1CUGNJQ1VZR0pEc280Nk1ERWxwRjE5LTlnLVE9PSIsInVkaWQiOiJjZjFlOWQwMS1iNDlkLTRlMTAtOGQ0My1kZmIyMjJhNzcwYTciLCJhZGRpdGlvbmFsX2Nhc19zeXN0ZW0iOjE0N30%3d&signature=urJaJ1%2fciO6jY9esT%2brPq0T1ZG4%3d&sessionId=41a577b9-124f-5a99-285e-56e50e9a47db:44af7076-500a-c163-f44d-0c2593accf21&clientTag=html5:v3.17.72&referrer=aHR0cHM6Ly93d3cubWV3YXRjaC5zZy9jaGFubmVscy9jaGFubmVsLTgvOTcxMDQ=",

What configuration are you using? What is the output of player.getNonDefaultConfiguration()?

N/A

What did you do?

1. Plug into external monitor which is non-HDCP compliant

2. Play Channel 8 (Standard DASH) on Production (HDCP error returned as expected)

3. Play Channel 5 (Low Latency CMAF) on Production (HDCP error not returned)

What did you expect to happen?

Low Latency CMAF channel i.e. Channel 5 should throw HDCP error in non-HDCP compliant monitor as same as Channel 8.

After reviewing we found no special handling for channels encrypted with the SPEKEv2 standard.

Our investigation confirms that the HDCP restriction is correctly applied by the Widevine CDM on Channel 5. Widevine reports the content key as output-restricted, and Chrome indicates that the key is no longer usable for further decryption.

Channel 5 uses an AWS MediaPackage v2 low-latency DASH stream.
Unlike Channel 8, which uses AWS MediaPackage v1, the Shaka player does not convert the Channel 5 restricted key status into the expected fatal error 4012 (RESTRICTIONS_CANNOT_BE_MET) and does not immediately stop or unload playback.
Instead, the low-latency session remains active and continues its seek/recovery behavior without presenting the HDCP restriction message.

for further investigation into the handling of output-restrictedkey-status events with AWS MediaPackage v2 low-latency dynamic DASH streams, including the mapping of the restricted KID to the active representations and the expected player response when the Widevine CDM marks the key as restricted.

Attaching all the relevant traces and logs attached.

CH8_media-internals.txt
CD8_2_media-internals.txt
CH8_3_media-internals.txt
CH8_1_EMELogFile.txt
CH5_2_EMELogFile.txt
CH5_2_media-internals.txt
CH5_3_media-internals.txt
CH5_4_media-internals.txt

What actually happened?

Low Latency CMAF channel i.e. Channel 5 plays in non-HDCP compliant monitor without any issues.
Should block playback and throwing HDCP error.

Are you planning to send a PR to add it?

No

[hannadevtools]

I compared the two attached HARs, the EME traces, and the media-internals snapshots. This looks narrower than a license-server/network failure:

• Both HARs contain the same four relevant exchanges: two successful getlicenseurl calls and two successful Widevine license calls. All four return HTTP 200; there is no failed network request to distinguish CH8 from CH5.
• Both EME traces show the CDM reporting the active KID as output-restricted.
• In CH8, the session is then closed by the application about one second later and its status map is cleared.
• In CH5, no matching close appears in the trace. The later media-internals snapshots instead report that both the decrypting demuxer stream and video decoder have no usable key and are waiting for one.

The most useful next check is v5.2.4 or current main, not another HAR. The issue is running v4.14.9, whose Player.onKeyStatus_() takes the drmInfo.keyIds path for any manifest with DRM info. Current v5.2.4 limits that special path to HLS; DASH is evaluated against stream.keyIds. That is directly relevant if this LL-DASH representation's active KID is present on the stream but absent/different in the selected DRM-info set.

If it still reproduces on v5.2.4/main, I would log these four values at onKeyStatus_() without publishing the raw KIDs: (1) whether the status-map KID equals an active stream.keyIds entry, (2) whether it equals an active Widevine drmInfo.keyIds entry, (3) current variant ID, and (4) allowedByKeySystem before/after the event. My working hypothesis is that CH5's output-restricted status is real, but it never gets associated with the active LL-DASH variant, so checkRestrictedVariants() is not reached with all variants disallowed and 4012 is never emitted.

A focused regression test would use a dynamic low-latency DASH manifest, emit output-restricted for the active representation's KID, and assert one RESTRICTIONS_CANNOT_BE_MET (4012) plus allowedByKeySystem === false for the current variant.

One security note: the raw HARs and issue text appear to contain live-looking license parameters/cookies. I would rotate/remove those attachments after the maintainers have what they need. I ran the HAR side through ReqRescue; it correctly reported “no explicit network failure” and flagged 22 sensitive locations in each file. This case is also a good example of HAR's boundary: EME key-status events only exist in the EME/player logs, not in HAR.

[rajeevgupta39-hub]

Hello @hannadevtools
I tested with the latest Kaltura player, which uses shaka-player: 4.14.9 (released Q2 2025), and with the Shaka demo using shaka-player: v5.2.8-uncompiled (recent release).
The behavior is the same: Chrome EME emits an output-restricted event, but the player did not handle it as described earlier in this ticket.