Re: [rtcweb] H.261

bryandonnovan@gmail.com Fri, 22 November 2013 17:06 UTC

Return-Path: <bryandonnovan@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 52BB91AE002 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level:
X-Spam-Status: No, score=-0.485 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, URIBL_RHS_DOB=1.514] autolearn=no
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 sbO2gCZCLdpq for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:06:46 -0800 (PST)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 964511ADFC6 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:06:46 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so1076893vcb.10 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:06:39 -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=MXhuTneusH15TvNCWYCxCF8VSBLuL9J+HsoIMztmRiY=; b=T1fKba/Zm5SsxPfp1p/L8wfJOQVqwT38aKWi/MoAjXjkaKztnrt6wvKnsgZQrQL0uZ gmfM7cWAoQMYeSvuCvzmy6H9qqSkXPY+HE1omUMH2qeW/0E4+NdwMj3LW80jY/tb95/4 GeWi4MGAv6uq0Q3E9wnrv/hQqVMLdLGHyKt5mW2d0G4c4iJ86QrDwvc1VW/EnngD1G8H 0K7Dv6ncqZ69Z+EnD7fp6tVvkqJr7xZVtBM81/kJh7CoCz0k2cPY7xgqYrWkk1fepynn 5phlx1jbOoTSWh7asNt6ihAktY1NSn5Si4T+1rYB6xWIQnK2yGxu69JZEpKRoDgiH6L2 AKGA==
MIME-Version: 1.0
X-Received: by 10.58.143.17 with SMTP id sa17mr12450631veb.14.1385139999306; Fri, 22 Nov 2013 09:06:39 -0800 (PST)
Received: by 10.52.231.233 with HTTP; Fri, 22 Nov 2013 09:06:39 -0800 (PST)
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: Fri, 22 Nov 2013 09:06:39 -0800
Message-ID: <CAMwTW+hidtQ1_Xsd7aCpjDiURwuxdoAEWV2cL5BtztLoUVpNZA@mail.gmail.com>
From: bryandonnovan@gmail.com
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=047d7b6d95ee9f7a8d04ebc70965
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: Fri, 22 Nov 2013 17:06:49 -0000

The point that I was making (perhaps not very clearly) is that in many use
cases, the common codec is much more important than that 30% number would
suggest.  My priority is having an efficient common video codec.  I would
transcode as a last resort.

Also, my concern with transcoding is not cost, but scalability.  I can find
a dedicated server for a couple hundred dollars per month that would give
me 100TB of bandwidth.  If I had to transcode, then I would run out of cpu
cycles long before I ran out of bandwidth.  If I only have to route packets
and transcrypt, then the balance between cpu and bandwidth allows much more
efficient resource utilization.

Perhaps the math on cpu vs bandwidth cost that you are referring to was
based on AWS -- I use dedicated hardware.


On Fri, Nov 22, 2013 at 8:53 AM, 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.
>
>
> 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
>>
>>
>