Re: [rtcweb] H.261

Ron <ron@debian.org> Fri, 22 November 2013 17:10 UTC

Return-Path: <ron@debian.org>
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 A7B191ADFF6 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vd0jOyLLSV61 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:10:32 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id E2C751ADFE2 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:10:31 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 03:40:24 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 32EF24F8F3 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 03:40:22 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UcJztSqP9AI2 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 03:40:20 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 81FF34F902; Sat, 23 Nov 2013 03:40:20 +1030 (CST)
Date: Sat, 23 Nov 2013 03:40:20 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131122171020.GY3245@audi.shelbyville.oz>
References: <CEB4350B.1E7B2%mzanaty@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CEB4350B.1E7B2%mzanaty@cisco.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.261
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: Fri, 22 Nov 2013 17:10:33 -0000

On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote:
> On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org<mailto:basilgohar@librevideo.org>> wrote:
> Has anyone actually objected to H.261 being the one MTI codec [...] ?
> 
> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to
> various (incredibly extrapolated, possibly inaccurate and sometimes
> conflicting) sources [1] on who uses what browser, the chance of H.261
> fallback is a whopping 30% [2]. Not the minor insignificant case some had
> assumed.
> 
> How will these users react to H.261 QCIF/CIF compared to what they use today ...

You seem to be forgetting that WebRTC is a communication protocol
for PEOPLE, not some one-sided push technology that gives them
take it or leave it choices decided by self-interested vendors.

So I would assume they'll react the same way they already do.
Something along the lines of:

  "D00d!!  Y U use that crap browser!??!111"

And then they'll use the amazing text capabilities to paste
a download link for firefox or something.

  2 minutes later, problem solved.

And they'll be watching each other's cats do fun things in full
hi-res glory.


It's not some accident of fate that the vendor browsers have the
poor level of mindshare that they do, even given the solid advantage
of incumbency they should otherwise enjoy.

If the only way they think they can compete is via lock in and
exclusivity using codec patents, then that alone speaks for the
irrelevancy of those opinions about what is best for making this
standard become ubiquitous.


We need to guarantee interoperability between things that claim to
implement the standard.  Quality of implementation is something
that users will judge for themselves, and their mindshare will
again gravitate accordingly between the available options.

I'd still much prefer a better codec than H.261 as our baseline,
but if the proprietary patent holders refuse to let us have that,
then we need to work with the technology that is available to us.

It doesn't take a doctorate in formal logic to connect those dots.


This is our next best option for "making the patents evaporate",
are people really now saying they didn't really want that to
actually happen after all, despite what they said previously?

  Ron