draft-ietf-cellar-ffv1-11.txt   draft-ietf-cellar-ffv1-12.txt 
cellar M. Niedermayer cellar M. Niedermayer
Internet-Draft D. Rice Internet-Draft
Intended status: Informational J. Martinez Intended status: Informational D. Rice
Expires: 25 April 2020 23 October 2019 Expires: 30 July 2020
J. Martinez
27 January 2020
FFV1 Video Coding Format Version 0, 1, and 3 FFV1 Video Coding Format Version 0, 1, and 3
draft-ietf-cellar-ffv1-11 draft-ietf-cellar-ffv1-12
Abstract Abstract
This document defines FFV1, a lossless intra-frame video encoding This document defines FFV1, a lossless intra-frame video encoding
format. FFV1 is designed to efficiently compress video data in a format. FFV1 is designed to efficiently compress video data in a
variety of pixel formats. Compared to uncompressed video, FFV1 variety of pixel formats. Compared to uncompressed video, FFV1
offers storage compression, frame fixity, and self-description, which offers storage compression, frame fixity, and self-description, which
makes FFV1 useful as a preservation or intermediate video format. makes FFV1 useful as a preservation or intermediate video format.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 April 2020. This Internet-Draft will expire on 30 July 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6 2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6
2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 6 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 6
2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7 2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7
2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7 2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7
2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8 2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8
2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 8 2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 8
2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 8 2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 8
3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 42 skipping to change at page 3, line 45
4.8.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 43 4.8.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 43
4.9. Quantization Table Set . . . . . . . . . . . . . . . . . 44 4.9. Quantization Table Set . . . . . . . . . . . . . . . . . 44
4.9.1. quant_tables . . . . . . . . . . . . . . . . . . . . 45 4.9.1. quant_tables . . . . . . . . . . . . . . . . . . . . 45
4.9.2. context_count . . . . . . . . . . . . . . . . . . . . 45 4.9.2. context_count . . . . . . . . . . . . . . . . . . . . 45
5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 45 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 45
6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46
7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 47 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 47
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
9. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Decoder implementation suggestions . . . . . . . . . . . 48 9.1. Decoder implementation suggestions . . . . . . . . . . . 48
9.1.1. Multi-threading Support and Independence of 9.1.1. Multi-threading Support and Independence of Slices . 48
Slices . . . . . . . . . . . . . . . . . . . . . . . 48
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. Normative References . . . . . . . . . . . . . . . . . . . . 49 11. Normative References . . . . . . . . . . . . . . . . . . . . 49
12. Informative References . . . . . . . . . . . . . . . . . . . 50 12. Informative References . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document describes FFV1, a lossless video encoding format. The This document describes FFV1, a lossless video encoding format. The
design of FFV1 considers the storage of image characteristics, data design of FFV1 considers the storage of image characteristics, data
fixity, and the optimized use of encoding time and storage fixity, and the optimized use of encoding time and storage
skipping to change at page 4, line 38 skipping to change at page 4, line 38
blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx
(https://github.com/FFmpeg/FFV1/ (https://github.com/FFmpeg/FFV1/
blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx). blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx).
* Version 3 of FFV1 adds several features such as increased * Version 3 of FFV1 adds several features such as increased
description of the characteristics of the encoding images and description of the characteristics of the encoding images and
embedded CRC data to support fixity verification of the encoding. embedded CRC data to support fixity verification of the encoding.
Version 3 has been in non-experimental use since August 17, 2013 Version 3 has been in non-experimental use since August 17, 2013
[FFV1_V3]. [FFV1_V3].
The latest version of this document is available at
https://raw.github.com/FFmpeg/FFV1/master/ffv1.md
(https://raw.github.com/FFmpeg/FFV1/master/ffv1.md)
This document assumes familiarity with mathematical and coding This document assumes familiarity with mathematical and coding
concepts such as Range coding [range-coding] and YCbCr color spaces concepts such as Range coding [range-coding] and YCbCr color spaces
[YCbCr]. [YCbCr].
2. Notation and Conventions 2. Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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 2.1. Definitions
"Container": Format that encapsulates "Frames" (see the section on "Container": Format that encapsulates "Frames" (see Section 4.3) and
Frames (#frame)) and (when required) a "Configuration Record" into a (when required) a "Configuration Record" into a bitstream.
bitstream.
"Sample": The smallest addressable representation of a color "Sample": The smallest addressable representation of a color
component or a luma component in a "Frame". Examples of "Sample" are component or a luma component in a "Frame". Examples of "Sample" are
Luma, Blue Chrominance, Red Chrominance, Transparency, Red, Green, Luma, Blue Chrominance, Red Chrominance, Transparency, Red, Green,
and Blue. and Blue.
"Plane": A discrete component of a static image comprised of "Plane": A discrete component of a static image comprised of
"Samples" that represent a specific quantification of "Samples" of "Samples" that represent a specific quantification of "Samples" of
that image. that image.
skipping to change at page 6, line 4 skipping to change at page 6, line 6
(Y) and the chrominance of the "Pixel" (Cb and Cr). YCbCr word is (Y) and the chrominance of the "Pixel" (Cb and Cr). YCbCr word is
used for historical reasons and currently references any color space used for historical reasons and currently references any color space
relying on 1 luma "Sample" and 2 chrominance "Samples", e.g. YCbCr, relying on 1 luma "Sample" and 2 chrominance "Samples", e.g. YCbCr,
YCgCo or ICtCp. The exact meaning of the three numeric values is YCgCo or ICtCp. The exact meaning of the three numeric values is
unspecified. unspecified.
"TBA": To Be Announced. Used in reference to the development of "TBA": To Be Announced. Used in reference to the development of
future iterations of the FFV1 specification. future iterations of the FFV1 specification.
2.2. Conventions 2.2. Conventions
2.2.1. Pseudo-code 2.2.1. Pseudo-code
The FFV1 bitstream is described in this document using pseudo-code. The FFV1 bitstream is described in this document using pseudo-code.
Note that the pseudo-code is used for clarity in order to illustrate Note that the pseudo-code is used for clarity in order to illustrate
the structure of FFV1 and not intended to specify any particular the structure of FFV1 and not intended to specify any particular
implementation. The pseudo-code used is based upon the C programming implementation. The pseudo-code used is based upon the C programming
language [ISO.9899.1990] and uses its "if/else", "while" and "for" language [ISO.9899.1990] and uses its "if/else", "while" and "for"
functions as well as functions defined within this document. keywords as well as functions defined within this document.
2.2.2. Arithmetic Operators 2.2.2. Arithmetic Operators
Note: the operators and the order of precedence are the same as used Note: the operators and the order of precedence are the same as used
in the C programming language [ISO.9899.1990]. in the C programming language [ISO.9899.2018].
"a + b" means a plus b. "a + b" means a plus b.
"a - b" means a minus b. "a - b" means a minus b.
"-a" means negation of a. "-a" means negation of a.
"a * b" means a multiplied by b. "a * b" means a multiplied by b.
"a / b" means a divided by b. "a / b" means a divided by b.
skipping to change at page 8, line 36 skipping to change at page 8, line 37
a = b, a += b, a -= b, a *= b a = b, a += b, a -= b, a *= b
2.2.7. Range 2.2.7. Range
"a...b" means any value starting from a to b, inclusive. "a...b" means any value starting from a to b, inclusive.
2.2.8. NumBytes 2.2.8. NumBytes
"NumBytes" is a non-negative integer that expresses the size in 8-bit "NumBytes" is a non-negative integer that expresses the size in 8-bit
octets of a particular FFV1 "Configuration Record" or "Frame". FFV1 octets of a particular FFV1 "Configuration Record" or "Frame". FFV1
relies on its "Container" to store the "NumBytes" values, see the relies on its "Container" to store the "NumBytes" values; see
section on the Mapping FFV1 into Containers (#mapping-ffv1-into- Section 4.2.3.
containers).
2.2.9. Bitstream Functions 2.2.9. Bitstream Functions
2.2.9.1. remaining_bits_in_bitstream 2.2.9.1. remaining_bits_in_bitstream
"remaining_bits_in_bitstream( )" means the count of remaining bits "remaining_bits_in_bitstream( )" means the count of remaining bits
after the pointer in that "Configuration Record" or "Frame". It is after the pointer in that "Configuration Record" or "Frame". It is
computed from the "NumBytes" value multiplied by 8 minus the count of computed from the "NumBytes" value multiplied by 8 minus the count of
bits of that "Configuration Record" or "Frame" already read by the bits of that "Configuration Record" or "Frame" already read by the
bitstream parser. bitstream parser.
skipping to change at page 9, line 23 skipping to change at page 9, line 23
)" is a multiple of 8, otherwise false. )" is a multiple of 8, otherwise false.
2.2.9.4. get_bits 2.2.9.4. get_bits
"get_bits( i )" is the action to read the next "i" bits in the "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 bitstream, from most significant bit to least significant bit, and to
return the corresponding value. The pointer is increased by "i". return the corresponding value. The pointer is increased by "i".
3. Sample Coding 3. Sample Coding
For each "Slice" (as described in the section on Slices (#slice)) of For each "Slice" (as described in Section 4.4) of a "Frame", the
a "Frame", the "Planes", "Lines", and "Samples" are coded in an order "Planes", "Lines", and "Samples" are coded in an order determined by
determined by the "Color Space" (see the section on Color Space the "Color Space" (see Section 3.7). Each "Sample" is predicted by
(#color-spaces)). Each "Sample" is predicted by the median predictor the median predictor as described in Section 3.3 from other "Samples"
as described in the section of the Median Predictor (#median- within the same "Plane" and the difference is stored using the method
predictor) from other "Samples" within the same "Plane" and the described in Section 3.8.
difference is stored using the method described in Coding of the
Sample Difference (#coding-of-the-sample-difference).
3.1. Border 3.1. Border
A border is assumed for each coded "Slice" for the purpose of the A border is assumed for each coded "Slice" for the purpose of the
median predictor and context according to the following rules: median predictor and context according to the following rules:
* one column of "Samples" to the left of the coded slice is assumed * 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 as identical to the "Samples" of the leftmost column of the coded
slice shifted down by one row. The value of the topmost "Sample" 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 of the column of "Samples" to the left of the coded slice is
assumed to be "0" assumed to be "0"
* one column of "Samples" to the right of the coded slice is assumed * 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 as identical to the "Samples" of the rightmost column of the coded
slice slice
* an additional column of "Samples" to the left 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 and two rows of "Samples" above the coded slice are assumed to be
"0" "0"
The following table depicts a slice of 9 "Samples" Figure 1 depicts a slice of 9 "Samples" "a,b,c,d,e,f,g,h,i" in a 3x3
"a,b,c,d,e,f,g,h,i" in a 3x3 arrangement along with its assumed arrangement along with its assumed border.
border.
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | | 0 | 0 | 0 | | 0 | | 0 | 0 | | 0 | 0 | 0 | | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | | 0 | 0 | 0 | | 0 | | 0 | 0 | | 0 | 0 | 0 | | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | | a | b | c | | c | | 0 | 0 | | a | b | c | | c |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | a | | d | e | f | | f | | 0 | a | | d | e | f | | f |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | d | | g | h | i | | i | | 0 | d | | g | h | i | | i |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 1: A depiction of FFV1's assumed border for a set example
Samples.
3.2. Samples 3.2. Samples
Relative to any "Sample" "X", six other relatively positioned Relative to any "Sample" "X", six other relatively positioned
"Samples" from the coded "Samples" and presumed border are identified "Samples" from the coded "Samples" and presumed border are identified
according to the labels used in the following diagram. The labels according to the labels used in Figure 2. The labels for these
for these relatively positioned "Samples" are used within the median relatively positioned "Samples" are used within the median predictor
predictor and context. and context.
+---+---+---+---+ +---+---+---+---+
| | | T | | | | | T | |
+---+---+---+---+ +---+---+---+---+
| |tl | t |tr | | |tl | t |tr |
+---+---+---+---+ +---+---+---+---+
| L | l | X | | | L | l | X | |
+---+---+---+---+ +---+---+---+---+
Figure 2: A depiction of how relatively positions Samples are
references within this document.
The labels for these relative "Samples" are made of the first letters The labels for these relative "Samples" are made of the first letters
of the words Top, Left and Right. of the words Top, Left and Right.
3.3. Median Predictor 3.3. Median Predictor
The prediction for any "Sample" value at position "X" may be computed The prediction for any "Sample" value at position "X" may be computed
based upon the relative neighboring values of "l", "t", and "tl" via based upon the relative neighboring values of "l", "t", and "tl" via
this equation: this equation:
"median(l, t, l + t - tl)". "median(l, t, l + t - tl)".
skipping to change at page 11, line 43 skipping to change at page 11, line 46
Relative to any "Sample" "X", the Quantized Sample Differences "L-l", Relative to any "Sample" "X", the Quantized Sample Differences "L-l",
"l-tl", "tl-t", "T-t", and "t-tr" are used as context: "l-tl", "tl-t", "T-t", and "t-tr" are used as context:
context = Q_{0}[l - tl] + context = Q_{0}[l - tl] +
Q_{1}[tl - t] + Q_{1}[tl - t] +
Q_{2}[t - tr] + Q_{2}[t - tr] +
Q_{3}[L - l] + Q_{3}[L - l] +
Q_{4}[T - t] Q_{4}[T - t]
Figure 1 Figure 3
If "context >= 0" then "context" is used and the difference between If "context >= 0" then "context" is used and the difference between
the "Sample" and its predicted value is encoded as is, else the "Sample" and its predicted value is encoded as is, else
"-context" is used and the difference between the "Sample" and its "-context" is used and the difference between the "Sample" and its
predicted value is encoded with a flipped sign. predicted value is encoded with a flipped sign.
3.5. Quantization Table Sets 3.5. Quantization Table Sets
The FFV1 bitstream contains 1 or more Quantization Table Sets. Each The FFV1 bitstream contains 1 or more Quantization Table Sets. Each
Quantization Table Set contains exactly 5 Quantization Tables with Quantization Table Set contains exactly 5 Quantization Tables with
each Quantization Table corresponding to 1 of the 5 Quantized Sample each Quantization Table corresponding to 1 of the 5 Quantized Sample
Differences. For each Quantization Table, both the number of Differences. For each Quantization Table, both the number of
quantization steps and their distribution are stored in the FFV1 quantization steps and their distribution are stored in the FFV1
bitstream; each Quantization Table has exactly 256 entries, and the 8 bitstream; each Quantization Table has exactly 256 entries, and the 8
least significant bits of the Quantized Sample Difference are used as least significant bits of the Quantized Sample Difference are used as
index: index:
Q_{j}[k] = quant_tables[i][j][k&255] Q_{j}[k] = quant_tables[i][j][k&255]
Figure 2 Figure 4
In this formula, "i" is the Quantization Table Set index, "j" is the In this formula, "i" is the Quantization Table Set index, "j" is the
Quantized Table index, "k" the Quantized Sample Difference. Quantized Table index, "k" the Quantized Sample Difference.
3.6. Quantization Table Set Indexes 3.6. Quantization Table Set Indexes
For each "Plane" of each slice, a Quantization Table Set is selected For each "Plane" of each slice, a Quantization Table Set is selected
from an index: from an index:
* For Y "Plane", "quant_table_set_index[ 0 ]" index is used * For Y "Plane", "quant_table_set_index[ 0 ]" index is used
skipping to change at page 13, line 50 skipping to change at page 13, line 50
[ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr [ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr
and RGB use the following formulae. and RGB use the following formulae.
Cb=b-g Cb=b-g
Cr=r-g Cr=r-g
Y=g+(Cb+Cr)>>2 Y=g+(Cb+Cr)>>2
g=Y-(Cb+Cr)>>2 g=Y-(Cb+Cr)>>2
r=Cr+g r=Cr+g
b=Cb+g b=Cb+g
Figure 3 Figure 5
Exception for the JPEG2000-RCT conversion: if bits_per_raw_sample is Exception for the JPEG2000-RCT conversion: if bits_per_raw_sample is
between 9 and 15 inclusive and extra_plane is 0, the following between 9 and 15 inclusive and extra_plane is 0, the following
formulae for reversible conversions between YCbCr and RGB MUST be formulae for reversible conversions between YCbCr and RGB MUST be
used instead of the ones above: used instead of the ones above:
Cb=g-b Cb=g-b
Cr=r-b Cr=r-b
Y=b+(Cb+Cr)>>2 Y=b+(Cb+Cr)>>2
b=Y-(Cb+Cr)>>2 b=Y-(Cb+Cr)>>2
r=Cr+b r=Cr+b
g=Cb+b g=Cb+b
Figure 4 Figure 6
Background: At the time of this writing, in all known implementations Background: At the time of this writing, in all known implementations
of FFV1 bitstream, when bits_per_raw_sample was between 9 and 15 of FFV1 bitstream, when bits_per_raw_sample was between 9 and 15
inclusive and extra_plane is 0, GBR "Planes" were used as BGR inclusive and extra_plane is 0, GBR "Planes" were used as BGR
"Planes" during both encoding and decoding. In the meanwhile, 16-bit "Planes" during both encoding and decoding. In the meanwhile, 16-bit
JPEG2000-RCT was implemented without this issue in one implementation JPEG2000-RCT was implemented without this issue in one implementation
and validated by one conformance checker. Methods to address this and validated by one conformance checker. Methods to address this
exception for the transform are under consideration for the next exception for the transform are under consideration for the next
version of the FFV1 bitstream. version of the FFV1 bitstream.
When FFV1 uses the JPEG2000-RCT, the horizontal "Lines" are When FFV1 uses the JPEG2000-RCT, the horizontal "Lines" are
interleaved to improve caching efficiency since it is most likely interleaved to improve caching efficiency since it is most likely
that the JPEG2000-RCT will immediately be converted to RGB during that the JPEG2000-RCT will immediately be converted to RGB during
decoding. The interleaved coding order is also Y, then Cb, then Cr, decoding. The interleaved coding order is also Y, then Cb, then Cr,
and then if used transparency. and then if used transparency.
As an example, a "Frame" that is two "Pixels" wide and two "Pixels" As an example, a "Frame" that is two "Pixels" wide and two "Pixels"
high, could be comprised of the following structure: high, could comprise the following structure:
+------------------------+------------------------+ +------------------------+------------------------+
| Pixel(1,1) | Pixel(2,1) | | Pixel(1,1) | Pixel(2,1) |
| Y(1,1) Cb(1,1) Cr(1,1) | Y(2,1) Cb(2,1) Cr(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) | | Pixel(1,2) | Pixel(2,2) |
| Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) | | Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) |
+------------------------+------------------------+ +------------------------+------------------------+
In JPEG2000-RCT, the coding order would be left to right and then top In JPEG2000-RCT, the coding order would be left to right and then top
skipping to change at page 15, line 17 skipping to change at page 15, line 17
Instead of coding the n+1 bits of the Sample Difference with Huffman Instead of coding the n+1 bits of the Sample Difference with Huffman
or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the
n (or n+1, in the case of JPEG2000-RCT) least significant bits are n (or n+1, in the case of JPEG2000-RCT) least significant bits are
used, since this is sufficient to recover the original "Sample". In used, since this is sufficient to recover the original "Sample". In
the equation below, the term "bits" represents bits_per_raw_sample+1 the equation below, the term "bits" represents bits_per_raw_sample+1
for JPEG2000-RCT or bits_per_raw_sample otherwise: for JPEG2000-RCT or bits_per_raw_sample otherwise:
coder_input = coder_input =
[(sample_difference + 2^(bits-1)) & (2^bits - 1)] - 2^(bits-1) [(sample_difference + 2^(bits-1)) & (2^bits - 1)] - 2^(bits-1)
Figure 5 Figure 7
3.8.1. Range Coding Mode 3.8.1. Range Coding Mode
Early experimental versions of FFV1 used the CABAC Arithmetic coder Early experimental versions of FFV1 used the CABAC Arithmetic coder
from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain
patent/royalty situation, as well as its slightly worse performance, patent/royalty situation, as well as its slightly worse performance,
CABAC was replaced by a Range coder based on an algorithm defined by CABAC was replaced by a Range coder based on an algorithm defined by
G. Nigel and N. Martin in 1979 [range-coding]. G. Nigel and N. Martin in 1979 [range-coding].
3.8.1.1. Range Binary Values 3.8.1.1. Range Binary Values
To encode binary digits efficiently a Range coder is used. "C~i~" is To encode binary digits efficiently a Range coder is used. "C~i~" is
the i-th Context. "B~i~" is the i-th byte of the bytestream. "b~i~" the i-th Context. "B~i~" is the i-th byte of the bytestream. "b~i~"
is the i-th Range coded binary value, "S~0,i~" is the i-th initial is the i-th Range coded binary value, "S~0,i~" is the i-th initial
state. The length of the bytestream encoding n binary symbols is state. The length of the bytestream encoding n binary symbols is
"j~n~" bytes. "j~n~" bytes.
r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 ) r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 )
Figure 6 Figure 8
S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} XOR S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} AND
l_i = L_i XOR l_i = L_i AND
t_i = R_i - r_i <== t_i = R_i - r_i <==
b_i = 0 <==> b_i = 0 <==>
L_i < R_i - r_i L_i < R_i - r_i
S_{i+1,C_{i}} = one_state_{S_{i,C_{i}}} XOR S_{i+1,C_{i}} = one_state_{S_{i,C_{i}}} AND
l_i = L_i - R_i + r_i XOR l_i = L_i - R_i + r_i AND
t_i = r_i <== t_i = r_i <==
b_i = 1 <==> b_i = 1 <==>
L_i >= R_i - r_i L_i >= R_i - r_i
Figure 7 Figure 9
S_{i+1,k} = S_{i,k} <== C_i != k S_{i+1,k} = S_{i,k} <== C_i != k
Figure 8 Figure 10
R_{i+1} = 2^8 * t_{i} XOR R_{i+1} = 2^8 * t_{i} AND
L_{i+1} = 2^8 * l_{i} + B_{j_{i}} XOR L_{i+1} = 2^8 * l_{i} + B_{j_{i}} AND
j_{i+1} = j_{i} + 1 <== j_{i+1} = j_{i} + 1 <==
t_{i} < 2^8 t_{i} < 2^8
R_{i+1} = t_{i} XOR R_{i+1} = t_{i} AND
L_{i+1} = l_{i} XOR L_{i+1} = l_{i} AND
j_{i+1} = j_{i} <== j_{i+1} = j_{i} <==
t_{i} >= 2^8 t_{i} >= 2^8
Figure 9 Figure 11
R_{0} = 65280 R_{0} = 65280
Figure 10 Figure 12
L_{0} = 2^8 * B_{0} + B_{1} L_{0} = 2^8 * B_{0} + B_{1}
Figure 11 Figure 13
j_{0} = 2 j_{0} = 2
Figure 12 Figure 14
3.8.1.1.1. Termination 3.8.1.1.1. Termination
The range coder can be used in 3 modes. The range coder can be used in 3 modes.
* In "Open mode" when decoding, every symbol the reader attempts to * In "Open mode" when decoding, every symbol the reader attempts to
read is available. In this mode arbitrary data can have been read is available. In this mode arbitrary data can have been
appended without affecting the range coder output. This mode is appended without affecting the range coder output. This mode is
not used in FFV1. not used in FFV1.
skipping to change at page 17, line 33 skipping to change at page 17, line 33
To encode scalar integers, it would be possible to encode each bit To encode scalar integers, it would be possible to encode each bit
separately and use the past bits as context. However that would mean separately and use the past bits as context. However that would mean
255 contexts per 8-bit symbol that is not only a waste of memory but 255 contexts per 8-bit symbol that is not only a waste of memory but
also requires more past data to reach a reasonably good estimate of also requires more past data to reach a reasonably good estimate of
the probabilities. Alternatively assuming a Laplacian distribution the probabilities. Alternatively assuming a Laplacian distribution
and only dealing with its variance and mean (as in Huffman coding) and only dealing with its variance and mean (as in Huffman coding)
would also be possible, however, for maximum flexibility and would also be possible, however, for maximum flexibility and
simplicity, the chosen method uses a single symbol to encode if a simplicity, the chosen method uses a single symbol to encode if a
number is 0, and if not, encodes the number using its exponent, number is 0, and if not, encodes the number using its exponent,
mantissa and sign. The exact contexts used are best described by the mantissa and sign. The exact contexts used are best described by
following code, followed by some comments. Figure 15, followed by some comments.
pseudo-code | type pseudo-code | type
--------------------------------------------------------------|----- --------------------------------------------------------------|-----
void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ | void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ |
is_signed) { | is_signed) { |
int i; | int i; |
put_rac(c, state+0, !v); | put_rac(c, state+0, !v); |
if (v) { | if (v) { |
int a= abs(v); | int a= abs(v); |
int e= log2(a); | int e= log2(a); |
skipping to change at page 18, line 30 skipping to change at page 18, line 30
for (i = e-1; i >= 0; i--) { | for (i = e-1; i >= 0; i--) { |
put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 |
} | } |
| |
if (is_signed) { | if (is_signed) { |
put_rac(c, state+11 + min(e, 10), v < 0); //11..21| put_rac(c, state+11 + min(e, 10), v < 0); //11..21|
} | } |
} | } |
} | } |
Figure 15: A pseudo-code description of the contexts of Range Non
Binary Values.
3.8.1.3. Initial Values for the Context Model 3.8.1.3. Initial Values for the Context Model
At keyframes all Range coder state variables are set to their initial At keyframes all Range coder state variables are set to their initial
state. state.
3.8.1.4. State Transition Table 3.8.1.4. State Transition Table
one_state_{i} = one_state_{i} =
default_state_transition_{i} + state_transition_delta_{i} default_state_transition_{i} + state_transition_delta_{i}
Figure 13 Figure 16
zero_state_{i} = 256 - one_state_{256-i} zero_state_{i} = 256 - one_state_{256-i}
Figure 14 Figure 17
3.8.1.5. default_state_transition 3.8.1.5. default_state_transition
0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27, 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, 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, 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, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
skipping to change at page 19, line 40 skipping to change at page 19, line 40
210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225, 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, 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, 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0,
3.8.1.6. Alternative State Transition Table 3.8.1.6. Alternative State Transition Table
The alternative state transition table has been built using iterative The alternative state transition table has been built using iterative
minimization of frame sizes and generally performs better than the minimization of frame sizes and generally performs better than the
default. To use it, the coder_type (see the section on coder_type default. To use it, the coder_type (see Section 4.1.3) MUST be set
(#codertype)) MUST be set to 2 and the difference to the default MUST to 2 and the difference to the default MUST be stored in the
be stored in the "Parameters", see the section on Parameters "Parameters", see Section 4.1. The reference implementation of FFV1
(#parameters). The reference implementation of FFV1 in FFmpeg uses in FFmpeg uses Figure 18 by default at the time of this writing when
this table by default at the time of this writing when Range coding Range coding is used.
is used.
0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49, 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, 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, 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, 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, 87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97,
skipping to change at page 20, line 37 skipping to change at page 20, line 37
175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196, 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, 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, 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, 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, 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255,
Figure 18: Alternative state transition table for Range coding.
3.8.2. Golomb Rice Mode 3.8.2. Golomb Rice Mode
The end of the bitstream of the "Frame" is filled with 0-bits until The end of the bitstream of the "Frame" is filled with 0-bits until
that the bitstream contains a multiple of 8 bits. that the bitstream contains a multiple of 8 bits.
3.8.2.1. Signed Golomb Rice Codes 3.8.2.1. Signed Golomb Rice Codes
This coding mode uses Golomb Rice codes. The VLC is split into 2 This coding mode uses Golomb Rice codes. The VLC is split into 2
parts, the prefix stores the most significant bits and the suffix parts, the prefix stores the most significant bits and the suffix
stores the k least significant bits or stores the whole number in the stores the k least significant bits or stores the whole number in the
skipping to change at page 25, line 16 skipping to change at page 25, line 16
error_sum = 4; error_sum = 4;
bias = 0; bias = 0;
count = 1; count = 1;
4. Bitstream 4. Bitstream
An FFV1 bitstream is composed of a series of 1 or more "Frames" and An FFV1 bitstream is composed of a series of 1 or more "Frames" and
(when required) a "Configuration Record". (when required) a "Configuration Record".
Within the following sub-sections, pseudo-code is used to explain the Within the following sub-sections, pseudo-code is used to explain the
structure of each FFV1 bitstream component, as described in the structure of each FFV1 bitstream component, as described in
section on Pseudo-Code (#pseudocode). The following table lists Section 2.2.1. Table 4 lists symbols used to annotate that pseudo-
symbols used to annotate that pseudo-code in order to define the code in order to define the storage of the data referenced in that
storage of the data referenced in that line of pseudo-code. line of pseudo-code.
+--------+-------------------------------------------+ +--------+----------------------------------------------+
| Symbol | Definition | | Symbol | Definition |
+========+===========================================+ +========+==============================================+
| u(n) | unsigned big endian integer using n bits | | u(n) | unsigned big endian integer using n bits |
+--------+-------------------------------------------+ +--------+----------------------------------------------+
| sg | Golomb Rice coded signed scalar symbol | | sg | Golomb Rice coded signed scalar symbol coded |
| | coded with the method described in Signed | | | with the method described in Section 3.8.2 |
| | Golomb Rice Codes (#golomb-rice-mode) | +--------+----------------------------------------------+
+--------+-------------------------------------------+ | br | Range coded Boolean (1-bit) symbol with the |
| br | Range coded Boolean (1-bit) symbol with | | | method described in Section 3.8.1.1 |
| | the method described in Range binary | +--------+----------------------------------------------+
| | values (#range-binary-values) | | ur | Range coded unsigned scalar symbol coded |
+--------+-------------------------------------------+ | | with the method described in Section 3.8.1.2 |
| ur | Range coded unsigned scalar symbol coded | +--------+----------------------------------------------+
| | with the method described in Range non | | sr | Range coded signed scalar symbol coded with |
| | binary values (#range-non-binary-values) | | | the method described in Section 3.8.1.2 |
+--------+-------------------------------------------+ +--------+----------------------------------------------+
| sr | Range coded signed scalar symbol coded |
| | with the method described in Range non |
| | binary values (#range-non-binary-values) |
+--------+-------------------------------------------+
Table 4 Table 4: Definition of pseudo-code symbols for this
document.
The same context that is initialized to 128 is used for all fields in The same context that is initialized to 128 is used for all fields in
the header. the header.
The following MUST be provided by external means during The following MUST be provided by external means during
initialization of the decoder: initialization of the decoder:
"frame_pixel_width" is defined as "Frame" width in "Pixels". "frame_pixel_width" is defined as "Frame" width in "Pixels".
"frame_pixel_height" is defined as "Frame" height in "Pixels". "frame_pixel_height" is defined as "Frame" height in "Pixels".
skipping to change at page 26, line 17 skipping to change at page 26, line 13
Default values at the decoder initialization phase: Default values at the decoder initialization phase:
"ConfigurationRecordIsPresent" is set to 0. "ConfigurationRecordIsPresent" is set to 0.
4.1. Parameters 4.1. Parameters
The "Parameters" section contains significant characteristics about The "Parameters" section contains significant characteristics about
the decoding configuration used for all instances of "Frame" (in FFV1 the decoding configuration used for all instances of "Frame" (in FFV1
version 0 and 1) or the whole FFV1 bitstream (other versions), version 0 and 1) or the whole FFV1 bitstream (other versions),
including the stream version, color configuration, and quantization including the stream version, color configuration, and quantization
tables. The pseudo-code below describes the contents of the tables. Figure 19 describes the contents of the bitstream.
bitstream.
pseudo-code | type pseudo-code | type
--------------------------------------------------------------|----- --------------------------------------------------------------|-----
Parameters( ) { | Parameters( ) { |
version | ur version | ur
if (version >= 3) { | if (version >= 3) { |
micro_version | ur micro_version | ur
} | } |
coder_type | ur coder_type | ur
if (coder_type > 1) { | if (coder_type > 1) { |
skipping to change at page 27, line 50 skipping to change at page 27, line 50
initial_state_delta[ i ][ j ][ k ] | sr initial_state_delta[ i ][ j ][ k ] | sr
} | } |
} | } |
} | } |
} | } |
ec | ur ec | ur
intra | ur intra | ur
} | } |
} | } |
Figure 19: A pseudo-code description of the bitstream contents.
CONTEXT_SIZE is 32. CONTEXT_SIZE is 32.
4.1.1. version 4.1.1. version
"version" specifies the version of the FFV1 bitstream. "version" specifies the version of the FFV1 bitstream.
Each version is incompatible with other versions: decoders SHOULD Each version is incompatible with other versions: decoders SHOULD
reject a file due to an unknown version. reject a file due to an unknown version.
Decoders SHOULD reject a file with version <= 1 && Decoders SHOULD reject a file with version <= 1 &&
skipping to change at page 29, line 15 skipping to change at page 29, line 15
+-------+-------------------------+ +-------+-------------------------+
| value | micro_version | | value | micro_version |
+=======+=========================+ +=======+=========================+
| 0...3 | reserved* | | 0...3 | reserved* |
+-------+-------------------------+ +-------+-------------------------+
| 4 | first stable variant | | 4 | first stable variant |
+-------+-------------------------+ +-------+-------------------------+
| Other | reserved for future use | | Other | reserved for future use |
+-------+-------------------------+ +-------+-------------------------+
Table 6 Table 6: The definitions for
micro_version values.
* development versions may be incompatible with the stable variants. * development versions may be incompatible with the stable variants.
4.1.3. coder_type 4.1.3. coder_type
"coder_type" specifies the coder used. "coder_type" specifies the coder used.
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| value | coder used | | value | coder used |
+=======+=================================================+ +=======+=================================================+
skipping to change at page 32, line 46 skipping to change at page 32, line 46
Table 12 Table 12
4.1.15. initial_state_delta 4.1.15. initial_state_delta
"initial_state_delta[ i ][ j ][ k ]" indicates the initial Range "initial_state_delta[ i ][ j ][ k ]" indicates the initial Range
coder state, it is encoded using "k" as context index and coder state, it is encoded using "k" as context index and
pred = j ? initial_states[ i ][j - 1][ k ] pred = j ? initial_states[ i ][j - 1][ k ]
Figure 15 Figure 20
initial_state[ i ][ j ][ k ] = initial_state[ i ][ j ][ k ] =
( pred + initial_state_delta[ i ][ j ][ k ] ) & 255 ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255
Figure 16 Figure 21
4.1.16. ec 4.1.16. ec
"ec" indicates the error detection/correction type. "ec" indicates the error detection/correction type.
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| value | error detection/correction type | | value | error detection/correction type |
+=======+============================================+ +=======+============================================+
| 0 | 32-bit CRC on the global header | | 0 | 32-bit CRC on the global header |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
skipping to change at page 38, line 4 skipping to change at page 38, line 4
of the specification and may have a significance in a later revision of the specification and may have a significance in a later revision
of this specification. of this specification.
Encoders SHOULD NOT fill these bits. Encoders SHOULD NOT fill these bits.
Decoders SHOULD ignore these bits. Decoders SHOULD ignore these bits.
Note in case these bits are used in a later revision of this Note in case these bits are used in a later revision of this
specification: any revision of this specification SHOULD care about specification: any revision of this specification SHOULD care about
avoiding to add 40 bits of content after "SliceContent" for version 0 avoiding to add 40 bits of content after "SliceContent" for version 0
and 1 of the bitstream. Background: due to some non conforming and 1 of the bitstream. Background: Due to some non-conforming
encoders, some bitstreams where found with 40 extra bits encoders, some bitstreams were found with 40 extra bits corresponding
corresponding to "error_status" and "slice_crc_parity", a decoder to "error_status" and "slice_crc_parity". As a result, a decoder
conforming to the revised specification could not do the difference conforming to the revised specification could not distinguish between
between a revised bitstream and a buggy bitstream. a revised bitstream and a buggy bitstream.
4.5. Slice Header 4.5. Slice Header
A "Slice Header" provides information about the decoding A "Slice Header" provides information about the decoding
configuration of the "Slice", such as its spatial position, size, and configuration of the "Slice", such as its spatial position, size, and
aspect ratio. The pseudo-code below describes the contents of the aspect ratio. The pseudo-code below describes the contents of the
"Slice Header". "Slice Header".
pseudo-code | type pseudo-code | type
--------------------------------------------------------------|----- --------------------------------------------------------------|-----
skipping to change at page 42, line 49 skipping to change at page 42, line 49
"slice_pixel_x" is the slice horizontal position in "Pixels". "slice_pixel_x" is the slice horizontal position in "Pixels".
Its value is "floor( slice_x * frame_pixel_width / num_h_slices )". Its value is "floor( slice_x * frame_pixel_width / num_h_slices )".
4.7.4. sample_difference 4.7.4. sample_difference
"sample_difference[ p ][ y ][ x ]" is the sample difference for "sample_difference[ p ][ y ][ x ]" is the sample difference for
"Sample" at "Plane" "p", y position "y", and x position "x". The "Sample" at "Plane" "p", y position "y", and x position "x". The
"Sample" value is computed based on median predictor and context "Sample" value is computed based on median predictor and context
described in the section on Samples (#samples). described in Section 3.2.
4.8. Slice Footer 4.8. Slice Footer
A "Slice Footer" provides information about slice size and A "Slice Footer" provides information about slice size and
(optionally) parity. The pseudo-code below describes the contents of (optionally) parity. The pseudo-code below describes the contents of
the "Slice Footer". the "Slice Footer".
Note: "Slice Footer" is always byte aligned. Note: "Slice Footer" is always byte aligned.
pseudo-code | type pseudo-code | type
skipping to change at page 44, line 15 skipping to change at page 44, line 15
This is equivalent to storing the crc remainder in the 32-bit parity. This is equivalent to storing the crc remainder in the 32-bit parity.
The CRC generator polynomial used is the standard IEEE CRC polynomial The CRC generator polynomial used is the standard IEEE CRC polynomial
(0x104C11DB7), with initial value 0, without pre-inversion and (0x104C11DB7), with initial value 0, without pre-inversion and
without post-inversion. without post-inversion.
4.9. Quantization Table Set 4.9. Quantization Table Set
The Quantization Table Sets are stored by storing the number of equal The Quantization Table Sets are stored by storing the number of equal
entries -1 of the first half of the table (represented as "len - 1" entries -1 of the first half of the table (represented as "len - 1"
in the pseudo-code below) using the method described in Range Non in the pseudo-code below) using the method described in
Binary Values (#range-non-binary-values). The second half doesn't Section 3.8.1.2. The second half doesn't need to be stored as it is
need to be stored as it is identical to the first with flipped sign. identical to the first with flipped sign. "scale" and "len_count[ i
"scale" and "len_count[ i ][ j ]" are temporary values used for the ][ j ]" are temporary values used for the computing of
computing of "context_count[ i ]" and are not used outside "context_count[ i ]" and are not used outside Quantization Table Set
Quantization Table Set pseudo-code. pseudo-code.
Example: Example:
Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0 Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0
Stored values: 1, 3, 1 Stored values: 1, 3, 1
pseudo-code | type pseudo-code | type
--------------------------------------------------------------|----- --------------------------------------------------------------|-----
QuantizationTableSet( i ) { | QuantizationTableSet( i ) { |
skipping to change at page 47, line 22 skipping to change at page 47, line 22
Subtype name: FFV1 Subtype name: FFV1
Required parameters: None. Required parameters: None.
Optional parameters: Optional parameters:
This parameter is used to signal the capabilities of a receiver This parameter is used to signal the capabilities of a receiver
implementation. This parameter MUST NOT be used for any other implementation. This parameter MUST NOT be used for any other
purpose. purpose.
version: The version of the FFV1 encoding as defined by the section version: The version of the FFV1 encoding as defined by
on version (#version). Section 4.1.1.
micro_version: The micro_version of the FFV1 encoding as defined by micro_version: The micro_version of the FFV1 encoding as defined by
the section on micro_version (#micro-version). Section 4.1.2.
coder_type: The coder_type of the FFV1 encoding as defined by the coder_type: The coder_type of the FFV1 encoding as defined by
section on coder_type (#coder-type). Section 4.1.3.
colorspace_type: The colorspace_type of the FFV1 encoding as defined colorspace_type: The colorspace_type of the FFV1 encoding as defined
by the section on colorspace_type (#colorspace-type). by Section 4.1.5.
bits_per_raw_sample: The bits_per_raw_sample of the FFV1 encoding as bits_per_raw_sample: The bits_per_raw_sample of the FFV1 encoding as
defined by the section on bits_per_raw_sample (#bits-per-raw-sample). defined by Section 4.1.7.
max-slices: The value of max-slices is an integer indicating the max-slices: The value of max-slices is an integer indicating the
maximum count of slices with a frames of the FFV1 encoding. maximum count of slices with a frames of the FFV1 encoding.
Encoding considerations: Encoding considerations:
This media type is defined for encapsulation in several audiovisual This media type is defined for encapsulation in several audiovisual
container formats and contains binary data; see the section on container formats and contains binary data; see Section 4.2.3. This
"Mapping FFV1 into Containers" (#mapping-ffv1-into-containers). This
media type is framed binary data Section 4.8 of [RFC6838]. media type is framed binary data Section 4.8 of [RFC6838].
Security considerations: Security considerations:
See the "Security Considerations" section (#security-considerations) See Section 6 of this document.
of this document.
Interoperability considerations: None. Interoperability considerations: None.
Published specification: Published specification:
[I-D.ietf-cellar-ffv1] and RFC XXXX. [I-D.ietf-cellar-ffv1] and RFC XXXX.
[RFC Editor: Upon publication as an RFC, please replace "XXXX" with [RFC Editor: Upon publication as an RFC, please replace "XXXX" with
the number assigned to this document and remove this note.] the number assigned to this document and remove this note.]
skipping to change at page 48, line 37 skipping to change at page 48, line 35
Restrictions on usage: None. Restrictions on usage: None.
Author: Dave Rice dave@dericed.com (mailto:dave@dericed.com) Author: Dave Rice dave@dericed.com (mailto:dave@dericed.com)
Change controller: IETF cellar working group delegated from the IESG. Change controller: IETF cellar working group delegated from the IESG.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to register the following values: The IANA is requested to register the following values:
* Media type registration as described in Media Type Definition * Media type registration as described in Section 7.
(#media-type-definition).
9. Appendixes 9. Appendixes
9.1. Decoder implementation suggestions 9.1. Decoder implementation suggestions
9.1.1. Multi-threading Support and Independence of Slices 9.1.1. Multi-threading Support and Independence of Slices
The FFV1 bitstream is parsable in two ways: in sequential order as 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 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 each slice. Each slice footer contains a slice_size field so the
skipping to change at page 49, line 21 skipping to change at page 49, line 18
coherent...) or if there is no possibility of seeking into the coherent...) or if there is no possibility of seeking into the
stream. stream.
10. Changelog 10. Changelog
See https://github.com/FFmpeg/FFV1/commits/master See https://github.com/FFmpeg/FFV1/commits/master
(https://github.com/FFmpeg/FFV1/commits/master) (https://github.com/FFmpeg/FFV1/commits/master)
11. Normative References 11. Normative References
[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>.
[I-D.ietf-cellar-ffv1] [I-D.ietf-cellar-ffv1]
Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video
Coding Format Version 0, 1, and 3", Work in Progress, Coding Format Version 0, 1, and 3", Work in Progress,
Internet-Draft, draft-ietf-cellar-ffv1-09, 6 September Internet-Draft, draft-ietf-cellar-ffv1-11, 23 October
2019, 2019,
<https://tools.ietf.org/html/draft-ietf-cellar-ffv1-09>. <https://tools.ietf.org/html/draft-ietf-cellar-ffv1-11>.
[ISO.15444-1.2016] [ISO.15444-1.2016]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- JPEG 2000 image coding system: "Information technology -- JPEG 2000 image coding system:
Core coding system", October 2016. Core coding system", October 2016.
[ISO.9899.1990] [ISO.9899.1990]
International Organization for Standardization, International Organization for Standardization,
"Programming languages - C", 1990. "Programming languages - C", 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Requirement Levels", BCP 14, RFC 2119, Specifications and Registration Procedures", BCP 13,
DOI 10.17487/RFC2119, March 1997, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc6838>.
[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 [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>. <https://www.rfc-editor.org/info/rfc4855>.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
September 2012, <https://www.rfc-editor.org/info/rfc6716>. September 2012, <https://www.rfc-editor.org/info/rfc6716>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [Matroska] IETF, "Matroska", 2019, <https://datatracker.ietf.org/doc/
Specifications and Registration Procedures", BCP 13, draft-ietf-cellar-matroska/>.
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>.
[ISO.9899.2018]
International Organization for Standardization,
"Programming languages - C", 2018.
12. Informative References 12. Informative References
[FFV1_V1] Niedermayer, M., "Commit to release FFV1 version 1", April
2009, <https://git.videolan.org/?p=ffmpeg.git;a=commit;h=6
8f8d33becbd73b4d0aa277f472a6e8e72ea6849>.
[ISO.14495-1.1999]
International Organization for Standardization,
"Information technology -- Lossless and near-lossless
compression of continuous-tone still images: Baseline",
December 1999.
[Address-Sanitizer] [Address-Sanitizer]
The Clang Team, "ASAN AddressSanitizer website", undated, The Clang Team, "ASAN AddressSanitizer website", undated,
<https://clang.llvm.org/docs/AddressSanitizer.html>. <https://clang.llvm.org/docs/AddressSanitizer.html>.
[AVI] Microsoft, "AVI RIFF File Reference", undated, [AVI] Microsoft, "AVI RIFF File Reference", undated,
<https://msdn.microsoft.com/en-us/library/windows/desktop/ <https://msdn.microsoft.com/en-us/library/windows/desktop/
dd318189%28v=vs.85%29.aspx>. dd318189%28v=vs.85%29.aspx>.
[HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003,
<https://web.archive.org/web/20040402121343/
http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>.
[ISO.14496-10.2014]
International Organization for Standardization,
"Information technology -- Coding of audio-visual objects
-- Part 10: Advanced Video Coding", September 2014.
[FFV1_V0] Niedermayer, M., "Commit to mark FFV1 version 0 as non- [FFV1_V0] Niedermayer, M., "Commit to mark FFV1 version 0 as non-
experimental", April 2006, <https://git.videolan.org/?p=ff experimental", April 2006, <https://git.videolan.org/?p=ff
mpeg.git;a=commit;h=b548f2b91b701e1235608ac882ea6df915167c mpeg.git;a=commit;h=b548f2b91b701e1235608ac882ea6df915167c
7e>. 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- [FFV1_V3] Niedermayer, M., "Commit to mark FFV1 version 3 as non-
experimental", August 2013, <https://git.videolan.org/?p=f experimental", August 2013, <https://git.videolan.org/?p=f
fmpeg.git;a=commit;h=abe76b851c05eea8743f6c899cbe5f7409b0f fmpeg.git;a=commit;h=abe76b851c05eea8743f6c899cbe5f7409b0f
301>. 301>.
[HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, [VALGRIND] Valgrind Developers, "Valgrind website", undated,
<https://web.archive.org/web/20040402121343/ <https://valgrind.org/>.
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",
December 1999.
[ISO.14496-10.2014] [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the
International Organization for Standardization, FFV1 codec in FFmpeg", undated, <https://ffmpeg.org>.
"Information technology -- Coding of audio-visual objects
-- Part 10: Advanced Video Coding", September 2014.
[ISO.14496-12.2015] [ISO.14496-12.2015]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- Coding of audio-visual objects "Information technology -- Coding of audio-visual objects
-- Part 12: ISO base media file format", December 2015. -- Part 12: ISO base media file format", December 2015.
[Matroska] IETF, "Matroska", 2016, <https://datatracker.ietf.org/doc/
draft-lhomme-cellar-matroska/>.
[NUT] Niedermayer, M., "NUT Open Container Format", December
2013, <https://ffmpeg.org/~michael/nut.txt>.
[range-coding] [range-coding]
Nigel, G. and N. Martin, "Range encoding: an algorithm for Nigel, G. and N. Martin, "Range encoding: an algorithm for
removing redundancy from a digitised message.", July 1979. removing redundancy from a digitised message.", July 1979.
[REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the
FFV1 codec in FFmpeg", undated, <https://ffmpeg.org>.
[VALGRIND] Valgrind Developers, "Valgrind website", undated,
<https://valgrind.org/>.
[YCbCr] Wikipedia, "YCbCr", undated, [YCbCr] Wikipedia, "YCbCr", undated,
<https://en.wikipedia.org/w/index.php?title=YCbCr>. <https://en.wikipedia.org/w/index.php?title=YCbCr>.
[NUT] Niedermayer, M., "NUT Open Container Format", December
2013, <https://ffmpeg.org/~michael/nut.txt>.
Authors' Addresses Authors' Addresses
Michael Niedermayer Michael Niedermayer
Email: michael@niedermayer.cc Email: michael@niedermayer.cc
Dave Rice Dave Rice
Email: dave@dericed.com Email: dave@dericed.com
 End of changes. 73 change blocks. 
168 lines changed or deleted 177 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/