Re: [rtcweb] H.261

Stefan Slivinski <> Mon, 25 November 2013 02:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 31D4B1A1DFA for <>; Sun, 24 Nov 2013 18:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U5Uu__n6PEbo for <>; Sun, 24 Nov 2013 18:28:40 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 004741A1F1B for <>; Sun, 24 Nov 2013 18:28:39 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUpK11+zLpQi8iTOJvA/; Sun, 24 Nov 2013 18:28:40 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sun, 24 Nov 2013 20:21:49 -0600
From: Stefan Slivinski <>
To: Maik Merten <>, "" <>
Date: Sun, 24 Nov 2013 20:21:46 -0600
Thread-Topic: [rtcweb] H.261
Thread-Index: Ac7o9VigiG9QHbpBQw68m1ooDQMzOwAjWd1Q
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <20131123003548.GD3245@audi.shelbyville.oz> <> <> <> <> <>
In-Reply-To: <>
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: Mon, 25 Nov 2013 02:28:42 -0000

All good points.  3rd party support is inconsistent, there are platforms that play nice and others that don't.  It's definitely a problem but in theory everyone could support exposing an API to hardware acceleration.  Typically error resiliency is half-hearted, generally these engines were designed for playing movies or recording videos where packet loss is impossible.  Most of the time issues can be fixed with a firmware upgrade.  As for decoding several streams in parallel, the short answer is no.  some architectures have multiple hardware acceleration engines (TI omap as an example) where this is possible, otherwise it's serial but if you are decoding say 720p30 on a hardware acceleration engine that can do up to 4Kp30 then you can do 9 720p30 streams by decoding one frame for each stream as they arrive.  Managing all the 9 independent streams will usually have some hit to performance in order to page context information in/out of memory so maybe 8 streams is more realistic.

I don't know about skype on every platform, I know one of our products supports skype and we do all the encode/decode in hardware but that's just once example.  But one thing skype didn't do was use H.261.

-----Original Message-----
From: rtcweb [] On Behalf Of Maik Merten
Sent: Sunday, November 24, 2013 1:13 AM
Subject: Re: [rtcweb] H.261

Am 24.11.2013 05:29, schrieb Stefan Slivinski:
> What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.264 to their chips.  Purpose designed hardware will always be faster and require less power than software implementations and no one is spending anything supporting H.261 hardware acceleration.

It appears that these hardware accelerators are usually not accessible to 3rd-party applications on mobile platforms (as has been discussed before). Even if they are they may not be consistent regarding available settings and performance. Can hardware accelerators, e.g., decode several incoming streams in parallel (honest question, I really don't know)? How does bitrate control of the embedded encoders behave? Do they offer options for error resilience etc. etc.?

IIRC it has been confirmed on this list that Skype deploys H.264 in software across all platforms for such reasons. So clearly, the theoretical advantages of H.264 hardware support (which works nicely in media playback, no doubt) do clearly not transfer quite easily to real-time communication on consumer devices. Given that older codecs currently in discussion are much more frugal in terms of overall computation, deployments in software don't look especially intimidating.

rtcweb mailing list