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

Ted Hardie <> Sat, 06 December 2014 00:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E9BD21A86FD for <>; Fri, 5 Dec 2014 16:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DzUciS6q983f for <>; Fri, 5 Dec 2014 16:07:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 579F31A86F2 for <>; Fri, 5 Dec 2014 16:07:53 -0800 (PST)
Received: by with SMTP id h15so157674igd.8 for <>; Fri, 05 Dec 2014 16:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vBHxWJZsPMVSUTmynRBKsaZVXc9zTLUazsAkATZfYUs=; b=i6nYMUQs0h4uh4xzZyXNKrAFC6ArSsNtyZtgVb1HtPZZWPaGEZS3cm3HkVpA3XwjdP fbEnu+ZaZ40eX1mYfSWJp1RVyiBcoRexMbOIZN2WIU6w7cV1ft2PpCW9J4XrjNgNTVG7 7hWu0ZAQvUOzMzSym07Ezw+kJ1kzfjgJDThnhzTQMs07zxPm7GxJQNAb51Ubc69DTJnX BT5MPeXQ7/7V9FJaEnCYZSY0Z38wjJZuhhUC7yWsmilPCfiidDvfklWx4SGFc+6RgVl3 rtzeVNw3d7NsFagAkasm0L9dMmd5jESJQNNKV2KLEkImNPiC8m8FvC5A70mYRAtnTyMx 7reg==
MIME-Version: 1.0
X-Received: by with SMTP id mm17mr17780557icb.18.1417824472395; Fri, 05 Dec 2014 16:07:52 -0800 (PST)
Received: by with HTTP; Fri, 5 Dec 2014 16:07:52 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <20141205035706.GB21150@hex.shelbyville.oz> <> <> <> <> <> <> <>
Date: Fri, 5 Dec 2014 16:07:52 -0800
Message-ID: <>
From: Ted Hardie <>
To: David Singer <>
Content-Type: multipart/alternative; boundary=20cf3036404f07f4b6050980fc6d
Cc: "" <>
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: Sat, 06 Dec 2014 00:07:56 -0000

On Fri, Dec 5, 2014 at 3:13 PM, David Singer <> wrote:

> OK, let me see if I can persuade you of a qualitative difference.  For
> each ‘must’,
> ​​
> ​​
> what is the nature and availability of licenses that I might need from
> those claiming IPR?
​Is that the right question?  I think that "​​​​​what is the nature and
availability of licenses that I might need from those whose IPR I believe I
must use?" might be closer, but, again, I am not a lawyer.  Seeking a
license for everything claimed is at best highly conservative; it might
even be expensive and unnecessary.

This is, in any case, exactly what I pointed out earlier:  each participant
must make this same assessment for each of the cases.

> * H.264: all those claiming IPR offer licenses, though most of them ask
> for payment

​Note that this may be the case for common encoders and decoders, but
anyone coming up with their own code (especially on the encoder side) would
have ​to conduct the analysis for themselves.

* VP8: almost all offer licenses that are either free or effectively so
> (pre-paid, in the case of the MPEG-LA), but there is one for which no
> license is available (and it’s not an insignificant company, or one not
> active in the field, or a small set of patents)
> ​​There has been one assertion of non-licensable patents to be named later
(MPEG) and one set of patents (often asserted in multiple countries)  named
to the IETF in the following IPR declaration: . As noted above, I am not a lawyer,
but I invite folks to have their lawyers wade through that; it may be
shallower water than it first appears.

For me, that is a major difference.  Clearly for others (e.g. Ron who has
> said as much), the cost is more significant than the license availability.
> I think inserting the ‘must’ here means that companies will either ignore
> it

​I don't have a crystal ball myself, but I note at least two companies that
make browsers have said that they will comply if this the standard.  There
may be others that do not, of course, and if they had been intending to
consider it, it is obviously something that they would need to add to the
consideration.   But your conclusion is not the same as others', at least
according to my hearing or my reading of the work at Chrome and Firefox.​


Ted Hardie
as an individual​