[FFmpeg-devel] FFV1 Specification

[Reimar Döffinger]

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