[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, 07 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.
- [rtcweb] H.261 vs No MTI (was: Alternative consen… cowwoc
- [rtcweb] Alternative consensus and MTI video code… Gregory Maxwell
- Re: [rtcweb] Alternative consensus and MTI video … Adam Roach
- Re: [rtcweb] Alternative consensus and MTI video … Gregory Maxwell
- Re: [rtcweb] Alternative consensus and MTI video … Ron
- Re: [rtcweb] Alternative consensus and MTI video … Adam Roach
- Re: [rtcweb] H.261 vs No MTI cowwoc
- [rtcweb] On the form of the question (was Re: Alt… Adam Roach
- Re: [rtcweb] H.261 vs No MTI Leon Geyser
- Re: [rtcweb] H.261 vs No MTI (was: Alternative co… Tim Panton
- Re: [rtcweb] H.261 vs No MTI Tim Panton
- Re: [rtcweb] H.261 vs No MTI Leon Geyser
- Re: [rtcweb] H.261 vs No MTI cb.list6
- Re: [rtcweb] On the form of the question (was Re:… Markus.Isomaki
- Re: [rtcweb] H.261 vs No MTI cowwoc
- Re: [rtcweb] H.261 vs No MTI cb.list6
- Re: [rtcweb] H.261 vs No MTI cowwoc
- Re: [rtcweb] On the form of the question (was Re:… Ron