Re: [Wish] [AVTCORE] Video ingest over QUIC

Yes I think DISPATCH would be right avenue for exploring this further.

Best
  Nils Ohlmeier

> On Jul 15, 2021, at 10:53, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> Wouldn't it be best to present the draft at the next DISPATCH meeting to create a WG/mailing list/etc? 
> 
> Best regards
> Sergio
> 
> El jue, 15 jul 2021 a las 19:29, Maxim Sharabayko (<maxsharabayko@haivision.com <mailto:maxsharabayko@haivision.com>>) escribió:
> @Alan, cool draft, thanks for sharing!
> 
>  
> 
> @here
> 
> It would be extremely interesting to see a dedicated mailing list and a working group established to discuss options for live contribution over QUIC.
> 
>  
> 
> We at Haivision have started evaluating QUIC Datagrams as an underlying transport for the Secure Reliable Transport (SRT) protocol [1].
> 
> In such a combination QUIC provides a network transport known to CDNs and ISPs, allowing to route and load balance the traffic, while SRT is used for latency-aware live streaming at sub-second latencies and loss recovery based on ARQ and/or FEC.
> 
> An RFC draft preview "Tunneling SRT over QUIC" is available here [2].
> 
>  
> 
> We've also done a PoC using the quicly [3] library to assess the approach and check for technical difficulties like possible conflicts between SRT's and QUIC's CC. The results are exciting!
> 
>  
> 
> We would be happy to present our work to the IETF community.
> 
>  
> 
> [1] - https://tools.ietf.org/html/draft-sharabayko-srt-00 <https://tools.ietf.org/html/draft-sharabayko-srt-00>
> [2] - https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html <https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html>
> [3] - https://github.com/h2o/quicly <https://github.com/h2o/quicly>
>  
> 
> -- Maxim
> 
>  
> 
>  
> 
> From: QUIC <quic-bounces@ietf.org <mailto:quic-bounces@ietf.org>> on behalf of Mike English <ietf@englishm.net <mailto:ietf@englishm.net>>
> Sent: 14 July 2021 19:09
> To: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org <mailto:vasilvv=40google.com@dmarc.ietf.org>>
> Cc: Roberto Peon <fenix=40fb.com@dmarc.ietf.org <mailto:fenix=40fb.com@dmarc.ietf.org>>; avt@ietf.org <mailto:avt@ietf.org> <avt@ietf.org <mailto:avt@ietf.org>>; wish@ietf.org <mailto:wish@ietf.org> <wish@ietf.org <mailto:wish@ietf.org>>; juberti@alphaexplorationco.com <mailto:juberti@alphaexplorationco.com> <juberti@alphaexplorationco.com <mailto:juberti@alphaexplorationco.com>>; Alan Frindell <afrind=40fb.com@dmarc.ietf.org <mailto:afrind=40fb.com@dmarc.ietf.org>>; quic@ietf.org <mailto:quic@ietf.org> <quic@ietf.org <mailto:quic@ietf.org>>; Kirill Pugin <ikir@fb.com <mailto:ikir@fb.com>>; Luke Curley <kixelated@gmail.com <mailto:kixelated@gmail.com>>
> Subject: [EXTERNAL] Re: [Wish] [AVTCORE] Video ingest over QUIC
> 
>  
> 
> I would personally be very interested in a "video over QUIC" working group or mailing list.
> 
> The directness of this draft is perhaps what's most interesting to me. 
> In particular, the absence of out-of-band signaling / session establishment stands in striking contrast with another UDP-based media ingest option: WebRTC.
> 
> The signaling needed for session establishment (and the diversity of implementations for such signaling) has historically been a barrier for WebRTC adoption as an ingest protocol outside of the browser context. WISH-WG is working to improve that situation for WebRTC of course, but a new QUIC-based ingest protocol presents an opportunity to sidestep some of those known-issues by making an architectural decision up front about whether that style of session management is necessary in a video contribution workflow.
> 
> I'm hoping others with more experience on these lists can speak to the history and tradeoffs associated with those approaches, but I just wanted to call attention to the aspect of the draft that seemed most notable to me as an operator of a low latency streaming platform where WebRTC egress and ingest capabilities are provided, but where RTMP is still the de facto ingest protocol of choice for many users.
> 
> Thanks for sharing this work!
> -Mike
> 
>  
> 
>  
> 
> 
> 
> 
> Maxim Sharabayko 
> Senior Software Developer                                                 
> <logo-h.png> <https://www.haivision.com/>	
> 
> 
> 
> 
> -- 
> Wish mailing list
> Wish@ietf.org <mailto:Wish@ietf.org>
> https://www.ietf.org/mailman/listinfo/wish <https://www.ietf.org/mailman/listinfo/wish>
> -- 
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish