Re: [webrtc-pc] How should be populated codecs capabilities fmtp lines? (#3024)

If we are clear about what constitutes the "media format" for each codec, and what the defaults are in the absence of fmtp parameters, we can avoid unnecessary negotiation failures.  For example: 

For VP8
- max-fs and max-fr parameters are not part of the "media format", only mimeType
- Browser advertising no parameters should be able to succesfully negotiate with browser including max-fs/max-fr

For H264
- "media format" includes mimeType, profile-level-id (because profile and level-id are combined), packetization-mode, level-asymmetry-allowed
- packetization-mode = 0 assumed if omitted?
- With  level-asymmetry-allowed in Offer & Answer, Offer of level-id A and Answer of level-id B will fail negotiation if B != A even if profile and packetization-mode matches.  This is a design error in RFC 6184, so not clear we can fix it. 

For VP9
- "media format" includes mimeType, profile-id
- profile-id = 0 assumed if omitted?
- Browser advertising no parameters should be able to succesfully negotiate with browser including profile-id=0, max-fs/max-fr

For AV1
- "media format" includes mimeType, profile, tier
- profile=0, tier=0 assumed if omitted
- level-idx=5 assumed if omitted
- level-idx represents max level that can be sent (sendonly), received (receiveonly)
- level-idx represents max level that can be sent/received (sendrecv)
- Offer of level-idx 4 is observed to cause a negotiation failure if Answerer supports level-idx 5


-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3024#issuecomment-2492061065 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 21 November 2024 19:15:02 UTC