search

w3c / webrtc-svc

W3C Scalable Video Coding (SVC) Extension for WebRTC
https://w3c.github.io/webrtc-svc/
Other
39 stars 14 forks source link

Add Behavior section #64

Closed aboba closed 2 years ago

aboba commented 2 years ago

Fixes Issues: https://github.com/w3c/webrtc-svc/issues/57 https://github.com/w3c/webrtc-svc/issues/58 https://github.com/w3c/webrtc-svc/issues/59

Preview available here: https://webrtc.internaut.com/svc/

Preview | Diff

aboba commented 2 years ago

@sergio @orphis @alvestrand @fippo PTAL.

Orphis commented 2 years ago

Most of it looks good to me, but we may have an issue with returning the scalabilityMode of the preferred codec before negotiation as it may change if we call setCodecPreferences() and we could unintentionally change the meaning from "use default value" to "use a specified value".

How can we make sure that the default value is preserved for applications that aren't aware of the SVC specification and yet use setParameters() and setCodecPreferences()? Should we also invalidate the sender.[[LastReturnedParameters]] internal slot after calling setCodecPreferences()?

aboba commented 2 years ago

Yes, after calling setCodecPreferences(), the preferred codec could change, and therefore so would the scalabilityMode values in encodings returned by getParameters().

This seems like it could surprise developers. In WebRTC-PC the setCodecPreferences() text only indicates that it affects createOffer() or createAnswer(). There is no mention of side effects on getParameters().

Maybe a better answer is that if scalabilityMode wasn't supplied in addTransceiver() or setParameters(), getParameters() should not return scalabilityMode values until negotiation is complete.