Re: [rtcweb] confirming sense of the room: mti codec

Adam Roach <adam@nostrum.com> Tue, 09 December 2014 03:44 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55AE1A1B7F for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 19:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 t9_ttW3oAwAo for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 19:44:22 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B02A1A1B5E for <rtcweb@ietf.org>; Mon, 8 Dec 2014 19:44:22 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB93iIQS081574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 21:44:19 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <54867014.7000709@nostrum.com>
Date: Mon, 08 Dec 2014 21:44:20 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrew Allen <aallen@blackberry.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <BBF5DDFE515C3946BC18D733B20DAD233998AC05@XMB122CNC.rim.net> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <BBF5DDFE515C3946BC18D733B20DAD233998ADF1@XMB122CNC.rim.net>
In-Reply-To: <BBF5DDFE515C3946BC18D733B20DAD233998ADF1@XMB122CNC.rim.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dQV7nphtDRVEgtTzIpawdLiigyE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 09 Dec 2014 03:44:24 -0000

I see two proposals in your response, both of which have been explored 
already. One is "choice 1" from the straw poll, which garnered only 48% 
support, and the other is "choice 12", which received only 7%.

Which is to say that these are not merely implausible, but demonstrably 
non-viable. So, when I asked whether you had a "constructive and 
plausible proposal," you could have saved us all some time by simply 
saying "no."

/a

On 12/8/14 18:45, Andrew Allen wrote:
> Adam
>
> Our preference is for H.264 to be the single MTI. We believe that Cisco's open source royalty free code offer goes a long long way to address the concerns of many related to IPR on H.264 and the prevalence now of APIs to access embedded codecs (such as H.264) on mobile devices goes even further to address those concerns. See http://www.ietf.org/id/draft-burman-rtcweb-h264-proposal-05.txt
>
> We also have proposed as a compromise having 2 MTI decoders but only have to implement one encoder.
>
> I know the above doesn't make everyone happy either.
>
> But this current proposed "compromise" whilst succeeding in garnering a significant hum in the room is opposed by some rather significant vendors in the browser space. So whilst it may make the RTCWEB Video RFC look pretty and complete it is unlikely to ensure interoperability in the market any more than simply leaving it to the market to decide (which is what will happen if we fail to agree on a single MTI video codec).  Having a standard that is not fully implemented by some of the primary participants in the market does not  bode well for the success of the standard even more than not agreeing on a single MTI codec IMHO. CLUE has agreed not to define MTI codecs but does this mean that telepresence interoperability will be a failure - I think not.
>
> BetaMax vs VHS and Blu Ray vs HD DVD have shown that ultimately the market will resolve these entrenched interoperability issues which are based on business reasons not technical merit without everyone having to agree in a standards body to support both or to support only one.
>
> Andrew
>
> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Monday, December 08, 2014 6:57 PM
> To: Andrew Allen
> Cc: Maire Reavy; rtcweb@ietf.org
> Subject: Re: [rtcweb] confirming sense of the room: mti codec
>
>
>
>> On Dec 8, 2014, at 17:28, Andrew Allen <aallen@blackberry.com> wrote:
>>
>> If we decide on two MTI video codecs then we have clearly failed to meet this commitment.
> Do you have a constructive and plausible proposal?
>
> /a