You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
Instead of saying "media format", say something like "media formats, excluding media configuration parameters that are allowed to be asymmetrical for this codec"
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
The text was updated successfully, but these errors were encountered:
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)
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)
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:
A clarifying NOTE would help here would help for AV1 and H.265 as prime examples
The text was updated successfully, but these errors were encountered: