How do we handle versioning?

[aboba]

Opened by Stephen Botzko.

As briefly discussed in the 16 May 2024 meeting, Proposed extensions to AV1 [under discussion in FG14] use the spatial/temporal id fields in a new way, which is likely not compatible with SFMs. These extensions might not be in new profiles, which would complicate negotiation.

Options discussed in that meeting included:

• Identifying a specific (e.g. current) version of the AV1 specification in the RTP specification
• Getting new media types as needed from IANA, and restricting the use of current media type.

Requirements to maintain compatibility need to be communicated back to the main working group, as they will require action on their part.

[aboba]

From an AV1 RTP payload perspective, Section 7.2 defines the profile, level-idx and tier parameters. For example, in Chromium an SDP Offer with direction=recvonly includes the following "a=" lines:

a=rtpmap:45 AV1/90000
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=fmtp:45 level-idx=5;profile=0;tier=0
a=rtpmap:46 rtx/90000
a=fmtp:46 apt=45
a=rtpmap:47 AV1/90000
a=rtcp-fb:47 goog-remb
a=rtcp-fb:47 transport-cc
a=rtcp-fb:47 ccm fir
a=rtcp-fb:47 nack
a=rtcp-fb:47 nack pli
a=fmtp:47 level-idx=5;profile=1;tier=0
a=rtpmap:48 rtx/90000
a=fmtp:48 apt=47

The key thing from our perspective is that an SDP Offer indicating willingness to receive these tier/profile/level-idx combinations not be interpreted to allow a sender to provide depth or alpha layers denoted by SID, which an existing browser, MANE or SFU will not be prepared to properly interpret.

This could be achieved by requiring depth/alpha extensions to utilize a new profile. Another alternative might be for the depth/alpha extensions to utilize a new mime-type (e.g. AV1-ARVR).