Re: [rtcweb] H.261

Stephan Wenger <> Wed, 27 November 2013 05:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0B5241A1F62 for <>; Tue, 26 Nov 2013 21:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pn_JLpq_kBoP for <>; Tue, 26 Nov 2013 21:07:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D50A21AE124 for <>; Tue, 26 Nov 2013 21:07:24 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 05:07:16 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 05:07:15 +0000
From: Stephan Wenger <>
To: cowwoc <>, "" <>
Thread-Topic: [rtcweb] H.261
Date: Wed, 27 Nov 2013 05:07:13 +0000
Message-ID: <>
References: <> <20131122171020.GY3245@audi.shelbyville.oz> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 004395A01C
x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(199002)(189002)(479174003)(377454003)(24454002)(19580395003)(80022001)(65816001)(77982001)(4396001)(59766001)(19580405001)(16601075003)(83322001)(49866001)(74662001)(66066001)(79102001)(63696002)(80976001)(83072001)(74706001)(74876001)(15202345003)(74502001)(47446002)(31966008)(77096001)(47736001)(69226001)(47976001)(87266001)(54316002)(2656002)(51856001)(87936001)(74366001)(16236675002)(36756003)(81816001)(76786001)(46102001)(76796001)(53806001)(56816003)(81686001)(56776001)(15975445006)(85306002)(81342001)(54356001)(76482001)(81542001)(50986001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364;; CLIP:; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CEBABA4FAAF51stewesteweorg_"
MIME-Version: 1.0
Subject: Re: [rtcweb] H.261
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: Wed, 27 Nov 2013 05:07:30 -0000

Inline below, with the caveat that I do not represent MPEG-LA; I'm only a guy who works for a company that is both an MPEG-LA licensee and licensor, and therefore have some very limited insight in their thinking process.

From: cowwoc <<>>
Date: Tuesday, 26 November, 2013 at 19:40
To: "<>" <<>>
Subject: Re: [rtcweb] H.261

On 26/11/2013 10:30 PM, Cullen Jennings (fluffy) wrote:

When I go to, the top headline is "Google Chrome dropping support for H.264, will support only open web codecs in the future" which seem, ah, a little out of date. I think the article is also a bit confused about the current state of MPEG LA license terms for 264 AVC pool. I do get they MPEG LA terms can be confusing at times but lots of people have figured it out. If people have questions about specific use case I'm glad to try and get them answers.


  1.  If I recall correctly, someone asked for a more concrete definition of a licensing "unit".

StW: I do not recall the context, but MPEG-LA licenses (in addition to content, which is not at issue here) a thing called "codec", which is defined as one encoder, one decoder, or one encoder and one decoder. /StW

2. On a related note, if my application is downloaded once but installed 5 times by the same end-user, how many units is that?

StW: I believe the correct answer would be 5.  However, there is a provision that allows you to distribute "disabled" copies of a "codec", and in that case the license fee only becomes due upon the enabling of the copy, for example at the first use.  People use this in conjunction with software activation mechanisms.  /StW

3. I asked for the ability to license multiple units at a time so we deploy images and applications without a separate plugin/download process.

StW: if this is related to MPEG-LA (and not to the Cisco download mechanism) the answer is simple.  You, as an MPEG-LA sublicensee, are responsible for the correct accounting of the number of codecs you "sell" (where "sell" includes things like free download etc.).  MPEG-LA has the right to audit you, and if they do  and you are found cheating, then there are provisions for penalties. /StW