Re: [rtcweb] Alternative decision process in RTCWeb

cowwoc <> Tue, 03 December 2013 02:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 721F61AE027 for <>; Mon, 2 Dec 2013 18:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RV8htp8Ni2xo for <>; Mon, 2 Dec 2013 18:46:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 431C91AE026 for <>; Mon, 2 Dec 2013 18:46:53 -0800 (PST)
Received: by with SMTP id lx4so22234668iec.23 for <>; Mon, 02 Dec 2013 18:46:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=cGApMNI5BNjl7rpv9IsK/lAvRktBq1HGN9byHIIS/eM=; b=HnYrlpNaWEkQfj7cNAHR0sxaomInhwcT7P1U2iemiSUmS2eL0Ypdgxe4gOZGXouPnj 7pJxJFSKcgBawfdgNoPQx93nglWKYKxnjlz7Jeu6NO9fkMKOp0LmtXX8ZGaT1pJYbxdg IJ6cykfxUNSIfMSPWafaCHrVlTxuDKyVAM3kl+sb8Ktn21Jn8zBNAQ2nKftqLpwfNHBu t1Id7aBYBxQEO88vjnLJPYkdIdt5Zby4WYbUgINK/LWQ0JjirwxskSiosiynItyuVzZY 75J3Jrodm8CKrNi/5+qkz8FX3ud3FrYUimgdmVjPbeeorK6OGf1AemAM5GHivZWvuiip yLCw==
X-Gm-Message-State: ALoCoQkhAHHq7W6NSA3qFIzZ3VeyFzK4RMKVUIyr5jaisp4NCkUhZ2w4pUOQzQsaDyoTGhrI0/WS
X-Received: by with SMTP id im10mr4509217icb.46.1386038810595; Mon, 02 Dec 2013 18:46:50 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i11sm797829igh.0.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 18:46:49 -0800 (PST)
Message-ID: <>
Date: Mon, 02 Dec 2013 21:46:47 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030306040008090406060407"
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2013 02:46:55 -0000

On 02/12/2013 9:00 PM, Bjoern Hoehrmann wrote:
> 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. 


I'd like to point you to 
for two reasons:

 1. It states that Germany has an average upload rate of 3.13Mbps.
 2. It shows that upload speeds are increasing over time.

>> 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.

H.261 is meant as a fallback only in the case that the market cannot 
agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the 
market cannot agree at runtime, what makes you believe that that same 
sizable portion can agree on a MTI codec? And a final question, in case 
you disagree with everything I've written so far: How do you advocate we 
proceed in light of the fact that we already tried to (and failed) to 
reach consensus around VP8 and H.264?