[FFmpeg-devel] FFV1 Specification

[Michael Niedermayer]

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 ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- 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/6c0be2d8/attachment.asc>