Re: [rtcweb] H.261

cowwoc <> Sat, 23 November 2013 07:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D99C21AE135 for <>; Fri, 22 Nov 2013 23:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h6QyBpyVAKek for <>; Fri, 22 Nov 2013 23:24:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC2D61AE0EB for <>; Fri, 22 Nov 2013 23:24:03 -0800 (PST)
Received: by with SMTP id e14so3736079iej.14 for <>; Fri, 22 Nov 2013 23:23:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QjH4LLsYFxrUz6qQ/Cmvqt3WKCvxW5XgyVKGpc72eak=; b=N9CLgCgL/C0MlAjWuG84hW+UYp4bA+xTChiMeaK/oSAzDxxjFbXo7dHw3nL/qEjL2p 3uQzgsRDuOyz+MnvExLvjzeeVn+YM7ukIgRuJB7HdoNGzdEpNiQP4yrnAhDlKcCsfdj/ gXSGsKmpyUEENOYC4PMBoCzv3cOMzyiMDw7o8arZjQpBrsWd5ZK/iklFnB1mcpP+w5AI xoCg+Sq9yvmxXrZ1O3OKroEhSiuLsK1MpBekOC7jrOsk5W0ct5OCo54LRYi9tarbhlKx 6H8N7Cs7e0nCYFc6OkORzH5J/nnWPjanWH7kYT6+JYbJ3rmptDH1jF+zOY13UV/Epo4g UXHw==
X-Gm-Message-State: ALoCoQnbYl2jmWaSuxhObQyvLjnlaqbBynv7wgAvUX6byyBAXhNbxpaqN8AuY6TRZ65ZTivyL0Eo
X-Received: by with SMTP id j9mr5401728igj.52.1385191436277; Fri, 22 Nov 2013 23:23:56 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id qi3sm13282204igc.8.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 23:23:55 -0800 (PST)
Message-ID: <>
Date: Sat, 23 Nov 2013 02:23:23 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <20131123003548.GD3245@audi.shelbyville.oz> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 07:24:06 -0000


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