- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 05 Mar 2018 22:22:33 +0000
- To: youenn fablet <yfablet@apple.com>
- Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, WebRTC WG <public-webrtc@w3.org>
- Message-ID: <CAJrXDUE32uFiC6LoSDX4pZUBGE-Uj0V-MD3EX_S9t0p=SoEfwg@mail.gmail.com>
On Mon, Mar 5, 2018 at 1:53 PM youenn fablet <yfablet@apple.com> wrote: > On Mar 5, 2018, at 12:25 PM, Peter Thatcher <pthatcher@google.com> wrote: > > Even though you have discussion in the IETF going on at dispatch@ietf.org, > I think that it's worth having discussion here about the Web API side of > things. I think almost your entire proposal could be implemented in > JS/wasm with the following Web APIs: > > - SLICE (what I proposed two virtual interims ago as part of > https://github.com/w3c/webrtc-ice) > - QUIC data streams (https://github.com/w3c/webrtc-quic) > - A low-level audio/video encoder/decoder API (like what I proposed at > TPAC in 2017) > > > I like the idea of low level APIs. > One important missing bit is the ability for web apps to do efficient > frame processing from getUserMedia/video tracks. > Moving that forward would be great, the current canvas based approach is > not ideal. > > I do not see very compelling use cases for low-level audio/video > encoder/decoder API on the other hand. > If you want to send media over QUIC or do your own crypto between encode and network (perhaps over some low-level RTP transport), then you need access to media after its encoded and before it's decoded. > Maybe I should look at what was presented at TPAC but I would tend to put > it at a much lower priority. > Here's what I presented: https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9HVu7W38Y4zA/edit#slide=id.g29a8672e18_22_120 > I think having those APIs available for your idea to be possible to > implement in a web context (or other similar ideas) is a great direction to > go. > > > The only thing I think your proposal seeks that the three APIs above > cannot provide is a mechanism for replacing the STUN/TURN message format. > It could allow for new STUN/TURN message formats if run over QUIC, but if > they need to be outside of QUIC, then it would need be standardized first > in the IETF and then added into SLICE. > > On Mon, Mar 5, 2018 at 11:48 AM Cullen Jennings (fluffy) <fluffy@cisco.com> > wrote: > >> >> SDP is really awful - encoding SDP as parsed JSON does not help much. >> What we need to do to greatly simplify things is get rid of SDP. The offer >> answer is really complicated for modern systems that have more uniform >> capabilities so I would like to get rid of offer answer too. To simplify >> all the control, I think one needs to also simplify STUN, TURN, ICE, RTP, >> and SRTP. >> >> I wrote a draft outlining that - it is at: >> >> https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ >> >> it is being discussed on the dispatch@ietf.org email list ( you can join >> at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR at >> https://github.com/WhatIETF/draft-jennings-dispatch-new-media >> >> Love to get feedback in general and also on how this, or parts of it, >> would be a good way to go for the next version of WebRTC >> >> Thanks, Cullen >> >> >> >> >>
Received on Monday, 5 March 2018 22:23:09 UTC