Re: [rtcweb] H.261

Hrishikesh Kulkarni <rishi@turtleyogi.com> Wed, 27 November 2013 06:39 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 85D7D1AE166 for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 22:39:14 -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 osw1xxTMCGyx for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 22:39:10 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7071AE119 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 22:39:10 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id e14so11470824iej.0 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 22:39:09 -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=M7w2UZZbAio//84P0dug+wjA0yN/muw7+oIPYDYSJic=; b=lzXX076T33U7RaGQFb+RogzI9lbNvSSvhAZ6+etDYHeAF3bTfLi1T4oPPl6z7GHO1O N0+lZpayTjt/OTTV2pfLnVJJS35VBGW3mF69uuU4+3IfQnFUebHwPOyDgZWXjBQEaUzf wLj8/vqg/jz2SpS+wpPCJiMLNBWX1Wn+PAc+MNGCH7aJj87ETb0J0PT6kub/YSefblpI oyM99DZkhRv9L1i2Sa/vPiQ2ZH9Odt+RKYC4mCqjTmlhqVVJVAZvMuKFBFxvWq7Znl30 khdGEWpHk443jj+ztRAU8g36AxntstLqqQL7tMMVa86bZsmskd4YQzStZKZiOi29X7uz yekA==
X-Gm-Message-State: ALoCoQnQz/IdfCvS82zf9NTwIfZTqfU/kkeB7PCnHl89AbUh2uAIzKVPZS6QTwLO2UVo3zB5oQuV
MIME-Version: 1.0
X-Received: by 10.42.40.83 with SMTP id k19mr22240776ice.3.1385534349759; Tue, 26 Nov 2013 22:39:09 -0800 (PST)
Received: by 10.64.229.68 with HTTP; Tue, 26 Nov 2013 22:39:09 -0800 (PST)
X-Originating-IP: [115.113.11.220]
In-Reply-To: <CAOJ7v-0fwSrsT4CmTUP8cK7TJTA3J7LqDN0bbtNT4DxnQS6HnQ@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>
Date: Wed, 27 Nov 2013 12:09:09 +0530
Message-ID: <CALFWOz7XReU20aEbOVPvP4Q7KWUbGzbBedXE246b47HDWvzz6Q@mail.gmail.com>
From: Hrishikesh Kulkarni <rishi@turtleyogi.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="90e6ba1efbf4be160504ec22da00"
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 06:39:15 -0000

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@800kbps which
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
>
>