Skip to content

[EME] Check support for full content type string (including codecs)#1643

Open
asurdej-comcast wants to merge 1 commit intoWebPlatformForEmbedded:wpe-2.46from
asurdej-comcast:eme_suports_type
Open

[EME] Check support for full content type string (including codecs)#1643
asurdej-comcast wants to merge 1 commit intoWebPlatformForEmbedded:wpe-2.46from
asurdej-comcast:eme_suports_type

Conversation

@asurdej-comcast
Copy link

@asurdej-comcast asurdej-comcast commented Mar 20, 2026

When evaluating media capability support in EME::requestMediaKeySystemAccess(), MediaPlayer::supportsType() was called with only the container MIME type (e.g. 'video/mp4'), stripping codecs and other parameters.

Pass the full content type string (e.g. 'video/mp4; codecs="avc1.42E01E"') so the media engine can properly validate codec support, not just the container.
391b3c3

Build-Tests Layout-Tests
✅ 🛠 wpe-246-amd64-build ✅ 🧪 wpe-246-amd64-layout
✅ 🛠 wpe-246-arm32-build ✅ 🧪 wpe-246-arm32-layout

When evaluating media capability support in EME::requestMediaKeySystemAccess(),
MediaPlayer::supportsType() was called with only the container MIME type
(e.g. 'video/mp4'), stripping codecs and other parameters.

Pass the full content type string (e.g. 'video/mp4; codecs="avc1.42E01E"')
so the media engine can properly validate codec support, not just the container.
@asurdej-comcast
Copy link
Author

We received a test app from Dolby that queries support for dolby types from different JS APIs (isTypeSupported, MediaCapabilites, EME). With current implementation, EME will check only the mime type of original content type string. This ignores all parameters, including codecs.
According to spec comment

        // 3.13. If the user agent and implementation definitely support playback of encrypted media data for the
        //       combination of container, media types, robustness and local accumulated configuration in combination
        //       with restrictions:

"media types" here refers directly to codecs:

        // 3.9. Let media types be the set of codecs and codec constraints specified by parameters. The case-sensitivity
        //      of string comparisons is determined by the appropriate RFC or other specification.

In that sense it's reasonable to check full content type string instead of mime type only.

Checking the history of that impl shows that "codecs" was part of inital impl in 79099b3 (but was ignored by MediaPlayer at that time).
Then it was merged with mimeType into ContentType param in f73bc7e
and dropped eventually with e001f66

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

2 participants