Re: [Mops] Low latency protocol comparision

Alexandre GOUAILLARD <agouaillard@gmail.com> Sat, 13 June 2020 22:34 UTC

Return-Path: <agouaillard@gmail.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 C06F33A00B2 for <mops@ietfa.amsl.com>; Sat, 13 Jun 2020 15:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 V3OHR0G9V6Q7 for <mops@ietfa.amsl.com>; Sat, 13 Jun 2020 15:34:16 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 DC02E3A003C for <mops@ietf.org>; Sat, 13 Jun 2020 15:34:15 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id z2so12046051ilq.0 for <mops@ietf.org>; Sat, 13 Jun 2020 15:34:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nf8nrrwCYjNqwWBjr4lnNVK2VS8aIH36kA2tSGkQxWc=; b=HLH5aS6iTjLhJDnQ8BvqoIN6KYu+q3bS8bJ60wgAUW4YSUCqcpGHYT/70spIit9sq4 QPrZMDdXamGgm7F95LSCjNd6OUIsWQgt1lsdPn/T0T9/sCBFtPLjPV11S6WujGoNfEl9 PNh7hDlw6/4sIzmn6V1v3HjP8wO6OWAvMClAvKsIXG2wzGNFT5AmmBWeVMl6C8wySbpE vaUCNuPijfdBUYH6eM5hkok6ZNr01rmFdD+/hdu6C+qp1gP6Uy1rpaEbr81ooHAVAgzi iK7STKkzLIp63LYNR1moI+YRQaSId5p25GLryDnYpeH708ywMx3/P7jyK42Se09HhpF3 l2Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nf8nrrwCYjNqwWBjr4lnNVK2VS8aIH36kA2tSGkQxWc=; b=OOs8h0wj6Vc95v/pZDG8rggxzdXFA7HaiNx+ZTLkHK5s3aBposMiz6H4PQBcFgpSX7 zSSdHso+u2cvXIwGmi1RbhJEIIlGOCXX1D8Mq4CbGdaCEA3MA+dbs+A1VwC+utJe/BG5 PqqC8Ynb+NIOUjtgmZQooI9EFk8Qfc2dM3f4cWce1CyoEzLTiex9dvvqtAjlv59Dxnqm d7oERw7QNbyrLV02PigRzWZQMt28W0AAMWMRmTwyMhA5Y/t1SKFJlEQPeo14VvhsPIza 3IFOWjm3oO33eTBnnvm00ie6cNAkiylQAtYbvKva0piN+lyKPGhET6CV0mBwp27fyBOL gOzA==
X-Gm-Message-State: AOAM532LwuglNW8Eqd2p0e3fSXdTLh0rT/Kb/elNLreyGYFIfn6SyrEH Sv1Ljc/wZzhLqN+b6sWEe3WTirKXuGeRImW9tos=
X-Google-Smtp-Source: ABdhPJxKCEou2zp8UqD0cn7T/49EISrS3lSsCh9l2sEMQU8YZYHiMcBCYQ/b6SeuwWbimLHWeqh5QS1u2yg09vBFBho=
X-Received: by 2002:a92:5b86:: with SMTP id c6mr20343693ilg.100.1592087654702; Sat, 13 Jun 2020 15:34:14 -0700 (PDT)
MIME-Version: 1.0
References: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com>
In-Reply-To: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com>
From: Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Sun, 14 Jun 2020 00:34:03 +0200
Message-ID: <CAHgZEq4iQx0Un2N_rSOPafDCqzWxO_y_dX3JzZ=nw3=hbhinRQ@mail.gmail.com>
To: Leslie Daigle <ldaigle@thinkingcat.com>
Cc: mops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001c24d205a7fecba2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/0SIauRXhnUu5WoBLYETuyjFckZg>
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:34:18 -0000

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

   -