idnits 2.17.1 draft-ietf-cellar-ffv1-v4-03.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 (October 18, 2018) is 2011 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: '1' on line 619 -- Looks like a reference, but probably isn't: '2' on line 619 == Outdated reference: A later version (-20) exists of draft-ietf-cellar-ffv1-05 ** Downref: Normative reference to an Informational draft: draft-ietf-cellar-ffv1 (ref. 'I-D.ietf-cellar-ffv1') ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Downref: Normative reference to an Informational RFC: RFC 4732 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: April 21, 2019 6 J. Martinez 7 October 18, 2018 9 FFV1 Video Coding Format Version 4 10 draft-ietf-cellar-ffv1-v4-03 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 April 21, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4 56 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 5 59 2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 5 60 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 6 61 2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 6 62 2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7 63 2.2.6. Order of Operation Precedence . . . . . . . . . . . . 7 64 2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 8 66 2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 8 67 3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.2. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 10 71 3.4. Context . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.5. Quantization Table Sets . . . . . . . . . . . . . . . . . 11 73 3.6. Quantization Table Set Indexes . . . . . . . . . . . . . 11 74 3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 11 75 3.7.1. YCbCr . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.8. Coding of the Sample Difference . . . . . . . . . . . . . 13 78 3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 14 79 3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 17 80 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 4.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 20 82 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 21 83 4.1.2. micro_version . . . . . . . . . . . . . . . . . . . . 22 84 4.1.3. coder_type . . . . . . . . . . . . . . . . . . . . . 23 85 4.1.4. state_transition_delta . . . . . . . . . . . . . . . 23 86 4.1.5. colorspace_type . . . . . . . . . . . . . . . . . . . 23 87 4.1.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 24 88 4.1.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 24 89 4.1.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 24 90 4.1.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 24 91 4.1.10. alpha_plane . . . . . . . . . . . . . . . . . . . . . 24 92 4.1.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 25 93 4.1.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 25 94 4.1.13. quant_table_set_count . . . . . . . . . . . . . . . . 25 95 4.1.14. states_coded . . . . . . . . . . . . . . . . . . . . 25 96 4.1.15. initial_state_delta . . . . . . . . . . . . . . . . . 25 97 4.1.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 4.1.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 26 99 4.2. Configuration Record . . . . . . . . . . . . . . . . . . 26 100 4.2.1. reserved_for_future_use . . . . . . . . . . . . . . . 26 101 4.2.2. configuration_record_crc_parity . . . . . . . . . . . 27 102 4.2.3. Mapping FFV1 into Containers . . . . . . . . . . . . 27 103 4.3. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 4.4. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 4.5. Slice Header . . . . . . . . . . . . . . . . . . . . . . 30 106 4.5.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 30 107 4.5.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 30 108 4.5.3. slice_width . . . . . . . . . . . . . . . . . . . . . 30 109 4.5.4. slice_height . . . . . . . . . . . . . . . . . . . . 30 110 4.5.5. quant_table_set_index_count . . . . . . . . . . . . . 31 111 4.5.6. quant_table_set_index . . . . . . . . . . . . . . . . 31 112 4.5.7. picture_structure . . . . . . . . . . . . . . . . . . 31 113 4.5.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 31 114 4.5.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 31 115 4.5.10. reset_contexts . . . . . . . . . . . . . . . . . . . 32 116 4.5.11. slice_coding_mode . . . . . . . . . . . . . . . . . . 32 117 4.6. Slice Content . . . . . . . . . . . . . . . . . . . . . . 32 118 4.6.1. primary_color_count . . . . . . . . . . . . . . . . . 32 119 4.6.2. plane_pixel_height . . . . . . . . . . . . . . . . . 33 120 4.6.3. slice_pixel_height . . . . . . . . . . . . . . . . . 33 121 4.6.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 33 122 4.7. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 33 123 4.7.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 33 124 4.7.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 34 125 4.7.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 34 126 4.7.4. sample_difference . . . . . . . . . . . . . . . . . . 34 127 4.8. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 34 128 4.8.1. slice_size . . . . . . . . . . . . . . . . . . . . . 34 129 4.8.2. error_status . . . . . . . . . . . . . . . . . . . . 34 130 4.8.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 35 131 4.9. Quantization Table Set . . . . . . . . . . . . . . . . . 35 132 4.9.1. quant_tables . . . . . . . . . . . . . . . . . . . . 36 133 4.9.2. context_count . . . . . . . . . . . . . . . . . . . . 36 134 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 36 135 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 136 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 37 137 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 138 9. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . 39 139 9.1. Decoder implementation suggestions . . . . . . . . . . . 39 140 9.1.1. Multi-threading Support and Independence of Slices . 39 141 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 40 142 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 143 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 144 11.2. Informative References . . . . . . . . . . . . . . . . . 41 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 148 1. Introduction 150 This document describes FFV1, a lossless video encoding format. The 151 design of FFV1 considers the storage of image characteristics, data 152 fixity, and the optimized use of encoding time and storage 153 requirements. FFV1 is designed to support a wide range of lossless 154 video applications such as long-term audiovisual preservation, 155 scientific imaging, screen recording, and other video encoding 156 scenarios that seek to avoid the generational loss of lossy video 157 encodings. 159 This document defines a version 4 of FFV1. Prior versions of FFV1 160 are defined within [I-D.ietf-cellar-ffv1]. 162 The latest version of this document is available at 163 165 This document assumes familiarity with mathematical and coding 166 concepts such as Range coding [range-coding] and YCbCr color spaces 167 [YCbCr]. 169 2. Notation and Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 2.1. Definitions 177 "Container": Format that encapsulates "Frames" (see Section 4.3) and 178 (when required) a "Configuration Record" into a bitstream. 180 "Sample": The smallest addressable representation of a color 181 component or a luma component in a "Frame". Examples of "Sample" are 182 Luma, Blue Chrominance, Red Chrominance, Alpha, Red, Green, and Blue. 184 "Plane": A discrete component of a static image comprised of 185 "Samples" that represent a specific quantification of "Samples" of 186 that image. 188 "Pixel": The smallest addressable representation of a color in a 189 "Frame". It is composed of 1 or more "Samples". 191 "ESC": An ESCape symbol to indicate that the symbol to be stored is 192 too large for normal storage and that an alternate storage method. 194 "MSB": Most Significant Bit, the bit that can cause the largest 195 change in magnitude of the symbol. 197 "RCT": Reversible Color Transform, a near linear, exactly reversible 198 integer transform that converts between RGB and YCbCr representations 199 of a "Pixel". 201 "VLC": Variable Length Code, a code that maps source symbols to a 202 variable number of bits. 204 "RGB": A reference to the method of storing the value of a "Pixel" by 205 using three numeric values that represent Red, Green, and Blue. 207 "YCbCr": A reference to the method of storing the value of a "Pixel" 208 by using three numeric values that represent the luma of the "Pixel" 209 (Y) and the chrominance of the "Pixel" (Cb and Cr). YCbCr word is 210 used for historical reasons and currently references any color space 211 relying on 1 luma "Sample" and 2 chrominance "Samples" e.g. YCbCr, 212 YCgCo or ICtCp. Exact meaning of the three numeric values is 213 unspecified. 215 "TBA": To Be Announced. Used in reference to the development of 216 future iterations of the FFV1 specification. 218 2.2. Conventions 220 2.2.1. Pseudo-code 222 The FFV1 bitstream is described in this document using pseudo-code. 223 Note that the pseudo-code is used for clarity in order to illustrate 224 the structure of FFV1 and not intended to specify any particular 225 implementation. The pseudo-code used is based upon the C programming 226 language [ISO.9899.1990] and uses its "if/else", "while" and "for" 227 functions as well as functions defined within this document. 229 2.2.2. Arithmetic Operators 231 Note: the operators and the order of precedence are the same as used 232 in the C programming language [ISO.9899.1990]. 234 "a + b" means a plus b. 236 "a - b" means a minus b. 238 "-a" means negation of a. 240 "a * b" means a multiplied by b. 242 "a / b" means a divided by b. 244 "a & b" means bit-wise "and" of a and b. 246 "a | b" means bit-wise "or" of a and b. 248 "a >> b" means arithmetic right shift of two's complement integer 249 representation of a by b binary digits. 251 "a << b" means arithmetic left shift of two's complement integer 252 representation of a by b binary digits. 254 2.2.3. Assignment Operators 256 "a = b" means a is assigned b. 258 "a++" is equivalent to a is assigned a + 1. 260 "a--" is equivalent to a is assigned a - 1. 262 "a += b" is equivalent to a is assigned a + b. 264 "a -= b" is equivalent to a is assigned a - b. 266 "a *= b" is equivalent to a is assigned a * b. 268 2.2.4. Comparison Operators 270 "a > b" means a is greater than b. 272 "a >= b" means a is greater than or equal to b. 274 "a < b" means a is less than b. 276 "a <= b" means a is less than or equal b. 278 "a == b" means a is equal to b. 280 "a != b" means a is not equal to b. 282 "a && b" means Boolean logical "and" of a and b. 284 "a || b" means Boolean logical "or" of a and b. 286 "!a" means Boolean logical "not" of a. 288 "a ? b : c" if a is true, then b, otherwise c. 290 2.2.5. Mathematical Functions 292 floor(a) the largest integer less than or equal to a 294 ceil(a) the smallest integer greater than or equal to a 296 sign(a) extracts the sign of a number, i.e. if a < 0 then -1, else if 297 a > 0 then 1, else 0 299 abs(a) the absolute value of a, i.e. abs(a) = sign(a)*a 301 log2(a) the base-two logarithm of a 303 min(a,b) the smallest of two values a and b 305 max(a,b) the largest of two values a and b 307 median(a,b,c) the numerical middle value in a data set of a, b, and 308 c, i.e. a+b+c-min(a,b,c)-max(a,b,c) 310 a_{b} the b-th value of a sequence of a 312 a_{b,c} the 'b,c'-th value of a sequence of a 314 2.2.6. Order of Operation Precedence 316 When order of precedence is not indicated explicitly by use of 317 parentheses, operations are evaluated in the following order (from 318 top to bottom, operations of same precedence being evaluated from 319 left to right). This order of operations is based on the order of 320 operations used in Standard C. 322 a++, a-- 323 !a, -a 324 a * b, a / b, a % b 325 a + b, a - b 326 a << b, a >> b 327 a < b, a <= b, a > b, a >= b 328 a == b, a != b 329 a & b 330 a | b 331 a && b 332 a || b 333 a ? b : c 334 a = b, a += b, a -= b, a *= b 336 2.2.7. Range 338 "a...b" means any value starting from a to b, inclusive. 340 2.2.8. NumBytes 342 "NumBytes" is a non-negative integer that expresses the size in 8-bit 343 octets of particular FFV1 "Configuration Record" or "Frame". FFV1 344 relies on its "Container" to store the "NumBytes" values, see 345 Section 4.2.3. 347 2.2.9. Bitstream Functions 349 2.2.9.1. remaining_bits_in_bitstream 351 "remaining_bits_in_bitstream( )" means the count of remaining bits 352 after the pointer in that "Configuration Record" or "Frame". It is 353 computed from the "NumBytes" value multiplied by 8 minus the count of 354 bits of that "Configuration Record" or "Frame" already read by the 355 bitstream parser. 357 2.2.9.2. byte_aligned 359 "byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes 360 )" is a multiple of 8, otherwise false. 362 2.2.9.3. get_bits 364 "get_bits( i )" is the action to read the next "i" bits in the 365 bitstream, from most significant bit to least significant bit, and to 366 return the corresponding value. The pointer is increased by "i". 368 3. Sample Coding 370 For each "Slice" (as described in Section 4.4) of a "Frame", the 371 "Planes", "Lines", and "Samples" are coded in an order determined by 372 the "Color Space" (see Section 3.7). Each "Sample" is predicted by 373 the median predictor as described in Section 3.3 from other "Samples" 374 within the same "Plane" and the difference is stored using the method 375 described in Section 3.8. 377 3.1. Border 379 A border is assumed for each coded "Slice" for the purpose of the 380 median predictor and context according to the following rules: 382 o one column of "Samples" to the left of the coded slice is assumed 383 as identical to the "Samples" of the leftmost column of the coded 384 slice shifted down by one row. The value of the topmost "Sample" 385 of the column of "Samples" to the left of the coded slice is 386 assumed to be "0" 388 o one column of "Samples" to the right of the coded slice is assumed 389 as identical to the "Samples" of the rightmost column of the coded 390 slice 392 o an additional column of "Samples" to the left of the coded slice 393 and two rows of "Samples" above the coded slice are assumed to be 394 "0" 396 The following table depicts a slice of 9 "Samples" 397 "a,b,c,d,e,f,g,h,i" in a 3x3 arrangement along with its assumed 398 border. 400 +---+---+---+---+---+---+---+---+ 401 | 0 | 0 | | 0 | 0 | 0 | | 0 | 402 +---+---+---+---+---+---+---+---+ 403 | 0 | 0 | | 0 | 0 | 0 | | 0 | 404 +---+---+---+---+---+---+---+---+ 405 | | | | | | | | | 406 +---+---+---+---+---+---+---+---+ 407 | 0 | 0 | | a | b | c | | c | 408 +---+---+---+---+---+---+---+---+ 409 | 0 | a | | d | e | f | | f | 410 +---+---+---+---+---+---+---+---+ 411 | 0 | d | | g | h | i | | i | 412 +---+---+---+---+---+---+---+---+ 414 3.2. Samples 416 Relative to any "Sample" "X", six other relatively positioned 417 "Samples" from the coded "Samples" and presumed border are identified 418 according to the labels used in the following diagram. The labels 419 for these relatively positioned "Samples" are used within the median 420 predictor and context. 422 +---+---+---+---+ 423 | | | T | | 424 +---+---+---+---+ 425 | |tl | t |tr | 426 +---+---+---+---+ 427 | L | l | X | | 428 +---+---+---+---+ 430 The labels for these relative "Samples" are made of the first letters 431 of the words Top, Left and Right. 433 3.3. Median Predictor 435 The prediction for any "Sample" value at position "X" may be computed 436 based upon the relative neighboring values of "l", "t", and "tl" via 437 this equation: 439 "median(l, t, l + t - tl)". 441 Note, this prediction template is also used in [ISO.14495-1.1999] and 442 [HuffYUV]. 444 Exception for the median predictor: if "colorspace_type == 0 && 445 bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 )", 446 the following median predictor MUST be used: 448 "median(left16s, top16s, left16s + top16s - diag16s)" 450 where: 452 left16s = l >= 32768 ? ( l - 65536 ) : l 453 top16s = t >= 32768 ? ( t - 65536 ) : t 454 diag16s = tl >= 32768 ? ( tl - 65536 ) : tl 456 Background: a two's complement signed 16-bit signed integer was used 457 for storing "Sample" values in all known implementations of FFV1 458 bitstream. So in some circumstances, the most significant bit was 459 wrongly interpreted (used as a sign bit instead of the 16th bit of an 460 unsigned integer). Note that when the issue is discovered, the only 461 configuration of all known implementations being impacted is 16-bit 462 YCbCr with no Pixel transformation with Range Coder coder, as other 463 potentially impacted configurations (e.g. 15/16-bit JPEG2000-RCT with 464 Range Coder coder, or 16-bit content with Golomb Rice coder) were 465 implemented nowhere [ISO.15444-1.2016]. In the meanwhile, 16-bit 466 JPEG2000-RCT with Range Coder coder was implemented without this 467 issue in one implementation and validated by one conformance checker. 468 It is expected (to be confirmed) to remove this exception for the 469 median predictor in the next version of the FFV1 bitstream. 471 3.4. Context 473 Relative to any "Sample" "X", the Quantized Sample Differences "L-l", 474 "l-tl", "tl-t", "T-t", and "t-tr" are used as context: 476 context = Q_{0}[l - tl] + 477 Q_{1}[tl - t] + 478 Q_{2}[t - tr] + 479 Q_{3}[L - l] + 480 Q_{4}[T - t] 482 If "context >= 0" then "context" is used and the difference between 483 the "Sample" and its predicted value is encoded as is, else 484 "-context" is used and the difference between the "Sample" and its 485 predicted value is encoded with a flipped sign. 487 3.5. Quantization Table Sets 489 The FFV1 bitstream contains 1 or more Quantization Table Sets. Each 490 Quantization Table Set contains exactly 5 Quantization Tables with 491 each Quantization Table corresponding to 1 of the 5 Quantized Sample 492 Differences. For each Quantization Table, both the number of 493 quantization steps and their distribution are stored in the FFV1 494 bitstream; each Quantization Table has exactly 256 entries, and the 8 495 least significant bits of the Quantized Sample Difference are used as 496 index: 498 Q_{j}[k] = quant_tables[i][j][k&255] 500 In this formula, "i" is the Quantization Table Set index, "j" is the 501 Quantized Table index, "k" the Quantized Sample Difference. 503 3.6. Quantization Table Set Indexes 505 For each "Plane" of each slice, a Quantization Table Set is selected 506 from an index: 508 o For Y "Plane", "quant_table_set_index [ 0 ]" index is used 510 o For Cb and Cr "Planes", "quant_table_set_index [ 1 ]" index is 511 used 513 o For Alpha "Plane", "quant_table_set_index [ (version <= 3 || 514 chroma_planes) ? 2 : 1 ]" index is used 516 Background: in first implementations of FFV1 bitstream, the index for 517 Cb and Cr "Planes" was stored even if it is not used (chroma_planes 518 set to 0), this index is kept for version <= 3 in order to keep 519 compatibility with FFV1 bitstreams in the wild. 521 3.7. Color spaces 523 FFV1 supports two color spaces: YCbCr and RGB. Both color spaces 524 allow an optional Alpha "Plane" that can be used to code transparency 525 data. 527 The FFV1 bitstream interleaves data in an order determined by the 528 color space. In YCbCr for each "Plane", each "Line" is coded from 529 top to bottom and for each "Line", each "Sample" is coded from left 530 to right. In JPEG2000-RCT for each "Line" from top to bottom, each 531 "Plane" is coded and for each "Plane", each "Sample" is encoded from 532 left to right. 534 3.7.1. YCbCr 536 In YCbCr color space, the Cb and Cr "Planes" are optional, but if 537 used then MUST be used together. Omitting the Cb and Cr "Planes" 538 codes the frames in grayscale without color data. An FFV1 "Frame" 539 using YCbCr MUST use one of the following arrangements: 541 o Y 543 o Y, Alpha 545 o Y, Cb, Cr 547 o Y, Cb, Cr, Alpha 549 The Y "Plane" MUST be coded first. If the Cb and Cr "Planes" are 550 used then they MUST be coded after the Y "Plane". If an Alpha 551 (transparency) "Plane" is used, then it MUST be coded last. 553 3.7.2. RGB 555 JPEG2000-RCT is a Reversible Color Transform that codes RGB (red, 556 green, blue) "Planes" losslessly in a modified YCbCr color space 557 [ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr 558 and RGB use the following formulae. 560 Cb=b-g 562 Cr=r-g 564 Y=g+(Cb+Cr)>>2 566 g=Y-(Cb+Cr)>>2 568 r=Cr+g 570 b=Cb+g 572 Exception for the JPEG2000-RCT conversion: if bits_per_raw_sample is 573 between 9 and 15 inclusive and alpha_plane is 0, the following 574 formulae for reversible conversions between YCbCr and RGB MUST be 575 used instead of the ones above: 577 Cb=g-b 578 Cr=r-b 580 Y=b+(Cb+Cr)>>2 582 b=Y-(Cb+Cr)>>2 584 r=Cr+b 586 g=Cb+b 588 Background: At the time of this writing, in all known implementations 589 of FFV1 bitstream, when bits_per_raw_sample was between 9 and 15 590 inclusive and alpha_plane is 0, GBR "Planes" were used as BGR 591 "Planes" during both encoding and decoding. In the meanwhile, 16-bit 592 JPEG2000-RCT was implemented without this issue in one implementation 593 and validated by one conformance checker. Methods to address this 594 exception for the transform are under consideration for the next 595 version of the FFV1 bitstream. 597 When FFV1 uses the JPEG2000-RCT, the horizontal "Lines" are 598 interleaved to improve caching efficiency since it is most likely 599 that the JPEG2000-RCT will immediately be converted to RGB during 600 decoding. The interleaved coding order is also Y, then Cb, then Cr, 601 and then if used Alpha. 603 As an example, a "Frame" that is two "Pixels" wide and two "Pixels" 604 high, could be comprised of the following structure: 606 +------------------------+------------------------+ 607 | Pixel[1,1] | Pixel[2,1] | 608 | Y[1,1] Cb[1,1] Cr[1,1] | Y[2,1] Cb[2,1] Cr[2,1] | 609 +------------------------+------------------------+ 610 | Pixel[1,2] | Pixel[2,2] | 611 | Y[1,2] Cb[1,2] Cr[1,2] | Y[2,2] Cb[2,2] Cr[2,2] | 612 +------------------------+------------------------+ 614 In JPEG2000-RCT, the coding order would be left to right and then top 615 to bottom, with values interleaved by "Lines" and stored in this 616 order: 618 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] 619 Cb[2,2] Cr[1,2] Cr[2,2] 621 3.8. Coding of the Sample Difference 623 Instead of coding the n+1 bits of the Sample Difference with Huffman 624 or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the 625 n (or n+1, in the case of JPEG2000-RCT) least significant bits are 626 used, since this is sufficient to recover the original "Sample". In 627 the equation below, the term "bits" represents bits_per_raw_sample+1 628 for JPEG2000-RCT or bits_per_raw_sample otherwise: 630 coder_input = 631 [(sample_difference + 2^(bits-1)) & (2^bits - 1)] - 2^(bits-1) 633 3.8.1. Range Coding Mode 635 Early experimental versions of FFV1 used the CABAC Arithmetic coder 636 from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain 637 patent/royalty situation, as well as its slightly worse performance, 638 CABAC was replaced by a Range coder based on an algorithm defined by 639 G. Nigel and N. Martin in 1979 [range-coding]. 641 3.8.1.1. Range Binary Values 643 To encode binary digits efficiently a Range coder is used. "C_{i}" 644 is the i-th Context. "B_{i}" is the i-th byte of the bytestream. 645 "b_{i}" is the i-th Range coded binary value, "S_{0,i}" is the i-th 646 initial state, which is 128. The length of the bytestream encoding n 647 binary symbols is "j_{n}" bytes. 649 r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 ) 651 S_{i+1,C_{i}} = zero_state_{S_{i,C_{i}}} XOR 652 l_i = L_i XOR 653 t_i = R_i - r_i <== 654 b_i = 0 <==> 655 L_i < R_i - r_i 657 S_{i+1,C_{i}} = one_state_{S_{i,C_{i}}} XOR 658 l_i = L_i - R_i + r_i XOR 659 t_i = r_i <== 660 b_i = 1 <==> 661 L_i >= R_i - r_i 663 S_{i+1,k} = S_{i,k} <== C_i != k 665 R_{i+1} = 2^8 * t_{i} XOR 666 L_{i+1} = 2^8 * l_{i} + B_{j_{i}} XOR 667 j_{i+1} = j_{i} + 1 <== 668 t_{i} < 2^8 670 R_{i+1} = t_{i} XOR 671 L_{i+1} = l_{i} XOR 672 j_{i+1} = j_{i} <== 673 t_{i} >= 2^8 674 R_{0} = 65280 676 L_{0} = 2^8 * B_{0} + B_{1} 678 j_{0} = 2 680 3.8.1.2. Range Non Binary Values 682 To encode scalar integers, it would be possible to encode each bit 683 separately and use the past bits as context. However that would mean 684 255 contexts per 8-bit symbol that is not only a waste of memory but 685 also requires more past data to reach a reasonably good estimate of 686 the probabilities. Alternatively assuming a Laplacian distribution 687 and only dealing with its variance and mean (as in Huffman coding) 688 would also be possible, however, for maximum flexibility and 689 simplicity, the chosen method uses a single symbol to encode if a 690 number is 0 and if not encodes the number using its exponent, 691 mantissa and sign. The exact contexts used are best described by the 692 following code, followed by some comments. 694 pseudo-code | type 695 --------------------------------------------------------------|----- 696 void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ | 697 is_signed) { | 698 int i; | 699 put_rac(c, state+0, !v); | 700 if (v) { | 701 int a= abs(v); | 702 int e= log2(a); | 703 | 704 for (i=0; i=0; i--) | 709 put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | 710 | 711 if (is_signed) | 712 put_rac(c, state+11 + min(e, 10), v < 0); //11..21| 713 } | 714 } | 716 3.8.1.3. Initial Values for the Context Model 718 At keyframes all Range coder state variables are set to their initial 719 state. 721 3.8.1.4. State Transition Table 723 one_state_{i} = 724 default_state_transition_{i} + state_transition_delta_{i} 726 zero_state_{i} = 256 - one_state_{256-i} 728 3.8.1.5. default_state_transition 730 0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27, 732 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42, 734 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57, 736 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 738 74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 740 89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103, 742 104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118, 744 119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133, 746 134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149, 748 150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164, 750 165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179, 752 180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194, 754 195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209, 756 210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225, 758 226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240, 760 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0, 762 3.8.1.6. Alternative State Transition Table 764 The alternative state transition table has been built using iterative 765 minimization of frame sizes and generally performs better than the 766 default. To use it, the coder_type (see Section 4.1.3) MUST be set 767 to 2 and the difference to the default MUST be stored in the 768 "Parameters", see Section 4.1. The reference implementation of FFV1 769 in FFmpeg uses this table by default at the time of this writing when 770 Range coding is used. 772 0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49, 774 59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39, 776 40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52, 778 53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69, 780 87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97, 782 85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98, 784 105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125, 786 115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129, 788 165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148, 790 147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160, 792 172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178, 794 175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196, 796 197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214, 798 209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225, 800 226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242, 802 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255, 804 3.8.2. Golomb Rice Mode 806 This coding mode uses Golomb Rice codes. The VLC is split into 2 807 parts, the prefix stores the most significant bits and the suffix 808 stores the k least significant bits or stores the whole number in the 809 ESC case. The end of the bitstream of the "Frame" is filled with 810 0-bits until that the bitstream contains a multiple of 8 bits. 812 3.8.2.1. Prefix 813 +----------------+-------+ 814 | bits | value | 815 +----------------+-------+ 816 | 1 | 0 | 817 | 01 | 1 | 818 | ... | ... | 819 | 0000 0000 0001 | 11 | 820 | 0000 0000 0000 | ESC | 821 +----------------+-------+ 823 3.8.2.2. Suffix 825 +-------+-----------------------------------------------------------+ 826 | non | the k least significant bits MSB first | 827 | ESC | | 828 | ESC | the value - 11, in MSB first order, ESC may only be used | 829 | | if the value cannot be coded as non ESC | 830 +-------+-----------------------------------------------------------+ 832 3.8.2.3. Examples 834 +-----+-------------------------+-------+ 835 | k | bits | value | 836 +-----+-------------------------+-------+ 837 | 0 | "1" | 0 | 838 | 0 | "001" | 2 | 839 | 2 | "1 00" | 0 | 840 | 2 | "1 10" | 2 | 841 | 2 | "01 01" | 5 | 842 | any | "000000000000 10000000" | 139 | 843 +-----+-------------------------+-------+ 845 3.8.2.4. Run Mode 847 Run mode is entered when the context is 0 and left as soon as a non-0 848 difference is found. The level is identical to the predicted one. 849 The run and the first different level are coded. 851 3.8.2.5. Run Length Coding 853 The run value is encoded in 2 parts, the prefix part stores the more 854 significant part of the run as well as adjusting the run_index that 855 determines the number of bits in the less significant part of the 856 run. The 2nd part of the value stores the less significant part of 857 the run as it is. The run_index is reset for each "Plane" and slice 858 to 0. 860 pseudo-code | type 861 --------------------------------------------------------------|----- 862 log2_run[41]={ | 863 0, 0, 0, 0, 1, 1, 1, 1, | 864 2, 2, 2, 2, 3, 3, 3, 3, | 865 4, 4, 5, 5, 6, 6, 7, 7, | 866 8, 9,10,11,12,13,14,15, | 867 16,17,18,19,20,21,22,23, | 868 24, | 869 }; | 870 | 871 if (run_count == 0 && run_mode == 1) { | 872 if (get_bits(1)) { | 873 run_count = 1 << log2_run[run_index]; | 874 if (x + run_count <= w) | 875 run_index++; | 876 } else { | 877 if (log2_run[run_index]) | 878 run_count = get_bits(log2_run[run_index]); | 879 else | 880 run_count = 0; | 881 if (run_index) | 882 run_index--; | 883 run_mode = 2; | 884 } | 885 } | 887 The log2_run function is also used within [ISO.14495-1.1999]. 889 3.8.2.6. Level Coding 891 Level coding is identical to the normal difference coding with the 892 exception that the 0 value is removed as it cannot occur: 894 if (diff>0) diff--; 895 encode(diff); 897 Note, this is different from JPEG-LS, which doesn't use prediction in 898 run mode and uses a different encoding and context model for the last 899 difference On a small set of test "Samples" the use of prediction 900 slightly improved the compression rate. 902 4. Bitstream 904 An FFV1 bitstream is composed of a series of 1 or more "Frames" and 905 (when required) a "Configuration Record". 907 Within the following sub-sections, pseudo-code is used to explain the 908 structure of each FFV1 bitstream component, as described in 909 Section 2.2.1. The following table lists symbols used to annotate 910 that pseudo-code in order to define the storage of the data 911 referenced in that line of pseudo-code. 913 +--------+----------------------------------------------------------+ 914 | Symbol | Definition | 915 +--------+----------------------------------------------------------+ 916 | u(n) | unsigned big endian integer using n bits | 917 | sg | Golomb Rice coded signed scalar symbol coded with the | 918 | | method described in Section 3.8.2 | 919 | br | Range coded Boolean (1-bit) symbol with the method | 920 | | described in Section 3.8.1.1 | 921 | ur | Range coded unsigned scalar symbol coded with the method | 922 | | described in Section 3.8.1.2 | 923 | sr | Range coded signed scalar symbol coded with the method | 924 | | described in Section 3.8.1.2 | 925 +--------+----------------------------------------------------------+ 927 The same context that is initialized to 128 is used for all fields in 928 the header. 930 The following MUST be provided by external means during 931 initialization of the decoder: 933 "frame_pixel_width" is defined as "Frame" width in "Pixels". 935 "frame_pixel_height" is defined as "Frame" height in "Pixels". 937 Default values at the decoder initialization phase: 939 "ConfigurationRecordIsPresent" is set to 0. 941 4.1. Parameters 943 The "Parameters" section contains significant characteristics about 944 the decoding configuration used for all instances of "Frame" (in FFV1 945 version 0 and 1) or the whole FFV1 bitstream (other versions), 946 including the stream version, color configuration, and quantization 947 tables. The pseudo-code below describes the contents of the 948 bitstream. 950 pseudo-code | type 951 --------------------------------------------------------------|----- 952 Parameters( ) { | 953 version | ur 954 if (version >= 3) | 955 micro_version | ur 956 coder_type | ur 957 if (coder_type > 1) | 958 for (i = 1; i < 256; i++) | 959 state_transition_delta[ i ] | sr 960 colorspace_type | ur 961 if (version >= 1) | 962 bits_per_raw_sample | ur 963 chroma_planes | br 964 log2_h_chroma_subsample | ur 965 log2_v_chroma_subsample | ur 966 alpha_plane | br 967 if (version >= 3) { | 968 num_h_slices - 1 | ur 969 num_v_slices - 1 | ur 970 quant_table_set_count | ur 971 } | 972 for( i = 0; i < quant_table_set_count; i++ ) | 973 QuantizationTableSet( i ) | 974 if (version >= 3) { | 975 for( i = 0; i < quant_table_set_count; i++ ) { | 976 states_coded | br 977 if (states_coded) | 978 for( j = 0; j < context_count[ i ]; j++ ) | 979 for( k = 0; k < CONTEXT_SIZE; k++ ) | 980 initial_state_delta[ i ][ j ][ k ] | sr 981 } | 982 ec | ur 983 intra | ur 984 } | 985 } | 987 4.1.1. version 989 "version" specifies the version of the FFV1 bitstream. 990 Each version is incompatible with others versions: decoders SHOULD 991 reject a file due to unknown version. 992 Decoders SHOULD reject a file with version <= 1 && 993 ConfigurationRecordIsPresent == 1. 994 Decoders SHOULD reject a file with version >= 3 && 995 ConfigurationRecordIsPresent == 0. 997 +-------+-------------------------+ 998 | value | version | 999 +-------+-------------------------+ 1000 | 0 | FFV1 version 0 | 1001 | 1 | FFV1 version 1 | 1002 | 2 | reserved* | 1003 | 3 | FFV1 version 3 | 1004 | 4 | FFV1 version 4 | 1005 | Other | reserved for future use | 1006 +-------+-------------------------+ 1008 * Version 2 was never enabled in the encoder thus version 2 files 1009 SHOULD NOT exist, and this document does not describe them to keep 1010 the text simpler. 1012 4.1.2. micro_version 1014 "micro_version" specifies the micro-version of the FFV1 bitstream. 1015 After a version is considered stable (a micro-version value is 1016 assigned to be the first stable variant of a specific version), each 1017 new micro-version after this first stable variant is compatible with 1018 the previous micro-version: decoders SHOULD NOT reject a file due to 1019 an unknown micro-version equal or above the micro-version considered 1020 as stable. 1022 Meaning of micro_version for version 3: 1024 +-------+-------------------------+ 1025 | value | micro_version | 1026 +-------+-------------------------+ 1027 | 0...3 | reserved* | 1028 | 4 | first stable variant | 1029 | Other | reserved for future use | 1030 +-------+-------------------------+ 1032 * development versions may be incompatible with the stable variants. 1034 Meaning of micro_version for version 4 (note: at the time of writing 1035 of this specification, version 4 is not considered stable so the 1036 first stable version value is to be announced in the future): 1038 +---------+-------------------------+ 1039 | value | micro_version | 1040 +---------+-------------------------+ 1041 | 0...TBA | reserved* | 1042 | TBA | first stable variant | 1043 | Other | reserved for future use | 1044 +---------+-------------------------+ 1046 * development versions which may be incompatible with the stable 1047 variants. 1049 4.1.3. coder_type 1051 "coder_type" specifies the coder used. 1053 +-------+-------------------------------------------------+ 1054 | value | coder used | 1055 +-------+-------------------------------------------------+ 1056 | 0 | Golomb Rice | 1057 | 1 | Range Coder with default state transition table | 1058 | 2 | Range Coder with custom state transition table | 1059 | Other | reserved for future use | 1060 +-------+-------------------------------------------------+ 1062 4.1.4. state_transition_delta 1064 "state_transition_delta" specifies the Range coder custom state 1065 transition table. 1066 If state_transition_delta is not present in the FFV1 bitstream, all 1067 Range coder custom state transition table elements are assumed to be 1068 0. 1070 4.1.5. colorspace_type 1072 "colorspace_type" specifies the color space losslessly encoded, the 1073 Pixel transformation used by the encoder, as well as interleave 1074 method. 1076 +-------+---------------------+------------------+------------------+ 1077 | value | color space | transformation | interleave | 1078 | | losslessly encoded | | method | 1079 +-------+---------------------+------------------+------------------+ 1080 | 0 | YCbCr | No Pixel | "Plane" then | 1081 | | | transformation | "Line" | 1082 | 1 | RGB | JPEG2000-RCT | "Line" then | 1083 | | | | "Plane" | 1084 | Other | reserved for future | reserved for | reserved for | 1085 | | use | future use | future use | 1086 +-------+---------------------+------------------+------------------+ 1088 Restrictions: 1089 If "colorspace_type" is 1, then "chroma_planes" MUST be 1, 1090 "log2_h_chroma_subsample" MUST be 0, and "log2_v_chroma_subsample" 1091 MUST be 0. 1093 4.1.6. chroma_planes 1095 "chroma_planes" indicates if chroma (color) "Planes" are present. 1097 +-------+---------------------------------+ 1098 | value | presence | 1099 +-------+---------------------------------+ 1100 | 0 | chroma "Planes" are not present | 1101 | 1 | chroma "Planes" are present | 1102 +-------+---------------------------------+ 1104 4.1.7. bits_per_raw_sample 1106 "bits_per_raw_sample" indicates the number of bits for each "Sample". 1107 Inferred to be 8 if not present. 1109 +-------+-----------------------------------+ 1110 | value | bits for each sample | 1111 +-------+-----------------------------------+ 1112 | 0 | reserved* | 1113 | Other | the actual bits for each "Sample" | 1114 +-------+-----------------------------------+ 1116 * Encoders MUST NOT store bits_per_raw_sample = 0 Decoders SHOULD 1117 accept and interpret bits_per_raw_sample = 0 as 8. 1119 4.1.8. log2_h_chroma_subsample 1121 "log2_h_chroma_subsample" indicates the subsample factor, stored in 1122 powers to which the number 2 must be raised, between luma and chroma 1123 width ("chroma_width = 2^(-log2_h_chroma_subsample) * luma_width"). 1125 4.1.9. log2_v_chroma_subsample 1127 "log2_v_chroma_subsample" indicates the subsample factor, stored in 1128 powers to which the number 2 must be raised, between luma and chroma 1129 height ("chroma_height=2^(-log2_v_chroma_subsample) * luma_height"). 1131 4.1.10. alpha_plane 1133 "alpha_plane" indicates if a transparency "Plane" is present. 1135 +-------+-------------------------------------+ 1136 | value | presence | 1137 +-------+-------------------------------------+ 1138 | 0 | transparency "Plane" is not present | 1139 | 1 | transparency "Plane" is present | 1140 +-------+-------------------------------------+ 1142 4.1.11. num_h_slices 1144 "num_h_slices" indicates the number of horizontal elements of the 1145 slice raster. 1146 Inferred to be 1 if not present. 1148 4.1.12. num_v_slices 1150 "num_v_slices" indicates the number of vertical elements of the slice 1151 raster. 1152 Inferred to be 1 if not present. 1154 4.1.13. quant_table_set_count 1156 "quant_table_set_count" indicates the number of Quantization 1157 Table Sets. 1158 Inferred to be 1 if not present. 1159 MUST NOT be 0. 1161 4.1.14. states_coded 1163 "states_coded" indicates if the respective Quantization Table Set has 1164 the initial states coded. 1165 Inferred to be 0 if not present. 1167 +-------+-----------------------------------------------------------+ 1168 | value | initial states | 1169 +-------+-----------------------------------------------------------+ 1170 | 0 | initial states are not present and are assumed to be all | 1171 | | 128 | 1172 | 1 | initial states are present | 1173 +-------+-----------------------------------------------------------+ 1175 4.1.15. initial_state_delta 1177 "initial_state_delta[ i ][ j ][ k ]" indicates the initial Range 1178 coder state, it is encoded using "k" as context index and 1180 pred = j ? initial_states[ i ][j - 1][ k ] : 128 1182 initial_state[ i ][ j ][ k ] = 1183 ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255 1185 4.1.16. ec 1187 "ec" indicates the error detection/correction type. 1189 +-------+--------------------------------------------+ 1190 | value | error detection/correction type | 1191 +-------+--------------------------------------------+ 1192 | 0 | 32-bit CRC on the global header | 1193 | 1 | 32-bit CRC per slice and the global header | 1194 | Other | reserved for future use | 1195 +-------+--------------------------------------------+ 1197 4.1.17. intra 1199 "intra" indicates the relationship between the instances of "Frame". 1200 Inferred to be 0 if not present. 1202 +-------+-----------------------------------------------------------+ 1203 | value | relationship | 1204 +-------+-----------------------------------------------------------+ 1205 | 0 | Frames are independent or dependent (keyframes and non | 1206 | | keyframes) | 1207 | 1 | Frames are independent (keyframes only) | 1208 | Other | reserved for future use | 1209 +-------+-----------------------------------------------------------+ 1211 4.2. Configuration Record 1213 In the case of a FFV1 bitstream with "version >= 3", a "Configuration 1214 Record" is stored in the underlying "Container", at the track header 1215 level. It contains the "Parameters" used for all instances of 1216 "Frame". The size of the "Configuration Record", "NumBytes", is 1217 supplied by the underlying "Container". 1219 pseudo-code | type 1220 --------------------------------------------------------------|----- 1221 ConfigurationRecord( NumBytes ) { | 1222 ConfigurationRecordIsPresent = 1 | 1223 Parameters( ) | 1224 while( remaining_bits_in_bitstream( NumBytes ) > 32 ) | 1225 reserved_for_future_use | u(1) 1226 configuration_record_crc_parity | u(32) 1227 } | 1229 4.2.1. reserved_for_future_use 1231 "reserved_for_future_use" has semantics that are reserved for future 1232 use. 1233 Encoders conforming to this version of this specification SHALL NOT 1234 write this value. 1235 Decoders conforming to this version of this specification SHALL 1236 ignore its value. 1238 4.2.2. configuration_record_crc_parity 1240 "configuration_record_crc_parity" 32 bits that are chosen so that the 1241 "Configuration Record" as a whole has a crc remainder of 0. 1242 This is equivalent to storing the crc remainder in the 32-bit parity. 1243 The CRC generator polynomial used is the standard IEEE CRC polynomial 1244 (0x104C11DB7) with initial value 0. 1246 4.2.3. Mapping FFV1 into Containers 1248 This "Configuration Record" can be placed in any file format 1249 supporting "Configuration Records", fitting as much as possible with 1250 how the file format uses to store "Configuration Records". The 1251 "Configuration Record" storage place and "NumBytes" are currently 1252 defined and supported by this version of this specification for the 1253 following formats: 1255 4.2.3.1. AVI File Format 1257 The "Configuration Record" extends the stream format chunk ("AVI ", 1258 "hdlr", "strl", "strf") with the ConfigurationRecord bitstream. 1259 See [AVI] for more information about chunks. 1261 "NumBytes" is defined as the size, in bytes, of the strf chunk 1262 indicated in the chunk header minus the size of the stream format 1263 structure. 1265 4.2.3.2. ISO Base Media File Format 1267 The "Configuration Record" extends the sample description box 1268 ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box 1269 that contains the ConfigurationRecord bitstream. See 1270 [ISO.14496-12.2015] for more information about boxes. 1272 "NumBytes" is defined as the size, in bytes, of the "glbl" box 1273 indicated in the box header minus the size of the box header. 1275 4.2.3.3. NUT File Format 1277 The codec_specific_data element (in "stream_header" packet) contains 1278 the ConfigurationRecord bitstream. See [NUT] for more information 1279 about elements. 1281 "NumBytes" is defined as the size, in bytes, of the 1282 codec_specific_data element as indicated in the "length" field of 1283 codec_specific_data 1285 4.2.3.4. Matroska File Format 1287 FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 1288 versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be 1289 used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" 1290 Element MUST contain the FFV1 "Configuration Record" structure and no 1291 other data. See [Matroska] for more information about elements. 1293 "NumBytes" is defined as the "Element Data Size" of the 1294 "CodecPrivate" Element. 1296 4.3. Frame 1298 A "Frame" is an encoded representation of a complete static image. 1299 The whole "Frame" is provided by the underlaying container. 1301 A "Frame" consists of the keyframe field, "Parameters" (if version 1302 <=1), and a sequence of independent slices. The pseudo-code below 1303 describes the contents of a "Frame". 1305 pseudo-code | type 1306 --------------------------------------------------------------|----- 1307 Frame( NumBytes ) { | 1308 keyframe | br 1309 if (keyframe && !ConfigurationRecordIsPresent | 1310 Parameters( ) | 1311 while ( remaining_bits_in_bitstream( NumBytes ) ) | 1312 Slice( ) | 1313 } | 1315 Architecture overview of slices in a "Frame": 1317 +-----------------------------------------------------------------+ 1318 | first slice header | 1319 | first slice content | 1320 | first slice footer | 1321 | --------------------------------------------------------------- | 1322 | second slice header | 1323 | second slice content | 1324 | second slice footer | 1325 | --------------------------------------------------------------- | 1326 | ... | 1327 | --------------------------------------------------------------- | 1328 | last slice header | 1329 | last slice content | 1330 | last slice footer | 1331 +-----------------------------------------------------------------+ 1333 4.4. Slice 1335 A "Slice" is an independent spatial sub-section of a "Frame" that is 1336 encoded separately from an other region of the same "Frame". The use 1337 of more than one "Slice" per "Frame" can be useful for taking 1338 advantage of the opportunities of multithreaded encoding and 1339 decoding. 1341 A "Slice" consists of a "Slice Header" (when relevant), a "Slice 1342 Content", and a "Slice Footer" (when relevant). The pseudo-code 1343 below describes the contents of a "Slice". 1345 pseudo-code | type 1346 --------------------------------------------------------------|----- 1347 Slice( ) { | 1348 if (version >= 3) | 1349 SliceHeader( ) | 1350 SliceContent( ) | 1351 if (coder_type == 0) | 1352 while (!byte_aligned()) | 1353 padding | u(1) 1354 if (version <= 1) { | 1355 while (remaining_bits_in_bitstream( NumBytes ) != 0 ) | 1356 reserved | u(1) 1357 } | 1358 if (version >= 3) | 1359 SliceFooter( ) | 1360 } | 1362 "padding" specifies a bit without any significance and used only for 1363 byte alignment. MUST be 0. 1365 "reserved" specifies a bit without any significance in this revision 1366 of the specification and may have a significance in a later revision 1367 of this specification. 1368 Encoders SHOULD NOT fill these bits. 1369 Decoders SHOULD ignore these bits. 1370 Note in case these bits are used in a later revision of this 1371 specification: any revision of this specification SHOULD care about 1372 avoiding to add 40 bits of content after "SliceContent" for version 0 1373 and 1 of the bitstream. Background: due to some non conforming 1374 encoders, some bitstreams where found with 40 extra bits 1375 corresponding to "error_status" and "slice_crc_parity", a decoder 1376 conforming to the revised specification could not do the difference 1377 between a revised bitstream and a buggy bitstream. 1379 4.5. Slice Header 1381 A "Slice Header" provides information about the decoding 1382 configuration of the "Slice", such as its spatial position, size, and 1383 aspect ratio. The pseudo-code below describes the contents of the 1384 "Slice Header". 1386 pseudo-code | type 1387 --------------------------------------------------------------|----- 1388 SliceHeader( ) { | 1389 slice_x | ur 1390 slice_y | ur 1391 slice_width - 1 | ur 1392 slice_height - 1 | ur 1393 for( i = 0; i < quant_table_set_index_count; i++ ) | 1394 quant_table_set_index [ i ] | ur 1395 picture_structure | ur 1396 sar_num | ur 1397 sar_den | ur 1398 if (version >= 4) { | 1399 reset_contexts | br 1400 slice_coding_mode | ur 1401 } | 1402 } | 1404 4.5.1. slice_x 1406 "slice_x" indicates the x position on the slice raster formed by 1407 num_h_slices. 1408 Inferred to be 0 if not present. 1410 4.5.2. slice_y 1412 "slice_y" indicates the y position on the slice raster formed by 1413 num_v_slices. 1414 Inferred to be 0 if not present. 1416 4.5.3. slice_width 1418 "slice_width" indicates the width on the slice raster formed by 1419 num_h_slices. 1420 Inferred to be 1 if not present. 1422 4.5.4. slice_height 1424 "slice_height" indicates the height on the slice raster formed by 1425 num_v_slices. 1426 Inferred to be 1 if not present. 1428 4.5.5. quant_table_set_index_count 1430 "quant_table_set_index_count" is defined as "1 + ( ( chroma_planes || 1431 version \<= 3 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 )". 1433 4.5.6. quant_table_set_index 1435 "quant_table_set_index" indicates the Quantization Table Set index to 1436 select the Quantization Table Set and the initial states for the 1437 slice. 1438 Inferred to be 0 if not present. 1440 4.5.7. picture_structure 1442 "picture_structure" specifies the temporal and spatial relationship 1443 of each "Line" of the "Frame". 1444 Inferred to be 0 if not present. 1446 +-------+-------------------------+ 1447 | value | picture structure used | 1448 +-------+-------------------------+ 1449 | 0 | unknown | 1450 | 1 | top field first | 1451 | 2 | bottom field first | 1452 | 3 | progressive | 1453 | Other | reserved for future use | 1454 +-------+-------------------------+ 1456 4.5.8. sar_num 1458 "sar_num" specifies the "Sample" aspect ratio numerator. 1459 Inferred to be 0 if not present. 1460 A value of 0 means that aspect ratio is unknown. 1461 Encoders MUST write 0 if "Sample" aspect ratio is unknown. 1462 If "sar_den" is 0, decoders SHOULD ignore the encoded value and 1463 consider that "sar_num" is 0. 1465 4.5.9. sar_den 1467 "sar_den" specifies the "Sample" aspect ratio denominator. 1468 Inferred to be 0 if not present. 1469 A value of 0 means that aspect ratio is unknown. 1470 Encoders MUST write 0 if "Sample" aspect ratio is unknown. 1471 If "sar_num" is 0, decoders SHOULD ignore the encoded value and 1472 consider that "sar_den" is 0. 1474 4.5.10. reset_contexts 1476 "reset_contexts" indicates if slice contexts must be reset. 1477 Inferred to be 0 if not present. 1479 4.5.11. slice_coding_mode 1481 "slice_coding_mode" indicates the slice coding mode. 1482 Inferred to be 0 if not present. 1484 +-------+-----------------------------+ 1485 | value | slice coding mode | 1486 +-------+-----------------------------+ 1487 | 0 | Range Coding or Golomb Rice | 1488 | 1 | raw PCM | 1489 | Other | reserved for future use | 1490 +-------+-----------------------------+ 1492 4.6. Slice Content 1494 A "Slice Content" contains all "Line" elements part of the "Slice". 1496 Depending on the configuration, "Line" elements are ordered by 1497 "Plane" then by row (YCbCr) or by row then by "Plane" (RGB). 1499 pseudo-code | type 1500 --------------------------------------------------------------|----- 1501 SliceContent( ) { | 1502 if (colorspace_type == 0) { | 1503 for( p = 0; p < primary_color_count; p++ ) | 1504 for( y = 0; y < plane_pixel_height[ p ]; y++ ) | 1505 Line( p, y ) | 1506 } else if (colorspace_type == 1) { | 1507 for( y = 0; y < slice_pixel_height; y++ ) | 1508 for( p = 0; p < primary_color_count; p++ ) | 1509 Line( p, y ) | 1510 } | 1511 } | 1513 4.6.1. primary_color_count 1515 "primary_color_count" is defined as "1 + ( chroma_planes ? 2 : 0 ) + 1516 ( alpha_plane ? 1 : 0 )". 1518 4.6.2. plane_pixel_height 1520 "plane_pixel_height[ p ]" is the height in pixels of plane p of the 1521 slice. 1522 "plane_pixel_height[ 0 ]" and "plane_pixel_height[ 1 + ( 1523 chroma_planes ? 2 : 0 ) ]" value is "slice_pixel_height". 1524 If "chroma_planes" is set to 1, "plane_pixel_height[ 1 ]" and 1525 "plane_pixel_height[ 2 ]" value is "ceil(slice_pixel_height / 1526 log2_v_chroma_subsample)". 1528 4.6.3. slice_pixel_height 1530 "slice_pixel_height" is the height in pixels of the slice. 1531 Its value is "floor(( slice_y + slice_height ) * slice_pixel_height / 1532 num_v_slices) - slice_pixel_y". 1534 4.6.4. slice_pixel_y 1536 "slice_pixel_y" is the slice vertical position in pixels. 1537 Its value is "floor(slice_y * frame_pixel_height / num_v_slices)". 1539 4.7. Line 1541 A "Line" is a list of the sample differences (relative to the 1542 predictor) of primary color components. The pseudo-code below 1543 describes the contents of the "Line". 1545 pseudo-code | type 1546 --------------------------------------------------------------|----- 1547 Line( p, y ) { | 1548 if (colorspace_type == 0) { | 1549 for( x = 0; x < plane_pixel_width[ p ]; x++ ) | 1550 sample_difference[ p ][ y ][ x ] | 1551 } else if (colorspace_type == 1) { | 1552 for( x = 0; x < slice_pixel_width; x++ ) | 1553 sample_difference[ p ][ y ][ x ] | 1554 } | 1555 } | 1557 4.7.1. plane_pixel_width 1559 "plane_pixel_width[ p ]" is the width in "Pixels" of "Plane" p of the 1560 slice. 1561 "plane_pixel_width[ 0 ]" and "plane_pixel_width[ 1 + ( chroma_planes 1562 ? 2 : 0 ) ]" value is "slice_pixel_width". 1563 If "chroma_planes" is set to 1, "plane_pixel_width[ 1 ]" and 1564 "plane_pixel_width[ 2 ]" value is "ceil(slice_pixel_width / (1 << 1565 log2_h_chroma_subsample))". 1567 4.7.2. slice_pixel_width 1569 "slice_pixel_width" is the width in "Pixels" of the slice. 1570 Its value is "floor(( slice_x + slice_width ) * slice_pixel_width / 1571 num_h_slices) - slice_pixel_x". 1573 4.7.3. slice_pixel_x 1575 "slice_pixel_x" is the slice horizontal position in "Pixels". 1576 Its value is "floor(slice_x * frame_pixel_width / num_h_slices)". 1578 4.7.4. sample_difference 1580 "sample_difference[ p ][ y ][ x ]" is the sample difference for 1581 "Sample" at "Plane" "p", y position "y", and x position "x". The 1582 "Sample" value is computed based on median predictor and context 1583 described in Section 3.2. 1585 4.8. Slice Footer 1587 A "Slice Footer" provides information about slice size and 1588 (optionally) parity. The pseudo-code below describes the contents of 1589 the "Slice Header". 1591 Note: "Slice Footer" is always byte aligned. 1593 pseudo-code | type 1594 --------------------------------------------------------------|----- 1595 SliceFooter( ) { | 1596 slice_size | u(24) 1597 if (ec) { | 1598 error_status | u(8) 1599 slice_crc_parity | u(32) 1600 } | 1601 } | 1603 4.8.1. slice_size 1605 "slice_size" indicates the size of the slice in bytes. 1606 Note: this allows finding the start of slices before previous slices 1607 have been fully decoded, and allows parallel decoding as well as 1608 error resilience. 1610 4.8.2. error_status 1612 "error_status" specifies the error status. 1614 +-------+--------------------------------------+ 1615 | value | error status | 1616 +-------+--------------------------------------+ 1617 | 0 | no error | 1618 | 1 | slice contains a correctable error | 1619 | 2 | slice contains a uncorrectable error | 1620 | Other | reserved for future use | 1621 +-------+--------------------------------------+ 1623 4.8.3. slice_crc_parity 1625 "slice_crc_parity" 32 bits that are chosen so that the slice as a 1626 whole has a crc remainder of 0. 1627 This is equivalent to storing the crc remainder in the 32-bit parity. 1628 The CRC generator polynomial used is the standard IEEE CRC polynomial 1629 (0x104C11DB7) with initial value 0. 1631 4.9. Quantization Table Set 1633 The Quantization Table Sets are stored by storing the number of equal 1634 entries -1 of the first half of the table (represented as "len - 1" 1635 in the pseudo-code below) using the method described in 1636 Section 3.8.1.2. The second half doesn't need to be stored as it is 1637 identical to the first with flipped sign. "scale" and "len_count[ i 1638 ][ j ]" are temporary values used for the computing of 1639 "context_count[ i ]" and are not used outside Quantization Table Set 1640 pseudo-code. 1642 example: 1644 Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0 1646 Stored values: 1, 3, 1 1648 pseudo-code | type 1649 --------------------------------------------------------------|----- 1650 QuantizationTableSet( i ) { | 1651 scale = 1 | 1652 for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { | 1653 QuantizationTable( i, j, scale ) | 1654 scale *= 2 * len_count[ i ][ j ] - 1 | 1655 } | 1656 context_count[ i ] = ceil ( scale / 2 ) | 1657 } | 1659 MAX_CONTEXT_INPUTS is 5. 1661 pseudo-code | type 1662 --------------------------------------------------------------|----- 1663 QuantizationTable(i, j, scale) { | 1664 v = 0 | 1665 for( k = 0; k < 128; ) { | 1666 len - 1 | ur 1667 for( a = 0; a < len; a++ ) { | 1668 quant_tables[ i ][ j ][ k ] = scale* v | 1669 k++ | 1670 } | 1671 v++ | 1672 } | 1673 for( k = 1; k < 128; k++ ) { | 1674 quant_tables[ i ][ j ][ 256 - k ] = \ | 1675 -quant_tables[ i ][ j ][ k ] | 1676 } | 1677 quant_tables[ i ][ j ][ 128 ] = \ | 1678 -quant_tables[ i ][ j ][ 127 ] | 1679 len_count[ i ][ j ] = v | 1680 } | 1682 4.9.1. quant_tables 1684 "quant_tables[ i ][ j ][ k ]" indicates the quantification table 1685 value of the Quantized Sample Difference "k" of the Quantization 1686 Table "j" of the Set Quantization Table Set "i". 1688 4.9.2. context_count 1690 "context_count[ i ]" indicates the count of contexts for Quantization 1691 Table Set "i". 1693 5. Restrictions 1695 To ensure that fast multithreaded decoding is possible, starting 1696 version 3 and if frame_pixel_width * frame_pixel_height is more than 1697 101376, slice_width * slice_height MUST be less or equal to 1698 num_h_slices * num_v_slices / 4. Note: 101376 is the frame size in 1699 "Pixels" of a 352x288 frame also known as CIF ("Common Intermediate 1700 Format") frame size format. 1702 For each "Frame", each position in the slice raster MUST be filled by 1703 one and only one slice of the "Frame" (no missing slice position, no 1704 slice overlapping). 1706 For each "Frame" with keyframe value of 0, each slice MUST have the 1707 same value of slice_x, slice_y, slice_width, slice_height as a slice 1708 in the previous "Frame", except if reset_contexts is 1. 1710 6. Security Considerations 1712 Like any other codec, (such as [RFC6716]), FFV1 should not be used 1713 with insecure ciphers or cipher-modes that are vulnerable to known 1714 plaintext attacks. Some of the header bits as well as the padding 1715 are easily predictable. 1717 Implementations of the FFV1 codec need to take appropriate security 1718 considerations into account, as outlined in [RFC4732]. It is 1719 extremely important for the decoder to be robust against malicious 1720 payloads. Malicious payloads must not cause the decoder to overrun 1721 its allocated memory or to take an excessive amount of resources to 1722 decode. Although problems in encoders are typically rarer, the same 1723 applies to the encoder. Malicious video streams must not cause the 1724 encoder to misbehave because this would allow an attacker to attack 1725 transcoding gateways. A frequent security problem in image and video 1726 codecs is also to not check for integer overflows in "Pixel" count 1727 computations, that is to allocate width * height without considering 1728 that the multiplication result may have overflowed the arithmetic 1729 types range. 1731 The reference implementation [REFIMPL] contains no known buffer 1732 overflow or cases where a specially crafted packet or video segment 1733 could cause a significant increase in CPU load. 1735 The reference implementation [REFIMPL] was validated in the following 1736 conditions: 1738 o Sending the decoder valid packets generated by the reference 1739 encoder and verifying that the decoder's output matches the 1740 encoder's input. 1742 o Sending the decoder packets generated by the reference encoder and 1743 then subjected to random corruption. 1745 o Sending the decoder random packets that are not FFV1. 1747 In all of the conditions above, the decoder and encoder was run 1748 inside the [VALGRIND] memory debugger as well as clangs address 1749 sanitizer [Address-Sanitizer], which track reads and writes to 1750 invalid memory regions as well as the use of uninitialized memory. 1751 There were no errors reported on any of the tested conditions. 1753 7. Media Type Definition 1755 This registration is done using the template defined in [RFC6838] and 1756 following [RFC4855]. 1758 Type name: video 1760 Subtype name: FFV1 1762 Required parameters: None. 1764 Optional parameters: 1766 This parameter is used to signal the capabilities of a receiver 1767 implementation. This parameter MUST NOT be used for any other 1768 purpose. 1770 version: The version of the FFV1 encoding as defined by 1771 Section 4.1.1. 1773 micro_version: The micro_version of the FFV1 encoding as defined by 1774 Section 4.1.2. 1776 coder_type: The coder_type of the FFV1 encoding as defined by 1777 Section 4.1.3. 1779 colorspace_type: The colorspace_type of the FFV1 encoding as defined 1780 by Section 4.1.5. 1782 bits_per_raw_sample: The version of the FFV1 encoding as defined by 1783 Section 4.1.7. 1785 max-slices: The value of max-slices is an integer indicating the 1786 maximum count of slices with a frames of the FFV1 encoding. 1788 Encoding considerations: 1790 This media type is defined for encapsulation in several audiovisual 1791 container formats and contains binary data; see Section 4.2.3. This 1792 media type is framed binary data Section 4.8 of [RFC4288]. 1794 Security considerations: 1796 See Section 6 of this document. 1798 Interoperability considerations: None. 1800 Published specification: 1802 [I-D.ietf-cellar-ffv1] and RFC XXXX. 1804 [RFC Editor: Upon publication as an RFC, please replace "XXXX" with 1805 the number assigned to this document and remove this note.] 1806 Applications which use this media type: 1808 Any application that requires the transport of lossless video can use 1809 this media type. Some examples are, but not limited to screen 1810 recording, scientific imaging, and digital video preservation. 1812 Fragment identifier considerations: N/A. 1814 Additional information: None. 1816 Person & email address to contact for further information: Michael 1817 Niedermayer 1819 Intended usage: COMMON 1821 Restrictions on usage: None. 1823 Author: Dave Rice 1825 Change controller: IETF cellar working group delegated from the IESG. 1827 8. IANA Considerations 1829 The IANA is requested to register the following values: 1831 o Media type registration as described in Section 7. 1833 9. Appendixes 1835 9.1. Decoder implementation suggestions 1837 9.1.1. Multi-threading Support and Independence of Slices 1839 The FFV1 bitstream is parsable in two ways: in sequential order as 1840 described in this document or with the pre-analysis of the footer of 1841 each slice. Each slice footer contains a slice_size field so the 1842 boundary of each slice is computable without having to parse the 1843 slice content. That allows multi-threading as well as independence 1844 of slice content (a bitstream error in a slice header or slice 1845 content has no impact on the decoding of the other slices). 1847 After having checked keyframe field, a decoder SHOULD parse 1848 slice_size fields, from slice_size of the last slice at the end of 1849 the "Frame" up to slice_size of the first slice at the beginning of 1850 the "Frame", before parsing slices, in order to have slices 1851 boundaries. A decoder MAY fallback on sequential order e.g. in case 1852 of a corrupted "Frame" (frame size unknown, slice_size of slices not 1853 coherent...) or if there is no possibility of seek into the stream. 1855 10. Changelog 1857 See 1859 11. References 1861 11.1. Normative References 1863 [I-D.ietf-cellar-ffv1] 1864 Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video 1865 Coding Format Version 0, 1, and 3", draft-ietf-cellar- 1866 ffv1-05 (work in progress), September 2018. 1868 [ISO.15444-1.2016] 1869 International Organization for Standardization, 1870 "Information technology -- JPEG 2000 image coding system: 1871 Core coding system", October 2016. 1873 [ISO.9899.1990] 1874 International Organization for Standardization, 1875 "Programming languages - C", ISO Standard 9899, 1990. 1877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1878 Requirement Levels", BCP 14, RFC 2119, 1879 DOI 10.17487/RFC2119, March 1997, 1880 . 1882 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1883 Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, 1884 December 2005, . 1886 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1887 Denial-of-Service Considerations", RFC 4732, 1888 DOI 10.17487/RFC4732, December 2006, 1889 . 1891 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1892 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1893 . 1895 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 1896 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 1897 September 2012, . 1899 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1900 Specifications and Registration Procedures", BCP 13, 1901 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1902 . 1904 11.2. Informative References 1906 [Address-Sanitizer] 1907 The Clang Team, "ASAN AddressSanitizer website", undated, 1908 . 1910 [AVI] Microsoft, "AVI RIFF File Reference", undated, 1911 . 1914 [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, 1915 . 1918 [ISO.14495-1.1999] 1919 International Organization for Standardization, 1920 "Information technology -- Lossless and near-lossless 1921 compression of continuous-tone still images: Baseline", 1922 December 1999. 1924 [ISO.14496-10.2014] 1925 International Organization for Standardization, 1926 "Information technology -- Coding of audio-visual objects 1927 -- Part 10: Advanced Video Coding", September 2014. 1929 [ISO.14496-12.2015] 1930 International Organization for Standardization, 1931 "Information technology -- Coding of audio-visual objects 1932 -- Part 12: ISO base media file format", December 2015. 1934 [Matroska] 1935 IETF, "Matroska", 2016, . 1938 [NUT] Niedermayer, M., "NUT Open Container Format", December 1939 2013, . 1941 [range-coding] 1942 Nigel, G. and N. Martin, "Range encoding: an algorithm for 1943 removing redundancy from a digitised message.", Proc. 1944 Institution of Electronic and Radio Engineers 1945 International Conference on Video and Data Recording , 1946 July 1979. 1948 [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the 1949 FFV1 codec in FFmpeg", undated, . 1951 [VALGRIND] 1952 Valgrind Developers, "Valgrind website", undated, 1953 . 1955 [YCbCr] Wikipedia, "YCbCr", undated, 1956 . 1958 Authors' Addresses 1960 Michael Niedermayer 1962 Email: michael@niedermayer.cc 1964 Dave Rice 1966 Email: dave@dericed.com 1968 Jerome Martinez 1970 Email: jerome@mediaarea.net