Allow level-id to be different in codec match

[henbos]

Fixes #3020

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Dec 2, 2024, 9:59 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 [Related URL]([object Object])

Navigation timeout of 29271 ms exceeded

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[henbos]

@aboba Does this wording make sense to you?

[fippo]

if you want to go this route you will also need to take care of RFC6184s level-asymmetry-allowed, no? All of this is reasonably well-defined in IETF specs though (well, not quite for HEVC) already

[henbos]

if you want to go this route you will also need to take care of RFC6184s level-asymmetry-allowed, no?

No this is just about the codec matching algorithm used to sanity check input to setParameters/setCodecPreferences, what is actually negotiated based on this is defined somewhere else.

As for sending the selected codec, the description is kind of vague, RTCRtpEncodingParmaters.codec just says:

Optional value selecting which codec is used for this encoding's RTP stream. If absent, the user agent can chose to use any negotiated codec.

And setParameters just says:

In parallel, configure the media stack to use parameters to transmit sender.[[SenderTrack]].

So it's just "codec used for selecting what to send", we might want to create an issue about clarifying not to send greater than the level-id that was negotiated, but that seems more like an editorial note.

[henbos]

not to send greater than the level-id

We might want to update getParameters().encodings[i].codec to match the level-id that you find in getParamters().codecs though? Separate issue though because that is the same as what happens with setCodecPreferences() today

[henbos]

Remote SDP is testable.

[henbos]

Codec wizard @aboba, can you do another review?

[henbos]

Btw I had said during the meeting that I thought all instances of "codec matching" could ignore level, but upon a second look I realized that we don't need to be that "loose" in most cases. For example if you addTransceiver, the only valid input is from getCapabilities since there is no chance that anything else has been negotiated for that transceiver yet. It might not hurt to be more loose here, but it does not seem to help either. Ultimately we only need to "ignoreLevels=true" at a few places:

• When negotiation completes, the check to see if the codec was negotiated away and for maybe clearing setParameters's codec value, this should not remove the codec because of a level mismatch.
• When setParameters is called, this should not throw due to level mismatch (= "Proposal A").
• In addition I clarified that the "RTCRtpEncodingParameters.codec" picks codec based on "ignoreLevels=true" for the same reason that setParameters is supposed to work here, but this was never called out before.

In all other cases we can "ignoreLevels=false", which the PR reflects now.

[jan-ivar]

If one of the inputs is garbage the old algorithm returned false. Doesn't this risk returning true if the line is not parseable?

[henbos]

More accurately "..., so that ignoring the level requires codec-specific parsing" to reflect level ID in H.264 being something that can be parsed e.g. last byte