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

[Harald Alvestrand <[e-mail]>]

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".