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
-------------------------------------------------------------------