Re: [rtcweb] Interoperability between browsers (MTI Video)

Enrico Marocco <> Sat, 16 March 2013 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03E4C21F8675 for <>; Sat, 16 Mar 2013 13:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TGN4YllcEPxJ for <>; Sat, 16 Mar 2013 13:41:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C0CD21F8623 for <>; Sat, 16 Mar 2013 13:41:14 -0700 (PDT)
Received: from grfhub702rm001.griffon.local ( by ( with Microsoft SMTP Server (TLS) id; Sat, 16 Mar 2013 21:41:04 +0100
Received: from airlab.local ( by ( with Microsoft SMTP Server (TLS) id; Sat, 16 Mar 2013 21:41:02 +0100
Message-ID: <>
Date: Sat, 16 Mar 2013 16:40:55 -0400
From: Enrico Marocco <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030100060901070000090005"
X-TI-Disclaimer: Disclaimer1
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-Mailman-Version: 2.1.12
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: Sat, 16 Mar 2013 20:41:15 -0000

On 3/16/13 4:08 PM, Hadriel Kaplan wrote:
>> --Decide on H.261: This might be old tech, but browsers might be
>> able to use H.261 without paying any royalties and without
>> transcoding. The codec can be used at 352x288 resolution from
>> 64Kbit/s to 2Mbit/s Remember this is just a fallback for
>> interoperability. Browsers will still implement VP8 and/or H.264.
>> ... Atleast there is video instead of no Video. Any opinions?
> I agree this would be better than nothing, as mentioned on the thread
> titled "Video Codec MTI & User Experience == 1". I also asked a few
> vendors after this week's meetings whether their existing devices
> support H.261, but they didn't know.  If most existing video devices
> do, then having H.261 as the MTI would also facilitate interop with
> legacy equipment.  I.e., it would follow the same rationale for why
> we chose G.711 as one of the MTI audio codecs.

Not only that. It would also foster competition and innovation. Crappy 
quality when negotiation falls back on H.261 will be a big incentive for 
the communicating parties to switch to a common browser. In the end the 
fluctuations in browser market share will take care themselves to set 
the de-facto standard.

At this point crappy quality may be a feature rather than a bug..