Re: [rtcweb] Plan for MTI video codec?

Ron <> Fri, 14 November 2014 02:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0DD6C1A1AF8 for <>; Thu, 13 Nov 2014 18:42:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YO34G1GUs6EH for <>; Thu, 13 Nov 2014 18:42:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 241B61A1ADA for <>; Thu, 13 Nov 2014 18:42:55 -0800 (PST)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 14 Nov 2014 13:12:54 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id A6935FFEDC for <>; Fri, 14 Nov 2014 13:12:53 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id JVTIdejYnjdf for <>; Fri, 14 Nov 2014 13:12:52 +1030 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 91AF8FFC9E for <>; Fri, 14 Nov 2014 13:12:52 +1030 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7E50980470; Fri, 14 Nov 2014 13:12:52 +1030 (ACDT)
Date: Fri, 14 Nov 2014 13:12:52 +1030
From: Ron <>
Message-ID: <20141114024252.GD10827@hex.shelbyville.oz>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [rtcweb] Plan for MTI video codec?
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: Fri, 14 Nov 2014 02:42:59 -0000

On Fri, Nov 14, 2014 at 12:51:43AM +0000, wrote:
> Hi Adam, all,
> Since we are going to discuss video codecs today, I thought to clarify something that was said earlier.  
> Adam Roach wrote 25. lokakuuta 2014 2:33
> > 
> > On 10/22/14 14:45, Stephan Wenger wrote:
> > > ...
> > > Nokia has made MPEG and ISO/IEC officially aware that they are not
> > > willing to license essential patents under RAND terms.
> >>...
> > 
> > Thanks for the update.
> > 
> > That's actually even more interesting than it first appears to be. The official
> > rationale previously offered by Nokia was that the refusal to license patents
> > [0] for VP8 was that VP8 had not been through an appropriate standards
> > process [1]. The fact that Nokia is now using those same patents to *block*
> > VP8-based work from going through an appropriate standards process pretty
> > clearly exposes that claim as false. This isn't aimed at ensuring "open and
> > collaborative efforts for
> > standardization": this is aimed at suppressing technology.
> > 
> The key here is "open and collaborative efforts for standardization",
> though. Nokia does not think the *way* VP8 has been dealt with in MPEG
> meets that criteria. Collaborative effort means that all interested
> parties actually have a fair chance to contribute. With VP8 in MPEG
> this has not been the case, but it has been just a matter of pushing a
> ready-made technology through with no changes in practice possible.

I'm not clear on how you think you were denied a "fair chance" here?

Is Nokia saying they *tried* to contribute something of real value
to VP8 and were rebuffed?

Or are you just saying the usual game of everybody trying to stack
a proposed technology with their own "essential" patents didn't
play out because this one was carefully written to avoid them?

One of these would confirm Adam's observation.  The other I believe,
would actually be New Information.

> For those who are just a user of video codecs like WebRTC is, it may
> not matter how the codecs are developed or where they come from as
> long as they work, but for those who actually do codec development it
> does. There has been some criticism over how Opus was developed too,
> but it was certainly a much more open and collaborative model than
> what has happened with VP8 in MPEG. 

Was that "criticism" made in public somewhere, or do you mean there
was some internal griping that it also sought to avoid proprietary
encumbrances and you were unable to poison the well with it too?

I certainly don't recall ever seeing such criticism about the process
the IETF followed with it, and actual contributions which were warmly
welcomed came from many individuals and organisations.  Including
several where IPR was donated under RF terms.

IIRC Nokia did some listening tests, but I don't recall them ever
actually attempting to contribute any technology or ideas to the
development of it.

If my memory is simply failing me, I'd welcome some pointers to
things which back up your claims here to refresh it.