You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We start with a MPEG-DASH stream that uses CENC DRM (supporting both Modular Widevine and Microsoft PlayReady). The manifest itself contains ContentProtection values though they are not the primary decryption mechanism. Decryption is handled with a license url (Widevine when tested in Chrome browser on macOS) fed to VideoJS. When played out in this manner, the license is requested and there are no issues with playback.
When this stream is passed to Google DAI to be SSAI backed, it comes back with a multi-period manifest where some periods are Clear (bumpers and ads) and some periods are DRM protected (primary content).
The underlying issue is that VideoJS seems to ignore the license url that has been passed in player setup when it sees that the first period of content is not encrypted and fails to ever call the license url to decrypt content when it gets to a period with content. You can see in the network tab that the license url is never requested. videojs-contrib-eme suggests there is a method that could be called initializemediakeys: https://github.com/videojs/videojs-contrib-eme#initializemediakeys
But using this always results in:
"Unsupported keySystem or supportedConfigurations."
Example urls can only be shared privately due to legal reasons but the VideoJS team should be able to easily replicate this by taking any standard DRM stream (to see successful playback) and then apply SSAI advertising from Google DAI or similar that supports SSAI on MPEG-DASH streams.
I can say that the same streams play fine and we see DRM license url calls in:
Shaka Player
Bitmovin Player
Tizen AVPlay
AVPlayerViewController on iOS/tvOS
ExoPlayer on Android/AndroidTV/FireTV
Roku Player
Very much appreciate the help looking in to this.
The text was updated successfully, but these errors were encountered:
Hi,
This has been reported in this ticket here:
videojs/video.js#7824 (comment)
But have been advised to add this here as well.
videojs-contrib-eme @ 3.11.1
video.js @ 8.5.2
videojs/http-streaming @ 3.5.3
We start with a MPEG-DASH stream that uses CENC DRM (supporting both Modular Widevine and Microsoft PlayReady). The manifest itself contains ContentProtection values though they are not the primary decryption mechanism. Decryption is handled with a license url (Widevine when tested in Chrome browser on macOS) fed to VideoJS. When played out in this manner, the license is requested and there are no issues with playback.
When this stream is passed to Google DAI to be SSAI backed, it comes back with a multi-period manifest where some periods are Clear (bumpers and ads) and some periods are DRM protected (primary content).
The underlying issue is that VideoJS seems to ignore the license url that has been passed in player setup when it sees that the first period of content is not encrypted and fails to ever call the license url to decrypt content when it gets to a period with content. You can see in the network tab that the license url is never requested. videojs-contrib-eme suggests there is a method that could be called initializemediakeys:
https://github.com/videojs/videojs-contrib-eme#initializemediakeys
But using this always results in:
"Unsupported keySystem or supportedConfigurations."
Example urls can only be shared privately due to legal reasons but the VideoJS team should be able to easily replicate this by taking any standard DRM stream (to see successful playback) and then apply SSAI advertising from Google DAI or similar that supports SSAI on MPEG-DASH streams.
I can say that the same streams play fine and we see DRM license url calls in:
Shaka Player
Bitmovin Player
Tizen AVPlay
AVPlayerViewController on iOS/tvOS
ExoPlayer on Android/AndroidTV/FireTV
Roku Player
Very much appreciate the help looking in to this.
The text was updated successfully, but these errors were encountered: