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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Thu, 04 December 2014 20:43 UTC

Return-Path: <keith.drage@alcatel-lucent.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 B35A61A1ABB for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 12:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XRRm-d4hAonw for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 12:43:48 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5EA1A1AA5 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 12:43:48 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A1EC6DC592D10; Thu, 4 Dec 2014 20:43:43 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB4Khk5Y027530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 21:43:46 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 21:43:46 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: David Singer <singer@apple.com>, Silvia Pfieffer <silviapfeiffer1@gmail.com>
Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
Thread-Index: AQHQD/+9dvoOgSKMeEyydWLYZisN4px/0Z8AgAASoDA=
Date: Thu, 04 Dec 2014 20:43:46 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <CAHp8n2m+KMnui30_fMrwM+81UX-RUJM2ktuiZuPpRSnC7dxqcA@mail.gmail.com> <20141204014218.5955730.38619.3157@blackberry.com> <CAHp8n2=KWuTsmruz3W-90eAsptSoMYLTUVtyx9pAwcZFGXSKCQ@mail.gmail.com> <CB477124-13AD-47EA-A607-8A81AFFA379E@apple.com> <CAHp8n2n1m6WRaBPNyKpowPEz_BK-SAMMFWTiB7d-eVL69w4rpQ@mail.gmail.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com>
In-Reply-To: <1F326DF9-79C2-4562-853B-240D934EA235@apple.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EkqsZ9wBzl4LEnrDD-3L7GBsVz8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Thu, 04 Dec 2014 20:43:51 -0000

As a tangent to this discussion, I'd note that pretty much every codec implementor will be subject to additional IPR risk. This is because pretty much all the standards specifications of codecs only specify the decoder (VP8 included). Therefore any IPR claims and licences tied to the specification will only have relevance to the decoder.

Unless you have a viable application that only needs the decoder, you will have zero visibility in the standards IPR databases of what IPR claims might exist against your coder implementation.

Everyone who uses the term "codec" in association with "royalty free" or "IPR free" is misleading the world. What they mean is the decoder only.

Regards

Keith



> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
> David Singer
> Sent: 04 December 2014 20:31
> To: Silvia Pfieffer
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Finishing up the Video Codec document, 
> MTI (again, still, sorry)
> 
> 
> > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer 
> <silviapfeiffer1@gmail.com> wrote:
> > 
> > 
> > On 5 Dec 2014 06:25, "David Singer" <singer@apple.com> wrote:
> > >
> > >
> > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer 
> <silviapfeiffer1@gmail.com> wrote:
> > > >
> > > > Indeed, that's why I said point 1. in David's list 
> doesn't make sense, since he's talking about a small company 
> getting sued by Nokia.
> > >
> > > So, your conclusion to my question is "Ship VP8, most of 
> you probably won't get sued. Good luck.  Try not to be too 
> successful or your luck may change."
> > 
> > Yes and it's the same answer as for h.264 and h.265 for that matter.
> 
> It is not at all.  Where are the "unwilling to license" 
> statements for H.264?  Where is the VP8 license coverage from 
> the larger players not in the MPEG-LA agreement?
> 
> > Only add to that the extra licence fee you heavy to pay, 
> which is a certainty - the risk of getting sued is uncertain 
> and frankly quite small compared to other risks that you take 
> as a small company.
> 
> See the other thread...
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>