Re: [Mops] Low latency protocol comparision
Leslie Daigle <ldaigle@thinkingcat.com> Sat, 13 June 2020 22:41 UTC
Return-Path: <ldaigle@thinkingcat.com>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8933A03FF for <mops@ietfa.amsl.com>; Sat, 13 Jun 2020 15:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=thinkingcat.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 tQKdGfHPNbFN for <mops@ietfa.amsl.com>; Sat, 13 Jun 2020 15:41:46 -0700 (PDT)
Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98563A03F3 for <mops@ietf.org>; Sat, 13 Jun 2020 15:41:45 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D51FB20B57; Sat, 13 Jun 2020 22:41:44 +0000 (UTC)
Received: from pdx1-sub0-mail-a61.g.dreamhost.com (100-96-22-28.trex.outbound.svc.cluster.local [100.96.22.28]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3689D20872; Sat, 13 Jun 2020 22:41:44 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com
Received: from pdx1-sub0-mail-a61.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 13 Jun 2020 22:41:44 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com
X-MailChannels-Auth-Id: dreamhost
X-Chief-Daffy: 7341c2c522d41005_1592088104684_1368413538
X-MC-Loop-Signature: 1592088104684:2455384564
X-MC-Ingress-Time: 1592088104683
Received: from pdx1-sub0-mail-a61.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTP id DD13E91F83; Sat, 13 Jun 2020 15:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type; s=thinkingcat.com; bh=cSm3Z1Jp52IfqiTU65UPjzMSgUQ =; b=X30vFWT0ynh2JV0K11RSmQcqqqTDGNftWk7QXeKutECI8x1eufa/B/JJq9b Ue4vicAXCnVm6aj2LnS1VA4Q6OW7QzexGwjiEUjZaX8sBnRX7CEo9loHm0dw87vU b6saZWBKO9B2WlRznSV/Fbcb12FlAqeMO/tLwrjtH6MeVew8=
Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTPSA id E41D2838E4; Sat, 13 Jun 2020 15:41:41 -0700 (PDT)
X-DH-BACKEND: pdx1-sub0-mail-a61
From: Leslie Daigle <ldaigle@thinkingcat.com>
To: Alexandre GOUAILLARD <agouaillard@gmail.com>
Cc: mops@ietf.org
Date: Sat, 13 Jun 2020 18:41:32 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <0807B637-529D-4F69-834B-80304DD5F276@thinkingcat.com>
In-Reply-To: <CAHgZEq4iQx0Un2N_rSOPafDCqzWxO_y_dX3JzZ=nw3=hbhinRQ@mail.gmail.com>
References: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com> <CAHgZEq4iQx0Un2N_rSOPafDCqzWxO_y_dX3JzZ=nw3=hbhinRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_FB2BA0C3-DE83-475A-ACED-55A39E95F324_="
Embedded-HTML: [{"HTML":[1217, 8031], "plain":[576, 4569], "uuid":"7108787B-A899-4249-A418-55FE735A5899"}]
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeigedgudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffoffkjghfgggtsegrtdhmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuggftrfgrthhtvghrnhepveejvdehgfeuffeuteevtedvgfelheevgedutdeikeejfffgueegueffleehvdegnecuffhomhgrihhnpeifvggsrhhttggshigurhgrlhgvgidrtghomhdpihgvthhfrdhorhhgpdgthhhrohhmihhumhdrohhrghdptggrnhhiuhhsvgdrtghomhdpfihpthdrfhihihdpvghlvggtrghrugdrtghomhdplhhinhhkvgguihhnrdgtohhmnecukfhppedvudeirdeiiedruddtvddrkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehjegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtoh hmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/c9AbuUFyBrJL7Nnx-QfbWjDAMIM>
Subject: Re: [Mops] Low latency protocol comparision
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jun 2020 22:41:51 -0000
Hi, [You wrote:] > If anybody is interested in going deep into a real thorough > comparison > between all those protocols, why not doing it during the IETF > hackathon in > July, or in october (hopefully in BKK) just like we did group > co-testing > with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF > hackathons? Volunteering? :-> If there’s interest in doing it, along the specific vector of video delivery, and willingness to write it up as an I-D afterwards, I think it would be great. Leslie. On 13 Jun 2020, at 18:34, Alexandre GOUAILLARD wrote: > There are multiple inaccurate statements in the linked documents. Most > of > them that have been carried around for many years by other SRT vendors > like > Wowza and already called out (here > <http://webrtcbydralex.com/index.php/2019/05/18/wowzas-marketing-at-work-again-webrtc/> > for example). > > I'm just going to point to three of the most egregious (read > "verifiably > wrong") statements, that by themselves undermine the credibility of > the > entire document. > > - "Maximum supported resolution: 720p, 30 frames per second with a bit > rate > of up to 2 Mbps." > - There is no limit to the spatial and temporal resolution in > webrtc/rtcweb > protocol. > Stadia for example send up to 4K@30fps. > > "WebRTC is inferior to its colleagues in terms of the coding quality > and > maximum amount of transmitted data. > - There is no limit to the bandwidth used in the webrtc/rtcweb > protocol. > - There is a limit of 2Mbps per peer connection on the sending-side > *only > in the google chrome implementation*, only by default (web application > can > lift this limit), and only for webcams devices (screensharing has no > bandwidth limit). This is a chrome implementation detail, and not a > protocol limit. > -While VP8 and H264 are both mandatory to implement (original IETF > discussion > <https://mailarchive.ietf.org/arch/msg/rtcweb/juVsZKp-AmRpYLCgy-uwartuNrY/>) > anybody can add any codec to webrtc as long as an RTP payload > specification > exists. > -- Google chrome, and firefox, both supports real-time VP9 mode 2 > (4:4:4, > 10 bits, HDR) > https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=985 > -- Chrome has a real-time AV1 implementation in webrtc, which goes up > to > high profile (4:4:4, 8~10bits, HDR). > https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/modules/video_coding/codecs/av1/ > In terms of quality, only codecs at high profile (i.e. 12bits) can do > better, and none of those have a "real-time" version today. > In terms of coding efficiency, AV1 is still the best codec available > in > production. > > "WebRTC is not available in Safari and partially unavailable in Bowser > and > Edge." > - webrtc is fully available in Edge, and Safari. > https://caniuse.com/#search=webrtc > official daily W3C results: > https://wpt.fyi/results/?label=master&label=experimental&aligned&q=webrtc > - Safari has added H.265 support in addition to the mandatory to > implement > VP8 and H.264 in the latest safari tech preview. > > I'm not going into the Discussion about webrtc's underlying RTC/RTCP > protocol and corresponding extension: NACK, RTX, FEC, RED, or > Congestion > Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re > all > aware of RFC3550 and all its derivatives. Many authors of those RFCs > are > part of this group. > > Maybe more overlooked is the most recent Draft for end-to-end > encryption on > top of webrtc co-authored by google: > https://tools.ietf.org/html/draft-omara-sframe-00 > > I'm not saying that SRT is worse, or better than WebRTC. I'm just > saying, > this comparison is not egregiously incorrect, and I'm a little bit > surprised that we are discussing marketing blogs that go in the face > of so > many IETF specs. > > If anybody is interested in going deep into a real thorough > comparison > between all those protocols, why not doing it during the IETF > hackathon in > July, or in october (hopefully in BKK) just like we did group > co-testing > with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF > hackathons? > > Regards, > > > > On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle > <ldaigle@thinkingcat.com> > wrote: > >> I thought this was a pretty interesting analysis: >> >> Low broadcast latency and protocols for implementation thereof: >> >> https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_implementation_thereof >> >> Particularly telling is the chart at the end: WebRTC and SRT don’t >> look >> very similar, in this particular regard. >> >> Leslie. >> >> -- >> ------------------------------ >> >> Leslie Daigle >> Principal, ThinkingCat Enterprises >> ldaigle@thinkingcat.com >> -- >> Mops mailing list >> Mops@ietf.org >> https://www.ietf.org/mailman/listinfo/mops >> > > > -- > Alex. Gouaillard, PhD, PhD, MBA > ------------------------------------------------------------------------------------ > President - CoSMo Software Consulting, Singapore > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > - -- ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com -------------------------------------------------------------------
- [Mops] Low latency protocol comparision Leslie Daigle
- Re: [Mops] Low latency protocol comparision Alexandre GOUAILLARD
- Re: [Mops] Low latency protocol comparision Leslie Daigle
- Re: [Mops] Low latency protocol comparision Deen, Glenn (NBCUniversal)
- Re: [Mops] Low latency protocol comparision Alexandre GOUAILLARD
- Re: [Mops] Low latency protocol comparision Maxim Sharabayko
- Re: [Mops] Low latency protocol comparision Alexandre GOUAILLARD
- Re: [Mops] Low latency protocol comparision Leslie Daigle
- Re: [Mops] Low latency protocol comparision Kyle Rose
- Re: [Mops] Low latency protocol comparision Maxim Sharabayko
- Re: [Mops] Low latency protocol comparision Ross Finlayson
- Re: [Mops] Low latency protocol comparision Leslie Daigle
- Re: [Mops] [EXTERNAL] Re: Low latency protocol co… Glenn Deen
- Re: [Mops] Low latency protocol comparision Spencer Dawkins at IETF
- Re: [Mops] Low latency protocol comparision Maxim Sharabayko