Re: [rtcweb] Making both VP8 and H264 MTI

cowwoc <cowwoc@bbs.darktech.org> Wed, 06 November 2013 01:59 UTC

Return-Path: <cowwoc@bbs.darktech.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D125A11E8163 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 17:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level:
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL4cHIT4fiyF for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 17:59:24 -0800 (PST)
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id C0FCE21E80CD for <rtcweb@ietf.org>; Tue, 5 Nov 2013 17:59:16 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id u16so16106612iet.4 for <rtcweb@ietf.org>; Tue, 05 Nov 2013 17:59:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=sRjzyK+f4+wNSwi8JVamPAE+Ezo96iKdBBpHtnihuTo=; b=Rmn5kNTJ7fLH8DmxLJFCgxG77K7BjNrLvMYyG/ifwSOHeS+o3gTQIOyqH/3TrpqDZN O+a+TqdLWXjDJ30lPgQwk42AoVkZXNMS4ch5H2ueurhw2mUC+05Ucipqus5qVzXKH3uW yzqyuHRQe1gpSDO0z/Z+ol8g0sKcMZ5h7RfAdk/3XOG1bX9J97jwlVdxuMN2ABTkpp1e rj9ytDCZOyUQ8EBmH1WUOQAMzvn8n5zOI7qYt2slz0f6130t/2QNUgxwgj0UPx36tM3B kWocP88aUAx3d1mkNb5xcmcKSYoD9clzRZMfnvsffR5d/cV/z3JsbCAhzPcXLLilL0Eb 7Vzg==
X-Gm-Message-State: ALoCoQkFkqG6I9Ai+ZTTQnaP/+HX8uvP7k2ciWFxgVpdCJg1EAnRa6EJtnwlMUIjH2ZJ+HLNw6yl
X-Received: by 10.42.215.11 with SMTP id hc11mr352542icb.47.1383703154521; Tue, 05 Nov 2013 17:59:14 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm11548387igj.10.2013.11.05.17.59.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 17:59:13 -0800 (PST)
Message-ID: <5279A26F.7030204@bbs.darktech.org>
Date: Tue, 05 Nov 2013 20:59:11 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <CAOJ7v-3xE-e5Tdbw-V27eF38a6PhEYZEZwVMPGp8m+ogTWanCQ@mail.gmail.com> <5279866E.1040604@bbs.darktech.org> <CAOJ7v-2j8ohnHZBn=Q7bZm1EyZq9zxtuyBTvty0mkG50mEz0Zw@mail.gmail.com>
In-Reply-To: <CAOJ7v-2j8ohnHZBn=Q7bZm1EyZq9zxtuyBTvty0mkG50mEz0Zw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040406080609000204060706"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Nov 2013 01:59:57 -0000

On 05/11/2013 8:01 PM, Justin Uberti wrote:
> True P2P isn't always possible, witness TURN. So everyone deploying a 
> reliable WebRTC app is going to have bandwidth costs.
>
> Those costs will be higher and/or quality much lower, when using H.261 
> or comparable codecs.

     So what? Assuming the endpoints can't agree on a codec... If you 
mandate H.261 as MTI, vendors have the choice of either:

  * Using H.261, or
  * Upgrading endpoints to H.264/VP8, and transcoding.

     The choice is theirs. If you don't mandate any codec as MTI, we are 
*forced* to transcode.

     Transcoding might be fine for the big boys, but not for indie 
developers working out of their garage. P2P calls make up the vast 
majority of cases. I might be willing to lose 5% of users due to lack of 
TURN support, if it reduces my costs and simplifies my infrastructure.

Gili