[FFmpeg-devel] FFV1 Specification

[Peter B.]

On 04/08/2012 11:57 AM, Reimar Döffinger wrote:
> On Sun, Apr 08, 2012 at 11:03:00AM +0200, Peter B. wrote:
>> Additionally, I don't understand how FFv1's compression is so effective,
>> if the used algorithms are rather old (Range coder: 1979, Huffman: 1952).
>> Why is it, that these can compete with JPEG2000's heavy-lifting Wavelet
>> compression?
> JPEG2000 in the lossless variant in some tests even loses to JPEG.
> It seems likely that J2k performs badly because, not despite using
> wavelets. Despite some nice properties in theory I haven't seen much
> evidence that they are any better than the old methods, even less so
> considering much less experience in using them and that worse
> performance in at least one use case is the usual result of trying to
> use the same algorithm for both lossy and lossless compression.
Very interesting!
thanks for this explanation.
Did I understand you correctly, that using the same algorithm for lossy
and lossless causes these disadvantage (performance/compression),
compared to a e.g. a lossless-only codec like FFv1?


> bit-errors are just something that doesn't really happen. If anything it will
> be large corruption of any kind.
> And even with the MPEG codecs you end up just replacing (most of) the
> frame with the reference frame.
> IMO that leaves two questions open
> 1) Can you reliably detect a corrupted frame in FFV1? Not sure about
> that. Having some kind of checksum that protects the whole encode ->
> decode chain like it is usually done for lossless audio might be nice.
> 2) Can you decode the next frame. Since FFV1 does not specify the
> container, that is not a property of FFV1. If you store it in e.g.
> NUT the answer is "better than with any MPEG-format", if you would store
> it in mov/mp4 the answer would be "about the same as for e.g. Intra-only H.264"
> I'd say.
Dave Rice once mentioned the idea of embedding per-frame checksums
within FFV1's stream. Sounds like what you're mentioning as an option
here, right?


> If you can't make bit errors rare, using a lossless codec is really
> silly in the first place IMO.
:)
totally agree!


Thanks,
Pb