Re: [rtcweb] Plan for MTI video codec?

<markus.isomaki@nokia.com> Fri, 14 November 2014 00:51 UTC

Return-Path: <prvs=388f0da97=markus.isomaki@nokia.com>
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 EC15F1A1A32 for <rtcweb@ietfa.amsl.com>; Thu, 13 Nov 2014 16:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 MV5dTz57Kcdm for <rtcweb@ietfa.amsl.com>; Thu, 13 Nov 2014 16:51:48 -0800 (PST)
Received: from nok-msg-3.service.capgemini.fi (nok-msg-3.service.capgemini.fi [145.247.12.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2971A1A52 for <rtcweb@ietf.org>; Thu, 13 Nov 2014 16:51:47 -0800 (PST)
Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-3.service.capgemini.fi with ESMTP; 14 Nov 2014 02:51:45 +0200
Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 14 Nov 2014 02:51:44 +0200
Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.0775.031; Fri, 14 Nov 2014 02:51:44 +0200
From: <markus.isomaki@nokia.com>
To: <adam@nostrum.com>, <stewe@stewe.org>, <watsonbladd@gmail.com>, <agouaillard@gmail.com>
Thread-Topic: [rtcweb] Plan for MTI video codec?
Thread-Index: AQHP7+LLZ1FATfQqEkuoDIJCcWSHI5xfXjHg
Date: Fri, 14 Nov 2014 00:51:43 +0000
Message-ID: <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com>
References: <CAGTXFp-HVJDwd86207PNM2QVYO4Z_K4WF-KarnRs1fb7nvy4zA@mail.gmail.com> <CA+9kkMDfES8gpi0-PTXpCnQHjFYUSF2r44TNzH5B4UfDGo8PtA@mail.gmail.com> <CAGTXFp8O-7ACksk3v3f=KjCkcDb4e8G=t-e=EJ1503vt7TkpCQ@mail.gmail.com> <CAGTXFp867AMUZ_fEKxG9uAoR1H1AirVHi3-ayJ=KTQk9L+C7+g@mail.gmail.com> <CA+9kkMAZufR7gUrwkS7Tf5GOfg+ZtsZWGcn-8YLCvnmYnTgfFw@mail.gmail.com> <544035DE.8000606@matthew.at> <CABkgnnUNgWaauS6-nZ5fcExjsMPy4ZGPXaahduzA39=iqh9+fQ@mail.gmail.com> <D5D11F2B-9E32-4932-A601-F1D7FD50C706@gmail.com> <544117FB.6050706@alvestrand.no> <CAHgZEq6GTk5ei+LLpWPM5povpieompD66VU9F+u7--WJVgapaQ@mail.gmail.com> <CA+23+fGWnWd0QEeCmZ=6BmJkPrUVW6cZ0jwmXA+fM88=_+_NWw@mail.gmail.com> <CAOW+2dugTtfLhk0VuJOk7OPEonGBApMjY93EZocH90RbX6X22w@mail.gmail.com> <CAHgZEq5t4-Cot9XkU_pfyfi0TBCUxfT79ZvpiLW=X5_KUQh5dA@mail.gmail.com> <CACsn0ck_VtMnf6740rh0ku1Qct7s-xrJEfokg6oufEi4wgrYAw@mail.gmail.com> <D069AC57.49A8E%stewe@stewe.org> <D06D5403.49D1D%stewe@stewe.org> <544AE196.6080907@nostrum.com>
In-Reply-To: <544AE196.6080907@nostrum.com>
Accept-Language: en-US, fi-FI
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.50.31.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QYXOq-RDFnsDrzXusJTz3n1Pgk4
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?
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, 14 Nov 2014 00:51:50 -0000

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. 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. 

So the original reasons for Nokia's "unwilling to license under RF or RAND" declarations are still valid. I'm sure people have a lot of different views on this and the MPEG process, but I just wanted to convey Nokia's viewpoint. And I know there are also lot of companies/people who agree with it.

Personally I'm sad to see these types of issues getting in the way of interoperability, but that has unfortunately been the story with the video codecs for a while. It seems the next generation video codecs are facing the exact same issue, hopefully the next-next generation will be better off...

Regards,
	Markus