[rtcweb] H.261 vs No MTI (was: Alternative consensus and MTI video codecs)
cowwoc <cowwoc@bbs.darktech.org> Fri, 08 November 2013 05:56 UTC
Return-Path: <cowwoc@bbs.darktech.org>
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 0AD8D11E811A for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 21:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.304
X-Spam-Level:
X-Spam-Status: No, score=-4.304 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 tpU0Pun4IiZ3 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 21:56:18 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id E902A11E8158 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 21:56:17 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id to1so790401ieb.37 for <rtcweb@ietf.org>; Thu, 07 Nov 2013 21:56:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=skVWRQlp2nlCffock4wnFp+sHls4wX4cUzrx8aTFhzs=; b=Yz4DTsOxhApeGxk9Rr2G44ZWju92OdHbZWRfVoRA9jP9LQ+fSmDWvKG/8PQ96RjVVz BxiP/nT/M92MDmR4So4y85X7VbOnWOqWG8iy1TcnW7dDdbdx2Iyc3I/XVTG8xtMlmiNG cuOmjSQM7P+6rsBpT32h9yEBRm8AbX88EJexIyImnEDJg+ZnIbCV1pJ9H5iMxYNET//B nIcVRjb7ibl5ne4qhHqIY6d/f8PAS/2aEaKahUl78XYuZbq38s27/IVpkBR48HaQp70P 0reReG5zaVA5+XdxXxw/5Nt5+6pglg18YtNE+6YiWMz7tuClsVxhb6M/ko0ye+Fo2H77 6F7Q==
X-Gm-Message-State: ALoCoQluubma3Rfjo1+T3DEeBg9f0OAHtoneIlaodbdqJLH4AAP+lTMh/ukxsVxKDa2MvGGuKeDH
X-Received: by 10.43.152.78 with SMTP id kv14mr7769644icc.13.1383890176903; Thu, 07 Nov 2013 21:56:16 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm1662646igc.4.2013.11.07.21.56.15 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 21:56:16 -0800 (PST)
Message-ID: <527C7CFE.4080700@bbs.darktech.org>
Date: Fri, 08 Nov 2013 00:56:14 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAAS2fgQ730sjjv5Ly0_TFmdz=ryhPN13+A69_0_MedotHGEthg@mail.gmail.com> <527C38FF.6040000@nostrum.com> <CAAS2fgSGdmFaxZ4jtYjyG9tDqKv09-L8FXSybeHrgvzNtdqYpQ@mail.gmail.com>
In-Reply-To: <CAAS2fgSGdmFaxZ4jtYjyG9tDqKv09-L8FXSybeHrgvzNtdqYpQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090909070406090707070703"
Subject: [rtcweb] H.261 vs No MTI (was: 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 05:56:27 -0000
I'll bring up a related point that I brought up a few days ago (I changed to subject to avoid hijacking the thread). Say we can't agree on whether to use VP8 or H.264 as MTI. We can then simply settle on a codec with expired IPR such as H.261. H.261 is the codec everyone loves to hate but allow me to point out the following: * If H.261 is MTI, you can still upgrade to VP8 * If H.261 is MTI, you can still upgrade to H.264 * If H.261 is MTI, you can still use transcoding to connect VP8 to H.264 Using H.261 as MTI is a big win over no MTI because "no MTI" means we're forced to do transcoding, whereas H.261 as MTI means we can still do transcoding if we want, but we don't have to. And yes, I agree that a more ideal solution is to choose VP8 or H.264 as MTI (or both) than H.261... but if worse comes to worse, I don't see a benefit to choosing "no MTI" over H.261. Does anyone have a counter-point? Gili On 07/11/2013 9:22 PM, Gregory Maxwell wrote: > On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach <adam@nostrum.com> wrote: >> Our situation is radically different: there are a number of actual arguments >> to be made for both options. > We've heard these arguments, at long length, and have, apparently, not > found them sufficiently decisive or we wouldn't be at this juncture. > > I must have failed to make the point I was attempting to make > sufficiently clear. Let me retry: If we believe that an MTI video > codec, regardless of what it is, was an independently important thing > to have then "no MTI" shouldn't be the result of failing to achieve an > MTI in discussion, because there exist _an option_, any option, to > achieve a MTI video codec. So I was hoping to see any support for "no > MTI" (which sounded very popular in the room) to come with arguments > for why an MTI doesn't actually matter. > > Without intending any "push", strong or otherwise, I'll point out that > the apparent difficulty in responding to my message without > allegations of irrational arguments and emotional investments > increases my estimation that locating a set of "randomly selected > neutral parties" which is sufficiently non-partisan to not cloud the > process is not obviously possible. Without that kind of doubt in mind > it's not clear to me if that alternative process could be successful, > which is why I attempted to illustrate my point with the 4.4 coinflip. > Coinflip will produce a result, and the result it will produce will > achieve the goal of selecting an MTI codec (especially in > consideration of substantial support for either option, both on the list > and in the room), and it doesn't require selecting non-partisan > parties. I wasn't trying to say it was _good_ though, only that it > was enough to say failure to pick an MTI alone isn't enough to justify > removing MTI for the sake of MTI from the goals. > > (There are plenty of other arguments that can be made about the > non-optimality of the 3929 panel process— e.g. the requirement to meet > nomcom requirements with physical meeting attendance would generally > make it easy for large corporate contributors, especially ones with > diverse participation, to be over represented. But, to be frank, your > response has made me feel uncomfortable pointing that much out... I > didn't start this thread with an intention to argue against it, but I > wonder after your message if anyone else would dare.) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [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