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

Tim Panton <> Mon, 10 November 2014 17:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A2411A1A4D for <>; Mon, 10 Nov 2014 09:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id amnfxjxYhzZQ for <>; Mon, 10 Nov 2014 09:46:15 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DC001A1A4C for <>; Mon, 10 Nov 2014 09:40:34 -0800 (PST)
Received: (qmail 65281 invoked from network); 10 Nov 2014 17:40:32 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 14345
Received: from unknown (HELO ( by with SMTP; 10 Nov 2014 17:40:32 -0000
Received: from (localhost []) by (Postfix) with ESMTP id 185FD18A0E78; Mon, 10 Nov 2014 17:40:29 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPSA id F3B2D18A056B; Mon, 10 Nov 2014 17:40:28 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C902EBD-4044-4AE5-A9BC-D2DEF78BB730"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Tim Panton <>
In-Reply-To: <>
Date: Mon, 10 Nov 2014 17:40:27 +0000
Message-Id: <>
References: <> <> <>
X-Mailer: Apple Mail (2.1990.1)
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 17:46:19 -0000

> On 10 Nov 2014, at 16:51, Daniel-Constantin Mierla < <>> wrote:
> On 10/11/14 11:29, tim panton wrote:
>> 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
> It looks more like the reality on the ground of a few groups of
> interests (e.g, GSMA, telco vendors) trying to protect themselves. But
> again, in the web/internet world I don't see the same reality, they must
> stay competitive with features, not with restrictions or barriers to
> potential competitors.

On the subject of codecs, I discount the opinion of the GSMA utterly,
they have had 10 years  to make video calling (and wideband audio)
a desirable user proposition and have failed completely. 

The realities I’m thinking of are the ones facing someone building a
video enabled pet phone (for example). I can get H264 hardware very
cheaply (eg a raspberry Pi) and have it communicate with an ios App
or firefox on a laptop without any license (as far as I can tell).
Getting the same setup to work with VP8 will consume significantly 
more battery power at both ends.

I wish this were not the case, but that’s the reality I see.

> If something costly or with other restrictions is technically better or
> improving the user experience a lot in some medium of communication,
> then the developer of some app can decide to use/implement it. There is
> no reason of enforcing limits and financial constraints to everyone in
> open web via specs supposed to become standard.

If we mandate both codecs for devices, I agree, we are imposing an unacceptable
burden on everyone.
However I’m doubtful that any entity who can afford to build a new
w3c standards compatible browser will be unable to afford the (capped) h264 fee,
that’s simply a measure of how much work I think it is to do a new user agent now.
So the penalty in terms of restricting new browser innovation is small  (IMHO)
I’m much more worried about innovative devices.

> Rather than forcing now something inconvenient to be re-evaluated later
> for removal, better don't force anything now and re-evaluate later for
> inclusion. It will allow the market (besides the big players) to decide
> freely where it wants to move. The current proposal looks like: let's
> close the group now and later decide if we allow others in. Why not the
> other way around, keep the market fully open for new comers now and see
> what is going to be out there in few years, whether it makes sense to
> start building the walls at that moment.

That’s where we disagree. I really do not want to have to have a complex
matrix of versions of my parrot phone that correctly interop with other devices and
other pairings that don’t.

(E.G. buy a new android tablet and our android app if you use chrome, but if you reuse
an old ipad, you’ll have to use firefox).

We need an MTI statement. If we don’t get one we will be stuck with little
facetime-like islands again.

> Daniel
>> 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.
>> Tim.
>> _______________________________________________
>> rtcweb mailing list
>> <>
> -- 
> Daniel-Constantin Mierla
>!/miconda <!/miconda> - <>
> _______________________________________________
> rtcweb mailing list
> <>

Tim Panton - Web/VoIP consultant and implementor <>