Closed decrek closed 4 years ago
Hi @gesinger, I've looked at the test setup and I don't think I fully understand it. So I don't feel that confident in adding some tests. I also can not find any test code related to for example setting the audioCapabilities
and videoCapabilities
that were there already? Maybe one of the maintainers could add the tests, since you guys are probably far more familiar with writing the tests? 😬Would really be appreciated!
Is there any update on this? It is still not possible to set robustness levels.
Is this ready to merge? So we can get rid of the warning on Chrome
Hi,
Actually it would be nice to be able set the whole bunch of properties mentioned above: persistentState, etc. I.e. more or else inline with original proposal - to pass the whole configuration in the same format as 'navigator.requestMediaKeySystemAccess'...
Created PR https://github.com/decrek/videojs-contrib-eme/pull/1 with support for robustness, tests, and supportedConfigurations option. @decrek , let me know if all looks good, or if you'd prefer I create a separate PR on videojs-contrib-eme. Thanks again!
Nice! Thanks @gesinger, will close this. Great to be able to pass all properties!
Hi there, thanks for writing this plugin! Currently it is not possible to pass a robustness level. This leads to warnings in chrome that unexpected behaviour can occur. I do not really care about the warnings but I only want to play streams when hardware decoding is supported. So I made a pull request.
In the native
navigator.requestMediaKeySystemAccess
the second argument is a supportedConfigurations array. In my case it is something like this:I am especially interested wether hardware supported decoding is supported through the robustness property, so I added a
videoRobustness
property to thesystemOptions
. That's it!i do have one more question. How do you feel about just passing the configuration in the same format as with
navigator.requestMediaKeySystemAccess
so the mapping ofvideoContentType
tocontentType
and nowvideoRobustness
torobustness
would not be necessary? Also that would solve all other missing "mappings", which would make the plugin more applicable in a broader range of configurations.Thanks in advance!