Closed alvestrand closed 2 years ago
'TotalNonsense' isn't a valid scalabilityMode for any codec. This is an argument for addTransceiver
throwing an exception. On the other hand, the text for addTransceiver
in WebRTC 1.0 API doesn't specify any validation steps for sendEncodings
. So one could argue that {sendEncodings: 'totalNonsense'} would also not throw an exception.
In the SVC spec https://w3c.github.io/webrtc-svc/#error-handling:
However, an error will result only if the requested scalabilityMode value is invalid for any supported codec.
. I guess this should throw an RTCError
with description hardware-encoder-error
or just an OperationError
. We should probably be more clear about what to do there.
While it doesn't apply for addTransceiver
, we may want to make sure that setParameters
only checks the negotiated codec list or the subset indicated by setCodecPreferences
prior negotiation.
This section should probably be written in imperative language. Something like:
Add to the operation of setParameters step 6:
If any scalabilityMode of any encoding is not supported by any codec in parameters.codecs, reject p with a newly created InvalidModificationError.
Add to the operation of addTransceivers step 8:
If any scalabilityMode is not supported by any codec in RTCRtpSender.getCapabilities(kind).codecs, reject p with a newly created OperationError.
Closed after merger of PR 64.
Consider the following snippet:
What should the value of encoding.scalabilityMode be?
This matters a lot for the case where "supported scalability modes" is not part of the API. (At the moment the Chrome implementation returns 'TotalNonsense')