Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF

Bernard Aboba <> Fri, 04 May 2012 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2646621F84CD for <>; Fri, 4 May 2012 15:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.714
X-Spam-Status: No, score=-100.714 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 77LFuKRYpykL for <>; Fri, 4 May 2012 15:56:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5C93321F84C8 for <>; Fri, 4 May 2012 15:56:57 -0700 (PDT)
Received: from BLU169-W2 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 15:56:55 -0700
Message-ID: <BLU169-W20EE1AD0881F6C8F48B31932C0@phx.gbl>
Content-Type: multipart/alternative; boundary="_0b5b1707-703a-4d7c-9fde-6b8eefcb3b86_"
X-Originating-IP: []
From: Bernard Aboba <>
Date: Fri, 04 May 2012 15:56:55 -0700
Importance: Normal
In-Reply-To: <>
References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc>, <>, <20120504104446.2d7b2715@lminiero-acer>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 May 2012 22:56:55.0815 (UTC) FILETIME=[34117170:01CD2A49]
Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF
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: Fri, 04 May 2012 22:56:58 -0000

> I am more worried about the guy implementing a WebRTC security camera
> that uses an embedded Linux kernel and a software video encoder. Each
> unit might "produce" video 24x7. But there is no MPEG-LA licensed
> browser or OS or encoder chip to fall back on. The whole product might
> sell for less than it might cost him to license the codec.

[BA]  We are rapidly moving toward inclusion of hardware video encode/decode by default on battery-powered devices (mobile handsets, tablets, etc.). 

Since software encode/decode is processor (and battery) intensive, the latest generation of webcams have video encode/decode built-in.  For example, see:

When handled purely in software, it is quite difficult to enable video sessions of substantial duration without draining the battery.   

While my assumption is that hardware support for encode/decode will become less codec-specific over time,  that is typically not the case today.