On Fri, 16 Jul 2021, 19:36 Spencer Dawkins at IETF, < [email protected]> wrote:
> This is, of course, why ADs get paid the big bucks (ha!), but > > On Wed, Jul 14, 2021 at 12:10 PM Mike English <[email protected]> wrote: > >> I would personally be very interested in a "video over QUIC" working >> group or mailing list. >> > > Martin Thompson said (in a reply that, I think, only went to the QUIC > mailing list(*)) that he thought this was big enough to BOF (which doesn't > mean it shouldn't be discussed at DISPATCH at IETF 111), but does say > something about what a mailing list could be used for. Offhand, I can > imagine: > > - discussion of the existing > https://www.ietf.org/archive/id/draft-kpugin-rush-00.html draft > - discussion of potential scope for a BOF proposal > - discussion of proposed text for a BOF request > > Could I ask what the people who are expressing interest in a mailing list > are thinking about? > +1. Good questions. There seems to be some appetite for _something_ that doesn't fit in existing boxes. Defining exactly what might be would be a sensible step on the path to a BoF. Cheers, Lucas > > Best, > > Spencer > > (*) email is archived at > https://mailarchive.ietf.org/arch/msg/quic/ocCm8E-GzP_pn4LBcJyKQeN7GRU/. > > 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 >> >> On Wed, Jul 14, 2021 at 12:32 PM Victor Vasiliev <vasilvv= >> [email protected]> wrote: >> >>> Hi Alan, >>> >>> Excited to see this draft! >>> >>> Since this isn't technically in scope for either avtcore, wish or quic >>> working groups, what would people think about making a new mailing list for >>> video over QUIC? >>> >>> Cheers, >>> Victor. >>> >>> On Wed, Jul 14, 2021 at 3:27 AM Justin Uberti < >>> [email protected]> wrote: >>> >>>> +1 >>>> >>>> On Tue, Jul 13, 2021 at 1:35 PM Roberto Peon <fenix= >>>> [email protected]> wrote: >>>> >>>>> Seems like a good idea to me, unless there is a home that is already >>>>> well suited! >>>>> >>>>> -=R >>>>> >>>>> >>>>> >>>>> *From: *QUIC <[email protected]> on behalf of Luke Curley < >>>>> [email protected]> >>>>> *Date: *Tuesday, July 13, 2021 at 1:16 PM >>>>> *To: *Alan Frindell <[email protected]> >>>>> *Cc: *"[email protected]" <[email protected]>, Sergio Garcia Murillo < >>>>> [email protected]>, "[email protected]" <[email protected]>, " >>>>> [email protected]" <[email protected]>, Kirill Pugin <[email protected]> >>>>> *Subject: *Re: [Wish] Video ingest over QUIC >>>>> >>>>> >>>>> >>>>> Hey Alan, thanks for publishing your protocol! >>>>> >>>>> >>>>> >>>>> Twitch has also been working on a video over QUIC protocol, albeit >>>>> primarily for video distribution instead of contribution. We're very >>>>> interested in collaborating on RUSH and producing a new standard for live >>>>> streaming! Would there be broader interest in forming a video over QUIC >>>>> working group? >>>>> >>>>> >>>>> >>>>> On Tue, Jul 13, 2021 at 12:04 PM Alan Frindell <afrind= >>>>> [email protected]> wrote: >>>>> >>>>> Hi Sergio, thanks for your interest in the draft. >>>>> >>>>> >>>>> >>>>> I’m interested in seeing a video ingest protocol standard that >>>>> leverages QUIC as a transport, has some partial reliability support, and >>>>> is >>>>> less connection-oriented so that servers can go down for maintenance >>>>> without impacting ingest reliability or having arbitrarily long drain >>>>> times. We published our RUSH draft to help kickstart the conversation but >>>>> we’re open to feedback and modifications if they help advance those goals. >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> -Alan >>>>> >>>>> >>>>> >>>>> *From: *Sergio Garcia Murillo <[email protected]> >>>>> *Date: *Tuesday, July 13, 2021 at 9:02 AM >>>>> *To: *Alan Frindell <[email protected]> >>>>> *Cc: *"[email protected]" <[email protected]>, "[email protected]" <[email protected]>, >>>>> "[email protected]" <[email protected]>, Kirill Pugin <[email protected]> >>>>> *Subject: *Re: [Wish] Video ingest over QUIC >>>>> >>>>> >>>>> >>>>> Hi Alan, >>>>> >>>>> >>>>> >>>>> I think that the correct place for discussing it is AVTCORE as Bernard >>>>> has indicated, as WISH is not chartered to implement any new media >>>>> protocol. >>>>> >>>>> >>>>> >>>>> The draft is very interesting and I would be willing to collaborate, >>>>> what is your main interest? Do you want to try to publish it as it is or >>>>> would you be accepting feedback and include modifications? >>>>> >>>>> >>>>> >>>>> Best regards >>>>> >>>>> Sergio >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> El mar, 13 jul 2021 a las 17:37, Alan Frindell (<afrind= >>>>> [email protected]>) escribió: >>>>> >>>>> Hi, for several years, Facebook has been using its own video ingest >>>>> protocol over QUIC from our apps to our infra. While we’ve spoken about >>>>> it >>>>> before, we just now published a draft documenting how it works: >>>>> https://www.ietf.org/archive/id/draft-kpugin-rush-00.html. >>>>> >>>>> The protocol leverages the advantages of QUIC transport, and features >>>>> a partially reliable mode using only QUIC v1 RST_STREAM. >>>>> >>>>> We welcome your feedback >>>>> >>>>> Thanks >>>>> >>>>> -Alan Frindell >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Wish mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/wish >>>>> >>>>> -- >>>>> Wish mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/wish >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Core Maintenance >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/avt >>>>> >>>> -- >>> Wish mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/wish >>> >>
