Re: [rtcweb] H.261

Ron <> Sun, 24 November 2013 06:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A537C1AE00B for <>; Sat, 23 Nov 2013 22:40:47 -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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LE3NZf1GPmwI for <>; Sat, 23 Nov 2013 22:40:46 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by (Postfix) with ESMTP id 11A4D1ADFE3 for <>; Sat, 23 Nov 2013 22:40:45 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 24 Nov 2013 17:10:15 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 015634F8F3 for <>; Sun, 24 Nov 2013 17:10:13 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id E9D1tRaFd8ih for <>; Sun, 24 Nov 2013 17:10:11 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 5C0084F902; Sun, 24 Nov 2013 17:10:11 +1030 (CST)
Date: Sun, 24 Nov 2013 17:10:11 +1030
From: Ron <>
Message-ID: <20131124064011.GK3245@audi.shelbyville.oz>
References: <> <> <> <> <20131123003548.GD3245@audi.shelbyville.oz> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.261
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: Sun, 24 Nov 2013 06:40:47 -0000

On Sun, Nov 24, 2013 at 08:02:36AM +0200, Leon Geyser wrote:
> If we fallback to a software H.261 encoder/decoder then will it really use
> so much CPU that devices will be unusable or the battery will deplete
> early?

No, it won't.  You're pretty much certain to get better battery life
doing software H.261 than hardware H.264 on all but the most retarded
of architectures (ie. something with _no_ powersaving ability at all).
And both of them pale into insignificance against the power your
display will use.

tldr;  something that take 100x more operations to perform _still_
takes ~100x more operations to perform, and about the same amount of
power, regardless of whether it's run on a "custom processor" (aka
'hardware acceleration') or a general purpose processor (aka CPU).

If you want it to actually go faster too, that will generally use
MORE power, not less.  Ye cannae change the laws o' physics.

Nobody who has actually measured this, or understands anything about
the details of it peddles this kind of snake oil about hardware accel.

> I didn't know that H.261 was so CPU intensive...

It's so CPU intensive that it ran on phones from 25 years ago ...

So I guess we can add "power saving and longer battery life" to
the list of pros for H.261, and reasons someone might deliberately
choose to use it, even if other options are available!

If we keep thinking, the list just keeps growing :)