IETF Logo Mail Archive

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

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 04 May 2012 22:56 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2646621F84CD for <rtcweb@ietfa.amsl.com>; Fri, 4 May 2012 15:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.714
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77LFuKRYpykL for <rtcweb@ietfa.amsl.com>; Fri, 4 May 2012 15:56:57 -0700 (PDT)
Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5C93321F84C8 for <rtcweb@ietf.org>; Fri, 4 May 2012 15:56:57 -0700 (PDT)
Received: from BLU169-W2 ([65.55.111.73]) by blu0-omc2-s27.blu0.hotmail.com 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: [131.107.0.69]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: dean.willis@softarmor.com
Date: Fri, 04 May 2012 15:56:55 -0700
Importance: Normal
In-Reply-To: <4FA3E48E.1050204@freedesktop.org>
References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc>, <A9FB11DB-8617-4ED6-BDB4-689FD5E7C0C7@softarmor.com>, <20120504104446.2d7b2715@lminiero-acer>, <CAOHm=4scg-+QnU2g_Tbmc1c615rrRO=oiUCAQ3nL4JORU+3Zmg@mail.gmail.com>, <4FA3E48E.1050204@freedesktop.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 May 2012 22:56:55.0815 (UTC) FILETIME=[34117170:01CD2A49]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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:
http://www.ehomeupgrade.com/2011/06/02/skype-certified-webcams-tote-built-in-720p-h-264-video-encoders/

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.

v2.23.0 | Report a Bug | By Email