[FFmpeg-devel] FFV1 Specification

[Michael Niedermayer]

On Sun, Apr 08, 2012 at 04:04:03PM +0200, Reimar Döffinger wrote:
> 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...

I dunno, its not so unexpected
for gop 1 each slice starts with a good average optimized state
for gop 300 most slices use the previous slices state, this as such
would likely be better but its not exactly what happens rather the
left top starts using the coder state of the previous slices bottom
right and with the matrix lobby scene with 4 rectangular slices the
tops and bottoms allways are in a different area (black border vs
picture) this likely gives a penalty relative to starting with
a middle average state

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120408/64cd563b/attachment.asc>