-
Notifications
You must be signed in to change notification settings - Fork 143
Capabilities #25
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
Comments
We likely will need a surface to feature detect new encoder/decoder features as well. That doesn't seem like it would be covered by MediaCapabilities. |
Steve, can you give an example? |
@mounirlamouri fyi |
I don't think we've discussed how specific we want encoder/decoder settings yet, but here's some examples I could think of (some of this may be suitable for MediaCapabilities):
Disclaimer: Not a codec expert |
At first glance I don't think we need a different API surface from MediaCapabilities. MediaCapabilities already has feedback on both decode and encode capabilities.
Is this a capability or something that can be measured by observing the behavior of the encoder?
Is this contentType: "video/H264-SVC" or similar values?
MediaCapabilities may need a VideoEncodingConfiguration dictionary to be able to query for specific encoder capabilities.
How is this related to encoding? Can you give specific examples? |
Right. We want to use MediaCapabilities, but we may need things added to it.
I think it's something that can be statically known and which you would like to know before creating the encoder, because there might be a range of delay options you can choose from and you might want to choose within that range.
Yes I think that would make sense.
No, it only applies to decode, not encode. |
Would the next step then to be to craft a PR on what changes we'd like to see to Media Capabilities (as part of the explainer in this repository)? I can take a stab at that. |
Yes, I think that would be a good next step. Thanks for helping. |
Happy to review! You may also/instead want to file a bug with a rough outline of your proposed change. Guess it depends on how fast you are at spec-work (I'm slow) and how large the PR ends up being. Particularly for the big changes, discussion in an GH issue can be a bit easier and save you time re-writing spec-speak. |
We've now added an IsConfigSupported() API for all encoders and decoders. Later integration with MC is not off the table, but not a priority at this time. |
@steveanton WebCodecs doesn't explicitly support simulcast (e.g. multiple encoders need to be created). Question is whether explicit support is required or whether the implementation can optimize after noticing that there are multiple encodings utilizing the same track as input. SVC is supported using |
Triage note: marking 'extension', as proposal here would be to add new dictionary members to the adjacent MediaCapabilities API. This doesn't change my stance mentioned earlier: I think WebCodecs has now solved most of this problem with it's various IsConfigSupported() methods. |
@dalecurtis Can we close this issue? |
I think it is covered by isConfigSupported(). Closing it |
We need an API for capabilities, like what MediaCapabilities has. Is that enough for us? What input do we need to provide to MediaCapabilities?
The text was updated successfully, but these errors were encountered: