Re: [rtcweb] H.261

Leon Geyser <lgeyser@gmail.com> Sun, 24 November 2013 06:02 UTC

Return-Path: <lgeyser@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4C1ADF7D for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 22:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgTR9outm8SO for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 22:02:45 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06A1ADF6B for <rtcweb@ietf.org>; Sat, 23 Nov 2013 22:02:44 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id eo20so2046168lab.14 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 22:02:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aT4acpXts/hwtkVedLp1J5nHOiguO9qhHb4eyI+0Nds=; b=Hp6GAnKkB7Bd889oqRGlnI7Lrg4WxaVAX1JoLGqH2CfCnRPlaAjbQqwSnQHJM7CEkr 8MIQ5dq3Qxy0BHvJdpntTeptB/q3kBg6YtdCmf+lgv3bn2mGX/4G6W6LFqGB7OOA9Qjx 6SSmdnilo4feF8Ghtwr9ct1IDcF1Od706CPlCyZgAe2RAMVfQqpXhx8hSBvY75oaICZa 5t9FZseF37NJkWGliA1/AruwrpQi8/PWFfOb1a+3sdP9sCo5VPqXWEG3wKbLBfEQtzcT QjtpbjRrO4wW+mpWHj/K5vrSUE79RAX7RywI6qcix4zGHFvdUqEqQpTtUIw37UB7j9kN R6bw==
MIME-Version: 1.0
X-Received: by 10.112.154.129 with SMTP id vo1mr131332lbb.31.1385272956693; Sat, 23 Nov 2013 22:02:36 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Sat, 23 Nov 2013 22:02:36 -0800 (PST)
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com>
References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <CE523335-0146-4FA5-A735-1EB4A8B3F1EF@apple.com> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com>
Date: Sun, 24 Nov 2013 08:02:36 +0200
Message-ID: <CAGgHUiTE31Fes8Dhw5ZttfxhonzyTd_x0Vt-jLh2+C3U+mkVDw@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=089e0115fb0880332004ebe5fe76
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2013 06:02:48 -0000

If we fallback to a software H.261 encoder/decoder then will it really use
so much CPU that devices will be unusable or the battery will deplete
early? I didn't know that H.261 was so CPU intensive...
I also agree with Ron that we shouldn't make a codec like H.264 mandatory
that will anyway be obsoleted by the next best thing in the future.


On 24 November 2013 06:29, Stefan Slivinski <sslivinski@lifesize.com>; wrote:

> 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 [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
> Sent: Friday, November 22, 2013 11:23 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] H.261
>
> 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 [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach
> > Sent: Friday, November 22, 2013 5:37 PM
> > To: Ron; rtcweb@ietf.org
> > 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@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>