--- 1/draft-ietf-cellar-ffv1-15.txt 2020-07-02 15:13:14.726808046 -0700 +++ 2/draft-ietf-cellar-ffv1-16.txt 2020-07-02 15:13:14.830810670 -0700 @@ -1,20 +1,20 @@ cellar M. Niedermayer Internet-Draft Intended status: Informational D. Rice -Expires: 25 December 2020 +Expires: 3 January 2021 J. Martinez - 23 June 2020 + 2 July 2020 FFV1 Video Coding Format Version 0, 1, and 3 - draft-ietf-cellar-ffv1-15 + draft-ietf-cellar-ffv1-16 Abstract This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 25 December 2020. + This Internet-Draft will expire on 3 January 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -49,103 +49,103 @@ provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6 - 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 6 + 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 7 2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7 2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7 2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8 2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 8 - 2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 8 + 2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 9 + 2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 9 3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 10 - 3.4. Context . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 11 + 3.4. Context . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Quantization Table Sets . . . . . . . . . . . . . . . . . 12 3.6. Quantization Table Set Indexes . . . . . . . . . . . . . 12 - 3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 12 + 3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 13 3.7.1. YCbCr . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.8. Coding of the Sample Difference . . . . . . . . . . . . . 15 - 3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 15 - 3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 20 - 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 4.1. Quantization Table Set . . . . . . . . . . . . . . . . . 26 - 4.1.1. quant_tables . . . . . . . . . . . . . . . . . . . . 27 - 4.1.2. context_count . . . . . . . . . . . . . . . . . . . . 28 - 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 28 - 4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 30 - 4.2.2. micro_version . . . . . . . . . . . . . . . . . . . . 30 - 4.2.3. coder_type . . . . . . . . . . . . . . . . . . . . . 31 - 4.2.4. state_transition_delta . . . . . . . . . . . . . . . 31 - 4.2.5. colorspace_type . . . . . . . . . . . . . . . . . . . 32 - 4.2.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 32 - 4.2.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 33 - 4.2.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 33 - 4.2.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 33 - 4.2.10. extra_plane . . . . . . . . . . . . . . . . . . . . . 33 - 4.2.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 34 - 4.2.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 34 - 4.2.13. quant_table_set_count . . . . . . . . . . . . . . . . 34 - 4.2.14. states_coded . . . . . . . . . . . . . . . . . . . . 34 - 4.2.15. initial_state_delta . . . . . . . . . . . . . . . . . 34 - 4.2.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 4.2.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 35 - 4.3. Configuration Record . . . . . . . . . . . . . . . . . . 36 - 4.3.1. reserved_for_future_use . . . . . . . . . . . . . . . 36 - 4.3.2. configuration_record_crc_parity . . . . . . . . . . . 36 - 4.3.3. Mapping FFV1 into Containers . . . . . . . . . . . . 36 - 4.4. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 4.5. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 4.6. Slice Header . . . . . . . . . . . . . . . . . . . . . . 40 - 4.6.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 41 - 4.6.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 41 - 4.6.3. slice_width . . . . . . . . . . . . . . . . . . . . . 41 - 4.6.4. slice_height . . . . . . . . . . . . . . . . . . . . 41 - 4.6.5. quant_table_set_index_count . . . . . . . . . . . . . 41 - 4.6.6. quant_table_set_index . . . . . . . . . . . . . . . . 42 - 4.6.7. picture_structure . . . . . . . . . . . . . . . . . . 42 - 4.6.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 42 - 4.6.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 43 - 4.7. Slice Content . . . . . . . . . . . . . . . . . . . . . . 43 - 4.7.1. primary_color_count . . . . . . . . . . . . . . . . . 43 - 4.7.2. plane_pixel_height . . . . . . . . . . . . . . . . . 43 - 4.7.3. slice_pixel_height . . . . . . . . . . . . . . . . . 44 - 4.7.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 44 - 4.8. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 4.8.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 44 - 4.8.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 45 - 4.8.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 45 - 4.8.4. sample_difference . . . . . . . . . . . . . . . . . . 45 - 4.9. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 45 - 4.9.1. slice_size . . . . . . . . . . . . . . . . . . . . . 45 - 4.9.2. error_status . . . . . . . . . . . . . . . . . . . . 46 - 4.9.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 46 - 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 46 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 - 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 48 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 - 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 10. Normative References . . . . . . . . . . . . . . . . . . . . 49 - 11. Informative References . . . . . . . . . . . . . . . . . . . 50 - Appendix A. Multi-theaded decoder implementation suggestions . . 52 + 3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 16 + 3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 21 + 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 4.1. Quantization Table Set . . . . . . . . . . . . . . . . . 27 + 4.1.1. quant_tables . . . . . . . . . . . . . . . . . . . . 28 + 4.1.2. context_count . . . . . . . . . . . . . . . . . . . . 29 + 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 29 + 4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.2.2. micro_version . . . . . . . . . . . . . . . . . . . . 31 + 4.2.3. coder_type . . . . . . . . . . . . . . . . . . . . . 32 + 4.2.4. state_transition_delta . . . . . . . . . . . . . . . 32 + 4.2.5. colorspace_type . . . . . . . . . . . . . . . . . . . 33 + 4.2.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 33 + 4.2.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 34 + 4.2.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 34 + 4.2.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 34 + 4.2.10. extra_plane . . . . . . . . . . . . . . . . . . . . . 34 + 4.2.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 35 + 4.2.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 35 + 4.2.13. quant_table_set_count . . . . . . . . . . . . . . . . 35 + 4.2.14. states_coded . . . . . . . . . . . . . . . . . . . . 35 + 4.2.15. initial_state_delta . . . . . . . . . . . . . . . . . 35 + 4.2.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 4.2.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 36 + 4.3. Configuration Record . . . . . . . . . . . . . . . . . . 37 + 4.3.1. reserved_for_future_use . . . . . . . . . . . . . . . 37 + 4.3.2. configuration_record_crc_parity . . . . . . . . . . . 37 + 4.3.3. Mapping FFV1 into Containers . . . . . . . . . . . . 37 + 4.4. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 4.5. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 4.6. Slice Header . . . . . . . . . . . . . . . . . . . . . . 41 + 4.6.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 42 + 4.6.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 42 + 4.6.3. slice_width . . . . . . . . . . . . . . . . . . . . . 42 + 4.6.4. slice_height . . . . . . . . . . . . . . . . . . . . 42 + 4.6.5. quant_table_set_index_count . . . . . . . . . . . . . 42 + 4.6.6. quant_table_set_index . . . . . . . . . . . . . . . . 43 + 4.6.7. picture_structure . . . . . . . . . . . . . . . . . . 43 + 4.6.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 43 + 4.6.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 44 + 4.7. Slice Content . . . . . . . . . . . . . . . . . . . . . . 44 + 4.7.1. primary_color_count . . . . . . . . . . . . . . . . . 44 + 4.7.2. plane_pixel_height . . . . . . . . . . . . . . . . . 44 + 4.7.3. slice_pixel_height . . . . . . . . . . . . . . . . . 45 + 4.7.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 45 + 4.8. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 4.8.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 45 + 4.8.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 46 + 4.8.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 46 + 4.8.4. sample_difference . . . . . . . . . . . . . . . . . . 46 + 4.9. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 46 + 4.9.1. slice_size . . . . . . . . . . . . . . . . . . . . . 47 + 4.9.2. error_status . . . . . . . . . . . . . . . . . . . . 47 + 4.9.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 47 + 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 47 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 + 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 49 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 10. Normative References . . . . . . . . . . . . . . . . . . . . 50 + 11. Informative References . . . . . . . . . . . . . . . . . . . 51 + Appendix A. Multi-theaded decoder implementation suggestions . . 53 Appendix B. Future handling of some streams created by non - conforming encoders . . . . . . . . . . . . . . . . . . . 52 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + conforming encoders . . . . . . . . . . . . . . . . . . . 53 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction This document describes FFV1, a lossless video encoding format. The design of FFV1 considers the storage of image characteristics, data fixity, and the optimized use of encoding time and storage requirements. FFV1 is designed to support a wide range of lossless video applications such as long-term audiovisual preservation, scientific imaging, screen recording, and other video encoding scenarios that seek to avoid the generational loss of lossy video @@ -192,22 +192,22 @@ 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Definitions "Container": Format that encapsulates "Frames" (see Section 4.4) and (when required) a "Configuration Record" into a bitstream. "Sample": The smallest addressable representation of a color component or a luma component in a "Frame". Examples of "Sample" are - Luma, Blue Chrominance, Red Chrominance, Transparency, Red, Green, - and Blue. + Luma (Y), Blue-difference Chroma (Cb), Red-difference Chroma (Cr), + Transparency, Red, Green, and Blue. "Plane": A discrete component of a static image comprised of "Samples" that represent a specific quantification of "Samples" of that image. "Pixel": The smallest addressable representation of a color in a "Frame". It is composed of one or more "Samples". "ESC": An ESCape symbol to indicate that the symbol to be stored is too large for normal storage and that an alternate storage method is @@ -217,36 +217,50 @@ change in magnitude of the symbol. "VLC": Variable Length Code, a code that maps source symbols to a variable number of bits. "RGB": A reference to the method of storing the value of a "Pixel" by using three numeric values that represent Red, Green, and Blue. "YCbCr": A reference to the method of storing the value of a "Pixel" by using three numeric values that represent the luma of the "Pixel" - (Y) and the chrominance of the "Pixel" (Cb and Cr). YCbCr word is - used for historical reasons and currently references any color space - relying on 1 luma "Sample" and 2 chrominance "Samples", e.g. YCbCr, - YCgCo or ICtCp. The exact meaning of the three numeric values is + (Y) and the chroma of the "Pixel" (Cb and Cr). YCbCr word is used + for historical reasons and currently references any color space + relying on 1 luma "Sample" and 2 chroma "Samples", e.g. YCbCr, YCgCo + or ICtCp. The exact meaning of the three numeric values is unspecified. 2.2. Conventions 2.2.1. 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 the structure of FFV1 and not intended to specify any particular implementation. The pseudo-code used is based upon the C programming language [ISO.9899.1990] and uses its "if/else", "while" and "for" keywords as well as functions defined within this document. + In some instances, pseudo-code is presented in a two-column format + such as shown in Figure 1. In this form the "type" column provides a + symbol as defined in Table 4 that defines the storage of the data + referenced in that same line of pseudo-code. + + pseudo-code | type + --------------------------------------------------------------|----- + ExamplePseudoCode( ) { | + value | ur + } | + + Figure 1: A depiction of type-labelled pseudo-code used within + this document. + 2.2.2. Arithmetic Operators Note: the operators and the order of precedence are the same as used in the C programming language [ISO.9899.2018], with the exception of ">>" (removal of implementation defined behavior) and "^" (power instead of XOR) operators which are re-defined within this section. "a + b" means a plus b. "a - b" means a minus b. @@ -412,57 +426,57 @@ assumed to be "0" * one column of "Samples" to the right of the coded slice is assumed as identical to the "Samples" of the rightmost column of the coded slice * an additional column of "Samples" to the left of the coded slice and two rows of "Samples" above the coded slice are assumed to be "0" - Figure 1 depicts a slice of 9 "Samples" "a,b,c,d,e,f,g,h,i" in a 3x3 + Figure 2 depicts a slice of 9 "Samples" "a,b,c,d,e,f,g,h,i" in a 3x3 arrangement along with its assumed border. +---+---+---+---+---+---+---+---+ | 0 | 0 | | 0 | 0 | 0 | | 0 | +---+---+---+---+---+---+---+---+ | 0 | 0 | | 0 | 0 | 0 | | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | +---+---+---+---+---+---+---+---+ | 0 | 0 | | a | b | c | | c | +---+---+---+---+---+---+---+---+ | 0 | a | | d | e | f | | f | +---+---+---+---+---+---+---+---+ | 0 | d | | g | h | i | | i | +---+---+---+---+---+---+---+---+ - Figure 1: A depiction of FFV1's assumed border for a set example + Figure 2: A depiction of FFV1's assumed border for a set example Samples. 3.2. Samples Relative to any "Sample" "X", six other relatively positioned "Samples" from the coded "Samples" and presumed border are identified - according to the labels used in Figure 2. The labels for these + according to the labels used in Figure 3. The labels for these relatively positioned "Samples" are used within the median predictor and context. +---+---+---+---+ | | | T | | +---+---+---+---+ | |tl | t |tr | +---+---+---+---+ | L | l | X | | +---+---+---+---+ - Figure 2: A depiction of how relatively positions Samples are + Figure 3: A depiction of how relatively positions Samples are references within this document. The labels for these relative "Samples" are made of the first letters of the words Top, Left and Right. 3.3. Median Predictor The prediction for any "Sample" value at position "X" may be computed based upon the relative neighboring values of "l", "t", and "tl" via this equation: @@ -472,22 +487,23 @@ [HuffYUV]. Exception for the median predictor: if "colorspace_type == 0 && bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 )", the following median predictor MUST be used: median(left16s, top16s, left16s + top16s - diag16s) where: - left16s = l >= 32768 ? ( l - 65536 ) : l top16s = t >= 32768 ? ( t - - 65536 ) : t diag16s = tl >= 32768 ? ( tl - 65536 ) : tl + left16s = l >= 32768 ? ( l - 65536 ) : l + top16s = t >= 32768 ? ( t - 65536 ) : t + diag16s = tl >= 32768 ? ( tl - 65536 ) : tl Background: a two's complement signed 16-bit signed integer was used for storing "Sample" values in all known implementations of FFV1 bitstream. So in some circumstances, the most significant bit was wrongly interpreted (used as a sign bit instead of the 16th bit of an unsigned integer). Note that when the issue was discovered, the only configuration of all known implementations being impacted is 16-bit YCbCr with no Pixel transformation with Range Coder coder, as other potentially impacted configurations (e.g. 15/16-bit JPEG2000-RCT with Range Coder coder, or 16-bit content with Golomb Rice coder) were @@ -501,41 +517,41 @@ Relative to any "Sample" "X", the Quantized Sample Differences "L-l", "l-tl", "tl-t", "T-t", and "t-tr" are used as context: context = Q_{0}[l - tl] + Q_{1}[tl - t] + Q_{2}[t - tr] + Q_{3}[L - l] + Q_{4}[T - t] - Figure 3 + Figure 4 If "context >= 0" then "context" is used and the difference between the "Sample" and its predicted value is encoded as is, else "-context" is used and the difference between the "Sample" and its predicted value is encoded with a flipped sign. 3.5. Quantization Table Sets The FFV1 bitstream contains one or more Quantization Table Sets. Each Quantization Table Set contains exactly 5 Quantization Tables with each Quantization Table corresponding to one of the five Quantized Sample Differences. For each Quantization Table, both the number of quantization steps and their distribution are stored in the FFV1 bitstream; each Quantization Table has exactly 256 entries, and the 8 least significant bits of the Quantized Sample Difference are used as index: Q_{j}[k] = quant_tables[i][j][k&255] - Figure 4 + Figure 5 In this formula, "i" is the Quantization Table Set index, "j" is the Quantized Table index, "k" the Quantized Sample Difference. 3.6. Quantization Table Set Indexes For each "Plane" of each slice, a Quantization Table Set is selected from an index: * For Y "Plane", "quant_table_set_index[ 0 ]" index is used @@ -601,35 +616,35 @@ [ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr and RGB use the following formulae. Cb = b - g Cr = r - g Y = g + (Cb + Cr) >> 2 g = Y - (Cb + Cr) >> 2 r = Cr + g b = Cb + g - Figure 5 + Figure 6 Exception for the JPEG2000-RCT conversion: if "bits_per_raw_sample" is between 9 and 15 inclusive and "extra_plane" is 0, the following formulae for reversible conversions between YCbCr and RGB MUST be used instead of the ones above: Cb = g - b Cr = r - b Y = b +(Cb + Cr) >> 2 b = Y -(Cb + Cr) >> 2 r = Cr + b g = Cb + b - Figure 6 + Figure 7 Background: At the time of this writing, in all known implementations 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 "Planes" during both encoding and decoding. In the meanwhile, 16-bit JPEG2000-RCT was implemented without this issue in one implementation and validated by one conformance checker. Methods to address this exception for the transform are under consideration for the next version of the FFV1 bitstream. @@ -667,84 +683,83 @@ 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 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 the equation below, the term "bits" represents "bits_per_raw_sample + 1" for JPEG2000-RCT or "bits_per_raw_sample" otherwise: coder_input = [(sample_difference + 2 ^ (bits - 1)) & (2 ^ bits - 1)] - 2 ^ (bits - 1) - Figure 7: Description of the coding of the Sample Difference in + Figure 8: Description of the coding of the Sample Difference in the bitstream. 3.8.1. Range Coding Mode 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 patent/royalty situation, as well as its slightly worse performance, CABAC was replaced by a Range coder based on an algorithm defined by G. Nigel and N. Martin in 1979 [range-coding]. 3.8.1.1. Range Binary Values 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)" 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 "j(n)" bytes. r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2 ^ 8 ) - Figure 8 + Figure 9 S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} AND l_i = L_i AND t_i = R_i - r_i <== b_i = 0 <==> L_i < R_i - r_i S_{i+1,C_{i}} = one_state_{S_{i,C_{i}}} AND l_i = L_i - R_i + r_i AND t_i = r_i <== b_i = 1 <==> L_i >= R_i - r_i - Figure 9 + Figure 10 S_{i+1,k} = S_{i,k} <== C_i != k - Figure 10 + Figure 11 R_{i+1} = 2 ^ 8 * t_{i} AND L_{i+1} = 2 ^ 8 * l_{i} + B_{j_{i}} AND j_{i+1} = j_{i} + 1 <== t_{i} < 2 ^ 8 R_{i+1} = t_{i} AND L_{i+1} = l_{i} AND j_{i+1} = j_{i} <== t_{i} >= 2 ^ 8 - - Figure 11 + Figure 12 R_{0} = 65280 - Figure 12 + Figure 13 L_{0} = 2 ^ 8 * B_{0} + B_{1} - Figure 13 + Figure 14 j_{0} = 2 - Figure 14 + Figure 15 3.8.1.1.1. Termination The range coder can be used in three modes. * In "Open mode" when decoding, every symbol the reader attempts to read is available. In this mode arbitrary data can have been appended without affecting the range coder output. This mode is not used in FFV1. @@ -782,21 +797,21 @@ To encode scalar integers, it would be possible to encode each bit separately and use the past bits as context. However that would mean 255 contexts per 8-bit symbol that is not only a waste of memory but also requires more past data to reach a reasonably good estimate of the probabilities. Alternatively assuming a Laplacian distribution and only dealing with its variance and mean (as in Huffman coding) would also be possible, however, for maximum flexibility and simplicity, the chosen method uses a single symbol to encode if a number is 0, and if not, encodes the number using its exponent, mantissa and sign. The exact contexts used are best described by - Figure 15. + Figure 16. int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) { if (get_rac(c, state + 0) { return 0; } int e = 0; while (get_rac(c, state + 1 + min(e, 9)) { //1..10 e++; } @@ -810,45 +825,45 @@ return a; } if (get_rac(c, state + 11 + min(e, 10))) { //11..21 return -a; } else { return a; } } - Figure 15: A pseudo-code description of the contexts of Range Non + Figure 16: A pseudo-code description of the contexts of Range Non Binary Values. "get_symbol" is used for the read out of "sample_difference" - indicated in Figure 7. + indicated in Figure 8. "get_rac" is the process described in Section 3.8.1.1. 3.8.1.3. Initial Values for the Context Model At keyframes all Range coder state variables are set to their initial state. 3.8.1.4. State Transition Table one_state_{i} = default_state_transition_{i} + state_transition_delta_{i} - Figure 16 + Figure 17 zero_state_{i} = 256 - one_state_{256-i} - Figure 17 -3.8.1.5. default_state_transition + Figure 18 +3.8.1.5. default_state_transition 0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, @@ -874,21 +889,21 @@ 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0, 3.8.1.6. Alternative State Transition Table The alternative state transition table has been built using iterative minimization of frame sizes and generally performs better than the default. To use it, the "coder_type" (see Section 4.2.3) MUST be set to 2 and the difference to the default MUST be stored in the "Parameters", see Section 4.2. The reference implementation of FFV1 - in FFmpeg uses Figure 18 by default at the time of this writing when + in FFmpeg uses Figure 19 by default at the time of this writing when Range coding is used. 0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49, 59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39, 40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52, 53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69, @@ -909,21 +924,21 @@ 175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196, 197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214, 209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225, 226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242, 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255, - Figure 18: Alternative state transition table for Range coding. + Figure 19: Alternative state transition table for Range coding. 3.8.2. Golomb Rice Mode The end of the bitstream of the "Frame" is filled with 0-bits until that the bitstream contains a multiple of 8 bits. 3.8.2.1. Signed Golomb Rice Codes This coding mode uses Golomb Rice codes. The VLC is split into two parts. The prefix stores the most significant bits and the suffix @@ -932,35 +947,35 @@ int get_ur_golomb(k) { for (prefix = 0; prefix < 12; prefix++) { if (get_bits(1)) { return get_bits(k) + (prefix << k); } } return get_bits(bits) + 11; } - Figure 19: A pseudo-code description of the read of an unsigned + Figure 20: A pseudo-code description of the read of an unsigned integer in Golomb Rice mode. int get_sr_golomb(k) { v = get_ur_golomb(k); if (v & 1) return - (v >> 1) - 1; else return (v >> 1); } - Figure 20: A pseudo-code description of the read of a signed + Figure 21: A pseudo-code description of the read of a signed integer in Golomb Rice mode. 3.8.2.1.1. Prefix - +----------------+-------+ + +================+=======+ | bits | value | +================+=======+ | 1 | 0 | +----------------+-------+ | 01 | 1 | +----------------+-------+ | ... | ... | +----------------+-------+ | 0000 0000 01 | 9 | +----------------+-------+ @@ -968,48 +983,48 @@ +----------------+-------+ | 0000 0000 0001 | 11 | +----------------+-------+ | 0000 0000 0000 | ESC | +----------------+-------+ Table 1 3.8.2.1.2. Suffix - +---------+----------------------------------------+ + +=========+========================================+ +=========+========================================+ | non ESC | the k least significant bits MSB first | +---------+----------------------------------------+ | ESC | the value - 11, in MSB first order | +---------+----------------------------------------+ Table 2 "ESC" MUST NOT be used if the value can be coded as "non ESC". 3.8.2.1.3. Examples - +-----+-------------------------+-------+ + +=====+=======================+=======+ | k | bits | value | - +=====+=========================+=======+ - | 0 | "1" | 0 | - +-----+-------------------------+-------+ - | 0 | "001" | 2 | - +-----+-------------------------+-------+ - | 2 | "1 00" | 0 | - +-----+-------------------------+-------+ - | 2 | "1 10" | 2 | - +-----+-------------------------+-------+ - | 2 | "01 01" | 5 | - +-----+-------------------------+-------+ - | any | "000000000000 10000000" | 139 | - +-----+-------------------------+-------+ + +=====+=======================+=======+ + | 0 | 1 | 0 | + +-----+-----------------------+-------+ + | 0 | 001 | 2 | + +-----+-----------------------+-------+ + | 2 | 1 00 | 0 | + +-----+-----------------------+-------+ + | 2 | 1 10 | 2 | + +-----+-----------------------+-------+ + | 2 | 01 01 | 5 | + +-----+-----------------------+-------+ + | any | 000000000000 10000000 | 139 | + +-----+-----------------------+-------+ Table 3 3.8.2.2. Run Mode 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. The run and the first different level are coded. 3.8.2.2.1. Run Length Coding @@ -1142,21 +1157,21 @@ An FFV1 bitstream is composed of a series of one or more "Frames" and (when required) a "Configuration Record". Within the following sub-sections, pseudo-code is used to explain the structure of each FFV1 bitstream component, as described in Section 2.2.1. Table 4 lists symbols used to annotate that pseudo- code in order to define the storage of the data referenced in that line of pseudo-code. - +--------+----------------------------------------------+ + +========+==============================================+ | Symbol | Definition | +========+==============================================+ | u(n) | unsigned big endian integer using n bits | +--------+----------------------------------------------+ | sg | Golomb Rice coded signed scalar symbol coded | | | with the method described in Section 3.8.2 | +--------+----------------------------------------------+ | br | Range coded Boolean (1-bit) symbol with the | | | method described in Section 3.8.1.1 | +--------+----------------------------------------------+ @@ -1248,21 +1263,21 @@ "context_count[ i ]" indicates the count of contexts for Quantization Table Set "i". "context_count[ i ]" MUST be less than or equal to 32768. 4.2. Parameters The "Parameters" section contains significant characteristics about the decoding configuration used for all instances of "Frame" (in FFV1 version 0 and 1) or the whole FFV1 bitstream (other versions), including the stream version, color configuration, and quantization - tables. Figure 21 describes the contents of the bitstream. + tables. Figure 22 describes the contents of the bitstream. "Parameters" has its own initial states, all set to 128. pseudo-code | type --------------------------------------------------------------|----- Parameters( ) { | version | ur if (version >= 3) { | micro_version | ur } | @@ -1297,38 +1312,38 @@ initial_state_delta[ i ][ j ][ k ] | sr } | } | } | } | ec | ur intra | ur } | } | - Figure 21: A pseudo-code description of the bitstream contents. + Figure 22: A pseudo-code description of the bitstream contents. CONTEXT_SIZE is 32. 4.2.1. version "version" specifies the version of the FFV1 bitstream. Each version is incompatible with other versions: decoders SHOULD reject FFV1 bitstreams due to an unknown version. Decoders SHOULD reject FFV1 bitstreams with version <= 1 && ConfigurationRecordIsPresent == 1. Decoders SHOULD reject FFV1 bitstreams with version >= 3 && ConfigurationRecordIsPresent == 0. - +-------+-------------------------+ + +=======+=========================+ | value | version | +=======+=========================+ | 0 | FFV1 version 0 | +-------+-------------------------+ | 1 | FFV1 version 1 | +-------+-------------------------+ | 2 | reserved* | +-------+-------------------------+ | 3 | FFV1 version 3 | +-------+-------------------------+ @@ -1345,41 +1360,41 @@ After a version is considered stable (a micro-version value is assigned to be the first stable variant of a specific version), each new micro-version after this first stable variant is compatible with the previous micro-version: decoders SHOULD NOT reject FFV1 bitstreams due to an unknown micro-version equal or above the micro- version considered as stable. Meaning of "micro_version" for "version" 3: - +-------+-------------------------+ + +=======+=========================+ | value | micro_version | +=======+=========================+ | 0...3 | reserved* | +-------+-------------------------+ | 4 | first stable variant | +-------+-------------------------+ | Other | reserved for future use | +-------+-------------------------+ Table 6: The definitions for "micro_version" values for FFV1 version 3. * development versions may be incompatible with the stable variants. 4.2.3. coder_type "coder_type" specifies the coder used. - +-------+-------------------------------------------------+ + +=======+=================================================+ | value | coder used | +=======+=================================================+ | 0 | Golomb Rice | +-------+-------------------------------------------------+ | 1 | Range Coder with default state transition table | +-------+-------------------------------------------------+ | 2 | Range Coder with custom state transition table | +-------+-------------------------------------------------+ | Other | reserved for future use | +-------+-------------------------------------------------+ @@ -1403,21 +1418,21 @@ If "state_transition_delta" is not present in the FFV1 bitstream, all Range coder custom state transition table elements are assumed to be 0. 4.2.5. colorspace_type "colorspace_type" specifies the color space encoded, the pixel transformation used by the encoder, the extra plane content, as well as interleave method. - +-------+-------------+----------------+--------------+-------------+ + +=======+=============+================+==============+=============+ | value | color space | pixel | extra plane | interleave | | | encoded | transformation | content | method | +=======+=============+================+==============+=============+ | 0 | YCbCr | None | Transparency | "Plane" | | | | | | then | | | | | | "Line" | +-------+-------------+----------------+--------------+-------------+ | 1 | RGB | JPEG2000-RCT | Transparency | "Line" | | | | | | then | | | | | | "Plane" | @@ -1430,36 +1445,36 @@ Table 8 FFV1 bitstreams with "colorspace_type" == 1 && ("chroma_planes" != 1 || "log2_h_chroma_subsample" != 0 || "log2_v_chroma_subsample" != 0) are not part of this specification. 4.2.6. chroma_planes "chroma_planes" indicates if chroma (color) "Planes" are present. - +-------+---------------------------------+ + +=======+=================================+ | value | presence | +=======+=================================+ | 0 | chroma "Planes" are not present | +-------+---------------------------------+ | 1 | chroma "Planes" are present | +-------+---------------------------------+ Table 9 4.2.7. bits_per_raw_sample "bits_per_raw_sample" indicates the number of bits for each "Sample". Inferred to be 8 if not present. - +-------+-----------------------------------+ + +=======+===================================+ | value | bits for each sample | +=======+===================================+ | 0 | reserved* | +-------+-----------------------------------+ | Other | the actual bits for each "Sample" | +-------+-----------------------------------+ Table 10 * Encoders MUST NOT store "bits_per_raw_sample" = 0. Decoders SHOULD @@ -1475,21 +1490,21 @@ "log2_v_chroma_subsample" indicates the subsample factor, stored in powers to which the number 2 must be raised, between luma and chroma height ("chroma_height = 2 ^ -log2_v_chroma_subsample * luma_height"). 4.2.10. extra_plane "extra_plane" indicates if an extra "Plane" is present. - +-------+------------------------------+ + +=======+==============================+ | value | presence | +=======+==============================+ | 0 | extra "Plane" is not present | +-------+------------------------------+ | 1 | extra "Plane" is present | +-------+------------------------------+ Table 11 4.2.11. num_h_slices @@ -1515,68 +1530,68 @@ MUST NOT be 0. 4.2.14. states_coded "states_coded" indicates if the respective Quantization Table Set has the initial states coded. Inferred to be 0 if not present. - +-------+--------------------------------+ + +=======+================================+ | value | initial states | +=======+================================+ | 0 | initial states are not present | | | and are assumed to be all 128 | +-------+--------------------------------+ | 1 | initial states are present | +-------+--------------------------------+ Table 12 4.2.15. initial_state_delta "initial_state_delta[ i ][ j ][ k ]" indicates the initial Range coder state, it is encoded using "k" as context index and pred = j ? initial_states[ i ][j - 1][ k ] : 128 - Figure 22 + Figure 23 initial_state[ i ][ j ][ k ] = ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255 - Figure 23 + Figure 24 4.2.16. ec "ec" indicates the error detection/correction type. - +-------+-------------------------------------------------+ + +=======+=================================================+ | value | error detection/correction type | +=======+=================================================+ | 0 | 32-bit CRC in "ConfigurationRecord" | +-------+-------------------------------------------------+ | 1 | 32-bit CRC in "Slice" and "ConfigurationRecord" | +-------+-------------------------------------------------+ | Other | reserved for future use | +-------+-------------------------------------------------+ Table 13 4.2.17. intra "intra" indicates the constraint on "keyframe" in each instance of "Frame". Inferred to be 0 if not present. - +-------+-------------------------------------------------------+ + +=======+=======================================================+ | value | relationship | +=======+=======================================================+ | 0 | "keyframe" can be 0 or 1 (non keyframes or keyframes) | +-------+-------------------------------------------------------+ | 1 | "keyframe" MUST be 1 (keyframes only) | +-------+-------------------------------------------------------+ | Other | reserved for future use | +-------+-------------------------------------------------------+ Table 14 @@ -1689,21 +1704,21 @@ if (keyframe && !ConfigurationRecordIsPresent { | Parameters( ) | } | while (remaining_bits_in_bitstream( NumBytes )) { | Slice( ) | } | } | Architecture overview of slices in a "Frame": - +-----------------------------------------------------------------+ + +=================================================================+ +=================================================================+ | first slice header | +-----------------------------------------------------------------+ | first slice content | +-----------------------------------------------------------------+ | first slice footer | +-----------------------------------------------------------------+ | --------------------------------------------------------------- | +-----------------------------------------------------------------+ | second slice header | @@ -1821,39 +1836,39 @@ "slice_height" indicates the height on the slice raster formed by num_v_slices. Inferred to be 1 if not present. 4.6.5. quant_table_set_index_count "quant_table_set_index_count" is defined as: - 1 + ( ( chroma_planes || version <= 3 ) ? 1 : 0 ) + ( extra_plane ? 1 - : 0 ) + 1 + ( ( chroma_planes || version <= 3 ) ? 1 : 0 ) + + ( extra_plane ? 1 : 0 ) 4.6.6. quant_table_set_index "quant_table_set_index" indicates the Quantization Table Set index to select the Quantization Table Set and the initial states for the "Slice Content". Inferred to be 0 if not present. 4.6.7. picture_structure "picture_structure" specifies the temporal and spatial relationship of each "Line" of the "Frame". Inferred to be 0 if not present. - +-------+-------------------------+ + +=======+=========================+ | value | picture structure used | +=======+=========================+ | 0 | unknown | +-------+-------------------------+ | 1 | top field first | +-------+-------------------------+ | 2 | bottom field first | +-------+-------------------------+ | 3 | progressive | +-------+-------------------------+ @@ -1917,29 +1932,33 @@ "primary_color_count" is defined as: 1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 ) 4.7.2. plane_pixel_height "plane_pixel_height[ p ]" is the height in "Pixels" of "Plane" p of the "Slice". It is defined as: - (chroma_planes == 1 && (p == 1 || p == 2)) ? ceil(slice_pixel_height - / (1 << log2_v_chroma_subsample)) : slice_pixel_height + chroma_planes == 1 && (p == 1 || p == 2) + ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) + : slice_pixel_height 4.7.3. slice_pixel_height "slice_pixel_height" is the height in pixels of the slice. It is defined as: - floor( ( slice_y + slice_height ) * slice_pixel_height / num_v_slices + floor( + ( slice_y + slice_height ) + * slice_pixel_height + / num_v_slices ) - slice_pixel_y. 4.7.4. slice_pixel_y "slice_pixel_y" is the slice vertical position in pixels. It is defined as: floor( slice_y * frame_pixel_height / num_v_slices ) 4.8. Line @@ -1960,30 +1979,34 @@ sample_difference[ p ][ y ][ x ] | sd } | } | } | 4.8.1. plane_pixel_width "plane_pixel_width[ p ]" is the width in "Pixels" of "Plane" p of the "Slice". It is defined as: - (chroma_planes == 1 && (p == 1 || p == 2)) ? ceil( slice_pixel_width - / (1 << log2_h_chroma_subsample) ) : slice_pixel_width. + chroma\_planes == 1 && (p == 1 || p == 2) + ? ceil( slice_pixel_width / (1 << log2_h_chroma_subsample) ) + : slice_pixel_width. 4.8.2. slice_pixel_width "slice_pixel_width" is the width in "Pixels" of the slice. It is defined as: - floor( ( slice_x + slice_width ) * slice_pixel_width / num_h_slices ) - - slice_pixel_x + floor( + ( slice_x + slice_width ) + * slice_pixel_width + / num_h_slices + ) - slice_pixel_x 4.8.3. slice_pixel_x "slice_pixel_x" is the slice horizontal position in "Pixels". It is defined as: floor( slice_x * frame_pixel_width / num_h_slices ) 4.8.4. sample_difference @@ -2015,21 +2038,21 @@ "slice_size" indicates the size of the slice in bytes. Note: this allows finding the start of slices before previous slices have been fully decoded, and allows parallel decoding as well as error resilience. 4.9.2. error_status "error_status" specifies the error status. - +-------+--------------------------------------+ + +=======+======================================+ | value | error status | +=======+======================================+ | 0 | no error | +-------+--------------------------------------+ | 1 | slice contains a correctable error | +-------+--------------------------------------+ | 2 | slice contains a uncorrectable error | +-------+--------------------------------------+ | Other | reserved for future use | +-------+--------------------------------------+ @@ -2185,122 +2209,122 @@ 9. Changelog See https://github.com/FFmpeg/FFV1/commits/master (https://github.com/FFmpeg/FFV1/commits/master) [RFC Editor: Please remove this Changelog section prior to publication.] 10. Normative References - [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet - Denial-of-Service Considerations", RFC 4732, - DOI 10.17487/RFC4732, December 2006, - . - [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . - [RFC4855] Casner, S., "Media Type Registration of RTP Payload - Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, - . + [ISO.9899.2018] + International Organization for Standardization, + "Programming languages - C", 2018. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . + [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the + Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, + September 2012, . [ISO.9899.1990] International Organization for Standardization, "Programming languages - C", 1990. - [ISO.9899.2018] + [ISO.15444-1.2016] International Organization for Standardization, - "Programming languages - C", 2018. + "Information technology -- JPEG 2000 image coding system: + Core coding system", October 2016. + + [Matroska] IETF, "Matroska", 2019, . + + [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet + Denial-of-Service Considerations", RFC 4732, + DOI 10.17487/RFC4732, December 2006, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [Matroska] IETF, "Matroska", 2019, . - - [ISO.15444-1.2016] - International Organization for Standardization, - "Information technology -- JPEG 2000 image coding system: - Core coding system", October 2016. + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, + . - [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the - Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, - September 2012, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . 11. Informative References - [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the - FFV1 codec in FFmpeg", undated, . - - [range-coding] - Nigel, G. and N. Martin, "Range encoding: an algorithm for - removing redundancy from a digitised message.", July 1979. - - [NUT] Niedermayer, M., "NUT Open Container Format", December - 2013, . - - [VALGRIND] Valgrind Developers, "Valgrind website", undated, - . + [FFV1_V3] Niedermayer, M., "Commit to mark FFV1 version 3 as non- + experimental", August 2013, . [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, . + + [range-coding] + Nigel, G. and N. Martin, "Range encoding: an algorithm for + removing redundancy from a digitised message.", July 1979. + [AVI] Microsoft, "AVI RIFF File Reference", undated, . - [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, - . - [FFV1_V0] Niedermayer, M., "Commit to mark FFV1 version 0 as non- experimental", April 2006, . - [ISO.14496-10.2014] - International Organization for Standardization, - "Information technology -- Coding of audio-visual objects - -- Part 10: Advanced Video Coding", September 2014. + [YCbCr] Wikipedia, "YCbCr", undated, + . + + [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, + . + + [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the + FFV1 codec in FFmpeg", undated, . [FFV1_V1] Niedermayer, M., "Commit to release FFV1 version 1", April 2009, . - [YCbCr] Wikipedia, "YCbCr", undated, - . + [VALGRIND] Valgrind Developers, "Valgrind website", undated, + . - [ISO.14495-1.1999] + [ISO.14496-10.2014] International Organization for Standardization, - "Information technology -- Lossless and near-lossless - compression of continuous-tone still images: Baseline", - December 1999. + "Information technology -- Coding of audio-visual objects + -- Part 10: Advanced Video Coding", September 2014. [Address-Sanitizer] The Clang Team, "ASAN AddressSanitizer website", undated, . - [FFV1_V3] Niedermayer, M., "Commit to mark FFV1 version 3 as non- - experimental", August 2013, . + [ISO.14495-1.1999] + International Organization for Standardization, + "Information technology -- Lossless and near-lossless + compression of continuous-tone still images: Baseline", + December 1999. Appendix A. Multi-theaded decoder implementation suggestions This appendix is informative. The FFV1 bitstream is parsable in two ways: in sequential order as described in this document or with the pre-analysis of the footer of each slice. Each slice footer contains a "slice_size" field so the boundary of each slice is computable without having to parse the slice content. That allows multi-threading as well as independence