Re: [webrtc-svc] should scalabilityMode be an array scalabilityModes? (#50)

> True. That is probably worth pointing out in webrtc-pc (and should be asserted with a test)
Agree, this should  be done.

> But you don't need to do this if the UA is granted some flexibility (while allowing enough control)

I am worried that the algorithm to choose the best scalability mode applicable is not deterministic enough or causes unnecessary complexity to the implementations. 

Also, in the SVC case, unlike simulcast, you can dynamically change it. So it the apps is concerned about SVC modes being supported or not after the renegotiationm the app could start without it enabled and set it after the remote description is set. That way it could check what is the codec choose, gather the scalability modes supported for that codec implementation (to differentiate the hw from sw implementation, we might need more work around this) and set a valid one (even getting a promise rejection if the mode is not supported).

> Agree. I also assume that client and server announce and negotiate scalability modes out of band (coming back to the above, why check after sdp negotiation if you can ignore it and set what is appropriate)

Agree, the typical use case would put the correct values and not worry about failure.

> There is a third scenario: if you do replaceTrack and replace camera with screenshare the libwebrtc implementation will behave very different. If the UA is constrained to a single encoding via scalabilityMode should there be an error?

Isn't this an implementation issue of libwebrtc and not a spec one? I mean, number of encodings and scalabilityMode do not change if you do a replace track. 

-- 
GitHub Notification of comment by murillo128
Please view or discuss this issue at https://github.com/w3c/webrtc-svc/issues/50#issuecomment-953599389 using your GitHub account


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

Received on Thursday, 28 October 2021 08:04:56 UTC