Re: [rtcweb] H.261
Hrishikesh Kulkarni <rishi@turtleyogi.com> Wed, 27 November 2013 07:26 UTC
Return-Path: <rishi@turtleyogi.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 72A781AE159 for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 23:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Wpt06FaQ734S for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 23:26:53 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA921AE115 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 23:26:53 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id x13so10882915ief.6 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 23:26:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rH0sMFQdQx2zcmcJ5/pAeNzh4J2R0bAity3B1Yq0qTM=; b=Ya0OvsqHbu81RHw3iBXidGtHnWBxOGLI4kEwiAYCFsrbwY7lwmXOOWuC05EMw0wxsZ PIut/Ng0k79SfVmNizNW/rIeeKBQb7wdaTmUINs2/aXPAtB/kJQPM/akLcXG2fDkaI5M p90TLQJ4qm+8P8p6+ZS5bCO2LY4aLSud4TE76Y1jj2rEkB/COjLNs/bMKVzz+QwraxPQ za+wqvpr+wb4ygKEN6PSrIoagTtzIX5DdBQoPWY+DuXqfb9iuMJxeS6hRW4ggkBP5hFM OYvDH3Pq7EdCucsyGhy/9v1yw4Uhnm41pLYj2OhvVE1fKOjSXiRPcmJ9s6RAXvob4fLZ N7Lw==
X-Gm-Message-State: ALoCoQkrzyYvv2bm+hOir5Ry0UEDldF5Brx1WBAxhObItOv2XoIMXtpSLD9+I5I2XyrJrSYE5dKT
MIME-Version: 1.0
X-Received: by 10.42.82.196 with SMTP id e4mr4273603icl.58.1385537213233; Tue, 26 Nov 2013 23:26:53 -0800 (PST)
Received: by 10.64.229.68 with HTTP; Tue, 26 Nov 2013 23:26:53 -0800 (PST)
X-Originating-IP: [14.139.157.28]
In-Reply-To: <CAGgHUiSsWH70q9F9bKXtjMA9Ht63HgAvxK+RBeZgPWsL=jsZDw@mail.gmail.com>
References: <CEB4350B.1E7B2%mzanaty@cisco.com> <CEB43444.4986F%stevek@stevek.com> <CAMwTW+jO-BQh00fmH-ueCNsVsHbHRCiwHt6X0jFbho-B89ag=Q@mail.gmail.com> <CAOJ7v-0fwSrsT4CmTUP8cK7TJTA3J7LqDN0bbtNT4DxnQS6HnQ@mail.gmail.com> <CALFWOz7XReU20aEbOVPvP4Q7KWUbGzbBedXE246b47HDWvzz6Q@mail.gmail.com> <CAGgHUiSsWH70q9F9bKXtjMA9Ht63HgAvxK+RBeZgPWsL=jsZDw@mail.gmail.com>
Date: Wed, 27 Nov 2013 12:56:53 +0530
Message-ID: <CALFWOz44jyB=5nXYNQBtEpUrMgXfD8GGMXW87VeaVMWu-o_5Qw@mail.gmail.com>
From: Hrishikesh Kulkarni <rishi@turtleyogi.com>
To: Leon Geyser <lgeyser@gmail.com>
Content-Type: multipart/alternative; boundary="20cf30363fa16b134004ec23850d"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Wed, 27 Nov 2013 07:26:56 -0000
In that case the source endpoint/browser needs the bandwidth/compute to produce many encode streams (different codecs/bitrate). I would rather the MCU handle the transcoding/transrating. On Wed, Nov 27, 2013 at 12:25 PM, Leon Geyser <lgeyser@gmail.com> wrote: > Why not just run the codec at the same bitrates that the other codecs > would of been using anyway? That wouldn't increase the costs of bandwidth. > > > On 27 November 2013 08:39, Hrishikesh Kulkarni <rishi@turtleyogi.com>wrote: > >> On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti <juberti@google.com>wrote: >> >>> For 1:many with MCU, I don't understand why you wouldn't do #2, i.e. >>> transcode. As stated earlier, the bandwidth costs of using an inefficient >>> codec (which any MCU service will incur) exceed the CPU cost of transcode. >>> >> >> Good point on bandwidth costs. But you need to transcode if the decoding >> endpoints/browsers dont support the codec or the bitrate of the source. >> This applies to audio and video. If the source video is 720p@800kbpswhich could then "transrated" into multiple bitrates at 500kbps or >> downsized to 480p@300kbps. We did this for audio when Chrome was on isac >> and Firefox was on opus. >> >> >>> >>> >>> On Fri, Nov 22, 2013 at 4:47 AM, <bryandonnovan@gmail.com> wrote: >>> >>>> Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this >>>> case. My use of WebRTC involves 1:many group calls in the browser with an >>>> MCU. For 1:many, the options are 1) fallback to common codec and 2) >>>> transcode. So, for 1:many we can say that the chance of using the fallback >>>> codec is 100%. Assuming IE and Safari actually ship WebRTC. >>>> >>>> >>>> >>>> On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.com> wrote: >>>> >>>>> >>>>> Mo, >>>>> >>>>> I think we all agree that choosing H.264 or VP8 would be better, but >>>>> it is clear that neither option today has consensus. Circumstances could >>>>> change in the future, but it seems that OpenH264 was not enough to change >>>>> that circumstance. >>>>> >>>>> I think that where your scenario might go astray is that users won’t >>>>> associate their poor experience with “WebRTC”, or “that web stuff” — they >>>>> will associate it with the brand of the service which they are using at the >>>>> time. >>>>> >>>>> So, for example, if Facebook builds video chat using WebRTC, and they >>>>> do no transcoding, 30% of users might associate their poor video with >>>>> Facebook, but most of them won’t call it “that web shit” — they would say >>>>> Facebook video sucks. >>>>> >>>>> Of course, Facebook could decide to transcode 30% of the time, in >>>>> which case the user would have a different experience. >>>>> >>>>> Facebook obviously just being used as an example service which might >>>>> implement WebRTC video. >>>>> >>>>> -SteveK >>>>> >>>>> >>>>> >>>>> From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> >>>>> Date: Thursday, November 21, 2013 at 9:17 PM >>>>> To: Basil Mohamed Gohar <basilgohar@librevideo.org> >>>>> Cc: "rtcweb@ietf.org" <rtcweb@ietf.org> >>>>> Subject: [rtcweb] H.261 >>>>> >>>>> On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> >>>>> wrote: >>>>> >>>>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>>>> >>>>> >>>>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >>>>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to >>>>> various (incredibly extrapolated, possibly inaccurate and sometimes >>>>> conflicting) sources [1] on who uses what browser, the chance of H.261 >>>>> fallback is a whopping 30% [2]. Not the minor insignificant case some had >>>>> assumed. >>>>> >>>>> How will these users react to H.261 QCIF/CIF compared to what they use >>>>> today, say Skype for example? "This web shit really sucks. I’m going back >>>>> to Skype and never trying it again." Is that the first (and perhaps last) >>>>> impression we want from users that try webrtc? Those arguing crappy video >>>>> is better than no video are ignoring the critical importance of first >>>>> impressions. While some may accept crappy video as usable, many more may be >>>>> permanently turned off and tune out even faster than if they got only >>>>> (good) audio. It’s not as if webrtc is the only game in town. Users have >>>>> options, so it needs to be competitive with competitive technology which >>>>> has already set the bar. >>>>> >>>>> We previously narrowed the options down to H.264 and VP8 for good >>>>> reasons over the course of this excruciatingly long decision. Reopening >>>>> discarded tangents like H.261 does not move us forward as a workgroup, and >>>>> certainly does not move webrtc forward as a technology. >>>>> >>>>> Mo >>>>> >>>>> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers >>>>> [2] H.261 fallback % = 2 x VP8-only% x H.264-only% = 2 x Chrome% x >>>>> (IE% + Safari%) >>>>> >>>>> _______________________________________________ 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 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