Re: [rtcweb] H.261 Sat, 23 November 2013 15:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F32EC1ADF10 for <>; Sat, 23 Nov 2013 07:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwPnhr2sd_sP for <>; Sat, 23 Nov 2013 07:00:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::22a]) by (Postfix) with ESMTP id 04E6E1ADEBA for <>; Sat, 23 Nov 2013 07:00:53 -0800 (PST)
Received: by with SMTP id ht10so1713325vcb.29 for <>; Sat, 23 Nov 2013 07:00:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=97vAgmupEqi9Myle555W1eT0zcpfq8ceYBljKAShlg4=; b=zzHTzj6mQhxld7k6YFd9Mgl3jOnHxlvskCU4uny2S1i5RmcDU8XNXEWRcOE/IapTP8 8Pjqbhs3RmCpdB66tDInUcrQPg6HPr1gxa0qVxY0UzkwkitQts40OGhsiWvh+OoJgyK7 0aQlAIK9Y5l8NCoidVkdj0m+Shm2CMWvE2Vj+Fs17wcT6soTV8TL4SDB5w82PhwFWfzj QNObX4SP3SK728NblTOGeF6sBm5B9I8u6YFYOD/hFhsCJ/6xgC1xnVFFkQRkc/AIrEac Gs3FWI3LTsA1NShgNCiGZN+9REMvK2QLf8xsq25c2i9Q+q21X4hPGaLLENXkjMSdTkja J06g==
MIME-Version: 1.0
X-Received: by with SMTP id ef2mr17212968vcb.7.1385218846214; Sat, 23 Nov 2013 07:00:46 -0800 (PST)
Received: by with HTTP; Sat, 23 Nov 2013 07:00:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <20131123003548.GD3245@audi.shelbyville.oz> <> <> <>
Date: Sat, 23 Nov 2013 07:00:46 -0800
Message-ID: <>
To: cowwoc <>
Content-Type: multipart/alternative; boundary="001a1132e6e243cded04ebd96564"
Cc: "" <>
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 15:00:57 -0000


Large group conferences, classes, seminars, etc., typically have 1 person
sending and N persons receiving -- at least where my product is concerned.
 This is 1:N, not mesh conferencing.  My original point, the one that
Stefan said he was agreeing with, was to do with the fact that you would
always be using the common codec when you have multiple people receiving
the same video stream on different browsers, unless you wanted to transcode
the video.  Granted, this would be 1 transcode for each sending stream, not
1 transcode for each receiver, so the cost is not terrible.

On Fri, Nov 22, 2013 at 11:23 PM, cowwoc <> wrote:

> Stefan,
> 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.
> Gili
> 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