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

Maik Merten <> Tue, 19 November 2013 11:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A09EA1ADF28 for <>; Tue, 19 Nov 2013 03:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cFsBA1Y82H0h for <>; Tue, 19 Nov 2013 03:59:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4008:c01::233]) by (Postfix) with ESMTP id E2A161AD8EA for <>; Tue, 19 Nov 2013 03:59:41 -0800 (PST)
Received: by with SMTP id 6so1098285bkj.10 for <>; Tue, 19 Nov 2013 03:59:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=abtxsoVzpcIzxvXMNJVswRBM1BP4tZHslhWv9qDxDko=; b=nqPBhwb0+x25TphKnJPCIIX0uAf2Hk4YQbeZL6w6k7p6gCsv/6+15eTraayjucM1cv zBDa2903j9J3ZyYNdT/eNeEO3OLQGk3UT4VElSvYey3c4wIczaa0sSHvMQF3Ljlucmpd EI/Do0SV1a7zdR/9RkmWhtD6hDntsBsF/wW3hKJI4tP2tUw3QSoMkPdjAsdtGHNc9RWt Kb7fg8zJBhGzixzQPcNtK3VHv7kP9RwkP6if4VP94ECFvhYOMnBEf5olbrhdD9XWdY2E Lzo6y7A/pNMj7erjBaqfEzmK1DEDG7vNNCb1WC7Xaz5EQA+LVGwaWffMkQeqeRvk3ADK wW4g==
X-Received: by with SMTP id jt14mr16103346bkb.3.1384862375167; Tue, 19 Nov 2013 03:59:35 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id j6sm9557297bki.17.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 03:59:34 -0800 (PST)
Message-ID: <>
Date: Tue, 19 Nov 2013 13:00:42 +0100
From: Maik Merten <>
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 11:59:43 -0000

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.