[ortc] RtpSender.send() should just allow a single codec

ibc has just created a new issue for https://github.com/openpeer/ortc:

== RtpSender.send() should just allow a single codec ==
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).




Please view or discuss this issue at 
https://github.com/openpeer/ortc/issues/439 using your GitHub account

Received on Monday, 21 March 2016 10:54:04 UTC