[FFmpeg-devel] [PATCH] ffv1enc: Make ffv1.3 non experimental

[Dave Rice]

On Aug 17, 2013, at 10:10 AM, compn <tempn at twmi.rr.com> wrote:
> On Sat, 17 Aug 2013 15:27:43 +0200, wm4 wrote:
>> On Sat, 17 Aug 2013 13:33:27 +0200
>> Michael Niedermayer <michaelni at gmx.at> wrote:
>> 
>>> On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
>>>> On 17.08.2013, at 05:00, Michael Niedermayer <michaelni at gmx.at> wrote:
>>>> 
>>>>> The fate tests change as they used 1.2 previously
>>>> 
>>>> It's fairly minimal, but is it expected that every single frame becomes larger?
>>> 
>>> 1.3 adds 32bit CRCs per slice by default (can be disabled),
>>> it adds slice headers to allow decoding one slice without the others
>>> an additional slice size field is added to make it possible to find
>>> slices within corrupted surroundings.
>>> 
>>> these add up to about 57bit per slice more
>>> at 50 frames and 4 slices thats 1425 byte which comes close to the
>>> actual difference, so i would say that explains the difference
>> 
>> I'm just curious: isn't CRC a pretty slow checksum algorithm? Why are
>> checksums needed at all, isn't that the responsibility of the
>> container, if it should be inside the file at all?

I've seen this for FLAC with audio but is there a container for video that can contain losslessly encoded video and document that data with checksums?

> read up on previous ffv1 threads. it was requested from multiple users
> that it needed frame checksums. either because they use it as rawvideo
> without a container or because they mux it into a container later.
> 
> when people use ffv1 for archiving , they want as many checks as
> possible :)

I was one of the requestors and one of those who use ffv1 in archival work (mostly for losslessly encoding the results of the digitization of analog video). I see the integration of frame checksums to create a video equivalent of the advantages of FLAC within digital preservation. FLAC stores a checksum of the encoded audio in its header so the entire flac encoding may be assessed as valid or invalid on future inspection and if the FLAC is invalid, then the embedded crc's can direct you to a close location of where the digital error is. FFV1 version 3 offers a similar function in that digital corruption of any FFV1 version 3 encoding may be identified from the point of encoding onward without requiring external checksum workflows or storage of framemd5 files. If interested I wrote up more on this here: http://dericed.com/papers/reconsidering-the-checksum-for-audiovisual-preservation.

Dave Rice