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/
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Dave Crocker
- Re: [rtcweb] Alternative decision process in RTCW… Eliot Lear
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Bernard Aboba
- Re: [rtcweb] Alternative decision process in RTCW… DRAGE, Keith (Keith)
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Ron
- Re: [rtcweb] Alternative decision process in RTCW… Michael Richardson
- Re: [rtcweb] Alternative decision process in RTCW… Maik Merten
- Re: [rtcweb] Alternative decision process in RTCW… Roger Jørgensen
- Re: [rtcweb] Alternative decision process in RTCW… Roberto Peon
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Leon Geyser
- Re: [rtcweb] Alternative decision process in RTCW… Basil Mohamed Gohar
- Re: [rtcweb] Alternative decision process in RTCW… Mary Barnes
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Basil Mohamed Gohar
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Martin Thomson
- Re: [rtcweb] Alternative decision process in RTCW… Silvia Pfeiffer
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Stephan Wenger
- Re: [rtcweb] Alternative decision process in RTCW… Bernard Aboba
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Basil Mohamed Gohar
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Max Jonas Werner
- Re: [rtcweb] Alternative decision process in RTCW… John Leslie
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Dave Crocker
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Sam Hartman
- Re: [rtcweb] Alternative decision process in RTCW… Richard Shockey
- Re: [rtcweb] Alternative decision process in RTCW… David Singer
- Re: [rtcweb] Alternative decision process in RTCW… Maik Merten
- Re: [rtcweb] Alternative decision process in RTCW… Harald Alvestrand
- Re: [rtcweb] Alternative decision process in RTCW… Silvia Pfeiffer
- Re: [rtcweb] Alternative decision process in RTCW… Randell Jesup