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

wm4 nfxjfg at googlemail.com
Sun Aug 18 02:28:42 CEST 2013


On Sat, 17 Aug 2013 19:54:04 -0400
Dave Rice <dave at dericed.com> wrote:

> 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?

I thought that could be added to NUT, which is AFAIK the native
container for this video codec? (Or a least it's a container format
created by FFmpeg.)


More information about the ffmpeg-devel mailing list