Re: [rtcweb] H.261

Stefan Slivinski <> Sun, 24 November 2013 08:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 404A91AE03B for <>; Sun, 24 Nov 2013 00:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1bVytohbLa81 for <>; Sun, 24 Nov 2013 00:18:06 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id E76FB1ADFEC for <>; Sun, 24 Nov 2013 00:18:05 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUpG2NCFqdNp50LEEQq2BIKQ/; Sun, 24 Nov 2013 00:17:58 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sun, 24 Nov 2013 02:10:32 -0600
From: Stefan Slivinski <>
To: Ron <>, "" <>
Date: Sun, 24 Nov 2013 02:10:30 -0600
Thread-Topic: [rtcweb] H.261
Thread-Index: Ac7o4BmbvmEFNmkISO2UMCfmUphuHQACcv3Q
Message-ID: <>
References: <> <> <> <> <20131123003548.GD3245@audi.shelbyville.oz> <> <> <> <> <> <20131124064011.GK3245@audi.shelbyville.oz>
In-Reply-To: <20131124064011.GK3245@audi.shelbyville.oz>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 08:18:08 -0000

I'm not suggesting H.261 in software is going to consume less power than H.264 720p in hardware but apples to apples in terms of resolution it's unlikely software is going to come out ahead in very many architectures.

It's not about changing the laws of physics, it's about cutting out what you don't need.  General purpose instruction sets don't necessarily map well to every algorithm, not to mention these hardware acceleration engines can put lots of on chip memory to limit how often they need to go to external memory, and generally speaking hardware acceleration engines run at much lower clock speeds than their host processors.

But don't take my word for it, intel and apple seem to think they saved power:

Comparison on hardware codec vs software codec

see: 'Fourth, there's battery life'

-----Original Message-----
From: rtcweb [] On Behalf Of Ron
Sent: Saturday, November 23, 2013 10:40 PM
Subject: Re: [rtcweb] H.261

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 :)


rtcweb mailing list