idnits 2.17.1
draft-ietf-cellar-ffv1-19.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 (1 December 2020) is 1241 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '41' on line 1134
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 cellar M. Niedermayer
3 Internet-Draft
4 Intended status: Informational D. Rice
5 Expires: 4 June 2021
6 J. Martinez
7 1 December 2020
9 FFV1 Video Coding Format Version 0, 1, and 3
10 draft-ietf-cellar-ffv1-19
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 4 June 2021.
37 Copyright Notice
39 Copyright (c) 2020 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents (https://trustee.ietf.org/
44 license-info) in effect on the date of publication of this document.
45 Please review these documents carefully, as they describe your rights
46 and restrictions with respect to this document. Code Components
47 extracted from this document must include Simplified BSD License text
48 as described in Section 4.e of the Trust Legal Provisions and are
49 provided without warranty as described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
54 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 5
55 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
56 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
57 2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 6
58 2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6
59 2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 7
60 2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7
61 2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 8
62 2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8
63 2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 9
64 2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 9
65 2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 9
66 3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 10
67 3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 10
68 3.2. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 11
69 3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 11
70 3.3.1. Exception . . . . . . . . . . . . . . . . . . . . . . 12
71 3.4. Quantization Table Sets . . . . . . . . . . . . . . . . . 12
72 3.5. Context . . . . . . . . . . . . . . . . . . . . . . . . . 13
73 3.6. Quantization Table Set Indexes . . . . . . . . . . . . . 13
74 3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 13
75 3.7.1. YCbCr . . . . . . . . . . . . . . . . . . . . . . . . 14
76 3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 14
77 3.8. Coding of the Sample Difference . . . . . . . . . . . . . 16
78 3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 16
79 3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 23
80 4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 29
81 4.1. Quantization Table Set . . . . . . . . . . . . . . . . . 30
82 4.1.1. quant_tables . . . . . . . . . . . . . . . . . . . . 31
83 4.1.2. context_count . . . . . . . . . . . . . . . . . . . . 32
84 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 32
85 4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 34
86 4.2.2. micro_version . . . . . . . . . . . . . . . . . . . . 34
87 4.2.3. coder_type . . . . . . . . . . . . . . . . . . . . . 35
88 4.2.4. state_transition_delta . . . . . . . . . . . . . . . 35
89 4.2.5. colorspace_type . . . . . . . . . . . . . . . . . . . 36
90 4.2.6. chroma_planes . . . . . . . . . . . . . . . . . . . . 36
91 4.2.7. bits_per_raw_sample . . . . . . . . . . . . . . . . . 37
92 4.2.8. log2_h_chroma_subsample . . . . . . . . . . . . . . . 37
93 4.2.9. log2_v_chroma_subsample . . . . . . . . . . . . . . . 37
94 4.2.10. extra_plane . . . . . . . . . . . . . . . . . . . . . 37
95 4.2.11. num_h_slices . . . . . . . . . . . . . . . . . . . . 38
96 4.2.12. num_v_slices . . . . . . . . . . . . . . . . . . . . 38
97 4.2.13. quant_table_set_count . . . . . . . . . . . . . . . . 38
98 4.2.14. states_coded . . . . . . . . . . . . . . . . . . . . 38
99 4.2.15. initial_state_delta . . . . . . . . . . . . . . . . . 38
100 4.2.16. ec . . . . . . . . . . . . . . . . . . . . . . . . . 39
101 4.2.17. intra . . . . . . . . . . . . . . . . . . . . . . . . 39
102 4.3. Configuration Record . . . . . . . . . . . . . . . . . . 40
103 4.3.1. reserved_for_future_use . . . . . . . . . . . . . . . 40
104 4.3.2. configuration_record_crc_parity . . . . . . . . . . . 40
105 4.3.3. Mapping FFV1 into Containers . . . . . . . . . . . . 40
106 4.4. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 41
107 4.5. Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 43
108 4.6. Slice Header . . . . . . . . . . . . . . . . . . . . . . 44
109 4.6.1. slice_x . . . . . . . . . . . . . . . . . . . . . . . 45
110 4.6.2. slice_y . . . . . . . . . . . . . . . . . . . . . . . 45
111 4.6.3. slice_width . . . . . . . . . . . . . . . . . . . . . 45
112 4.6.4. slice_height . . . . . . . . . . . . . . . . . . . . 45
113 4.6.5. quant_table_set_index_count . . . . . . . . . . . . . 45
114 4.6.6. quant_table_set_index . . . . . . . . . . . . . . . . 46
115 4.6.7. picture_structure . . . . . . . . . . . . . . . . . . 46
116 4.6.8. sar_num . . . . . . . . . . . . . . . . . . . . . . . 46
117 4.6.9. sar_den . . . . . . . . . . . . . . . . . . . . . . . 47
118 4.7. Slice Content . . . . . . . . . . . . . . . . . . . . . . 47
119 4.7.1. primary_color_count . . . . . . . . . . . . . . . . . 47
120 4.7.2. plane_pixel_height . . . . . . . . . . . . . . . . . 47
121 4.7.3. slice_pixel_height . . . . . . . . . . . . . . . . . 48
122 4.7.4. slice_pixel_y . . . . . . . . . . . . . . . . . . . . 48
123 4.8. Line . . . . . . . . . . . . . . . . . . . . . . . . . . 48
124 4.8.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 48
125 4.8.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 49
126 4.8.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 49
127 4.8.4. sample_difference . . . . . . . . . . . . . . . . . . 49
128 4.9. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 49
129 4.9.1. slice_size . . . . . . . . . . . . . . . . . . . . . 50
130 4.9.2. error_status . . . . . . . . . . . . . . . . . . . . 50
131 4.9.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 50
132 5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 50
133 6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
134 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
135 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 51
136 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 53
137 9. Normative References . . . . . . . . . . . . . . . . . . . . 53
138 10. Informative References . . . . . . . . . . . . . . . . . . . 54
139 Appendix A. Multi-theaded decoder implementation suggestions . . 55
140 Appendix B. Future handling of some streams created by non
141 conforming encoders . . . . . . . . . . . . . . . . . . . 56
142 Appendix C. FFV1 Implementations . . . . . . . . . . . . . . . . 56
143 C.1. FFmpeg FFV1 Codec . . . . . . . . . . . . . . . . . . . . 56
144 C.2. FFV1 Decoder in Go . . . . . . . . . . . . . . . . . . . 57
145 C.3. MediaConch . . . . . . . . . . . . . . . . . . . . . . . 57
146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
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 version 0, 1 and 3 of FFV1. The distinctions
160 of the versions are provided throughout the document, but in summary:
162 * Version 0 of FFV1 was the original implementation of FFV1 and has
163 been flagged as stable on April 14, 2006 [FFV1_V0].
165 * Version 1 of FFV1 adds support of more video bit depths and has
166 been has been flagged as stable on April 24, 2009 [FFV1_V1].
168 * Version 2 of FFV1 only existed in experimental form and is not
169 described by this document, but is available as a LyX file at
170 https://github.com/FFmpeg/FFV1/
171 blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx
172 (https://github.com/FFmpeg/FFV1/
173 blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx).
175 * Version 3 of FFV1 adds several features such as increased
176 description of the characteristics of the encoding images and
177 embedded CRC data to support fixity verification of the encoding.
178 Version 3 has been flagged as stable on August 17, 2013 [FFV1_V3].
180 This document assumes familiarity with mathematical and coding
181 concepts such as Range coding [range-coding] and YCbCr color spaces
182 [YCbCr].
184 This specification describes the valid bitstream and how to decode
185 such valid bitstream. Bitstreams not conforming to this
186 specification or how they are handled is outside this specification.
187 A decoder could reject every invalid bitstream or attempt to perform
188 error concealment or re-download or use a redundant copy of the
189 invalid part or any other action it deems appropriate.
191 2. Notation and Conventions
193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
195 "OPTIONAL" in this document are to be interpreted as described in BCP
196 14 [RFC2119] [RFC8174] when, and only when, they appear in all
197 capitals, as shown here.
199 2.1. Definitions
201 "FFV1": choosen name of this video encoding format, short version of
202 "FF Video 1", the letters "FF" coming from "FFmpeg", the name of the
203 reference decoder, whose the first letters originaly means "Fast
204 Forward".
206 "Container": Format that encapsulates Frames (see Section 4.4) and
207 (when required) a "Configuration Record" into a bitstream.
209 "Sample": The smallest addressable representation of a color
210 component or a luma component in a Frame. Examples of Sample are
211 Luma (Y), Blue-difference Chroma (Cb), Red-difference Chroma (Cr),
212 Transparency, Red, Green, and Blue.
214 "Symbol": A value stored in the bitstream, which is defined and
215 decoded through one of the methods described in Table 4.
217 "Line": A discrete component of a static image composed of Samples
218 that represent a specific quantification of Samples of that image.
220 "Plane": A discrete component of a static image composed of Lines
221 that represent a specific quantification of Lines of that image.
223 "Pixel": The smallest addressable representation of a color in a
224 Frame. It is composed of one or more Samples.
226 "MSB": Most Significant Bit, the bit that can cause the largest
227 change in magnitude of the Symbol.
229 "VLC": Variable Length Code, a code that maps source symbols to a
230 variable number of bits.
232 "RGB": A reference to the method of storing the value of a Pixel by
233 using three numeric values that represent Red, Green, and Blue.
235 "YCbCr": A reference to the method of storing the value of a Pixel by
236 using three numeric values that represent the luma of the Pixel (Y)
237 and the chroma of the Pixel (Cb and Cr). YCbCr word is used for
238 historical reasons and currently references any color space relying
239 on 1 luma Sample and 2 chroma Samples, e.g. YCbCr, YCgCo or ICtCp.
240 The exact meaning of the three numeric values is unspecified.
242 2.2. Conventions
244 2.2.1. Pseudo-code
246 The FFV1 bitstream is described in this document using pseudo-code.
247 Note that the pseudo-code is used for clarity in order to illustrate
248 the structure of FFV1 and not intended to specify any particular
249 implementation. The pseudo-code used is based upon the C programming
250 language [ISO.9899.2018] and uses its "if/else", "while" and "for"
251 keywords as well as functions defined within this document.
253 In some instances, pseudo-code is presented in a two-column format
254 such as shown in Figure 1. In this form the "type" column provides a
255 Symbol as defined in Table 4 that defines the storage of the data
256 referenced in that same line of pseudo-code.
258 pseudo-code | type
259 --------------------------------------------------------------|-----
260 ExamplePseudoCode( ) { |
261 value | ur
262 } |
264 Figure 1: A depiction of type-labelled pseudo-code used within
265 this document.
267 2.2.2. Arithmetic Operators
269 Note: the operators and the order of precedence are the same as used
270 in the C programming language [ISO.9899.2018], with the exception of
271 ">>" (removal of implementation defined behavior) and "^" (power
272 instead of XOR) operators which are re-defined within this section.
274 "a + b" means a plus b.
276 "a - b" means a minus b.
278 "-a" means negation of a.
280 "a * b" means a multiplied by b.
282 "a / b" means a divided by b.
284 "a ^ b" means a raised to the b-th power.
286 "a & b" means bit-wise "and" of a and b.
288 "a | b" means bit-wise "or" of a and b.
290 "a >> b" means arithmetic right shift of two's complement integer
291 representation of a by b binary digits. This is equivalent to
292 dividing a by 2, b times, with rounding toward negative infinity.
294 "a << b" means arithmetic left shift of two's complement integer
295 representation of a by b binary digits.
297 2.2.3. Assignment Operators
299 "a = b" means a is assigned b.
301 "a++" is equivalent to a is assigned a + 1.
303 "a--" is equivalent to a is assigned a - 1.
305 "a += b" is equivalent to a is assigned a + b.
307 "a -= b" is equivalent to a is assigned a - b.
309 "a *= b" is equivalent to a is assigned a * b.
311 2.2.4. Comparison Operators
313 "a > b" is true when a is greater than b.
315 "a >= b" is true when a is greater than or equal to b.
317 "a < b" is true when a is less than b.
319 "a <= b" is true when a is less than or equal b.
321 "a == b" is true when a is equal to b.
323 "a != b" is true when a is not equal to b.
325 "a && b" is true when both a is true and b is true.
327 "a || b" is true when either a is true or b is true.
329 "!a" is true when a is not true.
331 "a ? b : c" if a is true, then b, otherwise c.
333 2.2.5. Mathematical Functions
335 "floor(a)" means the largest integer less than or equal to a.
337 "ceil(a)" means the smallest integer greater than or equal to a.
339 "sign(a)" extracts the sign of a number, i.e. if a < 0 then -1, else
340 if a > 0 then 1, else 0.
342 "abs(a)" means the absolute value of a, i.e. "abs(a)" = "sign(a) *
343 a".
345 "log2(a)" means the base-two logarithm of a.
347 "min(a,b)" means the smaller of two values a and b.
349 "max(a,b)" means the larger of two values a and b.
351 "median(a,b,c)" means the numerical middle value in a data set of a,
352 b, and c, i.e. a+b+c-min(a,b,c)-max(a,b,c).
354 "A <== B" means B implies A.
356 "A <==> B" means A <== B , B <== A.
358 a_(b) means the b-th value of a sequence of a
360 a_(b,c) means the 'b,c'-th value of a sequence of a
362 2.2.6. Order of Operation Precedence
364 When order of precedence is not indicated explicitly by use of
365 parentheses, operations are evaluated in the following order (from
366 top to bottom, operations of same precedence being evaluated from
367 left to right). This order of operations is based on the order of
368 operations used in Standard C.
370 a++, a--
371 !a, -a
372 a ^ b
373 a * b, a / b
374 a + b, a - b
375 a << b, a >> b
376 a < b, a <= b, a > b, a >= b
377 a == b, a != b
378 a & b
379 a | b
380 a && b
381 a || b
382 a ? b : c
383 a = b, a += b, a -= b, a *= b
385 2.2.7. Range
387 "a...b" means any value from a to b, inclusive.
389 2.2.8. NumBytes
391 "NumBytes" is a non-negative integer that expresses the size in 8-bit
392 octets of a particular FFV1 "Configuration Record" or "Frame". FFV1
393 relies on its Container to store the "NumBytes" values; see
394 Section 4.3.3.
396 2.2.9. Bitstream Functions
398 2.2.9.1. remaining_bits_in_bitstream
400 "remaining_bits_in_bitstream( NumBytes )" means the count of
401 remaining bits after the pointer in that "Configuration Record" or
402 "Frame". It is computed from the "NumBytes" value multiplied by 8
403 minus the count of bits of that "Configuration Record" or "Frame"
404 already read by the bitstream parser.
406 2.2.9.2. remaining_symbols_in_syntax
408 "remaining_symbols_in_syntax( )" is true as long as the RangeCoder
409 has not consumed all the given input bytes.
411 2.2.9.3. byte_aligned
413 "byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes
414 )" is a multiple of 8, otherwise false.
416 2.2.9.4. get_bits
418 "get_bits( i )" is the action to read the next "i" bits in the
419 bitstream, from most significant bit to least significant bit, and to
420 return the corresponding value. The pointer is increased by "i".
422 3. Sample Coding
424 For each "Slice" (as described in Section 4.5) of a Frame, the
425 Planes, Lines, and Samples are coded in an order determined by the
426 color space (see Section 3.7). Each Sample is predicted by the
427 median predictor as described in Section 3.3 from other Samples
428 within the same Plane and the difference is stored using the method
429 described in Section 3.8.
431 3.1. Border
433 A border is assumed for each coded "Slice" for the purpose of the
434 median predictor and context according to the following rules:
436 * one column of Samples to the left of the coded slice is assumed as
437 identical to the Samples of the leftmost column of the coded slice
438 shifted down by one row. The value of the topmost Sample of the
439 column of Samples to the left of the coded slice is assumed to be
440 "0"
442 * one column of Samples to the right of the coded slice is assumed
443 as identical to the Samples of the rightmost column of the coded
444 slice
446 * an additional column of Samples to the left of the coded slice and
447 two rows of Samples above the coded slice are assumed to be "0"
449 Figure 2 depicts a slice of 9 Samples "a,b,c,d,e,f,g,h,i" in a 3x3
450 arrangement along with its assumed border.
452 +---+---+---+---+---+---+---+---+
453 | 0 | 0 | | 0 | 0 | 0 | | 0 |
454 +---+---+---+---+---+---+---+---+
455 | 0 | 0 | | 0 | 0 | 0 | | 0 |
456 +---+---+---+---+---+---+---+---+
457 | | | | | | | | |
458 +---+---+---+---+---+---+---+---+
459 | 0 | 0 | | a | b | c | | c |
460 +---+---+---+---+---+---+---+---+
461 | 0 | a | | d | e | f | | f |
462 +---+---+---+---+---+---+---+---+
463 | 0 | d | | g | h | i | | i |
464 +---+---+---+---+---+---+---+---+
466 Figure 2: A depiction of FFV1's assumed border for a set example
467 Samples.
469 3.2. Samples
471 Relative to any Sample "X", six other relatively positioned Samples
472 from the coded Samples and presumed border are identified according
473 to the labels used in Figure 3. The labels for these relatively
474 positioned Samples are used within the median predictor and context.
476 +---+---+---+---+
477 | | | T | |
478 +---+---+---+---+
479 | |tl | t |tr |
480 +---+---+---+---+
481 | L | l | X | |
482 +---+---+---+---+
484 Figure 3: A depiction of how relatively positioned Samples are
485 referenced within this document.
487 The labels for these relative Samples are made of the first letters
488 of the words Top, Left and Right.
490 3.3. Median Predictor
492 The prediction for any Sample value at position "X" may be computed
493 based upon the relative neighboring values of "l", "t", and "tl" via
494 this equation:
496 median(l, t, l + t - tl)
498 Note, this prediction template is also used in [ISO.14495-1.1999] and
499 [HuffYUV].
501 3.3.1. Exception
503 If "colorspace_type == 0 && bits_per_raw_sample == 16 && ( coder_type
504 == 1 || coder_type == 2 )" (see Section 4.2.5, Section 4.2.7 and
505 Section 4.2.3), the following median predictor MUST be used:
507 median(left16s, top16s, left16s + top16s - diag16s)
509 where:
511 left16s = l >= 32768 ? ( l - 65536 ) : l
512 top16s = t >= 32768 ? ( t - 65536 ) : t
513 diag16s = tl >= 32768 ? ( tl - 65536 ) : tl
515 Background: a two's complement 16-bit signed integer was used for
516 storing Sample values in all known implementations of FFV1 bitstream
517 (see Appendix C). So in some circumstances, the most significant bit
518 was wrongly interpreted (used as a sign bit instead of the 16th bit
519 of an unsigned integer). Note that when the issue was discovered,
520 the only configuration of all known implementations being impacted is
521 16-bit YCbCr with no Pixel transformation with Range Coder coder, as
522 other potentially impacted configurations (e.g. 15/16-bit
523 JPEG2000-RCT with Range Coder coder, or 16-bit content with Golomb
524 Rice coder) were implemented nowhere [ISO.15444-1.2016]. In the
525 meanwhile, 16-bit JPEG2000-RCT with Range Coder coder was implemented
526 without this issue in one implementation and validated by one
527 conformance checker. It is expected (to be confirmed) to remove this
528 exception for the median predictor in the next version of the FFV1
529 bitstream.
531 3.4. Quantization Table Sets
533 Quantization Tables are used on Sample Differences (see Section 3.8),
534 so Quantized Sample Differences are stored in the bitstream.
536 The FFV1 bitstream contains one or more Quantization Table Sets.
537 Each Quantization Table Set contains exactly 5 Quantization Tables
538 with each Quantization Table corresponding to one of the five
539 Quantized Sample Differences. For each Quantization Table, both the
540 number of quantization steps and their distribution are stored in the
541 FFV1 bitstream; each Quantization Table has exactly 256 entries, and
542 the 8 least significant bits of the Quantized Sample Difference are
543 used as index:
545 Q_(j)[k] = quant_tables[i][j][k&255]
547 Figure 4
549 In this formula, "i" is the Quantization Table Set index, "j" is the
550 Quantized Table index, "k" the Quantized Sample Difference.
552 3.5. Context
554 Relative to any Sample "X", the Quantized Sample Differences "L-l",
555 "l-tl", "tl-t", "T-t", and "t-tr" are used as context:
557 context = Q_(0)[l - tl] +
558 Q_(1)[tl - t] +
559 Q_(2)[t - tr] +
560 Q_(3)[L - l] +
561 Q_(4)[T - t]
563 Figure 5
565 If "context >= 0" then "context" is used and the difference between
566 the Sample and its predicted value is encoded as is, else "-context"
567 is used and the difference between the Sample and its predicted value
568 is encoded with a flipped sign.
570 3.6. Quantization Table Set Indexes
572 For each Plane of each slice, a Quantization Table Set is selected
573 from an index:
575 * For Y Plane, "quant_table_set_index[ 0 ]" index is used
577 * For Cb and Cr Planes, "quant_table_set_index[ 1 ]" index is used
579 * For extra Plane, "quant_table_set_index[ (version <= 3 ||
580 chroma_planes) ? 2 : 1 ]" index is used
582 Background: in first implementations of FFV1 bitstream, the index for
583 Cb and Cr Planes was stored even if it is not used (chroma_planes set
584 to 0), this index is kept for "version" <= 3 in order to keep
585 compatibility with FFV1 bitstreams in the wild.
587 3.7. Color spaces
589 FFV1 supports several color spaces. The count of allowed coded
590 planes and the meaning of the extra Plane are determined by the
591 selected color space.
593 The FFV1 bitstream interleaves data in an order determined by the
594 color space. In YCbCr for each Plane, each Line is coded from top to
595 bottom and for each Line, each Sample is coded from left to right.
596 In JPEG2000-RCT for each Line from top to bottom, each Plane is coded
597 and for each Plane, each Sample is encoded from left to right.
599 3.7.1. YCbCr
601 This color space allows 1 to 4 Planes.
603 The Cb and Cr Planes are optional, but if used then MUST be used
604 together. Omitting the Cb and Cr Planes codes the frames in
605 grayscale without color data.
607 An optional transparency Plane can be used to code transparency data.
609 An FFV1 Frame using YCbCr MUST use one of the following arrangements:
611 * Y
613 * Y, Transparency
615 * Y, Cb, Cr
617 * Y, Cb, Cr, Transparency
619 The Y Plane MUST be coded first. If the Cb and Cr Planes are used
620 then they MUST be coded after the Y Plane. If a transparency Plane
621 is used, then it MUST be coded last.
623 3.7.2. RGB
625 This color space allows 3 or 4 Planes.
627 An optional transparency Plane can be used to code transparency data.
629 JPEG2000-RCT is a Reversible Color Transform that codes RGB (red,
630 green, blue) Planes losslessly in a modified YCbCr color space
631 [ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr
632 and RGB use the following formulae.
634 Cb = b - g
635 Cr = r - g
636 Y = g + (Cb + Cr) >> 2
638 Figure 6: Description of the transformation of pixels from RGB
639 color space to coded modified YCbCr color space.
641 g = Y - (Cb + Cr) >> 2
642 r = Cr + g
643 b = Cb + g
645 Figure 7: Description of the transformation of pixels from coded
646 modified YCbCr color space to RGB color space.
648 Cb and Cr are positively offset by "1 << bits_per_raw_sample" after
649 the conversion from RGB to the modified YCbCr and are negatively
650 offseted by the same value before the conversion from the modified
651 YCbCr to RGB, in order to have only non-negative values after the
652 conversion.
654 When FFV1 uses the JPEG2000-RCT, the horizontal Lines are interleaved
655 to improve caching efficiency since it is most likely that the
656 JPEG2000-RCT will immediately be converted to RGB during decoding.
657 The interleaved coding order is also Y, then Cb, then Cr, and then,
658 if used, transparency.
660 As an example, a Frame that is two Pixels wide and two Pixels high,
661 could comprise the following structure:
663 +------------------------+------------------------+
664 | Pixel(1,1) | Pixel(2,1) |
665 | Y(1,1) Cb(1,1) Cr(1,1) | Y(2,1) Cb(2,1) Cr(2,1) |
666 +------------------------+------------------------+
667 | Pixel(1,2) | Pixel(2,2) |
668 | Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) |
669 +------------------------+------------------------+
671 In JPEG2000-RCT, the coding order would be left to right and then top
672 to bottom, with values interleaved by Lines and stored in this order:
674 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)
675 Cb(2,2) Cr(1,2) Cr(2,2)
677 3.7.2.1. Exception
679 If "bits_per_raw_sample" is between 9 and 15 inclusive and
680 "extra_plane" is 0, the following formulae for reversible conversions
681 between YCbCr and RGB MUST be used instead of the ones above:
683 Cb = g - b
684 Cr = r - b
685 Y = b + (Cb + Cr) >> 2
686 Figure 8: Description of the transformation of pixels from RGB
687 color space to coded modified YCbCr color space (in case of
688 exception).
690 b = Y - (Cb + Cr) >> 2
691 r = Cr + b
692 g = Cb + b
694 Figure 9: Description of the transformation of pixels from coded
695 modified YCbCr color space to RGB color space (in case of
696 exception).
698 Background: At the time of this writing, in all known implementations
699 of FFV1 bitstream, when "bits_per_raw_sample" was between 9 and 15
700 inclusive and "extra_plane" is 0, GBR Planes were used as BGR Planes
701 during both encoding and decoding. In the meanwhile, 16-bit
702 JPEG2000-RCT was implemented without this issue in one implementation
703 and validated by one conformance checker. Methods to address this
704 exception for the transform are under consideration for the next
705 version of the FFV1 bitstream.
707 3.8. Coding of the Sample Difference
709 Instead of coding the n+1 bits of the Sample Difference with Huffman
710 or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the
711 n (or n+1, in the case of JPEG2000-RCT) least significant bits are
712 used, since this is sufficient to recover the original Sample. In
713 the equation below, the term "bits" represents "bits_per_raw_sample +
714 1" for JPEG2000-RCT or "bits_per_raw_sample" otherwise:
716 coder_input = ((sample_difference + 2 ^ (bits - 1)) &
717 (2 ^ bits - 1)) - 2 ^ (bits - 1)
719 Figure 10: Description of the coding of the Sample Difference in
720 the bitstream.
722 3.8.1. Range Coding Mode
724 Early experimental versions of FFV1 used the CABAC Arithmetic coder
725 from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain
726 patent/royalty situation, as well as its slightly worse performance,
727 CABAC was replaced by a Range coder based on an algorithm defined by
728 G. Nigel N. Martin in 1979 [range-coding].
730 3.8.1.1. Range Binary Values
732 To encode binary digits efficiently a Range coder is used. C_(i) is
733 the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) is
734 the i-th Range coded binary value, S_(0, i) is the i-th initial
735 state. The length of the bytestream encoding n binary symbols is
736 j_(n) bytes.
738 r_(i) = floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 )
740 Figure 11: A formula of the read of a binary value in Range
741 Binary mode.
743 S_(i + 1, C_(i)) = zero_state_(S_(i, C_(i))) AND
744 l_(i) = L_(i) AND
745 t_(i) = R_(i) - r_(i) <==
746 b_(i) = 0 <==>
747 L_(i) < R_(i) - r_(i)
749 S_(i + 1, C_(i)) = one_state_(S_(i, C_(i))) AND
750 l_(i) = L_(i) - R_(i) + r_(i) AND
751 t_(i) = r_(i) <==
752 b_(i) = 1 <==>
753 L_(i) >= R_(i) - r_(i)
755 Figure 12
757 S_(i + 1, k) = S_(i, k) <== C_(i) != k
759 Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if
760 the value of "k" is unequal to the i-th value of Context.
762 R_(i + 1) = 2 ^ 8 * t_(i) AND
763 L_(i + 1) = 2 ^ 8 * l_(i) + B_(j_(i)) AND
764 j_(i + 1) = j_(i) + 1 <==
765 t_(i) < 2 ^ 8
767 R_(i + 1) = t_(i) AND
768 L_(i + 1) = l_(i) AND
769 j_(i + 1) = j_(i) <==
770 t_(i) >= 2 ^ 8
772 Figure 14: The "i+1"-th values for "Range", "Low", and the length
773 of the bytestream encoding are conditionally set depending on the
774 "i-th" value of "t".
776 R_(0) = 65280
777 Figure 15: The initial value for "Range".
779 L_(0) = 2 ^ 8 * B_(0) + B_(1)
781 Figure 16: The initial value for "Low" is set according to the
782 first two bytes of the bytestream.
784 j_(0) = 2
786 Figure 17: The initial value for "j", the length of the
787 bytestream encoding.
789 range = 0xFF00;
790 end = 0;
791 low = get_bits(16);
792 if (low >= range) {
793 low = range;
794 end = 1;
795 }
797 Figure 18: A pseudo-code description of the initial states in
798 Range Binary mode.
800 refill() {
801 if (range < 256) {
802 range = range * 256;
803 low = low * 256;
804 if (!end) {
805 c.low += get_bits(8);
806 if (remaining_bits_in_bitstream( NumBytes ) == 0) {
807 end = 1;
808 }
809 }
810 }
811 }
813 Figure 19: A pseudo-code description of refilling the Range
814 Binary Value coder buffer.
816 get_rac(state) {
817 rangeoff = (range * state) / 256;
818 range -= rangeoff;
819 if (low < range) {
820 state = zero_state[state];
821 refill();
822 return 0;
823 } else {
824 low -= range;
825 state = one_state[state];
826 range = rangeoff;
827 refill();
828 return 1;
829 }
830 }
832 Figure 20: A pseudo-code description of the read of a binary
833 value in Range Binary mode.
835 3.8.1.1.1. Termination
837 The range coder can be used in three modes.
839 * In "Open mode" when decoding, every Symbol the reader attempts to
840 read is available. In this mode arbitrary data can have been
841 appended without affecting the range coder output. This mode is
842 not used in FFV1.
844 * In "Closed mode" the length in bytes of the bytestream is provided
845 to the range decoder. Bytes beyond the length are read as 0 by
846 the range decoder. This is generally one byte shorter than the
847 open mode.
849 * In "Sentinel mode" the exact length in bytes is not known and thus
850 the range decoder MAY read into the data that follows the range
851 coded bytestream by one byte. In "Sentinel mode", the end of the
852 range coded bytestream is a binary Symbol with state 129, which
853 value SHALL be discarded. After reading this Symbol, the range
854 decoder will have read one byte beyond the end of the range coded
855 bytestream. This way the byte position of the end can be
856 determined. Bytestreams written in "Sentinel mode" can be read in
857 "Closed mode" if the length can be determined, in this case the
858 last (sentinel) Symbol will be read non-corrupted and be of value
859 0.
861 Above describes the range decoding. Encoding is defined as any
862 process which produces a decodable bytestream.
864 There are three places where range coder termination is needed in
865 FFV1. First is in the "Configuration Record", in this case the size
866 of the range coded bytestream is known and handled as "Closed mode".
867 Second is the switch from the "Slice Header" which is range coded to
868 Golomb coded slices as "Sentinel mode". Third is the end of range
869 coded Slices which need to terminate before the CRC at their end.
870 This can be handled as "Sentinel mode" or as "Closed mode" if the CRC
871 position has been determined.
873 3.8.1.2. Range Non Binary Values
875 To encode scalar integers, it would be possible to encode each bit
876 separately and use the past bits as context. However that would mean
877 255 contexts per 8-bit Symbol that is not only a waste of memory but
878 also requires more past data to reach a reasonably good estimate of
879 the probabilities. Alternatively assuming a Laplacian distribution
880 and only dealing with its variance and mean (as in Huffman coding)
881 would also be possible, however, for maximum flexibility and
882 simplicity, the chosen method uses a single Symbol to encode if a
883 number is 0, and if not, encodes the number using its exponent,
884 mantissa and sign. The exact contexts used are best described by
885 Figure 21.
887 int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) {
888 if (get_rac(c, state + 0) {
889 return 0;
890 }
892 int e = 0;
893 while (get_rac(c, state + 1 + min(e, 9)) { //1..10
894 e++;
895 }
897 int a = 1;
898 for (int i = e - 1; i >= 0; i--) {
899 a = a * 2 + get_rac(c, state + 22 + min(i, 9)); // 22..31
900 }
902 if (!is_signed) {
903 return a;
904 }
906 if (get_rac(c, state + 11 + min(e, 10))) { //11..21
907 return -a;
908 } else {
909 return a;
910 }
911 }
912 Figure 21: A pseudo-code description of the contexts of Range Non
913 Binary Values.
915 "get_symbol" is used for the read out of "sample_difference"
916 indicated in Figure 10.
918 "get_rac" returns a boolean, computed from the bytestream as
919 described in Figure 11 as a formula and in Figure 20 as pseudo-code.
921 3.8.1.3. Initial Values for the Context Model
923 When "keyframe" (see Section 4.4) value is 1, all Range coder state
924 variables are set to their initial state.
926 3.8.1.4. State Transition Table
928 In this mode a State Transition Table is used, indicating in which
929 state the decoder will move to, based on the current state and the
930 value extracted from Figure 20.
932 one_state_(i) =
933 default_state_transition_(i) + state_transition_delta_(i)
935 Figure 22
937 zero_state_(i) = 256 - one_state_(256-i)
939 Figure 23
941 3.8.1.5. default_state_transition
943 By default, the following State Transition Table is used:
945 0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27,
947 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42,
949 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57,
951 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
953 74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
955 89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103,
957 104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118,
959 119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133,
961 134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,
963 150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164,
965 165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179,
967 180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194,
969 195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209,
971 210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225,
973 226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240,
975 241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0,
977 3.8.1.6. Alternative State Transition Table
979 The alternative state transition table has been built using iterative
980 minimization of frame sizes and generally performs better than the
981 default. To use it, the "coder_type" (see Section 4.2.3) MUST be set
982 to 2 and the difference to the default MUST be stored in the
983 "Parameters", see Section 4.2. The reference implementation of FFV1
984 in FFmpeg uses Figure 24 by default at the time of this writing when
985 Range coding is used.
987 0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49,
989 59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39,
991 40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52,
993 53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69,
995 87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97,
997 85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98,
999 105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125,
1001 115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129,
1003 165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148,
1005 147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160,
1007 172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178,
1009 175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196,
1011 197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214,
1013 209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225,
1015 226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242,
1017 241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255,
1019 Figure 24: Alternative state transition table for Range coding.
1021 3.8.2. Golomb Rice Mode
1023 The end of the bitstream of the Frame is padded with 0-bits until the
1024 bitstream contains a multiple of 8 bits.
1026 3.8.2.1. Signed Golomb Rice Codes
1028 This coding mode uses Golomb Rice codes. The VLC is split into two
1029 parts. The prefix stores the most significant bits and the suffix
1030 stores the k least significant bits or stores the whole number in the
1031 ESC case.
1033 int get_ur_golomb(k) {
1034 for (prefix = 0; prefix < 12; prefix++) {
1035 if (get_bits(1)) {
1036 return get_bits(k) + (prefix << k);
1037 }
1038 }
1039 return get_bits(bits) + 11;
1040 }
1042 Figure 25: A pseudo-code description of the read of an unsigned
1043 integer in Golomb Rice mode.
1045 int get_sr_golomb(k) {
1046 v = get_ur_golomb(k);
1047 if (v & 1) return - (v >> 1) - 1;
1048 else return (v >> 1);
1049 }
1051 Figure 26: A pseudo-code description of the read of a signed
1052 integer in Golomb Rice mode.
1054 3.8.2.1.1. Prefix
1056 +================+=======+
1057 | bits | value |
1058 +================+=======+
1059 | 1 | 0 |
1060 +----------------+-------+
1061 | 01 | 1 |
1062 +----------------+-------+
1063 | ... | ... |
1064 +----------------+-------+
1065 | 0000 0000 01 | 9 |
1066 +----------------+-------+
1067 | 0000 0000 001 | 10 |
1068 +----------------+-------+
1069 | 0000 0000 0001 | 11 |
1070 +----------------+-------+
1071 | 0000 0000 0000 | ESC |
1072 +----------------+-------+
1074 Table 1
1076 "ESC" is an ESCape Symbol to indicate that the Symbol to be stored is
1077 too large for normal storage and that an alternate storage method is
1078 used.
1080 3.8.2.1.2. Suffix
1082 +=========+========================================+
1083 +=========+========================================+
1084 | non ESC | the k least significant bits MSB first |
1085 +---------+----------------------------------------+
1086 | ESC | the value - 11, in MSB first order |
1087 +---------+----------------------------------------+
1089 Table 2
1091 ESC MUST NOT be used if the value can be coded as non ESC.
1093 3.8.2.1.3. Examples
1095 Table 3 shows practical examples of how Signed Golomb Rice Codes are
1096 decoded based on the series of bits extracted from the bitstream as
1097 described by the method above:
1099 +=====+=======================+=======+
1100 | k | bits | value |
1101 +=====+=======================+=======+
1102 | 0 | 1 | 0 |
1103 +-----+-----------------------+-------+
1104 | 0 | 001 | 2 |
1105 +-----+-----------------------+-------+
1106 | 2 | 1 00 | 0 |
1107 +-----+-----------------------+-------+
1108 | 2 | 1 10 | 2 |
1109 +-----+-----------------------+-------+
1110 | 2 | 01 01 | 5 |
1111 +-----+-----------------------+-------+
1112 | any | 000000000000 10000000 | 139 |
1113 +-----+-----------------------+-------+
1115 Table 3: Examples of decoded Signed
1116 Golomb Rice Codes.
1118 3.8.2.2. Run Mode
1120 Run mode is entered when the context is 0 and left as soon as a non-0
1121 difference is found. The sample difference is identical to the
1122 predicted one. The run and the first different sample difference are
1123 coded as defined in Section 3.8.2.4.1.
1125 3.8.2.2.1. Run Length Coding
1127 The run value is encoded in two parts. The prefix part stores the
1128 more significant part of the run as well as adjusting the "run_index"
1129 that determines the number of bits in the less significant part of
1130 the run. The second part of the value stores the less significant
1131 part of the run as it is. The "run_index" is reset for each Plane
1132 and slice to 0.
1134 log2_run[41] = {
1135 0, 0, 0, 0, 1, 1, 1, 1,
1136 2, 2, 2, 2, 3, 3, 3, 3,
1137 4, 4, 5, 5, 6, 6, 7, 7,
1138 8, 9,10,11,12,13,14,15,
1139 16,17,18,19,20,21,22,23,
1140 24,
1141 };
1143 if (run_count == 0 && run_mode == 1) {
1144 if (get_bits(1)) {
1145 run_count = 1 << log2_run[run_index];
1146 if (x + run_count <= w) {
1147 run_index++;
1148 }
1149 } else {
1150 if (log2_run[run_index]) {
1151 run_count = get_bits(log2_run[run_index]);
1152 } else {
1153 run_count = 0;
1154 }
1155 if (run_index) {
1156 run_index--;
1157 }
1158 run_mode = 2;
1159 }
1160 }
1162 The "log2_run" array is also used within [ISO.14495-1.1999].
1164 3.8.2.3. Sign extension
1166 "sign_extend" is the function of increasing the number of bits of an
1167 input binary number in twos complement signed number representation
1168 while preserving the input number's sign (positive/negative) and
1169 value, in order to fit in the output bit width. It MAY be computed
1170 with:
1172 sign_extend(input_number, input_bits) {
1173 negative_bias = 1 << (input_bits - 1);
1174 bits_mask = negative_bias - 1;
1175 output_number = input_number & bits_mask; // Remove negative bit
1176 is_negative = input_number & negative_bias; // Test negative bit
1177 if (is_negative)
1178 output_number -= negative_bias;
1179 return output_number
1180 }
1182 3.8.2.4. Scalar Mode
1184 Each difference is coded with the per context mean prediction removed
1185 and a per context value for k.
1187 get_vlc_symbol(state) {
1188 i = state->count;
1189 k = 0;
1190 while (i < state->error_sum) {
1191 k++;
1192 i += i;
1193 }
1195 v = get_sr_golomb(k);
1197 if (2 * state->drift < -state->count) {
1198 v = -1 - v;
1199 }
1201 ret = sign_extend(v + state->bias, bits);
1203 state->error_sum += abs(v);
1204 state->drift += v;
1206 if (state->count == 128) {
1207 state->count >>= 1;
1208 state->drift >>= 1;
1209 state->error_sum >>= 1;
1210 }
1211 state->count++;
1212 if (state->drift <= -state->count) {
1213 state->bias = max(state->bias - 1, -128);
1215 state->drift = max(state->drift + state->count,
1216 -state->count + 1);
1217 } else if (state->drift > 0) {
1218 state->bias = min(state->bias + 1, 127);
1220 state->drift = min(state->drift - state->count, 0);
1221 }
1223 return ret;
1224 }
1226 3.8.2.4.1. Golomb Rice Sample Difference Coding
1228 Level coding is identical to the normal difference coding with the
1229 exception that the 0 value is removed as it cannot occur:
1231 diff = get_vlc_symbol(context_state);
1232 if (diff >= 0) {
1233 diff++;
1234 }
1236 Note, this is different from JPEG-LS, which doesn't use prediction in
1237 run mode and uses a different encoding and context model for the last
1238 difference. On a small set of test Samples the use of prediction
1239 slightly improved the compression rate.
1241 3.8.2.5. Initial Values for the VLC context state
1243 When "keyframe" (see Section 4.4) value is 1, all coder state
1244 variables are set to their initial state.
1246 drift = 0;
1247 error_sum = 4;
1248 bias = 0;
1249 count = 1;
1251 4. Bitstream
1253 An FFV1 bitstream is composed of a series of one or more Frames and
1254 (when required) a "Configuration Record".
1256 Within the following sub-sections, pseudo-code is used, as described
1257 in Section 2.2.1, to explain the structure of each FFV1 bitstream
1258 component. Table 4 lists symbols used to annotate that pseudo-code
1259 in order to define the storage of the data referenced in that line of
1260 pseudo-code.
1262 +========+=================================================+
1263 | Symbol | Definition |
1264 +========+=================================================+
1265 | u(n) | unsigned big endian integer Symbol using n bits |
1266 +--------+-------------------------------------------------+
1267 | sg | Golomb Rice coded signed scalar Symbol coded |
1268 | | with the method described in Section 3.8.2 |
1269 +--------+-------------------------------------------------+
1270 | br | Range coded Boolean (1-bit) Symbol with the |
1271 | | method described in Section 3.8.1.1 |
1272 +--------+-------------------------------------------------+
1273 | ur | Range coded unsigned scalar Symbol coded with |
1274 | | the method described in Section 3.8.1.2 |
1275 +--------+-------------------------------------------------+
1276 | sr | Range coded signed scalar Symbol coded with the |
1277 | | method described in Section 3.8.1.2 |
1278 +--------+-------------------------------------------------+
1279 | sd | Sample difference Symbol coded with the method |
1280 | | described in Section 3.8 |
1281 +--------+-------------------------------------------------+
1283 Table 4: Definition of pseudo-code symbols for this
1284 document.
1286 The following MUST be provided by external means during
1287 initialization of the decoder:
1289 "frame_pixel_width" is defined as Frame width in Pixels.
1291 "frame_pixel_height" is defined as Frame height in Pixels.
1293 Default values at the decoder initialization phase:
1295 "ConfigurationRecordIsPresent" is set to 0.
1297 4.1. Quantization Table Set
1299 The Quantization Table Sets are stored by storing the number of equal
1300 entries -1 of the first half of the table (represented as "len - 1"
1301 in the pseudo-code below) using the method described in
1302 Section 3.8.1.2. The second half doesn't need to be stored as it is
1303 identical to the first with flipped sign. "scale" and "len_count[ i
1304 ][ j ]" are temporary values used for the computing of
1305 "context_count[ i ]" and are not used outside Quantization Table Set
1306 pseudo-code.
1308 Example:
1310 Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0
1312 Stored values: 1, 3, 1
1314 "QuantizationTableSet" has its own initial states, all set to 128.
1316 pseudo-code | type
1317 --------------------------------------------------------------|-----
1318 QuantizationTableSet( i ) { |
1319 scale = 1 |
1320 for (j = 0; j < MAX_CONTEXT_INPUTS; j++) { |
1321 QuantizationTable( i, j, scale ) |
1322 scale *= 2 * len_count[ i ][ j ] - 1 |
1323 } |
1324 context_count[ i ] = ceil( scale / 2 ) |
1325 } |
1327 "MAX_CONTEXT_INPUTS" is 5.
1329 pseudo-code | type
1330 --------------------------------------------------------------|-----
1331 QuantizationTable(i, j, scale) { |
1332 v = 0 |
1333 for (k = 0; k < 128;) { |
1334 len - 1 | ur
1335 for (n = 0; n < len; n++) { |
1336 quant_tables[ i ][ j ][ k ] = scale * v |
1337 k++ |
1338 } |
1339 v++ |
1340 } |
1341 for (k = 1; k < 128; k++) { |
1342 quant_tables[ i ][ j ][ 256 - k ] = \ |
1343 -quant_tables[ i ][ j ][ k ] |
1344 } |
1345 quant_tables[ i ][ j ][ 128 ] = \ |
1346 -quant_tables[ i ][ j ][ 127 ] |
1347 len_count[ i ][ j ] = v |
1348 } |
1350 4.1.1. quant_tables
1352 "quant_tables[ i ][ j ][ k ]" indicates the quantification table
1353 value of the Quantized Sample Difference "k" of the Quantization
1354 Table "j" of the Set Quantization Table Set "i".
1356 4.1.2. context_count
1358 "context_count[ i ]" indicates the count of contexts for Quantization
1359 Table Set "i". "context_count[ i ]" MUST be less than or equal to
1360 32768.
1362 4.2. Parameters
1364 The "Parameters" section contains significant characteristics about
1365 the decoding configuration used for all instances of Frame (in FFV1
1366 version 0 and 1) or the whole FFV1 bitstream (other versions),
1367 including the stream version, color configuration, and quantization
1368 tables. Figure 27 describes the contents of the bitstream.
1370 "Parameters" has its own initial states, all set to 128.
1372 pseudo-code | type
1373 --------------------------------------------------------------|-----
1374 Parameters( ) { |
1375 version | ur
1376 if (version >= 3) { |
1377 micro_version | ur
1378 } |
1379 coder_type | ur
1380 if (coder_type > 1) { |
1381 for (i = 1; i < 256; i++) { |
1382 state_transition_delta[ i ] | sr
1383 } |
1384 } |
1385 colorspace_type | ur
1386 if (version >= 1) { |
1387 bits_per_raw_sample | ur
1388 } |
1389 chroma_planes | br
1390 log2_h_chroma_subsample | ur
1391 log2_v_chroma_subsample | ur
1392 extra_plane | br
1393 if (version >= 3) { |
1394 num_h_slices - 1 | ur
1395 num_v_slices - 1 | ur
1396 quant_table_set_count | ur
1397 } |
1398 for (i = 0; i < quant_table_set_count; i++) { |
1399 QuantizationTableSet( i ) |
1400 } |
1401 if (version >= 3) { |
1402 for (i = 0; i < quant_table_set_count; i++) { |
1403 states_coded | br
1404 if (states_coded) { |
1405 for (j = 0; j < context_count[ i ]; j++) { |
1406 for (k = 0; k < CONTEXT_SIZE; k++) { |
1407 initial_state_delta[ i ][ j ][ k ] | sr
1408 } |
1409 } |
1410 } |
1411 } |
1412 ec | ur
1413 intra | ur
1414 } |
1415 } |
1417 Figure 27: A pseudo-code description of the bitstream contents.
1419 CONTEXT_SIZE is 32.
1421 4.2.1. version
1423 "version" specifies the version of the FFV1 bitstream.
1425 Each version is incompatible with other versions: decoders SHOULD
1426 reject FFV1 bitstreams due to an unknown version.
1428 Decoders SHOULD reject FFV1 bitstreams with version <= 1 &&
1429 ConfigurationRecordIsPresent == 1.
1431 Decoders SHOULD reject FFV1 bitstreams with version >= 3 &&
1432 ConfigurationRecordIsPresent == 0.
1434 +=======+=========================+
1435 | value | version |
1436 +=======+=========================+
1437 | 0 | FFV1 version 0 |
1438 +-------+-------------------------+
1439 | 1 | FFV1 version 1 |
1440 +-------+-------------------------+
1441 | 2 | reserved* |
1442 +-------+-------------------------+
1443 | 3 | FFV1 version 3 |
1444 +-------+-------------------------+
1445 | Other | reserved for future use |
1446 +-------+-------------------------+
1448 Table 5
1450 * Version 2 was experimental and this document does not describe it.
1452 4.2.2. micro_version
1454 "micro_version" specifies the micro-version of the FFV1 bitstream.
1456 After a version is considered stable (a micro-version value is
1457 assigned to be the first stable variant of a specific version), each
1458 new micro-version after this first stable variant is compatible with
1459 the previous micro-version: decoders SHOULD NOT reject FFV1
1460 bitstreams due to an unknown micro-version equal or above the micro-
1461 version considered as stable.
1463 Meaning of "micro_version" for "version" 3:
1465 +=======+=========================+
1466 | value | micro_version |
1467 +=======+=========================+
1468 | 0...3 | reserved* |
1469 +-------+-------------------------+
1470 | 4 | first stable variant |
1471 +-------+-------------------------+
1472 | Other | reserved for future use |
1473 +-------+-------------------------+
1475 Table 6: The definitions for
1476 "micro_version" values for FFV1
1477 version 3.
1479 * development versions may be incompatible with the stable variants.
1481 4.2.3. coder_type
1483 "coder_type" specifies the coder used.
1485 +=======+=================================================+
1486 | value | coder used |
1487 +=======+=================================================+
1488 | 0 | Golomb Rice |
1489 +-------+-------------------------------------------------+
1490 | 1 | Range Coder with default state transition table |
1491 +-------+-------------------------------------------------+
1492 | 2 | Range Coder with custom state transition table |
1493 +-------+-------------------------------------------------+
1494 | Other | reserved for future use |
1495 +-------+-------------------------------------------------+
1497 Table 7
1499 Restrictions:
1501 If "coder_type" is 0, then "bits_per_raw_sample" SHOULD NOT be > 8.
1503 Background: At the time of this writing, there is no known
1504 implementation of FFV1 bitstream supporting Golomb Rice algorithm
1505 with "bits_per_raw_sample" greater than 8, and Range Coder is
1506 prefered.
1508 4.2.4. state_transition_delta
1510 "state_transition_delta" specifies the Range coder custom state
1511 transition table.
1513 If "state_transition_delta" is not present in the FFV1 bitstream, all
1514 Range coder custom state transition table elements are assumed to be
1515 0.
1517 4.2.5. colorspace_type
1519 "colorspace_type" specifies the color space encoded, the pixel
1520 transformation used by the encoder, the extra plane content, as well
1521 as interleave method.
1523 +=======+==============+================+==============+============+
1524 | value | color space | pixel | extra plane | interleave |
1525 | | encoded | transformation | content | method |
1526 +=======+==============+================+==============+============+
1527 | 0 | YCbCr | None | Transparency | Plane then |
1528 | | | | | Line |
1529 +-------+--------------+----------------+--------------+------------+
1530 | 1 | RGB | JPEG2000-RCT | Transparency | Line then |
1531 | | | | | Plane |
1532 +-------+--------------+----------------+--------------+------------+
1533 | Other | reserved | reserved for | reserved for | reserved |
1534 | | for future | future use | future use | for future |
1535 | | use | | | use |
1536 +-------+--------------+----------------+--------------+------------+
1538 Table 8
1540 FFV1 bitstreams with "colorspace_type" == 1 && ("chroma_planes" !=
1541 1 || "log2_h_chroma_subsample" != 0 || "log2_v_chroma_subsample" !=
1542 0) are not part of this specification.
1544 4.2.6. chroma_planes
1546 "chroma_planes" indicates if chroma (color) Planes are present.
1548 +=======+===============================+
1549 | value | presence |
1550 +=======+===============================+
1551 | 0 | chroma Planes are not present |
1552 +-------+-------------------------------+
1553 | 1 | chroma Planes are present |
1554 +-------+-------------------------------+
1556 Table 9
1558 4.2.7. bits_per_raw_sample
1560 "bits_per_raw_sample" indicates the number of bits for each Sample.
1561 Inferred to be 8 if not present.
1563 +=======+=================================+
1564 | value | bits for each sample |
1565 +=======+=================================+
1566 | 0 | reserved* |
1567 +-------+---------------------------------+
1568 | Other | the actual bits for each Sample |
1569 +-------+---------------------------------+
1571 Table 10
1573 * Encoders MUST NOT store "bits_per_raw_sample" = 0. Decoders SHOULD
1574 accept and interpret "bits_per_raw_sample" = 0 as 8.
1576 4.2.8. log2_h_chroma_subsample
1578 "log2_h_chroma_subsample" indicates the subsample factor, stored in
1579 powers to which the number 2 is raised, between luma and chroma width
1580 ("chroma_width = 2 ^ -log2_h_chroma_subsample * luma_width").
1582 4.2.9. log2_v_chroma_subsample
1584 "log2_v_chroma_subsample" indicates the subsample factor, stored in
1585 powers to which the number 2 is raised, between luma and chroma
1586 height ("chroma_height = 2 ^ -log2_v_chroma_subsample *
1587 luma_height").
1589 4.2.10. extra_plane
1591 "extra_plane" indicates if an extra Plane is present.
1593 +=======+============================+
1594 | value | presence |
1595 +=======+============================+
1596 | 0 | extra Plane is not present |
1597 +-------+----------------------------+
1598 | 1 | extra Plane is present |
1599 +-------+----------------------------+
1601 Table 11
1603 4.2.11. num_h_slices
1605 "num_h_slices" indicates the number of horizontal elements of the
1606 slice raster.
1608 Inferred to be 1 if not present.
1610 4.2.12. num_v_slices
1612 "num_v_slices" indicates the number of vertical elements of the slice
1613 raster.
1615 Inferred to be 1 if not present.
1617 4.2.13. quant_table_set_count
1619 "quant_table_set_count" indicates the number of Quantization
1620 Table Sets. "quant_table_set_count" MUST be less than or equal to 8.
1622 Inferred to be 1 if not present.
1624 MUST NOT be 0.
1626 4.2.14. states_coded
1628 "states_coded" indicates if the respective Quantization Table Set has
1629 the initial states coded.
1631 Inferred to be 0 if not present.
1633 +=======+================================+
1634 | value | initial states |
1635 +=======+================================+
1636 | 0 | initial states are not present |
1637 | | and are assumed to be all 128 |
1638 +-------+--------------------------------+
1639 | 1 | initial states are present |
1640 +-------+--------------------------------+
1642 Table 12
1644 4.2.15. initial_state_delta
1646 "initial_state_delta[ i ][ j ][ k ]" indicates the initial Range
1647 coder state, it is encoded using "k" as context index and
1649 pred = j ? initial_states[ i ][j - 1][ k ] : 128
1650 Figure 28
1652 initial_state[ i ][ j ][ k ] =
1653 ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255
1655 Figure 29
1657 4.2.16. ec
1659 "ec" indicates the error detection/correction type.
1661 +=======+=================================================+
1662 | value | error detection/correction type |
1663 +=======+=================================================+
1664 | 0 | 32-bit CRC in "ConfigurationRecord" |
1665 +-------+-------------------------------------------------+
1666 | 1 | 32-bit CRC in "Slice" and "ConfigurationRecord" |
1667 +-------+-------------------------------------------------+
1668 | Other | reserved for future use |
1669 +-------+-------------------------------------------------+
1671 Table 13
1673 4.2.17. intra
1675 "intra" indicates the constraint on "keyframe" in each instance of
1676 Frame.
1678 Inferred to be 0 if not present.
1680 +=======+=======================================================+
1681 | value | relationship |
1682 +=======+=======================================================+
1683 | 0 | "keyframe" can be 0 or 1 (non keyframes or keyframes) |
1684 +-------+-------------------------------------------------------+
1685 | 1 | "keyframe" MUST be 1 (keyframes only) |
1686 +-------+-------------------------------------------------------+
1687 | Other | reserved for future use |
1688 +-------+-------------------------------------------------------+
1690 Table 14
1692 4.3. Configuration Record
1694 In the case of a FFV1 bitstream with "version >= 3", a "Configuration
1695 Record" is stored in the underlying Container as described in
1696 Section 4.3.3. It contains the "Parameters" used for all instances
1697 of Frame. The size of the "Configuration Record", "NumBytes", is
1698 supplied by the underlying Container.
1700 pseudo-code | type
1701 -----------------------------------------------------------|-----
1702 ConfigurationRecord( NumBytes ) { |
1703 ConfigurationRecordIsPresent = 1 |
1704 Parameters( ) |
1705 while (remaining_symbols_in_syntax(NumBytes - 4)) { |
1706 reserved_for_future_use | br/ur/sr
1707 } |
1708 configuration_record_crc_parity | u(32)
1709 } |
1711 4.3.1. reserved_for_future_use
1713 "reserved_for_future_use" is a placeholder for future updates of this
1714 specification.
1716 Encoders conforming to this version of this specification SHALL NOT
1717 write "reserved_for_future_use".
1719 Decoders conforming to this version of this specification SHALL
1720 ignore "reserved_for_future_use".
1722 4.3.2. configuration_record_crc_parity
1724 "configuration_record_crc_parity" 32 bits that are chosen so that the
1725 "Configuration Record" as a whole has a CRC remainder of 0.
1727 This is equivalent to storing the CRC remainder in the 32-bit parity.
1729 The CRC generator polynomial used is described in Section 4.9.3.
1731 4.3.3. Mapping FFV1 into Containers
1733 This "Configuration Record" can be placed in any file format
1734 supporting "Configuration Records", fitting as much as possible with
1735 how the file format uses to store "Configuration Records". The
1736 "Configuration Record" storage place and "NumBytes" are currently
1737 defined and supported by this version of this specification for the
1738 following formats:
1740 4.3.3.1. AVI File Format
1742 The "Configuration Record" extends the stream format chunk ("AVI ",
1743 "hdlr", "strl", "strf") with the ConfigurationRecord bitstream.
1745 See [AVI] for more information about chunks.
1747 "NumBytes" is defined as the size, in bytes, of the strf chunk
1748 indicated in the chunk header minus the size of the stream format
1749 structure.
1751 4.3.3.2. ISO Base Media File Format
1753 The "Configuration Record" extends the sample description box
1754 ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box
1755 that contains the ConfigurationRecord bitstream. See
1756 [ISO.14496-12.2015] for more information about boxes.
1758 "NumBytes" is defined as the size, in bytes, of the "glbl" box
1759 indicated in the box header minus the size of the box header.
1761 4.3.3.3. NUT File Format
1763 The "codec_specific_data" element (in "stream_header" packet)
1764 contains the ConfigurationRecord bitstream. See [NUT] for more
1765 information about elements.
1767 "NumBytes" is defined as the size, in bytes, of the
1768 "codec_specific_data" element as indicated in the "length" field of
1769 "codec_specific_data".
1771 4.3.3.4. Matroska File Format
1773 FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1
1774 versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be
1775 used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate"
1776 Element MUST contain the FFV1 "Configuration Record" structure and no
1777 other data. See [Matroska] for more information about elements.
1779 "NumBytes" is defined as the "Element Data Size" of the
1780 "CodecPrivate" Element.
1782 4.4. Frame
1784 A Frame is an encoded representation of a complete static image. The
1785 whole Frame is provided by the underlaying container.
1787 A Frame consists of the "keyframe" field, "Parameters" (if "version"
1788 <= 1), and a sequence of independent slices. The pseudo-code below
1789 describes the contents of a Frame.
1791 "keyframe" field has its own initial state, set to 128.
1793 pseudo-code | type
1794 --------------------------------------------------------------|-----
1795 Frame( NumBytes ) { |
1796 keyframe | br
1797 if (keyframe && !ConfigurationRecordIsPresent { |
1798 Parameters( ) |
1799 } |
1800 while (remaining_bits_in_bitstream( NumBytes )) { |
1801 Slice( ) |
1802 } |
1803 } |
1805 Architecture overview of slices in a Frame:
1807 +=================================================================+
1808 +=================================================================+
1809 | first slice header |
1810 +-----------------------------------------------------------------+
1811 | first slice content |
1812 +-----------------------------------------------------------------+
1813 | first slice footer |
1814 +-----------------------------------------------------------------+
1815 | --------------------------------------------------------------- |
1816 +-----------------------------------------------------------------+
1817 | second slice header |
1818 +-----------------------------------------------------------------+
1819 | second slice content |
1820 +-----------------------------------------------------------------+
1821 | second slice footer |
1822 +-----------------------------------------------------------------+
1823 | --------------------------------------------------------------- |
1824 +-----------------------------------------------------------------+
1825 | ... |
1826 +-----------------------------------------------------------------+
1827 | --------------------------------------------------------------- |
1828 +-----------------------------------------------------------------+
1829 | last slice header |
1830 +-----------------------------------------------------------------+
1831 | last slice content |
1832 +-----------------------------------------------------------------+
1833 | last slice footer |
1834 +-----------------------------------------------------------------+
1836 Table 15
1838 4.5. Slice
1840 A "Slice" is an independent spatial sub-section of a Frame that is
1841 encoded separately from another region of the same Frame. The use of
1842 more than one "Slice" per Frame can be useful for taking advantage of
1843 the opportunities of multithreaded encoding and decoding.
1845 A "Slice" consists of a "Slice Header" (when relevant), a "Slice
1846 Content", and a "Slice Footer" (when relevant). The pseudo-code
1847 below describes the contents of a "Slice".
1849 pseudo-code | type
1850 --------------------------------------------------------------|-----
1851 Slice( ) { |
1852 if (version >= 3) { |
1853 SliceHeader( ) |
1854 } |
1855 SliceContent( ) |
1856 if (coder_type == 0) { |
1857 while (!byte_aligned()) { |
1858 padding | u(1)
1859 } |
1860 } |
1861 if (version <= 1) { |
1862 while (remaining_bits_in_bitstream( NumBytes ) != 0) {|
1863 reserved | u(1)
1864 } |
1865 } |
1866 if (version >= 3) { |
1867 SliceFooter( ) |
1868 } |
1869 } |
1871 "padding" specifies a bit without any significance and used only for
1872 byte alignment. MUST be 0.
1874 "reserved" specifies a bit without any significance in this revision
1875 of the specification and may have a significance in a later revision
1876 of this specification.
1878 Encoders SHOULD NOT fill "reserved".
1880 Decoders SHOULD ignore "reserved".
1882 4.6. Slice Header
1884 A "Slice Header" provides information about the decoding
1885 configuration of the "Slice", such as its spatial position, size, and
1886 aspect ratio. The pseudo-code below describes the contents of the
1887 "Slice Header".
1889 "Slice Header" has its own initial states, all set to 128.
1891 pseudo-code | type
1892 --------------------------------------------------------------|-----
1893 SliceHeader( ) { |
1894 slice_x | ur
1895 slice_y | ur
1896 slice_width - 1 | ur
1897 slice_height - 1 | ur
1898 for (i = 0; i < quant_table_set_index_count; i++) { |
1899 quant_table_set_index[ i ] | ur
1900 } |
1901 picture_structure | ur
1902 sar_num | ur
1903 sar_den | ur
1904 } |
1906 4.6.1. slice_x
1908 "slice_x" indicates the x position on the slice raster formed by
1909 num_h_slices.
1911 Inferred to be 0 if not present.
1913 4.6.2. slice_y
1915 "slice_y" indicates the y position on the slice raster formed by
1916 num_v_slices.
1918 Inferred to be 0 if not present.
1920 4.6.3. slice_width
1922 "slice_width" indicates the width on the slice raster formed by
1923 num_h_slices.
1925 Inferred to be 1 if not present.
1927 4.6.4. slice_height
1929 "slice_height" indicates the height on the slice raster formed by
1930 num_v_slices.
1932 Inferred to be 1 if not present.
1934 4.6.5. quant_table_set_index_count
1936 "quant_table_set_index_count" is defined as:
1938 1 + ( ( chroma_planes || version <= 3 ) ? 1 : 0 )
1939 + ( extra_plane ? 1 : 0 )
1941 4.6.6. quant_table_set_index
1943 "quant_table_set_index" indicates the Quantization Table Set index to
1944 select the Quantization Table Set and the initial states for the
1945 "Slice Content".
1947 Inferred to be 0 if not present.
1949 4.6.7. picture_structure
1951 "picture_structure" specifies the temporal and spatial relationship
1952 of each Line of the Frame.
1954 Inferred to be 0 if not present.
1956 +=======+=========================+
1957 | value | picture structure used |
1958 +=======+=========================+
1959 | 0 | unknown |
1960 +-------+-------------------------+
1961 | 1 | top field first |
1962 +-------+-------------------------+
1963 | 2 | bottom field first |
1964 +-------+-------------------------+
1965 | 3 | progressive |
1966 +-------+-------------------------+
1967 | Other | reserved for future use |
1968 +-------+-------------------------+
1970 Table 16
1972 4.6.8. sar_num
1974 "sar_num" specifies the Sample aspect ratio numerator.
1976 Inferred to be 0 if not present.
1978 A value of 0 means that aspect ratio is unknown.
1980 Encoders MUST write 0 if Sample aspect ratio is unknown.
1982 If "sar_den" is 0, decoders SHOULD ignore the encoded value and
1983 consider that "sar_num" is 0.
1985 4.6.9. sar_den
1987 "sar_den" specifies the Sample aspect ratio denominator.
1989 Inferred to be 0 if not present.
1991 A value of 0 means that aspect ratio is unknown.
1993 Encoders MUST write 0 if Sample aspect ratio is unknown.
1995 If "sar_num" is 0, decoders SHOULD ignore the encoded value and
1996 consider that "sar_den" is 0.
1998 4.7. Slice Content
2000 A "Slice Content" contains all Line elements part of the "Slice".
2002 Depending on the configuration, Line elements are ordered by Plane
2003 then by row (YCbCr) or by row then by Plane (RGB).
2005 pseudo-code | type
2006 --------------------------------------------------------------|-----
2007 SliceContent( ) { |
2008 if (colorspace_type == 0) { |
2009 for (p = 0; p < primary_color_count; p++) { |
2010 for (y = 0; y < plane_pixel_height[ p ]; y++) { |
2011 Line( p, y ) |
2012 } |
2013 } |
2014 } else if (colorspace_type == 1) { |
2015 for (y = 0; y < slice_pixel_height; y++) { |
2016 for (p = 0; p < primary_color_count; p++) { |
2017 Line( p, y ) |
2018 } |
2019 } |
2020 } |
2021 } |
2023 4.7.1. primary_color_count
2025 "primary_color_count" is defined as:
2027 1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 )
2029 4.7.2. plane_pixel_height
2031 "plane_pixel_height[ p ]" is the height in Pixels of Plane p of the
2032 "Slice". It is defined as:
2034 chroma_planes == 1 && (p == 1 || p == 2)
2035 ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))
2036 : slice_pixel_height
2038 4.7.3. slice_pixel_height
2040 "slice_pixel_height" is the height in pixels of the slice. It is
2041 defined as:
2043 floor(
2044 ( slice_y + slice_height )
2045 * slice_pixel_height
2046 / num_v_slices
2047 ) - slice_pixel_y.
2049 4.7.4. slice_pixel_y
2051 "slice_pixel_y" is the slice vertical position in pixels. It is
2052 defined as:
2054 floor( slice_y * frame_pixel_height / num_v_slices )
2056 4.8. Line
2058 A Line is a list of the sample differences (relative to the
2059 predictor) of primary color components. The pseudo-code below
2060 describes the contents of the Line.
2062 pseudo-code | type
2063 --------------------------------------------------------------|-----
2064 Line( p, y ) { |
2065 if (colorspace_type == 0) { |
2066 for (x = 0; x < plane_pixel_width[ p ]; x++) { |
2067 sample_difference[ p ][ y ][ x ] | sd
2068 } |
2069 } else if (colorspace_type == 1) { |
2070 for (x = 0; x < slice_pixel_width; x++) { |
2071 sample_difference[ p ][ y ][ x ] | sd
2072 } |
2073 } |
2074 } |
2076 4.8.1. plane_pixel_width
2078 "plane_pixel_width[ p ]" is the width in Pixels of Plane p of the
2079 "Slice". It is defined as:
2081 chroma\_planes == 1 && (p == 1 || p == 2)
2082 ? ceil( slice_pixel_width / (1 << log2_h_chroma_subsample) )
2083 : slice_pixel_width.
2085 4.8.2. slice_pixel_width
2087 "slice_pixel_width" is the width in Pixels of the slice. It is
2088 defined as:
2090 floor(
2091 ( slice_x + slice_width )
2092 * slice_pixel_width
2093 / num_h_slices
2094 ) - slice_pixel_x
2096 4.8.3. slice_pixel_x
2098 "slice_pixel_x" is the slice horizontal position in Pixels. It is
2099 defined as:
2101 floor( slice_x * frame_pixel_width / num_h_slices )
2103 4.8.4. sample_difference
2105 "sample_difference[ p ][ y ][ x ]" is the sample difference for
2106 Sample at Plane "p", y position "y", and x position "x". The Sample
2107 value is computed based on median predictor and context described in
2108 Section 3.2.
2110 4.9. Slice Footer
2112 A "Slice Footer" provides information about slice size and
2113 (optionally) parity. The pseudo-code below describes the contents of
2114 the "Slice Footer".
2116 Note: "Slice Footer" is always byte aligned.
2118 pseudo-code | type
2119 --------------------------------------------------------------|-----
2120 SliceFooter( ) { |
2121 slice_size | u(24)
2122 if (ec) { |
2123 error_status | u(8)
2124 slice_crc_parity | u(32)
2125 } |
2126 } |
2128 4.9.1. slice_size
2130 "slice_size" indicates the size of the slice in bytes.
2132 Note: this allows finding the start of slices before previous slices
2133 have been fully decoded, and allows parallel decoding as well as
2134 error resilience.
2136 4.9.2. error_status
2138 "error_status" specifies the error status.
2140 +=======+======================================+
2141 | value | error status |
2142 +=======+======================================+
2143 | 0 | no error |
2144 +-------+--------------------------------------+
2145 | 1 | slice contains a correctable error |
2146 +-------+--------------------------------------+
2147 | 2 | slice contains a uncorrectable error |
2148 +-------+--------------------------------------+
2149 | Other | reserved for future use |
2150 +-------+--------------------------------------+
2152 Table 17
2154 4.9.3. slice_crc_parity
2156 "slice_crc_parity" 32 bits that are chosen so that the slice as a
2157 whole has a crc remainder of 0.
2159 This is equivalent to storing the crc remainder in the 32-bit parity.
2161 The CRC generator polynomial used is the standard IEEE CRC polynomial
2162 (0x104C11DB7), with initial value 0, without pre-inversion and
2163 without post-inversion.
2165 5. Restrictions
2167 To ensure that fast multithreaded decoding is possible, starting with
2168 version 3 and if "frame_pixel_width * frame_pixel_height" is more
2169 than 101376, "slice_width * slice_height" MUST be less or equal to
2170 "num_h_slices * num_v_slices / 4". Note: 101376 is the frame size in
2171 Pixels of a 352x288 frame also known as CIF ("Common Intermediate
2172 Format") frame size format.
2174 For each Frame, each position in the slice raster MUST be filled by
2175 one and only one slice of the Frame (no missing slice position, no
2176 slice overlapping).
2178 For each Frame with "keyframe" value of 0, each slice MUST have the
2179 same value of "slice_x", "slice_y", "slice_width", "slice_height" as
2180 a slice in the previous Frame.
2182 6. Security Considerations
2184 Like any other codec, (such as [RFC6716]), FFV1 should not be used
2185 with insecure ciphers or cipher-modes that are vulnerable to known
2186 plaintext attacks. Some of the header bits as well as the padding
2187 are easily predictable.
2189 Implementations of the FFV1 codec need to take appropriate security
2190 considerations into account. Those related to denial of service are
2191 outlined in Section 2.1 of [RFC4732]. It is extremely important for
2192 the decoder to be robust against malicious payloads. Malicious
2193 payloads MUST NOT cause the decoder to overrun its allocated memory
2194 or to take an excessive amount of resources to decode. An overrun in
2195 allocated memory could lead to arbitrary code execution by an
2196 attacker. The same applies to the encoder, even though problems in
2197 encoders are typically rarer. Malicious video streams MUST NOT cause
2198 the encoder to misbehave because this would allow an attacker to
2199 attack transcoding gateways. A frequent security problem in image
2200 and video codecs is failure to check for integer overflows. An
2201 example is allocating "frame_pixel_width * frame_pixel_height" in
2202 Pixel count computations without considering that the multiplication
2203 result may have overflowed the arithmetic types range. The range
2204 coder could, if implemented naively, read one byte over the end. The
2205 implementation MUST ensure that no read outside allocated and
2206 initialized memory occurs.
2208 None of the content carried in FFV1 is intended to be executable.
2210 7. IANA Considerations
2212 The IANA is requested to register the following values:
2214 7.1. Media Type Definition
2216 This registration is done using the template defined in [RFC6838] and
2217 following [RFC4855].
2219 Type name: video
2221 Subtype name: FFV1
2222 Required parameters: None.
2224 Optional parameters: These parameters are used to signal the
2225 capabilities of a receiver implementation. These parameters MUST NOT
2226 be used for any other purpose.
2228 * "version": The "version" of the FFV1 encoding as defined by
2229 Section 4.2.1.
2231 * "micro_version": The "micro_version" of the FFV1 encoding as
2232 defined by Section 4.2.2.
2234 * "coder_type": The "coder_type" of the FFV1 encoding as defined by
2235 Section 4.2.3.
2237 * "colorspace_type": The "colorspace_type" of the FFV1 encoding as
2238 defined by Section 4.2.5.
2240 * "bits_per_raw_sample": The "bits_per_raw_sample" of the FFV1
2241 encoding as defined by Section 4.2.7.
2243 * "max_slices": The value of "max_slices" is an integer indicating
2244 the maximum count of slices with a frames of the FFV1 encoding.
2246 Encoding considerations: This media type is defined for encapsulation
2247 in several audiovisual container formats and contains binary data;
2248 see Section 4.3.3. This media type is framed binary data; see
2249 Section 4.8 of [RFC6838].
2251 Security considerations: See Section 6 of this document.
2253 Interoperability considerations: None.
2255 Published specification: RFC XXXX.
2257 [RFC Editor: Upon publication as an RFC, please replace "XXXX" with
2258 the number assigned to this document and remove this note.]
2260 Applications which use this media type: Any application that requires
2261 the transport of lossless video can use this media type. Some
2262 examples are, but not limited to screen recording, scientific
2263 imaging, and digital video preservation.
2265 Fragment identifier considerations: N/A.
2267 Additional information: None.
2269 Person & email address to contact for further information: Michael
2270 Niedermayer michael@niedermayer.cc (mailto:michael@niedermayer.cc)
2272 Intended usage: COMMON
2274 Restrictions on usage: None.
2276 Author: Dave Rice dave@dericed.com (mailto:dave@dericed.com)
2278 Change controller: IETF cellar working group delegated from the IESG.
2280 8. Changelog
2282 See https://github.com/FFmpeg/FFV1/commits/master
2283 (https://github.com/FFmpeg/FFV1/commits/master)
2285 [RFC Editor: Please remove this Changelog section prior to
2286 publication.]
2288 9. Normative References
2290 [ISO.15444-1.2016]
2291 International Organization for Standardization,
2292 "Information technology -- JPEG 2000 image coding system:
2293 Core coding system", October 2016.
2295 [ISO.9899.2018]
2296 International Organization for Standardization,
2297 "Programming languages - C", ISO Standard 9899, 2018.
2299 [Matroska] IETF, "Matroska", 2019, .
2302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2303 Requirement Levels", BCP 14, RFC 2119,
2304 DOI 10.17487/RFC2119, March 1997,
2305 .
2307 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
2308 Denial-of-Service Considerations", RFC 4732,
2309 DOI 10.17487/RFC4732, December 2006,
2310 .
2312 [RFC4855] Casner, S., "Media Type Registration of RTP Payload
2313 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
2314 .
2316 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
2317 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
2318 September 2012, .
2320 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
2321 Specifications and Registration Procedures", BCP 13,
2322 RFC 6838, DOI 10.17487/RFC6838, January 2013,
2323 .
2325 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2326 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2327 May 2017, .
2329 10. Informative References
2331 [Address-Sanitizer]
2332 The Clang Team, "ASAN AddressSanitizer website", undated,
2333 .
2335 [AVI] Microsoft, "AVI RIFF File Reference", undated,
2336 .
2339 [FFV1GO] Buitenhuis, D., "FFV1 Decoder in Go", 2019,
2340 .
2342 [FFV1_V0] Niedermayer, M., "Commit to mark FFV1 version 0 as non-
2343 experimental", April 2006, .
2347 [FFV1_V1] Niedermayer, M., "Commit to release FFV1 version 1", April
2348 2009, .
2351 [FFV1_V3] Niedermayer, M., "Commit to mark FFV1 version 3 as non-
2352 experimental", August 2013, .
2356 [HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003,
2357 .
2360 [ISO.14495-1.1999]
2361 International Organization for Standardization,
2362 "Information technology -- Lossless and near-lossless
2363 compression of continuous-tone still images: Baseline",
2364 December 1999.
2366 [ISO.14496-10.2014]
2367 International Organization for Standardization,
2368 "Information technology -- Coding of audio-visual objects
2369 -- Part 10: Advanced Video Coding", September 2014.
2371 [ISO.14496-12.2015]
2372 International Organization for Standardization,
2373 "Information technology -- Coding of audio-visual objects
2374 -- Part 12: ISO base media file format", December 2015.
2376 [MediaConch]
2377 MediaArea.net, "MediaConch", 2018,
2378 .
2380 [NUT] Niedermayer, M., "NUT Open Container Format", December
2381 2013, .
2383 [range-coding]
2384 Martin, G. N. N., "Range encoding: an algorithm for
2385 removing redundancy from a digitised message", Proceedings
2386 of the Conference on Video and Data Recording. Institution
2387 of Electronic and Radio Engineers, Hampshire, England,
2388 July 1979.
2390 [REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the
2391 FFV1 codec in FFmpeg", undated, .
2393 [VALGRIND] Valgrind Developers, "Valgrind website", undated,
2394 .
2396 [YCbCr] Wikipedia, "YCbCr", undated,
2397 .
2399 Appendix A. Multi-theaded decoder implementation suggestions
2401 This appendix is informative.
2403 The FFV1 bitstream is parsable in two ways: in sequential order as
2404 described in this document or with the pre-analysis of the footer of
2405 each slice. Each slice footer contains a "slice_size" field so the
2406 boundary of each slice is computable without having to parse the
2407 slice content. That allows multi-threading as well as independence
2408 of slice content (a bitstream error in a slice header or slice
2409 content has no impact on the decoding of the other slices).
2411 After having checked "keyframe" field, a decoder SHOULD parse
2412 "slice_size" fields, from "slice_size" of the last slice at the end
2413 of the "Frame" up to "slice_size" of the first slice at the beginning
2414 of the "Frame", before parsing slices, in order to have slices
2415 boundaries. A decoder MAY fallback on sequential order e.g. in case
2416 of a corrupted "Frame" (frame size unknown, "slice_size" of slices
2417 not coherent...) or if there is no possibility of seeking into the
2418 stream.
2420 Appendix B. Future handling of some streams created by non conforming
2421 encoders
2423 This appendix is informative.
2425 Some bitstreams were found with 40 extra bits corresponding to
2426 "error_status" and "slice_crc_parity" in the "reserved" bits of
2427 "Slice()". Any revision of this specification SHOULD care about
2428 avoiding to add 40 bits of content after "SliceContent" if "version"
2429 == 0 or "version" == 1. Else a decoder conforming to the revised
2430 specification could not distinguish between a revised bitstream and
2431 such buggy bitstream in the wild.
2433 Appendix C. FFV1 Implementations
2435 This appendix provides references to a few notable implementations of
2436 FFV1.
2438 C.1. FFmpeg FFV1 Codec
2440 This reference implementation [REFIMPL] contains no known buffer
2441 overflow or cases where a specially crafted packet or video segment
2442 could cause a significant increase in CPU load.
2444 The reference implementation [REFIMPL] was validated in the following
2445 conditions:
2447 * Sending the decoder valid packets generated by the reference
2448 encoder and verifying that the decoder's output matches the
2449 encoder's input.
2451 * Sending the decoder packets generated by the reference encoder and
2452 then subjected to random corruption.
2454 * Sending the decoder random packets that are not FFV1.
2456 In all of the conditions above, the decoder and encoder was run
2457 inside the [VALGRIND] memory debugger as well as clangs address
2458 sanitizer [Address-Sanitizer], which track reads and writes to
2459 invalid memory regions as well as the use of uninitialized memory.
2460 There were no errors reported on any of the tested conditions.
2462 C.2. FFV1 Decoder in Go
2464 An FFV1 decoder was [FFV1GO] written in Go by Derek Buitenhuis during
2465 the work to development this document.
2467 C.3. MediaConch
2469 The developers of the MediaConch project [MediaConch] created an
2470 independent FFV1 decoder as part of that project to validate FFV1
2471 bitstreams. This work led to the discovery of three conflicts
2472 between existing FFV1 implementations and this document without the
2473 added exceptions.
2475 Authors' Addresses
2477 Michael Niedermayer
2479 Email: michael@niedermayer.cc
2481 Dave Rice
2483 Email: dave@dericed.com
2485 Jerome Martinez
2487 Email: jerome@mediaarea.net