Skip to content

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

Closed
pthatcherg opened this issue Sep 18, 2019 · 14 comments
Closed

Capabilities #25

pthatcherg opened this issue Sep 18, 2019 · 14 comments
Labels
editors-agenda Add to agenda for upcoming editors call extension Interface changes that extend without breaking.

Comments

@pthatcherg
Copy link
Contributor

We need an API for capabilities, like what MediaCapabilities has. Is that enough for us? What input do we need to provide to MediaCapabilities?

@steveanton
Copy link
Contributor

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.

@chcunningham
Copy link
Collaborator

new encoder/decoder features

Steve, can you give an example?

@chcunningham
Copy link
Collaborator

@mounirlamouri fyi

@steveanton
Copy link
Contributor

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):

  • How much latency an encoder requires (measured in frames)
  • What kind of SVC/simulcast a video encoder/decoder supports
  • Available encoder keyframe modes (e.g., does it support forcing keyframes)
  • Support for explicitly tagged golden frames (I've heard some hardware decoders don't support this?)
  • Supported encoding modes: VBR vs CBR vs ??
  • Post processing features

Disclaimer: Not a codec expert

@pthatcherg pthatcherg added the hard Hard problem that needs discussion label Sep 18, 2019
@markafoltz
Copy link
Contributor

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.

How much latency an encoder requires (measured in frames)

Is this a capability or something that can be measured by observing the behavior of the encoder?

What kind of SVC/simulcast a video encoder/decoder supports

Is this contentType: "video/H264-SVC" or similar values?

Available encoder keyframe modes (e.g., does it support forcing keyframes)
Support for explicitly tagged golden frames (I've heard some hardware decoders don't support this?)
Supported encoding modes: VBR vs CBR vs ??

MediaCapabilities may need a VideoEncodingConfiguration dictionary to be able to query for specific encoder capabilities.

Post processing features

How is this related to encoding? Can you give specific examples?

@pthatcherg
Copy link
Contributor Author

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.

Right. We want to use MediaCapabilities, but we may need things added to it.

How much latency an encoder requires (measured in frames)

Is this a capability or something that can be measured by observing the behavior of the encoder?

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.

What kind of SVC/simulcast a video encoder/decoder supports

Is this contentType: "video/H264-SVC" or similar values?

Available encoder keyframe modes (e.g., does it support forcing keyframes)
Support for explicitly tagged golden frames (I've heard some hardware decoders don't support this?)
Supported encoding modes: VBR vs CBR vs ??

MediaCapabilities may need a VideoEncodingConfiguration dictionary to be able to query for specific encoder capabilities.

Yes I think that would make sense.

Post processing features

How is this related to encoding? Can you give specific examples?

No, it only applies to decode, not encode.

@markafoltz
Copy link
Contributor

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.

@steveanton
Copy link
Contributor

Yes, I think that would be a good next step. Thanks for helping.

@chcunningham
Copy link
Collaborator

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.

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.

@chcunningham
Copy link
Collaborator

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.

@aboba
Copy link
Collaborator

aboba commented Apr 10, 2021

@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 scalabilityMode values and metadata.

@chcunningham
Copy link
Collaborator

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.

@chcunningham chcunningham added extension Interface changes that extend without breaking. and removed hard Hard problem that needs discussion labels May 12, 2021
@chcunningham chcunningham added agenda Add to Media WG call agenda editors-agenda Add to agenda for upcoming editors call and removed agenda Add to Media WG call agenda labels Jan 18, 2022
@aboba
Copy link
Collaborator

aboba commented Mar 16, 2023

@dalecurtis Can we close this issue?

@Djuffin
Copy link
Contributor

Djuffin commented May 11, 2023

I think it is covered by isConfigSupported(). Closing it

@Djuffin Djuffin closed this as completed May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editors-agenda Add to agenda for upcoming editors call extension Interface changes that extend without breaking.
Projects
None yet
Development

No branches or pull requests

6 participants