Re: [rtcweb] Stephan Wenger's choices

Tim Panton <tim@phonefromhere.com> Mon, 30 December 2013 19:47 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9A1AE21E for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 11:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm7N0bI00rba for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 11:47:45 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id B34B21AE1DE for <rtcweb@ietf.org>; Mon, 30 Dec 2013 11:47:44 -0800 (PST)
Received: (qmail 30838 invoked from network); 30 Dec 2013 19:47:38 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 5024
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 30 Dec 2013 19:47:38 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id F238918A04AA; Mon, 30 Dec 2013 19:47:37 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A4B0018A047A; Mon, 30 Dec 2013 19:47:37 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A4A2451-91C0-43ED-9100-76DC842623D9"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CABcZeBMZOhYvXvrFJkGTkpdnr1jGey4exC2=8h8oQVSouPwzRQ@mail.gmail.com>
Date: Mon, 30 Dec 2013 19:47:26 +0000
Message-Id: <C13A4510-0542-43EF-BC60-2DB4D47F5301@phonefromhere.com>
References: <52BF037D.4050706@googlemail.com> <CEE4479F.3E568%stewe@stewe.org> <20131228183148.GI3245@audi.shelbyville.oz> <CABcZeBOMEE9nOMzR2AisGQDTByrjsNms6qS4+DQvjUMUYyHCjw@mail.gmail.com> <20131228212423.GJ3245@audi.shelbyville.oz> <CABcZeBNwMPjGFZV08DV8ZFrJg0N+Lr8zD=CwUY2qxrCqw8MWdA@mail.gmail.com> <20131228230333.GK3245@audi.shelbyville.oz> <CABcZeBPBXT-4UqYyTVNjGBL5wo-n0qisMC2bj+=E115YQ8m8aQ@mail.gmail.com> <52C1B591.2010504@bbs.darktech.org> <CABcZeBMZOhYvXvrFJkGTkpdnr1jGey4exC2=8h8oQVSouPwzRQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1827)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Stephan Wenger's choices
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 30 Dec 2013 19:47:47 -0000

On 30 Dec 2013, at 18:33, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 2. Mobile devices on which we want to deploy WebRTC but which can't
> afford to run a modern codec in software but could perhaps use HW
> support (and perhaps could run some older codec).
> 
...
> The second category of elements would benefit from H.264 in the
> sense that they would be able to play video or have better battery
> life or whatever to the extent to which hardware is available and
> usable. The extent to which that's a benefit depends on how often
> that will be the case; I realize that a lot of people believe that will
> be rare, but the evidence I have seen so far seems pretty
> equivocal. Sure, if you think you will never be able to use
> HW acceleration for H.264, then this doesn't seem like a very
> good argument.

There is a subtle assumption there that hardware assist only applies to H264.
I notice that the raspberryPi gained experimental VP8 support using the video GPU
to accelerate it.
http://www.cnx-software.com/2013/01/26/raspberry-pi-now-has-experimental-support-for-vp6-vp8-mjpeg-and-ogg-theora-video-codecs/

What is especially interesting is that this didn't require any hardware changes,
so it may be that many existing 'H264 only' devices could follow suit if there was
a suitable motivation.

Tim.