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

Codec dictionary match, ignoring levels, and AV1 #3037

Open
henbos opened this issue Mar 5, 2025 · 3 comments
Open

Codec dictionary match, ignoring levels, and AV1 #3037

henbos opened this issue Mar 5, 2025 · 3 comments

Comments

@henbos
Copy link
Contributor

henbos commented Mar 5, 2025

Our codec match algorithm assumes media formats are the thing that needs to be "==", and highest complying bitstream levels can (sometimes) be ignored because in SDP offer/answer exchange you only need to ensure "<=" levels to ensure interoperability.

I think the mistake here is in the wording, because for AV1, all of the media format properties fall into the "<=" category:
https://aomediacodec.github.io/av1-rtp-spec/#723-usage-with-the-sdp-offeranswer-model

So "media format" and "highest complying bitstream levels", as was the words we choose to write this algorithm, are not actually two distinct categories.

Proposal:

  1. Instead of saying "media format", say something like "media formats, excluding media configuration parameters that are allowed to be asymmetrical for this codec"
  2. Clarify that "highest complying bitstream levels" does not only refer to "level", but any asymmetrical parameter (or whatever word we want to use here).

A clarifying NOTE would help here would help for AV1 and H.265 as prime examples

@henbos
Copy link
Contributor Author

henbos commented Mar 5, 2025

To clarify, I am not trying to reverse any prior decision, I am only trying to update the language to be inclusive of AV1 language (but that this would be a NO-OP for any other codec)

@henbos
Copy link
Contributor Author

henbos commented Mar 5, 2025

For reference, the reason this worked for H.265 is that section 2.1 seem to suggest "media format" and "parameter settings" as separate parameters (if I read it correctly)

@fippo
Copy link
Contributor

fippo commented Mar 5, 2025

"media format" is quite specific. Sadly it is codec-specific. We can agree it is a mess!

Can we define "media format" as a term referring to RFC 3264 and then say "media formats must be compatbile" in step 5 of the codec match algorithm.

(I think step 4 is wrong and not needed because of default parameters)

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

No branches or pull requests

2 participants