Re: [rtcweb] Alternative decision process in RTCWeb

Bjoern Hoehrmann <derhoermi@gmx.net> Tue, 03 December 2013 02:00 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 C15D41ADF33 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 18:00:40 -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 vkeMPdIjRCRX for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 18:00:39 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6E1ADE8B for <rtcweb@ietf.org>; Mon, 2 Dec 2013 18:00:38 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.34.108]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MBnPX-1VvbeO1cu7-00AjU9 for <rtcweb@ietf.org>; Tue, 03 Dec 2013 03:00:35 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Basil Mohamed Gohar <basilgohar@librevideo.org>
Date: Tue, 03 Dec 2013 03:00:36 +0100
Message-ID: <e5bq99dg3h6e82mnsn6k21aunc9eqlvc7q@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> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org>
In-Reply-To: <529CEAA6.9000501@librevideo.org>
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:pNaxOqH7V6DZNKUK2SoqGsSoyBXpvR0FirK0YJzh50fw93QFeZ1 vlnklbClLCZQ1poc3h9bGaSCkhP6tmdYKezzMLlZQbFzOAOk3lKK+aJmRWqpwEFHjfTNmC+ VFtT5nD0Q4tQnn4AjIAQIsaS9fvCVUfHDsOQctMBeGyct4NvYzQJ1eAOD0wxsD/7LvkShse kU+hDILiU0h5AGGW6jaIQ==
Cc: rtcweb@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: Tue, 03 Dec 2013 02:00:40 -0000

* Basil Mohamed Gohar wrote:
>The problem with your problem is that you've set an ambiguous bar that
>is also irrelevant - "reasonable quality".  That is not the purpose of
>an MTI codec.  Rather, an MTI codec is there to prevent the absolute
>worst case of two endpoints being unable to communicate via video at all
>due to codec negotiation failure.  And MTI codec is also not mandating
>that it be the ONLY codec or even the BEST codec to be used.  It's there
>specifically to ensure communication can ALWAYS happen, no matter what.

I think it is highly relevant whether the mandatory-to-implement codec
supports two people in typical German households communicate via video
in sign language, and how it does so relative to non-mandatory options,
as a simple example. If H.264 supports the scenario and H.261 does not,
then selecting H.261 does not in fact prevent the absolute worst case
and does not ensure that communication via video can always happen.

>The fight against H.261 as MTI is really not about quality or
>efficiency, but rather, about forcing a royalty-bearing format on what
>should be an open standard and to save a few big players some
>implementation dollars because they might want to reuse some existing
>hardware, all of which are secondary points in this charter compared to
>a universally applicable MTI video codec.

Like I said, I have not seen a convincing argument that H.261 performs
well enough, and the implementation techniques that can reasonably be
assumed to be unencumbered are old enough that I think it is fair to
assume without investigating myself that selecting H.261 as only manda-
tory-to-implement video codec could work on paper, but not in practise.

I read the "irrelevant" responses as essentially advocating that we may
just as well make sending raw and unencoded RGB data the MTI codec. I'm
more than willing to hear better arguments. The same goes for the H.263
option that has been suggested.
-- 
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/