- From: Peter Thatcher <pthatcher@google.com>
- Date: Thu, 31 May 2018 11:01:13 -0700
- To: westhawk <thp@westhawk.co.uk>
- Cc: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
Received on Thursday, 31 May 2018 18:01:50 UTC
True, but then you have to run your own encoder/decoder/jitterbuffer in wasm. It would be nice if there were Web API components for those, which I think is what's missing from the things Harald has proposed so far. I proposed such encoders and decoders at TPAC in 2017 and I think it would fit well into the rest of what Harald has proposed. On Thu, May 31, 2018 at 10:30 AM westhawk <thp@westhawk.co.uk> wrote: > > > On 31 May 2018, at 18:58, Peter Thatcher <pthatcher@google.com> wrote: > > If they want to use SCTP for sending media or use RTP for data channels > even if it's "wrong" because no one else does that, > > > I’ll note that both of these things are already possible by mistreating > the WebAudioAPI :-) > > Which brings me to the other guarantee the browser should give - The > various APIs > should interact in reasonable and unsurprising ways. > > So for example you should continue to be able to take a mediaStream from > webRTC, > run it though webaudio (mixing it with a UserMedia stream) and then plug > the result into > a media stream recorder and have something reasonable happen. > > Enhancements that aren’t easily pluggable with the rest of the browser’s > awesome capabilities are > of questionable value IMHO. > > T. >
Received on Thursday, 31 May 2018 18:01:50 UTC