draft-ietf-cellar-ffv1-12.txt   draft-ietf-cellar-ffv1-13.txt 
cellar M. Niedermayer cellar M. Niedermayer
Internet-Draft Internet-Draft
Intended status: Informational D. Rice Intended status: Informational D. Rice
Expires: 30 July 2020 Expires: 30 October 2020
J. Martinez J. Martinez
27 January 2020 28 April 2020
FFV1 Video Coding Format Version 0, 1, and 3 FFV1 Video Coding Format Version 0, 1, and 3
draft-ietf-cellar-ffv1-12 draft-ietf-cellar-ffv1-13
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 36 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 30 July 2020. This Internet-Draft will expire on 30 October 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 41 skipping to change at page 2, line 48
3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8. Coding of the Sample Difference . . . . . . . . . . . . . 15 3.8. Coding of the Sample Difference . . . . . . . . . . . . . 15
3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 15 3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 15
3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 20 3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 20
4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 26 4.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.2. micro_version . . . . . . . . . . . . . . . . . . . . 28 4.1.2. micro_version . . . . . . . . . . . . . . . . . . . . 28
4.1.3. coder_type . . . . . . . . . . . . . . . . . . . . . 29 4.1.3. coder_type . . . . . . . . . . . . . . . . . . . . . 29
4.1.4. state_transition_delta . . . . . . . . . . . . . . . 29 4.1.4. state_transition_delta . . . . . . . . . . . . . . . 29
4.1.5. colorspace_type . . . . . . . . . . . . . . . . . . . 29 4.1.5. colorspace_type . . . . . . . . . . . . . . . . . . . 30
4.1.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 30 4.1.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 30
4.1.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 30 4.1.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 31
4.1.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 31 4.1.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 31
4.1.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 31 4.1.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 31
4.1.10. extra_plane . . . . . . . . . . . . . . . . . . . . . 31 4.1.10. "extra\_plane" . . . . . . . . . . . . . . . . . . . 31
4.1.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 31 4.1.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 31
4.1.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 32 4.1.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 32
4.1.13. quant_table_set_count . . . . . . . . . . . . . . . . 32 4.1.13. quant_table_set_count . . . . . . . . . . . . . . . . 32
4.1.14. states_coded . . . . . . . . . . . . . . . . . . . . 32 4.1.14. states_coded . . . . . . . . . . . . . . . . . . . . 32
4.1.15. initial_state_delta . . . . . . . . . . . . . . . . . 32 4.1.15. initial_state_delta . . . . . . . . . . . . . . . . . 32
4.1.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Configuration Record . . . . . . . . . . . . . . . . . . 33 4.2. Configuration Record . . . . . . . . . . . . . . . . . . 33
4.2.1. reserved_for_future_use . . . . . . . . . . . . . . . 34 4.2.1. reserved_for_future_use . . . . . . . . . . . . . . . 34
4.2.2. configuration_record_crc_parity . . . . . . . . . . . 34 4.2.2. configuration_record_crc_parity . . . . . . . . . . . 34
skipping to change at page 3, line 43 skipping to change at page 3, line 49
4.8.1. slice_size . . . . . . . . . . . . . . . . . . . . . 43 4.8.1. slice_size . . . . . . . . . . . . . . . . . . . . . 43
4.8.2. error_status . . . . . . . . . . . . . . . . . . . . 43 4.8.2. error_status . . . . . . . . . . . . . . . . . . . . 43
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. Appendix A: Multi-theaded decoder implementation
9.1. Decoder implementation suggestions . . . . . . . . . . . 48 suggestions . . . . . . . . . . . . . . . . . . . . . . . 48
9.1.1. Multi-threading Support and Independence of 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 6, line 19 skipping to change at page 6, line 19
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"
keywords 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.2018]. 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 re-defined within this section.
"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.
"a ^ b" means a raised to the b-th power. "a ^ b" means a raised to the b-th power.
"a & b" means bit-wise "and" of a and b. "a & b" means bit-wise "and" of a and b.
"a | b" means bit-wise "or" of a and b. "a | b" means bit-wise "or" of a and b.
"a >> b" means arithmetic right shift of two's complement integer "a >> b" means arithmetic right shift of two's complement integer
representation of a by b binary digits. representation of a by b binary digits. This is equivalent to, b
times dividing a by 2 with rounding toward negative infinity.
"a << b" means arithmetic left shift of two's complement integer "a << b" means arithmetic left shift of two's complement integer
representation of a by b binary digits. representation of a by b binary digits.
2.2.3. Assignment Operators 2.2.3. Assignment Operators
"a = b" means a is assigned b. "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.
skipping to change at page 7, line 50 skipping to change at page 8, line 4
abs(a) the absolute value of a, i.e. abs(a) = sign(a)*a abs(a) the absolute value of a, i.e. abs(a) = sign(a)*a
log2(a) the base-two logarithm of a log2(a) the base-two logarithm of a
min(a,b) the smallest of two values a and b min(a,b) the smallest of two values a and b
max(a,b) the largest of two values a and b max(a,b) the largest of two values a and b
median(a,b,c) the numerical middle value in a data set of a, b, and median(a,b,c) 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) c, i.e. a+b+c-min(a,b,c)-max(a,b,c)
A <== B B implies A
a_(b) the b-th value of a sequence of a A <==> B A <== B , B <== A
a~b,c. the 'b,c'-th value of a sequence of a
2.2.6. Order of Operation Precedence 2.2.6. Order of Operation Precedence
When order of precedence is not indicated explicitly by use of When order of precedence is not indicated explicitly by use of
parentheses, operations are evaluated in the following order (from parentheses, operations are evaluated in the following order (from
top to bottom, operations of same precedence being evaluated from top to bottom, operations of same precedence being evaluated from
left to right). This order of operations is based on the order of left to right). This order of operations is based on the order of
operations used in Standard C. operations used in Standard C.
a++, a-- a++, a--
skipping to change at page 14, line 5 skipping to change at page 14, line 5
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 5 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"
between 9 and 15 inclusive and extra_plane is 0, the following is 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 6 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.
Cb and Cr are positively offseted by "1 << bits_per_raw_sample" after
the conversion from RGB to the modified YCbCr and are negatively
offseted by the same value before the conversion from the modified
YCbCr to RGB, in order to have only non-negative values after the
conversion.
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 comprise the following structure: high, could comprise the following structure:
+------------------------+------------------------+ +------------------------+------------------------+
skipping to change at page 15, line 11 skipping to change at page 15, line 17
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) 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) Cb(2,2) Cr(1,2) Cr(2,2)
3.8. Coding of the Sample Difference 3.8. Coding of the Sample Difference
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 +
for JPEG2000-RCT or bits_per_raw_sample otherwise: 1" 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 7 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 8 Figure 8
S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} AND S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} AND
l_i = L_i AND 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
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 Section 4.1.3) MUST be set default. To use it, the "coder_type" (see Section 4.1.3) MUST be set
to 2 and the difference to the default MUST be stored in the to 2 and the difference to the default MUST be stored in the
"Parameters", see Section 4.1. The reference implementation of FFV1 "Parameters", see Section 4.1. The reference implementation of FFV1
in FFmpeg uses Figure 18 by default at the time of this writing when in FFmpeg uses Figure 18 by default at the time of this writing when
Range coding is used. Range coding 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,
skipping to change at page 21, line 33 skipping to change at page 21, line 33
+----------------+-------+ +----------------+-------+
| bits | value | | bits | value |
+================+=======+ +================+=======+
| 1 | 0 | | 1 | 0 |
+----------------+-------+ +----------------+-------+
| 01 | 1 | | 01 | 1 |
+----------------+-------+ +----------------+-------+
| ... | ... | | ... | ... |
+----------------+-------+ +----------------+-------+
| 0000 0000 01 | 9 |
+----------------+-------+
| 0000 0000 001 | 10 |
+----------------+-------+
| 0000 0000 0001 | 11 | | 0000 0000 0001 | 11 |
+----------------+-------+ +----------------+-------+
| 0000 0000 0000 | ESC | | 0000 0000 0000 | ESC |
+----------------+-------+ +----------------+-------+
Table 1 Table 1
3.8.2.1.2. Suffix 3.8.2.1.2. Suffix
+---------+--------------------------------------------------+ +---------+--------------------------------------------------+
skipping to change at page 22, line 34 skipping to change at page 22, line 35
3.8.2.2. Run Mode 3.8.2.2. Run Mode
Run mode is entered when the context is 0 and left as soon as a non-0 Run mode is entered when the context is 0 and left as soon as a non-0
difference is found. The level is identical to the predicted one. difference is found. The level is identical to the predicted one.
The run and the first different level are coded. The run and the first different level are coded.
3.8.2.2.1. Run Length Coding 3.8.2.2.1. Run Length Coding
The run value is encoded in 2 parts, the prefix part stores the more The run value is encoded in 2 parts, the prefix part stores the more
significant part of the run as well as adjusting the run_index that 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 determines the number of bits in the less significant part of the
run. The 2nd part of the value stores the less significant part of run. The 2nd part of the value stores the less significant part of
the run as it is. The run_index is reset for each "Plane" and slice the run as it is. The run_index is reset for each "Plane" and slice
to 0. to 0.
pseudo-code | type pseudo-code | type
--------------------------------------------------------------|----- --------------------------------------------------------------|-----
log2_run[41]={ | log2_run[41]={ |
0, 0, 0, 0, 1, 1, 1, 1, | 0, 0, 0, 0, 1, 1, 1, 1, |
2, 2, 2, 2, 3, 3, 3, 3, | 2, 2, 2, 2, 3, 3, 3, 3, |
skipping to change at page 23, line 35 skipping to change at page 23, line 35
} else { | } else { |
run_count = 0; | run_count = 0; |
} | } |
if (run_index) { | if (run_index) { |
run_index--; | run_index--; |
} | } |
run_mode = 2; | run_mode = 2; |
} | } |
} | } |
The log2_run function is also used within [ISO.14495-1.1999]. The "log2_run" function is also used within [ISO.14495-1.1999].
3.8.2.2.2. Level Coding 3.8.2.2.2. Level Coding
Level coding is identical to the normal difference coding with the Level coding is identical to the normal difference coding with the
exception that the 0 value is removed as it cannot occur: exception that the 0 value is removed as it cannot occur:
diff = get_vlc_symbol(context_state); diff = get_vlc_symbol(context_state);
if (diff >= 0) { if (diff >= 0) {
diff++; diff++;
} }
skipping to change at page 28, line 49 skipping to change at page 28, line 49
"micro_version" specifies the micro-version of the FFV1 bitstream. "micro_version" specifies the micro-version of the FFV1 bitstream.
After a version is considered stable (a micro-version value is After a version is considered stable (a micro-version value is
assigned to be the first stable variant of a specific version), each assigned to be the first stable variant of a specific version), each
new micro-version after this first stable variant is compatible with new micro-version after this first stable variant is compatible with
the previous micro-version: decoders SHOULD NOT reject a file due to the previous micro-version: decoders SHOULD NOT reject a file due to
an unknown micro-version equal or above the micro-version considered an unknown micro-version equal or above the micro-version considered
as stable. as stable.
Meaning of micro_version for version 3: Meaning of "micro_version" for version 3:
+-------+-------------------------+ +-------+-------------------------+
| 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: The definitions for Table 6: The definitions for
micro_version values. "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 29, line 38 skipping to change at page 29, line 38
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| 1 | Range Coder with default state transition table | | 1 | Range Coder with default state transition table |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| 2 | Range Coder with custom state transition table | | 2 | Range Coder with custom state transition table |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| Other | reserved for future use | | Other | reserved for future use |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
Table 7 Table 7
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
implementations of FFV1 bitstream supporting Golomb Rice algorithm
with "bits_per_raw_sample" greater than 8, and Range Coder is
prefered.
4.1.4. state_transition_delta 4.1.4. state_transition_delta
"state_transition_delta" specifies the Range coder custom state "state_transition_delta" specifies the Range coder custom state
transition table. transition table.
If state_transition_delta is not present in the FFV1 bitstream, all If "state_transition_delta" is not present in the FFV1 bitstream, all
Range coder custom state transition table elements are assumed to be Range coder custom state transition table elements are assumed to be
0. 0.
4.1.5. colorspace_type 4.1.5. colorspace_type
"colorspace_type" specifies the color space encoded, the pixel "colorspace_type" specifies the color space encoded, the pixel
transformation used by the encoder, the extra plane content, as well transformation used by the encoder, the extra plane content, as well
as interleave method. as interleave method.
+-------+-------------+----------------+--------------+-------------+ +-------+-------------+----------------+--------------+-------------+
skipping to change at page 31, line 15 skipping to change at page 31, line 20
+-------+-----------------------------------+ +-------+-----------------------------------+
| value | bits for each sample | | value | bits for each sample |
+=======+===================================+ +=======+===================================+
| 0 | reserved* | | 0 | reserved* |
+-------+-----------------------------------+ +-------+-----------------------------------+
| Other | the actual bits for each "Sample" | | Other | the actual bits for each "Sample" |
+-------+-----------------------------------+ +-------+-----------------------------------+
Table 10 Table 10
* Encoders MUST NOT store bits_per_raw_sample = 0 Decoders SHOULD * Encoders MUST NOT store "bits_per_raw_sample" = 0 Decoders SHOULD
accept and interpret bits_per_raw_sample = 0 as 8. accept and interpret "bits_per_raw_sample" = 0 as 8.
4.1.8. log2_h_chroma_subsample 4.1.8. log2_h_chroma_subsample
"log2_h_chroma_subsample" indicates the subsample factor, stored in "log2_h_chroma_subsample" indicates the subsample factor, stored in
powers to which the number 2 must be raised, between luma and chroma powers to which the number 2 must be raised, between luma and chroma
width ("chroma_width = 2^-log2_h_chroma_subsample^ * luma_width"). width ("chroma_width = 2^-log2_h_chroma_subsample^ * luma_width").
4.1.9. log2_v_chroma_subsample 4.1.9. log2_v_chroma_subsample
"log2_v_chroma_subsample" indicates the subsample factor, stored in "log2_v_chroma_subsample" indicates the subsample factor, stored in
powers to which the number 2 must be raised, between luma and chroma powers to which the number 2 must be raised, between luma and chroma
height ("chroma_height=2^-log2_v_chroma_subsample^ * luma_height"). height ("chroma_height=2^-log2_v_chroma_subsample^ * luma_height").
4.1.10. extra_plane 4.1.10. "extra\_plane"
"extra_plane" indicates if an extra "Plane" is present. "extra_plane" indicates if an extra "Plane" is present.
+-------+------------------------------+ +-------+------------------------------+
| value | presence | | value | presence |
+=======+==============================+ +=======+==============================+
| 0 | extra "Plane" is not present | | 0 | extra "Plane" is not present |
+-------+------------------------------+ +-------+------------------------------+
| 1 | extra "Plane" is present | | 1 | extra "Plane" is present |
+-------+------------------------------+ +-------+------------------------------+
skipping to change at page 33, line 23 skipping to change at page 33, line 24
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 1 | 32-bit CRC per slice and the global header | | 1 | 32-bit CRC per slice and the global header |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| Other | reserved for future use | | Other | reserved for future use |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
Table 13 Table 13
4.1.17. intra 4.1.17. intra
"intra" indicates the relationship between the instances of "Frame". "intra" indicates the constraint on "keyframe" in each instance of
"Frame".
Inferred to be 0 if not present. Inferred to be 0 if not present.
+-------+-------------------------------------+ +-------+-------------------------------------------------------+
| value | relationship | | value | relationship |
+=======+=====================================+ +=======+=======================================================+
| 0 | Frames are independent or dependent | | 0 | "keyframe" can be 0 or 1 (non keyframes or keyframes) |
| | (keyframes and non keyframes) | +-------+-------------------------------------------------------+
+-------+-------------------------------------+ | 1 | "keyframe" MUST be 1 (keyframes only) |
| 1 | Frames are independent (keyframes | +-------+-------------------------------------------------------+
| | only) | | Other | reserved for future use |
+-------+-------------------------------------+ +-------+-------------------------------------------------------+
| Other | reserved for future use |
+-------+-------------------------------------+
Table 14 Table 14
4.2. Configuration Record 4.2. Configuration Record
In the case of a FFV1 bitstream with "version >= 3", a "Configuration In the case of a FFV1 bitstream with "version >= 3", a "Configuration
Record" is stored in the underlying "Container", at the track header Record" is stored in the underlying "Container", at the track header
level. It contains the "Parameters" used for all instances of level. It contains the "Parameters" used for all instances of
"Frame". The size of the "Configuration Record", "NumBytes", is "Frame". The size of the "Configuration Record", "NumBytes", is
supplied by the underlying "Container". supplied by the underlying "Container".
skipping to change at page 35, line 21 skipping to change at page 35, line 21
The "Configuration Record" extends the sample description box The "Configuration Record" extends the sample description box
("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box
that contains the ConfigurationRecord bitstream. See that contains the ConfigurationRecord bitstream. See
[ISO.14496-12.2015] for more information about boxes. [ISO.14496-12.2015] for more information about boxes.
"NumBytes" is defined as the size, in bytes, of the "glbl" box "NumBytes" is defined as the size, in bytes, of the "glbl" box
indicated in the box header minus the size of the box header. indicated in the box header minus the size of the box header.
4.2.3.3. NUT File Format 4.2.3.3. NUT File Format
The codec_specific_data element (in "stream_header" packet) contains The "codec_specific_data" element (in "stream_header" packet)
the ConfigurationRecord bitstream. See [NUT] for more information contains the ConfigurationRecord bitstream. See [NUT] for more
about elements. information about elements.
"NumBytes" is defined as the size, in bytes, of the "NumBytes" is defined as the size, in bytes, of the
codec_specific_data element as indicated in the "length" field of "codec_specific_data" element as indicated in the "length" field of
codec_specific_data "codec_specific_data".
4.2.3.4. Matroska File Format 4.2.3.4. Matroska File Format
FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1
versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be
used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate"
Element MUST contain the FFV1 "Configuration Record" structure and no Element MUST contain the FFV1 "Configuration Record" structure and no
other data. See [Matroska] for more information about elements. other data. See [Matroska] for more information about elements.
"NumBytes" is defined as the "Element Data Size" of the "NumBytes" is defined as the "Element Data Size" of the
"CodecPrivate" Element. "CodecPrivate" Element.
4.3. Frame 4.3. Frame
A "Frame" is an encoded representation of a complete static image. A "Frame" is an encoded representation of a complete static image.
The whole "Frame" is provided by the underlaying container. The whole "Frame" is provided by the underlaying container.
A "Frame" consists of the keyframe field, "Parameters" (if version A "Frame" consists of the "keyframe" field, "Parameters" (if
<=1), and a sequence of independent slices. The pseudo-code below "version" <=1), and a sequence of independent slices. The pseudo-
describes the contents of a "Frame". code below describes the contents of a "Frame".
pseudo-code | type pseudo-code | type
--------------------------------------------------------------|----- --------------------------------------------------------------|-----
Frame( NumBytes ) { | Frame( NumBytes ) { |
keyframe | br keyframe | br
if (keyframe && !ConfigurationRecordIsPresent { | if (keyframe && !ConfigurationRecordIsPresent { |
Parameters( ) | Parameters( ) |
} | } |
while (remaining_bits_in_bitstream( NumBytes )) { | while (remaining_bits_in_bitstream( NumBytes )) { |
Slice( ) | Slice( ) |
skipping to change at page 37, line 52 skipping to change at page 37, line 52
"reserved" specifies a bit without any significance in this revision "reserved" specifies a bit without any significance in this revision
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"
and 1 of the bitstream. Background: Due to some non-conforming 0 and 1 of the bitstream. Background: Due to some non-conforming
encoders, some bitstreams were found with 40 extra bits corresponding encoders, some bitstreams were found with 40 extra bits corresponding
to "error_status" and "slice_crc_parity". As a result, a decoder to "error_status" and "slice_crc_parity". As a result, a decoder
conforming to the revised specification could not distinguish between conforming to the revised specification could not distinguish 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
skipping to change at page 39, line 15 skipping to change at page 39, line 15
4.5.4. slice_height 4.5.4. slice_height
"slice_height" indicates the height on the slice raster formed by "slice_height" indicates the height on the slice raster formed by
num_v_slices. num_v_slices.
Inferred to be 1 if not present. Inferred to be 1 if not present.
4.5.5. quant_table_set_index_count 4.5.5. quant_table_set_index_count
"quant_table_set_index_count" is defined as "1 + ( ( chroma_planes || "quant_table_set_index_count" is defined as "1 + ( ( chroma_planes ||
version <= 3 ) ? 1 : 0 ) + ( extra_plane ? 1 : 0 )". version <= 3 ) ? 1 : 0 ) + ("extra_plane"? 1 : 0 )".
4.5.6. quant_table_set_index 4.5.6. quant_table_set_index
"quant_table_set_index" indicates the Quantization Table Set index to "quant_table_set_index" indicates the Quantization Table Set index to
select the Quantization Table Set and the initial states for the select the Quantization Table Set and the initial states for the
slice. slice.
Inferred to be 0 if not present. Inferred to be 0 if not present.
4.5.7. picture_structure 4.5.7. picture_structure
skipping to change at page 41, line 8 skipping to change at page 41, line 8
for (p = 0; p < primary_color_count; p++) { | for (p = 0; p < primary_color_count; p++) { |
Line( p, y ) | Line( p, y ) |
} | } |
} | } |
} | } |
} | } |
4.6.1. primary_color_count 4.6.1. primary_color_count
"primary_color_count" is defined as "1 + ( chroma_planes ? 2 : 0 ) + "primary_color_count" is defined as "1 + ( chroma_planes ? 2 : 0 ) +
( extra_plane ? 1 : 0 )". ("extra_plane"? 1 : 0 )".
4.6.2. plane_pixel_height 4.6.2. plane_pixel_height
"plane_pixel_height[ p ]" is the height in pixels of plane p of the "plane_pixel_height[ p ]" is the height in pixels of plane p of the
slice. slice.
"plane_pixel_height[ 0 ]" and "plane_pixel_height[ 1 + ( "plane_pixel_height[ 0 ]" and "plane_pixel_height[ 1 + (
chroma_planes ? 2 : 0 ) ]" value is "slice_pixel_height". chroma_planes ? 2 : 0 ) ]" value is "slice_pixel_height".
If "chroma_planes" is set to 1, "plane_pixel_height[ 1 ]" and If "chroma_planes" is set to 1, "plane_pixel_height[ 1 ]" and
skipping to change at page 45, line 41 skipping to change at page 45, line 41
4.9.2. context_count 4.9.2. context_count
"context_count[ i ]" indicates the count of contexts for Quantization "context_count[ i ]" indicates the count of contexts for Quantization
Table Set "i". "context_count[ i ]" MUST be less than or equal to Table Set "i". "context_count[ i ]" MUST be less than or equal to
32768. 32768.
5. Restrictions 5. Restrictions
To ensure that fast multithreaded decoding is possible, starting with To ensure that fast multithreaded decoding is possible, starting with
version 3 and if "frame_pixel_width * frame_pixel_height" is more "version" 3 and if "frame_pixel_width * frame_pixel_height" is more
than 101376, "slice_width * slice_height" MUST be less or equal to 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 "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 "Pixels" of a 352x288 frame also known as CIF ("Common Intermediate
Format") frame size format. Format") frame size format.
For each "Frame", each position in the slice raster MUST be filled by 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, no one and only one slice of the "Frame" (no missing slice position, no
slice overlapping). slice overlapping).
For each "Frame" with keyframe value of 0, each slice MUST have the For each "Frame" with "keyframe" value of 0, each slice MUST have the
same value of "slice_x, slice_y, slice_width, slice_height" as a same value of "slice_x", "slice_y", "slice_width", "slice_height" as
slice in the previous "Frame". a slice in the previous "Frame".
6. Security Considerations 6. Security Considerations
Like any other codec, (such as [RFC6716]), FFV1 should not be used Like any other codec, (such as [RFC6716]), FFV1 should not be used
with insecure ciphers or cipher-modes that are vulnerable to known with insecure ciphers or cipher-modes that are vulnerable to known
plaintext attacks. Some of the header bits as well as the padding plaintext attacks. Some of the header bits as well as the padding
are easily predictable. are easily predictable.
Implementations of the FFV1 codec need to take appropriate security Implementations of the FFV1 codec need to take appropriate security
considerations into account, as outlined in [RFC4732]. It is considerations into account, as outlined in [RFC4732]. It is
skipping to change at page 47, line 7 skipping to change at page 47, line 13
* Sending the decoder random packets that are not FFV1. * Sending the decoder random packets that are not FFV1.
In all of the conditions above, the decoder and encoder was run In all of the conditions above, the decoder and encoder was run
inside the [VALGRIND] memory debugger as well as clangs address inside the [VALGRIND] memory debugger as well as clangs address
sanitizer [Address-Sanitizer], which track reads and writes to sanitizer [Address-Sanitizer], which track reads and writes to
invalid memory regions as well as the use of uninitialized memory. invalid memory regions as well as the use of uninitialized memory.
There were no errors reported on any of the tested conditions. There were no errors reported on any of the tested conditions.
7. Media Type Definition 7. Media Type Definition
This registration is done using the template defined in [RFC6838] and This section completes the media type registration template defined
following [RFC4855]. in [RFC6838] and following [RFC4855].
Type name: video Type name: video
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 "version": The version of the FFV1 encoding as defined by
Section 4.1.1. 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
Section 4.1.2. by Section 4.1.2.
coder_type: The coder_type of the FFV1 encoding as defined by "coder_type": The "coder_type" of the FFV1 encoding as defined by
Section 4.1.3. 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
by Section 4.1.5. defined 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
defined by Section 4.1.7. as 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 Section 4.2.3. This container formats and contains binary data; see Section 4.2.3. This
media type is framed binary data Section 4.8 of [RFC6838]. media type is framed binary data; see Section 4.8 of [RFC6838].
Security considerations: Security considerations:
See Section 6 of this document. See Section 6 of this document.
Interoperability considerations: None. Interoperability considerations: None.
Published specification: Published specification:
[I-D.ietf-cellar-ffv1] and RFC XXXX. 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.]
Applications which use this media type: Applications which use this media type:
Any application that requires the transport of lossless video can use Any application that requires the transport of lossless video can use
this media type. Some examples are, but not limited to screen this media type. Some examples are, but not limited to screen
recording, scientific imaging, and digital video preservation. recording, scientific imaging, and digital video preservation.
skipping to change at page 48, line 37 skipping to change at page 48, line 43
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 Section 7. * Media type registration as described in Section 7.
9. Appendixes 9. Appendix A: Multi-theaded decoder implementation suggestions
9.1. Decoder implementation suggestions
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
boundary of each slice is computable without having to parse the boundary of each slice is computable without having to parse the
slice content. That allows multi-threading as well as independence slice content. That allows multi-threading as well as independence
of slice content (a bitstream error in a slice header or slice of slice content (a bitstream error in a slice header or slice
content has no impact on the decoding of the other slices). content has no impact on the decoding of the other slices).
After having checked keyframe field, a decoder SHOULD parse After having checked "keyframe" field, a decoder SHOULD parse
slice_size fields, from slice_size of the last slice at the end of "slice_size" fields, from "slice_size" of the last slice at the end
the "Frame" up to slice_size of the first slice at the beginning of of the "Frame" up to "slice_size" of the first slice at the beginning
the "Frame", before parsing slices, in order to have slices of the "Frame", before parsing slices, in order to have slices
boundaries. A decoder MAY fallback on sequential order e.g. in case boundaries. A decoder MAY fallback on sequential order e.g. in case
of a corrupted "Frame" (frame size unknown, slice_size of slices not of a corrupted "Frame" (frame size unknown, "slice_size" of slices
coherent...) or if there is no possibility of seeking into the not 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)
[RFC Editor: Please remove this Changelog section prior to
publication.]
11. Normative References 11. Normative References
[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>.
[ISO.9899.1990]
International Organization for Standardization,
"Programming languages - C", 1990.
[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>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>. <https://www.rfc-editor.org/info/rfc4732>.
[I-D.ietf-cellar-ffv1]
Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video
Coding Format Version 0, 1, and 3", Work in Progress,
Internet-Draft, draft-ietf-cellar-ffv1-11, 23 October
2019,
<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.2018]
International Organization for Standardization, International Organization for Standardization,
"Programming languages - C", 1990. "Programming languages - C", 2018.
[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>.
[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>.
[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>.
[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>.
[Matroska] IETF, "Matroska", 2019, <https://datatracker.ietf.org/doc/ [Matroska] IETF, "Matroska", 2019, <https://datatracker.ietf.org/doc/
draft-ietf-cellar-matroska/>. draft-ietf-cellar-matroska/>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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
[AVI] Microsoft, "AVI RIFF File Reference", undated,
<https://msdn.microsoft.com/en-us/library/windows/desktop/
dd318189%28v=vs.85%29.aspx>.
[range-coding]
Nigel, G. and N. Martin, "Range encoding: an algorithm for
removing redundancy from a digitised message.", July 1979.
[FFV1_V1] Niedermayer, M., "Commit to release FFV1 version 1", April [FFV1_V1] Niedermayer, M., "Commit to release FFV1 version 1", April
2009, <https://git.videolan.org/?p=ffmpeg.git;a=commit;h=6 2009, <https://git.videolan.org/?p=ffmpeg.git;a=commit;h=6
8f8d33becbd73b4d0aa277f472a6e8e72ea6849>. 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, [YCbCr] Wikipedia, "YCbCr", undated,
<https://msdn.microsoft.com/en-us/library/windows/desktop/ <https://en.wikipedia.org/w/index.php?title=YCbCr>.
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] [ISO.14496-10.2014]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- Coding of audio-visual objects "Information technology -- Coding of audio-visual objects
-- Part 10: Advanced Video Coding", September 2014. -- Part 10: Advanced Video Coding", September 2014.
[ISO.14496-12.2015]
International Organization for Standardization,
"Information technology -- Coding of audio-visual objects
-- Part 12: ISO base media file format", December 2015.
[NUT] Niedermayer, M., "NUT Open Container Format", December
2013, <https://ffmpeg.org/~michael/nut.txt>.
[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_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>.
[VALGRIND] Valgrind Developers, "Valgrind website", undated,
<https://valgrind.org/>.
[REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the
FFV1 codec in FFmpeg", undated, <https://ffmpeg.org>. FFV1 codec in FFmpeg", undated, <https://ffmpeg.org>.
[ISO.14496-12.2015] [VALGRIND] Valgrind Developers, "Valgrind website", undated,
International Organization for Standardization, <https://valgrind.org/>.
"Information technology -- Coding of audio-visual objects
-- Part 12: ISO base media file format", December 2015.
[range-coding]
Nigel, G. and N. Martin, "Range encoding: an algorithm for
removing redundancy from a digitised message.", July 1979.
[YCbCr] Wikipedia, "YCbCr", undated, [ISO.14495-1.1999]
<https://en.wikipedia.org/w/index.php?title=YCbCr>. International Organization for Standardization,
"Information technology -- Lossless and near-lossless
compression of continuous-tone still images: Baseline",
December 1999.
[NUT] Niedermayer, M., "NUT Open Container Format", December [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003,
2013, <https://ffmpeg.org/~michael/nut.txt>. <https://web.archive.org/web/20040402121343/
http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>.
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. 66 change blocks. 
140 lines changed or deleted 152 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/