Re: Issue 439: RtpSender.send() should just allow a single codec

Currently, both the WebRTC 1.0 API object model and ORTC allow an RtpSender to specify more than one codec, with the primary codec being the one used to send.

In WebRTC 1.0, this enables the list of codecs to be reordered so as to enable a change of sending codec, without having to initiate an O/A exchange:

// After every call to
// setLocalDescription and
// setRemoteDescription:
var p = sender.getParameters();
p.codecs = reorderCodecs(p.codecs);
sender.setParameters(p);

In ORTC, the equivalent functionality is provided:

var sender = new RTCRtpSender(...);
// Only once, but choose the PTs
var codecs = reorderCodecs(
  sender.getCapabilities().codecs);
sender.send({codecs: codecs, ...});

Currently, the ORTC spec is not clear enough about the importance of codec ordering in sender.send() (e.g. primary codec is the one used to send).   Some examples may help.

Also, with respect to using different codecs for each encoding, it appears that the specification could use some clarification.

There are two potential use cases that come to mind:


1.        Using one codec for a base layer encoding (e.g. H.264/AVC) and another one for extension layers (e.g. H.264/SVC).

2.       Simulcasting streams using different codecs (e.g. one simulcast stream using VP9, another one using VP8).

Use case 1 is specific to H.264.   This is not something that Edge currently supports (e.g. the H.264/SVC implementation does utilize an H.264/AVC compliant base layer, but only "H.264UC" needs to be configured to enable that).

There is an example in the RID draft (see Section 11.1 of https://tools.ietf.org/html/draft-ietf-mmusic-rid) that appears to support both use cases 1 and 2:


"In this scenario, the offerer supports the Opus, G.722, G.711 and
   DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC
   (SCBP/SCHP) and H.265 (MP/M10P) for video.  An 8-way video call (to a
   mixer) is supported (send 1 and receive 7 video streams) by offering
   7 video media sections (1 sendrecv at max resolution and 6 recvonly
   at smaller resolutions), all bundled on the same port, using 3
   different resolutions.
"

The example demonstrates negotiation between the VP8, VP9, H.264/AVC and H.264/SVC (!!) codecs.  However, I am not sure to what extent browsers actually plan to support this.


Inaki filed the following Issue:
https://github.com/openpeer/ortc/issues/439

Let's begin from how things are done in SDP O/A land:

  *   Alice sends an offer to Bob indicating her capabilities (which codecs are supported, etc).
  *   Bob replies an answer indicating his capabilities and selecting the exact codecs and features Alice is allowed to send.
  *   Such a "capabilities negotiation" implicitly defines which codecs will be used in both directions (although any negotiated codec can be used at any time).
To summarize, SDP O/A provides codec capabilities negotiation + implicit codec selection.
In the other side, ORTC does not define a specific negotiation mechanism. Both parties are supposed to exchange their capabilities somehow. Let's assume such a exchange is done. After that:

  *   Alice is allowed to create a video RtpSender and call send() by passing both VP8 and VP9 codecs into the RtpParameters. Even more: she can specify different SSRC streams for both codecs. Even worse: that means that two separate video streams could be sent (which makes no sense unless this is SVC and so on).
  *   Q: Why? If capabilities are already exchanged Alice should decide a single video codec and should instruct her RtpSender to encode using such a codec.
  *   Again: Alice can call send() with both VP8 and VP9.
  *   Q: What does it mean? which codec will the browser choose to encode the video?
A rationale for these questions may be the fact that ORTC defines RTX, FEC, etc also as codecs, so multiple "codecs" in RtpParameters make sense. But due to this design, we end with cross-reference structs of codecs and encodings that allow "anything" (or the same in multiple ways).