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 >
- [rtcweb] H.261 Mo Zanaty (mzanaty)
- Re: [rtcweb] H.261 Leon Geyser
- Re: [rtcweb] H.261 Steve Kann
- Re: [rtcweb] H.261 bryandonnovan
- Re: [rtcweb] H.261 Justin Uberti
- Re: [rtcweb] H.261 Maik Merten
- Re: [rtcweb] H.261 bryandonnovan
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Martin Thomson
- Re: [rtcweb] H.261 Maik Merten
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Maik Merten
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Martin Thomson
- Re: [rtcweb] H.261 Daniel-Constantin Mierla
- Re: [rtcweb] H.261 David Singer
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Eric Rescorla
- Re: [rtcweb] H.261 Basil Mohamed Gohar
- Re: [rtcweb] H.261 Daniel-Constantin Mierla
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Maik Merten
- Re: [rtcweb] H.261 Basil Mohamed Gohar
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Basil Mohamed Gohar
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 David Singer
- Re: [rtcweb] H.261 Basil Mohamed Gohar
- Re: [rtcweb] H.261 David Singer
- Re: [rtcweb] H.261 David Singer
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Lorenzo Miniero
- Re: [rtcweb] H.261 Bjoern Hoehrmann
- Re: [rtcweb] H.261 Steve Kann
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Eric Rescorla
- Re: [rtcweb] H.261 Mo Zanaty (mzanaty)
- [rtcweb] Opinions are fine, bypassing a vote is n… cowwoc
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Lorenzo Miniero
- Re: [rtcweb] Opinions are fine, bypassing a vote … Eric Rescorla
- Re: [rtcweb] H.261 bryandonnovan
- Re: [rtcweb] Opinions are fine, bypassing a vote … Stefan Slivinski
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] Opinions are fine, bypassing a vote … Ron
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Lorenzo Miniero
- Re: [rtcweb] H.261 Daniel-Constantin Mierla
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Daniel-Constantin Mierla
- Re: [rtcweb] H.261 Eric Rescorla
- Re: [rtcweb] H.261 Daniel-Constantin Mierla
- Re: [rtcweb] H.261 - taking a longer view of thin… Ron
- Re: [rtcweb] H.261 - taking a longer view of thin… Martin Thomson
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 - taking a longer view of thin… Ron
- Re: [rtcweb] H.261 - taking a longer view of thin… Ron
- Re: [rtcweb] H.261 Leon Geyser
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Maik Merten
- Re: [rtcweb] H.261 Florian Weimer
- Re: [rtcweb] H.261 Florian Weimer
- Re: [rtcweb] H.261 - taking a longer view of thin… cowwoc
- Re: [rtcweb] Opinions are fine, bypassing a vote … cowwoc
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 David Singer
- Re: [rtcweb] H.261 - taking a longer view of thin… cowwoc
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Stefan Slivinski
- Re: [rtcweb] H.261 Cullen Jennings (fluffy)
- Re: [rtcweb] H.261 Cullen Jennings (fluffy)
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Stephan Wenger
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Hrishikesh Kulkarni
- Re: [rtcweb] H.261 Leon Geyser
- Re: [rtcweb] H.261 Hrishikesh Kulkarni
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Cullen Jennings (fluffy)
- Re: [rtcweb] H.261 tim panton
- Re: [rtcweb] H.261 tim panton
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Stephan Wenger
- Re: [rtcweb] H.261 tim panton
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Eric Rescorla
- Re: [rtcweb] H.261 tim panton
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Eric Rescorla
- Re: [rtcweb] H.261 cowwoc
- Re: [rtcweb] H.261 Engel Nyst
- Re: [rtcweb] H.261 Ron
- Re: [rtcweb] H.261 Adam Roach
- Re: [rtcweb] H.261 Basil Mohamed Gohar
- Re: [rtcweb] H.261 Randell Jesup