Re: [rtcweb] Alternative decision process in RTCWeb

Basil Mohamed Gohar <> Mon, 02 December 2013 20:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 961811ADED6 for <>; Mon, 2 Dec 2013 12:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cC4MJu6f7A9T for <>; Mon, 2 Dec 2013 12:16:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DF4431ACCFF for <>; Mon, 2 Dec 2013 12:16:43 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 6B06D65B82E for <>; Mon, 2 Dec 2013 15:16:41 -0500 (EST)
Message-ID: <>
Date: Mon, 02 Dec 2013 15:16:38 -0500
From: Basil Mohamed Gohar <>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Mon, 02 Dec 2013 20:16:45 -0000

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

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.

It's a codec of last resort, and should not be compared against the
state of the art that's available elsewhere.

It also has the added bonus of being ridiculously simple to implement,
both for encoding and decoding, compared to what's out there.

It really fits the bill as being something to serve as the worst case
scenario that's not catastrophic.

And as stated elsewhere on this list, some tests have been done on CIF
videos (352x288) at lower framerates at 256kbps, and got acceptable
results.  In fact, it was designed in the area of ISDN (64k + 64k), so
it will, in fact, work at the stated bitrates you're talking about here.
 We'd need also to add only about 16kbps for a killer Opus speech
channel, and you'd be set.

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.

Libre Video