- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Tue, 12 Apr 2016 14:16:01 +0200
- To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Cc: Justin Uberti <juberti@google.com>, Peter Thatcher <pthatcher@google.com>, "public-ortc@w3.org" <public-ortc@w3.org>
2016-04-12 10:19 GMT+02:00 Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>: > I completely disagree with the "easiness of usage" of current API, I feel > that we are just using a jsonized-m-line containing all the information and > passing it to a RTCPeerconnection-like object that is almost an static > function. In this regards, IMHO, this is against the reasons why ORTC was > created on the first place, and I don't see the benefits from moving from > WebRTC to ORTC. If there is no need to change anything, then I just want to see a JS example of a VP9+SVC RtpSender with 3 layers over the same transport: - Layer 1: - quality: good - SSRC: 1111 - PT: 101 - Layer 2: - quality: medium - SSRC: 2222 - PT: 102 - Layer 3: - quality: low - SSRC: 3333 - PT: 103 Please don't tell me that setting SSRC values is not needed. The API allows that so I do want it (regardless the use cases of other developers and regardless the "RTP Matching Rules" section). Also consider that I may prefer to send all the SVC layers with same PT 100 (so the SSRC helps demultiplexing them in the receiver side). Also, please let me know how the developer can know what the VP9 codec supports, including SVC (I mean via API, not via codec spec, so this should also transparently work for a future VP10). Then, when the RTCRtpParameters blob is done, please show it here and convince me that **any** ORTC capable browser will behave exactly as such a complex Object describes. Thanks. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Tuesday, 12 April 2016 12:16:49 UTC