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

Decoder Capabilities #52

Closed
aboba opened this issue Nov 2, 2021 · 3 comments
Closed

Decoder Capabilities #52

aboba opened this issue Nov 2, 2021 · 3 comments

Comments

@aboba
Copy link
Contributor

aboba commented Nov 2, 2021

As noted in w3c/media-capabilities#182, there are decoder implementations which do not support reference scaling.

Reference scaling support is not purely an SVC issue, but a decoder that does not support reference scaling also will not be able to support spatial scalability modes.

So one potential approach would be for such a decoder to return the scalabilityModes that it does support.

Is this sufficient?

@chcunningham
Copy link

For MC, I'm hoping to meet w/ Danil soon to find a path we can all agree on. If getCapabilities() and MC both come to describe scalability, my preference would be that we more or less match in approach.

@aboba aboba changed the title Decoder compliance: Reference Scaling support Decoder Capabilities Nov 11, 2021
@aboba
Copy link
Contributor Author

aboba commented Dec 5, 2021

@chcunningham @alvestrand Proposed resolution is to remove RTCRtpReceiver.getCapabilities(). Instead, the spec will recommend the following:

  1. Use MC to determine referenceScaling for the codec.
  2. If referenceScaling is true, then the decoder can decode any scalabilityMode that the encoder can send.
  3. If referenceScaling is false, then the decoder can decode any scalabilityMode that the encoder can send with the exception of spatial scalability modes (e.g. only temporal modes and S modes, if supported in the codec).

Does this make sense?

aboba added a commit that referenced this issue Dec 5, 2021
@aboba aboba added the PR exists label Dec 6, 2021
@aboba
Copy link
Contributor Author

aboba commented Dec 8, 2021

Closing, based on merger of PR #54

@aboba aboba closed this as completed Dec 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants