Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define MediaCapabilitiesDecodingInfo.codecSwitchingSupported #165

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

chcunningham
Copy link
Contributor

@chcunningham chcunningham commented Feb 22, 2021

Implements the latest proposal from the discussion in #102. This adds a single codecSwitchingSupported boolean to the MediaCapabilitiesDecodingInfo dictionary that indicates whether sourceBuffer.changeType() may be used to switch codecs within the "decoding pipeline" as described by the config passed to mediaCapabilties.decodingInfo().

This PR creates a definition of "decoding pipeline" which distinguishes between clear vs eme playback (and eme playback of differently named key systems). It may occur that a given UA does not really have a separate pipeline for clear vs its platform key system, but this is still allowed by the specification as that difference is not observable.


💥 Error: connect ETIMEDOUT 173.230.149.95:443 💥

PR Preview failed to build. (Last tried on Jan 9, 2024, 11:53 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 CSS Spec Preprocessor - CSS Spec Preprocessor is the web service used to build Bikeshed specs.

🔗 Related URL

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

@chcunningham
Copy link
Contributor Author

@ grabbing some stakeholders (others welcome): @jernoble @xhwang-chromium @joeyparrish @gregwfreedman

Please let me know your thoughts!

@xhwang-chromium
Copy link
Contributor

I don't know how to comment on the diff directly, so I put my comments here.

For

... user agents may support several distinct encrypted media pipelines, which must be signalled by using different keySystem names.

Should it be using different keySystem names or robustness levels? There are key system implementations using the same key system name but with different robustness levels to indicate the robustness level, which determines which distinct encrypted media pipeline to use.

For

If pipeline is able to support dynamic codec switching via SourceBuffer changeType()...

What if the pipeline only supports switching to some codec, but not others? I think we agreed to keep the API stateless for simplicity. In that case, does it make sense to only set codecSwitchingSupported to true if the pipeline supports switching among all the codecs it supports for the same key system and robustness level?

@chcunningham
Copy link
Contributor Author

Thanks for reviewing!

Should it be using different keySystem names or robustness levels? There are key system implementations using the same key system name but with different robustness levels to indicate the robustness level, which determines which distinct encrypted media pipeline to use.

Yes, done!

does it make sense to only set codecSwitchingSupported to true if the pipeline supports switching among all the codecs it supports for the same key system and robustness level?

Yes, thats my intent and I've amended the language to reflect this. The API gets a lot more complicated if we need to describe a subset of codecs where transitions are supported.

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
@chcunningham
Copy link
Contributor Author

@jpiesing - @chrisn suggested you would be interested in this proposal.

index.bs Outdated Show resolved Hide resolved
@chrisn chrisn added this to the V2 milestone Dec 13, 2023
@@ -94,6 +100,8 @@ spec: encrypted-media; for: EME; urlPrefix: https://www.w3.org/TR/encrypted-medi
text: MediaKeysRequirement; url: dom-mediakeysrequirement
text: audioCapabilities; url: dom-mediakeysystemconfiguration-audiocapabilities
text: contentType; url: dom-mediakeysystemmediacapability-contenttype
type: method
Copy link
Member

@marcoscaceres marcoscaceres Jan 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You shouldn't need this in theory. Or if we do, we need to figure out why it hasn't been exported from the other spec.

<p>
A {{MediaCapabilitiesDecodingInfo}} has an associated
<dfn dict-member for='MediaCapabilitiesDecodingInfo'>
codecSwitchingSupported</dfn> which is a boolean.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
codecSwitchingSupported</dfn> which is a boolean.
codecSwitchingSupported</dfn> that is a boolean.

@@ -940,6 +980,23 @@ spec: secure-contexts; urlPrefix: https://www.w3.org/TR/secure-contexts/
efficiency unless the device's power source has side effects
such as enabling different decoding modules.
</li>
<li>
If <code>configuration.type</code> is set to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can type be linked to something?

Copy link
Member

@marcoscaceres marcoscaceres left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we avoid linking to a WICG spec?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants