Re: [rtcweb] H.261

Stefan Slivinski <> Sun, 24 November 2013 04:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C7EA01AD942 for <>; Sat, 23 Nov 2013 20:34:05 -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 qwscjykYr1dA for <>; Sat, 23 Nov 2013 20:34:02 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id C0B5E1AD939 for <>; Sat, 23 Nov 2013 20:34:02 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Sat, 23 Nov 2013 20:33:55 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sat, 23 Nov 2013 22:29:42 -0600
From: Stefan Slivinski <>
To: cowwoc <>, "" <>
Date: Sat, 23 Nov 2013 22:29:39 -0600
Thread-Topic: [rtcweb] H.261
Thread-Index: Ac7oHPx3wpNzlAGkTV2LmwG1ru8OlgAq6Nvw
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: Sun, 24 Nov 2013 04:34:05 -0000

I don't want to make any assumptions as to why their particular use case failed at 20+ participants.  Maybe it was bandwidth related, maybe it was because intel quicksync doesn't support VP8.  I don't know and I'm not going to speculate.  What I do know is intel quicksync is capable of decoding H.264 at 4K without breaking a sweat.  4K is more than 80x (yes, eighty times) the resolution of H.261.  So H.261 isn't likely to have helped them here.

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.  

H.261 does not have any technical advantage whether it be bitrate, performance, power consumption or otherwise over H.264 on any modern media processor

-----Original Message-----
From: rtcweb [] On Behalf Of cowwoc
Sent: Friday, November 22, 2013 11:23 PM
Subject: Re: [rtcweb] H.261


At the conference, they mentioned that you cannot implement online video classes (with 20+ participants) unless you reduce the resolution and frame rate of non-speakering participants. Meaning, even without having to do any transcoding (they use VP8 across the board) there is insufficient bandwidth and CPU to handle 20 incoming video streams at HD resolutions. So what you do is host non-speakers at tiny resolutions and
3 fps.

H.261 could handle those non-speakers just fine (in fact, it would be preferable as it reduces CPU usage). Furthermore, if you chose to transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, the use of H.261 or transcoding is not the bottleneck.


On 22/11/2013 8:42 PM, Stefan Slivinski wrote:
> Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is:
> Let's say through some divine miracle we manage to all agree to make H.261 the one and only MTI codec.  The rationale being of course that no one will ever use it because it is of course terrible, but we need it to get around those pesky patent/license terms with VP8/H.264 respectively.
> Alright fast forward, Chrome adds H.261 but continues to use VP8.  IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264 and VP8.  So far so good.  Chrome can talk using VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone.  As long as Chrome users don't try to call IE or Safari, we're in good shape, otherwise we need to transcode using some undefined cloud based transcoder service or just use H.261.
> So we're still in good shape.  Now let's consider the multiway case.  I heard a use case at the conference on Tuesday where a university was using webrtc to enable video online classes.  So let's assume there are 20 people in the class.  19 people in the class love Chrome, so they join the class from chrome and are all sending each other VP8.  But of course there's always one person that has to be difficult and they decide they prefer IE.  So what now?   Well the IE person doesn't understand any of the 19 VP8 streams and the 19 chrome users don't understand the 1 H.264 stream.  So we can now utilize that same undefined cloud transcoding service to convert each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H.261.
> My guess is H.261 is going to get used a lot more than anyone thinks.
> -----Original Message-----
> From: rtcweb [] On Behalf Of Adam Roach
> Sent: Friday, November 22, 2013 5:37 PM
> To: Ron;
> Subject: Re: [rtcweb] H.261
> On 11/22/13 18:35, Ron wrote:
>> The whole point of many distros is to supply binaries, often built 
>> many times for many different system architectures.
> And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded.
> I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier.
> /a
> _______________________________________________
> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list

rtcweb mailing list