Re: [rtcweb] H.261

bryandonnovan@gmail.com Fri, 22 November 2013 12:48 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 3A67E1AD9B8 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 04:48:05 -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 ptAvvisgHG-Q for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 04:48:02 -0800 (PST)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5B61C1AD9AD for <rtcweb@ietf.org>; Fri, 22 Nov 2013 04:48:02 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so850040veb.15 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 04:47:55 -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=S/Lmn57l1wbylj3CvD/vs3CVI7MlxF6W3e6nwQP7Yw8=; b=nJmpRatXS9wzMg5cAx/t4RDl1236sNIrOSeI+2bSzd7Wa3378jzuEoW7zO2LEGOac8 3+h29WexEbN4cWkZ57IJOFmKuH93oWXClwQ8v0UA7B0QEQ8cvMYI6BSkMAMq1ps/a3ff bE5u2SOmFGPFduKnwyNOkg+/XEJwYfE2E/Is41Z1OhL83T/XXjwHEanbcRR5xHUgYk1h faqLrZEdqM5Ue7gYfwGEvYHywpKbd9qHeVsq9FJMYEV6YfIk3jDHvyL77I2sRijvKg9r x2ouG4oZc2KdrLB/8kKzn1kDws1KN6/S+UNL2Rr1f62iw1FxPIfnpfzptKBFO8QvStfG yzmQ==
MIME-Version: 1.0
X-Received: by 10.52.166.200 with SMTP id zi8mr465553vdb.38.1385124475129; Fri, 22 Nov 2013 04:47:55 -0800 (PST)
Received: by 10.52.231.233 with HTTP; Fri, 22 Nov 2013 04:47:55 -0800 (PST)
In-Reply-To: <CEB43444.4986F%stevek@stevek.com>
References: <CEB4350B.1E7B2%mzanaty@cisco.com> <CEB43444.4986F%stevek@stevek.com>
Date: Fri, 22 Nov 2013 04:47:55 -0800
Message-ID: <CAMwTW+jO-BQh00fmH-ueCNsVsHbHRCiwHt6X0jFbho-B89ag=Q@mail.gmail.com>
From: bryandonnovan@gmail.com
To: Steve Kann <stevek@stevek.com>
Content-Type: multipart/alternative; boundary=089e01634aa64f5a5a04ebc36c98
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 12:48:05 -0000

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
>
>