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

[Maik Merten <[e-mail]>]

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.


Maik