[FFmpeg-devel] FFV1 Specification
Michael Niedermayer
michaelni at gmx.at
Sun Apr 8 14:36:55 CEST 2012
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/b87b9745/attachment.asc>
More information about the ffmpeg-devel
mailing list