Open XBDRX opened 4 years ago
The spec you linked to is a 5-year-old working draft with a giant warning on it saying it's outdated:
But even in the current spec, I can think of no reason you should ever get empty key statuses. My guess is that this would be a bug in the EME implementation of that smart TV, and I would recommend that you file a bug with the manufacturer.
Does this help?
Correct. That's the version of the EME spec implemented by LG WebOS 4.0 (2018) and WebOS 4.5 (2019) Smart TVs.
http://webostv.developer.lge.com/discover/specifications/supported-media-formats/
I will assume a bug in their implementation and discuss with them. I do notice that Shaka works on those devices so I will test those same streams using Shaka rather than my own EME-based implementation.
I'm implementing EME playback on a range of Smart TVs which support the spec "Encrypted Media Extensions W3C Working Draft 31 March 2015". The TVs have native DASH support so I am not using MSE.
I'm using commonly available test streams which I don't believe are using DASH features unsupported by the TVs:
Working https://demo.unified-streaming.com/video/tears-of-steel/tears-of-steel-dash-playready.ism/.mpd
Not Working https://media.axprod.net/TestVectors/v6.1-MultiDRM/Manifest_1080p.mpd
I've read through https://www.w3.org/TR/2015/WD-encrypted-media-20150331/ several times and it's not clear to me what can cause this to happen or what actions I should take. Can someone please clarify?
ps in case it's relevant, the video source and mimeType are set via a child element rather than directly on the