IETF Logo Mail Archive

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

Andrew Allen <aallen@blackberry.com> Tue, 09 December 2014 00:45 UTC

Return-Path: <aallen@blackberry.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 9D0581A1A87 for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 16:45:38 -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 hy6E4wQ-xtla for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 16:45:36 -0800 (PST)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 14FA31A1A7E for <rtcweb@ietf.org>; Mon, 8 Dec 2014 16:45:35 -0800 (PST)
Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 19:45:04 -0500
Received: from XCT114CNC.rim.net (10.65.161.214) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 8 Dec 2014 19:45:04 -0500
Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 19:45:03 -0500
From: Andrew Allen <aallen@blackberry.com>
To: Adam Roach <adam@nostrum.com>
Thread-Topic: [rtcweb] confirming sense of the room: mti codec
Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkIAAdtWA//+sviA=
Date: Tue, 09 Dec 2014 00:45:03 +0000
Message-ID: <BBF5DDFE515C3946BC18D733B20DAD233998ADF1@XMB122CNC.rim.net>
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>
In-Reply-To: <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G6pMcZoDsmazkuA4A2ywqmxGtWA
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 00:45:38 -0000

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

v2.23.0 | Report a Bug | By Email