Skip to content

Latest commit

 

History

History
208 lines (171 loc) · 8.73 KB

rfc_backmatter.md

File metadata and controls

208 lines (171 loc) · 8.73 KB

{backmatter}

<title>Information technology - Programming languages - C</title> International Organization for Standardization ISO/IEC 9899:2018 <title>Information technology -- JPEG 2000 image coding system: Core coding system</title> International Organization for Standardization ISO/IEC 15444-1:2019 <title>Information technology -- Lossless and near-lossless compression of continuous-tone still images: Baseline</title> International Organization for Standardization ISO/IEC 14495-1:1999 <title>Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding</title> International Organization for Standardization ISO/IEC 14496-10:2020 <title>Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format</title> International Organization for Standardization ISO/IEC 14496-12:2020 <title>Range encoding: an algorithm for removing redundancy from a digitised message</title> Proceedings of the Conference on Video and Data Recording Institution of Electronic and Radio Engineers, Hampshire, England <title>AVI RIFF File Reference</title> Microsoft <title>HuffYUV revisited</title> <title>NUT Open Container Format</title> <title>Valgrind website</title> Valgrind Developers <title>AddressSanitizer</title> Clang Project Clang 12 documentation <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>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>

Multithreaded 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 multithreading 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 the 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 Slice boundaries. A decoder MAY fall back on sequential order e.g., in case of a corrupted Frame (e.g., frame size unknown or slice_size of Slices not coherent) or if there is no possibility of seeking into the stream.

Future Handling of Some Streams Created by Nonconforming 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 avoid adding 40 bits of content after SliceContent if version == 0 or version == 1, otherwise 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 [@Valgrind] as well as the Clang AddressSanitizer [@AddressSanitizer], which tracks 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 [@FFV1GO] was written in Go by Derek Buitenhuis during the work to develop 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 draft versions of this document. These issues are addressed by (#exception), (#rgb-exception), and (#future-handling-of-some-streams-created-by-nonconforming-encoders).