- From: docfaraday via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Oct 2022 22:03:45 +0000
- To: public-webrtc-logs@w3.org
There are a handful of types of race here, on further thought. addTrack, then a race between sRD(simulcast recv offer) and setParameters(unicast) - There are multiple questions here. First we need to decide what addTrack followed by unicast setParameters means. Does it mean that we are definitely not doing simulcast, and we should reject additional encodings in the sRD? Or does it still allow simulcast. a race between sRD(unicast reoffer/answer/reanswer) and setParameters(simulcast) - I think we can agree that we do not want to end up settling on simulcast when this happens. We probably want the same result that we would have gotten if we ran the setParameters to completion, and then the sRD. (Doing the opposite order would result in the setParameters failing; not as clean, but possibly viable. I prefer not to do this.) a race between sRD(rollback of a unicast reoffer) and setParameters(unicast) - We want to end up back in simulcast here, and I guess we want to allow the changes from the setParameters to persist; that encoding will be there either way. a race between sRD(rollback of initial simulcast offer) and setParameters(simulcast) - We definitely want there to be just one encoding when this finishes. Do we want that encoding to have the changes from the setParameters call? I think the simplest way to handle all of these is to mimic what we do when addTrack races against sRD. Let the setParameters finish, and then re-do the sRD(whatever). -- GitHub Notification of comment by docfaraday Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2737#issuecomment-1269028219 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 October 2022 22:03:47 UTC