Re: [rtcweb] MTI Video Codec: a novel proposal

tim panton <> Mon, 10 November 2014 10:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B19EB1A89AD for <>; Mon, 10 Nov 2014 02:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qZyaMG2u_7jw for <>; Mon, 10 Nov 2014 02:29:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8039A1A899A for <>; Mon, 10 Nov 2014 02:29:16 -0800 (PST)
Received: (qmail 566 invoked from network); 10 Nov 2014 10:29:14 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 3509
Received: from unknown (HELO ( by with SMTP; 10 Nov 2014 10:29:14 -0000
Received: from (localhost []) by (Postfix) with ESMTP id 05FE818A0E62; Mon, 10 Nov 2014 10:29:15 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id D21B118A0CD3; Mon, 10 Nov 2014 10:29:14 +0000 (GMT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: tim panton <>
In-Reply-To: <>
Date: Mon, 10 Nov 2014 10:29:14 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Adam Roach <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Nov 2014 10:29:18 -0000

Adam, thanks for sticking you head above the parapet ! 
I’m largely in favour of this solution, further, I think it represents the realities on the ground better
than any other proposal to date, as such it merits support.

On 10 Nov 2014, at 02:08, Adam Roach <> wrote:

> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 

I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will 
always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement
of a webRTC device.

I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent
but that devices can’t necessarily communicate video between each other without a transcoding middle man.

This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or
don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a 
clearer separation.

This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to
know what is supported -  'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device
says that it will work with any user agent. 

With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category.