[rtcweb] Alternative consensus and MTI video codecs

Gregory Maxwell <greg@xiph.org> Fri, 08 November 2013 00:42 UTC

Return-Path: <gmaxwell@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A721E8177 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 16:42:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level:
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzaYgVZIYUKa for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 16:42:30 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBD21E8165 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 16:41:45 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id ea20so1091028lab.28 for <rtcweb@ietf.org>; Thu, 07 Nov 2013 16:41:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eJ0VSxjS2odmXC8shHjhUt5XM9OpsZ7sKLEaFXe2IHE=; b=i1vMAertNSuqZDnJob4brsMn3EalgpjhIkttSlymgCrJN3gkn6MA7CQclWryjIFvEZ d8u4KdGi6BCP/yz5HVTuM526f/JQjZhCM4DTnTdWm6V2xNmo/LZ3TChYt9gWxnHbog57 biwzj3ZH0mpli/RFaQT2wniHquhuhMrbEr/elbFqZgLjaxLHSdQnBo+5ewUY3jV5BmYQ 7vRoh1qavAlFh113/GVKkXGgz/hhHasenqgJub8s3gJdYTdwNqI/CiSenh9qPqmiU/tZ NlDhFrPqd8WfKW5mQETzE+WXdDX8Rf+A+HYdsXh96N2+GkDFsBTsKz/2+IK1vo21Il6D lmUA==
MIME-Version: 1.0
X-Received: by 10.112.198.39 with SMTP id iz7mr8445196lbc.24.1383871302902; Thu, 07 Nov 2013 16:41:42 -0800 (PST)
Sender: gmaxwell@gmail.com
Received: by 10.112.63.164 with HTTP; Thu, 7 Nov 2013 16:41:42 -0800 (PST)
Date: Thu, 7 Nov 2013 16:41:42 -0800
X-Google-Sender-Auth: 0QFoxM34pqDHP18aUvq82eqWMPE
Message-ID: <CAAS2fgQ730sjjv5Ly0_TFmdz=ryhPN13+A69_0_MedotHGEthg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] Alternative consensus and MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 00:42:32 -0000

I've always thought the RFC 3929 procedures were more of a threat to
encourage a consensus— if an uncomfortable one— than something that
ought to be used... but its not much of a threat if its never used,
and sometimes it's really important to have a decision.

I think we had previously agreed here that an MTI codec is important.
That it would break marketplace symmetry and create compatibility. It
may be that after the OpenH264 announcement some people believe MTI is
less important.

I think the question to ask is "Is and MTI video codec important
here".  Not do I support this codec or that. But is MTI video
something important the group should deliver.  If not, why not and why
wasn't it before?

"MTI is hard" isn't a valid answer to that question. "My favorite
option didn't win" isn't an answer either.

If we still believe from an engineering perspective that WebRTC ought
to have one MTI video codec it still can, even though the counts were
split:   We can invoke RFC 3929 4.4 and _flip a coin_.

A coinflip is a simple process which is guaranteed to make a section.
(If we don't trust a chair member to perform an actual coinflip, I can
suggest a trivial cryptographic protocol we can do in the list with
nothing more than the sha256sum tool)

I don't see how anyone can argue that for the goal of selecting an MTI
that a coinflip between options in a largely split room cannot achieve
that goal.

Alternatively, — considering market realities if MUST one of {vp8,h264
constrained baseline} is really the closest to MTI-in-practice  we
could expect full deployment of— is that preferable? Does it achieve
the goal of having MTI video in the first place? Does it partially
achieve it?

I don't think the argument that one-of-either is better than
none-at-all is sufficient: We can coinflip so none at all is not a
necessary option.  I think an argument for one-of-either must argue
that market realities make a single MTI (selected via coinflip) a dead
letter.  And arguments that either single codec as MTI were dead
letters have failed to convince the working group already.