rfc_backmatter.md

{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>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> <title>Programming languages - C</title> International Organization for Standardization

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.