Skip to content

Latest commit

 

History

History
218 lines (178 loc) · 8.62 KB

rfc_backmatter.md

File metadata and controls

218 lines (178 loc) · 8.62 KB

{backmatter}

<title>Programming languages - C</title> International Organization for Standardization <title>Information technology -- JPEG 2000 image coding system: Core coding system</title> International Organization for Standardization <title>Information technology -- Lossless and near-lossless compression of continuous-tone still images: Baseline</title> International Organization for Standardization <title>Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding</title> International Organization for Standardization <title>Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format</title> International Organization for Standardization <title>Range encoding: an algorithm for removing redundancy from a digitised message</title> <title>AVI RIFF File Reference</title> Microsoft <title>HuffYUV</title> <title>NUT Open Container Format</title> <title>Valgrind website</title> Valgrind Developers <title>ASAN AddressSanitizer website</title> The Clang Team <title>The reference FFV1 implementation / the FFV1 codec in FFmpeg</title> <title>FFV1 Decoder in Go</title> <title>MediaConch</title> MediaArea.net <title>YCbCr</title> Wikipedia <title>Matroska</title> IETF <title>Commit to mark FFV1 version 0 as non-experimental</title> <title>Commit to release FFV1 version 1</title> <title>Commit to mark FFV1 version 3 as non-experimental</title>

Multi-theaded decoder implementation suggestions

This appendix is informative.

The FFV1 bitstream is parsable in two ways: in sequential order as described in this document or with the pre-analysis of the footer of each slice. Each slice footer contains a slice_size field so the boundary of each slice is computable without having to parse the slice content. That allows multi-threading as well as independence of slice content (a bitstream error in a slice header or slice content has no impact on the decoding of the other slices).

After having checked keyframe field, a decoder SHOULD parse slice_size fields, from slice_size of the last slice at the end of the Frame up to slice_size of the first slice at the beginning of the Frame, before parsing slices, in order to have slices boundaries. A decoder MAY fallback on sequential order e.g. in case of a corrupted Frame (frame size unknown, slice_size of slices not coherent...) or if there is no possibility of seeking into the stream.

Future handling of some streams created by non conforming encoders

This appendix is informative.

Some bitstreams were found with 40 extra bits corresponding to error_status and slice_crc_parity in the reserved bits of Slice(). Any revision of this specification SHOULD care about avoiding to add 40 bits of content after SliceContent if version == 0 or version == 1. Else a decoder conforming to the revised specification could not distinguish between a revised bitstream and such buggy bitstream in the wild.

FFV1 Implementations

This appendix provides references to a few notable implementations of FFV1.

FFmpeg FFV1 Codec

This reference implementation [@REFIMPL] contains no known buffer overflow or cases where a specially crafted packet or video segment could cause a significant increase in CPU load.

The reference implementation [@REFIMPL] was validated in the following conditions:

  • Sending the decoder valid packets generated by the reference encoder and verifying that the decoder's output matches the encoder's input.
  • Sending the decoder packets generated by the reference encoder and then subjected to random corruption.
  • Sending the decoder random packets that are not FFV1.

In all of the conditions above, the decoder and encoder was run inside the [@VALGRIND] memory debugger as well as clangs address sanitizer [@Address-Sanitizer], which track reads and writes to invalid memory regions as well as the use of uninitialized memory. There were no errors reported on any of the tested conditions.

FFV1 Decoder in Go

An FFV1 decoder was [@FFV1GO] written in Go by Derek Buitenhuis during the work to development this document.

MediaConch

The developers of the MediaConch project [@MediaConch] created an independent FFV1 decoder as part of that project to validate FFV1 bitstreams. This work led to the discovery of three conflicts between existing FFV1 implementations and this document without the added exceptions.