Re: [rtcweb] Alternative decision process in RTCWeb

Bjoern Hoehrmann <derhoermi@gmx.net> Mon, 02 December 2013 19:27 UTC

Return-Path: <derhoermi@gmx.net>
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 C32EF1AC4A7 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 11:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 lwi7fdtfb1T1 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 11:27:25 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 450F21AD687 for <rtcweb@ietf.org>; Mon, 2 Dec 2013 11:27:25 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.23.195]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Lkjuq-1VD7wD1LgC-00aSsl for <rtcweb@ietf.org>; Mon, 02 Dec 2013 20:27:22 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Ron <ron@debian.org>
Date: Mon, 02 Dec 2013 20:27:20 +0100
Message-ID: <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <D4D5920A-E041-42E8-BB1C-1CB24FBEE3F4@nominum.com> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:OR6LjnH7QanpLRy5nSVFqwph0u1uKXHMfMEhhTkQtH+mWRNvWee jPznKyUgGQznacKCrPWaz1tz7r2YJkRm7tj/PEI3vJzp9E7csE/l2HkFQ12GnvFY5+9FZ7Y oQjGb9j7KJXzSOHDHP1sV8sc0kZXizhQXy/xrJugNvIqX6rrnVUeft3NOFOJynq2f54XaXy n4ChjIKSvZ+hzmpUEo8yA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, IETF Discussion <ietf@ietf.org>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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: Mon, 02 Dec 2013 19:27:28 -0000

* Ron wrote:
> 2. Can anybody show a sustainable objection for why we _can't_ use H.261.
>
>   If they can, we're probably doomed.  If they can't we have an initial
>   choice for MTI.

I have not seen a convincing argument that H.261 performs well enough to
permit real-time video communication at reasonable quality and bitrates.

I have not seen recent statistics for Germany but I suspect it is common
that household members share a line with an upstream of around 640 kbps,
that would basically allow for two 320x240 H.264 CBP + Audio streams at
30 fps in good quality. Would H.261 permit at least one stream at the
same quality? If not, then nobody would use H.261-only WebRTC products,
and people are not going to appreciate if a VP8 product connecting with
a H.264 product falls back to H.261 to avoid negotiation failure.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/