[FFmpeg-devel] FFV1 Specification

[David Rice]

On Apr 8, 2012, at 6:59 AM, Reimar Döffinger wrote:

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

I'm just catching up on the ffv1 discussion. Glad to see it.
The embedded checksum idea came from a discussion on using ffv1 in a long term digital preservation environment. I've been using the framemd5 output stored as a sidecar file to ffv1 files (along with a traditional whole file checksum). If there was even a mismatch of the file against the whole-file checksum, the framemd5 output allows the error to do located much more specifically.

Since sidecar framemd5 files are another step, I was thinking of how the flac file format includes an embedded md5 of the audio data that should be decoded. This allows the file to be somewhat self checking. I think something similar with ffv1 frames would help pinpoint and potentially resolve digital errors.
Dave Rice