idnits 2.17.1 draft-niedermayer-cellar-ffv1-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 8, 2017) is 2664 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 cellar M. Niedermayer 3 Internet-Draft January 8, 2017 4 Intended status: Standards Track 5 Expires: July 12, 2017 7 FF Video Codec 1 8 draft-niedermayer-cellar-ffv1-01 10 Abstract 12 This document defines FFV1, a lossless intra-frame video encoding 13 format. FFV1 is designed to efficiently compress video data in a 14 variety of pixel formats. Compared to uncompressed video, FFV1 15 offers storage compression, frame fixity, and self-description, which 16 makes FFV1 useful as a preservation or intermediate video format. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 12, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4 54 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2.1. Arithmetic operators . . . . . . . . . . . . . . . . 4 57 2.2.2. Assignment operators . . . . . . . . . . . . . . . . 5 58 2.2.3. Comparison operators . . . . . . . . . . . . . . . . 5 59 2.2.4. Mathematical functions . . . . . . . . . . . . . . . 6 60 2.2.5. Order of operation precedence . . . . . . . . . . . . 6 61 2.2.6. Range . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2.7. NumBytes . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.8. Bitstream functions . . . . . . . . . . . . . . . . . 7 64 3. General Description . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2. Median predictor . . . . . . . . . . . . . . . . . . . . 8 67 3.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.4. Quantization . . . . . . . . . . . . . . . . . . . . . . 9 69 3.5. Colorspace . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.5.1. JPEG2000-RCT . . . . . . . . . . . . . . . . . . . . 9 71 3.6. Coding of the sample difference . . . . . . . . . . . . . 9 72 3.6.1. Range coding mode . . . . . . . . . . . . . . . . . . 10 73 3.6.2. Huffman coding mode . . . . . . . . . . . . . . . . . 13 74 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 4.1. Configuration Record . . . . . . . . . . . . . . . . . . 16 76 4.1.1. reserved_for_future_use . . . . . . . . . . . . . . . 17 77 4.1.2. configuration_record_crc_parity . . . . . . . . . . . 17 78 4.1.3. Mapping FFV1 into Containers . . . . . . . . . . . . 17 79 4.2. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.3. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 4.4. Slice Header . . . . . . . . . . . . . . . . . . . . . . 18 82 4.4.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 19 83 4.4.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 19 84 4.4.3. slice_width . . . . . . . . . . . . . . . . . . . . . 19 85 4.4.4. slice_height . . . . . . . . . . . . . . . . . . . . 19 86 4.4.5. quant_table_index_count . . . . . . . . . . . . . . . 19 87 4.4.6. quant_table_index . . . . . . . . . . . . . . . . . . 19 88 4.4.7. picture_structure . . . . . . . . . . . . . . . . . . 20 89 4.4.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 20 90 4.4.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 20 91 4.4.10. reset_contexts . . . . . . . . . . . . . . . . . . . 20 92 4.4.11. slice_coding_mode . . . . . . . . . . . . . . . . . . 20 93 4.5. Slice Content . . . . . . . . . . . . . . . . . . . . . . 20 94 4.5.1. primary_color_count . . . . . . . . . . . . . . . . . 21 95 4.5.2. plane_pixel_height . . . . . . . . . . . . . . . . . 21 96 4.5.3. slice_pixel_height . . . . . . . . . . . . . . . . . 21 97 4.5.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 21 99 4.6. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 4.6.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 22 101 4.6.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 22 102 4.6.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 22 103 4.7. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 22 104 4.7.1. slice_size . . . . . . . . . . . . . . . . . . . . . 23 105 4.7.2. error_status . . . . . . . . . . . . . . . . . . . . 23 106 4.7.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 23 107 4.8. Parameters . . . . . . . . . . . . . . . . . . . . . . . 23 108 4.8.1. version . . . . . . . . . . . . . . . . . . . . . . . 24 109 4.8.2. micro_version . . . . . . . . . . . . . . . . . . . . 25 110 4.8.3. coder_type . . . . . . . . . . . . . . . . . . . . . 26 111 4.8.4. state_transition_delta . . . . . . . . . . . . . . . 26 112 4.8.5. colorspace_type . . . . . . . . . . . . . . . . . . . 26 113 4.8.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 26 114 4.8.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 27 115 4.8.8. h_chroma_subsample . . . . . . . . . . . . . . . . . 27 116 4.8.9. v_chroma_subsample . . . . . . . . . . . . . . . . . 27 117 4.8.10. alpha_plane . . . . . . . . . . . . . . . . . . . . . 27 118 4.8.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 27 119 4.8.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 27 120 4.8.13. quant_table_count . . . . . . . . . . . . . . . . . . 28 121 4.8.14. states_coded . . . . . . . . . . . . . . . . . . . . 28 122 4.8.15. initial_state_delta . . . . . . . . . . . . . . . . . 28 123 4.8.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 28 124 4.8.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 28 125 4.9. Quantization Tables . . . . . . . . . . . . . . . . . . . 29 126 4.9.1. quant_tables . . . . . . . . . . . . . . . . . . . . 30 127 4.9.2. context_count . . . . . . . . . . . . . . . . . . . . 30 128 4.9.3. Restrictions . . . . . . . . . . . . . . . . . . . . 30 129 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 130 6. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . 31 131 6.1. Decoder implementation suggestions . . . . . . . . . . . 32 132 6.1.1. Multi-threading support and independence of slices . 32 133 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 32 134 8. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 135 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 33 136 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 137 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 138 10.2. Informative References . . . . . . . . . . . . . . . . . 33 139 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 141 1. Introduction 143 The FFV1 video codec is a simple and efficient lossless intra-frame 144 only codec. 146 The latest version of this document is available at 147 149 This document assumes familiarity with mathematical and coding 150 concepts such as Range coding and YCbCr colorspaces. 152 2. Notation and Conventions 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2.1. Definitions 160 "ESC": An ESCape symbol to indicate that the symbol to be stored is 161 too large for normal storage and that an alternate storage method. 163 "MSB": Most Significant Bit, the bit that can cause the largest 164 change in magnitude of the symbol. 166 "RCT": Reversible Color Transform, a near linear, exactly reversible 167 integer transform that converts between RGB and YCbCr representations 168 of a sample. 170 "VLC": Variable Length Code. 172 "RGB": A reference to the method of storing the value of a sample by 173 using three numeric values that represent Red, Green, and Blue. 175 "YCbCr": A reference to the method of storing the value of a sample 176 by using three numeric values that represent the luminance of the 177 sample (Y) and the chrominance of the sample (Cb and Cr). 179 "TBA": To Be Announced. Used in reference to the development of 180 future iterations of the FFV1 specification. 182 2.2. Conventions 184 Note: the operators and the order of precedence are the same as used 185 in the C programming language [ISO.9899.1990]. 187 2.2.1. Arithmetic operators 189 "a + b" means a plus b. 191 "a - b" means a minus b. 193 "-a" means negation of a. 195 "a * b" means a multiplied by b. 197 "a / b" means a divided by b. 199 "a & b" means bit-wise "and" of a and b. 201 "a | b" means bit-wise "or" of a and b. 203 "a >> b" means arithmetic right shift of two's complement integer 204 representation of a by b binary digits. 206 "a << b" means arithmetic left shift of two's complement integer 207 representation of a by b binary digits. 209 2.2.2. Assignment operators 211 "a = b" means a is assigned b. 213 "a++" is equivalent to a is assigned a + 1. 215 "a--" is equivalent to a is assigned a - 1. 217 "a += b" is equivalent to a is assigned a + b. 219 "a -= b" is equivalent to a is assigned a - b. 221 "a *= b" is equivalent to a is assigned a * b. 223 2.2.3. Comparison operators 225 "a > b" means a is greater than b. 227 "a >= b" means a is greater than or equal to b. 229 "a < b" means a is less than b. 231 "a <= b" means a is less than or equal b. 233 "a == b" means a is equal to b. 235 "a != b" means a is not equal to b. 237 "a && b" means Boolean logical "and" of a and b. 239 "a || b" means Boolean logical "or" of a and b. 241 "!a" means Boolean logical "not". 243 "a ? b : c" if a is true, then b, otherwise c. 245 2.2.4. Mathematical functions 247 \lfloor a \rfloor the largest integer less than or equal to a 249 \lceil a \rceil the smallest integer greater than or equal to a 251 abs(a) the absolute value of a, i.e. abs(a) = sign(a)*a 253 log2(a) the base-two logarithm of a 255 min(a,b) the smallest of two values a and b 257 2.2.5. Order of operation precedence 259 When order of precedence is not indicated explicitly by use of 260 parentheses, operations are evaluated in the following order (from 261 top to bottom, operations of same precedence being evaluated from 262 left to right). This order of operations is based on the order of 263 operations used in Standard C. 265 a++, a-- 266 !a, -a 267 a * b, a / b, a % b 268 a + b, a - b 269 a << b, a >> b 270 a < b, a <= b, a > b, a >= b 271 a == b, a != b 272 a & b 273 a | b 274 a && b 275 a || b 276 a ? b : c 277 a = b, a += b, a -= b, a *= b 279 2.2.6. Range 281 "a...b" means any value starting from a to b, inclusive. 283 2.2.7. NumBytes 285 NumBytes is a non-negative integer that expresses the size in 8-bit 286 octets of particular FFV1 components such as the Configuration Record 287 and Frame. FFV1 relies on its container to store the NumBytes 288 values, see Section 4.1.3. 290 2.2.8. Bitstream functions 292 2.2.8.1. remaining_bits_in_bitstream 294 "remaining_bits_in_bitstream( )" means the count of remaining bits 295 after the current position in that bitstream component. It is 296 computed from the NumBytes value multiplied by 8 minus the count of 297 bits of that component already read by the bitstream parser. 299 2.2.8.2. byte_aligned 301 "byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes 302 )" is a multiple of 8, otherwise false. 304 3. General Description 306 Each frame is split in 1 to 4 planes (Y, Cb, Cr, Alpha). In the case 307 of the normal YCbCr colorspace the Y plane is coded first followed by 308 the Cb and Cr planes, if an Alpha/transparency plane exists, it is 309 coded last. In the case of the JPEG2000-RCT colorspace the lines are 310 interleaved to improve caching efficiency since it is most likely 311 that the RCT will immediately be converted to RGB during decoding; 312 the interleaved coding order is also Y, Cb, Cr, Alpha. 314 Samples within a plane are coded in raster scan order (left->right, 315 top->bottom). Each sample is predicted by the median predictor from 316 samples in the same plane and the difference is stored see 317 Section 3.6. 319 3.1. Border 321 For the purpose of the predictor and context, samples above the coded 322 slice are assumed to be 0; samples to the right of the coded slice 323 are identical to the closest left sample; samples to the left of the 324 coded slice are identical to the top right sample (if there is one), 325 otherwise 0. 327 +---+---+---+---+---+---+---+---+ 328 | 0 | 0 | | 0 | 0 | 0 | | 0 | 329 | 0 | 0 | | 0 | 0 | 0 | | 0 | 330 | | | | | | | | | 331 | 0 | 0 | | a | b | c | | c | 332 | 0 | a | | d | | e | | e | 333 | 0 | d | | f | g | h | | h | 334 +---+---+---+---+---+---+---+---+ 336 3.2. Median predictor 338 median(left, top, left + top - diag) 340 left, top, diag are the left, top and left-top samples 342 Note, this is also used in [ISO.14495-1.1999] and [HuffYUV]. 344 Exception for the media predictor: if colorspace_type == 0 && 345 bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 ), 346 the following media predictor MUST be used: 348 median(left16s, top16s, left16s + top16s - diag16s) 350 with: - left16s = left >= 32768 ? ( left - 65536 ) : left - top16s = 351 top >= 32768 ? ( top - 65536 ) : top - diag16s = diag >= 32768 ? ( 352 diag - 65536 ) : diag 354 Background: a two's complement signed 16-bit signed integer was used 355 for storing pixel values in all known implementations of FFV1 356 bitstream. So in some circumstances, the most significant bit was 357 wrongly interpreted (used as a sign bit instead of the 16th bit of an 358 unsigned integer). Note that when the issue is discovered, the only 359 configuration of all known implementations being impacted is 16-bit 360 YCbCr color space with Range Coder coder, as other potentially 361 impacted configurations (e.g. 15/16-bit JPEG2000-RCT color space with 362 Range Coder coder, or 16-bit any color space with Golomb Rice coder) 363 were implemented nowhere. In the meanwhile, 16-bit JPEG2000-RCT 364 color space with Range Coder coder was implemented without this issue 365 in one implementation and validated by one conformance checker. It 366 is expected (to be confirmed) to remove this exception for the media 367 predictor in the next version of the bitstream. 369 3.3. Context 371 +---+---+---+---+ 372 | | | T | | 373 +---+---+---+---+ 374 | |tl | t |tr | 375 +---+---+---+---+ 376 | L | l | X | | 377 +---+---+---+---+ 379 The quantized sample differences L-l, l-tl, tl-t, t-T, t-tr are used 380 as context: 382 context=Q_{0}[l-tl]+\left|Q_{0}\right|(Q_{1}[tl-t]+\left|Q_{1}\right| 383 (Q_{2}[t-tr]+\left|Q_{2}\right|(Q_{3}[L-l]+\left|Q_{3}\right|Q_{4}[T- 384 t]))) 386 If the context is smaller than 0 then -context is used and the 387 difference between the sample and its predicted value is encoded with 388 a flipped sign. 390 3.4. Quantization 392 There are 5 quantization tables for the 5 sample differences, both 393 the number of quantization steps and their distribution are stored in 394 the bitstream. Each quantization table has exactly 256 entries, and 395 the 8 least significant bits of the sample difference are used as 396 index: 398 Q_{i}[a-b]=Table_{i}[(a-b)\&255] 400 3.5. Colorspace 402 3.5.1. JPEG2000-RCT 404 Cb=b-g 406 Cr=r-g 408 Y=g+(Cb+Cr)>>2 410 g=Y-(Cb+Cr)>>2 412 r=Cr+g 414 b=Cb+g 416 [ISO.15444-1.2016] 418 3.6. Coding of the sample difference 420 Instead of coding the n+1 bits of the sample difference with 421 Huffman-, or Range coding (or n+2 bits, in the case of RCT), only the 422 n (or n+1) least significant bits are used, since this is sufficient 423 to recover the original sample. In the equation below, the term 424 "bits" represents bits_per_raw_sample+1 for RCT or 425 bits_per_raw_sample otherwise: 427 coder\_input=\left[\left(sample\_difference+2^{bits- 428 1}\right)\&\left(2^{bits}-1\right)\right]-2^{bits-1} 430 3.6.1. Range coding mode 432 Early experimental versions of FFV1 used the CABAC Arithmetic coder 433 from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain 434 patent/royalty situation, as well as its slightly worse performance, 435 CABAC was replaced by a Range coder based on an algorithm defined by 436 _G. Nigel_ and _N. Martin_ in 1979 [range-coding]. 438 3.6.1.1. Range binary values 440 To encode binary digits efficiently a Range coder is used. $C_{i}$ is 441 the i-th Context. $B_{i}$ is the i-th byte of the bytestream. $b_{i}$ 442 is the i-th Range coded binary value, $S_{0,i}$ is the i-th initial 443 state, which is 128. The length of the bytestream encoding n binary 444 symbols is $j_{n}$ bytes. 446 r_{i}=\left\lfloor \frac{R_{i}S_{i,C_{i}}}{2^{8}}\right\rfloor 448 \begin{array}{ccccccccc} S_{i+1,C_{i}}=zero\_state_{S_{i,C_{i}}} & 449 \wedge & l{}_{i}=L_{i} & \wedge & t_{i}=R_{i}-r_{i} & \Longleftarrow 450 & b_{i}=0 & \Longleftrightarrow & L_{i}=0; i--) | 499 put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | 500 | 501 if (is_signed) | 502 put_rac(c, state+11 + min(e, 10), v < 0); //11..21| 503 } | 504 } | 506 3.6.1.3. Initial values for the context model 508 At keyframes all Range coder state variables are set to their initial 509 state. 511 3.6.1.4. State transition table 513 one\_state_{i}=default\_state\_transition_{i}+state\_transition\_delt 514 a_{i} 516 zero\_state_{i}=256-one\_state_{256-i} 518 3.6.1.5. default_state_transition 519 0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27, 521 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42, 523 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57, 525 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 527 74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 529 89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103, 531 104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118, 533 119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133, 535 134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149, 537 150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164, 539 165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179, 541 180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194, 543 195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209, 545 210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225, 547 226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240, 549 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0, 551 3.6.1.6. alternative state transition table 553 The alternative state transition table has been build using iterative 554 minimization of frame sizes and generally performs better than the 555 default. To use it, the coder_type MUST be set to 2 and the 556 difference to the default MUST be stored in the parameters. The 557 reference implementation of FFV1 in FFmpeg uses this table by default 558 at the time of this writing when Range coding is used. 560 0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49, 562 59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39, 564 40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52, 566 53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69, 568 87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97, 570 85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98, 572 105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125, 574 115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129, 576 165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148, 578 147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160, 580 172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178, 582 175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196, 584 197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214, 586 209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225, 588 226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242, 590 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255, 592 3.6.2. Huffman coding mode 594 This coding mode uses Golomb Rice codes. The VLC code is split into 595 2 parts, the prefix stores the most significant bits, the suffix 596 stores the k least significant bits or stores the whole number in the 597 ESC case. The end of the bitstream (of the frame) is filled with 598 0-bits until that the bitstream contains a multiple of 8 bits. 600 3.6.2.1. Prefix 601 +----------------+-------+ 602 | bits | value | 603 +----------------+-------+ 604 | 1 | 0 | 605 | 01 | 1 | 606 | ... | ... | 607 | 0000 0000 0001 | 11 | 608 | 0000 0000 0000 | ESC | 609 +----------------+-------+ 611 3.6.2.2. Suffix 613 +-------+-----------------------------------------------------------+ 614 | non | the k least significant bits MSB first | 615 | ESC | | 616 | ESC | the value - 11, in MSB first order, ESC may only be used | 617 | | if the value cannot be coded as non ESC | 618 +-------+-----------------------------------------------------------+ 620 3.6.2.3. Examples 622 +-----+-------------------------+-------+ 623 | k | bits | value | 624 +-----+-------------------------+-------+ 625 | 0 | "1" | 0 | 626 | 0 | "001" | 2 | 627 | 2 | "1 00" | 0 | 628 | 2 | "1 10" | 2 | 629 | 2 | "01 01" | 5 | 630 | any | "000000000000 10000000" | 139 | 631 +-----+-------------------------+-------+ 633 3.6.2.4. Run mode 635 Run mode is entered when the context is 0 and left as soon as a non-0 636 difference is found. The level is identical to the predicted one. 637 The run and the first different level is coded. 639 3.6.2.5. Run length coding 641 The run value is encoded in 2 parts, the prefix part stores the more 642 significant part of the run as well as adjusting the run_index which 643 determines the number of bits in the less significant part of the 644 run. The 2nd part of the value stores the less significant part of 645 the run as it is. The run_index is reset for each plane and slice to 646 0. 648 function | type 649 --------------------------------------------------------------|----- 650 log2_run[41]={ | 651 0, 0, 0, 0, 1, 1, 1, 1, | 652 2, 2, 2, 2, 3, 3, 3, 3, | 653 4, 4, 5, 5, 6, 6, 7, 7, | 654 8, 9,10,11,12,13,14,15, | 655 16,17,18,19,20,21,22,23, | 656 24, | 657 }; | 658 | 659 if (run_count == 0 && run_mode == 1) { | 660 if (get_bits1()) { | 661 run_count = 1 << log2_run[run_index]; | 662 if (x + run_count <= w) | 663 run_index++; | 664 } else { | 665 if (log2_run[run_index]) | 666 run_count = get_bits(log2_run[run_index]); | 667 else | 668 run_count = 0; | 669 if (run_index) | 670 run_index--; | 671 run_mode = 2; | 672 } | 673 } | 675 The log2_run function is also used within [ISO.14495-1.1999]. 677 3.6.2.6. Level coding 679 Level coding is identical to the normal difference coding with the 680 exception that the 0 value is removed as it cannot occur: 682 if (diff>0) diff--; 683 encode(diff); 685 Note, this is different from JPEG-LS, which doesn't use prediction in 686 run mode and uses a different encoding and context model for the last 687 difference On a small set of test samples the use of prediction 688 slightly improved the compression rate. 690 4. Bitstream 691 +--------+----------------------------------------------------------+ 692 | Symbol | Definition | 693 +--------+----------------------------------------------------------+ 694 | u(n) | unsigned big endian integer using n bits | 695 | sg | Golomb Rice coded signed scalar symbol coded with the | 696 | | method described in Section 3.6.2 | 697 | br | Range coded Boolean (1-bit) symbol with the method | 698 | | described in Section 3.6.1.1 | 699 | ur | Range coded unsigned scalar symbol coded with the method | 700 | | described in Section 3.6.1.2 | 701 | sr | Range coded signed scalar symbol coded with the method | 702 | | described in Section 3.6.1.2 | 703 +--------+----------------------------------------------------------+ 705 The same context which is initialized to 128 is used for all fields 706 in the header. 708 The following MUST be provided by external means during 709 initialization of the decoder: 711 "frame_pixel_width" is defined as frame width in pixels. 713 "frame_pixel_height" is defined as frame height in pixels. 715 Default values at the decoder initialization phase: 717 "ConfigurationRecordIsPresent" is set to 0. 719 4.1. Configuration Record 721 In the case of a bitstream with "version >= 3", a Configuration 722 Record is stored in the underlying container, at the track header 723 level. It contains the parameters used for all frames. The size of 724 the Configuration Record, NumBytes, is supplied by the underlying 725 container. 727 function | type 728 --------------------------------------------------------------|----- 729 ConfigurationRecord( NumBytes ) { | 730 ConfigurationRecordIsPresent = 1 | 731 Parameters( ) | 732 while( remaining_bits_in_bitstream( NumBytes ) > 32 ) | 733 reserved_for_future_use | u(1) 734 configuration_record_crc_parity | u(32) 735 } | 737 4.1.1. reserved_for_future_use 739 "reserved_for_future_use" has semantics that are reserved for future 740 use. Encoders conforming to this version of this specification 741 SHALL NOT write this value. Decoders conforming to this version of 742 this specification SHALL ignore its value. 744 4.1.2. configuration_record_crc_parity 746 "configuration_record_crc_parity" 32 bits that are chosen so that the 747 Configuration Record as a whole has a crc remainder of 0. This is 748 equivalent to storing the crc remainder in the 32-bit parity. The 749 CRC generator polynomial used is the standard IEEE CRC polynomial 750 (0x104C11DB7) with initial value 0. 752 4.1.3. Mapping FFV1 into Containers 754 This Configuration Record can be placed in any file format supporting 755 Configuration Records, fitting as much as possible with how the file 756 format uses to store Configuration Records. The Configuration Record 757 storage place and NumBytes are currently defined and supported by 758 this version of this specification for the following container 759 formats: 761 4.1.3.1. In AVI File Format 763 The Configuration Record extends the stream format chunk ("AVI ", 764 "hdlr", "strl", "strf") with the ConfigurationRecord bitstream. See 765 [AVI] for more information about chunks. 767 "NumBytes" is defined as the size, in bytes, of the strf chunk 768 indicated in the chunk header minus the size of the stream format 769 structure. 771 4.1.3.2. In ISO/IEC 14496-12 (MP4 File Format) 773 The Configuration Record extends the sample description box ("moov", 774 "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box which 775 contains the ConfigurationRecord bitstream. See [ISO.14496-12.2015] 776 for more information about boxes. 778 "NumBytes" is defined as the size, in bytes, of the "glbl" box 779 indicated in the box header minus the size of the box header. 781 4.1.3.3. In NUT File Format 783 The codec_specific_data element (in "stream_header" packet) contains 784 the ConfigurationRecord bitstream. See [NUT] for more information 785 about elements. 787 "NumBytes" is defined as the size, in bytes, of the 788 codec_specific_data element as indicated in the "length" field of 789 codec_specific_data 791 4.2. Frame 793 A frame consists of the keyframe field, parameters (if version <=1), 794 and a sequence of independent slices. 796 function | type 797 --------------------------------------------------------------|----- 798 Frame( NumBytes ) { | 799 keyframe | br 800 if (keyframe && !ConfigurationRecordIsPresent | 801 Parameters( ) | 802 while ( remaining_bits_in_bitstream( NumBytes ) ) | 803 Slice( ) | 804 } | 806 4.3. Slice 808 function | type 809 --------------------------------------------------------------|----- 810 Slice( ) { | 811 if (version >= 3) | 812 SliceHeader( ) | 813 SliceContent( ) | 814 if (coder_type == 0) | 815 while (!byte_aligned()) | 816 padding | u(1) 817 if (version >= 3) | 818 SliceFooter( ) | 819 } | 821 "padding" specifies a bit without any significance and used only for 822 byte alignment. MUST be 0. 824 4.4. Slice Header 825 function | type 826 --------------------------------------------------------------|----- 827 SliceHeader( ) { | 828 slice_x | ur 829 slice_y | ur 830 slice_width - 1 | ur 831 slice_height - 1 | ur 832 for( i = 0; i < quant_table_index_count; i++ ) | 833 quant_table_index [ i ] | ur 834 picture_structure | ur 835 sar_num | ur 836 sar_den | ur 837 if (version >= 4) { | 838 reset_contexts | br 839 slice_coding_mode | ur 840 } | 841 } | 843 4.4.1. slice_x 845 "slice_x" indicates the x position on the slice raster formed by 846 num_h_slices. Inferred to be 0 if not present. 848 4.4.2. slice_y 850 "slice_y" indicates the y position on the slice raster formed by 851 num_v_slices. Inferred to be 0 if not present. 853 4.4.3. slice_width 855 "slice_width" indicates the width on the slice raster formed by 856 num_h_slices. Inferred to be 1 if not present. 858 4.4.4. slice_height 860 "slice_height" indicates the height on the slice raster formed by 861 num_v_slices. Inferred to be 1 if not present. 863 4.4.5. quant_table_index_count 865 "quant_table_index_count" is defined as 1 + ( ( chroma_planes || 866 version <= 3 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ). 868 4.4.6. quant_table_index 870 "quant_table_index" indicates the index to select the quantization 871 table set and the initial states for the slice. Inferred to be 0 if 872 not present. 874 4.4.7. picture_structure 876 "picture_structure" specifies the picture structure. Inferred to be 877 0 if not present. 879 +-------+-------------------------+ 880 | value | picture structure used | 881 +-------+-------------------------+ 882 | 0 | unknown | 883 | 1 | top field first | 884 | 2 | bottom field first | 885 | 3 | progressive | 886 | Other | reserved for future use | 887 +-------+-------------------------+ 889 4.4.8. sar_num 891 "sar_num" specifies the sample aspect ratio numerator. Inferred to 892 be 0 if not present. MUST be 0 if sample aspect ratio is unknown. 894 4.4.9. sar_den 896 "sar_den" specifies the sample aspect ratio numerator. Inferred to 897 be 0 if not present. MUST be 0 if sample aspect ratio is unknown. 899 4.4.10. reset_contexts 901 "reset_contexts" indicates if slice contexts must be reset. Inferred 902 to be 0 if not present. 904 4.4.11. slice_coding_mode 906 "slice_coding_mode" indicates the slice coding mode. Inferred to be 907 0 if not present. 909 +-------+----------------------------+ 910 | value | slice coding mode | 911 +-------+----------------------------+ 912 | 0 | normal Range Coding or VLC | 913 | 1 | raw PCM | 914 | Other | reserved for future use | 915 +-------+----------------------------+ 917 4.5. Slice Content 918 function | type 919 --------------------------------------------------------------|----- 920 SliceContent( ) { | 921 if (colorspace_type == 0) { | 922 for( p = 0; p < primary_color_count; p++ ) { | 923 for( y = 0; y < plane_pixel_height[ p ]; y++ ) | 924 Line( p, y ) | 925 } else if (colorspace_type == 1) { | 926 for( y = 0; y < slice_pixel_height; y++ ) | 927 for( p = 0; p < primary_color_count; p++ ) { | 928 Line( p, y ) | 929 } | 930 } | 932 4.5.1. primary_color_count 934 "primary_color_count" is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( 935 alpha_plane ? 1 : 0 ). 937 4.5.2. plane_pixel_height 939 "plane_pixel_height[ p ]" is the height in pixels of plane p of the 940 slice. plane_pixel_height[ 0 ] and plane_pixel_height[ 1 + ( 941 chroma_planes ? 2 : 0 ) ] value is slice_pixel_height if 942 chroma_planes is set to 1, plane_pixel_height[ 1 ] and 943 plane_pixel_height[ 2 ] value is $\lceil slice_pixel_height / 944 v_chroma_subsample \rceil$ 946 4.5.3. slice_pixel_height 948 "slice_pixel_height" is the height in pixels of the slice. Its value 949 is $\lfloor ( slice_y + slice_height ) * slice_pixel_height / 950 num_v_slices \rfloor - slice_pixel_y$ 952 4.5.4. slice_pixel_y 954 "slice_pixel_y" is the slice vertical position in pixels. Its value 955 is $\lfloor slice_y * frame_pixel_height / num_v_slices \rfloor$ 957 4.6. Line 958 function | type 959 --------------------------------------------------------------|----- 960 Line( p, y ) { | 961 if (colorspace_type == 0) { | 962 for( x = 0; x < plane_pixel_width[ p ]; x++ ) | 963 Pixel( p, y, x ) | 964 } else if (colorspace_type == 1) { | 965 for( x = 0; x < slice_pixel_width; x++ ) | 966 Pixel( p, y, x ) | 967 } | 968 } | 970 4.6.1. plane_pixel_width 972 "plane_pixel_width[ p ]" is the width in pixels of plane p of the 973 slice. plane_pixel_width[ 0 ] and plane_pixel_width[ 1 + ( 974 chroma_planes ? 2 : 0 ) ] value is slice_pixel_width if chroma_planes 975 is set to 1, plane_pixel_width[ 1 ] and plane_pixel_width[ 2 ] value 976 is $\lceil slice_pixel_width / v_chroma_subsample \rceil$ 978 4.6.2. slice_pixel_width 980 "slice_pixel_width" is the width in pixels of the slice. Its value 981 is $\lfloor ( slice_x + slice_width ) * slice_pixel_width / 982 num_h_slices \rfloor - slice_pixel_x$ 984 4.6.3. slice_pixel_x 986 "slice_pixel_x" is the slice horizontal position in pixels. Its 987 value is $\lfloor slice_x * frame_pixel_width / num_h_slices \rfloor$ 989 4.7. Slice Footer 991 Note: slice footer is always byte aligned. 993 function | type 994 --------------------------------------------------------------|----- 995 SliceFooter( ) { | 996 slice_size | u(24) 997 if (ec) { | 998 error_status | u(8) 999 slice_crc_parity | u(32) 1000 } | 1001 } | 1003 4.7.1. slice_size 1005 "slice_size" indicates the size of the slice in bytes. Note: this 1006 allows finding the start of slices before previous slices have been 1007 fully decoded. And allows this way parallel decoding as well as 1008 error resilience. 1010 4.7.2. error_status 1012 "error_status" specifies the error status. 1014 +-------+--------------------------------------+ 1015 | value | error status | 1016 +-------+--------------------------------------+ 1017 | 0 | no error | 1018 | 1 | slice contains a correctable error | 1019 | 2 | slice contains a uncorrectable error | 1020 | Other | reserved for future use | 1021 +-------+--------------------------------------+ 1023 4.7.3. slice_crc_parity 1025 "slice_crc_parity" 32 bits that are chosen so that the slice as a 1026 whole has a crc remainder of 0. This is equivalent to storing the 1027 crc remainder in the 32-bit parity. The CRC generator polynomial 1028 used is the standard IEEE CRC polynomial (0x104C11DB7) with initial 1029 value 0. 1031 4.8. Parameters 1032 function | type 1033 --------------------------------------------------------------|----- 1034 Parameters( ) { | 1035 version | ur 1036 if (version >= 3) | 1037 micro_version | ur 1038 coder_type | ur 1039 if (coder_type > 1) | 1040 for (i = 1; i < 256; i++) | 1041 state_transition_delta[ i ] | sr 1042 colorspace_type | ur 1043 if (version >= 1) | 1044 bits_per_raw_sample | ur 1045 chroma_planes | br 1046 log2( h_chroma_subsample ) | ur 1047 log2( v_chroma_subsample ) | ur 1048 alpha_plane | br 1049 if (version >= 3) { | 1050 num_h_slices - 1 | ur 1051 num_v_slices - 1 | ur 1052 quant_table_count | ur 1053 } | 1054 for( i = 0; i < quant_table_count; i++ ) | 1055 QuantizationTable( i ) | 1056 if (version >= 3) { | 1057 for( i = 0; i < quant_table_count; i++ ) { | 1058 states_coded | br 1059 if (states_coded) | 1060 for( j = 0; j < context_count[ i ]; j++ ) | 1061 for( k = 0; k < CONTEXT_SIZE; k++ ) | 1062 initial_state_delta[ i ][ j ][ k ] | sr 1063 } | 1064 ec | ur 1065 intra | ur 1066 } | 1067 } | 1069 4.8.1. version 1071 "version" specifies the version of the bitstream. Each version is 1072 incompatible with others versions: decoders SHOULD reject a file due 1073 to unknown version. Decoders SHOULD reject a file with version =< 1 1074 && ConfigurationRecordIsPresent == 1. Decoders SHOULD reject a file 1075 with version >= 3 && ConfigurationRecordIsPresent == 0. 1077 +-------+-------------------------+ 1078 | value | version | 1079 +-------+-------------------------+ 1080 | 0 | FFV1 version 0 | 1081 | 1 | FFV1 version 1 | 1082 | 2 | reserved* | 1083 | 3 | FFV1 version 3 | 1084 | Other | reserved for future use | 1085 +-------+-------------------------+ 1087 * Version 2 was never enabled in the encoder thus version 2 files 1088 SHOULD NOT exist, and this document does not describe them to keep 1089 the text simpler. 1091 4.8.2. micro_version 1093 "micro_version" specifies the micro-version of the bitstream. After 1094 a version is considered stable (a micro-version value is assigned to 1095 be the first stable variant of a specific version), each new micro- 1096 version after this first stable variant is compatible with the 1097 previous micro-version: decoders SHOULD NOT reject a file due to an 1098 unknown micro-version equal or above the micro-version considered as 1099 stable. 1101 Meaning of micro_version for version 3: 1103 +-------+-------------------------+ 1104 | value | micro_version | 1105 +-------+-------------------------+ 1106 | 0...3 | reserved* | 1107 | 4 | first stable variant | 1108 | Other | reserved for future use | 1109 +-------+-------------------------+ 1111 * were development versions which may be incompatible with the stable 1112 variants. 1114 Meaning of micro_version for version 4 (note: at the time of writing 1115 of this specification, version 4 is not considered stable so the 1116 first stable version value is to be announced in the future): 1118 +---------+-------------------------+ 1119 | value | micro_version | 1120 +---------+-------------------------+ 1121 | 0...TBA | reserved* | 1122 | TBA | first stable variant | 1123 | Other | reserved for future use | 1124 +---------+-------------------------+ 1126 * were development versions which may be incompatible with the stable 1127 variants. 1129 4.8.3. coder_type 1131 "coder_type" specifies the coder used 1133 +-------+-------------------------------------------------+ 1134 | value | coder used | 1135 +-------+-------------------------------------------------+ 1136 | 0 | Golomb Rice | 1137 | 1 | Range Coder with default state transition table | 1138 | 2 | Range Coder with custom state transition table | 1139 | Other | reserved for future use | 1140 +-------+-------------------------------------------------+ 1142 4.8.4. state_transition_delta 1144 "state_transition_delta" specifies the Range coder custom state 1145 transition table. If state_transition_delta is not present in the 1146 bitstream, all Range coder custom state transition table elements are 1147 assumed to be 0. 1149 4.8.5. colorspace_type 1151 "colorspace_type" specifies the color space. 1153 +-------+-------------------------+ 1154 | value | color space used | 1155 +-------+-------------------------+ 1156 | 0 | YCbCr | 1157 | 1 | JPEG2000-RCT | 1158 | Other | reserved for future use | 1159 +-------+-------------------------+ 1161 4.8.6. chroma_planes 1163 "chroma_planes" indicates if chroma (color) planes are present. 1165 +-------+-------------------------------+ 1166 | value | color space used | 1167 +-------+-------------------------------+ 1168 | 0 | chroma planes are not present | 1169 | 1 | chroma planes are present | 1170 +-------+-------------------------------+ 1172 4.8.7. bits_per_raw_sample 1174 "bits_per_raw_sample" indicates the number of bits for each luma and 1175 chroma sample. Inferred to be 8 if not present. 1177 +-------+-------------------------------------------------+ 1178 | value | bits for each luma and chroma sample | 1179 +-------+-------------------------------------------------+ 1180 | 0 | reserved* | 1181 | Other | the actual bits for each luma and chroma sample | 1182 +-------+-------------------------------------------------+ 1184 * Encoders MUST NOT store bits_per_raw_sample = 0 Decoders SHOULD 1185 accept and interpret bits_per_raw_sample = 0 as 8. 1187 4.8.8. h_chroma_subsample 1189 "h_chroma_subsample" indicates the subsample factor between luma and 1190 chroma width ($chroma_width=2^{-log2_h_chroma_subsample}luma_width$) 1192 4.8.9. v_chroma_subsample 1194 "v_chroma_subsample" indicates the subsample factor between luma and 1195 chroma height 1196 ($chroma_height=2^{-log2_v_chroma_subsample}luma_height$) 1198 4.8.10. alpha_plane 1200 alpha_plane 1201 indicates if a transparency plane is present. 1203 +-------+-----------------------------------+ 1204 | value | color space used | 1205 +-------+-----------------------------------+ 1206 | 0 | transparency plane is not present | 1207 | 1 | transparency plane is present | 1208 +-------+-----------------------------------+ 1210 4.8.11. num_h_slices 1212 "num_h_slices" indicates the number of horizontal elements of the 1213 slice raster. Inferred to be 1 if not present. 1215 4.8.12. num_v_slices 1217 "num_v_slices" indicates the number of vertical elements of the slice 1218 raster. Inferred to be 1 if not present. 1220 4.8.13. quant_table_count 1222 "quant_table_count" indicates the number of quantization table sets. 1223 Inferred to be 1 if not present. 1225 4.8.14. states_coded 1227 "states_coded" indicates if the respective quantization table set has 1228 the initial states coded. Inferred to be 0 if not present. 1230 +-------+-----------------------------------------------------------+ 1231 | value | initial states | 1232 +-------+-----------------------------------------------------------+ 1233 | 0 | initial states are not present and are assumed to be all | 1234 | | 128 | 1235 | 1 | initial states are present | 1236 +-------+-----------------------------------------------------------+ 1238 4.8.15. initial_state_delta 1240 "initial_state_delta" [ i ][ j ][ k ] indicates the initial Range 1241 coder state, it is encoded using k as context index and pred = j ? 1242 initial_states[ i ][j - 1][ k ] : 128 initial_state[ i ][ j ][ k ] = 1243 ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255 1245 4.8.16. ec 1247 "ec" indicates the error detection/correction type. 1249 +-------+--------------------------------------------+ 1250 | value | error detection/correction type | 1251 +-------+--------------------------------------------+ 1252 | 0 | 32-bit CRC on the global header | 1253 | 1 | 32-bit CRC per slice and the global header | 1254 | Other | reserved for future use | 1255 +-------+--------------------------------------------+ 1257 4.8.17. intra 1259 "intra" indicates the relationship between frames. Inferred to be 0 1260 if not present. 1262 +-------+-----------------------------------------------------------+ 1263 | value | relationship | 1264 +-------+-----------------------------------------------------------+ 1265 | 0 | frames are independent or dependent (keyframes and non | 1266 | | keyframes) | 1267 | 1 | frames are independent (keyframes only) | 1268 | Other | reserved for future use | 1269 +-------+-----------------------------------------------------------+ 1271 4.9. Quantization Tables 1273 The quantization tables are stored by storing the number of equal 1274 entries -1 of the first half of the table using the method described 1275 in Section 3.6.1.2. The second half doesn't need to be stored as it 1276 is identical to the first with flipped sign. 1278 example: 1280 Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0 1282 Stored values: 1, 3, 1 1284 function | type 1285 --------------------------------------------------------------|----- 1286 QuantizationTable( i ) { | 1287 scale = 1 | 1288 for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { | 1289 QuantizationTablePerContext( i, j, scale ) | 1290 scale *= 2 * len_count[ i ][ j ] - 1 | 1291 } | 1292 context_count[ i ] = ( scale + 1 ) / 2 | 1293 } | 1295 MAX_CONTEXT_INPUTS is 5. 1297 function | type 1298 --------------------------------------------------------------|----- 1299 QuantizationTablePerContext(i, j, scale) { | 1300 v = 0 | 1301 for( k = 0; k < 128; ) { | 1302 len - 1 | sr 1303 for( a = 0; a < len; a++ ) { | 1304 quant_tables[ i ][ j ][ k ] = scale* v | 1305 k++ | 1306 } | 1307 v++ | 1308 } | 1309 for( k = 1; k < 128; k++ ) { | 1310 quant_tables[ i ][ j ][ 256 - k ] = \ | 1311 -quant_tables[ i ][ j ][ k ] | 1312 } | 1313 quant_tables[ i ][ j ][ 128 ] = \ | 1314 -quant_tables[ i ][ j ][ 127 ] | 1315 len_count[ i ][ j ] = v | 1316 } | 1318 4.9.1. quant_tables 1320 "quant_tables" indicates the quantification table values. 1322 4.9.2. context_count 1324 "context_count" indicates the count of contexts. 1326 4.9.3. Restrictions 1328 To ensure that fast multithreaded decoding is possible, starting 1329 version 3 and if frame_pixel_width * frame_pixel_height is more than 1330 101376, slice_width * slice_height MUST be less or equal to 1331 num_h_slices * num_v_slices / 4. Note: 101376 is the frame size in 1332 pixels of a 352x288 frame also known as CIF ("Common Intermediate 1333 Format") frame size format. 1335 For each frame, each position in the slice raster MUST be filled by 1336 one and only one slice of the frame (no missing slice position, no 1337 slice overlapping). 1339 For each Frame with keyframe value of 0, each slice MUST have the 1340 same value of slice_x, slice_y, slice_width, slice_height as a slice 1341 in the previous frame, except if reset_contexts is 1. 1343 5. Security Considerations 1345 Like any other codec, (such as [RFC6716]), FFV1 should not be used 1346 with insecure ciphers or cipher-modes that are vulnerable to known 1347 plaintext attacks. Some of the header bits as well as the padding 1348 are easily predictable. 1350 Implementations of the FFV1 codec need to take appropriate security 1351 considerations into account, as outlined in [RFC4732]. It is 1352 extremely important for the decoder to be robust against malicious 1353 payloads. Malicious payloads must not cause the decoder to overrun 1354 its allocated memory or to take an excessive amount of resources to 1355 decode. Although problems in encoders are typically rarer, the same 1356 applies to the encoder. Malicious video streams must not cause the 1357 encoder to misbehave because this would allow an attacker to attack 1358 transcoding gateways. A frequent security problem in image and video 1359 codecs is also to not check for integer overflows in pixel count 1360 computations, that is to allocate width * height without considering 1361 that the multiplication result may have overflowed the arithmetic 1362 types range. 1364 The reference implementation [REFIMPL] contains no known buffer 1365 overflow or cases where a specially crafted packet or video segment 1366 could cause a significant increase in CPU load. 1368 The reference implementation [REFIMPL] was validated in the following 1369 conditions: 1371 o Sending the decoder valid packets generated by the reference 1372 encoder and verifying that the decoder's output matches the 1373 encoders input. 1375 o Sending the decoder packets generated by the reference encoder and 1376 then subjected to random corruption. 1378 o Sending the decoder random packets that are not FFV1. 1380 In all of the conditions above, the decoder and encoder was run 1381 inside the [VALGRIND] memory debugger as well as clangs address 1382 sanitizer [Address-Sanitizer], which track reads and writes to 1383 invalid memory regions as well as the use of uninitialized memory. 1384 There were no errors reported on any of the tested conditions. 1386 6. Appendixes 1387 6.1. Decoder implementation suggestions 1389 6.1.1. Multi-threading support and independence of slices 1391 The bitstream is parsable in two ways: in sequential order as 1392 described in this document or with the pre-analysis of the footer of 1393 each slice. Each slice footer contains a slice_size field so the 1394 boundary of each slice is computable without having to parse the 1395 slice content. That allows multi-threading as well as independence 1396 of slice content (a bitstream error in a slice header or slice 1397 content has no impact on the decoding of the other slices). 1399 After having checked keyframe field, a decoder SHOULD parse 1400 slice_size fields, from slice_size of the last slice at the end of 1401 the frame up to slice_size of the first slice at the beginning of the 1402 frame, before parsing slices, in order to have slices boundaries. A 1403 decoder MAY fallback on sequential order e.g. in case of corrupted 1404 frame (frame size unknown, slice_size of slices not coherent...) or 1405 if there is no possibility of seek into the stream. 1407 Architecture overview of slices in a frame: 1409 +-----------------------------------------------------------------+ 1410 | first slice header | 1411 | first slice content | 1412 | first slice footer | 1413 | --------------------------------------------------------------- | 1414 | second slice header | 1415 | second slice content | 1416 | second slice footer | 1417 | --------------------------------------------------------------- | 1418 | ... | 1419 | --------------------------------------------------------------- | 1420 | last slice header | 1421 | last slice content | 1422 | last slice footer | 1423 +-----------------------------------------------------------------+ 1425 7. Changelog 1427 See 1429 8. ToDo 1431 o mean,k estimation for the Golomb Rice codes 1433 9. Copyright 1435 Copyright 2003-2013 Michael Niedermayer This text 1436 can be used under the GNU Free Documentation License or GNU General 1437 Public License. See . 1439 10. References 1441 10.1. Normative References 1443 [ISO.15444-1.2016] 1444 International Organization for Standardization, 1445 "Information technology -- JPEG 2000 image coding system: 1446 Core coding system", October 2016. 1448 [ISO.9899.1990] 1449 International Organization for Standardization, 1450 "Programming languages - C", ISO Standard 9899, 1990. 1452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1453 Requirement Levels", BCP 14, RFC 2119, 1454 DOI 10.17487/RFC2119, March 1997, 1455 . 1457 10.2. Informative References 1459 [Address-Sanitizer] 1460 The Clang Team, "ASAN AddressSanitizer website", undated, 1461 . 1463 [AVI] Microsoft, "AVI RIFF File Reference", undated, 1464 . 1467 [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003, 1468 . 1471 [ISO.14495-1.1999] 1472 International Organization for Standardization, 1473 "Information technology -- Lossless and near-lossless 1474 compression of continuous-tone still images: Baseline", 1475 December 1999. 1477 [ISO.14496-10.2014] 1478 International Organization for Standardization, 1479 "Information technology -- Coding of audio-visual objects 1480 -- Part 10: Advanced Video Coding", September 2014. 1482 [ISO.14496-12.2015] 1483 International Organization for Standardization, 1484 "Information technology -- Coding of audio-visual objects 1485 -- Part 12: ISO base media file format", December 2015. 1487 [NUT] Niedermayer, M., "NUT Open Container Format", December 1488 2013, . 1490 [range-coding] 1491 Nigel, G. and N. Martin, "Range encoding: an algorithm for 1492 removing redundancy from a digitised message.", Proc. 1493 Institution of Electronic and Radio Engineers 1494 International Conference on Video and Data Recording , 1495 July 1979. 1497 [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the 1498 FFV1 codec in FFmpeg", undated, . 1500 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1501 Denial-of-Service Considerations", RFC 4732, 1502 DOI 10.17487/RFC4732, December 2006, 1503 . 1505 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 1506 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 1507 September 2012, . 1509 [VALGRIND] 1510 Valgrind Developers, "Valgrind website", undated, 1511 . 1513 Author's Address 1515 Michael Niedermayer