idnits 2.17.1 draft-ietf-cellar-ffv1-v4-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 July 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '41' on line 1025 ** Downref: Normative reference to an Informational RFC: RFC 4732 == Outdated reference: A later version (-20) exists of draft-ietf-cellar-ffv1-14 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 cellar M. Niedermayer 3 Internet-Draft 4 Intended status: Standards Track D. Rice 5 Expires: 3 January 2021 6 J. Martinez 7 2 July 2020 9 FFV1 Video Coding Format Version 4 10 draft-ietf-cellar-ffv1-v4-13 12 Abstract 14 This document defines FFV1, a lossless intra-frame video encoding 15 format. FFV1 is designed to efficiently compress video data in a 16 variety of pixel formats. Compared to uncompressed video, FFV1 17 offers storage compression, frame fixity, and self-description, which 18 makes FFV1 useful as a preservation or intermediate video format. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 3 January 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4 55 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 5 58 2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6 59 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 6 60 2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7 61 2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7 62 2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8 63 2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 8 65 2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 8 66 3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 11 70 3.4. Context . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.5. Quantization Table Sets . . . . . . . . . . . . . . . . . 12 72 3.6. Quantization Table Set Indexes . . . . . . . . . . . . . 12 73 3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 12 74 3.7.1. YCbCr . . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.8. Coding of the Sample Difference . . . . . . . . . . . . . 15 77 3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 15 78 3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 20 79 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 4.1. Quantization Table Set . . . . . . . . . . . . . . . . . 26 81 4.1.1. quant_tables . . . . . . . . . . . . . . . . . . . . 27 82 4.1.2. context_count . . . . . . . . . . . . . . . . . . . . 28 83 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 28 84 4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 30 85 4.2.2. micro_version . . . . . . . . . . . . . . . . . . . . 30 86 4.2.3. coder_type . . . . . . . . . . . . . . . . . . . . . 31 87 4.2.4. state_transition_delta . . . . . . . . . . . . . . . 32 88 4.2.5. colorspace_type . . . . . . . . . . . . . . . . . . . 32 89 4.2.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 33 90 4.2.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 33 91 4.2.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 34 92 4.2.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 34 93 4.2.10. extra_plane . . . . . . . . . . . . . . . . . . . . . 34 94 4.2.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 34 95 4.2.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 35 96 4.2.13. quant_table_set_count . . . . . . . . . . . . . . . . 35 97 4.2.14. states_coded . . . . . . . . . . . . . . . . . . . . 35 98 4.2.15. initial_state_delta . . . . . . . . . . . . . . . . . 35 99 4.2.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 36 100 4.2.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 36 101 4.3. Configuration Record . . . . . . . . . . . . . . . . . . 36 102 4.3.1. reserved_for_future_use . . . . . . . . . . . . . . . 37 103 4.3.2. configuration_record_crc_parity . . . . . . . . . . . 37 104 4.3.3. Mapping FFV1 into Containers . . . . . . . . . . . . 37 105 4.4. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 38 106 4.5. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 40 107 4.6. Slice Header . . . . . . . . . . . . . . . . . . . . . . 41 108 4.6.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 41 109 4.6.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 41 110 4.6.3. slice_width . . . . . . . . . . . . . . . . . . . . . 41 111 4.6.4. slice_height . . . . . . . . . . . . . . . . . . . . 42 112 4.6.5. quant_table_set_index_count . . . . . . . . . . . . . 42 113 4.6.6. quant_table_set_index . . . . . . . . . . . . . . . . 42 114 4.6.7. picture_structure . . . . . . . . . . . . . . . . . . 42 115 4.6.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 43 116 4.6.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 43 117 4.6.10. reset_contexts . . . . . . . . . . . . . . . . . . . 43 118 4.6.11. slice_coding_mode . . . . . . . . . . . . . . . . . . 43 119 4.7. Slice Content . . . . . . . . . . . . . . . . . . . . . . 44 120 4.7.1. primary_color_count . . . . . . . . . . . . . . . . . 44 121 4.7.2. plane_pixel_height . . . . . . . . . . . . . . . . . 44 122 4.7.3. slice_pixel_height . . . . . . . . . . . . . . . . . 45 123 4.7.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 45 124 4.8. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 45 125 4.8.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 45 126 4.8.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 46 127 4.8.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 46 128 4.8.4. sample_difference . . . . . . . . . . . . . . . . . . 46 129 4.9. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 46 130 4.9.1. slice_size . . . . . . . . . . . . . . . . . . . . . 47 131 4.9.2. error_status . . . . . . . . . . . . . . . . . . . . 47 132 4.9.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 47 133 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 47 134 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 135 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 49 136 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 137 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 50 138 10. Normative References . . . . . . . . . . . . . . . . . . . . 50 139 11. Informative References . . . . . . . . . . . . . . . . . . . 51 140 Appendix A. Multi-theaded decoder implementation suggestions . . 52 141 Appendix B. Future handling of some streams created by non 142 conforming encoders . . . . . . . . . . . . . . . . . . . 53 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 145 1. Introduction 147 This document describes FFV1, a lossless video encoding format. The 148 design of FFV1 considers the storage of image characteristics, data 149 fixity, and the optimized use of encoding time and storage 150 requirements. FFV1 is designed to support a wide range of lossless 151 video applications such as long-term audiovisual preservation, 152 scientific imaging, screen recording, and other video encoding 153 scenarios that seek to avoid the generational loss of lossy video 154 encodings. 156 This document defines a version 4 of FFV1. Prior versions of FFV1 157 are defined within [I-D.ietf-cellar-ffv1]. 159 This document assumes familiarity with mathematical and coding 160 concepts such as Range coding [range-coding] and YCbCr color spaces 161 [YCbCr]. 163 This specification describes the valid bitstream and how to decode 164 such valid bitstream. Bitstreams not conforming to this 165 specification or how they are handled is outside this specification. 166 A decoder could reject every invalid bitstream or attempt to perform 167 error concealment or re-download or use a redundant copy of the 168 invalid part or any other action it deems appropriate. 170 2. Notation and Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 2.1. Definitions 180 "Container": Format that encapsulates "Frames" (see Section 4.4) and 181 (when required) a "Configuration Record" into a bitstream. 183 "Sample": The smallest addressable representation of a color 184 component or a luma component in a "Frame". Examples of "Sample" are 185 Luma (Y), Blue-difference Chroma (Cb), Red-difference Chroma (Cr), 186 Transparency, Red, Green, and Blue. 188 "Plane": A discrete component of a static image comprised of 189 "Samples" that represent a specific quantification of "Samples" of 190 that image. 192 "Pixel": The smallest addressable representation of a color in a 193 "Frame". It is composed of one or more "Samples". 195 "ESC": An ESCape symbol to indicate that the symbol to be stored is 196 too large for normal storage and that an alternate storage method is 197 used. 199 "MSB": Most Significant Bit, the bit that can cause the largest 200 change in magnitude of the symbol. 202 "VLC": Variable Length Code, a code that maps source symbols to a 203 variable number of bits. 205 "RGB": A reference to the method of storing the value of a "Pixel" by 206 using three numeric values that represent Red, Green, and Blue. 208 "YCbCr": A reference to the method of storing the value of a "Pixel" 209 by using three numeric values that represent the luma of the "Pixel" 210 (Y) and the chroma of the "Pixel" (Cb and Cr). YCbCr word is used 211 for historical reasons and currently references any color space 212 relying on 1 luma "Sample" and 2 chroma "Samples", e.g. YCbCr, YCgCo 213 or ICtCp. The exact meaning of the three numeric values is 214 unspecified. 216 "TBA": To Be Announced. Used in reference to the development of 217 future iterations of the FFV1 specification. 219 2.2. Conventions 221 2.2.1. Pseudo-code 223 The FFV1 bitstream is described in this document using pseudo-code. 224 Note that the pseudo-code is used for clarity in order to illustrate 225 the structure of FFV1 and not intended to specify any particular 226 implementation. The pseudo-code used is based upon the C programming 227 language [ISO.9899.1990] and uses its "if/else", "while" and "for" 228 keywords as well as functions defined within this document. 230 In some instances, pseudo-code is presented in a two-column format 231 such as shown in Figure 1. In this form the "type" column provides a 232 symbol as defined in Table 4 that defines the storage of the data 233 referenced in that same line of pseudo-code. 235 pseudo-code | type 236 --------------------------------------------------------------|----- 237 ExamplePseudoCode( ) { | 238 value | ur 239 } | 241 Figure 1: A depiction of type-labelled pseudo-code used within 242 this document. 244 2.2.2. Arithmetic Operators 246 Note: the operators and the order of precedence are the same as used 247 in the C programming language [ISO.9899.2018], with the exception of 248 ">>" (removal of implementation defined behavior) and "^" (power 249 instead of XOR) operators which are re-defined within this section. 251 "a + b" means a plus b. 253 "a - b" means a minus b. 255 "-a" means negation of a. 257 "a * b" means a multiplied by b. 259 "a / b" means a divided by b. 261 "a ^ b" means a raised to the b-th power. 263 "a & b" means bit-wise "and" of a and b. 265 "a | b" means bit-wise "or" of a and b. 267 "a >> b" means arithmetic right shift of two's complement integer 268 representation of a by b binary digits. This is equivalent to 269 dividing a by 2, b times, with rounding toward negative infinity. 271 "a << b" means arithmetic left shift of two's complement integer 272 representation of a by b binary digits. 274 2.2.3. Assignment Operators 276 "a = b" means a is assigned b. 278 "a++" is equivalent to a is assigned a + 1. 280 "a--" is equivalent to a is assigned a - 1. 282 "a += b" is equivalent to a is assigned a + b. 284 "a -= b" is equivalent to a is assigned a - b. 286 "a *= b" is equivalent to a is assigned a * b. 288 2.2.4. Comparison Operators 290 "a > b" means a is greater than b. 292 "a >= b" means a is greater than or equal to b. 294 "a < b" means a is less than b. 296 "a <= b" means a is less than or equal b. 298 "a == b" means a is equal to b. 300 "a != b" means a is not equal to b. 302 "a && b" means Boolean logical "and" of a and b. 304 "a || b" means Boolean logical "or" of a and b. 306 "!a" means Boolean logical "not" of a. 308 "a ? b : c" if a is true, then b, otherwise c. 310 2.2.5. Mathematical Functions 312 "floor(a)" means the largest integer less than or equal to a. 314 "ceil(a)" means the smallest integer greater than or equal to a. 316 "sign(a)" extracts the sign of a number, i.e. if a < 0 then -1, else 317 if a > 0 then 1, else 0. 319 "abs(a)" means the absolute value of a, i.e. "abs(a)" = "sign(a) * 320 a". 322 "log2(a)" means the base-two logarithm of a. 324 "min(a,b)" means the smallest of two values a and b. 326 "max(a,b)" means the largest of two values a and b. 328 "median(a,b,c)" means the numerical middle value in a data set of a, 329 b, and c, i.e. a+b+c-min(a,b,c)-max(a,b,c). 331 "A <== B" means B implies A. 333 "A <==> B" means A <== B , B <== A. 335 2.2.6. Order of Operation Precedence 337 When order of precedence is not indicated explicitly by use of 338 parentheses, operations are evaluated in the following order (from 339 top to bottom, operations of same precedence being evaluated from 340 left to right). This order of operations is based on the order of 341 operations used in Standard C. 343 a++, a-- 344 !a, -a 345 a ^ b 346 a * b, a / b, a % b 347 a + b, a - b 348 a << b, a >> b 349 a < b, a <= b, a > b, a >= b 350 a == b, a != b 351 a & b 352 a | b 353 a && b 354 a || b 355 a ? b : c 356 a = b, a += b, a -= b, a *= b 358 2.2.7. Range 360 "a...b" means any value starting from a to b, inclusive. 362 2.2.8. NumBytes 364 "NumBytes" is a non-negative integer that expresses the size in 8-bit 365 octets of a particular FFV1 "Configuration Record" or "Frame". FFV1 366 relies on its "Container" to store the "NumBytes" values; see 367 Section 4.3.3. 369 2.2.9. Bitstream Functions 370 2.2.9.1. remaining_bits_in_bitstream 372 "remaining_bits_in_bitstream( )" means the count of remaining bits 373 after the pointer in that "Configuration Record" or "Frame". It is 374 computed from the "NumBytes" value multiplied by 8 minus the count of 375 bits of that "Configuration Record" or "Frame" already read by the 376 bitstream parser. 378 2.2.9.2. remaining_symbols_in_syntax 380 "remaining_symbols_in_syntax( )" is true as long as the RangeCoder 381 has not consumed all the given input bytes. 383 2.2.9.3. byte_aligned 385 "byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes 386 )" is a multiple of 8, otherwise false. 388 2.2.9.4. get_bits 390 "get_bits( i )" is the action to read the next "i" bits in the 391 bitstream, from most significant bit to least significant bit, and to 392 return the corresponding value. The pointer is increased by "i". 394 3. Sample Coding 396 For each "Slice" (as described in Section 4.5) of a "Frame", the 397 "Planes", "Lines", and "Samples" are coded in an order determined by 398 the "Color Space" (see Section 3.7). Each "Sample" is predicted by 399 the median predictor as described in Section 3.3 from other "Samples" 400 within the same "Plane" and the difference is stored using the method 401 described in Section 3.8. 403 3.1. Border 405 A border is assumed for each coded "Slice" for the purpose of the 406 median predictor and context according to the following rules: 408 * one column of "Samples" to the left of the coded slice is assumed 409 as identical to the "Samples" of the leftmost column of the coded 410 slice shifted down by one row. The value of the topmost "Sample" 411 of the column of "Samples" to the left of the coded slice is 412 assumed to be "0" 414 * one column of "Samples" to the right of the coded slice is assumed 415 as identical to the "Samples" of the rightmost column of the coded 416 slice 418 * an additional column of "Samples" to the left of the coded slice 419 and two rows of "Samples" above the coded slice are assumed to be 420 "0" 422 Figure 2 depicts a slice of 9 "Samples" "a,b,c,d,e,f,g,h,i" in a 3x3 423 arrangement along with its assumed border. 425 +---+---+---+---+---+---+---+---+ 426 | 0 | 0 | | 0 | 0 | 0 | | 0 | 427 +---+---+---+---+---+---+---+---+ 428 | 0 | 0 | | 0 | 0 | 0 | | 0 | 429 +---+---+---+---+---+---+---+---+ 430 | | | | | | | | | 431 +---+---+---+---+---+---+---+---+ 432 | 0 | 0 | | a | b | c | | c | 433 +---+---+---+---+---+---+---+---+ 434 | 0 | a | | d | e | f | | f | 435 +---+---+---+---+---+---+---+---+ 436 | 0 | d | | g | h | i | | i | 437 +---+---+---+---+---+---+---+---+ 439 Figure 2: A depiction of FFV1's assumed border for a set example 440 Samples. 442 3.2. Samples 444 Relative to any "Sample" "X", six other relatively positioned 445 "Samples" from the coded "Samples" and presumed border are identified 446 according to the labels used in Figure 3. The labels for these 447 relatively positioned "Samples" are used within the median predictor 448 and context. 450 +---+---+---+---+ 451 | | | T | | 452 +---+---+---+---+ 453 | |tl | t |tr | 454 +---+---+---+---+ 455 | L | l | X | | 456 +---+---+---+---+ 458 Figure 3: A depiction of how relatively positions Samples are 459 references within this document. 461 The labels for these relative "Samples" are made of the first letters 462 of the words Top, Left and Right. 464 3.3. Median Predictor 466 The prediction for any "Sample" value at position "X" may be computed 467 based upon the relative neighboring values of "l", "t", and "tl" via 468 this equation: 470 median(l, t, l + t - tl) 472 Note, this prediction template is also used in [ISO.14495-1.1999] and 473 [HuffYUV]. 475 Exception for the median predictor: if "colorspace_type == 0 && 476 bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 )", 477 the following median predictor MUST be used: 479 median(left16s, top16s, left16s + top16s - diag16s) 481 where: 483 left16s = l >= 32768 ? ( l - 65536 ) : l 484 top16s = t >= 32768 ? ( t - 65536 ) : t 485 diag16s = tl >= 32768 ? ( tl - 65536 ) : tl 487 Background: a two's complement signed 16-bit signed integer was used 488 for storing "Sample" values in all known implementations of FFV1 489 bitstream. So in some circumstances, the most significant bit was 490 wrongly interpreted (used as a sign bit instead of the 16th bit of an 491 unsigned integer). Note that when the issue was discovered, the only 492 configuration of all known implementations being impacted is 16-bit 493 YCbCr with no Pixel transformation with Range Coder coder, as other 494 potentially impacted configurations (e.g. 15/16-bit JPEG2000-RCT with 495 Range Coder coder, or 16-bit content with Golomb Rice coder) were 496 implemented nowhere [ISO.15444-1.2016]. In the meanwhile, 16-bit 497 JPEG2000-RCT with Range Coder coder was implemented without this 498 issue in one implementation and validated by one conformance checker. 499 It is expected (to be confirmed) to remove this exception for the 500 median predictor in the next version of the FFV1 bitstream. 502 3.4. Context 504 Relative to any "Sample" "X", the Quantized Sample Differences "L-l", 505 "l-tl", "tl-t", "T-t", and "t-tr" are used as context: 507 context = Q_{0}[l - tl] + 508 Q_{1}[tl - t] + 509 Q_{2}[t - tr] + 510 Q_{3}[L - l] + 511 Q_{4}[T - t] 512 Figure 4 514 If "context >= 0" then "context" is used and the difference between 515 the "Sample" and its predicted value is encoded as is, else 516 "-context" is used and the difference between the "Sample" and its 517 predicted value is encoded with a flipped sign. 519 3.5. Quantization Table Sets 521 The FFV1 bitstream contains one or more Quantization Table Sets. 522 Each Quantization Table Set contains exactly 5 Quantization Tables 523 with each Quantization Table corresponding to one of the five 524 Quantized Sample Differences. For each Quantization Table, both the 525 number of quantization steps and their distribution are stored in the 526 FFV1 bitstream; each Quantization Table has exactly 256 entries, and 527 the 8 least significant bits of the Quantized Sample Difference are 528 used as index: 530 Q_{j}[k] = quant_tables[i][j][k&255] 532 Figure 5 534 In this formula, "i" is the Quantization Table Set index, "j" is the 535 Quantized Table index, "k" the Quantized Sample Difference. 537 3.6. Quantization Table Set Indexes 539 For each "Plane" of each slice, a Quantization Table Set is selected 540 from an index: 542 * For Y "Plane", "quant_table_set_index[ 0 ]" index is used 544 * For Cb and Cr "Planes", "quant_table_set_index[ 1 ]" index is used 546 * For extra "Plane", "quant_table_set_index[ (version <= 3 || 547 chroma_planes) ? 2 : 1 ]" index is used 549 Background: in first implementations of FFV1 bitstream, the index for 550 Cb and Cr "Planes" was stored even if it is not used (chroma_planes 551 set to 0), this index is kept for "version" <= 3 in order to keep 552 compatibility with FFV1 bitstreams in the wild. 554 3.7. Color spaces 556 FFV1 supports several color spaces. The count of allowed coded 557 planes and the meaning of the extra "Plane" are determined by the 558 selected color space. 560 The FFV1 bitstream interleaves data in an order determined by the 561 color space. In YCbCr for each "Plane", each "Line" is coded from 562 top to bottom and for each "Line", each "Sample" is coded from left 563 to right. In JPEG2000-RCT for each "Line" from top to bottom, each 564 "Plane" is coded and for each "Plane", each "Sample" is encoded from 565 left to right. 567 3.7.1. YCbCr 569 This color space allows 1 to 4 "Planes". 571 The Cb and Cr "Planes" are optional, but if used then MUST be used 572 together. Omitting the Cb and Cr "Planes" codes the frames in 573 grayscale without color data. 575 An optional transparency "Plane" can be used to code transparency 576 data. 578 An FFV1 "Frame" using YCbCr MUST use one of the following 579 arrangements: 581 * Y 583 * Y, Transparency 585 * Y, Cb, Cr 587 * Y, Cb, Cr, Transparency 589 The Y "Plane" MUST be coded first. If the Cb and Cr "Planes" are 590 used then they MUST be coded after the Y "Plane". If a transparency 591 "Plane" is used, then it MUST be coded last. 593 3.7.2. RGB 595 This color space allows 3 or 4 "Planes". 597 An optional transparency "Plane" can be used to code transparency 598 data. 600 JPEG2000-RCT is a Reversible Color Transform that codes RGB (red, 601 green, blue) "Planes" losslessly in a modified YCbCr color space 602 [ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr 603 and RGB use the following formulae. 605 Cb = b - g 606 Cr = r - g 607 Y = g + (Cb + Cr) >> 2 608 g = Y - (Cb + Cr) >> 2 609 r = Cr + g 610 b = Cb + g 612 Figure 6 614 Exception for the JPEG2000-RCT conversion: if "bits_per_raw_sample" 615 is between 9 and 15 inclusive and "extra_plane" is 0, the following 616 formulae for reversible conversions between YCbCr and RGB MUST be 617 used instead of the ones above: 619 Cb = g - b 620 Cr = r - b 621 Y = b +(Cb + Cr) >> 2 622 b = Y -(Cb + Cr) >> 2 623 r = Cr + b 624 g = Cb + b 626 Figure 7 628 Background: At the time of this writing, in all known implementations 629 of FFV1 bitstream, when "bits_per_raw_sample" was between 9 and 15 630 inclusive and "extra_plane" is 0, GBR "Planes" were used as BGR 631 "Planes" during both encoding and decoding. In the meanwhile, 16-bit 632 JPEG2000-RCT was implemented without this issue in one implementation 633 and validated by one conformance checker. Methods to address this 634 exception for the transform are under consideration for the next 635 version of the FFV1 bitstream. 637 Cb and Cr are positively offset by "1 << bits_per_raw_sample" after 638 the conversion from RGB to the modified YCbCr and are negatively 639 offseted by the same value before the conversion from the modified 640 YCbCr to RGB, in order to have only non-negative values after the 641 conversion. 643 When FFV1 uses the JPEG2000-RCT, the horizontal "Lines" are 644 interleaved to improve caching efficiency since it is most likely 645 that the JPEG2000-RCT will immediately be converted to RGB during 646 decoding. The interleaved coding order is also Y, then Cb, then Cr, 647 and then if used transparency. 649 As an example, a "Frame" that is two "Pixels" wide and two "Pixels" 650 high, could comprise the following structure: 652 +------------------------+------------------------+ 653 | Pixel(1,1) | Pixel(2,1) | 654 | Y(1,1) Cb(1,1) Cr(1,1) | Y(2,1) Cb(2,1) Cr(2,1) | 655 +------------------------+------------------------+ 656 | Pixel(1,2) | Pixel(2,2) | 657 | Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) | 658 +------------------------+------------------------+ 660 In JPEG2000-RCT, the coding order would be left to right and then top 661 to bottom, with values interleaved by "Lines" and stored in this 662 order: 664 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) 665 Cb(2,2) Cr(1,2) Cr(2,2) 667 3.8. Coding of the Sample Difference 669 Instead of coding the n+1 bits of the Sample Difference with Huffman 670 or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the 671 n (or n+1, in the case of JPEG2000-RCT) least significant bits are 672 used, since this is sufficient to recover the original "Sample". In 673 the equation below, the term "bits" represents "bits_per_raw_sample + 674 1" for JPEG2000-RCT or "bits_per_raw_sample" otherwise: 676 coder_input = [(sample_difference + 2 ^ (bits - 1)) & 677 (2 ^ bits - 1)] - 2 ^ (bits - 1) 679 Figure 8: Description of the coding of the Sample Difference in 680 the bitstream. 682 3.8.1. Range Coding Mode 684 Early experimental versions of FFV1 used the CABAC Arithmetic coder 685 from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain 686 patent/royalty situation, as well as its slightly worse performance, 687 CABAC was replaced by a Range coder based on an algorithm defined by 688 G. Nigel and N. Martin in 1979 [range-coding]. 690 3.8.1.1. Range Binary Values 692 To encode binary digits efficiently a Range coder is used. "C(i)" is 693 the i-th Context. "B(i)" is the i-th byte of the bytestream. "b(i)" 694 is the i-th Range coded binary value, "S(0,i)" is the i-th initial 695 state. The length of the bytestream encoding n binary symbols is 696 "j(n)" bytes. 698 r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2 ^ 8 ) 699 Figure 9 701 S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} AND 702 l_i = L_i AND 703 t_i = R_i - r_i <== 704 b_i = 0 <==> 705 L_i < R_i - r_i 707 S_{i+1,C_{i}} = one_state_{S_{i,C_{i}}} AND 708 l_i = L_i - R_i + r_i AND 709 t_i = r_i <== 710 b_i = 1 <==> 711 L_i >= R_i - r_i 713 Figure 10 715 S_{i+1,k} = S_{i,k} <== C_i != k 717 Figure 11 719 R_{i+1} = 2 ^ 8 * t_{i} AND 720 L_{i+1} = 2 ^ 8 * l_{i} + B_{j_{i}} AND 721 j_{i+1} = j_{i} + 1 <== 722 t_{i} < 2 ^ 8 724 R_{i+1} = t_{i} AND 725 L_{i+1} = l_{i} AND 726 j_{i+1} = j_{i} <== 727 t_{i} >= 2 ^ 8 729 Figure 12 731 R_{0} = 65280 733 Figure 13 735 L_{0} = 2 ^ 8 * B_{0} + B_{1} 737 Figure 14 739 j_{0} = 2 741 Figure 15 743 3.8.1.1.1. Termination 745 The range coder can be used in three modes. 747 * In "Open mode" when decoding, every symbol the reader attempts to 748 read is available. In this mode arbitrary data can have been 749 appended without affecting the range coder output. This mode is 750 not used in FFV1. 752 * In "Closed mode" the length in bytes of the bytestream is provided 753 to the range decoder. Bytes beyond the length are read as 0 by 754 the range decoder. This is generally one byte shorter than the 755 open mode. 757 * In "Sentinel mode" the exact length in bytes is not known and thus 758 the range decoder MAY read into the data that follows the range 759 coded bytestream by one byte. In "Sentinel mode", the end of the 760 range coded bytestream is a binary symbol with state 129, which 761 value SHALL be discarded. After reading this symbol, the range 762 decoder will have read one byte beyond the end of the range coded 763 bytestream. This way the byte position of the end can be 764 determined. Bytestreams written in "Sentinel mode" can be read in 765 "Closed mode" if the length can be determined, in this case the 766 last (sentinel) symbol will be read non-corrupted and be of value 767 0. 769 Above describes the range decoding. Encoding is defined as any 770 process which produces a decodable bytestream. 772 There are three places where range coder termination is needed in 773 FFV1. First is in the "Configuration Record", in this case the size 774 of the range coded bytestream is known and handled as "Closed mode". 775 Second is the switch from the "Slice Header" which is range coded to 776 Golomb coded slices as "Sentinel mode". Third is the end of range 777 coded Slices which need to terminate before the CRC at their end. 778 This can be handled as "Sentinel mode" or as "Closed mode" if the CRC 779 position has been determined. 781 3.8.1.2. Range Non Binary Values 783 To encode scalar integers, it would be possible to encode each bit 784 separately and use the past bits as context. However that would mean 785 255 contexts per 8-bit symbol that is not only a waste of memory but 786 also requires more past data to reach a reasonably good estimate of 787 the probabilities. Alternatively assuming a Laplacian distribution 788 and only dealing with its variance and mean (as in Huffman coding) 789 would also be possible, however, for maximum flexibility and 790 simplicity, the chosen method uses a single symbol to encode if a 791 number is 0, and if not, encodes the number using its exponent, 792 mantissa and sign. The exact contexts used are best described by 793 Figure 16. 795 int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) { 796 if (get_rac(c, state + 0) { 797 return 0; 798 } 800 int e = 0; 801 while (get_rac(c, state + 1 + min(e, 9)) { //1..10 802 e++; 803 } 805 int a = 1; 806 for (int i = e - 1; i >= 0; i--) { 807 a = a * 2 + get_rac(c, state + 22 + min(i, 9)); // 22..31 808 } 810 if (!is_signed) { 811 return a; 812 } 814 if (get_rac(c, state + 11 + min(e, 10))) { //11..21 815 return -a; 816 } else { 817 return a; 818 } 819 } 821 Figure 16: A pseudo-code description of the contexts of Range Non 822 Binary Values. 824 "get_symbol" is used for the read out of "sample_difference" 825 indicated in Figure 8. 827 "get_rac" is the process described in Section 3.8.1.1. 829 3.8.1.3. Initial Values for the Context Model 831 At keyframes all Range coder state variables are set to their initial 832 state. 834 3.8.1.4. State Transition Table 836 one_state_{i} = 837 default_state_transition_{i} + state_transition_delta_{i} 839 Figure 17 841 zero_state_{i} = 256 - one_state_{256-i} 842 Figure 18 844 3.8.1.5. default_state_transition 846 0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27, 848 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42, 850 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57, 852 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 854 74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 856 89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103, 858 104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118, 860 119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133, 862 134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149, 864 150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164, 866 165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179, 868 180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194, 870 195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209, 872 210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225, 874 226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240, 876 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0, 878 3.8.1.6. Alternative State Transition Table 880 The alternative state transition table has been built using iterative 881 minimization of frame sizes and generally performs better than the 882 default. To use it, the "coder_type" (see Section 4.2.3) MUST be set 883 to 2 and the difference to the default MUST be stored in the 884 "Parameters", see Section 4.2. The reference implementation of FFV1 885 in FFmpeg uses Figure 19 by default at the time of this writing when 886 Range coding is used. 888 0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49, 890 59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39, 892 40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52, 894 53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69, 896 87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97, 898 85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98, 900 105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125, 902 115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129, 904 165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148, 906 147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160, 908 172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178, 910 175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196, 912 197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214, 914 209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225, 916 226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242, 918 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255, 920 Figure 19: Alternative state transition table for Range coding. 922 3.8.2. Golomb Rice Mode 924 The end of the bitstream of the "Frame" is filled with 0-bits until 925 that the bitstream contains a multiple of 8 bits. 927 3.8.2.1. Signed Golomb Rice Codes 929 This coding mode uses Golomb Rice codes. The VLC is split into two 930 parts. The prefix stores the most significant bits and the suffix 931 stores the k least significant bits or stores the whole number in the 932 ESC case. 934 int get_ur_golomb(k) { 935 for (prefix = 0; prefix < 12; prefix++) { 936 if (get_bits(1)) { 937 return get_bits(k) + (prefix << k); 938 } 939 } 940 return get_bits(bits) + 11; 941 } 943 Figure 20: A pseudo-code description of the read of an unsigned 944 integer in Golomb Rice mode. 946 int get_sr_golomb(k) { 947 v = get_ur_golomb(k); 948 if (v & 1) return - (v >> 1) - 1; 949 else return (v >> 1); 950 } 952 Figure 21: A pseudo-code description of the read of a signed 953 integer in Golomb Rice mode. 955 3.8.2.1.1. Prefix 957 +================+=======+ 958 | bits | value | 959 +================+=======+ 960 | 1 | 0 | 961 +----------------+-------+ 962 | 01 | 1 | 963 +----------------+-------+ 964 | ... | ... | 965 +----------------+-------+ 966 | 0000 0000 01 | 9 | 967 +----------------+-------+ 968 | 0000 0000 001 | 10 | 969 +----------------+-------+ 970 | 0000 0000 0001 | 11 | 971 +----------------+-------+ 972 | 0000 0000 0000 | ESC | 973 +----------------+-------+ 975 Table 1 977 3.8.2.1.2. Suffix 979 +=========+========================================+ 980 +=========+========================================+ 981 | non ESC | the k least significant bits MSB first | 982 +---------+----------------------------------------+ 983 | ESC | the value - 11, in MSB first order | 984 +---------+----------------------------------------+ 986 Table 2 988 "ESC" MUST NOT be used if the value can be coded as "non ESC". 990 3.8.2.1.3. Examples 992 +=====+=======================+=======+ 993 | k | bits | value | 994 +=====+=======================+=======+ 995 | 0 | 1 | 0 | 996 +-----+-----------------------+-------+ 997 | 0 | 001 | 2 | 998 +-----+-----------------------+-------+ 999 | 2 | 1 00 | 0 | 1000 +-----+-----------------------+-------+ 1001 | 2 | 1 10 | 2 | 1002 +-----+-----------------------+-------+ 1003 | 2 | 01 01 | 5 | 1004 +-----+-----------------------+-------+ 1005 | any | 000000000000 10000000 | 139 | 1006 +-----+-----------------------+-------+ 1008 Table 3 1010 3.8.2.2. Run Mode 1012 Run mode is entered when the context is 0 and left as soon as a non-0 1013 difference is found. The level is identical to the predicted one. 1014 The run and the first different level are coded. 1016 3.8.2.2.1. Run Length Coding 1018 The run value is encoded in two parts. The prefix part stores the 1019 more significant part of the run as well as adjusting the "run_index" 1020 that determines the number of bits in the less significant part of 1021 the run. The second part of the value stores the less significant 1022 part of the run as it is. The "run_index" is reset for each "Plane" 1023 and slice to 0. 1025 log2_run[41] = { 1026 0, 0, 0, 0, 1, 1, 1, 1, 1027 2, 2, 2, 2, 3, 3, 3, 3, 1028 4, 4, 5, 5, 6, 6, 7, 7, 1029 8, 9,10,11,12,13,14,15, 1030 16,17,18,19,20,21,22,23, 1031 24, 1032 }; 1034 if (run_count == 0 && run_mode == 1) { 1035 if (get_bits(1)) { 1036 run_count = 1 << log2_run[run_index]; 1037 if (x + run_count <= w) { 1038 run_index++; 1039 } 1040 } else { 1041 if (log2_run[run_index]) { 1042 run_count = get_bits(log2_run[run_index]); 1043 } else { 1044 run_count = 0; 1045 } 1046 if (run_index) { 1047 run_index--; 1048 } 1049 run_mode = 2; 1050 } 1051 } 1053 The "log2_run" array is also used within [ISO.14495-1.1999]. 1055 3.8.2.3. Sign extension 1057 "sign_extend" is the function of increasing the number of bits of an 1058 input binary number in twos complement signed number representation 1059 while preserving the input number's sign (positive/negative) and 1060 value, in order to fit in the output bit width. It MAY be computed 1061 with: 1063 sign_extend(input_number, input_bits) { 1064 negative_bias = 1 << (input_bits - 1); 1065 bits_mask = negative_bias - 1; 1066 output_number = input_number & bits_mask; // Remove negative bit 1067 is_negative = input_number & negative_bias; // Test negative bit 1068 if (is_negative) 1069 output_number -= negative_bias; 1070 return output_number 1071 } 1073 3.8.2.4. Scalar Mode 1075 Each difference is coded with the per context mean prediction removed 1076 and a per context value for k. 1078 get_vlc_symbol(state) { 1079 i = state->count; 1080 k = 0; 1081 while (i < state->error_sum) { 1082 k++; 1083 i += i; 1084 } 1086 v = get_sr_golomb(k); 1088 if (2 * state->drift < -state->count) { 1089 v = -1 - v; 1090 } 1092 ret = sign_extend(v + state->bias, bits); 1094 state->error_sum += abs(v); 1095 state->drift += v; 1097 if (state->count == 128) { 1098 state->count >>= 1; 1099 state->drift >>= 1; 1100 state->error_sum >>= 1; 1101 } 1102 state->count++; 1103 if (state->drift <= -state->count) { 1104 state->bias = max(state->bias - 1, -128); 1106 state->drift = max(state->drift + state->count, 1107 -state->count + 1); 1108 } else if (state->drift > 0) { 1109 state->bias = min(state->bias + 1, 127); 1111 state->drift = min(state->drift - state->count, 0); 1112 } 1114 return ret; 1115 } 1117 3.8.2.4.1. Level Coding 1119 Level coding is identical to the normal difference coding with the 1120 exception that the 0 value is removed as it cannot occur: 1122 diff = get_vlc_symbol(context_state); 1123 if (diff >= 0) { 1124 diff++; 1125 } 1127 Note, this is different from JPEG-LS, which doesn't use prediction in 1128 run mode and uses a different encoding and context model for the last 1129 difference. On a small set of test "Samples" the use of prediction 1130 slightly improved the compression rate. 1132 3.8.2.5. Initial Values for the VLC context state 1134 At keyframes all coder state variables are set to their initial 1135 state. 1137 drift = 0; 1138 error_sum = 4; 1139 bias = 0; 1140 count = 1; 1142 4. Bitstream 1144 An FFV1 bitstream is composed of a series of one or more "Frames" and 1145 (when required) a "Configuration Record". 1147 Within the following sub-sections, pseudo-code is used to explain the 1148 structure of each FFV1 bitstream component, as described in 1149 Section 2.2.1. Table 4 lists symbols used to annotate that pseudo- 1150 code in order to define the storage of the data referenced in that 1151 line of pseudo-code. 1153 +========+==============================================+ 1154 | Symbol | Definition | 1155 +========+==============================================+ 1156 | u(n) | unsigned big endian integer using n bits | 1157 +--------+----------------------------------------------+ 1158 | sg | Golomb Rice coded signed scalar symbol coded | 1159 | | with the method described in Section 3.8.2 | 1160 +--------+----------------------------------------------+ 1161 | br | Range coded Boolean (1-bit) symbol with the | 1162 | | method described in Section 3.8.1.1 | 1163 +--------+----------------------------------------------+ 1164 | ur | Range coded unsigned scalar symbol coded | 1165 | | with the method described in Section 3.8.1.2 | 1166 +--------+----------------------------------------------+ 1167 | sr | Range coded signed scalar symbol coded with | 1168 | | the method described in Section 3.8.1.2 | 1169 +--------+----------------------------------------------+ 1170 | sd | Sample difference coded with the method | 1171 | | described in Section 3.8 | 1172 +--------+----------------------------------------------+ 1174 Table 4: Definition of pseudo-code symbols for this 1175 document. 1177 The following MUST be provided by external means during 1178 initialization of the decoder: 1180 "frame_pixel_width" is defined as "Frame" width in "Pixels". 1182 "frame_pixel_height" is defined as "Frame" height in "Pixels". 1184 Default values at the decoder initialization phase: 1186 "ConfigurationRecordIsPresent" is set to 0. 1188 4.1. Quantization Table Set 1190 The Quantization Table Sets are stored by storing the number of equal 1191 entries -1 of the first half of the table (represented as "len - 1" 1192 in the pseudo-code below) using the method described in 1193 Section 3.8.1.2. The second half doesn't need to be stored as it is 1194 identical to the first with flipped sign. "scale" and "len_count[ i 1195 ][ j ]" are temporary values used for the computing of 1196 "context_count[ i ]" and are not used outside Quantization Table Set 1197 pseudo-code. 1199 Example: 1201 Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0 1203 Stored values: 1, 3, 1 1205 "QuantizationTableSet" has its own initial states, all set to 128. 1207 pseudo-code | type 1208 --------------------------------------------------------------|----- 1209 QuantizationTableSet( i ) { | 1210 scale = 1 | 1211 for (j = 0; j < MAX_CONTEXT_INPUTS; j++) { | 1212 QuantizationTable( i, j, scale ) | 1213 scale *= 2 * len_count[ i ][ j ] - 1 | 1214 } | 1215 context_count[ i ] = ceil( scale / 2 ) | 1216 } | 1218 "MAX_CONTEXT_INPUTS" is 5. 1220 pseudo-code | type 1221 --------------------------------------------------------------|----- 1222 QuantizationTable(i, j, scale) { | 1223 v = 0 | 1224 for (k = 0; k < 128;) { | 1225 len - 1 | ur 1226 for (n = 0; n < len; n++) { | 1227 quant_tables[ i ][ j ][ k ] = scale * v | 1228 k++ | 1229 } | 1230 v++ | 1231 } | 1232 for (k = 1; k < 128; k++) { | 1233 quant_tables[ i ][ j ][ 256 - k ] = \ | 1234 -quant_tables[ i ][ j ][ k ] | 1235 } | 1236 quant_tables[ i ][ j ][ 128 ] = \ | 1237 -quant_tables[ i ][ j ][ 127 ] | 1238 len_count[ i ][ j ] = v | 1239 } | 1241 4.1.1. quant_tables 1243 "quant_tables[ i ][ j ][ k ]" indicates the quantification table 1244 value of the Quantized Sample Difference "k" of the Quantization 1245 Table "j" of the Set Quantization Table Set "i". 1247 4.1.2. context_count 1249 "context_count[ i ]" indicates the count of contexts for Quantization 1250 Table Set "i". "context_count[ i ]" MUST be less than or equal to 1251 32768. 1253 4.2. Parameters 1255 The "Parameters" section contains significant characteristics about 1256 the decoding configuration used for all instances of "Frame" (in FFV1 1257 version 0 and 1) or the whole FFV1 bitstream (other versions), 1258 including the stream version, color configuration, and quantization 1259 tables. Figure 22 describes the contents of the bitstream. 1261 "Parameters" has its own initial states, all set to 128. 1263 pseudo-code | type 1264 --------------------------------------------------------------|----- 1265 Parameters( ) { | 1266 version | ur 1267 if (version >= 3) { | 1268 micro_version | ur 1269 } | 1270 coder_type | ur 1271 if (coder_type > 1) { | 1272 for (i = 1; i < 256; i++) { | 1273 state_transition_delta[ i ] | sr 1274 } | 1275 } | 1276 colorspace_type | ur 1277 if (version >= 1) { | 1278 bits_per_raw_sample | ur 1279 } | 1280 chroma_planes | br 1281 log2_h_chroma_subsample | ur 1282 log2_v_chroma_subsample | ur 1283 extra_plane | br 1284 if (version >= 3) { | 1285 num_h_slices - 1 | ur 1286 num_v_slices - 1 | ur 1287 quant_table_set_count | ur 1288 } | 1289 for (i = 0; i < quant_table_set_count; i++) { | 1290 QuantizationTableSet( i ) | 1291 } | 1292 if (version >= 3) { | 1293 for (i = 0; i < quant_table_set_count; i++) { | 1294 states_coded | br 1295 if (states_coded) { | 1296 for (j = 0; j < context_count[ i ]; j++) { | 1297 for (k = 0; k < CONTEXT_SIZE; k++) { | 1298 initial_state_delta[ i ][ j ][ k ] | sr 1299 } | 1300 } | 1301 } | 1302 } | 1303 ec | ur 1304 intra | ur 1305 } | 1306 } | 1308 Figure 22: A pseudo-code description of the bitstream contents. 1310 CONTEXT_SIZE is 32. 1312 4.2.1. version 1314 "version" specifies the version of the FFV1 bitstream. 1316 Each version is incompatible with other versions: decoders SHOULD 1317 reject FFV1 bitstreams due to an unknown version. 1319 Decoders SHOULD reject FFV1 bitstreams with version <= 1 && 1320 ConfigurationRecordIsPresent == 1. 1322 Decoders SHOULD reject FFV1 bitstreams with version >= 3 && 1323 ConfigurationRecordIsPresent == 0. 1325 +=======+=========================+ 1326 | value | version | 1327 +=======+=========================+ 1328 | 0 | FFV1 version 0 | 1329 +-------+-------------------------+ 1330 | 1 | FFV1 version 1 | 1331 +-------+-------------------------+ 1332 | 2 | reserved* | 1333 +-------+-------------------------+ 1334 | 3 | FFV1 version 3 | 1335 +-------+-------------------------+ 1336 | 4 | FFV1 version 4 | 1337 +-------+-------------------------+ 1338 | Other | reserved for future use | 1339 +-------+-------------------------+ 1341 Table 5 1343 * Version 2 was experimental and this document does not describe it. 1345 4.2.2. micro_version 1347 "micro_version" specifies the micro-version of the FFV1 bitstream. 1349 After a version is considered stable (a micro-version value is 1350 assigned to be the first stable variant of a specific version), each 1351 new micro-version after this first stable variant is compatible with 1352 the previous micro-version: decoders SHOULD NOT reject FFV1 1353 bitstreams due to an unknown micro-version equal or above the micro- 1354 version considered as stable. 1356 Meaning of "micro_version" for "version" 3: 1358 +=======+=========================+ 1359 | value | micro_version | 1360 +=======+=========================+ 1361 | 0...3 | reserved* | 1362 +-------+-------------------------+ 1363 | 4 | first stable variant | 1364 +-------+-------------------------+ 1365 | Other | reserved for future use | 1366 +-------+-------------------------+ 1368 Table 6: The definitions for 1369 "micro_version" values for FFV1 1370 version 3. 1372 * development versions may be incompatible with the stable variants. 1374 Meaning of "micro_version" for "version" 4 (note: at the time of 1375 writing of this specification, version 4 is not considered stable so 1376 the first stable "micro_version" value is to be announced in the 1377 future): 1379 +=========+=========================+ 1380 | value | micro_version | 1381 +=========+=========================+ 1382 | 0...TBA | reserved* | 1383 +---------+-------------------------+ 1384 | TBA | first stable variant | 1385 +---------+-------------------------+ 1386 | Other | reserved for future use | 1387 +---------+-------------------------+ 1389 Table 7: The definitions for 1390 "micro_version" values for FFV1 1391 version 4. 1393 * development versions which may be incompatible with the stable 1394 variants. 1396 4.2.3. coder_type 1398 "coder_type" specifies the coder used. 1400 +=======+=================================================+ 1401 | value | coder used | 1402 +=======+=================================================+ 1403 | 0 | Golomb Rice | 1404 +-------+-------------------------------------------------+ 1405 | 1 | Range Coder with default state transition table | 1406 +-------+-------------------------------------------------+ 1407 | 2 | Range Coder with custom state transition table | 1408 +-------+-------------------------------------------------+ 1409 | Other | reserved for future use | 1410 +-------+-------------------------------------------------+ 1412 Table 8 1414 Restrictions: 1416 If "coder_type" is 0, then "bits_per_raw_sample" SHOULD NOT be > 8. 1418 Background: At the time of this writing, there is no known 1419 implementation of FFV1 bitstream supporting Golomb Rice algorithm 1420 with "bits_per_raw_sample" greater than 8, and Range Coder is 1421 prefered. 1423 4.2.4. state_transition_delta 1425 "state_transition_delta" specifies the Range coder custom state 1426 transition table. 1428 If "state_transition_delta" is not present in the FFV1 bitstream, all 1429 Range coder custom state transition table elements are assumed to be 1430 0. 1432 4.2.5. colorspace_type 1434 "colorspace_type" specifies the color space encoded, the pixel 1435 transformation used by the encoder, the extra plane content, as well 1436 as interleave method. 1438 +=======+=============+================+==============+=============+ 1439 | value | color space | pixel | extra plane | interleave | 1440 | | encoded | transformation | content | method | 1441 +=======+=============+================+==============+=============+ 1442 | 0 | YCbCr | None | Transparency | "Plane" | 1443 | | | | | then | 1444 | | | | | "Line" | 1445 +-------+-------------+----------------+--------------+-------------+ 1446 | 1 | RGB | JPEG2000-RCT | Transparency | "Line" | 1447 | | | | | then | 1448 | | | | | "Plane" | 1449 +-------+-------------+----------------+--------------+-------------+ 1450 | Other | reserved | reserved for | reserved for | reserved | 1451 | | for future | future use | future use | for future | 1452 | | use | | | use | 1453 +-------+-------------+----------------+--------------+-------------+ 1455 Table 9 1457 FFV1 bitstreams with "colorspace_type" == 1 && ("chroma_planes" != 1458 1 || "log2_h_chroma_subsample" != 0 || "log2_v_chroma_subsample" != 1459 0) are not part of this specification. 1461 4.2.6. chroma_planes 1463 "chroma_planes" indicates if chroma (color) "Planes" are present. 1465 +=======+=================================+ 1466 | value | presence | 1467 +=======+=================================+ 1468 | 0 | chroma "Planes" are not present | 1469 +-------+---------------------------------+ 1470 | 1 | chroma "Planes" are present | 1471 +-------+---------------------------------+ 1473 Table 10 1475 4.2.7. bits_per_raw_sample 1477 "bits_per_raw_sample" indicates the number of bits for each "Sample". 1478 Inferred to be 8 if not present. 1480 +=======+===================================+ 1481 | value | bits for each sample | 1482 +=======+===================================+ 1483 | 0 | reserved* | 1484 +-------+-----------------------------------+ 1485 | Other | the actual bits for each "Sample" | 1486 +-------+-----------------------------------+ 1488 Table 11 1490 * Encoders MUST NOT store "bits_per_raw_sample" = 0. Decoders SHOULD 1491 accept and interpret "bits_per_raw_sample" = 0 as 8. 1493 4.2.8. log2_h_chroma_subsample 1495 "log2_h_chroma_subsample" indicates the subsample factor, stored in 1496 powers to which the number 2 must be raised, between luma and chroma 1497 width ("chroma_width = 2 ^ -log2_h_chroma_subsample * luma_width"). 1499 4.2.9. log2_v_chroma_subsample 1501 "log2_v_chroma_subsample" indicates the subsample factor, stored in 1502 powers to which the number 2 must be raised, between luma and chroma 1503 height ("chroma_height = 2 ^ -log2_v_chroma_subsample * 1504 luma_height"). 1506 4.2.10. extra_plane 1508 "extra_plane" indicates if an extra "Plane" is present. 1510 +=======+==============================+ 1511 | value | presence | 1512 +=======+==============================+ 1513 | 0 | extra "Plane" is not present | 1514 +-------+------------------------------+ 1515 | 1 | extra "Plane" is present | 1516 +-------+------------------------------+ 1518 Table 12 1520 4.2.11. num_h_slices 1522 "num_h_slices" indicates the number of horizontal elements of the 1523 slice raster. 1525 Inferred to be 1 if not present. 1527 4.2.12. num_v_slices 1529 "num_v_slices" indicates the number of vertical elements of the slice 1530 raster. 1532 Inferred to be 1 if not present. 1534 4.2.13. quant_table_set_count 1536 "quant_table_set_count" indicates the number of Quantization 1537 Table Sets. "quant_table_set_count" MUST be less than or equal to 8. 1539 Inferred to be 1 if not present. 1541 MUST NOT be 0. 1543 4.2.14. states_coded 1545 "states_coded" indicates if the respective Quantization Table Set has 1546 the initial states coded. 1548 Inferred to be 0 if not present. 1550 +=======+================================+ 1551 | value | initial states | 1552 +=======+================================+ 1553 | 0 | initial states are not present | 1554 | | and are assumed to be all 128 | 1555 +-------+--------------------------------+ 1556 | 1 | initial states are present | 1557 +-------+--------------------------------+ 1559 Table 13 1561 4.2.15. initial_state_delta 1563 "initial_state_delta[ i ][ j ][ k ]" indicates the initial Range 1564 coder state, it is encoded using "k" as context index and 1566 pred = j ? initial_states[ i ][j - 1][ k ] : 128 1568 Figure 23 1570 initial_state[ i ][ j ][ k ] = 1571 ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255 1573 Figure 24 1575 4.2.16. ec 1577 "ec" indicates the error detection/correction type. 1579 +=======+=================================================+ 1580 | value | error detection/correction type | 1581 +=======+=================================================+ 1582 | 0 | 32-bit CRC in "ConfigurationRecord" | 1583 +-------+-------------------------------------------------+ 1584 | 1 | 32-bit CRC in "Slice" and "ConfigurationRecord" | 1585 +-------+-------------------------------------------------+ 1586 | Other | reserved for future use | 1587 +-------+-------------------------------------------------+ 1589 Table 14 1591 4.2.17. intra 1593 "intra" indicates the constraint on "keyframe" in each instance of 1594 "Frame". 1596 Inferred to be 0 if not present. 1598 +=======+=======================================================+ 1599 | value | relationship | 1600 +=======+=======================================================+ 1601 | 0 | "keyframe" can be 0 or 1 (non keyframes or keyframes) | 1602 +-------+-------------------------------------------------------+ 1603 | 1 | "keyframe" MUST be 1 (keyframes only) | 1604 +-------+-------------------------------------------------------+ 1605 | Other | reserved for future use | 1606 +-------+-------------------------------------------------------+ 1608 Table 15 1610 4.3. Configuration Record 1612 In the case of a FFV1 bitstream with "version >= 3", a "Configuration 1613 Record" is stored in the underlying "Container" as described in 1614 Section 4.3.3. It contains the "Parameters" used for all instances 1615 of "Frame". The size of the "Configuration Record", "NumBytes", is 1616 supplied by the underlying "Container". 1618 pseudo-code | type 1619 -----------------------------------------------------------|----- 1620 ConfigurationRecord( NumBytes ) { | 1621 ConfigurationRecordIsPresent = 1 | 1622 Parameters( ) | 1623 while (remaining_symbols_in_syntax(NumBytes - 4)) { | 1624 reserved_for_future_use | br/ur/sr 1625 } | 1626 configuration_record_crc_parity | u(32) 1627 } | 1629 4.3.1. reserved_for_future_use 1631 "reserved_for_future_use" has semantics that are reserved for future 1632 use. 1634 Encoders conforming to this version of this specification SHALL NOT 1635 write this value. 1637 Decoders conforming to this version of this specification SHALL 1638 ignore its value. 1640 4.3.2. configuration_record_crc_parity 1642 "configuration_record_crc_parity" 32 bits that are chosen so that the 1643 "Configuration Record" as a whole has a CRC remainder of 0. 1645 This is equivalent to storing the CRC remainder in the 32-bit parity. 1647 The CRC generator polynomial used is described in Section 4.9.3. 1649 4.3.3. Mapping FFV1 into Containers 1651 This "Configuration Record" can be placed in any file format 1652 supporting "Configuration Records", fitting as much as possible with 1653 how the file format uses to store "Configuration Records". The 1654 "Configuration Record" storage place and "NumBytes" are currently 1655 defined and supported by this version of this specification for the 1656 following formats: 1658 4.3.3.1. AVI File Format 1660 The "Configuration Record" extends the stream format chunk ("AVI ", 1661 "hdlr", "strl", "strf") with the ConfigurationRecord bitstream. 1663 See [AVI] for more information about chunks. 1665 "NumBytes" is defined as the size, in bytes, of the strf chunk 1666 indicated in the chunk header minus the size of the stream format 1667 structure. 1669 4.3.3.2. ISO Base Media File Format 1671 The "Configuration Record" extends the sample description box 1672 ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box 1673 that contains the ConfigurationRecord bitstream. See 1674 [ISO.14496-12.2015] for more information about boxes. 1676 "NumBytes" is defined as the size, in bytes, of the "glbl" box 1677 indicated in the box header minus the size of the box header. 1679 4.3.3.3. NUT File Format 1681 The "codec_specific_data" element (in "stream_header" packet) 1682 contains the ConfigurationRecord bitstream. See [NUT] for more 1683 information about elements. 1685 "NumBytes" is defined as the size, in bytes, of the 1686 "codec_specific_data" element as indicated in the "length" field of 1687 "codec_specific_data". 1689 4.3.3.4. Matroska File Format 1691 FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 1692 versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be 1693 used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" 1694 Element MUST contain the FFV1 "Configuration Record" structure and no 1695 other data. See [Matroska] for more information about elements. 1697 "NumBytes" is defined as the "Element Data Size" of the 1698 "CodecPrivate" Element. 1700 4.4. Frame 1702 A "Frame" is an encoded representation of a complete static image. 1703 The whole "Frame" is provided by the underlaying container. 1705 A "Frame" consists of the "keyframe" field, "Parameters" (if 1706 "version" <= 1), and a sequence of independent slices. The pseudo- 1707 code below describes the contents of a "Frame". 1709 "keyframe" field has its own initial state, set to 128. 1711 pseudo-code | type 1712 --------------------------------------------------------------|----- 1713 Frame( NumBytes ) { | 1714 keyframe | br 1715 if (keyframe && !ConfigurationRecordIsPresent { | 1716 Parameters( ) | 1717 } | 1718 while (remaining_bits_in_bitstream( NumBytes )) { | 1719 Slice( ) | 1720 } | 1721 } | 1723 Architecture overview of slices in a "Frame": 1725 +=================================================================+ 1726 +=================================================================+ 1727 | first slice header | 1728 +-----------------------------------------------------------------+ 1729 | first slice content | 1730 +-----------------------------------------------------------------+ 1731 | first slice footer | 1732 +-----------------------------------------------------------------+ 1733 | --------------------------------------------------------------- | 1734 +-----------------------------------------------------------------+ 1735 | second slice header | 1736 +-----------------------------------------------------------------+ 1737 | second slice content | 1738 +-----------------------------------------------------------------+ 1739 | second slice footer | 1740 +-----------------------------------------------------------------+ 1741 | --------------------------------------------------------------- | 1742 +-----------------------------------------------------------------+ 1743 | ... | 1744 +-----------------------------------------------------------------+ 1745 | --------------------------------------------------------------- | 1746 +-----------------------------------------------------------------+ 1747 | last slice header | 1748 +-----------------------------------------------------------------+ 1749 | last slice content | 1750 +-----------------------------------------------------------------+ 1751 | last slice footer | 1752 +-----------------------------------------------------------------+ 1754 Table 16 1756 4.5. Slice 1758 A "Slice" is an independent spatial sub-section of a "Frame" that is 1759 encoded separately from another region of the same "Frame". The use 1760 of more than one "Slice" per "Frame" can be useful for taking 1761 advantage of the opportunities of multithreaded encoding and 1762 decoding. 1764 A "Slice" consists of a "Slice Header" (when relevant), a "Slice 1765 Content", and a "Slice Footer" (when relevant). The pseudo-code 1766 below describes the contents of a "Slice". 1768 pseudo-code | type 1769 --------------------------------------------------------------|----- 1770 Slice( ) { | 1771 if (version >= 3) { | 1772 SliceHeader( ) | 1773 } | 1774 SliceContent( ) | 1775 if (coder_type == 0) { | 1776 while (!byte_aligned()) { | 1777 padding | u(1) 1778 } | 1779 } | 1780 if (version <= 1) { | 1781 while (remaining_bits_in_bitstream( NumBytes ) != 0) {| 1782 reserved | u(1) 1783 } | 1784 } | 1785 if (version >= 3) { | 1786 SliceFooter( ) | 1787 } | 1788 } | 1790 "padding" specifies a bit without any significance and used only for 1791 byte alignment. MUST be 0. 1793 "reserved" specifies a bit without any significance in this revision 1794 of the specification and may have a significance in a later revision 1795 of this specification. 1797 Encoders SHOULD NOT fill these bits. 1799 Decoders SHOULD ignore these bits. 1801 4.6. Slice Header 1803 A "Slice Header" provides information about the decoding 1804 configuration of the "Slice", such as its spatial position, size, and 1805 aspect ratio. The pseudo-code below describes the contents of the 1806 "Slice Header". 1808 "Slice Header" has its own initial states, all set to 128. 1810 pseudo-code | type 1811 --------------------------------------------------------------|----- 1812 SliceHeader( ) { | 1813 slice_x | ur 1814 slice_y | ur 1815 slice_width - 1 | ur 1816 slice_height - 1 | ur 1817 for (i = 0; i < quant_table_set_index_count; i++) { | 1818 quant_table_set_index[ i ] | ur 1819 } | 1820 picture_structure | ur 1821 sar_num | ur 1822 sar_den | ur 1823 if (version >= 4) { | 1824 reset_contexts | br 1825 slice_coding_mode | ur 1826 } | 1827 } | 1829 4.6.1. slice_x 1831 "slice_x" indicates the x position on the slice raster formed by 1832 num_h_slices. 1834 Inferred to be 0 if not present. 1836 4.6.2. slice_y 1838 "slice_y" indicates the y position on the slice raster formed by 1839 num_v_slices. 1841 Inferred to be 0 if not present. 1843 4.6.3. slice_width 1845 "slice_width" indicates the width on the slice raster formed by 1846 num_h_slices. 1848 Inferred to be 1 if not present. 1850 4.6.4. slice_height 1852 "slice_height" indicates the height on the slice raster formed by 1853 num_v_slices. 1855 Inferred to be 1 if not present. 1857 4.6.5. quant_table_set_index_count 1859 "quant_table_set_index_count" is defined as: 1861 1 + ( ( chroma_planes || version <= 3 ) ? 1 : 0 ) 1862 + ( extra_plane ? 1 : 0 ) 1864 4.6.6. quant_table_set_index 1866 "quant_table_set_index" indicates the Quantization Table Set index to 1867 select the Quantization Table Set and the initial states for the 1868 "Slice Content". 1870 Inferred to be 0 if not present. 1872 4.6.7. picture_structure 1874 "picture_structure" specifies the temporal and spatial relationship 1875 of each "Line" of the "Frame". 1877 Inferred to be 0 if not present. 1879 +=======+=========================+ 1880 | value | picture structure used | 1881 +=======+=========================+ 1882 | 0 | unknown | 1883 +-------+-------------------------+ 1884 | 1 | top field first | 1885 +-------+-------------------------+ 1886 | 2 | bottom field first | 1887 +-------+-------------------------+ 1888 | 3 | progressive | 1889 +-------+-------------------------+ 1890 | Other | reserved for future use | 1891 +-------+-------------------------+ 1893 Table 17 1895 4.6.8. sar_num 1897 "sar_num" specifies the "Sample" aspect ratio numerator. 1899 Inferred to be 0 if not present. 1901 A value of 0 means that aspect ratio is unknown. 1903 Encoders MUST write 0 if "Sample" aspect ratio is unknown. 1905 If "sar_den" is 0, decoders SHOULD ignore the encoded value and 1906 consider that "sar_num" is 0. 1908 4.6.9. sar_den 1910 "sar_den" specifies the "Sample" aspect ratio denominator. 1912 Inferred to be 0 if not present. 1914 A value of 0 means that aspect ratio is unknown. 1916 Encoders MUST write 0 if "Sample" aspect ratio is unknown. 1918 If "sar_num" is 0, decoders SHOULD ignore the encoded value and 1919 consider that "sar_den" is 0. 1921 4.6.10. reset_contexts 1923 "reset_contexts" indicates if slice contexts must be reset. 1925 Inferred to be 0 if not present. 1927 4.6.11. slice_coding_mode 1929 "slice_coding_mode" indicates the slice coding mode. 1931 Inferred to be 0 if not present. 1933 +=======+=============================+ 1934 | value | slice coding mode | 1935 +=======+=============================+ 1936 | 0 | Range Coding or Golomb Rice | 1937 +-------+-----------------------------+ 1938 | 1 | raw PCM | 1939 +-------+-----------------------------+ 1940 | Other | reserved for future use | 1941 +-------+-----------------------------+ 1943 Table 18 1945 4.7. Slice Content 1947 A "Slice Content" contains all "Line" elements part of the "Slice". 1949 Depending on the configuration, "Line" elements are ordered by 1950 "Plane" then by row (YCbCr) or by row then by "Plane" (RGB). 1952 pseudo-code | type 1953 --------------------------------------------------------------|----- 1954 SliceContent( ) { | 1955 if (colorspace_type == 0) { | 1956 for (p = 0; p < primary_color_count; p++) { | 1957 for (y = 0; y < plane_pixel_height[ p ]; y++) { | 1958 Line( p, y ) | 1959 } | 1960 } | 1961 } else if (colorspace_type == 1) { | 1962 for (y = 0; y < slice_pixel_height; y++) { | 1963 for (p = 0; p < primary_color_count; p++) { | 1964 Line( p, y ) | 1965 } | 1966 } | 1967 } | 1968 } | 1970 4.7.1. primary_color_count 1972 "primary_color_count" is defined as: 1974 1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 ) 1976 4.7.2. plane_pixel_height 1978 "plane_pixel_height[ p ]" is the height in "Pixels" of "Plane" p of 1979 the "Slice". It is defined as: 1981 chroma_planes == 1 && (p == 1 || p == 2) 1982 ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) 1983 : slice_pixel_height 1985 4.7.3. slice_pixel_height 1987 "slice_pixel_height" is the height in pixels of the slice. It is 1988 defined as: 1990 floor( 1991 ( slice_y + slice_height ) 1992 * slice_pixel_height 1993 / num_v_slices 1994 ) - slice_pixel_y. 1996 4.7.4. slice_pixel_y 1998 "slice_pixel_y" is the slice vertical position in pixels. It is 1999 defined as: 2001 floor( slice_y * frame_pixel_height / num_v_slices ) 2003 4.8. Line 2005 A "Line" is a list of the sample differences (relative to the 2006 predictor) of primary color components. The pseudo-code below 2007 describes the contents of the "Line". 2009 pseudo-code | type 2010 --------------------------------------------------------------|----- 2011 Line( p, y ) { | 2012 if (colorspace_type == 0) { | 2013 for (x = 0; x < plane_pixel_width[ p ]; x++) { | 2014 sample_difference[ p ][ y ][ x ] | sd 2015 } | 2016 } else if (colorspace_type == 1) { | 2017 for (x = 0; x < slice_pixel_width; x++) { | 2018 sample_difference[ p ][ y ][ x ] | sd 2019 } | 2020 } | 2021 } | 2023 4.8.1. plane_pixel_width 2025 "plane_pixel_width[ p ]" is the width in "Pixels" of "Plane" p of the 2026 "Slice". It is defined as: 2028 chroma\_planes == 1 && (p == 1 || p == 2) 2029 ? ceil( slice_pixel_width / (1 << log2_h_chroma_subsample) ) 2030 : slice_pixel_width. 2032 4.8.2. slice_pixel_width 2034 "slice_pixel_width" is the width in "Pixels" of the slice. It is 2035 defined as: 2037 floor( 2038 ( slice_x + slice_width ) 2039 * slice_pixel_width 2040 / num_h_slices 2041 ) - slice_pixel_x 2043 4.8.3. slice_pixel_x 2045 "slice_pixel_x" is the slice horizontal position in "Pixels". It is 2046 defined as: 2048 floor( slice_x * frame_pixel_width / num_h_slices ) 2050 4.8.4. sample_difference 2052 "sample_difference[ p ][ y ][ x ]" is the sample difference for 2053 "Sample" at "Plane" "p", y position "y", and x position "x". The 2054 "Sample" value is computed based on median predictor and context 2055 described in Section 3.2. 2057 4.9. Slice Footer 2059 A "Slice Footer" provides information about slice size and 2060 (optionally) parity. The pseudo-code below describes the contents of 2061 the "Slice Footer". 2063 Note: "Slice Footer" is always byte aligned. 2065 pseudo-code | type 2066 --------------------------------------------------------------|----- 2067 SliceFooter( ) { | 2068 slice_size | u(24) 2069 if (ec) { | 2070 error_status | u(8) 2071 slice_crc_parity | u(32) 2072 } | 2073 } | 2075 4.9.1. slice_size 2077 "slice_size" indicates the size of the slice in bytes. 2079 Note: this allows finding the start of slices before previous slices 2080 have been fully decoded, and allows parallel decoding as well as 2081 error resilience. 2083 4.9.2. error_status 2085 "error_status" specifies the error status. 2087 +=======+======================================+ 2088 | value | error status | 2089 +=======+======================================+ 2090 | 0 | no error | 2091 +-------+--------------------------------------+ 2092 | 1 | slice contains a correctable error | 2093 +-------+--------------------------------------+ 2094 | 2 | slice contains a uncorrectable error | 2095 +-------+--------------------------------------+ 2096 | Other | reserved for future use | 2097 +-------+--------------------------------------+ 2099 Table 19 2101 4.9.3. slice_crc_parity 2103 "slice_crc_parity" 32 bits that are chosen so that the slice as a 2104 whole has a crc remainder of 0. 2106 This is equivalent to storing the crc remainder in the 32-bit parity. 2108 The CRC generator polynomial used is the standard IEEE CRC polynomial 2109 (0x104C11DB7), with initial value 0, without pre-inversion and 2110 without post-inversion. 2112 5. Restrictions 2114 To ensure that fast multithreaded decoding is possible, starting with 2115 version 3 and if "frame_pixel_width * frame_pixel_height" is more 2116 than 101376, "slice_width * slice_height" MUST be less or equal to 2117 "num_h_slices * num_v_slices / 4". Note: 101376 is the frame size in 2118 "Pixels" of a 352x288 frame also known as CIF ("Common Intermediate 2119 Format") frame size format. 2121 For each "Frame", each position in the slice raster MUST be filled by 2122 one and only one slice of the "Frame" (no missing slice position, no 2123 slice overlapping). 2125 For each "Frame" with "keyframe" value of 0, each slice MUST have the 2126 same value of "slice_x", "slice_y", "slice_width", "slice_height" as 2127 a slice in the previous "Frame", except if "reset_contexts" is 1. 2129 6. Security Considerations 2131 Like any other codec, (such as [RFC6716]), FFV1 should not be used 2132 with insecure ciphers or cipher-modes that are vulnerable to known 2133 plaintext attacks. Some of the header bits as well as the padding 2134 are easily predictable. 2136 Implementations of the FFV1 codec need to take appropriate security 2137 considerations into account, as outlined in [RFC4732]. It is 2138 extremely important for the decoder to be robust against malicious 2139 payloads. Malicious payloads must not cause the decoder to overrun 2140 its allocated memory or to take an excessive amount of resources to 2141 decode. The same applies to the encoder, even though problems in 2142 encoders are typically rarer. Malicious video streams must not cause 2143 the encoder to misbehave because this would allow an attacker to 2144 attack transcoding gateways. A frequent security problem in image 2145 and video codecs is also to not check for integer overflows in 2146 "Pixel" count computations, that is to allocate width * height 2147 without considering that the multiplication result may have 2148 overflowed the arithmetic types range. The range coder could, if 2149 implemented naively, read one byte over the end. The implementation 2150 must ensure that no read outside allocated and initialized memory 2151 occurs. 2153 The reference implementation [REFIMPL] contains no known buffer 2154 overflow or cases where a specially crafted packet or video segment 2155 could cause a significant increase in CPU load. 2157 The reference implementation [REFIMPL] was validated in the following 2158 conditions: 2160 * Sending the decoder valid packets generated by the reference 2161 encoder and verifying that the decoder's output matches the 2162 encoder's input. 2164 * Sending the decoder packets generated by the reference encoder and 2165 then subjected to random corruption. 2167 * Sending the decoder random packets that are not FFV1. 2169 In all of the conditions above, the decoder and encoder was run 2170 inside the [VALGRIND] memory debugger as well as clangs address 2171 sanitizer [Address-Sanitizer], which track reads and writes to 2172 invalid memory regions as well as the use of uninitialized memory. 2173 There were no errors reported on any of the tested conditions. 2175 7. Media Type Definition 2177 This registration is done using the template defined in [RFC6838] and 2178 following [RFC4855]. 2180 Type name: video 2182 Subtype name: FFV1 2184 Required parameters: None. 2186 Optional parameters: These parameters are used to signal the 2187 capabilities of a receiver implementation. These parameters MUST NOT 2188 be used for any other purpose. 2190 * "version": The "version" of the FFV1 encoding as defined by 2191 Section 4.2.1. 2193 * "micro_version": The "micro_version" of the FFV1 encoding as 2194 defined by Section 4.2.2. 2196 * "coder_type": The "coder_type" of the FFV1 encoding as defined by 2197 Section 4.2.3. 2199 * "colorspace_type": The "colorspace_type" of the FFV1 encoding as 2200 defined by Section 4.2.5. 2202 * "bits_per_raw_sample": The "bits_per_raw_sample" of the FFV1 2203 encoding as defined by Section 4.2.7. 2205 * "max_slices": The value of "max_slices" is an integer indicating 2206 the maximum count of slices with a frames of the FFV1 encoding. 2208 Encoding considerations: This media type is defined for encapsulation 2209 in several audiovisual container formats and contains binary data; 2210 see Section 4.3.3. This media type is framed binary data; see 2211 Section 4.8 of [RFC6838]. 2213 Security considerations: See Section 6 of this document. 2215 Interoperability considerations: None. 2217 Published specification: RFC XXXX. 2219 [RFC Editor: Upon publication as an RFC, please replace "XXXX" with 2220 the number assigned to this document and remove this note.] 2222 Applications which use this media type: Any application that requires 2223 the transport of lossless video can use this media type. Some 2224 examples are, but not limited to screen recording, scientific 2225 imaging, and digital video preservation. 2227 Fragment identifier considerations: N/A. 2229 Additional information: None. 2231 Person & email address to contact for further information: Michael 2232 Niedermayer michael@niedermayer.cc (mailto:michael@niedermayer.cc) 2234 Intended usage: COMMON 2236 Restrictions on usage: None. 2238 Author: Dave Rice dave@dericed.com (mailto:dave@dericed.com) 2240 Change controller: IETF cellar working group delegated from the IESG. 2242 8. IANA Considerations 2244 The IANA is requested to register the following values: 2246 * Media type registration as described in Section 7. 2248 9. Changelog 2250 See https://github.com/FFmpeg/FFV1/commits/master 2251 (https://github.com/FFmpeg/FFV1/commits/master) 2253 [RFC Editor: Please remove this Changelog section prior to 2254 publication.] 2256 10. Normative References 2258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2259 Requirement Levels", BCP 14, RFC 2119, 2260 DOI 10.17487/RFC2119, March 1997, 2261 . 2263 [ISO.15444-1.2016] 2264 International Organization for Standardization, 2265 "Information technology -- JPEG 2000 image coding system: 2266 Core coding system", October 2016. 2268 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 2269 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 2270 September 2012, . 2272 [ISO.9899.2018] 2273 International Organization for Standardization, 2274 "Programming languages - C", 2018. 2276 [Matroska] IETF, "Matroska", 2019, . 2279 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 2280 Denial-of-Service Considerations", RFC 4732, 2281 DOI 10.17487/RFC4732, December 2006, 2282 . 2284 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2285 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2286 . 2288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2290 May 2017, . 2292 [ISO.9899.1990] 2293 International Organization for Standardization, 2294 "Programming languages - C", 1990. 2296 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2297 Specifications and Registration Procedures", BCP 13, 2298 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2299 . 2301 11. Informative References 2303 [YCbCr] Wikipedia, "YCbCr", undated, 2304 . 2306 [I-D.ietf-cellar-ffv1] 2307 Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video 2308 Coding Format Version 0, 1, and 3", Work in Progress, 2309 Internet-Draft, draft-ietf-cellar-ffv1-14, 26 May 2020, 2310 . 2312 [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, 2313 . 2316 [AVI] Microsoft, "AVI RIFF File Reference", undated, 2317 . 2320 [ISO.14496-12.2015] 2321 International Organization for Standardization, 2322 "Information technology -- Coding of audio-visual objects 2323 -- Part 12: ISO base media file format", December 2015. 2325 [ISO.14495-1.1999] 2326 International Organization for Standardization, 2327 "Information technology -- Lossless and near-lossless 2328 compression of continuous-tone still images: Baseline", 2329 December 1999. 2331 [VALGRIND] Valgrind Developers, "Valgrind website", undated, 2332 . 2334 [range-coding] 2335 Nigel, G. and N. Martin, "Range encoding: an algorithm for 2336 removing redundancy from a digitised message.", July 1979. 2338 [ISO.14496-10.2014] 2339 International Organization for Standardization, 2340 "Information technology -- Coding of audio-visual objects 2341 -- Part 10: Advanced Video Coding", September 2014. 2343 [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the 2344 FFV1 codec in FFmpeg", undated, . 2346 [Address-Sanitizer] 2347 The Clang Team, "ASAN AddressSanitizer website", undated, 2348 . 2350 [NUT] Niedermayer, M., "NUT Open Container Format", December 2351 2013, . 2353 Appendix A. Multi-theaded decoder implementation suggestions 2355 This appendix is informative. 2357 The FFV1 bitstream is parsable in two ways: in sequential order as 2358 described in this document or with the pre-analysis of the footer of 2359 each slice. Each slice footer contains a "slice_size" field so the 2360 boundary of each slice is computable without having to parse the 2361 slice content. That allows multi-threading as well as independence 2362 of slice content (a bitstream error in a slice header or slice 2363 content has no impact on the decoding of the other slices). 2365 After having checked "keyframe" field, a decoder SHOULD parse 2366 "slice_size" fields, from "slice_size" of the last slice at the end 2367 of the "Frame" up to "slice_size" of the first slice at the beginning 2368 of the "Frame", before parsing slices, in order to have slices 2369 boundaries. A decoder MAY fallback on sequential order e.g. in case 2370 of a corrupted "Frame" (frame size unknown, "slice_size" of slices 2371 not coherent...) or if there is no possibility of seeking into the 2372 stream. 2374 Appendix B. Future handling of some streams created by non conforming 2375 encoders 2377 This appendix is informative. 2379 Some bitstreams were found with 40 extra bits corresponding to 2380 "error_status" and "slice_crc_parity" in the "reserved" bits of 2381 "Slice()". Any revision of this specification SHOULD care about 2382 avoiding to add 40 bits of content after "SliceContent" if "version" 2383 == 0 or "version" == 1. Else a decoder conforming to the revised 2384 specification could not distinguish between a revised bitstream and 2385 such buggy bitstream in the wild. 2387 Authors' Addresses 2389 Michael Niedermayer 2391 Email: michael@niedermayer.cc 2393 Dave Rice 2395 Email: dave@dericed.com 2397 Jerome Martinez 2399 Email: jerome@mediaarea.net