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

"DRAGE, Keith (Keith)" <> Thu, 04 December 2014 23:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00CEE1A8749 for <>; Thu, 4 Dec 2014 15:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 66rVaNsQyall for <>; Thu, 4 Dec 2014 15:02:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E9B01A8746 for <>; Thu, 4 Dec 2014 15:02:44 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id BE40B2BE58883; Thu, 4 Dec 2014 23:02:38 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id sB4N2gRk014668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 00:02:42 +0100
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 00:02:42 +0100
From: "DRAGE, Keith (Keith)" <>
To: "Timothy B. Terriberry" <>, "" <>
Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
Thread-Index: AQHQEAXmSNqBPks4zU2cSbL9+QhOa5x/3g0AgAAsGJA=
Date: Thu, 4 Dec 2014 23:02:41 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
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: Thu, 04 Dec 2014 23:02:50 -0000

Both yours and David's responses to this are outside the IPR gathering exercise that forms part of the standards process.

The idea of the standards process is that a group of vendors etc write a standard, they are forced to declare their IPR involved in that standard. If the population is sufficiently large you stand a good chance of identifying all the worldwide IPR relating to that standard.

The bigger the standards organisation, with the greater coverage of all the vendors in that space, the better the process works.

So at that level, IPR knowledge for codecs is primarily on the decoder space and what IPR exists there.

What Tim is saying (and a somewhat parallel situation exists with MPEG LA) is that a limited set of organisations will limit your IPR problems and give you some help with the encoder IPR. For VP8 that is limited to Google's IPR and any background research they may have done. For MPEG LA it is limited to the members of the pool, which is only a subset of those involved in the parallel standards process. Yes it helps, but it does not have the degree of confidence of identifying all the existing IPR that the standards process would do.



> -----Original Message-----
> From: rtcweb [] On Behalf Of 
> Timothy B. Terriberry
> Sent: 04 December 2014 21:16
> To:
> Subject: Re: [rtcweb] Finishing up the Video Codec document, 
> MTI (again, still, sorry)
> Roman Shpount wrote:
> > Actually Google does grant patent license to the implementation of 
> > WebM, which includes both encoder and decoder 
> > ( This is 
> one of the 
> > reasons we think VP8 license is better then H.264. (The 
> other two are 
> > reciprocity and no use restrictions on the produced media).
> Serge also confirmed on this list that that license applies 
> to third-party implementations as well: 
> The Opus licenses similarly grant rights to patents that read 
> on the reference implementation, including the encoder, even 
> if used in a third-party implementation.
> Now, it's certainly possible to infringe other people's IPR 
> by implementing an encoder sufficiently different from the 
> reference encoder. One must be very careful when doing that. 
> But these reference implementations are production-grade. 
> Anyone who merely wishes to deploy a codec has an 
> implementation they can use with just as much assurance of 
> the IPR safety of the encoder as they have of the decoder.
> _______________________________________________
> rtcweb mailing list