[FFmpeg-devel] FFV1 Specification

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Apr 8 11:57:08 CEST 2012

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.

> Almost all codecs/formats that have become standards in the
> digital-video domain provide means of handling bit-errors. Personally, I
> agree with you: I think bit-error resilience is a requirement that
> origins from the idea of "classic" video media.
> However, it is often mentioned thought of as a very important feature of
> a professional video codec, because it makes people sleep better :)

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.

> Sure it'd be a nice thing, but I think it's more a requirement for
> codecs used in different use cases, such as broadcasting over unreliable
> channels (e.g. Satellite, ...).

Most DVB decoders break down completely on stream errors, so in reality
nobody really cares. Also you'll never lose more than one frame with
FFV1, and you can throw enough error correction around it that is
optimized to the transmission method to make that a rare event.
If you can't make bit errors rare, using a lossless codec is really
silly in the first place IMO.

More information about the ffmpeg-devel mailing list