Re: [rtcweb] A different perspective on the video codec MTI discussion

Randell Jesup <> Thu, 14 March 2013 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE73021F8EA8 for <>; Thu, 14 Mar 2013 05:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EJhFYvf6otPa for <>; Thu, 14 Mar 2013 05:29:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D0E421F8E5D for <>; Thu, 14 Mar 2013 05:29:41 -0700 (PDT)
Received: from ([]:62492) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1UG7Hw-0001cx-KC for; Thu, 14 Mar 2013 07:29:40 -0500
Message-ID: <>
Date: Thu, 14 Mar 2013 08:29:44 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion
X-Mailman-Version: 2.1.12
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: Thu, 14 Mar 2013 12:29:41 -0000

On 3/13/2013 6:06 PM, Jonathan Rosenberg wrote:
> I’d like to put a different perspective on the video MTI discussion.

Note: I haven't read the whole thread yet, but I'll make a comment 
anyways and read the rest this morning. :-)

> Many developers would probably love to connect users on the web with 
> users on mobile apps. Most mobile platforms today support H264 based 
> hardware acceleration for decode and sometimes encode, but not yet 
> VP8. Developers who want to build business communications clients will 
> need to connect those users with other users in the business, who may 
> be using videophones, PC clients, telepresence units or video room 
> systems, the vast majority of which do not support VP8 today, but many 
> of which do support H.264.

I'll note that (no new arguments here):
a) not all H.264 hardware is good at low-delay coding, or will support 
all the knobs we would like for realtime use
b) software encoding generally uses more power, but WiFi at constant 
send/receive and device displays use a lot of power, such that the 
reduction in talk time for software encoding (at least at lower 
c) existing applications using H.264 variants (i.e. Hangouts) are in 
wide use using software encoding (to the best of my knowledge)

Mobile devices without HW encode may be limited by running out of CPU 
due to resolution & framerate.

Randell Jesup