Re: [rtcweb] H.261

Maik Merten <maikmerten@googlemail.com> Fri, 22 November 2013 17:06 UTC

Return-Path: <maikmerten@googlemail.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 62B551AE04C for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.486
X-Spam-Level:
X-Spam-Status: No, score=-0.486 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, 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 9kUgQNf6hHnk for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:06:26 -0800 (PST)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1761AE002 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:06:26 -0800 (PST)
Received: by mail-ee0-f49.google.com with SMTP id c41so614592eek.36 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:06:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uLcQ4X5vXtmP+F9xrw+U6SSGSceWejbYV6vziJYmQB0=; b=XTDhe+p/K0RQ9nICZ7T1zobxxpklLYF/3KL0GG6eoreslQ3qHEBEkln0HGD02n57/v 3q/bHb8bk9bAmjkBc3g0RHhP755rZ63x/BafGFLLx6fn5+MbV72HsO0OMpVfCL5/Qkb6 T/fP40f/7NIAtDXVdvk8bIiGEqb0iX+xMoW0PsyXzP/UGvWTHQy300YjeLYxtb2F9dF+ u2ZGh+sJJKcCiBlTEDoxRsxZlPcxeuW/FY9C/bcH6WeftkPBeqfn5HqOblbFDh9ShGRv 4RGG/1kojcADDCFf8KJH32sXpLBB8LYn9scwnpRoO2HeedPsdM7J+p9Fv3wol2xgYBeG jhWw==
X-Received: by 10.14.199.1 with SMTP id w1mr17864853een.29.1385139978688; Fri, 22 Nov 2013 09:06:18 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id a45sm62019707eem.6.2013.11.22.09.06.16 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 09:06:17 -0800 (PST)
Message-ID: <528F8F05.2040800@googlemail.com>
Date: Fri, 22 Nov 2013 18:06:13 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
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>
In-Reply-To: <CAOJ7v-0fwSrsT4CmTUP8cK7TJTA3J7LqDN0bbtNT4DxnQS6HnQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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:28 -0000

The best way to not run into bandwidth problems is *not* to go for 
transcoding. After all, all those video calls need to go through your 
transcoding infrastructure, directing all the traffic your way.

In P2P scenarios there's a much much higher chance of traffic finding a 
nice and direct route.

And talking about H.261: We're talking about video in the range of 0.2 
to 0.8 Mbps. Compression efficiency per-pixel certainly leaves much to 
be desired, but we're talking CIF resolution here.


Maik


Am 22.11.2013 17:53, schrieb Justin Uberti:
> 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
> <mailto: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
>     <mailto: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
>         <mailto:mzanaty@cisco.com>>
>         Date: Thursday, November 21, 2013 at 9:17 PM
>         To: Basil Mohamed Gohar <basilgohar@librevideo.org
>         <mailto:basilgohar@librevideo.org>>
>         Cc: "rtcweb@ietf.org <mailto:rtcweb@ietf.org>" <rtcweb@ietf.org
>         <mailto:rtcweb@ietf.org>>
>         Subject: [rtcweb] H.261
>
>             On 11/21/13 12:48, Basil Mohamed Gohar
>             <basilgohar@librevideo.org
>             <mailto: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 <mailto:rtcweb@ietf.org>
>             https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>