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

Randell Jesup <> Wed, 12 November 2014 14:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3D3E1A90DE for <>; Wed, 12 Nov 2014 06:42:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LdTtGygGevCu for <>; Wed, 12 Nov 2014 06:42:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 81A141A90D8 for <>; Wed, 12 Nov 2014 06:42:10 -0800 (PST)
X-Sender-Id: wwwh|x-authuser|
Received: from ( []) by (Postfix) with ESMTPA id 570D761245 for <>; Wed, 12 Nov 2014 14:42:05 +0000 (UTC)
X-Sender-Id: wwwh|x-authuser|
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by (trex/5.3.3); Wed, 12 Nov 2014 14:42:08 GMT
X-MC-Relay: Neutral
X-MailChannels-SenderId: wwwh|x-authuser|
X-MailChannels-Auth-Id: wwwh
X-MC-Loop-Signature: 1415803327688:2049864223
X-MC-Ingress-Time: 1415803326708
Received: from ([]:58391 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1XoZ7U-000GzO-Ut for; Wed, 12 Nov 2014 08:42:05 -0600
Message-ID: <>
Date: Wed, 12 Nov 2014 09:41:35 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090100000209030406000509"
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: Wed, 12 Nov 2014 14:42:15 -0000

On 11/11/2014 5:41 PM, Gaelle Martin-Cocher wrote:
> Thanks for the effort Adam.

Agreed.  This is an incredibly thorny issue due to politics, ideology, 
money, etc - almost none of which is technical, except in the 
ramifications of various not-clean-1-codec-MTI options, as mentioned 
somewhat here.  While I personally (this is the IETF) would prefer a 
pure VP8 MTI, I realize that isn't going to happen right now, and this 
may be (to steal a quote from B5) our last best hope for peace... I mean 

> We would still prefer a single video MTI codec. That said, here is an 
> alternative to/modification of the 'novel proposal' to try to mitigate 
> the concerns.
> When video interoperability is required, the following applies:
> - All WebRTC endpoints SHOULD implement decoding for at least
>    VP8 and H.264.
> - In operating environments that expose a platform provided
>    implementation of H.264, WebRTC endpoints MUST implement H.264

You assume "platform" codec implementations (H.264 and VP8) are 
inherently useful for WebRTC.  They often aren't.  You can include 
wiggle words about "usable" or "realtime", which helps but certainly 
makes the decision the domain of the implementing device/browser (to 
decide if it's usable).  I would extend this to must support both if 
they have "usable" platform-provided implementations.

> Some device/OS vendors have released API to hardware supported codec 
> (BlackBerry included). One of the goal is to offer codec access 
> without additional cost to non-platform-native 
> UA/browser/device/non-browser, hence maximizing interoperability for 
> WebRTC endpoints. And without having multiple occurrences of codecs 
> being loaded on the platform.
> We should leverage this possibility as this becomes more widely 
> available across platforms.

Agreed - but this can be easier said than done, especially on Android, 
and may require per-device/OS-version validation to use. Older OS's 
(Windows pre 8.x for example) don't have viable realtime H.264 codecs by 
default, and we haven't yet verified if the Win8 codec meets the WebRTC 
needs (though likely it does), and so far as I know it's software-only.  
Others may not be available to applications (iOS? especially older iOS).

Randell Jesup -- rjesup a t mozilla d o t com