Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Gaelle Martin-Cocher <gmartincocher@blackberry.com> Wed, 03 December 2014 23:32 UTC

Return-Path: <gmartincocher@blackberry.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 6D7E91A6F05 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 15:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0fMTnYrbNX5v for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 15:32:47 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5931A1ACE for <rtcweb@ietf.org>; Wed, 3 Dec 2014 15:32:46 -0800 (PST)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 18:32:42 -0500
Received: from XCT112CNC.rim.net (10.65.161.212) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 3 Dec 2014 18:32:41 -0500
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 18:32:40 -0500
From: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMA==
Date: Wed, 3 Dec 2014 23:32:40 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com>
In-Reply-To: <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d9Xe4coPw5Hr7lNuifBqY6mu1-0
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
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: Wed, 03 Dec 2014 23:32:50 -0000

Hello,

Here are some other feedbacks.

a) How can the group composed by a vast majority of non-browser vendors force a decision on browser vendors against their statements? 
- Apple and Microsoft have stated that they have no plans to implement VP8
- Google has stated they intend to implement the spec (assuming the two codecs)but they have not decided yet when and how
- Mozilla is the only browser vendor that has a clear commitment.
How will the specification be relevant if MTI functions are specified while knowing they will likely not be implemented?
Does the proposed text give us interoperability other than on paper?

b)I don't think there was enough discussion on "non-browser" entities. I believe the two topics (browser/non-browser) should have been separated. There was quite a few objections on a non-browser having to implement both codecs, at the meeting and on the list prior to the meeting. There was some comments as well about the state of WebRTC implementations preventing to deploy applications, the codec was not an issue. Most applications needs to interact with themselves on other platforms or via browsers. For that purpose they can chose the codec they want. Can we leave the non-browser alone (aka not mandating a codec) or asking that they support only one?

Can we separate the two topics to reach agreement on each of them independently?

c) codec versus decoder
I guess the discussion was very limited despite multiple comments that decoder(s) only should be mandated. I did not find any reasoning for mandating the two encoders in the audio archive feed, nor in the slides. Was that a lack of time? Can we discuss that point?


d)Cost increase
Cost does not only equal to patent license.
Cost also include implementation, testing, maintenance, providing APIs. By multiplying codecs, the cost is mechanically increased. Can this be taken in account in the revisiting note?

licensing and RF statement.
It seems there will be further discussion on the proposed revisiting note. When? How? 
Nokia's type 3 declaration has been pointed out many times as a serious concern. 
Another concern is the following: It was stated that Google is "working from the assumption that VP8 is RF and that anyone that challenges that assumption will be proven wrong. that proof may take time and lawyers but we are working from that assumption."
Microsoft, Dolby and Ericsson have made a type 2 declaration and possibly quite a few more can be expected.
It seems that no one knows, as of today, the actual licensing price of VP8; nor how long it will take to resolve that question.

Why does it sound reasonable to the group to impose unknown fees to WebRTC endpoints and actors? 
Is the goal to alleviate the codec fees to only part of the WebRTC ecosystem (aka gateways? App developers)? 
Can this be clarified?



thanks
Gaëlle

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer
Sent: Wednesday, December 03, 2014 4:08 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)


> On Dec 3, 2014, at 11:12 , Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> On 12/03/2014 07:33 PM, David Singer wrote:
>> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.
>> 
>> This is some feedback.
>> 
>> 
>> 
>> I’d like to point out that this could easily place companies in an impossible position.
>> 
>> Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry).  Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications.
> 
> I'm having trouble following the logic here. What technology are you imagining that Company X will put IPR claims on, and what conformance do you imagine that it would require?

I am imagining the common case that company X has IPR on some aspect of the WebRTC spec. (some other aspect than the codec), and they offer the fairly-common “license is free to conforming implementations of WebRTC”.  

> 
> (We could also consider the case of someone, call it Company G, claiming IPR on some non-codec part of WebRTC technology and refusing to license it at all. We can discuss the relative chances of the two things happening.)

No, I am not interested in discussing trolls here.  I am pursuing much more normal circumstances.

> 
>> 
>> Consider also: we have an “unwilling to license” statement from Nokia on VP8, on the formal record (and including a long list of patents).
>> 
>> Consider finally: a small company for whom WebRTC is important.
>> 
>> 
>> 
>> Let’s look at the choices:
>> 
>> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia.
>> 
>> 2.  Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X.
>> 
>> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance.
>> 
>> 
>> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.
> If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from Company G.
>> 
>> (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations” clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.)
>> 
>> (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.)
> 
> My impression from the meeting was that the people speaking in favour of the proposed solution had evaluated the risks, and were ready to make a decision based on their evaluation.

Well, this is exactly that:  for the ‘vanilla’ company, mandating VP8 means mandating a violation of Nokia’s statement, which puts them at risk;  or forcing people to abrogate a ‘must’ clause, which also may put them at risk.  Or not do WebRTC.



Dave Singer

singer@mac.com

David Singer
Manager, Software Standards, Apple Inc.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb