-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTCRtpSender.get/setParameters is underspecified #308
Comments
PR #298 is partly taking a stab at this. |
I think we have consensus that RTPSender.setParameters() never causes signalling to happen. Either it succeeds or it fails. |
I think this implies one of three things:
This implies that setParameters does not queue a task, nor can it be asynchronous, which probably means that the most it can do in practice is remember the parameters, but not actually apply them. This is probably ok with me, but I'll need to think it over. |
I think it's 2. A synchronous control surface to a background process I think can be fine, provided the API only exposes previously set settings, or things that don't change often. The lack of a promise then merely means the JS has no access to the delay inherent in changing things in the background, plus the UA has no means of communicating failures beyond input validation errors unrelated to live state. Whether the latter is a problem, I don't know. My only concern would be any |
Option 2 seems really awful to me. How would you increase the max bitrate for example? The only way I could see is to remove the track, renegotiate, and re-add it with the new max bitrate value. Just terrible. |
I believe that if we had a bitrate setting somewhere, you could renegotiate without changing the bitrate value. But if I think that we could consider bitrate control at the browser to be solely the domain of local control. And that negotiation is only to set the hard upper bound. If you take that position, then you would not be able to increase bitrate via negotiation. |
We do have a maxBitrate setting in RTCRtpEncodingParameters, and my understanding is that this is the knob you turn to change the max send bitrate on a given simulcast stream, which must then be sent to the other end in SDP (otherwise, how does the other end know which stream is going to be the higher bandwidth one). |
I really don't know what the simulcast solution looks like here. It could be that the first one is the biggest one. Or that this is signaled out of band. |
My understanding is that:
|
Ok, this is at a pretty fundamental impedance mismatch with the ongoing work over in mmusic; this work relies on explicit indication of maximums of things like send bitrate, resolution, fps, etc. https://mailarchive.ietf.org/arch/msg/mmusic/W90OvjhOh-eGtInYWZz-JEoaJr4 |
Yes. |
Odd then that we've decided to limit these APIs to the negotiated envelope. The WG had that choice as recently as |
When talking about simulcast, keep in mind that SDP interop is going to be a fact of life for a very long time. This is what conferencing servers use, and that's the primary use-case for simulcast. It would be a very good idea to ensure that the work in mmusic is compatible with the model over here in W3C. One way or another, the other end is going to need to be able to figure out which stream is which. If we say that maxBitrate is not signaled, that requires one of two things:
|
So seems decision was setParamters would be async with promise. |
As discussed at TPAC:
|
@fluffy will coordinate on generating a PR for the above. |
Work on this is started on branch asyncSetParamters |
There are a number of questions that occur to me:
The text was updated successfully, but these errors were encountered: