Re: [rtcweb] Trellis IPR status? (Re: H261/MPEG-1 video quality)

Harald Alvestrand <> Tue, 19 November 2013 13:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7079C1ADFB0 for <>; Tue, 19 Nov 2013 05:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.425
X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N81lD03jAaen for <>; Tue, 19 Nov 2013 05:26:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 70CD41ADFA6 for <>; Tue, 19 Nov 2013 05:26:28 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AD2139E49F for <>; Tue, 19 Nov 2013 14:26:22 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xQs5BSCJrjbk for <>; Tue, 19 Nov 2013 14:26:21 +0100 (CET)
Received: from (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by (Postfix) with ESMTPSA id DA39439E482 for <>; Tue, 19 Nov 2013 14:26:20 +0100 (CET)
Message-ID: <>
Date: Tue, 19 Nov 2013 14:26:19 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <DUB127-W49A2377699D81E3A1EA912E0FB0@phx.gbl> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Trellis IPR status? (Re: H261/MPEG-1 video quality)
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: Tue, 19 Nov 2013 13:26:31 -0000

On 11/19/2013 01:00 PM, Maik Merten wrote:
> Am 19.11.2013 09:00, schrieb Harald Alvestrand:
>> Just checking: Do you know the patent status of trellis quantization?
>> One issue this particular WG has with codecs is that in order to have a
>> non-IPR-encumbered spec, we need a non-IPR-encumbered encoder too -
>> unlike the situation for playback-only contexts, where a
>> non-IPR-encumbered decoder may be enough.
>> Thus, people who describe a particular quality level achievable with a
>> non-IPR-encumbered codec would seem to have to describe a
>> non-IPR-encumbered encoder that can achieve that quality level, too.
> I don't think discussing the IPR-situation of encoder optimizations 
> was a topic yet, as implementers can choose what optimization features 
> they enable in their encoder deployments. In the case of H.261, I 
> think it is undisputed that an "IPR-free", spec-compliant encoder can 
> be created. The samples I provided were encoded without modern encoder 
> techniques (simply because ffmpeg used to crash when doing the 
> advanced stuff, which now has been fixed), but clearly I'm not in a 
> position to report on the general IPR situation of ffmpeg's H.261 
> encoder. Due to H.261's special IPR status it may indeed make sense to 
> have both "IPR-safe" samples and "rockets attached" samples, once and 
> if such performance boosters become available for H.261.
> When assessing the performance that is achievable with a given format 
> it is natural to try to create the best encodes possible, as has been 
> done, e.g., with the VP8 vs. H.264 quality debate here on the list. 
> For instance, H.264 was represented by x264 (most likely because of it 
> is usually the best performing encoder) and not, e.g., by Cisco's 
> encoder, albeit the latter is likely to become more relevant in the 
> form of OpenH264. As far as I recall nobody called for a comparative 
> IPR analysis regarding, e.g., those two encoder implementations. I 
> assume this is because everyone assumes that each implementer will 
> make its own risk-assessment regarding deployed encoding techniques. 
> If this is so this should apply to H.261 as well.

In the case of VP8, the patent and copyright grants apply both to the 
decoder and the published reference encoder (which is also the one used 
for the tests).

Choosing x264 for the tests was easy; it's got a reputation for quality, 
and its reference source is available on the Internet, so everyone can 
agree what we're talking about when we say "x264, GIT tag xxxxx".