From nobody Wed Oct 28 14:09:28 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914163A0AD8 for ; Wed, 28 Oct 2020 14:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VImhlp4xl5sN for ; Wed, 28 Oct 2020 14:09:23 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEB73A0AD4 for ; Wed, 28 Oct 2020 14:09:23 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id n15so584004wrq.2 for ; Wed, 28 Oct 2020 14:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=keBGA3Screnp2xDIZGNbfq51UyNwvJ0SwN9SW1/e7KY=; b=kGq8eUTnpAbzCtC9l8gPKvR2sIlE4/6v+QL2wHDz2leHO9zu3JWq6aYcM+Ej5WrqmI uq7g4u1iTKA2CUPQakubm5Qz9HCRepSHWgjzgsgJ7V7uog1AtZoU1grias8m5U8FKucF tbssHGVEgbelAtyBWgsa/Dq/QJlFbJIdZKaKxU+H/dV4fd3nhkxnupl3yJYzolJtL2Wo 7ElmWaiIqdSlpV87ja8a12G8P4tfV2qbP31c6hhCA7e2O8WTyhek+kwulOBl4muLkc2N 6BJKh/gIq6iXQzACYREc4lCtlibvCoeRFEV7vAWSMBWmHyTmI3rw7tsIwqo1B+59Vmg2 IUTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=keBGA3Screnp2xDIZGNbfq51UyNwvJ0SwN9SW1/e7KY=; b=i6290qYam6THJK+MKUG1I9UTdWTSo2yDNisINgoeW/JuUzbXmns/8YJVOoRT8fKaEO bUbexK8OgNZ0ps1LCxEKNQcmqOVFG/jpPtytngGzUhPZXVmdV2ufjvf9YGd2dRziygo1 dbAM/j9qvaVY+XPyT5BDR1cIRSNJyIULF6bIhqTSCYUid7yBQkXW1dlXJx/vODIHSvZT RcXWYqxXzUZ04Lrsk1uNTDRv0zytpsmJuk0fjOGYLwgjV4qCykJE/sXqfPq2LX50QXhc /8KTIs1jWpdW14KfGntO+KFwuYW9KhK7kIuy7oQIpwW7t8iapGgXexhaOdP1yoqTlCIJ f+dg== X-Gm-Message-State: AOAM533qiZE1quTwhC7mpDF9Q8y4e1mbiduZ/I+9ZFGfU5zIQu85MhhZ I3cx8ksAyU5tGIxoK/vQciWhlSxmXY8AXg== X-Google-Smtp-Source: ABdhPJz79D63Rst93yaP2YhAapniO/nssASNXjY71xP8y4tjc010uPVB2F2mbcIqvOl027ld0LJYiw== X-Received: by 2002:a5d:43c6:: with SMTP id v6mr1471104wrr.20.1603919361215; Wed, 28 Oct 2020 14:09:21 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id p9sm821673wma.12.2020.10.28.14.09.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 14:09:20 -0700 (PDT) To: dispatch@ietf.org References: From: Sergio Garcia Murillo Message-ID: <40d984ce-2af4-0b9d-f3cc-ac561a0e769a@gmail.com> Date: Wed, 28 Oct 2020 22:09:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------55CBEF048ECE9C18DFE47954" Content-Language: en-US Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 21:09:27 -0000 This is a multi-part message in MIME format. --------------55CBEF048ECE9C18DFE47954 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Glen, We are already participating in the MOPS, but I don't think it is the best place to progress the proposal, from the MOPS charter: "The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats." However, we were thinking in using it in the future hackathon for testing webrtc as currently there is no other easy way to test webrtc across a different set of implementations without ad-hoc integrations. Regarding SRT and RIST, none of them work on a web browser as an ingest point nor they allow easily to be translated to webrtc to enable lowest delay on distribution via webrtc. Best regards Sergio On 28/10/2020 21:15, Deen, Glenn (NBCUniversal) wrote: > > It may make sense to cross post this to the MOPS mailing list. > > I’ll point out that SRT and RIST are two examples of protocols used > professionally to transport content during acquisition. > > Also, there has been discussion in MOPS about setting up a future > side-by-side set of transport tests and measurements to understand the > behaviors of the different transports – perhaps at a future IETF > hackathon when everyone can work together in the same room. > > -glenn > > On 10/28/20, 1:10 PM, "dispatch on behalf of Ben Campbell" > on > behalf of ben@nostrum.com > wrote: > > Hi Everyone, > > Did anyone have feedback or other thoughts on Sergio’s proposal? > > Thanks! > > Ben. > > > > On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo > > wrote: > > Hi all! > > While WebRTC has been very successful in a wide range of > scenarios, its adaption in the broadcasting/streaming industry is > lagging behind. Currently there is no standard protocol (like SIP > or RTSP) designed for ingesting media in a streaming service, and > content providers still rely heavily on protocols like RTMP for it. > > These protocols are much older than WebRTC and lack by default > some important security and resilience features provided by WebRTC > with minimal delay. > > The media codecs used in older protocols do not always match those > being used in WebRTC, mandating transcoding on the ingest node, > introducing delay and degrading media quality. This transcoding > step is always present in traditional streaming to support e.g. > ABR, and comes at no cost. However webrtc implements client-side > ABR, by means of simulcast and SVC codecs, which otherwise > alleviate the need for server-side transcoding. Content protection > and Privacy Enhancement can be achieve with End-to-End Encryption, > which preclude any server-side media processing. > > We have been working on a proposal for a simple HTTP based > protocol that will allow WebRTC endpoints to ingest content into > streaming services and/or CDNs to fill this gap and facilitate > deployment: > > ·https://tools.ietf.org/html/draft-murillo-whip-00 > > > ·https://github.com/murillo128/webrtc-http-ingest-protocol/ > > > We have already implemented it on Janus and Medooze media servers: > > ·https://www.meetecho.com/blog/whip-janus/ > > > ·https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 > > > And added support into a WebRTC version of OBS studio: > > ·https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2 > > > We also plan to have an interop session on the next IETF > hackhaton, that will allow to check the interoperability between > different WebRTC implementations. > > What would be the best way of moving this forward? Obviously, any > feedback will be very welcome. > > Best regards > > Sergio > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------55CBEF048ECE9C18DFE47954 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Glen,

We are already participating in the MOPS, but I don't think it is the best place to progress the proposal, from the MOPS charter:

"The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats."

However, we were thinking in using it in the future hackathon for testing webrtc as currently there is no other easy way to test webrtc across a different set of implementations without ad-hoc integrations.

Regarding SRT and RIST, none of them work on a web browser as an ingest point nor they allow easily to be translated to webrtc to enable lowest delay on distribution via webrtc.

Best regards
Sergio


On 28/10/2020 21:15, Deen, Glenn (NBCUniversal) wrote:

It may make sense to cross post this to the MOPS mailing list.

 

I’ll point out that SRT and RIST are two examples of protocols used professionally to transport content during acquisition.

 

Also, there has been discussion in MOPS about setting up a future side-by-side set of transport tests and measurements to understand the behaviors of the different transports – perhaps at a future IETF hackathon when everyone can work together in the same room.

 

-glenn

 

On 10/28/20, 1:10 PM, "dispatch on behalf of Ben Campbell" <dispatch-bounces@ietf.org on behalf of ben@nostrum.com> wrote:

 

Hi Everyone,

 

Did anyone have feedback or other thoughts on Sergio’s proposal?

 

Thanks!

 

Ben.



On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

 

Hi all!

 

While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:

·         https://tools.ietf.org/html/draft-murillo-whip-00

·         https://github.com/murillo128/webrtc-http-ingest-protocol/

 

We have already implemented it on Janus and Medooze media servers:

·         https://www.meetecho.com/blog/whip-janus/

·         https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7

 

And added support into a WebRTC version of OBS studio:

·         https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2

 

We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.

 

What would be the best way of moving this forward? Obviously, any feedback will be very welcome.

 

Best regards

Sergio

 

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--------------55CBEF048ECE9C18DFE47954--