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

Changing the interpretation if referenceScaling is absent #56

Merged
merged 1 commit into from Feb 1, 2022

Conversation

aboba
Copy link
Contributor

@aboba aboba commented Dec 9, 2021

This PR changes the interpretation when referenceScaling is absent.

Reflects discussion in Issue w3c/media-capabilities#182

@chcunningham PTAL.


Preview | Diff

@chcunningham
Copy link

chcunningham commented Dec 20, 2021

Sorry for the delay. The defaulting language looks right. Ideally most of this language should just appear directly in the MC spec and you should be able to simplify this to something like:

"Appliciations may use referenceScaling in MediaCapablities to detect decoding support for streams having spatial scalability. Decoding of temporal and quality scalability is assumed to always be supported."

I'm think @drkron will send a PR for MC. When we do add it to MC I'll prefer to define the values more in terms of the stream rather than the decoder.

If referenceScaling set to true, this indicates that the video track contains encoded frames that depend on (reference) other frames having a different resolution. This arrangement is typical of streams using spatial scalability. If referenceScaling is set to false or is absent, this indicates that the track does not contain video frame references between resolutions.

I like this^ stream-pov better as that's how MC does most other properties and it allows implementers to say "supported = true" for decoders that actually do support referenceScaling, even if your stream doesn't need it.

I don't want to speak for @drkron when it comes to timeline he might send a PR. I know folks (including myself) are heading OOO for the holidays. If you want to land this as is or massage some of the feedback above into your current text, I don't object. Always happy to iterate async.

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.

None yet

2 participants