[GST] Dynamic insertion of decryptor element #1490
Conversation
Create and insert a GST decryptor element on the fly once encrypted CAPS arrives
|
Here are test cases. First one start with clear playback, the second one with encrypted |
|
I had the same use-case in another project, I solved it by adding a new decryptor, a bin that would contain the real decryptor and a decodebin... That bin had a higher rank, so was auto-plugged. In there I had a pad probe, a bit similar to what you did, to know if I should plug decodebin or not (iirc). I don't think modifying the MSE code is a good solution. |
|
Could you please share more details on that? Considering playbin3, I think the only element that is autoplugging a pipeline is a parsebin and it should be possible to provide a high ranked bin element that will accept all caps - we need to always have it, even for clear caps. And do the dynamic decryptor insertion there. I'm not entirely sure if parsebin will autoplug such element really, will need to double check Whatever the final solution will be, the other question is, if this is something to be included in downstream repo or we should go with custom impl? |
|
Well with the current architecture something is already auto-plugging decryptors, either decodebin3 or parsebin, based on their rank. So if you have a bin acting as decryptor but also doing parsing, with a higher rank than the actual real decryptor, then it will be autoplugged. I can try to salvage that previous work if you want. And yes, it could be maintained in WebKit upstream. |
|
@philn Thanks,
That would be great if you still have it somewhere. Additionally, some media formats, create an extra parser inside AppendPipeline (createOptionalParserForFormat()) (eg h264). This prevents switching switching to encrypted caps as those are not supported by the parser. Currently we have that parser disabled but it would be better to try recreating it on caps change. however, that can probably be handled separately |
Yes, that can be handled separately in the AppendPipeline, probably by reacting on caps events from the appsrc, not sure... |
|
I think this patch might fix some of the issues reported here, can you check WebKit/WebKit#45912? |
|
Thank you @philn The AppendPipeline change to remove parser element when stream becomes encrypted only works for streams with DRM init data present in the content file. We have some tests with pssh/init data injected from JavaScript and not part of the init segment that doesn't trigger protection/encrypted events. |
|
If you can make a standalone test and have it fail, I can check it and it might be worth upstreaming as well. Also noteworthy for backporting, WebKit/WebKit@990c523 would be needed downstream too. |
|
Here is a test page: With current AppendPipeline version it reports an error and playback stops at 8sec so the moment of clear -> encrypted transition. Parser element is still present, not accepting encrypted caps |
|
Is it supposed to work in Chrome? Here the test fails after ~7 seconds, but I'm not sure if I have widevine... Would it be possible to adapt the test to use ClearKey instead of Widevine? |
|
It works for me with Chromium browser but fails at the same place. Both cases work well with Firefox. Looks like chrome has clear to encrypted transition not working/supported Automatic video playback is blocked so need to call video.play() from web inspector or click the "Play" button I added. |
|
It would be easier for me if the test relies on ClearKey and we could upstream that as well 🙏🏻 |
|
Ok then, I will make tc with clear key |
|
Here is an example with clearkey: https://asurdej-comcast.github.io/tr/tests/DELIA-65629_mse_eme_clear_encrypted_transition.html?start=clear&codec=h264&drm=clearkey EME setup looks good, no DRM related errors. Starting with encrypted also plays fine so there is a problem with initial clear->encrypted transition |
|
Playback doesn't even start here |
|
I had to revert 295500@main because it broke auto-plugging of 3rd-party decryptors, I'll work on a new version. |
|
Regarding playback failure with x86, try disabling audio by adding "audio=0" url param: That way I'm able to start clear video at least with x86 PC build |
|
Your initial idea is actually better than mine I think... Wrapping the decryptor in a new bin with parsebin seemed cool but it's also quite risky :( Draft PR opened, WebKit/WebKit#47230 (without svppay handling) |
Could you please provide more details? What kind of issues are you encountering? Otherwise, it seemed like a much cleaner solution to me |
|
I'm giving the magic parser another chance... |
|
The PR landed, hopefully all cases are covered now, can you give it a try? |
We have a use-case in one of our web apps where MSE encrypted playback is mixed with a clear one in single SourceBuffer. This is because of add-insertion where clear add is appended to the same SourceBuffer during encrypted video playback. As a result there is CAPS change in GST pipeline between encrypted and clear ones.
There are two main cases:
We have a change to handle that, created when playback pipeline was using appsource element instead of webkit media src (2.22 or earlier) where the decrypter is inserted dynamically into the playback pipeline based on caps from source element.
It's not the perfect solution but good enough to start discussion on how we can handle that, and if that's the valid use-case at all.
There are two parts there:
Please let me know what you think on that?
202bd4e