[FFmpeg-devel] FFV1 Specification

[Reimar Döffinger]

On Sun, Apr 08, 2012 at 03:16:20PM +0200, Michael Niedermayer wrote:
> On Sun, Apr 08, 2012 at 02:45:45PM +0200, Michael Niedermayer wrote:
> > On Sun, Apr 08, 2012 at 02:36:55PM +0200, Michael Niedermayer wrote:
> > > On Sun, Apr 08, 2012 at 02:21:38PM +0200, Peter B. wrote:
> > > > On 04/08/2012 01:58 PM, Michael Niedermayer wrote:
> > > > > Its unlikely that decoding a damaged frame will have the end-of-stream
> > > > > matching with the end of the pixels. So id say 99% of the damaged
> > > > > frames should be detectable that way. Detection failure should become
> > > > > a problem though when the error is close to the end of the frame.
> > > > > Adding a checksum should be no problem, that can be done.
> > > > Just to avoid confusion on my side:
> > > > The word "frame" here applies to a video-frame or something like a
> > > > data-frame inside the bitstream?
> > > 
> > > video frame, yes
> > > 
> > > 
> > > > 
> > > > 
> > > > >> 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.
> > > > > yes but dont forget ffv1 can reuse range coder contexts over frames
> > > > > so one has to set the gop size to 1 if this kind of next frame recovery
> > > > > is important to them
> > > > >
> > > > Interesting to hear that.
> > > > These are exactly the "small details" which I'd love to find when
> > > > reading docs about FFv1 :)
> > > > I thought that when using an intra-frame-only codec, all frames are
> > > > self-contained and there'd be no GOPs. Am I getting something wrong here?
> > > 
> > > they are intra frames in the sense that there is no motion
> > > compensation. The previous frame(s) also dont need to be kept as
> > > reference frames, but the contexts can be reset once per frame or
> > > less often to improve compression performance
> > > 
> > > The ffv1 spec does mention this:
> > >     Initial values for the context model
> > > 
> > >     At keyframes all range coder state variables are set to 128
> > > this implicates that no keyframe -> no reset
> > 
> > but reading this again, this should be written in a more direct way
> > because as is its easy to miss it.
> > 
> > maybe you could suggest some text ?
> 
> Also in relation to this (10 seconds from the matrix lobby scene)
> using rangecoding and the larger context model:
> ffv1    GOP=300     23736978
> ffv1    GOP=1       25056734
> 
> ffv1.2  GOP=300     23648224
> ffv1.2  GOP=1       23645074
> 
> and ffv1.2 does low latency multithreaded encoding & decoding for all
> who dont know that yet ...

Larger GOP values giving larger file size is not really the expected
behaviour though I have to say...