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