{"action":"created","issue":{"url":"https://api.github.com/repos/openpeer/ortc/issues/439","repository_url":"https://api.github.com/repos/openpeer/ortc","labels_url":"https://api.github.com/repos/openpeer/ortc/issues/439/labels{/name}","comments_url":"https://api.github.com/repos/openpeer/ortc/issues/439/comments","events_url":"https://api.github.com/repos/openpeer/ortc/issues/439/events","html_url":"https://github.com/openpeer/ortc/issues/439","id":142313558,"number":439,"title":"RtpSender.send() should just allow a single codec","user":{"login":"ibc","id":16191,"avatar_url":"https://avatars.githubusercontent.com/u/16191?v=3","gravatar_id":"","url":"https://api.github.com/users/ibc","html_url":"https://github.com/ibc","followers_url":"https://api.github.com/users/ibc/followers","following_url":"https://api.github.com/users/ibc/following{/other_user}","gists_url":"https://api.github.com/users/ibc/gists{/gist_id}","starred_url":"https://api.github.com/users/ibc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ibc/subscriptions","organizations_url":"https://api.github.com/users/ibc/orgs","repos_url":"https://api.github.com/users/ibc/repos","events_url":"https://api.github.com/users/ibc/events{/privacy}","received_events_url":"https://api.github.com/users/ibc/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/openpeer/ortc/labels/1.0","name":"1.0","color":"009800"},{"url":"https://api.github.com/repos/openpeer/ortc/labels/1.1","name":"1.1","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":14,"created_at":"2016-03-21T10:54:01Z","updated_at":"2016-04-09T15:17:48Z","closed_at":null,"body":"Let's begin from how things are done in SDP O/A land:\r\n\r\n* Alice sends an offer to Bob indicating her capabilities (which codecs are supported, etc).\r\n* Bob replies an answer indicating his capabilities and selecting the exact codecs and features Alice is allowed to send.\r\n* Such a \"capabilities negotiation\" implicitly defines which codecs will be used in both directions (although any negotiated codec can be used at any time).\r\n\r\nTo summarize, SDP O/A provides codec capabilities negotiation + implicit codec selection.\r\n\r\nIn 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:\r\n\r\n* 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).\r\n\r\n* **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.\r\n\r\n* Again: Alice can call `send()` with both VP8 and VP9.\r\n\r\n* **Q:** What does it mean? which codec will the browser choose to encode the video?\r\n\r\nA 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).\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/openpeer/ortc/issues/comments/207806015","html_url":"https://github.com/openpeer/ortc/issues/439#issuecomment-207806015","issue_url":"https://api.github.com/repos/openpeer/ortc/issues/439","id":207806015,"user":{"login":"robin-raymond","id":2962646,"avatar_url":"https://avatars.githubusercontent.com/u/2962646?v=3","gravatar_id":"","url":"https://api.github.com/users/robin-raymond","html_url":"https://github.com/robin-raymond","followers_url":"https://api.github.com/users/robin-raymond/followers","following_url":"https://api.github.com/users/robin-raymond/following{/other_user}","gists_url":"https://api.github.com/users/robin-raymond/gists{/gist_id}","starred_url":"https://api.github.com/users/robin-raymond/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/robin-raymond/subscriptions","organizations_url":"https://api.github.com/users/robin-raymond/orgs","repos_url":"https://api.github.com/users/robin-raymond/repos","events_url":"https://api.github.com/users/robin-raymond/events{/privacy}","received_events_url":"https://api.github.com/users/robin-raymond/received_events","type":"User","site_admin":false},"created_at":"2016-04-09T15:17:48Z","updated_at":"2016-04-09T15:17:48Z","body":">Me too. But then we should wonder why we have an API that allows passing several streams/encodings/ssrcs to the same RtpReceiver.\r\n\r\nEarly on we discussed doing multiple `RtpReceiver`s versus having a single `RtpReceiver` for simulcasting. Since each simulcast stream was a separate `RtpReceiver` but the argument lost because in the CG meeting because:\r\n1. each RtpReceiver would emit its own `MediaStreamTrack`;\r\n2. each track would have to be manually switch by the programmer to the render element based upon the active `RtpReceiver` stream in the simulcast;\r\n3. the CG felt this was an unneeded burden on the developer since the only \"right thing to do\" would be to auto-switch between those simulcasted streams which is best suited to do by the engine;\r\n4. this allows early wiring of the render element from the `MediaStreamTrack` no matter which simulcast stream happened to be active;\r\n5. if a developer really wanted manual switching, they always can wire up separate `RtpReceiver` streams for each simulcast and manually switch between tracks;\r\n6. Encodings could be auto-filled based upon whatever happened to be the active simulcasted stream.\r\n\r\nThat's my summary but that's how it went down to answer your \"why\"...\r\n"}}