- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sat, 24 Nov 2018 08:26:59 +0100
- To: public-webrtc@w3.org
On 11/23/2018 10:58 PM, Nils Ohlmeier wrote: > >> On 23Nov, 2018, at 13:40, Harald Alvestrand <harald@alvestrand.no> wrote: >> >> On 11/23/2018 11:02 AM, Sergio Garcia Murillo wrote: >>> On 23/11/2018 10:52, westhawk wrote: >>>> One problem that QUIC_theoretically_ solves is the congestion >>>> control problem by bringing everything under >>>> the same protocol, but only if you move all media to QUIC and ban RTP. >>> Just for the sake of completeness, the other problem that QUIC solves >>> is the sync between media and data, something that is not achievable >>> today between SCTP and RTP (AFAIK). >>> >>> This is already contemplated on the webrtc NV uses cases and it is a >>> critical issue for many applications (for example VR ones) >> I've made a couple of stabs in the past at making correlation possible >> between data and media (the easiest seems to be to offer access to the >> RTP timestamp of the frames on both sides of the connection). But those >> efforts have petered out for lack of interest. > As there seems to be general agreement that this use case is now interesting maybe the easier solution would be to revive one of these now and deliver a probably quicker solution for these uses, instead of establishing new transport protocols for which the synchronization would have to be solved as well. The proposal I made at one point (exposing timestamps) is detailed here: https://github.com/alvestrand/webrtc-framelog
Received on Saturday, 24 November 2018 07:34:27 UTC