[rtcweb] MTI video codec

John Leslie <john@jlc.net> Mon, 01 April 2013 14:36 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA1FF11E80C5 for <rtcweb@ietfa.amsl.com>; Mon, 1 Apr 2013 07:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.999
X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OGNKSu-Q+tDe for <rtcweb@ietfa.amsl.com>; Mon, 1 Apr 2013 07:36:03 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net []) by ietfa.amsl.com (Postfix) with ESMTP id 3E30111E80BF for <rtcweb@ietf.org>; Mon, 1 Apr 2013 07:36:03 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 22C3133C23; Mon, 1 Apr 2013 10:36:03 -0400 (EDT)
Date: Mon, 1 Apr 2013 10:36:03 -0400
From: John Leslie <john@jlc.net>
To: Leon Geyser <lgeyser@gmail.com>
Message-ID: <20130401143603.GF12940@verdi>
References: <CA+9kkMBho1Gmj_GfPorL+Q5B2wih9RDs+dNFDBdkfGT-MN6FVA@mail.gmail.com> <51562335.1020409@acm.org> <CAGgHUiQEx5HVdb==oeypa3=mg4bygxCy6FNxV9-WtrhpFL9Yng@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGgHUiQEx5HVdb==oeypa3=mg4bygxCy6FNxV9-WtrhpFL9Yng@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: [rtcweb] MTI video codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 01 Apr 2013 14:36:05 -0000

Leon Geyser <lgeyser@gmail.com> wrote:
> Does anyone know the IPR status of H.261?

   Of course not!

> On the ITU website it lists some patents registered 11 years after the
> other patents: http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS

   I did follow up on that: there are a bunch of Robert Bosch GmbH patents
and one Polycom patent. The Polycom one is easy to find: it was issued
December of 1988. The Bosch ones are a little too hard for me to follow,
but they appear to have been issued years earlier.

   But none of those really matter. While there might be interoperable
implementations of H.261 that run afoul of some patent issued after the
publication of H.261, that would really be accidental. All one needs to
do is find an old enough implementation of H.261 and be sure to add
nothing the least bit clever in transliterating the code. (If it is C
code, that's already done.)

> Here are some of my opinions:
> - If Google resolves the IPR issues around VP8 then VP8 should be MTI. (No
> negotiation failure)
> - If it can't be resolved and H.261 can be freely implemented then H.261
> should be MTI. (Browsers will still implement H.264 or VP8)
> - If H.261 also has IPR issues then no codec should be MTI. (Browsers will
> still implement H.264 or VP8, but there will be negotiation failures. Audio
> only.)
> - If H.264 is MTI then not all new browsers will be willing to implement
> WebRTC. Only the popular browsers will use WebRTC. So much for an open
> web...Also other programs interfacing with WebRTC would need licensing for
> H.264.

   I agree, subject to "some" wordsmithing.

1) If Google resolves the IPR issues around VP8 to the satisfaction of
   the browser distributors more comfortable with H.261, VP8 should be

2) If H.261 licensors resolve the IPR issues around H.261 to the
   satisfaction of the browser distributors more comfortable with VP8,
   H.261 should be MTI. (There's nothing wrong with both being MTI.)

3) If neither 1) nor 2) are satisfied. H.261 should be MTI.

   There is no question it's _possible_ to safely implement H.261. It's
not very good, but it's a starting point. (Anything we specify _will_
be a starting point! It just would be nice to find a better one...)

   I can easily imagine either (or both) 1) and 2) being satisfied; but
I'd have to pinch myself to be sure I wasn't dreaming!

   We're never going to reach consensus by exchanging messages from two
camps both saying, "Be reasonable! Do it my way." Both camps have good
reason to prefer their choice. Unless at least one camp can specify
what it would take to be satisfied with the IPR status of the other
camp's choice -- and we can see a path to getting that in reasonable
time -- I suggest we seriously consider the fallback to H.261.

John Leslie <john@jlc.net>