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

[Sergio Garcia Murillo <[e-mail]>]

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 (<
[e-mail]>) 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
>
> [2] -
> https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html
>
> [3] - https://github.com/h2o/quicly
>
>
>
> -- Maxim
>
>
>
>
> ------------------------------
>
> *From:* QUIC <[e-mail]> on behalf of Mike English <
> [e-mail]>
> *Sent:* 14 July 2021 19:09
> *To:* Victor Vasiliev <vasilvv=[e-mail]>
> *Cc:* Roberto Peon <fenix=[e-mail]>rg>; [e-mail] <
> [e-mail]>gt;; [e-mail] <[e-mail]>rg>;
> [e-mail] <[e-mail]>om>; Alan
> Frindell <afrind=[e-mail]>rg>; [e-mail] <[e-mail]>rg>;
> Kirill Pugin <[e-mail]>om>; Luke Curley <[e-mail]>
> *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
>
> [image: Logo] <https://www.haivision.com/>
>
>
>
>
> --
> Wish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wish
>