draft-ietf-cellar-ffv1-v4-15.txt		draft-ietf-cellar-ffv1-v4-16.txt
	cellar M. Niedermayer		cellar M. Niedermayer
	Internet-Draft		Internet-Draft
	Intended status: Standards Track D. Rice		Intended status: Standards Track D. Rice
	Expires: 10 April 2021		Expires: 4 June 2021
	J. Martinez		J. Martinez
	7 October 2020		1 December 2020
	FFV1 Video Coding Format Version 4		FFV1 Video Coding Format Version 4
	draft-ietf-cellar-ffv1-v4-15		draft-ietf-cellar-ffv1-v4-16
	Abstract		Abstract
	This document defines FFV1, a lossless intra-frame video encoding		This document defines FFV1, a lossless intra-frame video encoding
	format. FFV1 is designed to efficiently compress video data in a		format. FFV1 is designed to efficiently compress video data in a
	variety of pixel formats. Compared to uncompressed video, FFV1		variety of pixel formats. Compared to uncompressed video, FFV1
	offers storage compression, frame fixity, and self-description, which		offers storage compression, frame fixity, and self-description, which
	makes FFV1 useful as a preservation or intermediate video format.		makes FFV1 useful as a preservation or intermediate video format.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 10 April 2021.		This Internet-Draft will expire on 4 June 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4		2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4
	2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 6		2.2.1. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 6
	2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6		2.2.2. Arithmetic Operators . . . . . . . . . . . . . . . . 6
	2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 7		2.2.3. Assignment Operators . . . . . . . . . . . . . . . . 7
	2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7		2.2.4. Comparison Operators . . . . . . . . . . . . . . . . 7
	2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7		2.2.5. Mathematical Functions . . . . . . . . . . . . . . . 7
	2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8		2.2.6. Order of Operation Precedence . . . . . . . . . . . . 8
	2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 9		2.2.7. Range . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 9		2.2.8. NumBytes . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 9		2.2.9. Bitstream Functions . . . . . . . . . . . . . . . . . 9
	3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Sample Coding . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. Border . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.2. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 11		3.3. Median Predictor . . . . . . . . . . . . . . . . . . . . 11
			3.3.1. Exception . . . . . . . . . . . . . . . . . . . . . . 11
	3.4. Quantization Table Sets . . . . . . . . . . . . . . . . . 12		3.4. Quantization Table Sets . . . . . . . . . . . . . . . . . 12
	3.5. Context . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.5. Context . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.6. Quantization Table Set Indexes . . . . . . . . . . . . . 12		3.6. Quantization Table Set Indexes . . . . . . . . . . . . . 13
	3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 13		3.7. Color spaces . . . . . . . . . . . . . . . . . . . . . . 13
	3.7.1. YCbCr . . . . . . . . . . . . . . . . . . . . . . . . 13		3.7.1. YCbCr . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 14		3.7.2. RGB . . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.8. Coding of the Sample Difference . . . . . . . . . . . . . 15		3.8. Coding of the Sample Difference . . . . . . . . . . . . . 16
	3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 15		3.8.1. Range Coding Mode . . . . . . . . . . . . . . . . . . 16
	3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 22		3.8.2. Golomb Rice Mode . . . . . . . . . . . . . . . . . . 22
	4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 28		4. Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	4.1. Quantization Table Set . . . . . . . . . . . . . . . . . 29		4.1. Quantization Table Set . . . . . . . . . . . . . . . . . 29
	4.1.1. quant_tables . . . . . . . . . . . . . . . . . . . . 30		4.1.1. quant_tables . . . . . . . . . . . . . . . . . . . . 30
	4.1.2. context_count . . . . . . . . . . . . . . . . . . . . 31		4.1.2. context_count . . . . . . . . . . . . . . . . . . . . 31
	4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 31		4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 31
	4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 33		4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 33
	4.2.2. micro_version . . . . . . . . . . . . . . . . . . . . 33		4.2.2. micro_version . . . . . . . . . . . . . . . . . . . . 33
	4.2.3. coder_type . . . . . . . . . . . . . . . . . . . . . 34		4.2.3. coder_type . . . . . . . . . . . . . . . . . . . . . 34
	4.2.4. state_transition_delta . . . . . . . . . . . . . . . 35		4.2.4. state_transition_delta . . . . . . . . . . . . . . . 35
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 50 ¶
	4.8.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 48		4.8.1. plane_pixel_width . . . . . . . . . . . . . . . . . . 48
	4.8.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 49		4.8.2. slice_pixel_width . . . . . . . . . . . . . . . . . . 49
	4.8.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 49		4.8.3. slice_pixel_x . . . . . . . . . . . . . . . . . . . . 49
	4.8.4. sample_difference . . . . . . . . . . . . . . . . . . 49		4.8.4. sample_difference . . . . . . . . . . . . . . . . . . 49
	4.9. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 49		4.9. Slice Footer . . . . . . . . . . . . . . . . . . . . . . 49
	4.9.1. slice_size . . . . . . . . . . . . . . . . . . . . . 50		4.9.1. slice_size . . . . . . . . . . . . . . . . . . . . . 50
	4.9.2. error_status . . . . . . . . . . . . . . . . . . . . 50		4.9.2. error_status . . . . . . . . . . . . . . . . . . . . 50
	4.9.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 50		4.9.3. slice_crc_parity . . . . . . . . . . . . . . . . . . 50
	5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 50		5. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 50
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 51		6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 52		7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 51
	8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 53		8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 53
	9. Normative References . . . . . . . . . . . . . . . . . . . . 53		9. Normative References . . . . . . . . . . . . . . . . . . . . 53
	10. Informative References . . . . . . . . . . . . . . . . . . . 54		10. Informative References . . . . . . . . . . . . . . . . . . . 54
	Appendix A. Multi-theaded decoder implementation suggestions . . 55		Appendix A. Multi-theaded decoder implementation suggestions . . 55
	Appendix B. Future handling of some streams created by non		Appendix B. Future handling of some streams created by non
	conforming encoders . . . . . . . . . . . . . . . . . . . 56		conforming encoders . . . . . . . . . . . . . . . . . . . 56
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56		Appendix C. FFV1 Implementations . . . . . . . . . . . . . . . . 56
			C.1. FFmpeg FFV1 Codec . . . . . . . . . . . . . . . . . . . . 56
			C.2. FFV1 Decoder in Go . . . . . . . . . . . . . . . . . . . 56
			C.3. MediaConch . . . . . . . . . . . . . . . . . . . . . . . 57
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	This document describes FFV1, a lossless video encoding format. The		This document describes FFV1, a lossless video encoding format. The
	design of FFV1 considers the storage of image characteristics, data		design of FFV1 considers the storage of image characteristics, data
	fixity, and the optimized use of encoding time and storage		fixity, and the optimized use of encoding time and storage
	requirements. FFV1 is designed to support a wide range of lossless		requirements. FFV1 is designed to support a wide range of lossless
	video applications such as long-term audiovisual preservation,		video applications such as long-term audiovisual preservation,
	scientific imaging, screen recording, and other video encoding		scientific imaging, screen recording, and other video encoding
	scenarios that seek to avoid the generational loss of lossy video		scenarios that seek to avoid the generational loss of lossy video
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 32 ¶
	"Line": A discrete component of a static image composed of Samples		"Line": A discrete component of a static image composed of Samples
	that represent a specific quantification of Samples of that image.		that represent a specific quantification of Samples of that image.
	"Plane": A discrete component of a static image composed of Lines		"Plane": A discrete component of a static image composed of Lines
	that represent a specific quantification of Lines of that image.		that represent a specific quantification of Lines of that image.
	"Pixel": The smallest addressable representation of a color in a		"Pixel": The smallest addressable representation of a color in a
	Frame. It is composed of one or more Samples.		Frame. It is composed of one or more Samples.
	"ESC": An ESCape Symbol to indicate that the Symbol to be stored is
	too large for normal storage and that an alternate storage method is
	used.
	"MSB": Most Significant Bit, the bit that can cause the largest		"MSB": Most Significant Bit, the bit that can cause the largest
	change in magnitude of the Symbol.		change in magnitude of the Symbol.
	"VLC": Variable Length Code, a code that maps source symbols to a		"VLC": Variable Length Code, a code that maps source symbols to a
	variable number of bits.		variable number of bits.
	"RGB": A reference to the method of storing the value of a Pixel by		"RGB": A reference to the method of storing the value of a Pixel by
	using three numeric values that represent Red, Green, and Blue.		using three numeric values that represent Red, Green, and Blue.
	"YCbCr": A reference to the method of storing the value of a Pixel by		"YCbCr": A reference to the method of storing the value of a Pixel by
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 30 ¶
	The prediction for any Sample value at position "X" may be computed		The prediction for any Sample value at position "X" may be computed
	based upon the relative neighboring values of "l", "t", and "tl" via		based upon the relative neighboring values of "l", "t", and "tl" via
	this equation:		this equation:
	median(l, t, l + t - tl)		median(l, t, l + t - tl)
	Note, this prediction template is also used in [ISO.14495-1.1999] and		Note, this prediction template is also used in [ISO.14495-1.1999] and
	[HuffYUV].		[HuffYUV].
	Exception for the median predictor: if "colorspace_type == 0 &&		3.3.1. Exception
	bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 )"
	(see Section 4.2.5, Section 4.2.7 and Section 4.2.5), the following		If "colorspace_type == 0 && bits_per_raw_sample == 16 && ( coder_type
	median predictor MUST be used:		== 1 || coder_type == 2 )" (see Section 4.2.5, Section 4.2.7 and
			Section 4.2.3), the following median predictor MUST be used:
	median(left16s, top16s, left16s + top16s - diag16s)		median(left16s, top16s, left16s + top16s - diag16s)
	where:		where:
	left16s = l >= 32768 ? ( l - 65536 ) : l		left16s = l >= 32768 ? ( l - 65536 ) : l
	top16s = t >= 32768 ? ( t - 65536 ) : t		top16s = t >= 32768 ? ( t - 65536 ) : t
	diag16s = tl >= 32768 ? ( tl - 65536 ) : tl		diag16s = tl >= 32768 ? ( tl - 65536 ) : tl
	Background: a two's complement 16-bit signed integer was used for		Background: a two's complement 16-bit signed integer was used for
	storing Sample values in all known implementations of FFV1 bitstream.		storing Sample values in all known implementations of FFV1 bitstream
	So in some circumstances, the most significant bit was wrongly		(see Appendix C). So in some circumstances, the most significant bit
	interpreted (used as a sign bit instead of the 16th bit of an		was wrongly interpreted (used as a sign bit instead of the 16th bit
	unsigned integer). Note that when the issue was discovered, the only		of an unsigned integer). Note that when the issue was discovered,
	configuration of all known implementations being impacted is 16-bit		the only configuration of all known implementations being impacted is
	YCbCr with no Pixel transformation with Range Coder coder, as other		16-bit YCbCr with no Pixel transformation with Range Coder coder, as
	potentially impacted configurations (e.g. 15/16-bit JPEG2000-RCT with		other potentially impacted configurations (e.g. 15/16-bit
	Range Coder coder, or 16-bit content with Golomb Rice coder) were		JPEG2000-RCT with Range Coder coder, or 16-bit content with Golomb
	implemented nowhere [ISO.15444-1.2016]. In the meanwhile, 16-bit		Rice coder) were implemented nowhere [ISO.15444-1.2016]. In the
	JPEG2000-RCT with Range Coder coder was implemented without this		meanwhile, 16-bit JPEG2000-RCT with Range Coder coder was implemented
	issue in one implementation and validated by one conformance checker.		without this issue in one implementation and validated by one
	It is expected (to be confirmed) to remove this exception for the		conformance checker. It is expected (to be confirmed) to remove this
	median predictor in the next version of the FFV1 bitstream.		exception for the median predictor in the next version of the FFV1
			bitstream.
	3.4. Quantization Table Sets		3.4. Quantization Table Sets
			Quantization Tables are used on Sample Differences (see Section 3.8),
			so Quantized Sample Differences are stored in the bitstream.
	The FFV1 bitstream contains one or more Quantization Table Sets.		The FFV1 bitstream contains one or more Quantization Table Sets.
	Each Quantization Table Set contains exactly 5 Quantization Tables		Each Quantization Table Set contains exactly 5 Quantization Tables
	with each Quantization Table corresponding to one of the five		with each Quantization Table corresponding to one of the five
	Quantized Sample Differences. For each Quantization Table, both the		Quantized Sample Differences. For each Quantization Table, both the
	number of quantization steps and their distribution are stored in the		number of quantization steps and their distribution are stored in the
	FFV1 bitstream; each Quantization Table has exactly 256 entries, and		FFV1 bitstream; each Quantization Table has exactly 256 entries, and
	the 8 least significant bits of the Quantized Sample Difference are		the 8 least significant bits of the Quantized Sample Difference are
	used as index:		used as index:
	Q_(j)[k] = quant_tables[i][j][k&255]		Q_(j)[k] = quant_tables[i][j][k&255]
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, line 22 ¶
	An optional transparency Plane can be used to code transparency data.		An optional transparency Plane can be used to code transparency data.
	JPEG2000-RCT is a Reversible Color Transform that codes RGB (red,		JPEG2000-RCT is a Reversible Color Transform that codes RGB (red,
	green, blue) Planes losslessly in a modified YCbCr color space		green, blue) Planes losslessly in a modified YCbCr color space
	[ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr		[ISO.15444-1.2016]. Reversible Pixel transformations between YCbCr
	and RGB use the following formulae.		and RGB use the following formulae.
	Cb = b - g		Cb = b - g
	Cr = r - g		Cr = r - g
	Y = g + (Cb + Cr) >> 2		Y = g + (Cb + Cr) >> 2
			Figure 6: Description of the transformation of pixels from RGB
			color space to coded modified YCbCr color space.
	g = Y - (Cb + Cr) >> 2		g = Y - (Cb + Cr) >> 2
	r = Cr + g		r = Cr + g
	b = Cb + g		b = Cb + g
	Figure 6		Figure 7: Description of the transformation of pixels from coded
			modified YCbCr color space to RGB color space.
	Exception for the JPEG2000-RCT conversion: if "bits_per_raw_sample"
	is between 9 and 15 inclusive and "extra_plane" is 0, the following
	formulae for reversible conversions between YCbCr and RGB MUST be
	used instead of the ones above:
	Cb = g - b
	Cr = r - b
	Y = b +(Cb + Cr) >> 2
	b = Y -(Cb + Cr) >> 2
	r = Cr + b
	g = Cb + b
	Figure 7
	Background: At the time of this writing, in all known implementations
	of FFV1 bitstream, when "bits_per_raw_sample" was between 9 and 15
	inclusive and "extra_plane" is 0, GBR Planes were used as BGR Planes
	during both encoding and decoding. In the meanwhile, 16-bit
	JPEG2000-RCT was implemented without this issue in one implementation
	and validated by one conformance checker. Methods to address this
	exception for the transform are under consideration for the next
	version of the FFV1 bitstream.
	Cb and Cr are positively offset by "1 << bits_per_raw_sample" after		Cb and Cr are positively offset by "1 << bits_per_raw_sample" after
	the conversion from RGB to the modified YCbCr and are negatively		the conversion from RGB to the modified YCbCr and are negatively
	offseted by the same value before the conversion from the modified		offseted by the same value before the conversion from the modified
	YCbCr to RGB, in order to have only non-negative values after the		YCbCr to RGB, in order to have only non-negative values after the
	conversion.		conversion.
	When FFV1 uses the JPEG2000-RCT, the horizontal Lines are interleaved		When FFV1 uses the JPEG2000-RCT, the horizontal Lines are interleaved
	to improve caching efficiency since it is most likely that the		to improve caching efficiency since it is most likely that the
	JPEG2000-RCT will immediately be converted to RGB during decoding.		JPEG2000-RCT will immediately be converted to RGB during decoding.
	skipping to change at page 15, line 28 ¶		skipping to change at page 15, line 19 ¶
	| Pixel(1,2) | Pixel(2,2) |		| Pixel(1,2) | Pixel(2,2) |
	| Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) |		| Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) |
	+------------------------+------------------------+		+------------------------+------------------------+
	In JPEG2000-RCT, the coding order would be left to right and then top		In JPEG2000-RCT, the coding order would be left to right and then top
	to bottom, with values interleaved by Lines and stored in this order:		to bottom, with values interleaved by Lines and stored in this order:
	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)		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)
	Cb(2,2) Cr(1,2) Cr(2,2)		Cb(2,2) Cr(1,2) Cr(2,2)
			3.7.2.1. Exception
			If "bits_per_raw_sample" is between 9 and 15 inclusive and
			"extra_plane" is 0, the following formulae for reversible conversions
			between YCbCr and RGB MUST be used instead of the ones above:
			Cb = g - b
			Cr = r - b
			Y = b + (Cb + Cr) >> 2
			Figure 8: Description of the transformation of pixels from RGB
			color space to coded modified YCbCr color space (in case of
			exception).
			b = Y - (Cb + Cr) >> 2
			r = Cr + b
			g = Cb + b
			Figure 9: Description of the transformation of pixels from coded
			modified YCbCr color space to RGB color space (in case of
			exception).
			Background: At the time of this writing, in all known implementations
			of FFV1 bitstream, when "bits_per_raw_sample" was between 9 and 15
			inclusive and "extra_plane" is 0, GBR Planes were used as BGR Planes
			during both encoding and decoding. In the meanwhile, 16-bit
			JPEG2000-RCT was implemented without this issue in one implementation
			and validated by one conformance checker. Methods to address this
			exception for the transform are under consideration for the next
			version of the FFV1 bitstream.
	3.8. Coding of the Sample Difference		3.8. Coding of the Sample Difference
	Instead of coding the n+1 bits of the Sample Difference with Huffman		Instead of coding the n+1 bits of the Sample Difference with Huffman
	or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the		or Range coding (or n+2 bits, in the case of JPEG2000-RCT), only the
	n (or n+1, in the case of JPEG2000-RCT) least significant bits are		n (or n+1, in the case of JPEG2000-RCT) least significant bits are
	used, since this is sufficient to recover the original Sample. In		used, since this is sufficient to recover the original Sample. In
	the equation below, the term "bits" represents "bits_per_raw_sample +		the equation below, the term "bits" represents "bits_per_raw_sample +
	1" for JPEG2000-RCT or "bits_per_raw_sample" otherwise:		1" for JPEG2000-RCT or "bits_per_raw_sample" otherwise:
	coder_input = [(sample_difference + 2 ^ (bits - 1)) &		coder_input = ((sample_difference + 2 ^ (bits - 1)) &
	(2 ^ bits - 1)] - 2 ^ (bits - 1)		(2 ^ bits - 1)) - 2 ^ (bits - 1)
	Figure 8: Description of the coding of the Sample Difference in		Figure 10: Description of the coding of the Sample Difference in
	the bitstream.		the bitstream.
	3.8.1. Range Coding Mode		3.8.1. Range Coding Mode
	Early experimental versions of FFV1 used the CABAC Arithmetic coder		Early experimental versions of FFV1 used the CABAC Arithmetic coder
	from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain		from H.264 as defined in [ISO.14496-10.2014] but due to the uncertain
	patent/royalty situation, as well as its slightly worse performance,		patent/royalty situation, as well as its slightly worse performance,
	CABAC was replaced by a Range coder based on an algorithm defined by		CABAC was replaced by a Range coder based on an algorithm defined by
	G. Nigel N. Martin in 1979 [range-coding].		G. Nigel N. Martin in 1979 [range-coding].
	3.8.1.1. Range Binary Values		3.8.1.1. Range Binary Values
	To encode binary digits efficiently a Range coder is used. C_(i) is		To encode binary digits efficiently a Range coder is used. C_(i) is
	the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) is		the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) is
	the i-th Range coded binary value, S_(0, i) is the i-th initial		the i-th Range coded binary value, S_(0, i) is the i-th initial
	state. The length of the bytestream encoding n binary symbols is		state. The length of the bytestream encoding n binary symbols is
	j_(n) bytes.		j_(n) bytes.
	r_(i) = floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 )		r_(i) = floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 )
	Figure 9: A formula of the read of a binary value in Range Binary		Figure 11: A formula of the read of a binary value in Range
	mode.		Binary mode.
	S_(i + 1, C_(i)) = zero_state_(S_(i, C_(i))) AND		S_(i + 1, C_(i)) = zero_state_(S_(i, C_(i))) AND
	l_(i) = L_(i) AND		l_(i) = L_(i) AND
	t_(i) = R_(i) - r_(i) <==		t_(i) = R_(i) - r_(i) <==
	b_(i) = 0 <==>		b_(i) = 0 <==>
	L_(i) < R_(i) - r_(i)		L_(i) < R_(i) - r_(i)
	S_(i + 1, C_(i)) = one_state_(S_(i, C_(i))) AND		S_(i + 1, C_(i)) = one_state_(S_(i, C_(i))) AND
	l_(i) = L_(i) - R_(i) + r_(i) AND		l_(i) = L_(i) - R_(i) + r_(i) AND
	t_(i) = r_(i) <==		t_(i) = r_(i) <==
	b_(i) = 1 <==>		b_(i) = 1 <==>
	L_(i) >= R_(i) - r_(i)		L_(i) >= R_(i) - r_(i)
			Figure 12
	Figure 10
	S_(i + 1, k) = S_(i, k) <== C_(i) != k		S_(i + 1, k) = S_(i, k) <== C_(i) != k
	Figure 11		Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if
			the value of "k" is unequal to the i-th value of Context.
	R_(i + 1) = 2 ^ 8 * t_(i) AND		R_(i + 1) = 2 ^ 8 * t_(i) AND
	L_(i + 1) = 2 ^ 8 * l_(i) + B_(j_(i)) AND		L_(i + 1) = 2 ^ 8 * l_(i) + B_(j_(i)) AND
	j_(i + 1) = j_(i) + 1 <==		j_(i + 1) = j_(i) + 1 <==
	t_(i) < 2 ^ 8		t_(i) < 2 ^ 8
	R_(i + 1) = t_(i) AND		R_(i + 1) = t_(i) AND
	L_(i + 1) = l_(i) AND		L_(i + 1) = l_(i) AND
	j_(i + 1) = j_(i) <==		j_(i + 1) = j_(i) <==
	t_(i) >= 2 ^ 8		t_(i) >= 2 ^ 8
	Figure 12		Figure 14: The "i+1"-th values for "Range", "Low", and the length
			of the bytestream encoding are conditionally set depending on the
			"i-th" value of "t".
	R_(0) = 65280		R_(0) = 65280
	Figure 13		Figure 15: The initial value for "Range".
	L_(0) = 2 ^ 8 * B_(0) + B_(1)		L_(0) = 2 ^ 8 * B_(0) + B_(1)
	Figure 14
			Figure 16: The initial value for "Low" is set according to the
			first two bytes of the bytestream.
	j_(0) = 2		j_(0) = 2
	Figure 15		Figure 17: The initial value for "j", the length of the
			bytestream encoding.
	range = 0xFF00;		range = 0xFF00;
	end = 0;		end = 0;
	low = get_bits(16);		low = get_bits(16);
	if (low >= range) {		if (low >= range) {
	low = range;		low = range;
	end = 1;		end = 1;
	}		}
	Figure 16: A pseudo-code description of the initial states in		Figure 18: A pseudo-code description of the initial states in
	Range Binary mode.		Range Binary mode.
	refill() {		refill() {
	if (range < 256) {		if (range < 256) {
	range = range * 256;		range = range * 256;
	low = low * 256;		low = low * 256;
	if (!end) {		if (!end) {
	c.low += get_bits(8);		c.low += get_bits(8);
	if (remaining_bits_in_bitstream( NumBytes ) == 0) {		if (remaining_bits_in_bitstream( NumBytes ) == 0) {
	end = 1;		end = 1;
	}		}
	}		}
	}		}
	}		}
	Figure 17: A pseudo-code description of refilling the Range		Figure 19: A pseudo-code description of refilling the Range
	Binary Value coder buffer.		Binary Value coder buffer.
	get_rac(state) {		get_rac(state) {
	rangeoff = (range * state) / 256;		rangeoff = (range * state) / 256;
	range -= rangeoff;		range -= rangeoff;
	if (low < range) {		if (low < range) {
	state = zero_state[state];		state = zero_state[state];
	refill();		refill();
	return 0;		return 0;
	} else {		} else {
	low -= range;		low -= range;
	state = one_state[state];		state = one_state[state];
	range = rangeoff;		range = rangeoff;
	refill();		refill();
	return 1;		return 1;
	}		}
	}		}
	Figure 18: A pseudo-code description of the read of a binary
			Figure 20: A pseudo-code description of the read of a binary
	value in Range Binary mode.		value in Range Binary mode.
	3.8.1.1.1. Termination		3.8.1.1.1. Termination
	The range coder can be used in three modes.		The range coder can be used in three modes.
	* In "Open mode" when decoding, every Symbol the reader attempts to		* In "Open mode" when decoding, every Symbol the reader attempts to
	read is available. In this mode arbitrary data can have been		read is available. In this mode arbitrary data can have been
	appended without affecting the range coder output. This mode is		appended without affecting the range coder output. This mode is
	not used in FFV1.		not used in FFV1.
	skipping to change at page 19, line 17 ¶		skipping to change at page 19, line 41 ¶
	To encode scalar integers, it would be possible to encode each bit		To encode scalar integers, it would be possible to encode each bit
	separately and use the past bits as context. However that would mean		separately and use the past bits as context. However that would mean
	255 contexts per 8-bit Symbol that is not only a waste of memory but		255 contexts per 8-bit Symbol that is not only a waste of memory but
	also requires more past data to reach a reasonably good estimate of		also requires more past data to reach a reasonably good estimate of
	the probabilities. Alternatively assuming a Laplacian distribution		the probabilities. Alternatively assuming a Laplacian distribution
	and only dealing with its variance and mean (as in Huffman coding)		and only dealing with its variance and mean (as in Huffman coding)
	would also be possible, however, for maximum flexibility and		would also be possible, however, for maximum flexibility and
	simplicity, the chosen method uses a single Symbol to encode if a		simplicity, the chosen method uses a single Symbol to encode if a
	number is 0, and if not, encodes the number using its exponent,		number is 0, and if not, encodes the number using its exponent,
	mantissa and sign. The exact contexts used are best described by		mantissa and sign. The exact contexts used are best described by
	Figure 19.		Figure 21.
	int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) {		int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) {
	if (get_rac(c, state + 0) {		if (get_rac(c, state + 0) {
	return 0;		return 0;
	}		}
	int e = 0;		int e = 0;
	while (get_rac(c, state + 1 + min(e, 9)) { //1..10		while (get_rac(c, state + 1 + min(e, 9)) { //1..10
	e++;		e++;
	}		}
	skipping to change at page 19, line 45 ¶		skipping to change at page 20, line 31 ¶
	return a;		return a;
	}		}
	if (get_rac(c, state + 11 + min(e, 10))) { //11..21		if (get_rac(c, state + 11 + min(e, 10))) { //11..21
	return -a;		return -a;
	} else {		} else {
	return a;		return a;
	}		}
	}		}
	Figure 19: A pseudo-code description of the contexts of Range Non		Figure 21: A pseudo-code description of the contexts of Range Non
	Binary Values.		Binary Values.
	"get_symbol" is used for the read out of "sample_difference"		"get_symbol" is used for the read out of "sample_difference"
	indicated in Figure 8.		indicated in Figure 10.
	"get_rac" returns a boolean, computed from the bytestream as		"get_rac" returns a boolean, computed from the bytestream as
	described in Figure 9 as a formula and in Figure 18 as pseudo-code.		described in Figure 11 as a formula and in Figure 20 as pseudo-code.
	3.8.1.3. Initial Values for the Context Model		3.8.1.3. Initial Values for the Context Model
	When "keyframe" (see Section 4.4) value is 1, all Range coder state		When "keyframe" (see Section 4.4) value is 1, all Range coder state
	variables are set to their initial state.		variables are set to their initial state.
	3.8.1.4. State Transition Table		3.8.1.4. State Transition Table
			In this mode a State Transition Table is used, indicating in which
			state the decoder will move to, based on the current state and the
			value extracted from Figure 20.
	one_state_(i) =		one_state_(i) =
	default_state_transition_(i) + state_transition_delta_(i)		default_state_transition_(i) + state_transition_delta_(i)
			Figure 22
	Figure 20
	zero_state_(i) = 256 - one_state_(256-i)		zero_state_(i) = 256 - one_state_(256-i)
	Figure 21		Figure 23
	3.8.1.5. default_state_transition		3.8.1.5. default_state_transition
			By default, the following State Transition Table is used:
	0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27,		0, 0, 0, 0, 0, 0, 0, 0, 20, 21, 22, 23, 24, 25, 26, 27,
	28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42,		28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 37, 38, 39, 40, 41, 42,
	43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57,		43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 56, 57,
	58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,		58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
	74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,		74, 75, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
	skipping to change at page 21, line 43 ¶		skipping to change at page 22, line 12 ¶
	241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0,		241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0,
	3.8.1.6. Alternative State Transition Table		3.8.1.6. Alternative State Transition Table
	The alternative state transition table has been built using iterative		The alternative state transition table has been built using iterative
	minimization of frame sizes and generally performs better than the		minimization of frame sizes and generally performs better than the
	default. To use it, the "coder_type" (see Section 4.2.3) MUST be set		default. To use it, the "coder_type" (see Section 4.2.3) MUST be set
	to 2 and the difference to the default MUST be stored in the		to 2 and the difference to the default MUST be stored in the
	"Parameters", see Section 4.2. The reference implementation of FFV1		"Parameters", see Section 4.2. The reference implementation of FFV1
	in FFmpeg uses Figure 22 by default at the time of this writing when		in FFmpeg uses Figure 24 by default at the time of this writing when
	Range coding is used.		Range coding is used.
	0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49,		0, 10, 10, 10, 10, 16, 16, 16, 28, 16, 16, 29, 42, 49, 20, 49,
	59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39,		59, 25, 26, 26, 27, 31, 33, 33, 33, 34, 34, 37, 67, 38, 39, 39,
	40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52,		40, 40, 41, 79, 43, 44, 45, 45, 48, 48, 64, 50, 51, 52, 88, 52,
	53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69,		53, 74, 55, 57, 58, 58, 74, 60,101, 61, 62, 84, 66, 66, 68, 69,
	skipping to change at page 22, line 37 ¶		skipping to change at page 22, line 47 ¶
	175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196,		175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196,
	197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214,		197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214,
	209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225,		209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225,
	226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242,		226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242,
	241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255,		241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255,
	Figure 22: Alternative state transition table for Range coding.		Figure 24: Alternative state transition table for Range coding.
	3.8.2. Golomb Rice Mode		3.8.2. Golomb Rice Mode
	The end of the bitstream of the Frame is padded with 0-bits until the		The end of the bitstream of the Frame is padded with 0-bits until the
	bitstream contains a multiple of 8 bits.		bitstream contains a multiple of 8 bits.
	3.8.2.1. Signed Golomb Rice Codes		3.8.2.1. Signed Golomb Rice Codes
	This coding mode uses Golomb Rice codes. The VLC is split into two		This coding mode uses Golomb Rice codes. The VLC is split into two
	parts. The prefix stores the most significant bits and the suffix		parts. The prefix stores the most significant bits and the suffix
	skipping to change at page 23, line 14 ¶		skipping to change at page 23, line 21 ¶
	int get_ur_golomb(k) {		int get_ur_golomb(k) {
	for (prefix = 0; prefix < 12; prefix++) {		for (prefix = 0; prefix < 12; prefix++) {
	if (get_bits(1)) {		if (get_bits(1)) {
	return get_bits(k) + (prefix << k);		return get_bits(k) + (prefix << k);
	}		}
	}		}
	return get_bits(bits) + 11;		return get_bits(bits) + 11;
	}		}
	Figure 23: A pseudo-code description of the read of an unsigned		Figure 25: A pseudo-code description of the read of an unsigned
	integer in Golomb Rice mode.		integer in Golomb Rice mode.
	int get_sr_golomb(k) {		int get_sr_golomb(k) {
	v = get_ur_golomb(k);		v = get_ur_golomb(k);
	if (v & 1) return - (v >> 1) - 1;		if (v & 1) return - (v >> 1) - 1;
	else return (v >> 1);		else return (v >> 1);
	}		}
	Figure 24: A pseudo-code description of the read of a signed		Figure 26: A pseudo-code description of the read of a signed
	integer in Golomb Rice mode.		integer in Golomb Rice mode.
	3.8.2.1.1. Prefix		3.8.2.1.1. Prefix
	+================+=======+		+================+=======+
	| bits | value |		| bits | value |
	+================+=======+		+================+=======+
	| 1 | 0 |		| 1 | 0 |
	+----------------+-------+		+----------------+-------+
	| 01 | 1 |		| 01 | 1 |
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 27 ¶
	+----------------+-------+		+----------------+-------+
	| 0000 0000 001 | 10 |		| 0000 0000 001 | 10 |
	+----------------+-------+		+----------------+-------+
	| 0000 0000 0001 | 11 |		| 0000 0000 0001 | 11 |
	+----------------+-------+		+----------------+-------+
	| 0000 0000 0000 | ESC |		| 0000 0000 0000 | ESC |
	+----------------+-------+		+----------------+-------+
	Table 1		Table 1
			"ESC" is an ESCape Symbol to indicate that the Symbol to be stored is
			too large for normal storage and that an alternate storage method is
			used.
	3.8.2.1.2. Suffix		3.8.2.1.2. Suffix
	+=========+========================================+		+=========+========================================+
	+=========+========================================+		+=========+========================================+
	| non ESC | the k least significant bits MSB first |		| non ESC | the k least significant bits MSB first |
	+---------+----------------------------------------+		+---------+----------------------------------------+
	| ESC | the value - 11, in MSB first order |		| ESC | the value - 11, in MSB first order |
	+---------+----------------------------------------+		+---------+----------------------------------------+
	Table 2		Table 2
	skipping to change at page 31, line 17 ¶		skipping to change at page 31, line 17 ¶
	"context_count[ i ]" indicates the count of contexts for Quantization		"context_count[ i ]" indicates the count of contexts for Quantization
	Table Set "i". "context_count[ i ]" MUST be less than or equal to		Table Set "i". "context_count[ i ]" MUST be less than or equal to
	32768.		32768.
	4.2. Parameters		4.2. Parameters
	The "Parameters" section contains significant characteristics about		The "Parameters" section contains significant characteristics about
	the decoding configuration used for all instances of Frame (in FFV1		the decoding configuration used for all instances of Frame (in FFV1
	version 0 and 1) or the whole FFV1 bitstream (other versions),		version 0 and 1) or the whole FFV1 bitstream (other versions),
	including the stream version, color configuration, and quantization		including the stream version, color configuration, and quantization
	tables. Figure 25 describes the contents of the bitstream.		tables. Figure 27 describes the contents of the bitstream.
	"Parameters" has its own initial states, all set to 128.		"Parameters" has its own initial states, all set to 128.
	pseudo-code | type		pseudo-code | type
	--------------------------------------------------------------|-----		--------------------------------------------------------------|-----
	Parameters( ) { |		Parameters( ) { |
	version | ur		version | ur
	if (version >= 3) { |		if (version >= 3) { |
	micro_version | ur		micro_version | ur
	} |		} |
	skipping to change at page 32, line 50 ¶		skipping to change at page 32, line 50 ¶
	initial_state_delta[ i ][ j ][ k ] | sr		initial_state_delta[ i ][ j ][ k ] | sr
	} |		} |
	} |		} |
	} |		} |
	} |		} |
	ec | ur		ec | ur
	intra | ur		intra | ur
	} |		} |
	} |		} |
	Figure 25: A pseudo-code description of the bitstream contents.		Figure 27: A pseudo-code description of the bitstream contents.
	CONTEXT_SIZE is 32.		CONTEXT_SIZE is 32.
	4.2.1. version		4.2.1. version
	"version" specifies the version of the FFV1 bitstream.		"version" specifies the version of the FFV1 bitstream.
	Each version is incompatible with other versions: decoders SHOULD		Each version is incompatible with other versions: decoders SHOULD
	reject FFV1 bitstreams due to an unknown version.		reject FFV1 bitstreams due to an unknown version.
	skipping to change at page 38, line 46 ¶		skipping to change at page 38, line 46 ¶
	Table 13		Table 13
	4.2.15. initial_state_delta		4.2.15. initial_state_delta
	"initial_state_delta[ i ][ j ][ k ]" indicates the initial Range		"initial_state_delta[ i ][ j ][ k ]" indicates the initial Range
	coder state, it is encoded using "k" as context index and		coder state, it is encoded using "k" as context index and
	pred = j ? initial_states[ i ][j - 1][ k ] : 128		pred = j ? initial_states[ i ][j - 1][ k ] : 128
	Figure 26		Figure 28
	initial_state[ i ][ j ][ k ] =		initial_state[ i ][ j ][ k ] =
	( pred + initial_state_delta[ i ][ j ][ k ] ) & 255		( pred + initial_state_delta[ i ][ j ][ k ] ) & 255
	Figure 27		Figure 29
	4.2.16. ec		4.2.16. ec
	"ec" indicates the error detection/correction type.		"ec" indicates the error detection/correction type.
	+=======+=================================================+		+=======+=================================================+
	| value | error detection/correction type |		| value | error detection/correction type |
	+=======+=================================================+		+=======+=================================================+
	| 0 | 32-bit CRC in "ConfigurationRecord" |		| 0 | 32-bit CRC in "ConfigurationRecord" |
	+-------+-------------------------------------------------+		+-------+-------------------------------------------------+
	skipping to change at page 51, line 21 ¶		skipping to change at page 51, line 21 ¶
	a slice in the previous Frame, except if "reset_contexts" is 1.		a slice in the previous Frame, except if "reset_contexts" is 1.
	6. Security Considerations		6. Security Considerations
	Like any other codec, (such as [RFC6716]), FFV1 should not be used		Like any other codec, (such as [RFC6716]), FFV1 should not be used
	with insecure ciphers or cipher-modes that are vulnerable to known		with insecure ciphers or cipher-modes that are vulnerable to known
	plaintext attacks. Some of the header bits as well as the padding		plaintext attacks. Some of the header bits as well as the padding
	are easily predictable.		are easily predictable.
	Implementations of the FFV1 codec need to take appropriate security		Implementations of the FFV1 codec need to take appropriate security
	considerations into account, as outlined in [RFC4732]. It is		considerations into account. Those related to denial of service are
	extremely important for the decoder to be robust against malicious		outlined in Section 2.1 of [RFC4732]. It is extremely important for
	payloads. Malicious payloads MUST NOT cause the decoder to overrun		the decoder to be robust against malicious payloads. Malicious
	its allocated memory or to take an excessive amount of resources to		payloads MUST NOT cause the decoder to overrun its allocated memory
	decode. The same applies to the encoder, even though problems in		or to take an excessive amount of resources to decode. An overrun in
			allocated memory could lead to arbitrary code execution by an
			attacker. The same applies to the encoder, even though problems in
	encoders are typically rarer. Malicious video streams MUST NOT cause		encoders are typically rarer. Malicious video streams MUST NOT cause
	the encoder to misbehave because this would allow an attacker to		the encoder to misbehave because this would allow an attacker to
	attack transcoding gateways. A frequent security problem in image		attack transcoding gateways. A frequent security problem in image
	and video codecs is failure to check for integer overflows. An		and video codecs is failure to check for integer overflows. An
	example is allocating "frame_pixel_width * frame_pixel_height" in		example is allocating "frame_pixel_width * frame_pixel_height" in
	Pixel count computations without considering that the multiplication		Pixel count computations without considering that the multiplication
	result may have overflowed the arithmetic types range. The range		result may have overflowed the arithmetic types range. The range
	coder could, if implemented naively, read one byte over the end. The		coder could, if implemented naively, read one byte over the end. The
	implementation MUST ensure that no read outside allocated and		implementation MUST ensure that no read outside allocated and
	initialized memory occurs.		initialized memory occurs.
	None of the content carried in FFV1 is intended to be executable.		None of the content carried in FFV1 is intended to be executable.
	The reference implementation [REFIMPL] contains no known buffer
	overflow or cases where a specially crafted packet or video segment
	could cause a significant increase in CPU load.
	The reference implementation [REFIMPL] was validated in the following
	conditions:
	* Sending the decoder valid packets generated by the reference
	encoder and verifying that the decoder's output matches the
	encoder's input.
	* Sending the decoder packets generated by the reference encoder and
	then subjected to random corruption.
	* Sending the decoder random packets that are not FFV1.
	In all of the conditions above, the decoder and encoder was run
	inside the [VALGRIND] memory debugger as well as clangs address
	sanitizer [Address-Sanitizer], which track reads and writes to
	invalid memory regions as well as the use of uninitialized memory.
	There were no errors reported on any of the tested conditions.
	7. IANA Considerations		7. IANA Considerations
	The IANA is requested to register the following values:		The IANA is requested to register the following values:
	7.1. Media Type Definition		7.1. Media Type Definition
	This registration is done using the template defined in [RFC6838] and		This registration is done using the template defined in [RFC6838] and
	following [RFC4855].		following [RFC4855].
	Type name: video		Type name: video
	skipping to change at page 54, line 49 ¶		skipping to change at page 54, line 28 ¶
	10. Informative References		10. Informative References
	[Address-Sanitizer]		[Address-Sanitizer]
	The Clang Team, "ASAN AddressSanitizer website", undated,		The Clang Team, "ASAN AddressSanitizer website", undated,
	<https://clang.llvm.org/docs/AddressSanitizer.html>.		<https://clang.llvm.org/docs/AddressSanitizer.html>.
	[AVI] Microsoft, "AVI RIFF File Reference", undated,		[AVI] Microsoft, "AVI RIFF File Reference", undated,
	<https://msdn.microsoft.com/en-us/library/windows/desktop/		<https://msdn.microsoft.com/en-us/library/windows/desktop/
	dd318189%28v=vs.85%29.aspx>.		dd318189%28v=vs.85%29.aspx>.
			[FFV1GO] Buitenhuis, D., "FFV1 Decoder in Go", 2019,
			<https://github.com/dwbuiten/go-ffv1>.
	[HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003,		[HuffYUV] Rudiak-Gould, B., "HuffYUV", December 2003,
	<https://web.archive.org/web/20040402121343/		<https://web.archive.org/web/20040402121343/
	http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>.		http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>.
	[I-D.ietf-cellar-ffv1]		[I-D.ietf-cellar-ffv1]
	Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video		Niedermayer, M., Rice, D., and J. Martinez, "FFV1 Video
	Coding Format Version 0, 1, and 3", Work in Progress,		Coding Format Version 0, 1, and 3", Work in Progress,
	Internet-Draft, draft-ietf-cellar-ffv1-17, 21 August 2020,		Internet-Draft, draft-ietf-cellar-ffv1-18, 7 October 2020,
	<https://tools.ietf.org/html/draft-ietf-cellar-ffv1-17>.		<https://tools.ietf.org/html/draft-ietf-cellar-ffv1-18>.
	[ISO.14495-1.1999]		[ISO.14495-1.1999]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- Lossless and near-lossless		"Information technology -- Lossless and near-lossless
	compression of continuous-tone still images: Baseline",		compression of continuous-tone still images: Baseline",
	December 1999.		December 1999.
	[ISO.14496-10.2014]		[ISO.14496-10.2014]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- Coding of audio-visual objects		"Information technology -- Coding of audio-visual objects
	-- Part 10: Advanced Video Coding", September 2014.		-- Part 10: Advanced Video Coding", September 2014.
	[ISO.14496-12.2015]		[ISO.14496-12.2015]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- Coding of audio-visual objects		"Information technology -- Coding of audio-visual objects
	-- Part 12: ISO base media file format", December 2015.		-- Part 12: ISO base media file format", December 2015.
			[MediaConch]
			MediaArea.net, "MediaConch", 2018,
			<https://mediaarea.net/MediaConch>.
	[NUT] Niedermayer, M., "NUT Open Container Format", December		[NUT] Niedermayer, M., "NUT Open Container Format", December
	2013, <https://ffmpeg.org/~michael/nut.txt>.		2013, <https://ffmpeg.org/~michael/nut.txt>.
	[range-coding]		[range-coding]
	Martin, G. N. N., "Range encoding: an algorithm for		Martin, G. N. N., "Range encoding: an algorithm for
	removing redundancy from a digitised message", Proceedings		removing redundancy from a digitised message", Proceedings
	of the Conference on Video and Data Recording. Institution		of the Conference on Video and Data Recording. Institution
	of Electronic and Radio Engineers, Hampshire, England,		of Electronic and Radio Engineers, Hampshire, England,
	July 1979.		July 1979.
	skipping to change at page 56, line 31 ¶		skipping to change at page 56, line 18 ¶
	This appendix is informative.		This appendix is informative.
	Some bitstreams were found with 40 extra bits corresponding to		Some bitstreams were found with 40 extra bits corresponding to
	"error_status" and "slice_crc_parity" in the "reserved" bits of		"error_status" and "slice_crc_parity" in the "reserved" bits of
	"Slice()". Any revision of this specification SHOULD care about		"Slice()". Any revision of this specification SHOULD care about
	avoiding to add 40 bits of content after "SliceContent" if "version"		avoiding to add 40 bits of content after "SliceContent" if "version"
	== 0 or "version" == 1. Else a decoder conforming to the revised		== 0 or "version" == 1. Else a decoder conforming to the revised
	specification could not distinguish between a revised bitstream and		specification could not distinguish between a revised bitstream and
	such buggy bitstream in the wild.		such buggy bitstream in the wild.
			Appendix C. FFV1 Implementations
			This appendix provides references to a few notable implementations of
			FFV1.
			C.1. FFmpeg FFV1 Codec
			This reference implementation [REFIMPL] contains no known buffer
			overflow or cases where a specially crafted packet or video segment
			could cause a significant increase in CPU load.
			The reference implementation [REFIMPL] was validated in the following
			conditions:
			* Sending the decoder valid packets generated by the reference
			encoder and verifying that the decoder's output matches the
			encoder's input.
			* Sending the decoder packets generated by the reference encoder and
			then subjected to random corruption.
			* Sending the decoder random packets that are not FFV1.
			In all of the conditions above, the decoder and encoder was run
			inside the [VALGRIND] memory debugger as well as clangs address
			sanitizer [Address-Sanitizer], which track reads and writes to
			invalid memory regions as well as the use of uninitialized memory.
			There were no errors reported on any of the tested conditions.
			C.2. FFV1 Decoder in Go
			An FFV1 decoder was [FFV1GO] written in Go by Derek Buitenhuis during
			the work to development this document.
			C.3. MediaConch
			The developers of the MediaConch project [MediaConch] created an
			independent FFV1 decoder as part of that project to validate FFV1
			bitstreams. This work led to the discovery of three conflicts
			between existing FFV1 implementations and this document without the
			added exceptions.
	Authors' Addresses		Authors' Addresses
	Michael Niedermayer		Michael Niedermayer
	Email: michael@niedermayer.cc		Email: michael@niedermayer.cc
	Dave Rice		Dave Rice
	Email: dave@dericed.com		Email: dave@dericed.com
End of changes. 52 change blocks.
	115 lines changed or deleted		180 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/