Re: [rtcweb] H.261

Stefan Slivinski <> Sat, 23 November 2013 01:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60CCB1AE1E8 for <>; Fri, 22 Nov 2013 17:47:26 -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 MN1NhuGzAIHP for <>; Fri, 22 Nov 2013 17:47:24 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 3BFD71AE1E6 for <>; Fri, 22 Nov 2013 17:47:24 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUpAJJc6S41xVns1DXqD6Dqnga6/; Fri, 22 Nov 2013 17:47:17 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 19:42:47 -0600
From: Stefan Slivinski <>
To: "" <>
Date: Fri, 22 Nov 2013 19:42:45 -0600
Thread-Topic: [rtcweb] H.261
Thread-Index: Ac7n7LVNloYMpb4+Sb6txwPc2SuobQAADMwQ
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: Sat, 23 Nov 2013 01:47:26 -0000

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.

rtcweb mailing list