- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 21 May 2018 11:35:22 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
- Message-ID: <CAJrXDUHGE0vuw5K2nQVW856SiBi5M44WKmkYiUe1n-8REtRn6w@mail.gmail.com>
On Sun, May 20, 2018 at 9:08 PM Harald Alvestrand <harald@alvestrand.no> wrote: > On 05/18/2018 11:33 PM, Peter Thatcher wrote: > > By the way, this is my use case: as a web/mobile developer, I want to > > send media over QUIC for my own replacement for RTP. QUIC isn't the > > replacement for RTP, but my own protocol on top of QUIC (or SCTP, or > > any data channel) is the replacement for RTP. Luckily, this is > > "free" as soon as you add QUIC data channels and split the RtpSender > > into encoder and transport. That's all I need. > > > Peter, > > since I'm asking this of others: > > can you please expand this into an use case - describe a function or > application that is possible / easy when you have that functionality > available, and is impossible / hard to do today? > I have a few: - Terminating media (audio, video, data) on a server is a pain in the neck with DTLS/RTP/RTCP/SCTP. I would like that to be much easier. Sending a serialized frame object (say, CBOR or protobuf) over a QUIC stream is way easier to terminate. - Including real-time data that's synchronized with audio and data, or including metadata about a particular audio for video frame is much easier if I can just attach it to a serialized frame object as mentioned above. - Taking more directly control over stream control signaling (mute state, key frame requests, end-of-stream), etc is much easier if the control plane is controlled by the application and can be integrated with the flow of media, unlike today with RTCP (not under control of app) or data channels (not integrated with flow of media). - e2ee without the complexities of double SRTP. All of these have been brought up as use cases already by developers in responses to Sergio's survey https://docs.google.com/forms/d/1YVKqVU_ziCYtp8RGGnwB8WcQWDhkXe-mOmaSkFTdJm8/viewanalytics ). More generally, RTP is needlessly complex. It's hard to add things, it's hard to change things, it's hard to debug things, and it's hard to understand things. So in a sense, my use case is "cause me less complexity and pain". > > I agree with Sergio that this is a description of an implementation, not > an use case (and that it's useless for use cases that involve the RTP > ecosystem, which means that the use case you have in mind isn't one of > Sergio's use cases). > > -- > Surveillance is pervasive. Go Dark. > > >
Received on Monday, 21 May 2018 18:36:00 UTC