Codec negotiation and level IDs #3020
Comments
|
@aboba You have pointed this (or something similar) out before when I didn't think about it. Does offering and answering 156 in the above example if direction=sendrecv make sense to you? (If direction is sendonly or recvonly we would still offer/answer the highest value we support in that direction, so this issue only becomes apparent when direction is sendrecv) |
|
I see that the level-id way of thinking is consistent with our take on codec directionality as per https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-hevc-webrtc/pull/29/files and we should just clarify the same applies here. |
|
@henbos Yes. Note that for HEVC the "media format" doesn't include |
|
What are the implications of "media format" not including level-id? That link says "Implementations SHOULD include this parameter within SDP" but does not mention it in the fmtp sentence? Today in Chromium if I call RTCRtpSender.getCapabilities/RTCRtpReceiver.getCapabilities with I do see the level-id in the codec.sdpFmtpLine values. In your view, is that a bug or a feature? |
henbos
changed the title
|
On the SDP negotiation side, it is my understanding that we know how to deal with level-ids and unit tests are being added in https://webrtc-review.googlesource.com/c/src/+/367322 (C++ layer, no WPTs yet, we can also do WPTs later). However on the JS API side I think it might get confusing if setParameters rejects with values from getCapabilities? |
|
I would expect setParameters only select codecs as you get from getParameters(). What you get from getParameters() is related to the current direction of transceiver. RtpSender.getCapabilities() now only returns the supported codecs when the transceiver is in the sendonly direction. It is not reporting capability for a sendrecv transceiver(unless we have a transceiver.getCapability() API). |
|
This issue had an associated resolution in WebRTC November 19 2024 meeting – 19 November 2024 (Issue #3020: Codec negotiation and level IDs):
|
|
@taste1981 yes you should only be able to pick from what was negotiated, we don't want to change that. The issue here is specifically about the level-id of a codec getting "downgraded" for your codec/payload type that was in fact accepted, see slides. |
If you are capable of level-id=X then you are also capable of level-id=Y where Y<X, assuming mimeType, profile-id, tier-flag and tx-mode is the same. I.e.
Today's filter seems to assume that every unique combination of codec, profile and level-id is included in the list:
But in reality, user agents only list the highest level-id they support. Such as 186, rather than all possible values between 0 and 186 as separate codec values. This means you can offer one level-ID from your getCapabilities but this gets downgraded to a level-ID that is not in your getCapabilities with interesting consequences:
getParameters().codecs) is different from what was preferred (setCodecPreferences) or what was ingetCapabilities.setParameterswith 186 or do I have to change to 180?The text was updated successfully, but these errors were encountered: