Clarify requirement of handling symmetric/asymmetric levels of HEVC offer/answer

[taste1981]

Unlike AVC, in RFC 7798 we don't explicitly signal level-asymmetric-allowed in the SDP.

A few things that should be clarified for sendonly/sendrecv/recvonly cases in the O/A flow for HEVC

• level-asymmetric-allowed should be implicitly always true for HEVC;
• With a fixed profile/tier, if the offerer is able to decode/encode up to level 5.2, and the answerer is able to decode/encode up to level 3.1, what level/levels should answer include for sendonly/sendrecv/recvonly?
• With a fixed profile/tier, if the offerer is able to decode/encode up to level 3.1, and the answerer is able to decode/encode up to level 5.2, what level/levels should answer include for sendonly/sendrecv/recvonly?
  • With a fixed profile/tier, if the offerer is able to encode up to level 3.1, but decode up to level 5.2, what level/levels should offer include for sendonly/sendrecv/recvonly?
  • With a fixed profile, if the offerer is able to encode up to level 5.2, but decode up to level 3.1, what level/levels should the offer include for sendonly/sendrecv/recvonly?

There might be more combinations. So a rule should be specified for SDP offer/answer generation.

[aboba]

RFC 7798 Section 7.2.2 allows level-id asymmetry:

“The parameters identifying a media format configuration for HEVC are profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, and tx-mode. These media configuration parameters, except level-id, MUST be used symmetrically when the answerer does not include recv-sub-layer-id in the answer for the media format (payload type) or the included recv-sub-layer-id is equal to sprop-sub-layer-id in the offer.”

However, it also says:

“The Answerer MUST: 1) maintain all configuration parameters with the values remaining the same as in the offer for the media format (payload type), with the exception that the value of level-id is changeable as long as the highest level indicated by the answer is not higher than that indicated by the offer;”

@fippo What do you think?

[taste1981]

What about this case:

With a fixed profile/tier, if the offerer is able to decode/encode up to level 3.1, and the answerer is able to decode/encode up to level 5.2, what level/levels should answer include for sendonly/sendrecv/recvonly?

sendrecv Offer

Offer: 3.1 Answer: 3.1?

sendonly Offer

Offer: 3.1 Answer: 3.1?

recvonly Offer

Offer: 3.1 Answer: 3.1?

[aboba]

The meaning of the Offer and Answer changes based on direction. Here is my take:

sendrecv Offer

Offer: 3.1 (maximum it can encode and decode) Answer: 3.1 (constrained by the Offer)

Result: Offerer would send 3.1 to the the Answerer, Answerer will send 3.1 to the Offerer.

sendonly Offer

Offer: 3.1 (maximum it can encode) Answer: 3.1 (constrained by the Offer)

Result: Offerer would send 3.1 to the the Answerer.

recvonly Offer

Offer: 3.1 (maximum it can decode) Answer: 3.1 (constrained by the Offer)

Result: Answerer would send 3.1 to the the Offerer.

[fippo]

are we interpreting SDP correctly? The "sCP take" is what I put in my SDP is what I would prefer to receive (which makes me wonder if some of the current behavior for VP9 profiles is correct... h/t @alvestrand)

sendrecv

Offer: 3.1 (maximum it can decode) Answer: 5.2 (maximum it can decode) Result: Offerer would send 5.2 to the the Answerer if it can encode that, Answerer wil send 3.1 to the Offerer because that is the maximum that the Offerer can decode.

sendonly

Offer: 3.1 (maximum it can decode) Answer: 5.2 (maximum it can decode) Result: Offerer would send up to 5.2

recvonly

Offer: 3.1 (maximum it can decode) Answer: 5.2 (maximum it can decode) Result: Answerer would send 3.1 to the the Offerer

[aboba]

@fippo RFC 7798 Table 1 seems to indicate that level-id reflects what can be sent (not received) on a sendonly m-line.

[fippo]

And that is backed by RFC 3264 section 5.1 so we can not have nice things :-(

[aboba]

At TPAC 2024, the W3C WEBRTC WG decided on "Proposal A" which is aligned with RFC 3264 Section 5.1.

Related: https://github.com/w3c/webrtc-pc/issues/3006

[taste1981]

Looks like the proposal does not conform to RFC 7798(https://datatracker.ietf.org/doc/html/rfc7798#section-7.2.2, sub-clause #1):

  The answerer MUST:

  1) maintain all configuration parameters with the values remaining
     the same as in the offer for the media format (payload type),
     with the exception that the value of level-id is changeable as
     long as the highest level indicated by the answer is not higher
     than that indicated by the offer;

With this requirement, the answer must ensure level-id is no larger than that in offer.

[aboba]

@sprangerik @djuffin @JonathanLennox PTAL

[alvestrand]

Is this a bug in RFC 7798 (that it doesn't support answerer indicating that it supports more than the offerer does)?

[aboba]

@alvestrand We will explore this at IETF 121. Some of the text does look wrong (e.g. level-id should not be part of the "media format").

[aboba]

Resolution: Discussion at IETF 121 indicates that the text in Section 7.2.2 relating to the Answer level-id not being larger than the Offer is not an error.