[FFmpeg-devel] FFV1 Specification
Michael Niedermayer
michaelni at gmx.at
Sun Apr 8 13:58:34 CEST 2012
On Sun, Apr 08, 2012 at 11:57:08AM +0200, Reimar Döffinger wrote:
> On Sun, Apr 08, 2012 at 11:03:00AM +0200, Peter B. wrote:
[...]
> > Almost all codecs/formats that have become standards in the
> > digital-video domain provide means of handling bit-errors. Personally, I
> > agree with you: I think bit-error resilience is a requirement that
> > origins from the idea of "classic" video media.
> > However, it is often mentioned thought of as a very important feature of
> > a professional video codec, because it makes people sleep better :)
>
> bit-errors are just something that doesn't really happen. If anything it will
> be large corruption of any kind.
> And even with the MPEG codecs you end up just replacing (most of) the
> frame with the reference frame.
> IMO that leaves two questions open
> 1) Can you reliably detect a corrupted frame in FFV1? Not sure about
> that. Having some kind of checksum that protects the whole encode ->
> decode chain like it is usually done for lossless audio might be nice.
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.
> 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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- 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/1edac1d0/attachment.asc>
More information about the ffmpeg-devel
mailing list