[FFmpeg-devel] FFV1 Specification

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Apr 8 12:59:09 CEST 2012

On Sun, Apr 08, 2012 at 12:35:15PM +0200, Peter B. wrote:
> 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?

I don't think it's a necessity, but usually that is one of the results.
But I also meant to say that wavelets haven't shown themselves that
great for image compression.
Then there is also a speed issue. And if I remember right, FFV1 uses a
massive (to not say "insane") number of contexts in the arithmetic
coding mode, which I think is kind of unique.
Generally I wanted to say that a lot of compression wins is not about
using the latest fad but getting the details right.
(For example for MPEG-4 ASP vs. H264 there are a lot of small things
like requiring bit-exact decoding, making deblock filters - not really
a new idea at the time - part of the decoder etc. that made a lot of
difference taken together).

> > 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?

Yes. I am not sure I like it that much, but it is an easy way to verify
everything worked right (and could be used to enable bug workarounds
in an automated way for example)...

More information about the ffmpeg-devel mailing list