idnits 2.17.1 draft-ietf-cellar-ffv1-v4-10.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 (28 April 2020) is 1457 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) ** Downref: Normative reference to an Informational RFC: RFC 4732 == Outdated reference: A later version (-20) exists of draft-ietf-cellar-ffv1-12 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: 30 October 2020 6 J. Martinez 7 28 April 2020 9 FFV1 Video Coding Format Version 4 10 draft-ietf-cellar-ffv1-v4-10 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 30 October 2020. 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 . . . . . . . . . . . . . . . . 5 59 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 6 60 2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 6 61 2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7 62 2.2.6. Order of Operation Precedence . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . 10 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. Parameters . . . . . . . . . . . . . . . . . . . . . . . 26 81 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 28 82 4.1.2. micro_version . . . . . . . . . . . . . . . . . . . . 28 83 4.1.3. coder_type . . . . . . . . . . . . . . . . . . . . . 29 84 4.1.4. state_transition_delta . . . . . . . . . . . . . . . 30 85 4.1.5. colorspace_type . . . . . . . . . . . . . . . . . . . 30 86 4.1.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 31 87 4.1.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 31 88 4.1.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 32 89 4.1.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 32 90 4.1.10. "extra\_plane" . . . . . . . . . . . . . . . . . . . 32 91 4.1.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 32 92 4.1.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 33 93 4.1.13. quant_table_set_count . . . . . . . . . . . . . . . . 33 94 4.1.14. states_coded . . . . . . . . . . . . . . . . . . . . 33 95 4.1.15. initial_state_delta . . . . . . . . . . . . . . . . . 33 96 4.1.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 34 97 4.1.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 34 98 4.2. Configuration Record . . . . . . . . . . . . . . . . . . 34 99 4.2.1. reserved_for_future_use . . . . . . . . . . . . . . . 35 100 4.2.2. configuration_record_crc_parity . . . . . . . . . . . 35 101 4.2.3. Mapping FFV1 into Containers . . . . . . . . . . . . 35 102 4.3. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 4.4. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 38 104 4.5. Slice Header . . . . . . . . . . . . . . . . . . . . . . 39 105 4.5.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 39 106 4.5.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 39 107 4.5.3. slice_width . . . . . . . . . . . . . . . . . . . . . 40 108 4.5.4. slice_height . . . . . . . . . . . . . . . . . . . . 40 109 4.5.5. quant_table_set_index_count . . . . . . . . . . . . . 40 110 4.5.6. quant_table_set_index . . . . . . . . . . . . . . . . 40 111 4.5.7. picture_structure . . . . . . . . . . . . . . . . . . 40 112 4.5.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 41 113 4.5.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 41 114 4.5.10. reset_contexts . . . . . . . . . . . . . . . . . . . 41 115 4.5.11. slice_coding_mode . . . . . . . . . . . . . . . . . . 42 116 4.6. Slice Content . . . . . . . . . . . . . . . . . . . . . . 42 117 4.6.1. primary_color_count . . . . . . . . . . . . . . . . . 42 118 4.6.2. plane_pixel_height . . . . . . . . . . . . . . . . . 43 119 4.6.3. slice_pixel_height . . . . . . . . . . . . . . . . . 43 120 4.6.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 43 121 4.7. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 43 122 4.7.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 44 123 4.7.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 44 124 4.7.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 44 125 4.7.4. sample_difference . . . . . . . . . . . . . . . . . . 44 126 4.8. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 44 127 4.8.1. slice_size . . . . . . . . . . . . . . . . . . . . . 45 128 4.8.2. error_status . . . . . . . . . . . . . . . . . . . . 45 129 4.8.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 45 130 4.9. Quantization Table Set . . . . . . . . . . . . . . . . . 46 131 4.9.1. quant_tables . . . . . . . . . . . . . . . . . . . . 47 132 4.9.2. context_count . . . . . . . . . . . . . . . . . . . . 47 133 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 47 134 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 135 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 49 136 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 137 9. Appendix A: Multi-theaded decoder implementation 138 suggestions . . . . . . . . . . . . . . . . . . . . . . . 50 139 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 51 140 11. Normative References . . . . . . . . . . . . . . . . . . . . 51 141 12. Informative References . . . . . . . . . . . . . . . . . . . 52 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 144 1. Introduction 146 This document describes FFV1, a lossless video encoding format. The 147 design of FFV1 considers the storage of image characteristics, data 148 fixity, and the optimized use of encoding time and storage 149 requirements. FFV1 is designed to support a wide range of lossless 150 video applications such as long-term audiovisual preservation, 151 scientific imaging, screen recording, and other video encoding 152 scenarios that seek to avoid the generational loss of lossy video 153 encodings. 155 This document defines a version 4 of FFV1. Prior versions of FFV1 156 are defined within [I-D.ietf-cellar-ffv1]. 158 This document assumes familiarity with mathematical and coding 159 concepts such as Range coding [range-coding] and YCbCr color spaces 160 [YCbCr]. 162 2. Notation and Conventions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 2.1. Definitions 172 "Container": Format that encapsulates "Frames" (see Section 4.3) and 173 (when required) a "Configuration Record" into a bitstream. 175 "Sample": The smallest addressable representation of a color 176 component or a luma component in a "Frame". Examples of "Sample" are 177 Luma, Blue Chrominance, Red Chrominance, Transparency, Red, Green, 178 and Blue. 180 "Plane": A discrete component of a static image comprised of 181 "Samples" that represent a specific quantification of "Samples" of 182 that image. 184 "Pixel": The smallest addressable representation of a color in a 185 "Frame". It is composed of 1 or more "Samples". 187 "ESC": An ESCape symbol to indicate that the symbol to be stored is 188 too large for normal storage and that an alternate storage method is 189 used. 191 "MSB": Most Significant Bit, the bit that can cause the largest 192 change in magnitude of the symbol. 194 "RCT": Reversible Color Transform, a near linear, exactly reversible 195 integer transform that converts between RGB and YCbCr representations 196 of a "Pixel". 198 "VLC": Variable Length Code, a code that maps source symbols to a 199 variable number of bits. 201 "RGB": A reference to the method of storing the value of a "Pixel" by 202 using three numeric values that represent Red, Green, and Blue. 204 "YCbCr": A reference to the method of storing the value of a "Pixel" 205 by using three numeric values that represent the luma of the "Pixel" 206 (Y) and the chrominance of the "Pixel" (Cb and Cr). YCbCr word is 207 used for historical reasons and currently references any color space 208 relying on 1 luma "Sample" and 2 chrominance "Samples", e.g. YCbCr, 209 YCgCo or ICtCp. The exact meaning of the three numeric values is 210 unspecified. 212 "TBA": To Be Announced. Used in reference to the development of 213 future iterations of the FFV1 specification. 215 2.2. Conventions 217 2.2.1. Pseudo-code 219 The FFV1 bitstream is described in this document using pseudo-code. 220 Note that the pseudo-code is used for clarity in order to illustrate 221 the structure of FFV1 and not intended to specify any particular 222 implementation. The pseudo-code used is based upon the C programming 223 language [ISO.9899.1990] and uses its "if/else", "while" and "for" 224 keywords as well as functions defined within this document. 226 2.2.2. Arithmetic Operators 228 Note: the operators and the order of precedence are the same as used 229 in the C programming language [ISO.9899.2018]. With the exception of 230 ">>" (removal of implementation defined behavior) and "^" (power 231 instead of XOR) operators which are re-defined within this section. 233 "a + b" means a plus b. 235 "a - b" means a minus b. 237 "-a" means negation of a. 239 "a * b" means a multiplied by b. 241 "a / b" means a divided by b. 243 "a ^ b" means a raised to the b-th power. 245 "a & b" means bit-wise "and" of a and b. 247 "a | b" means bit-wise "or" of a and b. 249 "a >> b" means arithmetic right shift of two's complement integer 250 representation of a by b binary digits. This is equivalent to, b 251 times dividing a by 2 with rounding toward negative infinity. 253 "a << b" means arithmetic left shift of two's complement integer 254 representation of a by b binary digits. 256 2.2.3. Assignment Operators 258 "a = b" means a is assigned b. 260 "a++" is equivalent to a is assigned a + 1. 262 "a--" is equivalent to a is assigned a - 1. 264 "a += b" is equivalent to a is assigned a + b. 266 "a -= b" is equivalent to a is assigned a - b. 268 "a *= b" is equivalent to a is assigned a * b. 270 2.2.4. Comparison Operators 272 "a > b" means a is greater than b. 274 "a >= b" means a is greater than or equal to b. 276 "a < b" means a is less than b. 278 "a <= b" means a is less than or equal b. 280 "a == b" means a is equal to b. 282 "a != b" means a is not equal to b. 284 "a && b" means Boolean logical "and" of a and b. 286 "a || b" means Boolean logical "or" of a and b. 288 "!a" means Boolean logical "not" of a. 290 "a ? b : c" if a is true, then b, otherwise c. 292 2.2.5. Mathematical Functions 294 floor(a) the largest integer less than or equal to a 296 ceil(a) the smallest integer greater than or equal to a 298 sign(a) extracts the sign of a number, i.e. if a < 0 then -1, else if 299 a > 0 then 1, else 0 301 abs(a) the absolute value of a, i.e. abs(a) = sign(a)*a 303 log2(a) the base-two logarithm of a 305 min(a,b) the smallest of two values a and b 307 max(a,b) the largest of two values a and b 309 median(a,b,c) the numerical middle value in a data set of a, b, and 310 c, i.e. a+b+c-min(a,b,c)-max(a,b,c) 312 A <== B B implies A 314 A <==> B A <== B , B <== A 316 2.2.6. Order of Operation Precedence 318 When order of precedence is not indicated explicitly by use of 319 parentheses, operations are evaluated in the following order (from 320 top to bottom, operations of same precedence being evaluated from 321 left to right). This order of operations is based on the order of 322 operations used in Standard C. 324 a++, a-- 325 !a, -a 326 a ^ b 327 a * b, a / b, a % b 328 a + b, a - b 329 a << b, a >> b 330 a < b, a <= b, a > b, a >= b 331 a == b, a != b 332 a & b 333 a | b 334 a && b 335 a || b 336 a ? b : c 337 a = b, a += b, a -= b, a *= b 339 2.2.7. Range 341 "a...b" means any value starting from a to b, inclusive. 343 2.2.8. NumBytes 345 "NumBytes" is a non-negative integer that expresses the size in 8-bit 346 octets of a particular FFV1 "Configuration Record" or "Frame". FFV1 347 relies on its "Container" to store the "NumBytes" values; see 348 Section 4.2.3. 350 2.2.9. Bitstream Functions 352 2.2.9.1. remaining_bits_in_bitstream 354 "remaining_bits_in_bitstream( )" means the count of remaining bits 355 after the pointer in that "Configuration Record" or "Frame". It is 356 computed from the "NumBytes" value multiplied by 8 minus the count of 357 bits of that "Configuration Record" or "Frame" already read by the 358 bitstream parser. 360 2.2.9.2. remaining_symbols_in_syntax 362 "remaining_symbols_in_syntax( )" is true as long as the RangeCoder 363 has not consumed all the given input bytes. 365 2.2.9.3. byte_aligned 367 "byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes 368 )" is a multiple of 8, otherwise false. 370 2.2.9.4. get_bits 372 "get_bits( i )" is the action to read the next "i" bits in the 373 bitstream, from most significant bit to least significant bit, and to 374 return the corresponding value. The pointer is increased by "i". 376 3. Sample Coding 378 For each "Slice" (as described in Section 4.4) of a "Frame", the 379 "Planes", "Lines", and "Samples" are coded in an order determined by 380 the "Color Space" (see Section 3.7). Each "Sample" is predicted by 381 the median predictor as described in Section 3.3 from other "Samples" 382 within the same "Plane" and the difference is stored using the method 383 described in Section 3.8. 385 3.1. Border 387 A border is assumed for each coded "Slice" for the purpose of the 388 median predictor and context according to the following rules: 390 * one column of "Samples" to the left of the coded slice is assumed 391 as identical to the "Samples" of the leftmost column of the coded 392 slice shifted down by one row. The value of the topmost "Sample" 393 of the column of "Samples" to the left of the coded slice is 394 assumed to be "0" 396 * one column of "Samples" to the right of the coded slice is assumed 397 as identical to the "Samples" of the rightmost column of the coded 398 slice 400 * an additional column of "Samples" to the left of the coded slice 401 and two rows of "Samples" above the coded slice are assumed to be 402 "0" 404 Figure 1 depicts a slice of 9 "Samples" "a,b,c,d,e,f,g,h,i" in a 3x3 405 arrangement along with its assumed border. 407 +---+---+---+---+---+---+---+---+ 408 | 0 | 0 | | 0 | 0 | 0 | | 0 | 409 +---+---+---+---+---+---+---+---+ 410 | 0 | 0 | | 0 | 0 | 0 | | 0 | 411 +---+---+---+---+---+---+---+---+ 412 | | | | | | | | | 413 +---+---+---+---+---+---+---+---+ 414 | 0 | 0 | | a | b | c | | c | 415 +---+---+---+---+---+---+---+---+ 416 | 0 | a | | d | e | f | | f | 417 +---+---+---+---+---+---+---+---+ 418 | 0 | d | | g | h | i | | i | 419 +---+---+---+---+---+---+---+---+ 421 Figure 1: A depiction of FFV1's assumed border for a set example 422 Samples. 424 3.2. Samples 426 Relative to any "Sample" "X", six other relatively positioned 427 "Samples" from the coded "Samples" and presumed border are identified 428 according to the labels used in Figure 2. The labels for these 429 relatively positioned "Samples" are used within the median predictor 430 and context. 432 +---+---+---+---+ 433 | | | T | | 434 +---+---+---+---+ 435 | |tl | t |tr | 436 +---+---+---+---+ 437 | L | l | X | | 438 +---+---+---+---+ 440 Figure 2: A depiction of how relatively positions Samples are 441 references within this document. 443 The labels for these relative "Samples" are made of the first letters 444 of the words Top, Left and Right. 446 3.3. Median Predictor 448 The prediction for any "Sample" value at position "X" may be computed 449 based upon the relative neighboring values of "l", "t", and "tl" via 450 this equation: 452 "median(l, t, l + t - tl)". 454 Note, this prediction template is also used in [ISO.14495-1.1999] and 455 [HuffYUV]. 457 Exception for the median predictor: if "colorspace_type == 0 && 458 bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 )", 459 the following median predictor MUST be used: 461 "median(left16s, top16s, left16s + top16s - diag16s)" 463 where: 465 left16s = l >= 32768 ? ( l - 65536 ) : l 466 top16s = t >= 32768 ? ( t - 65536 ) : t 467 diag16s = tl >= 32768 ? ( tl - 65536 ) : tl 469 Background: a two's complement signed 16-bit signed integer was used 470 for storing "Sample" values in all known implementations of FFV1 471 bitstream. So in some circumstances, the most significant bit was 472 wrongly interpreted (used as a sign bit instead of the 16th bit of an 473 unsigned integer). Note that when the issue is discovered, the only 474 configuration of all known implementations being impacted is 16-bit 475 YCbCr with no Pixel transformation with Range Coder coder, as other 476 potentially impacted configurations (e.g. 15/16-bit JPEG2000-RCT with 477 Range Coder coder, or 16-bit content with Golomb Rice coder) were 478 implemented nowhere [ISO.15444-1.2016]. In the meanwhile, 16-bit 479 JPEG2000-RCT with Range Coder coder was implemented without this 480 issue in one implementation and validated by one conformance checker. 481 It is expected (to be confirmed) to remove this exception for the 482 median predictor in the next version of the FFV1 bitstream. 484 3.4. Context 486 Relative to any "Sample" "X", the Quantized Sample Differences "L-l", 487 "l-tl", "tl-t", "T-t", and "t-tr" are used as context: 489 context = Q_{0}[l - tl] + 490 Q_{1}[tl - t] + 491 Q_{2}[t - tr] + 492 Q_{3}[L - l] + 493 Q_{4}[T - t] 495 Figure 3 497 If "context >= 0" then "context" is used and the difference between 498 the "Sample" and its predicted value is encoded as is, else 499 "-context" is used and the difference between the "Sample" and its 500 predicted value is encoded with a flipped sign. 502 3.5. Quantization Table Sets 504 The FFV1 bitstream contains 1 or more Quantization Table Sets. Each 505 Quantization Table Set contains exactly 5 Quantization Tables with 506 each Quantization Table corresponding to 1 of the 5 Quantized Sample 507 Differences. For each Quantization Table, both the number of 508 quantization steps and their distribution are stored in the FFV1 509 bitstream; each Quantization Table has exactly 256 entries, and the 8 510 least significant bits of the Quantized Sample Difference are used as 511 index: 513 Q_{j}[k] = quant_tables[i][j][k&255] 515 Figure 4 517 In this formula, "i" is the Quantization Table Set index, "j" is the 518 Quantized Table index, "k" the Quantized Sample Difference. 520 3.6. Quantization Table Set Indexes 522 For each "Plane" of each slice, a Quantization Table Set is selected 523 from an index: 525 * For Y "Plane", "quant_table_set_index[ 0 ]" index is used 527 * For Cb and Cr "Planes", "quant_table_set_index[ 1 ]" index is used 529 * For extra "Plane", "quant_table_set_index[ (version <= 3 || 530 chroma_planes) ? 2 : 1 ]" index is used 532 Background: in first implementations of FFV1 bitstream, the index for 533 Cb and Cr "Planes" was stored even if it is not used (chroma_planes 534 set to 0), this index is kept for version <= 3 in order to keep 535 compatibility with FFV1 bitstreams in the wild. 537 3.7. Color spaces 539 FFV1 supports several color spaces. The count of allowed coded 540 planes and the meaning of the extra "Plane" are determined by the 541 selected color space. 543 The FFV1 bitstream interleaves data in an order determined by the 544 color space. In YCbCr for each "Plane", each "Line" is coded from 545 top to bottom and for each "Line", each "Sample" is coded from left 546 to right. In JPEG2000-RCT for each "Line" from top to bottom, each 547 "Plane" is coded and for each "Plane", each "Sample" is encoded from 548 left to right. 550 3.7.1. YCbCr 552 This color space allows 1 to 4 "Planes". 554 The Cb and Cr "Planes" are optional, but if used then MUST be used 555 together. Omitting the Cb and Cr "Planes" codes the frames in 556 grayscale without color data. 558 An optional transparency "Plane" can be used to code transparency 559 data. 561 An FFV1 "Frame" using YCbCr MUST use one of the following 562 arrangements: 564 * Y 566 * Y, Transparency 568 * Y, Cb, Cr 570 * Y, Cb, Cr, Transparency 572 The Y "Plane" MUST be coded first. If the Cb and Cr "Planes" are 573 used then they MUST be coded after the Y "Plane". If a transparency 574 "Plane" is used, then it MUST be coded last. 576 3.7.2. RGB 578 This color space allows 3 or 4 "Planes". 580 An optional transparency "Plane" can be used to code transparency 581 data. 583 JPEG2000-RCT is a Reversible Color Transform that codes RGB (red, 584 green, blue) "Planes" losslessly in a modified YCbCr color space 585 [ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr 586 and RGB use the following formulae. 588 Cb=b-g 589 Cr=r-g 590 Y=g+(Cb+Cr)>>2 591 g=Y-(Cb+Cr)>>2 592 r=Cr+g 593 b=Cb+g 595 Figure 5 597 Exception for the JPEG2000-RCT conversion: if "bits_per_raw_sample" 598 is between 9 and 15 inclusive and "extra_plane" is 0, the following 599 formulae for reversible conversions between YCbCr and RGB MUST be 600 used instead of the ones above: 602 Cb=g-b 603 Cr=r-b 604 Y=b+(Cb+Cr)>>2 605 b=Y-(Cb+Cr)>>2 606 r=Cr+b 607 g=Cb+b 609 Figure 6 611 Background: At the time of this writing, in all known implementations 612 of FFV1 bitstream, when "bits_per_raw_sample" was between 9 and 15 613 inclusive and "extra_plane" is 0, GBR "Planes" were used as BGR 614 "Planes" during both encoding and decoding. In the meanwhile, 16-bit 615 JPEG2000-RCT was implemented without this issue in one implementation 616 and validated by one conformance checker. Methods to address this 617 exception for the transform are under consideration for the next 618 version of the FFV1 bitstream. 620 Cb and Cr are positively offseted by "1 << bits_per_raw_sample" after 621 the conversion from RGB to the modified YCbCr and are negatively 622 offseted by the same value before the conversion from the modified 623 YCbCr to RGB, in order to have only non-negative values after the 624 conversion. 626 When FFV1 uses the JPEG2000-RCT, the horizontal "Lines" are 627 interleaved to improve caching efficiency since it is most likely 628 that the JPEG2000-RCT will immediately be converted to RGB during 629 decoding. The interleaved coding order is also Y, then Cb, then Cr, 630 and then if used transparency. 632 As an example, a "Frame" that is two "Pixels" wide and two "Pixels" 633 high, could comprise the following structure: 635 +------------------------+------------------------+ 636 | Pixel(1,1) | Pixel(2,1) | 637 | Y(1,1) Cb(1,1) Cr(1,1) | Y(2,1) Cb(2,1) Cr(2,1) | 638 +------------------------+------------------------+ 639 | Pixel(1,2) | Pixel(2,2) | 640 | Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) | 641 +------------------------+------------------------+ 642 In JPEG2000-RCT, the coding order would be left to right and then top 643 to bottom, with values interleaved by "Lines" and stored in this 644 order: 646 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) 647 Cb(2,2) Cr(1,2) Cr(2,2) 649 3.8. Coding of the Sample Difference 651 Instead of coding the n+1 bits of the Sample Difference with Huffman 652 or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the 653 n (or n+1, in the case of JPEG2000-RCT) least significant bits are 654 used, since this is sufficient to recover the original "Sample". In 655 the equation below, the term "bits" represents "bits_per_raw_sample + 656 1" for JPEG2000-RCT or "bits_per_raw_sample" otherwise: 658 coder_input = 659 [(sample_difference + 2^(bits-1)) & (2^bits - 1)] - 2^(bits-1) 661 Figure 7 663 3.8.1. Range Coding Mode 665 Early experimental versions of FFV1 used the CABAC Arithmetic coder 666 from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain 667 patent/royalty situation, as well as its slightly worse performance, 668 CABAC was replaced by a Range coder based on an algorithm defined by 669 G. Nigel and N. Martin in 1979 [range-coding]. 671 3.8.1.1. Range Binary Values 673 To encode binary digits efficiently a Range coder is used. "C(i)" is 674 the i-th Context. "B(i)" is the i-th byte of the bytestream. "b(i)" 675 is the i-th Range coded binary value, "S(0,i)" is the i-th initial 676 state. The length of the bytestream encoding n binary symbols is 677 "j(n)" bytes. 679 r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 ) 681 Figure 8 683 S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} AND 684 l_i = L_i AND 685 t_i = R_i - r_i <== 686 b_i = 0 <==> 687 L_i < R_i - r_i 689 S_{i+1,C_{i}} = one_state_{S_{i,C_{i}}} AND 690 l_i = L_i - R_i + r_i AND 691 t_i = r_i <== 692 b_i = 1 <==> 693 L_i >= R_i - r_i 695 Figure 9 697 S_{i+1,k} = S_{i,k} <== C_i != k 699 Figure 10 701 R_{i+1} = 2^8 * t_{i} AND 702 L_{i+1} = 2^8 * l_{i} + B_{j_{i}} AND 703 j_{i+1} = j_{i} + 1 <== 704 t_{i} < 2^8 706 R_{i+1} = t_{i} AND 707 L_{i+1} = l_{i} AND 708 j_{i+1} = j_{i} <== 709 t_{i} >= 2^8 711 Figure 11 713 R_{0} = 65280 715 Figure 12 717 L_{0} = 2^8 * B_{0} + B_{1} 719 Figure 13 721 j_{0} = 2 723 Figure 14 725 3.8.1.1.1. Termination 727 The range coder can be used in 3 modes. 729 * In "Open mode" when decoding, every symbol the reader attempts to 730 read is available. In this mode arbitrary data can have been 731 appended without affecting the range coder output. This mode is 732 not used in FFV1. 734 * In "Closed mode" the length in bytes of the bytestream is provided 735 to the range decoder. Bytes beyond the length are read as 0 by 736 the range decoder. This is generally 1 byte shorter than the open 737 mode. 739 * In "Sentinel mode" the exact length in bytes is not known and thus 740 the range decoder MAY read into the data that follows the range 741 coded bytestream by one byte. In "Sentinel mode", the end of the 742 range coded bytestream is a binary symbol with state 129, which 743 value SHALL be discarded. After reading this symbol, the range 744 decoder will have read one byte beyond the end of the range coded 745 bytestream. This way the byte position of the end can be 746 determined. Bytestreams written in "Sentinel mode" can be read in 747 "Closed mode" if the length can be determined, in this case the 748 last (sentinel) symbol will be read non-corrupted and be of value 749 0. 751 Above describes the range decoding, encoding is defined as any 752 process which produces a decodable bytestream. 754 There are 3 places where range coder termination is needed in FFV1. 755 First is in the "Configuration Record", in this case the size of the 756 range coded bytestream is known and handled as "Closed mode". Second 757 is the switch from the "Slice Header" which is range coded to Golomb 758 coded slices as "Sentinel mode". Third is the end of range coded 759 Slices which need to terminate before the CRC at their end. This can 760 be handled as "Sentinel mode" or as "Closed mode" if the CRC position 761 has been determined. 763 3.8.1.2. Range Non Binary Values 765 To encode scalar integers, it would be possible to encode each bit 766 separately and use the past bits as context. However that would mean 767 255 contexts per 8-bit symbol that is not only a waste of memory but 768 also requires more past data to reach a reasonably good estimate of 769 the probabilities. Alternatively assuming a Laplacian distribution 770 and only dealing with its variance and mean (as in Huffman coding) 771 would also be possible, however, for maximum flexibility and 772 simplicity, the chosen method uses a single symbol to encode if a 773 number is 0, and if not, encodes the number using its exponent, 774 mantissa and sign. The exact contexts used are best described by 775 Figure 15, followed by some comments. 777 pseudo-code | type 778 --------------------------------------------------------------|----- 779 void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ | 780 is_signed) { | 781 int i; | 782 put_rac(c, state+0, !v); | 783 if (v) { | 784 int a= abs(v); | 785 int e= log2(a); | 786 | 787 for (i = 0; i < e; i++) { | 788 put_rac(c, state+1+min(i,9), 1); //1..10 | 789 } | 790 | 791 put_rac(c, state+1+min(i,9), 0); | 792 for (i = e-1; i >= 0; i--) { | 793 put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | 794 } | 795 | 796 if (is_signed) { | 797 put_rac(c, state+11 + min(e, 10), v < 0); //11..21| 798 } | 799 } | 800 } | 802 Figure 15: A pseudo-code description of the contexts of Range Non 803 Binary Values. 805 3.8.1.3. Initial Values for the Context Model 807 At keyframes all Range coder state variables are set to their initial 808 state. 810 3.8.1.4. State Transition Table 812 one_state_{i} = 813 default_state_transition_{i} + state_transition_delta_{i} 815 Figure 16 817 zero_state_{i} = 256 - one_state_{256-i} 819 Figure 17 821 3.8.1.5. default_state_transition 822 0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27, 824 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42, 826 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57, 828 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 830 74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 832 89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103, 834 104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118, 836 119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133, 838 134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149, 840 150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164, 842 165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179, 844 180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194, 846 195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209, 848 210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225, 850 226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240, 852 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0, 854 3.8.1.6. Alternative State Transition Table 856 The alternative state transition table has been built using iterative 857 minimization of frame sizes and generally performs better than the 858 default. To use it, the "coder_type" (see Section 4.1.3) MUST be set 859 to 2 and the difference to the default MUST be stored in the 860 "Parameters", see Section 4.1. The reference implementation of FFV1 861 in FFmpeg uses Figure 18 by default at the time of this writing when 862 Range coding is used. 864 0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49, 866 59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39, 868 40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52, 870 53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69, 872 87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97, 874 85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98, 876 105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125, 878 115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129, 880 165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148, 882 147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160, 884 172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178, 886 175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196, 888 197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214, 890 209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225, 892 226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242, 894 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255, 896 Figure 18: Alternative state transition table for Range coding. 898 3.8.2. Golomb Rice Mode 900 The end of the bitstream of the "Frame" is filled with 0-bits until 901 that the bitstream contains a multiple of 8 bits. 903 3.8.2.1. Signed Golomb Rice Codes 905 This coding mode uses Golomb Rice codes. The VLC is split into 2 906 parts, the prefix stores the most significant bits and the suffix 907 stores the k least significant bits or stores the whole number in the 908 ESC case. 910 pseudo-code | type 911 --------------------------------------------------------------|----- 912 int get_ur_golomb(k) { | 913 for (prefix = 0; prefix < 12; prefix++) { | 914 if (get_bits(1)) { | 915 return get_bits(k) + (prefix << k) | 916 } | 917 } | 918 return get_bits(bits) + 11 | 919 } | 920 | 921 int get_sr_golomb(k) { | 922 v = get_ur_golomb(k); | 923 if (v & 1) return - (v >> 1) - 1; | 924 else return (v >> 1); | 925 } 927 3.8.2.1.1. Prefix 929 +----------------+-------+ 930 | bits | value | 931 +================+=======+ 932 | 1 | 0 | 933 +----------------+-------+ 934 | 01 | 1 | 935 +----------------+-------+ 936 | ... | ... | 937 +----------------+-------+ 938 | 0000 0000 01 | 9 | 939 +----------------+-------+ 940 | 0000 0000 001 | 10 | 941 +----------------+-------+ 942 | 0000 0000 0001 | 11 | 943 +----------------+-------+ 944 | 0000 0000 0000 | ESC | 945 +----------------+-------+ 947 Table 1 949 3.8.2.1.2. Suffix 951 +---------+--------------------------------------------------+ 952 +=========+==================================================+ 953 | non ESC | the k least significant bits MSB first | 954 +---------+--------------------------------------------------+ 955 | ESC | the value - 11, in MSB first order, ESC may only | 956 | | be used if the value cannot be coded as non ESC | 957 +---------+--------------------------------------------------+ 958 Table 2 960 3.8.2.1.3. Examples 962 +-----+-------------------------+-------+ 963 | k | bits | value | 964 +=====+=========================+=======+ 965 | 0 | "1" | 0 | 966 +-----+-------------------------+-------+ 967 | 0 | "001" | 2 | 968 +-----+-------------------------+-------+ 969 | 2 | "1 00" | 0 | 970 +-----+-------------------------+-------+ 971 | 2 | "1 10" | 2 | 972 +-----+-------------------------+-------+ 973 | 2 | "01 01" | 5 | 974 +-----+-------------------------+-------+ 975 | any | "000000000000 10000000" | 139 | 976 +-----+-------------------------+-------+ 978 Table 3 980 3.8.2.2. Run Mode 982 Run mode is entered when the context is 0 and left as soon as a non-0 983 difference is found. The level is identical to the predicted one. 984 The run and the first different level are coded. 986 3.8.2.2.1. Run Length Coding 988 The run value is encoded in 2 parts, the prefix part stores the more 989 significant part of the run as well as adjusting the "run_index" that 990 determines the number of bits in the less significant part of the 991 run. The 2nd part of the value stores the less significant part of 992 the run as it is. The run_index is reset for each "Plane" and slice 993 to 0. 995 pseudo-code | type 996 --------------------------------------------------------------|----- 997 log2_run[41]={ | 998 0, 0, 0, 0, 1, 1, 1, 1, | 999 2, 2, 2, 2, 3, 3, 3, 3, | 1000 4, 4, 5, 5, 6, 6, 7, 7, | 1001 8, 9,10,11,12,13,14,15, | 1002 16,17,18,19,20,21,22,23, | 1003 24, | 1004 }; | 1005 | 1006 if (run_count == 0 && run_mode == 1) { | 1007 if (get_bits(1)) { | 1008 run_count = 1 << log2_run[run_index]; | 1009 if (x + run_count <= w) { | 1010 run_index++; | 1011 } | 1012 } else { | 1013 if (log2_run[run_index]) { | 1014 run_count = get_bits(log2_run[run_index]); | 1015 } else { | 1016 run_count = 0; | 1017 } | 1018 if (run_index) { | 1019 run_index--; | 1020 } | 1021 run_mode = 2; | 1022 } | 1023 } | 1025 The "log2_run" function is also used within [ISO.14495-1.1999]. 1027 3.8.2.2.2. Level Coding 1029 Level coding is identical to the normal difference coding with the 1030 exception that the 0 value is removed as it cannot occur: 1032 diff = get_vlc_symbol(context_state); 1033 if (diff >= 0) { 1034 diff++; 1035 } 1037 Note, this is different from JPEG-LS, which doesn't use prediction in 1038 run mode and uses a different encoding and context model for the last 1039 difference On a small set of test "Samples" the use of prediction 1040 slightly improved the compression rate. 1042 3.8.2.3. Scalar Mode 1044 Each difference is coded with the per context mean prediction removed 1045 and a per context value for k. 1047 get_vlc_symbol(state) { 1048 i = state->count; 1049 k = 0; 1050 while (i < state->error_sum) { 1051 k++; 1052 i += i; 1053 } 1055 v = get_sr_golomb(k); 1057 if (2 * state->drift < -state->count) { 1058 v = -1 - v; 1059 } 1061 ret = sign_extend(v + state->bias, bits); 1063 state->error_sum += abs(v); 1064 state->drift += v; 1066 if (state->count == 128) { 1067 state->count >>= 1; 1068 state->drift >>= 1; 1069 state->error_sum >>= 1; 1070 } 1071 state->count++; 1072 if (state->drift <= -state->count) { 1073 state->bias = max(state->bias - 1, -128); 1075 state->drift = max(state->drift + state->count, 1076 -state->count + 1); 1077 } else if (state->drift > 0) { 1078 state->bias = min(state->bias + 1, 127); 1080 state->drift = min(state->drift - state->count, 0); 1081 } 1083 return ret; 1084 } 1086 3.8.2.4. Initial Values for the VLC context state 1088 At keyframes all coder state variables are set to their initial 1089 state. 1091 drift = 0; 1092 error_sum = 4; 1093 bias = 0; 1094 count = 1; 1096 4. Bitstream 1098 An FFV1 bitstream is composed of a series of 1 or more "Frames" and 1099 (when required) a "Configuration Record". 1101 Within the following sub-sections, pseudo-code is used to explain the 1102 structure of each FFV1 bitstream component, as described in 1103 Section 2.2.1. Table 4 lists symbols used to annotate that pseudo- 1104 code in order to define the storage of the data referenced in that 1105 line of pseudo-code. 1107 +--------+----------------------------------------------+ 1108 | Symbol | Definition | 1109 +========+==============================================+ 1110 | u(n) | unsigned big endian integer using n bits | 1111 +--------+----------------------------------------------+ 1112 | sg | Golomb Rice coded signed scalar symbol coded | 1113 | | with the method described in Section 3.8.2 | 1114 +--------+----------------------------------------------+ 1115 | br | Range coded Boolean (1-bit) symbol with the | 1116 | | method described in Section 3.8.1.1 | 1117 +--------+----------------------------------------------+ 1118 | ur | Range coded unsigned scalar symbol coded | 1119 | | with the method described in Section 3.8.1.2 | 1120 +--------+----------------------------------------------+ 1121 | sr | Range coded signed scalar symbol coded with | 1122 | | the method described in Section 3.8.1.2 | 1123 +--------+----------------------------------------------+ 1125 Table 4: Definition of pseudo-code symbols for this 1126 document. 1128 The same context that is initialized to 128 is used for all fields in 1129 the header. 1131 The following MUST be provided by external means during 1132 initialization of the decoder: 1134 "frame_pixel_width" is defined as "Frame" width in "Pixels". 1136 "frame_pixel_height" is defined as "Frame" height in "Pixels". 1138 Default values at the decoder initialization phase: 1140 "ConfigurationRecordIsPresent" is set to 0. 1142 4.1. Parameters 1144 The "Parameters" section contains significant characteristics about 1145 the decoding configuration used for all instances of "Frame" (in FFV1 1146 version 0 and 1) or the whole FFV1 bitstream (other versions), 1147 including the stream version, color configuration, and quantization 1148 tables. Figure 19 describes the contents of the bitstream. 1150 pseudo-code | type 1151 --------------------------------------------------------------|----- 1152 Parameters( ) { | 1153 version | ur 1154 if (version >= 3) { | 1155 micro_version | ur 1156 } | 1157 coder_type | ur 1158 if (coder_type > 1) { | 1159 for (i = 1; i < 256; i++) { | 1160 state_transition_delta[ i ] | sr 1161 } | 1162 } | 1163 colorspace_type | ur 1164 if (version >= 1) { | 1165 bits_per_raw_sample | ur 1166 } | 1167 chroma_planes | br 1168 log2_h_chroma_subsample | ur 1169 log2_v_chroma_subsample | ur 1170 extra_plane | br 1171 if (version >= 3) { | 1172 num_h_slices - 1 | ur 1173 num_v_slices - 1 | ur 1174 quant_table_set_count | ur 1175 } | 1176 for (i = 0; i < quant_table_set_count; i++) { | 1177 QuantizationTableSet( i ) | 1178 } | 1179 if (version >= 3) { | 1180 for (i = 0; i < quant_table_set_count; i++) { | 1181 states_coded | br 1182 if (states_coded) { | 1183 for (j = 0; j < context_count[ i ]; j++) { | 1184 for (k = 0; k < CONTEXT_SIZE; k++) { | 1185 initial_state_delta[ i ][ j ][ k ] | sr 1186 } | 1187 } | 1188 } | 1189 } | 1190 ec | ur 1191 intra | ur 1192 } | 1193 } | 1195 Figure 19: A pseudo-code description of the bitstream contents. 1197 CONTEXT_SIZE is 32. 1199 4.1.1. version 1201 "version" specifies the version of the FFV1 bitstream. 1203 Each version is incompatible with other versions: decoders SHOULD 1204 reject a file due to an unknown version. 1206 Decoders SHOULD reject a file with version <= 1 && 1207 ConfigurationRecordIsPresent == 1. 1209 Decoders SHOULD reject a file with version >= 3 && 1210 ConfigurationRecordIsPresent == 0. 1212 +-------+-------------------------+ 1213 | value | version | 1214 +=======+=========================+ 1215 | 0 | FFV1 version 0 | 1216 +-------+-------------------------+ 1217 | 1 | FFV1 version 1 | 1218 +-------+-------------------------+ 1219 | 2 | reserved* | 1220 +-------+-------------------------+ 1221 | 3 | FFV1 version 3 | 1222 +-------+-------------------------+ 1223 | 4 | FFV1 version 4 | 1224 +-------+-------------------------+ 1225 | Other | reserved for future use | 1226 +-------+-------------------------+ 1228 Table 5 1230 * Version 2 was never enabled in the encoder thus version 2 files 1231 SHOULD NOT exist, and this document does not describe them to keep 1232 the text simpler. 1234 4.1.2. micro_version 1236 "micro_version" specifies the micro-version of the FFV1 bitstream. 1238 After a version is considered stable (a micro-version value is 1239 assigned to be the first stable variant of a specific version), each 1240 new micro-version after this first stable variant is compatible with 1241 the previous micro-version: decoders SHOULD NOT reject a file due to 1242 an unknown micro-version equal or above the micro-version considered 1243 as stable. 1245 Meaning of "micro_version" for version 3: 1247 +-------+-------------------------+ 1248 | value | micro_version | 1249 +=======+=========================+ 1250 | 0...3 | reserved* | 1251 +-------+-------------------------+ 1252 | 4 | first stable variant | 1253 +-------+-------------------------+ 1254 | Other | reserved for future use | 1255 +-------+-------------------------+ 1257 Table 6: The definitions for 1258 "micro_version" values. 1260 * development versions may be incompatible with the stable variants. 1262 Meaning of "micro_version" for version 4 (note: at the time of 1263 writing of this specification, version 4 is not considered stable so 1264 the first stable version value is to be announced in the future): 1266 +---------+-------------------------+ 1267 | value | micro_version | 1268 +=========+=========================+ 1269 | 0...TBA | reserved* | 1270 +---------+-------------------------+ 1271 | TBA | first stable variant | 1272 +---------+-------------------------+ 1273 | Other | reserved for future use | 1274 +---------+-------------------------+ 1276 Table 7: The definitions for 1277 "micro_version" values for FFV1 1278 version 4. 1280 * development versions which may be incompatible with the stable 1281 variants. 1283 4.1.3. coder_type 1285 "coder_type" specifies the coder used. 1287 +-------+-------------------------------------------------+ 1288 | value | coder used | 1289 +=======+=================================================+ 1290 | 0 | Golomb Rice | 1291 +-------+-------------------------------------------------+ 1292 | 1 | Range Coder with default state transition table | 1293 +-------+-------------------------------------------------+ 1294 | 2 | Range Coder with custom state transition table | 1295 +-------+-------------------------------------------------+ 1296 | Other | reserved for future use | 1297 +-------+-------------------------------------------------+ 1299 Table 8 1301 Restrictions: 1303 If "coder_type" is 0, then "bits_per_raw_sample" SHOULD NOT be > 8. 1305 Background: At the time of this writing, there is no known 1306 implementations of FFV1 bitstream supporting Golomb Rice algorithm 1307 with "bits_per_raw_sample" greater than 8, and Range Coder is 1308 prefered. 1310 4.1.4. state_transition_delta 1312 "state_transition_delta" specifies the Range coder custom state 1313 transition table. 1315 If "state_transition_delta" is not present in the FFV1 bitstream, all 1316 Range coder custom state transition table elements are assumed to be 1317 0. 1319 4.1.5. colorspace_type 1321 "colorspace_type" specifies the color space encoded, the pixel 1322 transformation used by the encoder, the extra plane content, as well 1323 as interleave method. 1325 +-------+-------------+----------------+--------------+-------------+ 1326 | value | color space | pixel | extra plane | interleave | 1327 | | encoded | transformation | content | method | 1328 +=======+=============+================+==============+=============+ 1329 | 0 | YCbCr | None | Transparency | "Plane" | 1330 | | | | | then | 1331 | | | | | "Line" | 1332 +-------+-------------+----------------+--------------+-------------+ 1333 | 1 | RGB | JPEG2000-RCT | Transparency | "Line" | 1334 | | | | | then | 1335 | | | | | "Plane" | 1336 +-------+-------------+----------------+--------------+-------------+ 1337 | Other | reserved | reserved for | reserved for | reserved | 1338 | | for future | future use | future use | for future | 1339 | | use | | | use | 1340 +-------+-------------+----------------+--------------+-------------+ 1342 Table 9 1344 Restrictions: 1346 If "colorspace_type" is 1, then "chroma_planes" MUST be 1, 1347 "log2_h_chroma_subsample" MUST be 0, and "log2_v_chroma_subsample" 1348 MUST be 0. 1350 4.1.6. chroma_planes 1352 "chroma_planes" indicates if chroma (color) "Planes" are present. 1354 +-------+---------------------------------+ 1355 | value | presence | 1356 +=======+=================================+ 1357 | 0 | chroma "Planes" are not present | 1358 +-------+---------------------------------+ 1359 | 1 | chroma "Planes" are present | 1360 +-------+---------------------------------+ 1362 Table 10 1364 4.1.7. bits_per_raw_sample 1366 "bits_per_raw_sample" indicates the number of bits for each "Sample". 1367 Inferred to be 8 if not present. 1369 +-------+-----------------------------------+ 1370 | value | bits for each sample | 1371 +=======+===================================+ 1372 | 0 | reserved* | 1373 +-------+-----------------------------------+ 1374 | Other | the actual bits for each "Sample" | 1375 +-------+-----------------------------------+ 1377 Table 11 1379 * Encoders MUST NOT store "bits_per_raw_sample" = 0 Decoders SHOULD 1380 accept and interpret "bits_per_raw_sample" = 0 as 8. 1382 4.1.8. log2_h_chroma_subsample 1384 "log2_h_chroma_subsample" indicates the subsample factor, stored in 1385 powers to which the number 2 must be raised, between luma and chroma 1386 width ("chroma_width = 2^-log2_h_chroma_subsample^ * luma_width"). 1388 4.1.9. log2_v_chroma_subsample 1390 "log2_v_chroma_subsample" indicates the subsample factor, stored in 1391 powers to which the number 2 must be raised, between luma and chroma 1392 height ("chroma_height=2^-log2_v_chroma_subsample^ * luma_height"). 1394 4.1.10. "extra\_plane" 1396 "extra_plane" indicates if an extra "Plane" is present. 1398 +-------+------------------------------+ 1399 | value | presence | 1400 +=======+==============================+ 1401 | 0 | extra "Plane" is not present | 1402 +-------+------------------------------+ 1403 | 1 | extra "Plane" is present | 1404 +-------+------------------------------+ 1406 Table 12 1408 4.1.11. num_h_slices 1410 "num_h_slices" indicates the number of horizontal elements of the 1411 slice raster. 1413 Inferred to be 1 if not present. 1415 4.1.12. num_v_slices 1417 "num_v_slices" indicates the number of vertical elements of the slice 1418 raster. 1420 Inferred to be 1 if not present. 1422 4.1.13. quant_table_set_count 1424 "quant_table_set_count" indicates the number of Quantization 1425 Table Sets. "quant_table_set_count" MUST be less than or equal to 8. 1427 Inferred to be 1 if not present. 1429 MUST NOT be 0. 1431 4.1.14. states_coded 1433 "states_coded" indicates if the respective Quantization Table Set has 1434 the initial states coded. 1436 Inferred to be 0 if not present. 1438 +-------+--------------------------------+ 1439 | value | initial states | 1440 +=======+================================+ 1441 | 0 | initial states are not present | 1442 | | and are assumed to be all 128 | 1443 +-------+--------------------------------+ 1444 | 1 | initial states are present | 1445 +-------+--------------------------------+ 1447 Table 13 1449 4.1.15. initial_state_delta 1451 "initial_state_delta[ i ][ j ][ k ]" indicates the initial Range 1452 coder state, it is encoded using "k" as context index and 1454 pred = j ? initial_states[ i ][j - 1][ k ] 1456 Figure 20 1458 initial_state[ i ][ j ][ k ] = 1459 ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255 1461 Figure 21 1463 4.1.16. ec 1465 "ec" indicates the error detection/correction type. 1467 +-------+--------------------------------------------+ 1468 | value | error detection/correction type | 1469 +=======+============================================+ 1470 | 0 | 32-bit CRC on the global header | 1471 +-------+--------------------------------------------+ 1472 | 1 | 32-bit CRC per slice and the global header | 1473 +-------+--------------------------------------------+ 1474 | Other | reserved for future use | 1475 +-------+--------------------------------------------+ 1477 Table 14 1479 4.1.17. intra 1481 "intra" indicates the constraint on "keyframe" in each instance of 1482 "Frame". 1484 Inferred to be 0 if not present. 1486 +-------+-------------------------------------------------------+ 1487 | value | relationship | 1488 +=======+=======================================================+ 1489 | 0 | "keyframe" can be 0 or 1 (non keyframes or keyframes) | 1490 +-------+-------------------------------------------------------+ 1491 | 1 | "keyframe" MUST be 1 (keyframes only) | 1492 +-------+-------------------------------------------------------+ 1493 | Other | reserved for future use | 1494 +-------+-------------------------------------------------------+ 1496 Table 15 1498 4.2. Configuration Record 1500 In the case of a FFV1 bitstream with "version >= 3", a "Configuration 1501 Record" is stored in the underlying "Container", at the track header 1502 level. It contains the "Parameters" used for all instances of 1503 "Frame". The size of the "Configuration Record", "NumBytes", is 1504 supplied by the underlying "Container". 1506 pseudo-code | type 1507 -----------------------------------------------------------|----- 1508 ConfigurationRecord( NumBytes ) { | 1509 ConfigurationRecordIsPresent = 1 | 1510 Parameters( ) | 1511 while (remaining_symbols_in_syntax(NumBytes - 4)) { | 1512 reserved_for_future_use | br/ur/sr 1513 } | 1514 configuration_record_crc_parity | u(32) 1515 } | 1517 4.2.1. reserved_for_future_use 1519 "reserved_for_future_use" has semantics that are reserved for future 1520 use. 1522 Encoders conforming to this version of this specification SHALL NOT 1523 write this value. 1525 Decoders conforming to this version of this specification SHALL 1526 ignore its value. 1528 4.2.2. configuration_record_crc_parity 1530 "configuration_record_crc_parity" 32 bits that are chosen so that the 1531 "Configuration Record" as a whole has a crc remainder of 0. 1533 This is equivalent to storing the crc remainder in the 32-bit parity. 1535 The CRC generator polynomial used is the standard IEEE CRC polynomial 1536 (0x104C11DB7) with initial value 0. 1538 4.2.3. Mapping FFV1 into Containers 1540 This "Configuration Record" can be placed in any file format 1541 supporting "Configuration Records", fitting as much as possible with 1542 how the file format uses to store "Configuration Records". The 1543 "Configuration Record" storage place and "NumBytes" are currently 1544 defined and supported by this version of this specification for the 1545 following formats: 1547 4.2.3.1. AVI File Format 1549 The "Configuration Record" extends the stream format chunk ("AVI ", 1550 "hdlr", "strl", "strf") with the ConfigurationRecord bitstream. 1552 See [AVI] for more information about chunks. 1554 "NumBytes" is defined as the size, in bytes, of the strf chunk 1555 indicated in the chunk header minus the size of the stream format 1556 structure. 1558 4.2.3.2. ISO Base Media File Format 1560 The "Configuration Record" extends the sample description box 1561 ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box 1562 that contains the ConfigurationRecord bitstream. See 1563 [ISO.14496-12.2015] for more information about boxes. 1565 "NumBytes" is defined as the size, in bytes, of the "glbl" box 1566 indicated in the box header minus the size of the box header. 1568 4.2.3.3. NUT File Format 1570 The "codec_specific_data" element (in "stream_header" packet) 1571 contains the ConfigurationRecord bitstream. See [NUT] for more 1572 information about elements. 1574 "NumBytes" is defined as the size, in bytes, of the 1575 "codec_specific_data" element as indicated in the "length" field of 1576 "codec_specific_data". 1578 4.2.3.4. Matroska File Format 1580 FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 1581 versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be 1582 used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" 1583 Element MUST contain the FFV1 "Configuration Record" structure and no 1584 other data. See [Matroska] for more information about elements. 1586 "NumBytes" is defined as the "Element Data Size" of the 1587 "CodecPrivate" Element. 1589 4.3. Frame 1591 A "Frame" is an encoded representation of a complete static image. 1592 The whole "Frame" is provided by the underlaying container. 1594 A "Frame" consists of the "keyframe" field, "Parameters" (if 1595 "version" <=1), and a sequence of independent slices. The pseudo- 1596 code below describes the contents of a "Frame". 1598 pseudo-code | type 1599 --------------------------------------------------------------|----- 1600 Frame( NumBytes ) { | 1601 keyframe | br 1602 if (keyframe && !ConfigurationRecordIsPresent { | 1603 Parameters( ) | 1604 } | 1605 while (remaining_bits_in_bitstream( NumBytes )) { | 1606 Slice( ) | 1607 } | 1608 } | 1610 Architecture overview of slices in a "Frame": 1612 +-----------------------------------------------------------------+ 1613 +=================================================================+ 1614 | first slice header | 1615 +-----------------------------------------------------------------+ 1616 | first slice content | 1617 +-----------------------------------------------------------------+ 1618 | first slice footer | 1619 +-----------------------------------------------------------------+ 1620 | --------------------------------------------------------------- | 1621 +-----------------------------------------------------------------+ 1622 | second slice header | 1623 +-----------------------------------------------------------------+ 1624 | second slice content | 1625 +-----------------------------------------------------------------+ 1626 | second slice footer | 1627 +-----------------------------------------------------------------+ 1628 | --------------------------------------------------------------- | 1629 +-----------------------------------------------------------------+ 1630 | ... | 1631 +-----------------------------------------------------------------+ 1632 | --------------------------------------------------------------- | 1633 +-----------------------------------------------------------------+ 1634 | last slice header | 1635 +-----------------------------------------------------------------+ 1636 | last slice content | 1637 +-----------------------------------------------------------------+ 1638 | last slice footer | 1639 +-----------------------------------------------------------------+ 1641 Table 16 1643 4.4. Slice 1645 A "Slice" is an independent spatial sub-section of a "Frame" that is 1646 encoded separately from an other region of the same "Frame". The use 1647 of more than one "Slice" per "Frame" can be useful for taking 1648 advantage of the opportunities of multithreaded encoding and 1649 decoding. 1651 A "Slice" consists of a "Slice Header" (when relevant), a "Slice 1652 Content", and a "Slice Footer" (when relevant). The pseudo-code 1653 below describes the contents of a "Slice". 1655 pseudo-code | type 1656 --------------------------------------------------------------|----- 1657 Slice( ) { | 1658 if (version >= 3) { | 1659 SliceHeader( ) | 1660 } | 1661 SliceContent( ) | 1662 if (coder_type == 0) { | 1663 while (!byte_aligned()) { | 1664 padding | u(1) 1665 } | 1666 } | 1667 if (version <= 1) { | 1668 while (remaining_bits_in_bitstream( NumBytes ) != 0) {| 1669 reserved | u(1) 1670 } | 1671 } | 1672 if (version >= 3) { | 1673 SliceFooter( ) | 1674 } | 1675 } | 1677 "padding" specifies a bit without any significance and used only for 1678 byte alignment. MUST be 0. 1680 "reserved" specifies a bit without any significance in this revision 1681 of the specification and may have a significance in a later revision 1682 of this specification. 1684 Encoders SHOULD NOT fill these bits. 1686 Decoders SHOULD ignore these bits. 1688 Note in case these bits are used in a later revision of this 1689 specification: any revision of this specification SHOULD care about 1690 avoiding to add 40 bits of content after "SliceContent" for "version" 1691 0 and 1 of the bitstream. Background: Due to some non-conforming 1692 encoders, some bitstreams were found with 40 extra bits corresponding 1693 to "error_status" and "slice_crc_parity". As a result, a decoder 1694 conforming to the revised specification could not distinguish between 1695 a revised bitstream and a buggy bitstream. 1697 4.5. Slice Header 1699 A "Slice Header" provides information about the decoding 1700 configuration of the "Slice", such as its spatial position, size, and 1701 aspect ratio. The pseudo-code below describes the contents of the 1702 "Slice Header". 1704 pseudo-code | type 1705 --------------------------------------------------------------|----- 1706 SliceHeader( ) { | 1707 slice_x | ur 1708 slice_y | ur 1709 slice_width - 1 | ur 1710 slice_height - 1 | ur 1711 for (i = 0; i < quant_table_set_index_count; i++) { | 1712 quant_table_set_index[ i ] | ur 1713 } | 1714 picture_structure | ur 1715 sar_num | ur 1716 sar_den | ur 1717 if (version >= 4) { | 1718 reset_contexts | br 1719 slice_coding_mode | ur 1720 } | 1721 } | 1723 4.5.1. slice_x 1725 "slice_x" indicates the x position on the slice raster formed by 1726 num_h_slices. 1728 Inferred to be 0 if not present. 1730 4.5.2. slice_y 1732 "slice_y" indicates the y position on the slice raster formed by 1733 num_v_slices. 1735 Inferred to be 0 if not present. 1737 4.5.3. slice_width 1739 "slice_width" indicates the width on the slice raster formed by 1740 num_h_slices. 1742 Inferred to be 1 if not present. 1744 4.5.4. slice_height 1746 "slice_height" indicates the height on the slice raster formed by 1747 num_v_slices. 1749 Inferred to be 1 if not present. 1751 4.5.5. quant_table_set_index_count 1753 "quant_table_set_index_count" is defined as "1 + ( ( chroma_planes || 1754 version <= 3 ) ? 1 : 0 ) + ("extra_plane"? 1 : 0 )". 1756 4.5.6. quant_table_set_index 1758 "quant_table_set_index" indicates the Quantization Table Set index to 1759 select the Quantization Table Set and the initial states for the 1760 slice. 1762 Inferred to be 0 if not present. 1764 4.5.7. picture_structure 1766 "picture_structure" specifies the temporal and spatial relationship 1767 of each "Line" of the "Frame". 1769 Inferred to be 0 if not present. 1771 +-------+-------------------------+ 1772 | value | picture structure used | 1773 +=======+=========================+ 1774 | 0 | unknown | 1775 +-------+-------------------------+ 1776 | 1 | top field first | 1777 +-------+-------------------------+ 1778 | 2 | bottom field first | 1779 +-------+-------------------------+ 1780 | 3 | progressive | 1781 +-------+-------------------------+ 1782 | Other | reserved for future use | 1783 +-------+-------------------------+ 1785 Table 17 1787 4.5.8. sar_num 1789 "sar_num" specifies the "Sample" aspect ratio numerator. 1791 Inferred to be 0 if not present. 1793 A value of 0 means that aspect ratio is unknown. 1795 Encoders MUST write 0 if "Sample" aspect ratio is unknown. 1797 If "sar_den" is 0, decoders SHOULD ignore the encoded value and 1798 consider that "sar_num" is 0. 1800 4.5.9. sar_den 1802 "sar_den" specifies the "Sample" aspect ratio denominator. 1804 Inferred to be 0 if not present. 1806 A value of 0 means that aspect ratio is unknown. 1808 Encoders MUST write 0 if "Sample" aspect ratio is unknown. 1810 If "sar_num" is 0, decoders SHOULD ignore the encoded value and 1811 consider that "sar_den" is 0. 1813 4.5.10. reset_contexts 1815 "reset_contexts" indicates if slice contexts must be reset. 1817 Inferred to be 0 if not present. 1819 4.5.11. slice_coding_mode 1821 "slice_coding_mode" indicates the slice coding mode. 1823 Inferred to be 0 if not present. 1825 +-------+-----------------------------+ 1826 | value | slice coding mode | 1827 +=======+=============================+ 1828 | 0 | Range Coding or Golomb Rice | 1829 +-------+-----------------------------+ 1830 | 1 | raw PCM | 1831 +-------+-----------------------------+ 1832 | Other | reserved for future use | 1833 +-------+-----------------------------+ 1835 Table 18 1837 4.6. Slice Content 1839 A "Slice Content" contains all "Line" elements part of the "Slice". 1841 Depending on the configuration, "Line" elements are ordered by 1842 "Plane" then by row (YCbCr) or by row then by "Plane" (RGB). 1844 pseudo-code | type 1845 --------------------------------------------------------------|----- 1846 SliceContent( ) { | 1847 if (colorspace_type == 0) { | 1848 for (p = 0; p < primary_color_count; p++) { | 1849 for (y = 0; y < plane_pixel_height[ p ]; y++) { | 1850 Line( p, y ) | 1851 } | 1852 } | 1853 } else if (colorspace_type == 1) { | 1854 for (y = 0; y < slice_pixel_height; y++) { | 1855 for (p = 0; p < primary_color_count; p++) { | 1856 Line( p, y ) | 1857 } | 1858 } | 1859 } | 1860 } | 1862 4.6.1. primary_color_count 1864 "primary_color_count" is defined as "1 + ( chroma_planes ? 2 : 0 ) + 1865 ("extra_plane"? 1 : 0 )". 1867 4.6.2. plane_pixel_height 1869 "plane_pixel_height[ p ]" is the height in pixels of plane p of the 1870 slice. 1872 "plane_pixel_height[ 0 ]" and "plane_pixel_height[ 1 + ( 1873 chroma_planes ? 2 : 0 ) ]" value is "slice_pixel_height". 1875 If "chroma_planes" is set to 1, "plane_pixel_height[ 1 ]" and 1876 "plane_pixel_height[ 2 ]" value is "ceil( slice_pixel_height / (1 << 1877 log2_v_chroma_subsample) )". 1879 4.6.3. slice_pixel_height 1881 "slice_pixel_height" is the height in pixels of the slice. 1883 Its value is "floor( ( slice_y + slice_height ) * slice_pixel_height 1884 / num_v_slices ) - slice_pixel_y". 1886 4.6.4. slice_pixel_y 1888 "slice_pixel_y" is the slice vertical position in pixels. 1890 Its value is "floor( slice_y * frame_pixel_height / num_v_slices )". 1892 4.7. Line 1894 A "Line" is a list of the sample differences (relative to the 1895 predictor) of primary color components. The pseudo-code below 1896 describes the contents of the "Line". 1898 pseudo-code | type 1899 --------------------------------------------------------------|----- 1900 Line( p, y ) { | 1901 if (colorspace_type == 0) { | 1902 for (x = 0; x < plane_pixel_width[ p ]; x++) { | 1903 sample_difference[ p ][ y ][ x ] | 1904 } | 1905 } else if (colorspace_type == 1) { | 1906 for (x = 0; x < slice_pixel_width; x++) { | 1907 sample_difference[ p ][ y ][ x ] | 1908 } | 1909 } | 1910 } | 1912 4.7.1. plane_pixel_width 1914 "plane_pixel_width[ p ]" is the width in "Pixels" of "Plane" p of the 1915 slice. 1917 "plane_pixel_width[ 0 ]" and "plane_pixel_width[ 1 + ( chroma_planes 1918 ? 2 : 0 ) ]" value is "slice_pixel_width". 1920 If "chroma_planes" is set to 1, "plane_pixel_width[ 1 ]" and 1921 "plane_pixel_width[ 2 ]" value is "ceil( slice_pixel_width / (1 << 1922 log2_h_chroma_subsample) )". 1924 4.7.2. slice_pixel_width 1926 "slice_pixel_width" is the width in "Pixels" of the slice. 1928 Its value is "floor( ( slice_x + slice_width ) * slice_pixel_width / 1929 num_h_slices ) - slice_pixel_x". 1931 4.7.3. slice_pixel_x 1933 "slice_pixel_x" is the slice horizontal position in "Pixels". 1935 Its value is "floor( slice_x * frame_pixel_width / num_h_slices )". 1937 4.7.4. sample_difference 1939 "sample_difference[ p ][ y ][ x ]" is the sample difference for 1940 "Sample" at "Plane" "p", y position "y", and x position "x". The 1941 "Sample" value is computed based on median predictor and context 1942 described in Section 3.2. 1944 4.8. Slice Footer 1946 A "Slice Footer" provides information about slice size and 1947 (optionally) parity. The pseudo-code below describes the contents of 1948 the "Slice Footer". 1950 Note: "Slice Footer" is always byte aligned. 1952 pseudo-code | type 1953 --------------------------------------------------------------|----- 1954 SliceFooter( ) { | 1955 slice_size | u(24) 1956 if (ec) { | 1957 error_status | u(8) 1958 slice_crc_parity | u(32) 1959 } | 1960 } | 1962 4.8.1. slice_size 1964 "slice_size" indicates the size of the slice in bytes. 1966 Note: this allows finding the start of slices before previous slices 1967 have been fully decoded, and allows parallel decoding as well as 1968 error resilience. 1970 4.8.2. error_status 1972 "error_status" specifies the error status. 1974 +-------+--------------------------------------+ 1975 | value | error status | 1976 +=======+======================================+ 1977 | 0 | no error | 1978 +-------+--------------------------------------+ 1979 | 1 | slice contains a correctable error | 1980 +-------+--------------------------------------+ 1981 | 2 | slice contains a uncorrectable error | 1982 +-------+--------------------------------------+ 1983 | Other | reserved for future use | 1984 +-------+--------------------------------------+ 1986 Table 19 1988 4.8.3. slice_crc_parity 1990 "slice_crc_parity" 32 bits that are chosen so that the slice as a 1991 whole has a crc remainder of 0. 1993 This is equivalent to storing the crc remainder in the 32-bit parity. 1995 The CRC generator polynomial used is the standard IEEE CRC polynomial 1996 (0x104C11DB7), with initial value 0, without pre-inversion and 1997 without post-inversion. 1999 4.9. Quantization Table Set 2001 The Quantization Table Sets are stored by storing the number of equal 2002 entries -1 of the first half of the table (represented as "len - 1" 2003 in the pseudo-code below) using the method described in 2004 Section 3.8.1.2. The second half doesn't need to be stored as it is 2005 identical to the first with flipped sign. "scale" and "len_count[ i 2006 ][ j ]" are temporary values used for the computing of 2007 "context_count[ i ]" and are not used outside Quantization Table Set 2008 pseudo-code. 2010 Example: 2012 Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0 2014 Stored values: 1, 3, 1 2016 pseudo-code | type 2017 --------------------------------------------------------------|----- 2018 QuantizationTableSet( i ) { | 2019 scale = 1 | 2020 for (j = 0; j < MAX_CONTEXT_INPUTS; j++) { | 2021 QuantizationTable( i, j, scale ) | 2022 scale *= 2 * len_count[ i ][ j ] - 1 | 2023 } | 2024 context_count[ i ] = ceil( scale / 2 ) | 2025 } | 2027 MAX_CONTEXT_INPUTS is 5. 2029 pseudo-code | type 2030 --------------------------------------------------------------|----- 2031 QuantizationTable(i, j, scale) { | 2032 v = 0 | 2033 for (k = 0; k < 128;) { | 2034 len - 1 | ur 2035 for (a = 0; a < len; a++) { | 2036 quant_tables[ i ][ j ][ k ] = scale * v | 2037 k++ | 2038 } | 2039 v++ | 2040 } | 2041 for (k = 1; k < 128; k++) { | 2042 quant_tables[ i ][ j ][ 256 - k ] = \ | 2043 -quant_tables[ i ][ j ][ k ] | 2044 } | 2045 quant_tables[ i ][ j ][ 128 ] = \ | 2046 -quant_tables[ i ][ j ][ 127 ] | 2047 len_count[ i ][ j ] = v | 2048 } | 2050 4.9.1. quant_tables 2052 "quant_tables[ i ][ j ][ k ]" indicates the quantification table 2053 value of the Quantized Sample Difference "k" of the Quantization 2054 Table "j" of the Set Quantization Table Set "i". 2056 4.9.2. context_count 2058 "context_count[ i ]" indicates the count of contexts for Quantization 2059 Table Set "i". "context_count[ i ]" MUST be less than or equal to 2060 32768. 2062 5. Restrictions 2064 To ensure that fast multithreaded decoding is possible, starting with 2065 "version" 3 and if "frame_pixel_width * frame_pixel_height" is more 2066 than 101376, "slice_width * slice_height" MUST be less or equal to 2067 "num_h_slices * num_v_slices / 4". Note: 101376 is the frame size in 2068 "Pixels" of a 352x288 frame also known as CIF ("Common Intermediate 2069 Format") frame size format. 2071 For each "Frame", each position in the slice raster MUST be filled by 2072 one and only one slice of the "Frame" (no missing slice position, no 2073 slice overlapping). 2075 For each "Frame" with "keyframe" value of 0, each slice MUST have the 2076 same value of "slice_x", "slice_y", "slice_width", "slice_height" as 2077 a slice in the previous "Frame", except if "reset_contexts" is 1. 2079 6. Security Considerations 2081 Like any other codec, (such as [RFC6716]), FFV1 should not be used 2082 with insecure ciphers or cipher-modes that are vulnerable to known 2083 plaintext attacks. Some of the header bits as well as the padding 2084 are easily predictable. 2086 Implementations of the FFV1 codec need to take appropriate security 2087 considerations into account, as outlined in [RFC4732]. It is 2088 extremely important for the decoder to be robust against malicious 2089 payloads. Malicious payloads must not cause the decoder to overrun 2090 its allocated memory or to take an excessive amount of resources to 2091 decode. The same applies to the encoder, even though problems in 2092 encoders are typically rarer. Malicious video streams must not cause 2093 the encoder to misbehave because this would allow an attacker to 2094 attack transcoding gateways. A frequent security problem in image 2095 and video codecs is also to not check for integer overflows in 2096 "Pixel" count computations, that is to allocate width * height 2097 without considering that the multiplication result may have 2098 overflowed the arithmetic types range. The range coder could, if 2099 implemented naively, read one byte over the end. The implementation 2100 must ensure that no read outside allocated and initialized memory 2101 occurs. 2103 The reference implementation [REFIMPL] contains no known buffer 2104 overflow or cases where a specially crafted packet or video segment 2105 could cause a significant increase in CPU load. 2107 The reference implementation [REFIMPL] was validated in the following 2108 conditions: 2110 * Sending the decoder valid packets generated by the reference 2111 encoder and verifying that the decoder's output matches the 2112 encoder's input. 2114 * Sending the decoder packets generated by the reference encoder and 2115 then subjected to random corruption. 2117 * Sending the decoder random packets that are not FFV1. 2119 In all of the conditions above, the decoder and encoder was run 2120 inside the [VALGRIND] memory debugger as well as clangs address 2121 sanitizer [Address-Sanitizer], which track reads and writes to 2122 invalid memory regions as well as the use of uninitialized memory. 2123 There were no errors reported on any of the tested conditions. 2125 7. Media Type Definition 2127 This section completes the media type registration template defined 2128 in [RFC6838] and following [RFC4855]. 2130 Type name: video 2132 Subtype name: FFV1 2134 Required parameters: None. 2136 Optional parameters: 2138 This parameter is used to signal the capabilities of a receiver 2139 implementation. This parameter MUST NOT be used for any other 2140 purpose. 2142 "version": The version of the FFV1 encoding as defined by 2143 Section 4.1.1. 2145 "micro_version": The "micro_version" of the FFV1 encoding as defined 2146 by Section 4.1.2. 2148 "coder_type": The "coder_type" of the FFV1 encoding as defined by 2149 Section 4.1.3. 2151 "colorspace_type": The "colorspace_type" of the FFV1 encoding as 2152 defined by Section 4.1.5. 2154 "bits_per_raw_sample": The "bits_per_raw_sample" of the FFV1 encoding 2155 as defined by Section 4.1.7. 2157 "max_slices": The value of "max_slices" is an integer indicating the 2158 maximum count of slices with a frames of the FFV1 encoding. 2160 Encoding considerations: 2162 This media type is defined for encapsulation in several audiovisual 2163 container formats and contains binary data; see Section 4.2.3. This 2164 media type is framed binary data; see Section 4.8 of [RFC6838]. 2166 Security considerations: 2168 See Section 6 of this document. 2170 Interoperability considerations: None. 2172 Published specification: 2174 RFC XXXX. 2176 [RFC Editor: Upon publication as an RFC, please replace "XXXX" with 2177 the number assigned to this document and remove this note.] 2179 Applications which use this media type: 2181 Any application that requires the transport of lossless video can use 2182 this media type. Some examples are, but not limited to screen 2183 recording, scientific imaging, and digital video preservation. 2185 Fragment identifier considerations: N/A. 2187 Additional information: None. 2189 Person & email address to contact for further information: Michael 2190 Niedermayer michael@niedermayer.cc (mailto:michael@niedermayer.cc) 2192 Intended usage: COMMON 2194 Restrictions on usage: None. 2196 Author: Dave Rice dave@dericed.com (mailto:dave@dericed.com) 2198 Change controller: IETF cellar working group delegated from the IESG. 2200 8. IANA Considerations 2202 The IANA is requested to register the following values: 2204 * Media type registration as described in Section 7. 2206 9. Appendix A: Multi-theaded decoder implementation suggestions 2208 The FFV1 bitstream is parsable in two ways: in sequential order as 2209 described in this document or with the pre-analysis of the footer of 2210 each slice. Each slice footer contains a "slice_size" field so the 2211 boundary of each slice is computable without having to parse the 2212 slice content. That allows multi-threading as well as independence 2213 of slice content (a bitstream error in a slice header or slice 2214 content has no impact on the decoding of the other slices). 2216 After having checked "keyframe" field, a decoder SHOULD parse 2217 "slice_size" fields, from "slice_size" of the last slice at the end 2218 of the "Frame" up to "slice_size" of the first slice at the beginning 2219 of the "Frame", before parsing slices, in order to have slices 2220 boundaries. A decoder MAY fallback on sequential order e.g. in case 2221 of a corrupted "Frame" (frame size unknown, "slice_size" of slices 2222 not coherent...) or if there is no possibility of seeking into the 2223 stream. 2225 10. Changelog 2227 See https://github.com/FFmpeg/FFV1/commits/master 2228 (https://github.com/FFmpeg/FFV1/commits/master) 2230 [RFC Editor: Please remove this Changelog section prior to 2231 publication.] 2233 11. Normative References 2235 [ISO.9899.2018] 2236 International Organization for Standardization, 2237 "Programming languages - C", 2018. 2239 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 2240 Denial-of-Service Considerations", RFC 4732, 2241 DOI 10.17487/RFC4732, December 2006, 2242 . 2244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2245 Requirement Levels", BCP 14, RFC 2119, 2246 DOI 10.17487/RFC2119, March 1997, 2247 . 2249 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2250 Specifications and Registration Procedures", BCP 13, 2251 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2252 . 2254 [ISO.9899.1990] 2255 International Organization for Standardization, 2256 "Programming languages - C", 1990. 2258 [Matroska] IETF, "Matroska", 2019, . 2261 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2262 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 2263 . 2265 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2266 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2267 May 2017, . 2269 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 2270 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 2271 September 2012, . 2273 [ISO.15444-1.2016] 2274 International Organization for Standardization, 2275 "Information technology -- JPEG 2000 image coding system: 2276 Core coding system", October 2016. 2278 12. Informative References 2280 [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, 2281 . 2284 [ISO.14496-12.2015] 2285 International Organization for Standardization, 2286 "Information technology -- Coding of audio-visual objects 2287 -- Part 12: ISO base media file format", December 2015. 2289 [VALGRIND] Valgrind Developers, "Valgrind website", undated, 2290 . 2292 [AVI] Microsoft, "AVI RIFF File Reference", undated, 2293 . 2296 [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the 2297 FFV1 codec in FFmpeg", undated, . 2299 [Address-Sanitizer] 2300 The Clang Team, "ASAN AddressSanitizer website", undated, 2301 . 2303 [YCbCr] Wikipedia, "YCbCr", undated, 2304 . 2306 [ISO.14495-1.1999] 2307 International Organization for Standardization, 2308 "Information technology -- Lossless and near-lossless 2309 compression of continuous-tone still images: Baseline", 2310 December 1999. 2312 [range-coding] 2313 Nigel, G. and N. Martin, "Range encoding: an algorithm for 2314 removing redundancy from a digitised message.", July 1979. 2316 [ISO.14496-10.2014] 2317 International Organization for Standardization, 2318 "Information technology -- Coding of audio-visual objects 2319 -- Part 10: Advanced Video Coding", September 2014. 2321 [I-D.ietf-cellar-ffv1] 2322 Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video 2323 Coding Format Version 0, 1, and 3", Work in Progress, 2324 Internet-Draft, draft-ietf-cellar-ffv1-12, 28 January 2325 2020, 2326 . 2328 [NUT] Niedermayer, M., "NUT Open Container Format", December 2329 2013, . 2331 Authors' Addresses 2333 Michael Niedermayer 2335 Email: michael@niedermayer.cc 2337 Dave Rice 2339 Email: dave@dericed.com 2341 Jerome Martinez 2343 Email: jerome@mediaarea.net