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

compn tempn at twmi.rr.com
Sat Aug 17 16:10:08 CEST 2013

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?

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


More information about the ffmpeg-devel mailing list