Re: [rtcweb] H.261

Stefan Slivinski <> Sat, 23 November 2013 04:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E0901AD8F9 for <>; Fri, 22 Nov 2013 20:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i7kLU-2rPTMi for <>; Fri, 22 Nov 2013 20:05:26 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 237621AD939 for <>; Fri, 22 Nov 2013 20:05:26 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 22 Nov 2013 20:05:19 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 21:58:41 -0600
From: Stefan Slivinski <>
To: "Hervé W." <>, "" <>
Date: Fri, 22 Nov 2013 21:58:39 -0600
Thread-Topic: [rtcweb] H.261
Thread-Index: Ac7n+cohOgYLaem6T+62nsqP+AkzeAABcH2Q
Message-ID: <>
References: <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <20131123003548.GD3245@audi.shelbyville.oz>, <>, <> <DUB127-W71B7CA024B49E316DAE0E9E0E30@phx.gbl>
In-Reply-To: <DUB127-W71B7CA024B49E316DAE0E9E0E30@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
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 04:05:29 -0000

yes, it appears I missed that....Byran Donnovan's point is exactly in line with my comment here, even a small sized multiway conferences has a high likelihood of dissimilar browsers and will either require a transcoding MCU or they will be forced down to a common codec.

-----Original Message-----
From: Hervé W. [] 
Sent: Friday, November 22, 2013 7:12 PM
To: Stefan Slivinski;
Subject: RE: [rtcweb] H.261

> From:

> 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.

Either you need the fallback codec or no one will ever use it. They can't both be right. I realise that you're illustrating that exact point below, but you're misrepresenting the rationale behind h.261, I think.

> 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.

Yes, they can offer an extra H.261 stream to that IE user and receive a H.261 stream from them. And then watch H.261 play about as well as the 18 other P2P streams, while they clog up their Wifi and overheat their laptops ?
I think you've found a scenario that might benefit from No MTI; audio only or no streams to/from the IE user can't hurt network performance.

> My guess is H.261 is going to get used a lot more than anyone thinks.

related to that:

- Hervé