doc: Add RFC documents

1 files changed, 2562 insertions, 0 deletions

diff --git a/doc/rfc/rfc9043.txt b/doc/rfc/rfc9043.txt
new file mode 100644
index 0000000..df9d58b
--- /dev/null
+++ b/doc/rfc/rfc9043.txt
@@ -0,0 +1,2562 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                    M. Niedermayer
+Request for Comments: 9043                                              
+Category: Informational                                          D. Rice
+ISSN: 2070-1721                                                         
+                                                             J. Martinez
+                                                             August 2021
+
+
+             FFV1 Video Coding Format Versions 0, 1, and 3
+
+Abstract
+
+   This document defines FFV1, a lossless, intra-frame video encoding
+   format.  FFV1 is designed to efficiently compress video data in a
+   variety of pixel formats.  Compared to uncompressed video, FFV1
+   offers storage compression, frame fixity, and self-description, which
+   makes FFV1 useful as a preservation or intermediate video format.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9043.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Notation and Conventions
+     2.1.  Definitions
+     2.2.  Conventions
+       2.2.1.  Pseudocode
+       2.2.2.  Arithmetic Operators
+       2.2.3.  Assignment Operators
+       2.2.4.  Comparison Operators
+       2.2.5.  Mathematical Functions
+       2.2.6.  Order of Operation Precedence
+       2.2.7.  Range
+       2.2.8.  NumBytes
+       2.2.9.  Bitstream Functions
+   3.  Sample Coding
+     3.1.  Border
+     3.2.  Samples
+     3.3.  Median Predictor
+       3.3.1.  Exception
+     3.4.  Quantization Table Sets
+     3.5.  Context
+     3.6.  Quantization Table Set Indexes
+     3.7.  Color Spaces
+       3.7.1.  YCbCr
+       3.7.2.  RGB
+     3.8.  Coding of the Sample Difference
+       3.8.1.  Range Coding Mode
+       3.8.2.  Golomb Rice Mode
+   4.  Bitstream
+     4.1.  Quantization Table Set
+       4.1.1.  "quant_tables"
+       4.1.2.  "context_count"
+     4.2.  Parameters
+       4.2.1.  "version"
+       4.2.2.  "micro_version"
+       4.2.3.  "coder_type"
+       4.2.4.  "state_transition_delta"
+       4.2.5.  "colorspace_type"
+       4.2.6.  "chroma_planes"
+       4.2.7.  "bits_per_raw_sample"
+       4.2.8.  "log2_h_chroma_subsample"
+       4.2.9.  "log2_v_chroma_subsample"
+       4.2.10. "extra_plane"
+       4.2.11. "num_h_slices"
+       4.2.12. "num_v_slices"
+       4.2.13. "quant_table_set_count"
+       4.2.14. "states_coded"
+       4.2.15. "initial_state_delta"
+       4.2.16. "ec"
+       4.2.17. "intra"
+     4.3.  Configuration Record
+       4.3.1.  "reserved_for_future_use"
+       4.3.2.  "configuration_record_crc_parity"
+       4.3.3.  Mapping FFV1 into Containers
+     4.4.  Frame
+     4.5.  Slice
+     4.6.  Slice Header
+       4.6.1.  "slice_x"
+       4.6.2.  "slice_y"
+       4.6.3.  "slice_width"
+       4.6.4.  "slice_height"
+       4.6.5.  "quant_table_set_index_count"
+       4.6.6.  "quant_table_set_index"
+       4.6.7.  "picture_structure"
+       4.6.8.  "sar_num"
+       4.6.9.  "sar_den"
+     4.7.  Slice Content
+       4.7.1.  "primary_color_count"
+       4.7.2.  "plane_pixel_height"
+       4.7.3.  "slice_pixel_height"
+       4.7.4.  "slice_pixel_y"
+     4.8.  Line
+       4.8.1.  "plane_pixel_width"
+       4.8.2.  "slice_pixel_width"
+       4.8.3.  "slice_pixel_x"
+       4.8.4.  "sample_difference"
+     4.9.  Slice Footer
+       4.9.1.  "slice_size"
+       4.9.2.  "error_status"
+       4.9.3.  "slice_crc_parity"
+   5.  Restrictions
+   6.  Security Considerations
+   7.  IANA Considerations
+     7.1.  Media Type Definition
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Appendix A.  Multithreaded Decoder Implementation Suggestions
+   Appendix B.  Future Handling of Some Streams Created by
+           Nonconforming Encoders
+   Appendix C.  FFV1 Implementations
+     C.1.  FFmpeg FFV1 Codec
+     C.2.  FFV1 Decoder in Go
+     C.3.  MediaConch
+   Authors' Addresses
+
+1.  Introduction
+
+   This document describes FFV1, a lossless video encoding format.  The
+   design of FFV1 considers the storage of image characteristics, data
+   fixity, and the optimized use of encoding time and storage
+   requirements.  FFV1 is designed to support a wide range of lossless
+   video applications such as long-term audiovisual preservation,
+   scientific imaging, screen recording, and other video encoding
+   scenarios that seek to avoid the generational loss of lossy video
+   encodings.
+
+   This document defines versions 0, 1, and 3 of FFV1.  The distinctions
+   of the versions are provided throughout the document, but in summary:
+
+   *  Version 0 of FFV1 was the original implementation of FFV1 and was
+      flagged as stable on April 14, 2006 [FFV1_V0].
+
+   *  Version 1 of FFV1 adds support of more video bit depths and was
+      flagged as stable on April 24, 2009 [FFV1_V1].
+
+   *  Version 2 of FFV1 only existed in experimental form and is not
+      described by this document, but it is available as a LyX file at
+      <https://github.com/FFmpeg/FFV1/
+      blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx>.
+
+   *  Version 3 of FFV1 adds several features such as increased
+      description of the characteristics of the encoding images and
+      embedded Cyclic Redundancy Check (CRC) data to support fixity
+      verification of the encoding.  Version 3 was flagged as stable on
+      August 17, 2013 [FFV1_V3].
+
+   This document assumes familiarity with mathematical and coding
+   concepts such as Range encoding [Range-Encoding] and YCbCr color
+   spaces [YCbCr].
+
+   This specification describes the valid bitstream and how to decode
+   it.  Nonconformant bitstreams and the nonconformant handling of
+   bitstreams are outside this specification.  A decoder can perform any
+   action that it deems appropriate for an invalid bitstream: reject the
+   bitstream, attempt to perform error concealment, or re-download or
+   use a redundant copy of the invalid part.
+
+2.  Notation and Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.1.  Definitions
+
+   FFV1:  The chosen name of this video encoding format, which is the
+      short version of "FF Video 1".  The letters "FF" come from
+      "FFmpeg", which is the name of the reference decoder whose first
+      letters originally meant "Fast Forward".
+
+   Container:  A format that encapsulates Frames (see Section 4.4) and
+      (when required) a "Configuration Record" into a bitstream.
+
+   Sample:  The smallest addressable representation of a color component
+      or a luma component in a Frame.  Examples of Sample are Luma (Y),
+      Blue-difference Chroma (Cb), Red-difference Chroma (Cr),
+      Transparency, Red, Green, and Blue.
+
+   Symbol:  A value stored in the bitstream, which is defined and
+      decoded through one of the methods described in Table 4.
+
+   Line:  A discrete component of a static image composed of Samples
+      that represent a specific quantification of Samples of that image.
+
+   Plane:  A discrete component of a static image composed of Lines that
+      represent a specific quantification of Lines of that image.
+
+   Pixel:  The smallest addressable representation of a color in a
+      Frame.  It is composed of one or more Samples.
+
+   MSB:  Most Significant Bit, the bit that can cause the largest change
+      in magnitude of the symbol.
+
+   VLC:  Variable Length Code, a code that maps source symbols to a
+      variable number of bits.
+
+   RGB:  A reference to the method of storing the value of a pixel by
+      using three numeric values that represent Red, Green, and Blue.
+
+   YCbCr:  A reference to the method of storing the value of a pixel by
+      using three numeric values that represent the luma of the pixel
+      (Y) and the chroma of the pixel (Cb and Cr).  The term YCbCr is
+      used for historical reasons and currently references any color
+      space relying on one luma Sample and two chroma Samples, e.g.,
+      YCbCr (luma, blue-difference chroma, red-difference chroma),
+      YCgCo, or ICtCp (intensity, blue-yellow, red-green).
+
+2.2.  Conventions
+
+2.2.1.  Pseudocode
+
+   The FFV1 bitstream is described in this document using pseudocode.
+   Note that the pseudocode is used to illustrate the structure of FFV1
+   and is not intended to specify any particular implementation.  The
+   pseudocode used is based upon the C programming language
+   [ISO.9899.2018] and uses its "if/else", "while", and "for" keywords
+   as well as functions defined within this document.
+
+   In some instances, pseudocode is presented in a two-column format
+   such as shown in Figure 1.  In this form, the "type" column provides
+   a symbol as defined in Table 4 that defines the storage of the data
+   referenced in that same line of pseudocode.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   ExamplePseudoCode( ) {                                        |
+       value                                                     | ur
+   }                                                             |
+
+     Figure 1: A depiction of type-labeled pseudocode used within this
+                                 document.
+
+2.2.2.  Arithmetic Operators
+
+   Note: the operators and the order of precedence are the same as used
+   in the C programming language [ISO.9899.2018], with the exception of
+   ">>" (removal of implementation-defined behavior) and "^" (power
+   instead of XOR) operators, which are redefined within this section.
+
+   "a + b" means a plus b.
+
+   "a - b" means a minus b.
+
+   "-a" means negation of a.
+
+   "a * b" means a multiplied by b.
+
+   "a / b" means a divided by b.
+
+   "a ^ b" means a raised to the b-th power.
+
+   "a & b" means bitwise "and" of a and b.
+
+   "a | b" means bitwise "or" of a and b.
+
+   "a >> b" means arithmetic right shift of the two's complement integer
+   representation of a by b binary digits.  This is equivalent to
+   dividing a by 2, b times, with rounding toward negative infinity.
+
+   "a << b" means arithmetic left shift of the two's complement integer
+   representation of a by b binary digits.
+
+2.2.3.  Assignment Operators
+
+   "a = b" means a is assigned b.
+
+   "a++" is equivalent to a is assigned a + 1.
+
+   "a--" is equivalent to a is assigned a - 1.
+
+   "a += b" is equivalent to a is assigned a + b.
+
+   "a -= b" is equivalent to a is assigned a - b.
+
+   "a *= b" is equivalent to a is assigned a * b.
+
+2.2.4.  Comparison Operators
+
+   "a > b" is true when a is greater than b.
+
+   "a >= b" is true when a is greater than or equal to b.
+
+   "a < b" is true when a is less than b.
+
+   "a <= b" is true when a is less than or equal b.
+
+   "a == b" is true when a is equal to b.
+
+   "a != b" is true when a is not equal to b.
+
+   "a && b" is true when both a is true and b is true.
+
+   "a || b" is true when either a is true or b is true.
+
+   "!a" is true when a is not true.
+
+   "a ? b : c" if a is true, then b, otherwise c.
+
+2.2.5.  Mathematical Functions
+
+   "floor(a)" means the largest integer less than or equal to a.
+
+   "ceil(a)" means the smallest integer greater than or equal to a.
+
+   "sign(a)" extracts the sign of a number, i.e., if a < 0 then -1, else
+   if a > 0 then 1, else 0.
+
+   "abs(a)" means the absolute value of a, i.e., "abs(a)" = "sign(a) *
+   a".
+
+   "log2(a)" means the base-two logarithm of a.
+
+   "min(a,b)" means the smaller of two values a and b.
+
+   "max(a,b)" means the larger of two values a and b.
+
+   "median(a,b,c)" means the numerical middle value in a data set of a,
+   b, and c, i.e., "a+b+c-min(a,b,c)-max(a,b,c)".
+
+   "a ==> b" means a implies b.
+
+   "a <==> b" means a ==> b, b ==> a.
+
+   "a_b" means the b-th value of a sequence of a.
+
+   "a_(b,c)" means the 'b,c'-th value of a sequence of a.
+
+2.2.6.  Order of Operation Precedence
+
+   When order of precedence is not indicated explicitly by use of
+   parentheses, operations are evaluated in the following order (from
+   top to bottom, operations of same precedence being evaluated from
+   left to right).  This order of operations is based on the order of
+   operations used in Standard C.
+
+   a++, a--
+   !a, -a
+   a ^ b
+   a * b, a / b
+   a + b, a - b
+   a << b, a >> b
+   a < b, a <= b, a > b, a >= b
+   a == b, a != b
+   a & b
+   a | b
+   a && b
+   a || b
+   a ? b : c
+   a = b, a += b, a -= b, a *= b
+
+2.2.7.  Range
+
+   "a...b" means any value from a to b, inclusive.
+
+2.2.8.  NumBytes
+
+   "NumBytes" is a nonnegative integer that expresses the size in 8-bit
+   octets of a particular FFV1 "Configuration Record" or "Frame".  FFV1
+   relies on its container to store the "NumBytes" values; see
+   Section 4.3.3.
+
+2.2.9.  Bitstream Functions
+
+2.2.9.1.  remaining_bits_in_bitstream
+
+   "remaining_bits_in_bitstream( NumBytes )" means the count of
+   remaining bits after the pointer in that "Configuration Record" or
+   "Frame".  It is computed from the "NumBytes" value multiplied by 8
+   minus the count of bits of that "Configuration Record" or "Frame"
+   already read by the bitstream parser.
+
+2.2.9.2.  remaining_symbols_in_syntax
+
+   "remaining_symbols_in_syntax( )" is true as long as the range coder
+   has not consumed all the given input bytes.
+
+2.2.9.3.  byte_aligned
+
+   "byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes
+   )" is a multiple of 8, otherwise false.
+
+2.2.9.4.  get_bits
+
+   "get_bits( i )" is the action to read the next "i" bits in the
+   bitstream, from most significant bit to least significant bit, and to
+   return the corresponding value.  The pointer is increased by "i".
+
+3.  Sample Coding
+
+   For each "Slice" (as described in Section 4.5) of a Frame, the
+   Planes, Lines, and Samples are coded in an order determined by the
+   color space (see Section 3.7).  Each Sample is predicted by the
+   median predictor as described in Section 3.3 from other Samples
+   within the same Plane, and the difference is stored using the method
+   described in Section 3.8.
+
+3.1.  Border
+
+   A border is assumed for each coded "Slice" for the purpose of the
+   median predictor and context according to the following rules:
+
+   *  One column of Samples to the left of the coded Slice is assumed as
+      identical to the Samples of the leftmost column of the coded Slice
+      shifted down by one row.  The value of the topmost Sample of the
+      column of Samples to the left of the coded Slice is assumed to be
+      "0".
+
+   *  One column of Samples to the right of the coded Slice is assumed
+      as identical to the Samples of the rightmost column of the coded
+      Slice.
+
+   *  An additional column of Samples to the left of the coded Slice and
+      two rows of Samples above the coded Slice are assumed to be "0".
+
+   Figure 2 depicts a Slice of nine Samples "a,b,c,d,e,f,g,h,i" in a
+   three-by-three arrangement along with its assumed border.
+
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 |   | 0 | 0 | 0 |   | 0 |
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 |   | 0 | 0 | 0 |   | 0 |
+   +---+---+---+---+---+---+---+---+
+   |   |   |   |   |   |   |   |   |
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 |   | a | b | c |   | c |
+   +---+---+---+---+---+---+---+---+
+   | 0 | a |   | d | e | f |   | f |
+   +---+---+---+---+---+---+---+---+
+   | 0 | d |   | g | h | i |   | i |
+   +---+---+---+---+---+---+---+---+
+
+        Figure 2: A depiction of FFV1's assumed border for a set of
+                              example Samples.
+
+3.2.  Samples
+
+   Relative to any Sample "X", six other relatively positioned Samples
+   from the coded Samples and presumed border are identified according
+   to the labels used in Figure 3.  The labels for these relatively
+   positioned Samples are used within the median predictor and context.
+
+   +---+---+---+---+
+   |   |   | T |   |
+   +---+---+---+---+
+   |   |tl | t |tr |
+   +---+---+---+---+
+   | L | l | X |   |
+   +---+---+---+---+
+
+       Figure 3: A depiction of how relatively positioned Samples are
+                      referenced within this document.
+
+   The labels for these relative Samples are made of the first letters
+   of the words Top, Left, and Right.
+
+3.3.  Median Predictor
+
+   The prediction for any Sample value at position "X" may be computed
+   based upon the relative neighboring values of "l", "t", and "tl" via
+   this equation:
+
+   median(l, t, l + t - tl)
+
+   Note that this prediction template is also used in [ISO.14495-1.1999]
+   and [HuffYUV].
+
+3.3.1.  Exception
+
+   If "colorspace_type == 0 && bits_per_raw_sample == 16 && ( coder_type
+   == 1 || coder_type == 2 )" (see Sections 4.2.5, 4.2.7, and 4.2.3),
+   the following median predictor MUST be used:
+
+   median(left16s, top16s, left16s + top16s - diag16s)
+
+   where:
+
+   left16s = l  >= 32768 ? ( l  - 65536 ) : l
+   top16s  = t  >= 32768 ? ( t  - 65536 ) : t
+   diag16s = tl >= 32768 ? ( tl - 65536 ) : tl
+
+   Background: a two's complement 16-bit signed integer was used for
+   storing Sample values in all known implementations of FFV1 bitstream
+   (see Appendix C).  So in some circumstances, the most significant bit
+   was wrongly interpreted (used as a sign bit instead of the 16th bit
+   of an unsigned integer).  Note that when the issue was discovered,
+   the only impacted configuration of all known implementations was the
+   16-bit YCbCr with no pixel transformation and with the range coder
+   coder type, as the other potentially impacted configurations (e.g.,
+   the 15/16-bit JPEG 2000 Reversible Color Transform (RCT)
+   [ISO.15444-1.2019] with range coder or the 16-bit content with the
+   Golomb Rice coder type) were not implemented.  Meanwhile, the 16-bit
+   JPEG 2000 RCT with range coder was deployed without this issue in one
+   implementation and validated by one conformance checker.  It is
+   expected (to be confirmed) that this exception for the median
+   predictor will be removed in the next version of the FFV1 bitstream.
+
+3.4.  Quantization Table Sets
+
+   Quantization Tables are used on Sample Differences (see Section 3.8),
+   so Quantized Sample Differences are stored in the bitstream.
+
+   The FFV1 bitstream contains one or more Quantization Table Sets.
+   Each Quantization Table Set contains exactly five Quantization Tables
+   with each Quantization Table corresponding to one of the five
+   Quantized Sample Differences.  For each Quantization Table, both the
+   number of quantization steps and their distribution are stored in the
+   FFV1 bitstream; each Quantization Table has exactly 256 entries, and
+   the eight least significant bits of the Quantized Sample Difference
+   are used as an index:
+
+   Q_j[k] = quant_tables[i][j][k&255]
+
+    Figure 4: Description of the mapping from sample differences to the
+                corresponding Quantized Sample Differences.
+
+   In this formula, "i" is the Quantization Table Set index, "j" is the
+   Quantized Table index, and "k" is the Quantized Sample Difference
+   (see Section 4.1.1).
+
+3.5.  Context
+
+   Relative to any Sample "X", the Quantized Sample Differences "L-l",
+   "l-tl", "tl-t", "T-t", and "t-tr" are used as context:
+
+   context = Q_0[l - tl] +
+             Q_1[tl - t] +
+             Q_2[t - tr] +
+             Q_3[L - l]  +
+             Q_4[T - t]
+
+           Figure 5: Description of the computing of the Context.
+
+   If "context >= 0" then "context" is used, and the difference between
+   the Sample and its predicted value is encoded as is; else "-context"
+   is used, and the difference between the Sample and its predicted
+   value is encoded with a flipped sign.
+
+3.6.  Quantization Table Set Indexes
+
+   For each Plane of each Slice, a Quantization Table Set is selected
+   from an index:
+
+   *  For Y Plane, "quant_table_set_index[ 0 ]" index is used.
+
+   *  For Cb and Cr Planes, "quant_table_set_index[ 1 ]" index is used.
+
+   *  For extra Plane, "quant_table_set_index[ (version <= 3 ||
+      chroma_planes) ? 2 : 1 ]" index is used.
+
+   Background: in the first implementations of the FFV1 bitstream, the
+   index for Cb and Cr Planes was stored even if it was not used
+   ("chroma_planes" set to 0), this index is kept for "version <= 3" in
+   order to keep compatibility with FFV1 bitstreams in the wild.
+
+3.7.  Color Spaces
+
+   FFV1 supports several color spaces.  The count of allowed coded
+   Planes and the meaning of the extra Plane are determined by the
+   selected color space.
+
+   The FFV1 bitstream interleaves data in an order determined by the
+   color space.  In YCbCr for each Plane, each Line is coded from top to
+   bottom, and for each Line, each Sample is coded from left to right.
+   In JPEG 2000 RCT for each Line from top to bottom, each Plane is
+   coded, and for each Plane, each Sample is encoded from left to right.
+
+3.7.1.  YCbCr
+
+   This color space allows one to four Planes.
+
+   The Cb and Cr Planes are optional, but if they are used, then they
+   MUST be used together.  Omitting the Cb and Cr Planes codes the
+   frames in gray scale without color data.
+
+   An optional transparency Plane can be used to code transparency data.
+
+   An FFV1 Frame using YCbCr MUST use one of the following arrangements:
+
+   *  Y
+
+   *  Y, Transparency
+
+   *  Y, Cb, Cr
+
+   *  Y, Cb, Cr, Transparency
+
+   The Y Plane MUST be coded first.  If the Cb and Cr Planes are used,
+   then they MUST be coded after the Y Plane.  If a transparency Plane
+   is used, then it MUST be coded last.
+
+3.7.2.  RGB
+
+   This color space allows three or four Planes.
+
+   An optional transparency Plane can be used to code transparency data.
+
+   JPEG 2000 RCT is a Reversible Color Transform that codes RGB (Red,
+   Green, Blue) Planes losslessly in a modified YCbCr color space
+   [ISO.15444-1.2019].  Reversible pixel transformations between YCbCr
+   and RGB use the following formulae:
+
+   Cb = b - g
+   Cr = r - g
+   Y = g + (Cb + Cr) >> 2
+
+       Figure 6: Description of the transformation of pixels from RGB
+             color space to coded, modified YCbCr color space.
+
+   g = Y - (Cb + Cr) >> 2
+   r = Cr + g
+   b = Cb + g
+
+     Figure 7: Description of the transformation of pixels from coded,
+               modified YCbCr color space to RGB color space.
+
+   Cb and Cr are positively offset by "1 << bits_per_raw_sample" after
+   the conversion from RGB to the modified YCbCr, and they are
+   negatively offset by the same value before the conversion from the
+   modified YCbCr to RGB in order to have only nonnegative values after
+   the conversion.
+
+   When FFV1 uses the JPEG 2000 RCT, the horizontal Lines are
+   interleaved to improve caching efficiency since it is most likely
+   that the JPEG 2000 RCT will immediately be converted to RGB during
+   decoding.  The interleaved coding order is also Y, then Cb, then Cr,
+   and then, if used, transparency.
+
+   As an example, a Frame that is two pixels wide and two pixels high
+   could comprise the following structure:
+
+   +------------------------+------------------------+
+   | Pixel(1,1)             | Pixel(2,1)             |
+   | Y(1,1) Cb(1,1) Cr(1,1) | Y(2,1) Cb(2,1) Cr(2,1) |
+   +------------------------+------------------------+
+   | Pixel(1,2)             | Pixel(2,2)             |
+   | Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) |
+   +------------------------+------------------------+
+
+   In JPEG 2000 RCT, the coding order is left to right and then top to
+   bottom, with values interleaved by Lines and stored in this order:
+
+   Y(1,1) Y(2,1) Cb(1,1) Cb(2,1) Cr(1,1) Cr(2,1) Y(1,2) Y(2,2) Cb(1,2)
+   Cb(2,2) Cr(1,2) Cr(2,2)
+
+3.7.2.1.  RGB Exception
+
+   If "bits_per_raw_sample" is between 9 and 15 inclusive and
+   "extra_plane" is 0, the following formulae for reversible conversions
+   between YCbCr and RGB MUST be used instead of the ones above:
+
+   Cb = g - b
+   Cr = r - b
+   Y = b + (Cb + Cr) >> 2
+
+       Figure 8: Description of the transformation of pixels from RGB
+        color space to coded, modified YCbCr color space (in case of
+                                exception).
+
+   b = Y - (Cb + Cr) >> 2
+   r = Cr + b
+   g = Cb + b
+
+     Figure 9: Description of the transformation of pixels from coded,
+         modified YCbCr color space to RGB color space (in case of
+                                exception).
+
+   Background: At the time of this writing, in all known implementations
+   of the FFV1 bitstream, when "bits_per_raw_sample" was between 9 and
+   15 inclusive and "extra_plane" was 0, Green Blue Red (GBR) Planes
+   were used as Blue Green Red (BGR) Planes during both encoding and
+   decoding.  Meanwhile, 16-bit JPEG 2000 RCT was implemented without
+   this issue in one implementation and validated by one conformance
+   checker.  Methods to address this exception for the transform are
+   under consideration for the next version of the FFV1 bitstream.
+
+3.8.  Coding of the Sample Difference
+
+   Instead of coding the n+1 bits of the Sample Difference with Huffman
+   or Range coding (or n+2 bits, in the case of JPEG 2000 RCT), only the
+   n (or n+1, in the case of JPEG 2000 RCT) least significant bits are
+   used, since this is sufficient to recover the original Sample.  In
+   Figure 10, the term "bits" represents "bits_per_raw_sample + 1" for
+   JPEG 2000 RCT or "bits_per_raw_sample" otherwise:
+
+   coder_input = ((sample_difference + 2 ^ (bits - 1)) &
+                 (2 ^ bits - 1)) - 2 ^ (bits - 1)
+
+      Figure 10: Description of the coding of the Sample Difference in
+                               the bitstream.
+
+3.8.1.  Range Coding Mode
+
+   Early experimental versions of FFV1 used the Context-Adaptive Binary
+   Arithmetic Coding (CABAC) coder from H.264 as defined in
+   [ISO.14496-10.2020], but due to the uncertain patent/royalty
+   situation, as well as its slightly worse performance, CABAC was
+   replaced by a range coder based on an algorithm defined by G. Nigel
+   N. Martin in 1979 [Range-Encoding].
+
+3.8.1.1.  Range Binary Values
+
+   To encode binary digits efficiently, a range coder is used.  A range
+   coder encodes a series of binary symbols by using a probability
+   estimation within each context.  The sizes of each of the two
+   subranges are proportional to their estimated probability.  The
+   Quantization Table is used to choose the context used from the
+   surrounding image sample values for the case of coding the Sample
+   Differences.  The coding of integers is done by coding multiple
+   binary values.  The range decoder will read bytes until it can
+   determine into which subrange the input falls to return the next
+   binary symbol.
+
+   To describe Range coding for FFV1, the following values are used:
+
+   C_i  the i-th context.
+
+   B_i  the i-th byte of the bytestream.
+
+   R_i  the Range at the i-th symbol.
+
+   r_i  the boundary between two subranges of R_i: a subrange of r_i
+      values and a subrange R_i - r_i values.
+
+   L_i  the Low value of the Range at the i-th symbol.
+
+   l_i  a temporary variable to carry over or adjust the Low value of
+      the Range between range coding operations.
+
+   t_i  a temporary variable to transmit subranges between range coding
+      operations.
+
+   b_i  the i-th range-coded binary value.
+
+   S_(0, i)  the i-th initial state.
+
+   j_n  the length of the bytestream encoding n binary symbols.
+
+   The following range coder state variables are initialized to the
+   following values.  The Range is initialized to a value of 65,280
+   (expressed in base 16 as 0xFF00) as depicted in Figure 11.  The Low
+   is initialized according to the value of the first two bytes as
+   depicted in Figure 12. j_i tracks the length of the bytestream
+   encoding while incrementing from an initial value of j_0 to a final
+   value of j_n. j_0 is initialized to 2 as depicted in Figure 13.
+
+   R_0 = 65280
+
+                Figure 11: The initial value for the Range.
+
+   L_0 = 2 ^ 8 * B_0 + B_1
+
+        Figure 12: The initial value for Low is set according to the
+                     first two bytes of the bytestream.
+
+   j_0 = 2
+
+          Figure 13: The initial value for "j", the length of the
+                            bytestream encoding.
+
+   The following equations define how the range coder variables evolve
+   as it reads or writes symbols.
+
+   r_i = floor( ( R_i * S_(i, C_i) ) / 2 ^ 8 )
+
+        Figure 14: This formula shows the positioning of range split
+                            based on the state.
+
+              b_i =  0                        <==>
+              L_i <  R_i - r_i                ==>
+      S_(i+1,C_i) =  zero_state_(S_(i, C_i))  AND
+              l_i =  L_i                      AND
+              t_i =  R_i - r_i
+
+              b_i =  1                        <==>
+              L_i >= R_i - r_i                ==>
+      S_(i+1,C_i) =  one_state_(S_(i, C_i))   AND
+              l_i =  L_i - R_i + r_i          AND
+              t_i =  r_i
+
+      Figure 15: This formula shows the linking of the decoded symbol
+          (represented as b_i), the updated state (represented as
+      S_(i+1,C_i)), and the updated range (represented as a range from
+                                l_i to t_i).
+
+   C_i != k ==> S_(i + 1, k) = S_(i, k)
+
+       Figure 16: If the value of "k" is unequal to the i-th value of
+      context, in other words, if the state is unchanged from the last
+     symbol coding, then the value of the state is carried over to the
+                            next symbol coding.
+
+   t_i       <  2 ^ 8                         ==>
+   R_(i + 1) =  2 ^ 8 * t_i                   AND
+   L_(i + 1) =  2 ^ 8 * l_i + B_(j_i)         AND
+   j_(i + 1) =  j_i + 1
+
+   t_i       >= 2 ^ 8                         ==>
+   R_(i + 1) =  t_i                           AND
+   L_(i + 1) =  l_i                           AND
+   j_(i + 1) =  j_i
+
+     Figure 17: This formula shows the linking of the range coder with
+                 the reading or writing of the bytestream.
+
+       range = 0xFF00;
+       end   = 0;
+       low   = get_bits(16);
+       if (low >= range) {
+           low = range;
+           end = 1;
+       }
+
+        Figure 18: A pseudocode description of the initialization of
+                range coder variables in Range binary mode.
+
+   refill() {
+       if (range < 256) {
+           range = range * 256;
+           low   = low * 256;
+           if (!end) {
+               c.low += get_bits(8);
+               if (remaining_bits_in_bitstream( NumBytes ) == 0) {
+                   end = 1;
+               }
+           }
+       }
+   }
+
+     Figure 19: A pseudocode description of refilling the binary value
+                         buffer of the range coder.
+
+   get_rac(state) {
+       rangeoff  = (range * state) / 256;
+       range    -= rangeoff;
+       if (low < range) {
+           state = zero_state[state];
+           refill();
+           return 0;
+       } else {
+           low   -= range;
+           state  = one_state[state];
+           range  = rangeoff;
+           refill();
+           return 1;
+       }
+   }
+
+     Figure 20: A pseudocode description of the read of a binary value
+                           in Range binary mode.
+
+3.8.1.1.1.  Termination
+
+   The range coder can be used in three modes:
+
+   *  In Open mode when decoding, every symbol the reader attempts to
+      read is available.  In this mode, arbitrary data can have been
+      appended without affecting the range coder output.  This mode is
+      not used in FFV1.
+
+   *  In Closed mode, the length in bytes of the bytestream is provided
+      to the range decoder.  Bytes beyond the length are read as 0 by
+      the range decoder.  This is generally one byte shorter than the
+      Open mode.
+
+   *  In Sentinel mode, the exact length in bytes is not known, and thus
+      the range decoder MAY read into the data that follows the range-
+      coded bytestream by one byte.  In Sentinel mode, the end of the
+      range-coded bytestream is a binary symbol with state 129, which
+      value SHALL be discarded.  After reading this symbol, the range
+      decoder will have read one byte beyond the end of the range-coded
+      bytestream.  This way the byte position of the end can be
+      determined.  Bytestreams written in Sentinel mode can be read in
+      Closed mode if the length can be determined.  In this case, the
+      last (sentinel) symbol will be read uncorrupted and be of value 0.
+
+   The above describes the range decoding.  Encoding is defined as any
+   process that produces a decodable bytestream.
+
+   There are three places where range coder termination is needed in
+   FFV1.  The first is in the "Configuration Record", which in this case
+   the size of the range-coded bytestream is known and handled as Closed
+   mode.  The second is the switch from the "Slice Header", which is
+   range coded to Golomb-coded Slices as Sentinel mode.  The third is
+   the end of range-coded Slices, which need to terminate before the CRC
+   at their end.  This can be handled as Sentinel mode or as Closed mode
+   if the CRC position has been determined.
+
+3.8.1.2.  Range Nonbinary Values
+
+   To encode scalar integers, it would be possible to encode each bit
+   separately and use the past bits as context.  However, that would
+   mean 255 contexts per 8-bit symbol, which is not only a waste of
+   memory but also requires more past data to reach a reasonably good
+   estimate of the probabilities.  Alternatively, it would also be
+   possible to assume a Laplacian distribution and only deal with its
+   variance and mean (as in Huffman coding).  However, for maximum
+   flexibility and simplicity, the chosen method uses a single symbol to
+   encode if a number is 0, and if the number is nonzero, it encodes the
+   number using its exponent, mantissa, and sign.  The exact contexts
+   used are best described by Figure 21.
+
+   int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) {
+       if (get_rac(c, state + 0) {
+           return 0;
+       }
+
+       int e = 0;
+       while (get_rac(c, state + 1 + min(e, 9)) { //1..10
+           e++;
+       }
+
+       int a = 1;
+       for (int i = e - 1; i >= 0; i--) {
+           a = a * 2 + get_rac(c, state + 22 + min(i, 9));  // 22..31
+       }
+
+       if (!is_signed) {
+           return a;
+       }
+
+       if (get_rac(c, state + 11 + min(e, 10))) { //11..21
+           return -a;
+       } else {
+           return a;
+       }
+   }
+
+        Figure 21: A pseudocode description of the contexts of Range
+                             nonbinary values.
+
+   "get_symbol" is used for the read out of "sample_difference"
+   indicated in Figure 10.
+
+   "get_rac" returns a boolean computed from the bytestream as described
+   by the formula found in Figure 14 and by the pseudocode found in
+   Figure 20.
+
+3.8.1.3.  Initial Values for the Context Model
+
+   When the "keyframe" value (see Section 4.4) is 1, all range coder
+   state variables are set to their initial state.
+
+3.8.1.4.  State Transition Table
+
+   In Range Coding Mode, a state transition table is used, indicating to
+   which state the decoder will move based on the current state and the
+   value extracted from Figure 20.
+
+   one_state_i =
+          default_state_transition_i + state_transition_delta_i
+
+        Figure 22: Description of the coding of the state transition
+                 table for a "get_rac" readout value of 1.
+
+   zero_state_i = 256 - one_state_(256-i)
+
+        Figure 23: Description of the coding of the state transition
+                 table for a "get_rac" readout value of 0.
+
+3.8.1.5.  default_state_transition
+
+   By default, the following state transition table is used:
+
+     0,  0,  0,  0,  0,  0,  0,  0, 20, 21, 22, 23, 24, 25, 26, 27,
+
+    28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42,
+
+    43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57,
+
+    58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
+
+    74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
+
+    89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103,
+
+   104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118,
+
+   119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133,
+
+   134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,
+
+   150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164,
+
+   165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179,
+
+   180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194,
+
+   195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209,
+
+   210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225,
+
+   226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240,
+
+   241,242,243,244,245,246,247,248,248,  0,  0,  0,  0,  0,  0,  0,
+
+        Figure 24: Default state transition table for Range coding.
+
+3.8.1.6.  Alternative State Transition Table
+
+   The alternative state transition table has been built using iterative
+   minimization of frame sizes and generally performs better than the
+   default.  To use it, the "coder_type" (see Section 4.2.3) MUST be set
+   to 2, and the difference to the default MUST be stored in the
+   "Parameters", see Section 4.2.  At the time of this writing, the
+   reference implementation of FFV1 in FFmpeg uses Figure 25 by default
+   when Range coding is used.
+
+     0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49,
+
+    59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39,
+
+    40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52,
+
+    53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69,
+
+    87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97,
+
+    85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98,
+
+   105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125,
+
+   115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129,
+
+   165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148,
+
+   147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160,
+
+   172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178,
+
+   175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196,
+
+   197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214,
+
+   209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225,
+
+   226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242,
+
+   241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255,
+
+      Figure 25: Alternative state transition table for Range coding.
+
+3.8.2.  Golomb Rice Mode
+
+   The end of the bitstream of the Frame is padded with zeroes until the
+   bitstream contains a multiple of eight bits.
+
+3.8.2.1.  Signed Golomb Rice Codes
+
+   This coding mode uses Golomb Rice codes.  The VLC is split into two
+   parts: the prefix and suffix.  The prefix stores the most significant
+   bits or indicates if the symbol is too large to be stored (this is
+   known as the ESC case, see Section 3.8.2.1.1).  The suffix either
+   stores the k least significant bits or stores the whole number in the
+   ESC case.
+
+   int get_ur_golomb(k) {
+       for (prefix = 0; prefix < 12; prefix++) {
+           if (get_bits(1)) {
+               return get_bits(k) + (prefix << k);
+           }
+       }
+       return get_bits(bits) + 11;
+   }
+
+       Figure 26: A pseudocode description of the read of an unsigned
+                        integer in Golomb Rice mode.
+
+   int get_sr_golomb(k) {
+       v = get_ur_golomb(k);
+       if (v & 1) return - (v >> 1) - 1;
+       else       return   (v >> 1);
+   }
+
+        Figure 27: A pseudocode description of the read of a signed
+                        integer in Golomb Rice mode.
+
+3.8.2.1.1.  Prefix
+
+                        +================+=======+
+                        | bits           | value |
+                        +================+=======+
+                        | 1              | 0     |
+                        +----------------+-------+
+                        | 01             | 1     |
+                        +----------------+-------+
+                        | ...            | ...   |
+                        +----------------+-------+
+                        | 0000 0000 01   | 9     |
+                        +----------------+-------+
+                        | 0000 0000 001  | 10    |
+                        +----------------+-------+
+                        | 0000 0000 0001 | 11    |
+                        +----------------+-------+
+                        | 0000 0000 0000 | ESC   |
+                        +----------------+-------+
+
+                           Table 1: Description
+                           of the coding of the
+                             prefix of signed
+                            Golomb Rice codes.
+
+   ESC is an ESCape symbol to indicate that the symbol to be stored is
+   too large for normal storage and that an alternate storage method is
+   used.
+
+3.8.2.1.2.  Suffix
+
+           +---------+----------------------------------------+
+           | non-ESC | the k least significant bits MSB first |
+           +---------+----------------------------------------+
+           | ESC     | the value - 11, in MSB first order     |
+           +---------+----------------------------------------+
+
+             Table 2: Description of the coding of the suffix
+                       of signed Golomb Rice codes.
+
+   ESC MUST NOT be used if the value can be coded as non-ESC.
+
+3.8.2.1.3.  Examples
+
+   Table 3 shows practical examples of how signed Golomb Rice codes are
+   decoded based on the series of bits extracted from the bitstream as
+   described by the method above:
+
+                  +=====+=======================+=======+
+                  |  k  | bits                  | value |
+                  +=====+=======================+=======+
+                  |  0  | 1                     |     0 |
+                  +-----+-----------------------+-------+
+                  |  0  | 001                   |     2 |
+                  +-----+-----------------------+-------+
+                  |  2  | 1 00                  |     0 |
+                  +-----+-----------------------+-------+
+                  |  2  | 1 10                  |     2 |
+                  +-----+-----------------------+-------+
+                  |  2  | 01 01                 |     5 |
+                  +-----+-----------------------+-------+
+                  | any | 000000000000 10000000 |   139 |
+                  +-----+-----------------------+-------+
+
+                       Table 3: Examples of decoded,
+                         signed Golomb Rice codes.
+
+3.8.2.2.  Run Mode
+
+   Run mode is entered when the context is 0 and left as soon as a
+   nonzero difference is found.  The Sample Difference is identical to
+   the predicted one.  The run and the first different Sample Difference
+   are coded as defined in Section 3.8.2.4.1.
+
+3.8.2.2.1.  Run Length Coding
+
+   The run value is encoded in two parts.  The prefix part stores the
+   more significant part of the run as well as adjusting the "run_index"
+   that determines the number of bits in the less significant part of
+   the run.  The second part of the value stores the less significant
+   part of the run as it is.  The "run_index" is reset to zero for each
+   Plane and Slice.
+
+   log2_run[41] = {
+    0, 0, 0, 0, 1, 1, 1, 1,
+    2, 2, 2, 2, 3, 3, 3, 3,
+    4, 4, 5, 5, 6, 6, 7, 7,
+    8, 9,10,11,12,13,14,15,
+   16,17,18,19,20,21,22,23,
+   24,
+   };
+
+   if (run_count == 0 && run_mode == 1) {
+       if (get_bits(1)) {
+           run_count = 1 << log2_run[run_index];
+           if (x + run_count <= w) {
+               run_index++;
+           }
+       } else {
+           if (log2_run[run_index]) {
+               run_count = get_bits(log2_run[run_index]);
+           } else {
+               run_count = 0;
+           }
+           if (run_index) {
+               run_index--;
+           }
+           run_mode = 2;
+       }
+   }
+
+   The "log2_run" array is also used within [ISO.14495-1.1999].
+
+3.8.2.3.  Sign Extension
+
+   "sign_extend" is the function of increasing the number of bits of an
+   input binary number in two's complement signed number representation
+   while preserving the input number's sign (positive/negative) and
+   value, in order to fit in the output bit width.  It MAY be computed
+   with the following:
+
+   sign_extend(input_number, input_bits) {
+       negative_bias = 1 << (input_bits - 1);
+       bits_mask = negative_bias - 1;
+       output_number = input_number & bits_mask; // Remove negative bit
+       is_negative = input_number & negative_bias; // Test negative bit
+       if (is_negative)
+           output_number -= negative_bias;
+       return output_number
+   }
+
+3.8.2.4.  Scalar Mode
+
+   Each difference is coded with the per context mean prediction removed
+   and a per context value for "k".
+
+   get_vlc_symbol(state) {
+       i = state->count;
+       k = 0;
+       while (i < state->error_sum) {
+           k++;
+           i += i;
+       }
+
+       v = get_sr_golomb(k);
+
+       if (2 * state->drift < -state->count) {
+           v = -1 - v;
+       }
+
+       ret = sign_extend(v + state->bias, bits);
+
+       state->error_sum += abs(v);
+       state->drift     += v;
+
+       if (state->count == 128) {
+           state->count     >>= 1;
+           state->drift     >>= 1;
+           state->error_sum >>= 1;
+       }
+       state->count++;
+       if (state->drift <= -state->count) {
+           state->bias = max(state->bias - 1, -128);
+
+           state->drift = max(state->drift + state->count,
+                              -state->count + 1);
+       } else if (state->drift > 0) {
+           state->bias = min(state->bias + 1, 127);
+
+           state->drift = min(state->drift - state->count, 0);
+       }
+
+       return ret;
+   }
+
+3.8.2.4.1.  Golomb Rice Sample Difference Coding
+
+   Level coding is identical to the normal difference coding with the
+   exception that the 0 value is removed as it cannot occur:
+
+       diff = get_vlc_symbol(context_state);
+       if (diff >= 0) {
+           diff++;
+       }
+
+   Note that this is different from JPEG-LS (lossless JPEG), which
+   doesn't use prediction in run mode and uses a different encoding and
+   context model for the last difference.  On a small set of test
+   Samples, the use of prediction slightly improved the compression
+   rate.
+
+3.8.2.5.  Initial Values for the VLC Context State
+
+   When "keyframe" (see Section 4.4) value is 1, all VLC coder state
+   variables are set to their initial state.
+
+       drift     = 0;
+       error_sum = 4;
+       bias      = 0;
+       count     = 1;
+
+4.  Bitstream
+
+   An FFV1 bitstream is composed of a series of one or more Frames and
+   (when required) a "Configuration Record".
+
+   Within the following subsections, pseudocode as described in
+   Section 2.2.1 is used to explain the structure of each FFV1 bitstream
+   component.  Table 4 lists symbols used to annotate that pseudocode in
+   order to define the storage of the data referenced in that line of
+   pseudocode.
+
+       +========+==================================================+
+       | symbol | definition                                       |
+       +========+==================================================+
+       | u(n)   | Unsigned, big-endian integer symbol using n bits |
+       +--------+--------------------------------------------------+
+       | br     | Boolean (1-bit) symbol that is range coded with  |
+       |        | the method described in Section 3.8.1.1          |
+       +--------+--------------------------------------------------+
+       | ur     | Unsigned scalar symbol that is range coded with  |
+       |        | the method described in Section 3.8.1.2          |
+       +--------+--------------------------------------------------+
+       | sr     | Signed scalar symbol that is range coded with    |
+       |        | the method described in Section 3.8.1.2          |
+       +--------+--------------------------------------------------+
+       | sd     | Sample Difference symbol that is coded with the  |
+       |        | method described in Section 3.8                  |
+       +--------+--------------------------------------------------+
+
+        Table 4: Definition of pseudocode symbols for this document.
+
+   The following MUST be provided by external means during the
+   initialization of the decoder:
+
+   "frame_pixel_width" is defined as Frame width in pixels.
+
+   "frame_pixel_height" is defined as Frame height in pixels.
+
+   Default values at the decoder initialization phase:
+
+   "ConfigurationRecordIsPresent" is set to 0.
+
+4.1.  Quantization Table Set
+
+   The Quantization Table Sets store a sequence of values that are equal
+   to one less than the count of equal concurrent entries for each set
+   of equal concurrent entries within the first half of the table
+   (represented as "len - 1" in the pseudocode below) using the method
+   described in Section 3.8.1.2.  The second half doesn't need to be
+   stored as it is identical to the first with flipped sign. "scale" and
+   "len_count[ i ][ j ]" are temporary values used for the computing of
+   "context_count[ i ]" and are not used outside Quantization Table Set
+   pseudocode.
+
+   Example:
+
+   Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0
+
+   Stored values: 1, 3, 1
+
+   "QuantizationTableSet" has its own initial states, all set to 128.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   QuantizationTableSet( i ) {                                   |
+       scale = 1                                                 |
+       for (j = 0; j < MAX_CONTEXT_INPUTS; j++) {                |
+           QuantizationTable( i, j, scale )                      |
+           scale *= 2 * len_count[ i ][ j ] - 1                  |
+       }                                                         |
+       context_count[ i ] = ceil( scale / 2 )                    |
+   }                                                             |
+
+   "MAX_CONTEXT_INPUTS" is 5.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   QuantizationTable(i, j, scale) {                              |
+       v = 0                                                     |
+       for (k = 0; k < 128;) {                                   |
+           len - 1                                               | ur
+           for (n = 0; n < len; n++) {                           |
+               quant_tables[ i ][ j ][ k ] = scale * v           |
+               k++                                               |
+           }                                                     |
+           v++                                                   |
+       }                                                         |
+       for (k = 1; k < 128; k++) {                               |
+           quant_tables[ i ][ j ][ 256 - k ] = \                 |
+           -quant_tables[ i ][ j ][ k ]                          |
+       }                                                         |
+       quant_tables[ i ][ j ][ 128 ] = \                         |
+       -quant_tables[ i ][ j ][ 127 ]                            |
+       len_count[ i ][ j ] = v                                   |
+   }                                                             |
+
+4.1.1.  "quant_tables"
+
+   "quant_tables[ i ][ j ][ k ]" indicates the Quantization Table value
+   of the Quantized Sample Difference "k" of the Quantization Table "j"
+   of the Quantization Table Set "i".
+
+4.1.2.  "context_count"
+
+   "context_count[ i ]" indicates the count of contexts for Quantization
+   Table Set "i". "context_count[ i ]" MUST be less than or equal to
+   32768.
+
+4.2.  Parameters
+
+   The "Parameters" section, which could be in a global header of a
+   container file that may or may not be considered to be part of the
+   bitstream, contains significant characteristics about the decoding
+   configuration used for all instances of Frame (in FFV1 versions 0 and
+   1) or the whole FFV1 bitstream (other versions), including the stream
+   version, color configuration, and Quantization Tables.  Figure 28
+   describes the contents of the bitstream.
+
+   "Parameters" has its own initial states, all set to 128.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   Parameters( ) {                                               |
+       version                                                   | ur
+       if (version >= 3) {                                       |
+           micro_version                                         | ur
+       }                                                         |
+       coder_type                                                | ur
+       if (coder_type > 1) {                                     |
+           for (i = 1; i < 256; i++) {                           |
+               state_transition_delta[ i ]                       | sr
+           }                                                     |
+       }                                                         |
+       colorspace_type                                           | ur
+       if (version >= 1) {                                       |
+           bits_per_raw_sample                                   | ur
+       }                                                         |
+       chroma_planes                                             | br
+       log2_h_chroma_subsample                                   | ur
+       log2_v_chroma_subsample                                   | ur
+       extra_plane                                               | br
+       if (version >= 3) {                                       |
+           num_h_slices - 1                                      | ur
+           num_v_slices - 1                                      | ur
+           quant_table_set_count                                 | ur
+       }                                                         |
+       for (i = 0; i < quant_table_set_count; i++) {             |
+           QuantizationTableSet( i )                             |
+       }                                                         |
+       if (version >= 3) {                                       |
+           for (i = 0; i < quant_table_set_count; i++) {         |
+               states_coded                                      | br
+               if (states_coded) {                               |
+                   for (j = 0; j < context_count[ i ]; j++) {    |
+                       for (k = 0; k < CONTEXT_SIZE; k++) {      |
+                           initial_state_delta[ i ][ j ][ k ]    | sr
+                       }                                         |
+                   }                                             |
+               }                                                 |
+           }                                                     |
+           ec                                                    | ur
+           intra                                                 | ur
+       }                                                         |
+   }                                                             |
+
+       Figure 28: A pseudocode description of the bitstream contents.
+
+   CONTEXT_SIZE is 32.
+
+4.2.1.  "version"
+
+   "version" specifies the version of the FFV1 bitstream.
+
+   Each version is incompatible with other versions: decoders SHOULD
+   reject FFV1 bitstreams due to an unknown version.
+
+   Decoders SHOULD reject FFV1 bitstreams with "version <= 1 &&
+   ConfigurationRecordIsPresent == 1".
+
+   Decoders SHOULD reject FFV1 bitstreams with "version >= 3 &&
+   ConfigurationRecordIsPresent == 0".
+
+                    +=======+=========================+
+                    | value | version                 |
+                    +=======+=========================+
+                    | 0     | FFV1 version 0          |
+                    +-------+-------------------------+
+                    | 1     | FFV1 version 1          |
+                    +-------+-------------------------+
+                    | 2     | reserved*               |
+                    +-------+-------------------------+
+                    | 3     | FFV1 version 3          |
+                    +-------+-------------------------+
+                    | Other | reserved for future use |
+                    +-------+-------------------------+
+
+                        Table 5: The definitions for
+                             "version" values.
+
+   * Version 2 was experimental and this document does not describe it.
+
+4.2.2.  "micro_version"
+
+   "micro_version" specifies the micro-version of the FFV1 bitstream.
+
+   After a version is considered stable (a micro-version value is
+   assigned to be the first stable variant of a specific version), each
+   new micro-version after this first stable variant is compatible with
+   the previous micro-version: decoders SHOULD NOT reject FFV1
+   bitstreams due to an unknown micro-version equal or above the micro-
+   version considered as stable.
+
+   Meaning of "micro_version" for "version" 3:
+
+                    +=======+=========================+
+                    | value | micro_version           |
+                    +=======+=========================+
+                    | 0...3 | reserved*               |
+                    +-------+-------------------------+
+                    | 4     | first stable variant    |
+                    +-------+-------------------------+
+                    | Other | reserved for future use |
+                    +-------+-------------------------+
+
+                        Table 6: The definitions for
+                      "micro_version" values for FFV1
+                                 version 3.
+
+   * Development versions may be incompatible with the stable variants.
+
+4.2.3.  "coder_type"
+
+   "coder_type" specifies the coder used.
+
+        +=======+=================================================+
+        | value | coder used                                      |
+        +=======+=================================================+
+        | 0     | Golomb Rice                                     |
+        +-------+-------------------------------------------------+
+        | 1     | Range coder with default state transition table |
+        +-------+-------------------------------------------------+
+        | 2     | Range coder with custom state transition table  |
+        +-------+-------------------------------------------------+
+        | Other | reserved for future use                         |
+        +-------+-------------------------------------------------+
+
+             Table 7: The definitions for "coder_type" values.
+
+   Restrictions:
+
+   If "coder_type" is 0, then "bits_per_raw_sample" SHOULD NOT be > 8.
+
+   Background: At the time of this writing, there is no known
+   implementation of FFV1 bitstream supporting the Golomb Rice algorithm
+   with "bits_per_raw_sample" greater than eight, and range coder is
+   preferred.
+
+4.2.4.  "state_transition_delta"
+
+   "state_transition_delta" specifies the range coder custom state
+   transition table.
+
+   If "state_transition_delta" is not present in the FFV1 bitstream, all
+   range coder custom state transition table elements are assumed to be
+   0.
+
+4.2.5.  "colorspace_type"
+
+   "colorspace_type" specifies the color space encoded, the pixel
+   transformation used by the encoder, the extra Plane content, as well
+   as interleave method.
+
+   +=======+==============+================+==============+============+
+   | value | color space  | pixel          | extra Plane  | interleave |
+   |       | encoded      | transformation | content      | method     |
+   +=======+==============+================+==============+============+
+   | 0     | YCbCr        | None           | Transparency | Plane then |
+   |       |              |                |              | Line       |
+   +-------+--------------+----------------+--------------+------------+
+   | 1     | RGB          | JPEG 2000 RCT  | Transparency | Line then  |
+   |       |              |                |              | Plane      |
+   +-------+--------------+----------------+--------------+------------+
+   | Other | reserved     | reserved for   | reserved for | reserved   |
+   |       | for future   | future use     | future use   | for future |
+   |       | use          |                |              | use        |
+   +-------+--------------+----------------+--------------+------------+
+
+           Table 8: The definitions for "colorspace_type" values.
+
+   FFV1 bitstreams with "colorspace_type == 1 && (chroma_planes != 1 ||
+   log2_h_chroma_subsample != 0 || log2_v_chroma_subsample != 0)" are
+   not part of this specification.
+
+4.2.6.  "chroma_planes"
+
+   "chroma_planes" indicates if chroma (color) Planes are present.
+
+                 +=======+===============================+
+                 | value | presence                      |
+                 +=======+===============================+
+                 | 0     | chroma Planes are not present |
+                 +-------+-------------------------------+
+                 | 1     | chroma Planes are present     |
+                 +-------+-------------------------------+
+
+                        Table 9: The definitions for
+                          "chroma_planes" values.
+
+4.2.7.  "bits_per_raw_sample"
+
+   "bits_per_raw_sample" indicates the number of bits for each Sample.
+   Inferred to be 8 if not present.
+
+                +=======+=================================+
+                | value | bits for each Sample            |
+                +=======+=================================+
+                | 0     | reserved*                       |
+                +-------+---------------------------------+
+                | Other | the actual bits for each Sample |
+                +-------+---------------------------------+
+
+                       Table 10: The definitions for
+                       "bits_per_raw_sample" values.
+
+   * Encoders MUST NOT store "bits_per_raw_sample = 0".  Decoders SHOULD
+   accept and interpret "bits_per_raw_sample = 0" as 8.
+
+4.2.8.  "log2_h_chroma_subsample"
+
+   "log2_h_chroma_subsample" indicates the subsample factor, stored in
+   powers to which the number 2 is raised, between luma and chroma width
+   ("chroma_width = 2 ^ -log2_h_chroma_subsample * luma_width").
+
+4.2.9.  "log2_v_chroma_subsample"
+
+   "log2_v_chroma_subsample" indicates the subsample factor, stored in
+   powers to which the number 2 is raised, between luma and chroma
+   height ("chroma_height = 2 ^ -log2_v_chroma_subsample *
+   luma_height").
+
+4.2.10.  "extra_plane"
+
+   "extra_plane" indicates if an extra Plane is present.
+
+                  +=======+============================+
+                  | value | presence                   |
+                  +=======+============================+
+                  | 0     | extra Plane is not present |
+                  +-------+----------------------------+
+                  | 1     | extra Plane is present     |
+                  +-------+----------------------------+
+
+                      Table 11: The definitions for
+                          "extra_plane" values.
+
+4.2.11.  "num_h_slices"
+
+   "num_h_slices" indicates the number of horizontal elements of the
+   Slice raster.
+
+   Inferred to be 1 if not present.
+
+4.2.12.  "num_v_slices"
+
+   "num_v_slices" indicates the number of vertical elements of the Slice
+   raster.
+
+   Inferred to be 1 if not present.
+
+4.2.13.  "quant_table_set_count"
+
+   "quant_table_set_count" indicates the number of Quantization
+   Table Sets. "quant_table_set_count" MUST be less than or equal to 8.
+
+   Inferred to be 1 if not present.
+
+   MUST NOT be 0.
+
+4.2.14.  "states_coded"
+
+   "states_coded" indicates if the respective Quantization Table Set has
+   the initial states coded.
+
+   Inferred to be 0 if not present.
+
+                +=======+================================+
+                | value | initial states                 |
+                +=======+================================+
+                | 0     | initial states are not present |
+                |       | and are assumed to be all 128  |
+                +-------+--------------------------------+
+                | 1     | initial states are present     |
+                +-------+--------------------------------+
+
+                      Table 12: The definitions for
+                          "states_coded" values.
+
+4.2.15.  "initial_state_delta"
+
+   "initial_state_delta[ i ][ j ][ k ]" indicates the initial range
+   coder state, and it is encoded using "k" as context index for the
+   range coder and the following pseudocode:
+
+   pred = j ? initial_states[ i ][j - 1][ k ] : 128
+
+                Figure 29: Predictor value for the coding of
+                   "initial_state_delta[ i ][ j ][ k ]".
+
+   initial_state[ i ][ j ][ k ] =
+          ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255
+
+                  Figure 30: Description of the coding of
+                   "initial_state_delta[ i ][ j ][ k ]".
+
+4.2.16.  "ec"
+
+   "ec" indicates the error detection/correction type.
+
+        +=======+=================================================+
+        | value | error detection/correction type                 |
+        +=======+=================================================+
+        | 0     | 32-bit CRC in "ConfigurationRecord"             |
+        +-------+-------------------------------------------------+
+        | 1     | 32-bit CRC in "Slice" and "ConfigurationRecord" |
+        +-------+-------------------------------------------------+
+        | Other | reserved for future use                         |
+        +-------+-------------------------------------------------+
+
+                 Table 13: The definitions for "ec" values.
+
+4.2.17.  "intra"
+
+   "intra" indicates the constraint on "keyframe" in each instance of
+   Frame.
+
+   Inferred to be 0 if not present.
+
+     +=======+=======================================================+
+     | value | relationship                                          |
+     +=======+=======================================================+
+     | 0     | "keyframe" can be 0 or 1 (non keyframes or keyframes) |
+     +-------+-------------------------------------------------------+
+     | 1     | "keyframe" MUST be 1 (keyframes only)                 |
+     +-------+-------------------------------------------------------+
+     | Other | reserved for future use                               |
+     +-------+-------------------------------------------------------+
+
+               Table 14: The definitions for "intra" values.
+
+4.3.  Configuration Record
+
+   In the case of a FFV1 bitstream with "version >= 3", a "Configuration
+   Record" is stored in the underlying container as described in
+   Section 4.3.3.  It contains the "Parameters" used for all instances
+   of Frame.  The size of the "Configuration Record", "NumBytes", is
+   supplied by the underlying container.
+
+   pseudocode                                                 | type
+   -----------------------------------------------------------|-----
+   ConfigurationRecord( NumBytes ) {                          |
+       ConfigurationRecordIsPresent = 1                       |
+       Parameters( )                                          |
+       while (remaining_symbols_in_syntax(NumBytes - 4)) {    |
+           reserved_for_future_use                            | br/ur/sr
+       }                                                      |
+       configuration_record_crc_parity                        | u(32)
+   }                                                          |
+
+4.3.1.  "reserved_for_future_use"
+
+   "reserved_for_future_use" is a placeholder for future updates of this
+   specification.
+
+   Encoders conforming to this version of this specification SHALL NOT
+   write "reserved_for_future_use".
+
+   Decoders conforming to this version of this specification SHALL
+   ignore "reserved_for_future_use".
+
+4.3.2.  "configuration_record_crc_parity"
+
+   "configuration_record_crc_parity" is 32 bits that are chosen so that
+   the "Configuration Record" as a whole has a CRC remainder of zero.
+
+   This is equivalent to storing the CRC remainder in the 32-bit parity.
+
+   The CRC generator polynomial used is described in Section 4.9.3.
+
+4.3.3.  Mapping FFV1 into Containers
+
+   This "Configuration Record" can be placed in any file format that
+   supports "Configuration Records", fitting as much as possible with
+   how the file format stores "Configuration Records".  The
+   "Configuration Record" storage place and "NumBytes" are currently
+   defined and supported for the following formats:
+
+4.3.3.1.  Audio Video Interleave (AVI) File Format
+
+   The "Configuration Record" extends the stream format chunk ("AVI ",
+   "hdlr", "strl", "strf") with the "ConfigurationRecord" bitstream.
+
+   See [AVI] for more information about chunks.
+
+   "NumBytes" is defined as the size, in bytes, of the "strf" chunk
+   indicated in the chunk header minus the size of the stream format
+   structure.
+
+4.3.3.2.  ISO Base Media File Format
+
+   The "Configuration Record" extends the sample description box
+   ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box
+   that contains the "ConfigurationRecord" bitstream.  See
+   [ISO.14496-12.2020] for more information about boxes.
+
+   "NumBytes" is defined as the size, in bytes, of the "glbl" box
+   indicated in the box header minus the size of the box header.
+
+4.3.3.3.  NUT File Format
+
+   The "codec_specific_data" element (in "stream_header" packet)
+   contains the "ConfigurationRecord" bitstream.  See [NUT] for more
+   information about elements.
+
+   "NumBytes" is defined as the size, in bytes, of the
+   "codec_specific_data" element as indicated in the "length" field of
+   "codec_specific_data".
+
+4.3.3.4.  Matroska File Format
+
+   FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID".  For FFV1
+   versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be
+   used.  For FFV1 versions 3 or greater, the Matroska "CodecPrivate"
+   Element MUST contain the FFV1 "Configuration Record" structure and no
+   other data.  See [Matroska] for more information about elements.
+
+   "NumBytes" is defined as the "Element Data Size" of the
+   "CodecPrivate" Element.
+
+4.4.  Frame
+
+   A "Frame" is an encoded representation of a complete static image.
+   The whole "Frame" is provided by the underlying container.
+
+   A "Frame" consists of the "keyframe" field, "Parameters" (if "version
+   <= 1"), and a sequence of independent Slices.  The pseudocode below
+   describes the contents of a "Frame".
+
+   The "keyframe" field has its own initial state, set to 128.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   Frame( NumBytes ) {                                           |
+       keyframe                                                  | br
+       if (keyframe && !ConfigurationRecordIsPresent {           |
+           Parameters( )                                         |
+       }                                                         |
+       while (remaining_bits_in_bitstream( NumBytes )) {         |
+           Slice( )                                              |
+       }                                                         |
+   }                                                             |
+
+   The following is an architecture overview of Slices in a Frame:
+
+    +-----------------------------------------------------------------+
+    | first Slice header                                              |
+    +-----------------------------------------------------------------+
+    | first Slice content                                             |
+    +-----------------------------------------------------------------+
+    | first Slice footer                                              |
+    +-----------------------------------------------------------------+
+    | --------------------------------------------------------------- |
+    +-----------------------------------------------------------------+
+    | second Slice header                                             |
+    +-----------------------------------------------------------------+
+    | second Slice content                                            |
+    +-----------------------------------------------------------------+
+    | second Slice footer                                             |
+    +-----------------------------------------------------------------+
+    | --------------------------------------------------------------- |
+    +-----------------------------------------------------------------+
+    | ...                                                             |
+    +-----------------------------------------------------------------+
+    | --------------------------------------------------------------- |
+    +-----------------------------------------------------------------+
+    | last Slice header                                               |
+    +-----------------------------------------------------------------+
+    | last Slice content                                              |
+    +-----------------------------------------------------------------+
+    | last Slice footer                                               |
+    +-----------------------------------------------------------------+
+
+4.5.  Slice
+
+   A "Slice" is an independent, spatial subsection of a Frame that is
+   encoded separately from another region of the same Frame.  The use of
+   more than one "Slice" per Frame provides opportunities for taking
+   advantage of multithreaded encoding and decoding.
+
+   A "Slice" consists of a "Slice Header" (when relevant), a "Slice
+   Content", and a "Slice Footer" (when relevant).  The pseudocode below
+   describes the contents of a "Slice".
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   Slice( ) {                                                    |
+       if (version >= 3) {                                       |
+           SliceHeader( )                                        |
+       }                                                         |
+       SliceContent( )                                           |
+       if (coder_type == 0) {                                    |
+           while (!byte_aligned()) {                             |
+               padding                                           | u(1)
+           }                                                     |
+       }                                                         |
+       if (version <= 1) {                                       |
+           while (remaining_bits_in_bitstream( NumBytes ) != 0) {|
+               reserved                                          | u(1)
+           }                                                     |
+       }                                                         |
+       if (version >= 3) {                                       |
+           SliceFooter( )                                        |
+       }                                                         |
+   }                                                             |
+
+   "padding" specifies a bit without any significance and used only for
+   byte alignment. "padding" MUST be 0.
+
+   "reserved" specifies a bit without any significance in this
+   specification but may have a significance in a later revision of this
+   specification.
+
+   Encoders SHOULD NOT fill "reserved".
+
+   Decoders SHOULD ignore "reserved".
+
+4.6.  Slice Header
+
+   A "Slice Header" provides information about the decoding
+   configuration of the "Slice", such as its spatial position, size, and
+   aspect ratio.  The pseudocode below describes the contents of the
+   "Slice Header".
+
+   "Slice Header" has its own initial states, all set to 128.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   SliceHeader( ) {                                              |
+       slice_x                                                   | ur
+       slice_y                                                   | ur
+       slice_width - 1                                           | ur
+       slice_height - 1                                          | ur
+       for (i = 0; i < quant_table_set_index_count; i++) {       |
+           quant_table_set_index[ i ]                            | ur
+       }                                                         |
+       picture_structure                                         | ur
+       sar_num                                                   | ur
+       sar_den                                                   | ur
+   }                                                             |
+
+4.6.1.  "slice_x"
+
+   "slice_x" indicates the x position on the Slice raster formed by
+   "num_h_slices".
+
+   Inferred to be 0 if not present.
+
+4.6.2.  "slice_y"
+
+   "slice_y" indicates the y position on the Slice raster formed by
+   "num_v_slices".
+
+   Inferred to be 0 if not present.
+
+4.6.3.  "slice_width"
+
+   "slice_width" indicates the width on the Slice raster formed by
+   "num_h_slices".
+
+   Inferred to be 1 if not present.
+
+4.6.4.  "slice_height"
+
+   "slice_height" indicates the height on the Slice raster formed by
+   "num_v_slices".
+
+   Inferred to be 1 if not present.
+
+4.6.5.  "quant_table_set_index_count"
+
+   "quant_table_set_index_count" is defined as the following:
+
+   1 + ( ( chroma_planes || version <= 3 ) ? 1 : 0 )
+       + ( extra_plane ? 1 : 0 )
+
+4.6.6.  "quant_table_set_index"
+
+   "quant_table_set_index" indicates the Quantization Table Set index to
+   select the Quantization Table Set and the initial states for the
+   "Slice Content".
+
+   Inferred to be 0 if not present.
+
+4.6.7.  "picture_structure"
+
+   "picture_structure" specifies the temporal and spatial relationship
+   of each Line of the Frame.
+
+   Inferred to be 0 if not present.
+
+                    +=======+=========================+
+                    | value | picture structure used  |
+                    +=======+=========================+
+                    | 0     | unknown                 |
+                    +-------+-------------------------+
+                    | 1     | top field first         |
+                    +-------+-------------------------+
+                    | 2     | bottom field first      |
+                    +-------+-------------------------+
+                    | 3     | progressive             |
+                    +-------+-------------------------+
+                    | Other | reserved for future use |
+                    +-------+-------------------------+
+
+                       Table 15: The definitions for
+                        "picture_structure" values.
+
+4.6.8.  "sar_num"
+
+   "sar_num" specifies the Sample aspect ratio numerator.
+
+   Inferred to be 0 if not present.
+
+   A value of 0 means that aspect ratio is unknown.
+
+   Encoders MUST write 0 if the Sample aspect ratio is unknown.
+
+   If "sar_den" is 0, decoders SHOULD ignore the encoded value and
+   consider that "sar_num" is 0.
+
+4.6.9.  "sar_den"
+
+   "sar_den" specifies the Sample aspect ratio denominator.
+
+   Inferred to be 0 if not present.
+
+   A value of 0 means that aspect ratio is unknown.
+
+   Encoders MUST write 0 if the Sample aspect ratio is unknown.
+
+   If "sar_num" is 0, decoders SHOULD ignore the encoded value and
+   consider that "sar_den" is 0.
+
+4.7.  Slice Content
+
+   A "Slice Content" contains all Line elements part of the "Slice".
+
+   Depending on the configuration, Line elements are ordered by Plane
+   then by row (YCbCr) or by row then by Plane (RGB).
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   SliceContent( ) {                                             |
+       if (colorspace_type == 0) {                               |
+           for (p = 0; p < primary_color_count; p++) {           |
+               for (y = 0; y < plane_pixel_height[ p ]; y++) {   |
+                   Line( p, y )                                  |
+               }                                                 |
+           }                                                     |
+       } else if (colorspace_type == 1) {                        |
+           for (y = 0; y < slice_pixel_height; y++) {            |
+               for (p = 0; p < primary_color_count; p++) {       |
+                   Line( p, y )                                  |
+               }                                                 |
+           }                                                     |
+       }                                                         |
+   }                                                             |
+
+4.7.1.  "primary_color_count"
+
+   "primary_color_count" is defined as the following:
+
+   1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 )
+
+4.7.2.  "plane_pixel_height"
+
+   "plane_pixel_height[ p ]" is the height in pixels of Plane p of the
+   "Slice".  It is defined as the following:
+
+   chroma_planes == 1 && (p == 1 || p == 2)
+       ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))
+       : slice_pixel_height
+
+4.7.3.  "slice_pixel_height"
+
+   "slice_pixel_height" is the height in pixels of the Slice.  It is
+   defined as the following:
+
+   floor(
+           ( slice_y + slice_height )
+           * slice_pixel_height
+           / num_v_slices
+       ) - slice_pixel_y.
+
+4.7.4.  "slice_pixel_y"
+
+   "slice_pixel_y" is the Slice vertical position in pixels.  It is
+   defined as the following:
+
+   floor( slice_y * frame_pixel_height / num_v_slices )
+
+4.8.  Line
+
+   A "Line" is a list of the Sample Differences (relative to the
+   predictor) of primary color components.  The pseudocode below
+   describes the contents of the "Line".
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   Line( p, y ) {                                                |
+       if (colorspace_type == 0) {                               |
+           for (x = 0; x < plane_pixel_width[ p ]; x++) {        |
+               sample_difference[ p ][ y ][ x ]                  | sd
+           }                                                     |
+       } else if (colorspace_type == 1) {                        |
+           for (x = 0; x < slice_pixel_width; x++) {             |
+               sample_difference[ p ][ y ][ x ]                  | sd
+           }                                                     |
+       }                                                         |
+   }                                                             |
+
+4.8.1.  "plane_pixel_width"
+
+   "plane_pixel_width[ p ]" is the width in pixels of Plane p of the
+   "Slice".  It is defined as the following:
+
+   chroma_planes == 1 && (p == 1 || p == 2)
+       ? ceil( slice_pixel_width / (1 << log2_h_chroma_subsample) )
+       : slice_pixel_width.
+
+4.8.2.  "slice_pixel_width"
+
+   "slice_pixel_width" is the width in pixels of the Slice.  It is
+   defined as the following:
+
+   floor(
+           ( slice_x + slice_width )
+           * slice_pixel_width
+           / num_h_slices
+       ) - slice_pixel_x
+
+4.8.3.  "slice_pixel_x"
+
+   "slice_pixel_x" is the Slice horizontal position in pixels.  It is
+   defined as the following:
+
+   floor( slice_x * frame_pixel_width / num_h_slices )
+
+4.8.4.  "sample_difference"
+
+   "sample_difference[ p ][ y ][ x ]" is the Sample Difference for
+   Sample at Plane "p", y position "y", and x position "x".  The Sample
+   value is computed based on median predictor and context described in
+   Section 3.2.
+
+4.9.  Slice Footer
+
+   A "Slice Footer" provides information about Slice size and
+   (optionally) parity.  The pseudocode below describes the contents of
+   the "Slice Footer".
+
+   Note: "Slice Footer" is always byte aligned.
+
+   pseudocode                                                    | type
+   --------------------------------------------------------------|-----
+   SliceFooter( ) {                                              |
+       slice_size                                                | u(24)
+       if (ec) {                                                 |
+           error_status                                          | u(8)
+           slice_crc_parity                                      | u(32)
+       }                                                         |
+   }                                                             |
+
+4.9.1.  "slice_size"
+
+   "slice_size" indicates the size of the Slice in bytes.
+
+   Note: this allows finding the start of Slices before previous Slices
+   have been fully decoded and allows parallel decoding as well as error
+   resilience.
+
+4.9.2.  "error_status"
+
+   "error_status" specifies the error status.
+
+             +=======+=======================================+
+             | value | error status                          |
+             +=======+=======================================+
+             | 0     | no error                              |
+             +-------+---------------------------------------+
+             | 1     | Slice contains a correctable error    |
+             +-------+---------------------------------------+
+             | 2     | Slice contains an uncorrectable error |
+             +-------+---------------------------------------+
+             | Other | reserved for future use               |
+             +-------+---------------------------------------+
+
+                Table 16: The definitions for "error_status"
+                                  values.
+
+4.9.3.  "slice_crc_parity"
+
+   "slice_crc_parity" is 32 bits that are chosen so that the Slice as a
+   whole has a CRC remainder of 0.
+
+   This is equivalent to storing the CRC remainder in the 32-bit parity.
+
+   The CRC generator polynomial used is the standard IEEE CRC polynomial
+   (0x104C11DB7) with initial value 0, without pre-inversion, and
+   without post-inversion.
+
+5.  Restrictions
+
+   To ensure that fast multithreaded decoding is possible, starting with
+   version 3 and if "frame_pixel_width * frame_pixel_height" is more
+   than 101376, "slice_width * slice_height" MUST be less or equal to
+   "num_h_slices * num_v_slices / 4".  Note: 101376 is the frame size in
+   pixels of a 352x288 frame also known as CIF (Common Intermediate
+   Format) frame size format.
+
+   For each Frame, each position in the Slice raster MUST be filled by
+   one and only one Slice of the Frame (no missing Slice position and no
+   Slice overlapping).
+
+   For each Frame with a "keyframe" value of 0, each Slice MUST have the
+   same value of "slice_x", "slice_y", "slice_width", and "slice_height"
+   as a Slice in the previous Frame.
+
+6.  Security Considerations
+
+   Like any other codec (such as [RFC6716]), FFV1 should not be used
+   with insecure ciphers or cipher modes that are vulnerable to known
+   plaintext attacks.  Some of the header bits as well as the padding
+   are easily predictable.
+
+   Implementations of the FFV1 codec need to take appropriate security
+   considerations into account.  Those related to denial of service are
+   outlined in Section 2.1 of [RFC4732].  It is extremely important for
+   the decoder to be robust against malicious payloads.  Malicious
+   payloads MUST NOT cause the decoder to overrun its allocated memory
+   or to take an excessive amount of resources to decode.  An overrun in
+   allocated memory could lead to arbitrary code execution by an
+   attacker.  The same applies to the encoder, even though problems in
+   encoders are typically rarer.  Malicious video streams MUST NOT cause
+   the encoder to misbehave because this would allow an attacker to
+   attack transcoding gateways.  A frequent security problem in image
+   and video codecs is failure to check for integer overflows.  An
+   example is allocating "frame_pixel_width * frame_pixel_height" in
+   pixel count computations without considering that the multiplication
+   result may have overflowed the range of the arithmetic type.  The
+   range coder could, if implemented naively, read one byte over the
+   end.  The implementation MUST ensure that no read outside allocated
+   and initialized memory occurs.
+
+   None of the content carried in FFV1 is intended to be executable.
+
+7.  IANA Considerations
+
+   IANA has registered the following values.
+
+7.1.  Media Type Definition
+
+   This registration is done using the template defined in [RFC6838] and
+   following [RFC4855].
+
+   Type name:  video
+
+   Subtype name:  FFV1
+
+   Required parameters:  None.
+
+   Optional parameters:  These parameters are used to signal the
+      capabilities of a receiver implementation.  These parameters MUST
+      NOT be used for any other purpose.
+
+      "version":  The "version" of the FFV1 encoding as defined by
+         Section 4.2.1.
+
+      "micro_version":  The "micro_version" of the FFV1 encoding as
+         defined by Section 4.2.2.
+
+      "coder_type":  The "coder_type" of the FFV1 encoding as defined by
+         Section 4.2.3.
+
+      "colorspace_type":  The "colorspace_type" of the FFV1 encoding as
+         defined by Section 4.2.5.
+
+      "bits_per_raw_sample":  The "bits_per_raw_sample" of the FFV1
+         encoding as defined by Section 4.2.7.
+
+      "max_slices":  The value of "max_slices" is an integer indicating
+         the maximum count of Slices within a Frame of the FFV1
+         encoding.
+
+   Encoding considerations:  This media type is defined for
+      encapsulation in several audiovisual container formats and
+      contains binary data; see Section 4.3.3.  This media type is
+      framed binary data; see Section 4.8 of [RFC6838].
+
+   Security considerations:  See Section 6 of this document.
+
+   Interoperability considerations:  None.
+
+   Published specification:  RFC 9043.
+
+   Applications that use this media type:  Any application that requires
+      the transport of lossless video can use this media type.  Some
+      examples are, but not limited to, screen recording, scientific
+      imaging, and digital video preservation.
+
+   Fragment identifier considerations:  N/A.
+
+   Additional information:  None.
+
+   Person & email address to contact for further information:
+      Michael Niedermayer (mailto:michael@niedermayer.cc)
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  None.
+
+   Author:  Dave Rice (mailto:dave@dericed.com)
+
+   Change controller:  IETF CELLAR Working Group delegated from the
+      IESG.
+
+8.  References
+
+8.1.  Normative References
+
+   [ISO.9899.2018]
+              International Organization for Standardization,
+              "Information technology - Programming languages - C", ISO/
+              IEC 9899:2018, June 2018.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
+              Denial-of-Service Considerations", RFC 4732,
+              DOI 10.17487/RFC4732, December 2006,
+              <https://www.rfc-editor.org/info/rfc4732>.
+
+   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
+              Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
+              <https://www.rfc-editor.org/info/rfc4855>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <https://www.rfc-editor.org/info/rfc6838>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2.  Informative References
+
+   [AddressSanitizer]
+              Clang Project, "AddressSanitizer", Clang 12 documentation,
+              <https://clang.llvm.org/docs/AddressSanitizer.html>.
+
+   [AVI]      Microsoft, "AVI RIFF File Reference",
+              <https://docs.microsoft.com/en-
+              us/windows/win32/directshow/avi-riff-file-reference>.
+
+   [FFV1GO]   Buitenhuis, D., "FFV1 Decoder in Go", 2019,
+              <https://github.com/dwbuiten/go-ffv1>.
+
+   [FFV1_V0]  Niedermayer, M., "Commit to mark FFV1 version 0 as non-
+              experimental", April 2006, <https://git.videolan.org/?p=ff
+              mpeg.git;a=commit;h=b548f2b91b701e1235608ac882ea6df915167c
+              7e>.
+
+   [FFV1_V1]  Niedermayer, M., "Commit to release FFV1 version 1", April
+              2009, <https://git.videolan.org/?p=ffmpeg.git;a=commit;h=6
+              8f8d33becbd73b4d0aa277f472a6e8e72ea6849>.
+
+   [FFV1_V3]  Niedermayer, M., "Commit to mark FFV1 version 3 as non-
+              experimental", August 2013, <https://git.videolan.org/?p=f
+              fmpeg.git;a=commit;h=abe76b851c05eea8743f6c899cbe5f7409b0f
+              301>.
+
+   [HuffYUV]  Rudiak-Gould, B., "HuffYUV revisited", December 2003,
+              <https://web.archive.org/web/20040402121343/
+              http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>.
+
+   [ISO.14495-1.1999]
+              International Organization for Standardization,
+              "Information technology -- Lossless and near-lossless
+              compression of continuous-tone still images: Baseline",
+              ISO/IEC 14495-1:1999, December 1999.
+
+   [ISO.14496-10.2020]
+              International Organization for Standardization,
+              "Information technology -- Coding of audio-visual objects
+              -- Part 10: Advanced Video Coding", ISO/IEC 14496-10:2020,
+              December 2020.
+
+   [ISO.14496-12.2020]
+              International Organization for Standardization,
+              "Information technology -- Coding of audio-visual objects
+              -- Part 12: ISO base media file format", ISO/IEC
+              14496-12:2020, December 2020.
+
+   [ISO.15444-1.2019]
+              International Organization for Standardization,
+              "Information technology -- JPEG 2000 image coding system:
+              Core coding system", ISO/IEC 15444-1:2019, October 2019.
+
+   [Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media
+              Container Format Specifications", Work in Progress,
+              Internet-Draft, draft-ietf-cellar-matroska-07, 12 April
+              2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
+              cellar-matroska-07>.
+
+   [MediaConch]
+              MediaArea.net, "MediaConch", 2018,
+              <https://mediaarea.net/MediaConch>.
+
+   [NUT]      Niedermayer, M., "NUT Open Container Format", December
+              2013, <https://ffmpeg.org/~michael/nut.txt>.
+
+   [Range-Encoding]
+              Martin, G. N. N., "Range encoding: an algorithm for
+              removing redundancy from a digitised message", Proceedings
+              of the Conference on Video and Data Recording, Institution
+              of Electronic and Radio Engineers, Hampshire, England,
+              July 1979.
+
+   [REFIMPL]  Niedermayer, M., "The reference FFV1 implementation / the
+              FFV1 codec in FFmpeg",
+              <https://ffmpeg.org/doxygen/trunk/ffv1_8h.html>.
+
+   [RFC6716]  Valin, JM., Vos, K., and T. Terriberry, "Definition of the
+              Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
+              September 2012, <https://www.rfc-editor.org/info/rfc6716>.
+
+   [Valgrind] Valgrind Developers, "Valgrind website",
+              <https://valgrind.org/>.
+
+   [YCbCr]    Wikipedia, "YCbCr", 25 May 2021,
+              <https://en.wikipedia.org/w/
+              index.php?title=YCbCr&oldid=1025097882>.
+
+Appendix A.  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.
+
+Appendix B.  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.
+
+Appendix C.  FFV1 Implementations
+
+   This appendix provides references to a few notable implementations of
+   FFV1.
+
+C.1.  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.
+
+C.2.  FFV1 Decoder in Go
+
+   An FFV1 decoder [FFV1GO] was written in Go by Derek Buitenhuis during
+   the work to develop this document.
+
+C.3.  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 Section 3.3.1,
+   Section 3.7.2.1, and Appendix B.
+
+Authors' Addresses
+
+   Michael Niedermayer
+
+   Email: michael@niedermayer.cc
+
+
+   Dave Rice
+
+   Email: dave@dericed.com
+
+
+   Jérôme Martinez
+
+   Email: jerome@mediaarea.net