Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Call generateRequest BEFORE pushing any segment with PlayReady
Another day, another PlayReady-specific issue :/ A partner signalled to us that they weren't able to play a mix of unencrypted and encrypted content on any PlayReady devices. After investigation, it seems that calling `generateRequest` for the first time after clear segments are already present on a MSE `SourceBuffer` associated to the MediaSource linked to the corresponding media element immediately triggered an HTML5 `MEDIA_ERR_DECODE` error. We tried A LOT of work-arounds: - patching clear segments with a `tenc` box with a `0x0` key id to incite the CDM to understand that encrypted contents may be pushed in the future - Rewriting the pssh sent through the EME `generateRequest` API so that it is barebone to limit weird PlayReady edge cases. - Replacing those stream clear segments' with those in our demo page, just to check that the clear segments were not at fault here - Waiting more time between the association of a MediaKeys to the media element and pushing the first segments. None of those actions had an effect. However, what had an effect, was to call the `generateRequest` API BEFORE buffering any segment yet AFTER attaching the MediaKeys (and perhaps MediaSource) to the media element. So this commit does just that, communicating dummy initialization data for a session that will be closed directly after. Note that we already do a fake `generateRequest` on Edge Chromium with Playready since #1434, yet this test was not sufficient, seemingly because it is performed BEFORE MediaKeys attachment. Note that this commit fixes the clear -> encrypted issues our partner were having, but we're unsure yet of if it fixes the encrypted -> clear issues (and I have good reasons to think it does not). So, uh, yeah, PlayReady seems to keep being hard-at-work giving us challenges and head-scratchers.
- Loading branch information