[要約] RFC 9043はFFV1ビデオコーディングフォーマットのバージョン0、1、および3を定義しています。このフォーマットは、高い圧縮率と逆変換可能なロスレスビデオ圧縮を目的としています。主にアーカイブやプロフェッショナルなビデオ編集で利用されます。
Internet Engineering Task Force (IETF) M. Niedermayer
Request for Comments: 9043
Category: Informational D. Rice
ISSN: 2070-1721
J. Martinez
August 2021
FFV1 Video Coding Format Versions 0, 1, and 3
FFV1ビデオコーディングフォーマットバージョン0,1、および3
Abstract
概要
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.
このドキュメントはFFv1、ロスレス、フレーム内ビデオエンコードフォーマットを定義します。FFV1は、さまざまなピクセルフォーマットでビデオデータを効率的に圧縮するように設計されています。非圧縮ビデオと比較して、FFV1はストレージ圧縮、フレーム固定、および自己記述を提供します。これにより、FFV1は保存または中間ビデオフォーマットとして役立ちます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9043.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9043で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Notation and Conventions
2.1. Definitions
2.2. Conventions
2.2.1. Pseudocode
2.2.2. Arithmetic Operators
2.2.3. Assignment Operators
2.2.4. Comparison Operators
2.2.5. Mathematical Functions
2.2.6. Order of Operation Precedence
2.2.7. Range
2.2.8. NumBytes
2.2.9. Bitstream Functions
3. Sample Coding
3.1. Border
3.2. Samples
3.3. Median Predictor
3.3.1. Exception
3.4. Quantization Table Sets
3.5. Context
3.6. Quantization Table Set Indexes
3.7. Color Spaces
3.7.1. YCbCr
3.7.2. RGB
3.8. Coding of the Sample Difference
3.8.1. Range Coding Mode
3.8.2. Golomb Rice Mode
4. Bitstream
4.1. Quantization Table Set
4.1.1. "quant_tables"
4.1.2. "context_count"
4.2. Parameters
4.2.1. "version"
4.2.2. "micro_version"
4.2.3. "coder_type"
4.2.4. "state_transition_delta"
4.2.5. "colorspace_type"
4.2.6. "chroma_planes"
4.2.7. "bits_per_raw_sample"
4.2.8. "log2_h_chroma_subsample"
4.2.9. "log2_v_chroma_subsample"
4.2.10. "extra_plane"
4.2.11. "num_h_slices"
4.2.12. "num_v_slices"
4.2.13. "quant_table_set_count"
4.2.14. "states_coded"
4.2.15. "initial_state_delta"
4.2.16. "ec"
4.2.17. "intra"
4.3. Configuration Record
4.3.1. "reserved_for_future_use"
4.3.2. "configuration_record_crc_parity"
4.3.3. Mapping FFV1 into Containers
4.4. Frame
4.5. Slice
4.6. Slice Header
4.6.1. "slice_x"
4.6.2. "slice_y"
4.6.3. "slice_width"
4.6.4. "slice_height"
4.6.5. "quant_table_set_index_count"
4.6.6. "quant_table_set_index"
4.6.7. "picture_structure"
4.6.8. "sar_num"
4.6.9. "sar_den"
4.7. Slice Content
4.7.1. "primary_color_count"
4.7.2. "plane_pixel_height"
4.7.3. "slice_pixel_height"
4.7.4. "slice_pixel_y"
4.8. Line
4.8.1. "plane_pixel_width"
4.8.2. "slice_pixel_width"
4.8.3. "slice_pixel_x"
4.8.4. "sample_difference"
4.9. Slice Footer
4.9.1. "slice_size"
4.9.2. "error_status"
4.9.3. "slice_crc_parity"
5. Restrictions
6. Security Considerations
7. IANA Considerations
7.1. Media Type Definition
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Multithreaded Decoder Implementation Suggestions
Appendix B. Future Handling of Some Streams Created by
Nonconforming Encoders
Appendix C. FFV1 Implementations
C.1. FFmpeg FFV1 Codec
C.2. FFV1 Decoder in Go
C.3. MediaConch
Authors' Addresses
This document describes FFV1, a lossless video encoding format. The design of FFV1 considers the storage of image characteristics, data fixity, and the optimized use of encoding time and storage requirements. FFV1 is designed to support a wide range of lossless video applications such as long-term audiovisual preservation, scientific imaging, screen recording, and other video encoding scenarios that seek to avoid the generational loss of lossy video encodings.
この文書では、FFv1、無損失ビデオエンコーディング形式について説明します。FFV1の設計は、画像特性、データ固定、および符号化時間と記憶域要件の最適化された使用の記憶を考慮しています。FFV1は、長期的な視聴覚保存、科学的イメージング、スクリーン記録、および損失のあるビデオエンコーディングの世代損失を回避しようとする他のビデオエンコードシナリオなどの幅広いロスレスビデオアプリケーションをサポートするように設計されています。
This document defines versions 0, 1, and 3 of FFV1. The distinctions of the versions are provided throughout the document, but in summary:
この文書はFFV1のバージョン0,1、および3を定義します。バージョンの区別は文書全体にわたって提供されますが、概要：
* Version 0 of FFV1 was the original implementation of FFV1 and was flagged as stable on April 14, 2006 [FFV1_V0].
* FFV1のバージョン0はFFV1の元の実装であり、2006年4月14日に安定してフラグが立てられました[FFV1_V0]。
* Version 1 of FFV1 adds support of more video bit depths and was flagged as stable on April 24, 2009 [FFV1_V1].
* FFV1のバージョン1は、より多くのビデオビット深さのサポートを追加し、2009年4月24日、[FFV1_v1]で安定したフラグを立てました。
* Version 2 of FFV1 only existed in experimental form and is not described by this document, but it is available as a LyX file at <https://github.com/FFmpeg/FFV1/ blob/8ad772b6d61c3dd8b0171979a2cd9f11924d5532/ffv1.lyx>.
* FFV1のバージョン2は実験形式でのみ存在しており、この文書では説明されていませんが、<https：//github.com/ffmpeg/ffv1/blob / 8ad772b6d61c3dd8b017979a2cd9f11924d5532 / ffv1.lyx>のLYXファイルとして入手できます。
* Version 3 of FFV1 adds several features such as increased description of the characteristics of the encoding images and embedded Cyclic Redundancy Check (CRC) data to support fixity verification of the encoding. Version 3 was flagged as stable on August 17, 2013 [FFV1_V3].
* FFV1のバージョン3は、符号化画像の特性の記述の詳細、埋め込み巡回冗長検査（CRC）データの記述など、エンコードの固定検証をサポートするいくつかの機能を追加します。バージョン3は、2013年8月17日に安定したフラグを付けられました[FFV1_v3]。
This document assumes familiarity with mathematical and coding concepts such as Range encoding [Range-Encoding] and YCbCr color spaces [YCbCr].
この文書は、範囲符号化[範囲符号化]やYCBCR色空間[YCBCR]などの数学的および符号化概念に精通している。
This specification describes the valid bitstream and how to decode it. Nonconformant bitstreams and the nonconformant handling of bitstreams are outside this specification. A decoder can perform any action that it deems appropriate for an invalid bitstream: reject the bitstream, attempt to perform error concealment, or re-download or use a redundant copy of the invalid part.
この仕様では、有効なビットストリームと復号方法について説明します。不適合ビットストリームとビットストリームの不適合的な処理はこの仕様の外側にあります。デコーダは、無効なビットストリームに適していると判断する任意の動作を実行できます。ビットストリームを拒否し、エラーの隠蔽を実行したり、無効な部分の冗長コピーを再ダウンロードしたりします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
FFV1: The chosen name of this video encoding format, which is the short version of "FF Video 1". The letters "FF" come from "FFmpeg", which is the name of the reference decoder whose first letters originally meant "Fast Forward".
FFV1：このビデオエンコーディングフォーマットの選択された名前。 "FFビデオ1"の短版です。文字「FF」は「FFMPEG」から来ており、これは最初の文字が最初に「早送り」を意味している参照復号器の名前です。
Container: A format that encapsulates Frames (see Section 4.4) and (when required) a "Configuration Record" into a bitstream.
コンテナ：フレームをカプセル化するフォーマット（セクション4.4）と（必要な場合）ビットストリームへの「設定レコード」を参照してください。
Sample: The smallest addressable representation of a color component or a luma component in a Frame. Examples of Sample are Luma (Y), Blue-difference Chroma (Cb), Red-difference Chroma (Cr), Transparency, Red, Green, and Blue.
サンプル：フレーム内の色成分またはLUMA成分の最小のアドレス指定可能な表現。サンプルの例は、LUMA（Y）、青色差クロマ（CB）、赤色差クロマ（CR）、透明度、赤、緑、および青である。
Symbol: A value stored in the bitstream, which is defined and decoded through one of the methods described in Table 4.
シンボル：ビットストリームに格納されている値。表4に記載されている方法のうちの1つを通して定義および復号化されます。
Line: A discrete component of a static image composed of Samples that represent a specific quantification of Samples of that image.
線：その画像のサンプルの特定の定量化を表すサンプルからなる静的画像の離散成分。
Plane: A discrete component of a static image composed of Lines that represent a specific quantification of Lines of that image.
平面：その画像の線の特定の定量化を表す線からなる静的画像の離散的な構成要素。
Pixel: The smallest addressable representation of a color in a Frame. It is composed of one or more Samples.
ピクセル：フレーム内の色の最も小さいアドレス指定可能な表現。それは1つ以上のサンプルからなる。
MSB: Most Significant Bit, the bit that can cause the largest change in magnitude of the symbol.
MSB：最上位ビット、シンボルの大きさの最大の変更を引き起こす可能性があるビット。
VLC: Variable Length Code, a code that maps source symbols to a variable number of bits.
VLC：可変長コード、ソースシンボルを可変数のビット数にマッピングするコード。
RGB: A reference to the method of storing the value of a pixel by using three numeric values that represent Red, Green, and Blue.
RGB：赤、緑、青を表す3つの数値を用いて、画素の値を格納する方法への参照。
YCbCr: A reference to the method of storing the value of a pixel by using three numeric values that represent the luma of the pixel (Y) and the chroma of the pixel (Cb and Cr). The term YCbCr is used for historical reasons and currently references any color space relying on one luma Sample and two chroma Samples, e.g., YCbCr (luma, blue-difference chroma, red-difference chroma), YCgCo, or ICtCp (intensity, blue-yellow, red-green).
YCBCR：画素（Y）の輝度を表す3つの数値と画素の彩度（CBとCR）を用いて画素の値を格納する方法への参照。YCBCRという用語は歴史的な理由で使用されており、現在1つのLUMAサンプルと2つのクロマサンプル、例えばYCBCR（Luma、青色差クロマ、赤差彩度彩度）、YCGCO、またはICTCPの2つの任意の色空間を参照しています（強度、青 - 黄色、赤緑）。
The FFV1 bitstream is described in this document using pseudocode. Note that the pseudocode is used to illustrate the structure of FFV1 and is not intended to specify any particular implementation. The pseudocode used is based upon the C programming language [ISO.9899.2018] and uses its "if/else", "while", and "for" keywords as well as functions defined within this document.
FFV1ビットストリームは、疑似コードを使用してこの文書に記載されています。疑似コードはFFV1の構造を説明するために使用され、特定の実装を指定することを意図していないことに注意してください。使用されている疑似コードは、Cプログラミング言語[ISO.9899.2018]に基づいており、その「if / else」、「while」、および「for」キーワード、およびこの文書内で定義された関数を使用しています。
In some instances, pseudocode is presented in a two-column format such as shown in Figure 1. In this form, the "type" column provides a symbol as defined in Table 4 that defines the storage of the data referenced in that same line of pseudocode.
場合によっては、疑似コードは図1に示すような2列の形式で表示されます。この形式では、「Type」列は表4に定義されているシンボルを表4に示します。擬似コード
pseudocode | type
--------------------------------------------------------------|-----
ExamplePseudoCode( ) { |
value | ur
} |
Figure 1: A depiction of type-labeled pseudocode used within this document.
図1：この文書内で使用されているタイプラベル付き擬似コードの描写。
Note: the operators and the order of precedence are the same as used in the C programming language [ISO.9899.2018], with the exception of ">>" (removal of implementation-defined behavior) and "^" (power instead of XOR) operators, which are redefined within this section.
注：演算子と優先順位の順序は、「>>」（実装定義の動作の取り外し）と "^"（XORの代わりに）を除いて、Cプログラミング言語[ISO.9899.2018]で使用されているものと同じです。このセクションで再定義されている演算子。
"a + b" means a plus b.
「A B」はプラスBを意味する。
"a - b" means a minus b.
「A - B」はマイナスBを意味する。
"-a" means negation of a.
"-a"はaの否定を意味します。
"a * b" means a multiplied by b.
「a * b」とは、bを乗算したことを意味する。
"a / b" means a divided by b.
「a / b」はbで割ったものを意味する。
"a ^ b" means a raised to the b-th power.
「a ^ b」とは、b番目の電力に上昇することを意味する。
"a & b" means bitwise "and" of a and b.
「A＆B」は、AとBのビットごとの「AND」を意味します。
"a | b" means bitwise "or" of a and b.
「A | B」は、AとBのビット単位「または」を意味する。
"a >> b" means arithmetic right shift of the two's complement integer representation of a by b binary digits. This is equivalent to dividing a by 2, b times, with rounding toward negative infinity.
「A >> B」は、B 2進数の2の補数整数表現の算術右シフトを意味します。これは、負の無限大に丸めて、2 B回、B倍を分割することと等価です。
"a << b" means arithmetic left shift of the two's complement integer representation of a by b binary digits.
「<< B」とは、B 2の2進数の2つの補数整数表現の算術左シフトを意味する。
"a = b" means a is assigned b.
「a = b」とは、aを割り当てられていることを意味する。
"a++" is equivalent to a is assigned a + 1.
「a」がAに相当するA 1に相当する。
"a--" is equivalent to a is assigned a - 1.
"a--"がA - 1に相当する。
"a += b" is equivalent to a is assigned a + b.
「a = b」はAに等価である。
"a -= b" is equivalent to a is assigned a - b.
「a - = b」がA - Bに相当する。
"a *= b" is equivalent to a is assigned a * b.
「a * = b」がA * Bに相当する。
"a > b" is true when a is greater than b.
AがBより大きい場合、「A> B」は真実です。
"a >= b" is true when a is greater than or equal to b.
aがb以上の場合、 "A> = b"は真です。
"a < b" is true when a is less than b.
A aがb未満の場合、「a <b」は当てはまる。
"a <= b" is true when a is less than or equal b.
A <= B」は、aがb以下の場合に該当する。
"a == b" is true when a is equal to b.
A aがbに等しい場合、 "A == B"は真です。
"a != b" is true when a is not equal to b.
"a！= b"は、aがbに等しくないときに該当です。
"a && b" is true when both a is true and b is true.
aが真実であり、bの両方が真実である場合は、「A && B」が真です。
"a || b" is true when either a is true or b is true.
"A || b"がtrueまたはbのどちらかがtrueの場合、trueです。
"!a" is true when a is not true.
"！a"が真実ではないときに真実です。
"a ? b : c" if a is true, then b, otherwise c.
Aが真実である場合は、「A？B：C」、B、そうでなければc。
"floor(a)" means the largest integer less than or equal to a.
「床（a）」は、それ以下の最大の整数を意味します。
"ceil(a)" means the smallest integer greater than or equal to a.
「CEIL（a）」は、それ以上の最小の整数を意味します。
"sign(a)" extracts the sign of a number, i.e., if a < 0 then -1, else if a > 0 then 1, else 0.
「サイン（a）」は、<0の場合、すなわち-1が> 0の場合、a> 0の場合は1、他の場合は0。
"abs(a)" means the absolute value of a, i.e., "abs(a)" = "sign(a) * a".
「ABS（a）」は、A、すなわち「ABS（a）」符号（a）* a」の絶対値を意味する。
"log2(a)" means the base-two logarithm of a.
「log2（a）」は、aの基本2対数を意味します。
"min(a,b)" means the smaller of two values a and b.
「min（a、b）」は、2つの値aとbの小さい方を意味します。
"max(a,b)" means the larger of two values a and b.
「最大（a、b）」は、2つの値AとBの大きいことを意味します。
"median(a,b,c)" means the numerical middle value in a data set of a, b, and c, i.e., "a+b+c-min(a,b,c)-max(a,b,c)".
「中央値（a、b、c）」は、A、B、Cのデータセット内の数値中間値、すなわち「AB C-Min（A、B、C）」-MAX（A、B、C）を意味する。"。
"a ==> b" means a implies b.
「a ==> b」とは、意味bを意味する。
"a <==> b" means a ==> b, b ==> a.
「a <==> b」は、==> b、b ==> aを意味する。
"a_b" means the b-th value of a sequence of a.
「a b」とは、aのシーケンスの値を意味する。
"a_(b,c)" means the 'b,c'-th value of a sequence of a.
「A_（B、C）」は、Aのシーケンスの「B」、C '番目の値を意味する。
When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C.
優先順位が括弧を使用して明示的に示されていない場合、操作は次の順序で評価されます（上から下に、同じ優位の操作が左から右へと評価されます）。この操作の順序は、標準Cで使用される操作の順序に基づいています。
a++, a--
!a, -a
a ^ b
a * b, a / b
a + b, a - b
a << b, a >> b
a < b, a <= b, a > b, a >= b
a == b, a != b
a & b
a | b
a && b
a || b
a ? b : c
a = b, a += b, a -= b, a *= b
"a...b" means any value from a to b, inclusive.
「A ... B」とは、AからBまでの値を意味します。
"NumBytes" is a nonnegative integer that expresses the size in 8-bit octets of a particular FFV1 "Configuration Record" or "Frame". FFV1 relies on its container to store the "NumBytes" values; see Section 4.3.3.
「NUMBYTES」は、特定のFFV1「構成レコード」または「フレーム」の8ビットオクテット内のサイズを表す非負整数です。FFV1は「NUMBYTES」の値を格納するためにコンテナに依存しています。セクション4.3.3を参照してください。
"remaining_bits_in_bitstream( NumBytes )" means the count of remaining bits after the pointer in that "Configuration Record" or "Frame". It is computed from the "NumBytes" value multiplied by 8 minus the count of bits of that "Configuration Record" or "Frame" already read by the bitstream parser.
「lement_bits_in_bitstream（numbytes）」とは、その「構成レコード」または「フレーム」のポインタの後の残りのビットの数を意味します。「NUMBYTES」値から8マイナスの「構成レコード」または「フレーム」のビット数の数は、ビットストリームパーサーによって既に読み取られている。
"remaining_symbols_in_syntax( )" is true as long as the range coder has not consumed all the given input bytes.
"lefent_symbols_in_syntax（）"は、Range Coderが指定されたすべての入力バイトを消費していない限り、trueです。
"byte_aligned( )" is true if "remaining_bits_in_bitstream( NumBytes )" is a multiple of 8, otherwise false.
"rester_bits_in_bitstream（numbytes）"が8の倍数、それ以外の場合はfalseの場合、 "byte_aligned（）"はtrueです。
"get_bits( i )" is the action to read the next "i" bits in the bitstream, from most significant bit to least significant bit, and to return the corresponding value. The pointer is increased by "i".
"get_bits（i）"は、ビットストリーム内の次の "i"ビットを最上位ビットから最下位ビットに読み取るためのアクションで、対応する値を返します。ポインタは「i」だけ増加します。
For each "Slice" (as described in Section 4.5) of a Frame, the Planes, Lines, and Samples are coded in an order determined by the color space (see Section 3.7). Each Sample is predicted by the median predictor as described in Section 3.3 from other Samples within the same Plane, and the difference is stored using the method described in Section 3.8.
フレームの「スライス」（セクション4.5に記載されているように）ごとに、平面、線、およびサンプルは、色空間によって決定された順序で符号化されている（セクション3.7を参照）。各サンプルは、同じ平面内の他のサンプルからのセクション3.3に記載されているように、中央値予測子によって予測され、その差はセクション3.8に記載された方法を使用して記憶される。
A border is assumed for each coded "Slice" for the purpose of the median predictor and context according to the following rules:
以下の規則に従って、中央値予測子とコンテキストの目的で、符号化された「スライス」について境界が想定されます。
* One column of Samples to the left of the coded Slice is assumed as identical to the Samples of the leftmost column of the coded Slice shifted down by one row. The value of the topmost Sample of the column of Samples to the left of the coded Slice is assumed to be "0".
* 符号化スライスの左側にあるサンプルの1つの列は、1行ずつシフトダウンされた符号化スライスの最左の列のサンプルと同一であると仮定される。符号化スライスの左側へのサンプルの列の最上部サンプルの値は「0」とする。
* One column of Samples to the right of the coded Slice is assumed as identical to the Samples of the rightmost column of the coded Slice.
* 符号化スライスの右側のサンプルの1列は、符号化スライスの右端の列のサンプルと同一であると仮定される。
* An additional column of Samples to the left of the coded Slice and two rows of Samples above the coded Slice are assumed to be "0".
* 符号化スライスの左側にあるサンプルの追加の列と、符号化スライスの上に2列のサンプルを「0」とする。
Figure 2 depicts a Slice of nine Samples "a,b,c,d,e,f,g,h,i" in a three-by-three arrangement along with its assumed border.
図2は、想定された境界線と共に3×3の配置における9個のサンプル「A、B、C、D、E、F、G、H、I」のスライスを示す。
+---+---+---+---+---+---+---+---+
| 0 | 0 | | 0 | 0 | 0 | | 0 |
+---+---+---+---+---+---+---+---+
| 0 | 0 | | 0 | 0 | 0 | | 0 |
+---+---+---+---+---+---+---+---+
| | | | | | | | |
+---+---+---+---+---+---+---+---+
| 0 | 0 | | a | b | c | | c |
+---+---+---+---+---+---+---+---+
| 0 | a | | d | e | f | | f |
+---+---+---+---+---+---+---+---+
| 0 | d | | g | h | i | | i |
+---+---+---+---+---+---+---+---+
Figure 2: A depiction of FFV1's assumed border for a set of example Samples.
図2：一連のサンプルのセットに対するFFV1の想定境界の描写。
Relative to any Sample "X", six other relatively positioned Samples from the coded Samples and presumed border are identified according to the labels used in Figure 3. The labels for these relatively positioned Samples are used within the median predictor and context.
任意のサンプル「X」と比較して、符号化サンプルおよび推定境界からの6つの他の比較的配置されたサンプルが、図3で使用されるラベルに従って識別される。これらの比較的配置されたサンプルのラベルは、中央の予測および文脈内で使用される。
+---+---+---+---+
| | | T | |
+---+---+---+---+
| |tl | t |tr |
+---+---+---+---+
| L | l | X | |
+---+---+---+---+
Figure 3: A depiction of how relatively positioned Samples are referenced within this document.
図3：この文書内で比較的配置されたサンプルがどのように参照されるかの描写。
The labels for these relative Samples are made of the first letters of the words Top, Left, and Right.
これらの相対サンプルのラベルは、左上、左右の単語の最初の文字でできています。
The prediction for any Sample value at position "X" may be computed based upon the relative neighboring values of "l", "t", and "tl" via this equation:
位置「X」における任意のサンプル値の予測は、この式を介して「L」、「T」、および「TL」の相対隣接値に基づいて計算されてもよい。
median(l, t, l + t - tl)
Note that this prediction template is also used in [ISO.14495-1.1999] and [HuffYUV].
この予測テンプレートは[ISO.14495-1.1999]および[Huffyuv]でも使用されます。
If "colorspace_type == 0 && bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 )" (see Sections 4.2.5, 4.2.7, and 4.2.3), the following median predictor MUST be used:
"colorspace_type == 0 && bits_per_raw_sample == 16 &&（coder_type == 2）"（セクション4.2.5,4.2.7、および4.2.3を参照）、次の中央値予測子を使用する必要があります。
median(left16s, top16s, left16s + top16s - diag16s)
where:
ただし：
left16s = l >= 32768 ? ( l - 65536 ) : l
top16s = t >= 32768 ? ( t - 65536 ) : t
diag16s = tl >= 32768 ? ( tl - 65536 ) : tl
Background: a two's complement 16-bit signed integer was used for storing Sample values in all known implementations of FFV1 bitstream (see Appendix C). So in some circumstances, the most significant bit was wrongly interpreted (used as a sign bit instead of the 16th bit of an unsigned integer). Note that when the issue was discovered, the only impacted configuration of all known implementations was the 16-bit YCbCr with no pixel transformation and with the range coder coder type, as the other potentially impacted configurations (e.g., the 15/16-bit JPEG 2000 Reversible Color Transform (RCT) [ISO.15444-1.2019] with range coder or the 16-bit content with the Golomb Rice coder type) were not implemented. Meanwhile, the 16-bit JPEG 2000 RCT with range coder was deployed without this issue in one implementation and validated by one conformance checker. It is expected (to be confirmed) that this exception for the median predictor will be removed in the next version of the FFV1 bitstream.
背景：FFV1ビットストリームのすべての既知の実装においてサンプル値を格納するために、2の補数16ビット符号付き整数を使用した（付録Cを参照）。したがって、状況によっては、最上位ビットが誤って解釈されました（符号なし整数の16ビットの代わりに符号ビットとして使用されます）。問題が発見されたときに、すべての既知の実装の唯一の影響は、ピクセル変換がない16ビットYCBCRであり、他の潜在的に影響された構成（例えば、15/16ビットJPEGなど）2000リバーシブルカラー変換（RCT）[ISO.1544-1.2019]レンジコーダーまたはゴロンライスコーダータイプの16ビット含有量が実装されていません。一方、Range Coderを持つ16ビットJPEG 2000 RCTは、この問題なしで1つの実装で展開され、1つの適合性チェッカーによって検証されました。中央値予測子のこの例外は、FFV1ビットストリームの次のバージョンで削除されることが予想されます。
Quantization Tables are used on Sample Differences (see Section 3.8), so Quantized Sample Differences are stored in the bitstream.
量子化テーブルはサンプルの違いに使用されます（セクション3.8を参照）、そのため、量子化されたサンプルの違いはビットストリームに格納されます。
The FFV1 bitstream contains one or more Quantization Table Sets. Each Quantization Table Set contains exactly five Quantization Tables with each Quantization Table corresponding to one of the five Quantized Sample Differences. For each Quantization Table, both the number of quantization steps and their distribution are stored in the FFV1 bitstream; each Quantization Table has exactly 256 entries, and the eight least significant bits of the Quantized Sample Difference are used as an index:
FFV1ビットストリームには、1つ以上の量子化テーブルセットが含まれています。各量子化テーブルセットは、5つの量子化サンプル差のうちの1つに対応する各量子化テーブルを有する正確に5つの量子化テーブルを含む。各量子化テーブルについて、量子化ステップ数とそれらの分布の両方がFFV1ビットストリームに格納されています。各量子化テーブルは正確に256のエントリを持ち、量子化されたサンプル差の8つの最下位ビットがインデックスとして使用されます。
Q_j[k] = quant_tables[i][j][k&255]
q_j [k] = quant_tables [i] [j] [k＆255]
Figure 4: Description of the mapping from sample differences to the corresponding Quantized Sample Differences.
図4：サンプルの違いから対応する量子化されたサンプルの違いに対するマッピングの説明。
In this formula, "i" is the Quantization Table Set index, "j" is the Quantized Table index, and "k" is the Quantized Sample Difference (see Section 4.1.1).
この式において、「i」は量子化テーブルセットインデックスである「j」は量子化テーブルインデックスであり、「K」は量子化されたサンプル差である（セクション4.1.1参照）。
Relative to any Sample "X", the Quantized Sample Differences "L-l", "l-tl", "tl-t", "T-t", and "t-tr" are used as context:
任意のサンプル「X」に対して、量子化されたサンプルの差「L-L」、「L-L」、「T-T」、「T-T」、および「T-T」、および「T-TR」は、状況として使用されます。
context = Q_0[l - tl] +
Q_1[tl - t] +
Q_2[t - tr] +
Q_3[L - l] +
Q_4[T - t]
Figure 5: Description of the computing of the Context.
図5：コンテキストのコンピューティングの説明。
If "context >= 0" then "context" is used, and the difference between the Sample and its predicted value is encoded as is; else "-context" is used, and the difference between the Sample and its predicted value is encoded with a flipped sign.
「CONTEXT> = 0」が「コンテキスト」が使用されている場合、サンプルとその予測値の差はそのままに符号化される。そうでなければ「-Context」が使用され、サンプルとその予測値の差は反転記号で符号化されています。
For each Plane of each Slice, a Quantization Table Set is selected from an index:
各スライスの各面ごとに、量子化テーブルセットがインデックスから選択されます。
* For Y Plane, "quant_table_set_index[ 0 ]" index is used.
* y平面の場合、「quant_table_set_index [0]」インデックスが使用されます。
* For Cb and Cr Planes, "quant_table_set_index[ 1 ]" index is used.
* CBおよびCRプレーンの場合は、「QUATT_TABLE_SET_INDEX [1]」インデックスが使用されます。
* For extra Plane, "quant_table_set_index[ (version <= 3 || chroma_planes) ? 2 : 1 ]" index is used.
* 余分な平面の場合は、「QUANT_TABLE_SET_INDEX [（バージョン<= 3 || CHROMA_PLANES）？2：1]インデックスが使用されます。
Background: in the first implementations of the FFV1 bitstream, the index for Cb and Cr Planes was stored even if it was not used ("chroma_planes" set to 0), this index is kept for "version <= 3" in order to keep compatibility with FFV1 bitstreams in the wild.
背景：FFV1ビットストリームの最初の実装では、使用されていなくてもCBとCRプレーンのインデックスが格納されていました（ "Chroma_planes"が0に設定されています）、このインデックスは保持するために "バージョン<= 3"に保存されます。野生のFFV1ビットストリームとの互換性。
FFV1 supports several color spaces. The count of allowed coded Planes and the meaning of the extra Plane are determined by the selected color space.
FFV1はいくつかの色空間をサポートします。許容された符号化プレーンの数および余分な平面の意味は、選択された色空間によって決定される。
The FFV1 bitstream interleaves data in an order determined by the color space. In YCbCr for each Plane, each Line is coded from top to bottom, and for each Line, each Sample is coded from left to right. In JPEG 2000 RCT for each Line from top to bottom, each Plane is coded, and for each Plane, each Sample is encoded from left to right.
FFV1ビットストリームは、色空間によって決定された順序でデータをインターリーブする。各平面についてYCBCRでは、各行は上から下へ符号化され、各ラインについては各サンプルが左から右に符号化される。上から下への各行のJPEG 2000 RCTでは、各平面は符号化され、各平面について各サンプルは左から右に符号化されている。
This color space allows one to four Planes.
この色空間は1つの平面を可能にします。
The Cb and Cr Planes are optional, but if they are used, then they MUST be used together. Omitting the Cb and Cr Planes codes the frames in gray scale without color data.
CBとCRプレーンはオプションですが、使用されている場合は、それらを一緒に使用する必要があります。CBおよびCRプレーンを省略すると、カラーデータなしでグレースケールでフレームを符号化する。
An optional transparency Plane can be used to code transparency data.
透明度データを符号化するために任意の透明面を使用することができる。
An FFV1 Frame using YCbCr MUST use one of the following arrangements:
YCBCRを使用したFFV1フレームは、次のいずれかの手配を使用する必要があります。
* Y
* y
* Y, Transparency
* 透明度
* Y, Cb, Cr
* Y、CB、CR
* Y, Cb, Cr, Transparency
* y、cb、cr、透明度
The Y Plane MUST be coded first. If the Cb and Cr Planes are used, then they MUST be coded after the Y Plane. If a transparency Plane is used, then it MUST be coded last.
Y平面は最初に符号化されなければならない。CBとCRプレーンが使用されている場合、それらはY平面後にコーディングされなければなりません。透明面が使用されている場合は、最後にコーディングする必要があります。
This color space allows three or four Planes.
この色空間は3つまたは4つの平面を可能にします。
An optional transparency Plane can be used to code transparency data.
透明度データを符号化するために任意の透明面を使用することができる。
JPEG 2000 RCT is a Reversible Color Transform that codes RGB (Red, Green, Blue) Planes losslessly in a modified YCbCr color space [ISO.15444-1.2019]. Reversible pixel transformations between YCbCr and RGB use the following formulae:
JPEG 2000 RCTは、RGB（赤、緑、青）が修正されたYCBCR色空間で損失を取り消す可逆色変換です[ISO.15444-1.2019]。YCBCRとRGBの間の可逆的なピクセル変換次の式を使用します。
Cb = b - g
Cr = r - g
Y = g + (Cb + Cr) >> 2
Figure 6: Description of the transformation of pixels from RGB color space to coded, modified YCbCr color space.
図6：RGB色空間から符号化された、修正されたYCBCR色空間へのピクセルの変換の説明。
g = Y - (Cb + Cr) >> 2
r = Cr + g
b = Cb + g
Figure 7: Description of the transformation of pixels from coded, modified YCbCr color space to RGB color space.
図7：符号化修正YCbCr色空間からRGB色空間へのピクセルの変換の説明。
Cb and Cr are positively offset by "1 << bits_per_raw_sample" after the conversion from RGB to the modified YCbCr, and they are negatively offset by the same value before the conversion from the modified YCbCr to RGB in order to have only nonnegative values after the conversion.
CBとCRは、RGBから修正YCBCRへの変換後に「1 << BITS_PER_RAW_SAMPLE」とは積極的にオフセットされており、それらは、修正されたYCBCRからRGBへの変換前の同じ値で負に相殺されています。会話。
When FFV1 uses the JPEG 2000 RCT, the horizontal Lines are interleaved to improve caching efficiency since it is most likely that the JPEG 2000 RCT will immediately be converted to RGB during decoding. The interleaved coding order is also Y, then Cb, then Cr, and then, if used, transparency.
FFV1がJPEG 2000 RCTを使用すると、JPEG 2000 RCTが復号化中にすぐにRGBに変換される可能性が最も高いため、水平線はインターリーブされてキャッシング効率を向上させます。インターリーブ符号化順序もy、次にCB、次にCR、そして使用されている場合は透明度である。
As an example, a Frame that is two pixels wide and two pixels high could comprise the following structure:
一例として、2つのピクセル幅と2つのピクセルのフレームは、次の構造を構成することができます。
+------------------------+------------------------+
| Pixel(1,1) | Pixel(2,1) |
| Y(1,1) Cb(1,1) Cr(1,1) | Y(2,1) Cb(2,1) Cr(2,1) |
+------------------------+------------------------+
| Pixel(1,2) | Pixel(2,2) |
| Y(1,2) Cb(1,2) Cr(1,2) | Y(2,2) Cb(2,2) Cr(2,2) |
+------------------------+------------------------+
In JPEG 2000 RCT, the coding order is left to right and then top to bottom, with values interleaved by Lines and stored in this order:
JPEG 2000 RCTでは、コーディング順序は右に左にあり、次に下から下に、値は行によってインターリーブされ、この順序で保存されます。
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)
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:
"bits_per_raw_sample"が9から15の間で "extrant_plane"の場合は、上記のものの代わりにycbcrとRGB間のリバーシブル変換のための次の式を使用する必要がある場合は、次のようにしてください。
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).
図8：RGBカラースペースから符号化された修正YCBCR色空間へのピクセルの変換（例外の場合）。
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).
図9：符号化修正YCbCr色空間からRGB色空間へのピクセルの変換の説明（例外の場合）。
Background: At the time of this writing, in all known implementations of the FFV1 bitstream, when "bits_per_raw_sample" was between 9 and 15 inclusive and "extra_plane" was 0, Green Blue Red (GBR) Planes were used as Blue Green Red (BGR) Planes during both encoding and decoding. Meanwhile, 16-bit JPEG 2000 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.
背景：この書き込み時に、FFV1ビットストリームのすべての既知の実装では、「BITS_PER_RAW_SAMPLE」が9~15の間で、「Extrant_plane」が0の場合、緑色の赤（GBR）平面が青緑色の赤（BGR）として使用されていました。符号化と復号化の両方の間にプレーン。一方、16ビットJPEG 2000 RCTはこの問題なく1つの実装で実装され、1つの適合性チェッカーによって検証されました。変換のこの例外に対処するための方法は、FFV1ビットストリームの次のバージョンについて考慮しています。
Instead of coding the n+1 bits of the Sample Difference with Huffman or Range coding (or n+2 bits, in the case of JPEG 2000 RCT), only the n (or n+1, in the case of JPEG 2000 RCT) least significant bits are used, since this is sufficient to recover the original Sample. In Figure 10, the term "bits" represents "bits_per_raw_sample + 1" for JPEG 2000 RCT or "bits_per_raw_sample" otherwise:
ハフマンまたは範囲符号化（JPEG2000 RCTの場合はN 2ビット）とのサンプル差のN 1ビット（またはN 2ビット）を符号化する代わりに、N（またはN 1、JPEG 2000 RCTの場合）最下位ビットこれは元のサンプルを回復するのに十分であるので使用されます。図10では、「ビット」という用語は、JPEG 2000 RCTまたは「BITS_PER_RAW_SAMPLE」についての「BITS_PER_RAW_SAMPLE 1」を表します。
coder_input = ((sample_difference + 2 ^ (bits - 1)) &
(2 ^ bits - 1)) - 2 ^ (bits - 1)
Figure 10: Description of the coding of the Sample Difference in the bitstream.
図10：ビットストリームのサンプル差の符号化の説明。
Early experimental versions of FFV1 used the Context-Adaptive Binary Arithmetic Coding (CABAC) coder from H.264 as defined in [ISO.14496-10.2020], but due to the uncertain patent/royalty situation, as well as its slightly worse performance, CABAC was replaced by a range coder based on an algorithm defined by G. Nigel N. Martin in 1979 [Range-Encoding].
FFV1の初期の実験的バージョンは、[ISO.14496-10.2020]で定義されているが、不確実な特許/ロイヤリティの状況、そしてそのわずかに悪いパフォーマンスのために、CANTECT対応バイナリ算術符号化（CABAC）コーディャー（CABAC）コーディング（CABAC）コーディャーを使用した。CABACは、1979年のG. Nigel N. Martinによって定義されたアルゴリズムに基づいて距離コーダに置き換えられた[Range-Encoding]。
To encode binary digits efficiently, a range coder is used. A range coder encodes a series of binary symbols by using a probability estimation within each context. The sizes of each of the two subranges are proportional to their estimated probability. The Quantization Table is used to choose the context used from the surrounding image sample values for the case of coding the Sample Differences. The coding of integers is done by coding multiple binary values. The range decoder will read bytes until it can determine into which subrange the input falls to return the next binary symbol.
2進数桁を効率的にエンコードするために、範囲コーダが使用されます。範囲コーダは、各コンテキスト内の確率推定を使用することによって一連の2進記号を符号化する。2つのサブレンジのそれぞれのサイズは、それらの推定確率に比例します。量子化テーブルは、サンプルの違いをコーディングする場合について、周囲の画像サンプル値から使用されるコンテキストを選択するために使用されます。整数の符号化は、複数のバイナリ値を符号化することによって行われる。範囲デコーダは、入力が次の2値記号を返すために入力が落ちるサブレンジに決定されるまでバイトを読み取ります。
To describe Range coding for FFV1, the following values are used:
FFV1の範囲符号化を説明するために、以下の値が使用されます。
C_i the i-th context.
c_i i番目の文脈
B_i the i-th byte of the bytestream.
b_i byteStreamのi番目のバイト。
R_i the Range at the i-th symbol.
r_i i番目のシンボルの範囲。
r_i the boundary between two subranges of R_i: a subrange of r_i values and a subrange R_i - r_i values.
R_I R_Iの2つのサブレンジ間の境界：R_I値のサブレンジとサブレンジR_I - R_I値。
L_i the Low value of the Range at the i-th symbol.
l_i i番目のシンボルの範囲の低い値。
l_i a temporary variable to carry over or adjust the Low value of the Range between range coding operations.
l_i範囲符号化操作間の範囲の低い値を搬送するかまたは調整するための一時変数。
t_i a temporary variable to transmit subranges between range coding operations.
T_I範囲符号化操作間のサブレンジを送信するための一時変数。
b_i the i-th range-coded binary value.
b_i範囲符号化バイナリ値。
S_(0, i) the i-th initial state.
S_（0、i）i番目の初期状態。
j_n the length of the bytestream encoding n binary symbols.
j_nバイナリシンボルを符号化するbyteStreamの長さ。
The following range coder state variables are initialized to the following values. The Range is initialized to a value of 65,280 (expressed in base 16 as 0xFF00) as depicted in Figure 11. The Low is initialized according to the value of the first two bytes as depicted in Figure 12. j_i tracks the length of the bytestream encoding while incrementing from an initial value of j_0 to a final value of j_n. j_0 is initialized to 2 as depicted in Figure 13.
以下の範囲のコーダ状態変数が次の値に初期化されます。図11に示すように、範囲は65,280の値（0xFF00として表される）に初期化されます。図12に示すように、最初の2バイトの値に従って初期化されます.J_Iはバイトストリームエンコーディングの長さを追跡j_0の初期値からj_nの最終値までインクリメントしながら。図13に示すように、J_0が2に初期化されます。
R_0 = 65280
Figure 11: The initial value for the Range.
図11：範囲の初期値。
L_0 = 2 ^ 8 * B_0 + B_1
Figure 12: The initial value for Low is set according to the first two bytes of the bytestream.
図12：LOWの初期値は、BYTESTREAMの最初の2バイトに従って設定されます。
j_0 = 2
Figure 13: The initial value for "j", the length of the bytestream encoding.
図13：「j」の初期値、バイトストリームエンコーディングの長さ。
The following equations define how the range coder variables evolve as it reads or writes symbols.
次の式は、シンボルを読み書きするときに範囲コーダの変数がどのように進化するかを定義します。
r_i = floor( ( R_i * S_(i, C_i) ) / 2 ^ 8 )
Figure 14: This formula shows the positioning of range split based on the state.
図14：この式は、状態に基づく範囲分割の位置決めを示しています。
b_i = 0 <==>
L_i < R_i - r_i ==>
S_(i+1,C_i) = zero_state_(S_(i, C_i)) AND
l_i = L_i AND
t_i = R_i - r_i
b_i = 1 <==>
L_i >= R_i - r_i ==>
S_(i+1,C_i) = one_state_(S_(i, C_i)) AND
l_i = L_i - R_i + r_i AND
t_i = r_i
Figure 15: This formula shows the linking of the decoded symbol (represented as b_i), the updated state (represented as S_(i+1,C_i)), and the updated range (represented as a range from l_i to t_i).
図15：この式は、復号化されたシンボル（b_iとして表される）、更新された状態（s_（i 1、c_i）として表されます）、および更新された範囲（L_iからT_iの範囲として表されます）のリンクを示しています。
C_i != k ==> S_(i + 1, k) = S_(i, k)
Figure 16: If the value of "k" is unequal to the i-th value of context, in other words, if the state is unchanged from the last symbol coding, then the value of the state is carried over to the next symbol coding.
図16：「k」の値がコンテキストのi番目の値とは異なる場合、言い換えれば、状態が最後のシンボル符号化から変化しない場合、状態の値は次のシンボル符号化に伝送される。。
t_i < 2 ^ 8 ==>
R_(i + 1) = 2 ^ 8 * t_i AND
L_(i + 1) = 2 ^ 8 * l_i + B_(j_i) AND
j_(i + 1) = j_i + 1
t_i >= 2 ^ 8 ==>
R_(i + 1) = t_i AND
L_(i + 1) = l_i AND
j_(i + 1) = j_i
Figure 17: This formula shows the linking of the range coder with the reading or writing of the bytestream.
図17：この式は、範囲コーダのリンクを示しており、バイトストリームの読み書きを示しています。
range = 0xFF00;
end = 0;
low = get_bits(16);
if (low >= range) {
low = range;
end = 1;
}
Figure 18: A pseudocode description of the initialization of range coder variables in Range binary mode.
図18：範囲バイナリモードにおける範囲コーダ変数の初期化の擬似コード記述。
refill() {
if (range < 256) {
range = range * 256;
low = low * 256;
if (!end) {
c.low += get_bits(8);
if (remaining_bits_in_bitstream( NumBytes ) == 0) {
end = 1;
}
}
}
}
Figure 19: A pseudocode description of refilling the binary value buffer of the range coder.
図19：範囲コーダのバイナリ値バッファを補充するという擬似コード記述。
get_rac(state) {
rangeoff = (range * state) / 256;
range -= rangeoff;
if (low < range) {
state = zero_state[state];
refill();
return 0;
} else {
low -= range;
state = one_state[state];
range = rangeoff;
refill();
return 1;
}
}
Figure 20: A pseudocode description of the read of a binary value in Range binary mode.
図20：範囲バイナリモードにおける2進値の読み取りの疑似コード記述。
The range coder can be used in three modes:
範囲コーダは3つのモードで使用できます。
* In Open mode when decoding, every symbol the reader attempts to read is available. In this mode, arbitrary data can have been appended without affecting the range coder output. This mode is not used in FFV1.
* デコード時にオープンモードでは、読者が読み込もうとするすべてのシンボルが利用可能です。このモードでは、範囲コーダ出力に影響を与えることなく任意のデータが追加されています。このモードはFFv1では使用されません。
* In Closed mode, the length in bytes of the bytestream is provided to the range decoder. Bytes beyond the length are read as 0 by the range decoder. This is generally one byte shorter than the Open mode.
* 閉モードでは、バイトストリームのバイト数が範囲デコーダに提供される。長さを超えるバイトは範囲デコーダによって0として読み込まれます。これは一般にオープンモードより1バイト短いです。
* In Sentinel mode, the exact length in bytes is not known, and thus the range decoder MAY read into the data that follows the range-coded bytestream by one byte. In Sentinel mode, the end of the range-coded bytestream is a binary symbol with state 129, which value SHALL be discarded. After reading this symbol, the range decoder will have read one byte beyond the end of the range-coded bytestream. This way the byte position of the end can be determined. Bytestreams written in Sentinel mode can be read in Closed mode if the length can be determined. In this case, the last (sentinel) symbol will be read uncorrupted and be of value 0.
* センチネルモードでは、正確な長さが正確な長さが知られていないため、範囲デコーダは1バイトで範囲で符号化された範囲に続くデータに読み込まれます。センチネルモードでは、範囲符号化された範囲の終わりは状態129を有する2値記号であり、その値は廃棄される。このシンボルを読み取った後、範囲デコーダは範囲コード化された範囲の終わりを超えて1バイトを読み取っています。このようにして、端部のバイト位置を決定することができる。長さを決定できる場合は、Sentinelモードで書かれたバイトストリームをクローズモードで読み取ることができます。この場合、最後の（Sentinel）シンボルは不正外に読み取られ、値0になります。
The above describes the range decoding. Encoding is defined as any process that produces a decodable bytestream.
上記は範囲復号化について説明する。符号化は、復号可能なByTeStreamを生成する任意のプロセスとして定義されます。
There are three places where range coder termination is needed in FFV1. The first is in the "Configuration Record", which in this case the size of the range-coded bytestream is known and handled as Closed mode. The second is the switch from the "Slice Header", which is range coded to Golomb-coded Slices as Sentinel mode. The third is the end of range-coded Slices, which need to terminate before the CRC at their end. This can be handled as Sentinel mode or as Closed mode if the CRC position has been determined.
FFV1に範囲コーダ終了が必要な3つの場所があります。1つ目は「構成レコード」にあります。この場合、この場合、範囲コード化された範囲のサイズは既知であり、閉モードとして扱われます。2つ目は、 "スライスヘッダー"からのスイッチです。これは、Sentinelモードとしてゴローム符号化スライスに符号化された範囲です。3つ目は、範囲コード化スライスの終わりです。これは、CRCの前に終了する必要があります。これは、CRC位置が決定されている場合は、センチネルモードまたはクローズモードとして処理できます。
To encode scalar integers, it would be possible to encode each bit separately and use the past bits as context. However, that would mean 255 contexts per 8-bit symbol, which is not only a waste of memory but also requires more past data to reach a reasonably good estimate of the probabilities. Alternatively, it would also be possible to assume a Laplacian distribution and only deal with its variance and mean (as in Huffman coding). However, for maximum flexibility and simplicity, the chosen method uses a single symbol to encode if a number is 0, and if the number is nonzero, it encodes the number using its exponent, mantissa, and sign. The exact contexts used are best described by Figure 21.
スカラー整数をエンコードするためには、各ビットを別々にエンコードし、コンテキストとして過去のビットを使用することが可能になります。ただし、8ビットシンボルあたり255のコンテキストを意味します。これは、メモリの無駄だけでなく、確率の合理的に良好な推定値に達するためにもっと過去のデータも必要とします。あるいは、ラプラシアン分布を想定し、その分散と平均を扱うことも可能であろう（ハフマン符号化のように）。ただし、最大限の柔軟性と単純さのために、選択されたメソッドは、数値が0の場合に符号化するために単一のシンボルを使用し、その数がゼロ以外の場合、その指数、仮数、および符号を使用して番号を符号化します。使用される正確なコンテキストは、図21で最もよく説明されています。
int get_symbol(RangeCoder *c, uint8_t *state, int is_signed) {
if (get_rac(c, state + 0) {
return 0;
}
int e = 0;
while (get_rac(c, state + 1 + min(e, 9)) { //1..10
e++;
}
int a = 1;
for (int i = e - 1; i >= 0; i--) {
a = a * 2 + get_rac(c, state + 22 + min(i, 9)); // 22..31
}
if (!is_signed) {
return a;
}
if (get_rac(c, state + 11 + min(e, 10))) { //11..21
return -a;
} else {
return a;
}
}
Figure 21: A pseudocode description of the contexts of Range nonbinary values.
図21：範囲非バイナリ値のコンテキストの擬似コード記述。
"get_symbol" is used for the read out of "sample_difference" indicated in Figure 10.
図10に示す「sample_difference」の読み出しには「GET_SYMBOL」が使用されます。
"get_rac" returns a boolean computed from the bytestream as described by the formula found in Figure 14 and by the pseudocode found in Figure 20.
"get_rac"は、図14にある式と図20に見つかった疑似コードによって説明されているように、Bytestreamから計算されたブール値を返します。
When the "keyframe" value (see Section 4.4) is 1, all range coder state variables are set to their initial state.
「キーフレーム」の値（セクション4.4を参照）が1の場合、すべての範囲コーダ状態変数が初期状態に設定されます。
In Range Coding Mode, a state transition table is used, indicating to which state the decoder will move based on the current state and the value extracted from Figure 20.
範囲符号化モードでは、現在の状態に基づいてデコーダが移動する状態と図20から抽出された値とを示す状態遷移テーブルが使用される。
one_state_i = default_state_transition_i + state_transition_delta_i
one_state_i = default_state_transition_i state_transition_delta_i
Figure 22: Description of the coding of the state transition table for a "get_rac" readout value of 1.
図22：「GET_RAC」読み出し値1の状態遷移表の符号化の説明。
zero_state_i = 256 - one_state_(256-i)
Figure 23: Description of the coding of the state transition table for a "get_rac" readout value of 0.
"GET_RAC"読み出し値0の状態遷移表の符号化の説明。
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,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,37,34,42、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、
89, 90, 91, 92, 93, 94, 94, 95, 96, 97, 98, 99,100,101,102,103,
89,90,91,92,93,94,94,95,96,97,98,99,100,101,102,103
104,105,106,107,108,109,110,111,112,113,114,114,115,116,117,118,
【0072】
119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,133,
119,20,120,13,125,129,129,129,129,129,129,129,129,129,129,129,129,129,129,129,127,129,129,129,129,127,131,129,130,131,129,132,133,133
134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,
134,135,136,144,142,144,147,146,144,147,147,147,146,147,146,147,147,147,142,146,144,147,146,147,146,149
150,151,152,152,153,154,155,156,157,158,159,160,161,162,163,164,
【請求項15】【請求項51」目）150,197,197,199,199,199,199,199
165,166,167,168,169,170,171,171,172,173,174,175,176,177,178,179,
【特徴】
180,181,182,183,184,185,186,187,188,189,190,190,191,192,194,194,
【】【00028】
195,196,197,198,199,200,201,202,202,204,205,206,207,208,209,209,
【0002】【】【0009】
210,211,212,213,215,215,216,217,218,219,220,220,222,223,224,225,
【】【0002】【0002】
226,227,227,229,229,230,231,232,234,234,235,236,237,238,239,240,
【228,237,238,237,237,238,236,237,238,237,237,238,236,237,236,236,237,238,236,237,230,238,233ページ
241,242,243,244,245,246,247,248,248, 0, 0, 0, 0, 0, 0, 0,
0,0,0,0,0,0,0,0,0,0
Figure 24: Default state transition table for Range coding.
図24：範囲符号化のデフォルト状態遷移表
The alternative state transition table has been built using iterative 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 to 2, and the difference to the default MUST be stored in the "Parameters", see Section 4.2. At the time of this writing, the reference implementation of FFV1 in FFmpeg uses Figure 25 by default when Range coding is used.
代替状態遷移表は、フレームサイズの反復最小化を使用して構築されており、一般にデフォルトよりも優れている。それを使用するには、 "coder_type"（セクション4.2.3を参照）を2に設定する必要があり、デフォルトとの差は「パラメータ」に保存する必要があります。セクション4.2を参照してください。この書き込み時に、FFMPEGにおけるFFV1の基準実装は、範囲符号化が使用されている場合には、デフォルトで図25を使用します。
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,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、
87, 82, 71, 97, 73, 73, 82, 75,111, 77, 94, 78, 87, 81, 83, 97,
87,82,71,97,73,73,82,75,111,77,94,78,87,81,83,97、
85, 83, 94, 86, 99, 89, 90, 99,111, 92, 93,134, 95, 98,105, 98,
85,83,94,86,99,89,90,99,111,92,93,134,95,98,105,98、
105,110,102,108,102,118,103,106,106,113,109,112,114,112,116,125,
【0002】,10,92,102,94,108,102,92,117,103,109,116,113,109,109,116,113,109,102,116,103,109,110
115,116,117,117,126,119,125,121,121,123,145,124,126,131,127,129,
【特徴】
165,130,132,138,133,135,145,136,137,139,146,141,143,142,144,148,
【】
147,155,151,149,151,150,152,157,153,154,156,168,158,162,161,160,
【0002】,199,199,197,19,149,197,197,19,14,162,161,160、
172,163,169,164,166,184,167,170,177,174,171,173,182,176,180,178,
【】
175,189,179,181,186,183,192,185,200,187,191,188,190,197,193,196,
【】【0002】
197,194,195,196,198,202,199,201,210,203,207,204,205,206,208,214,
【】【00028】
209,211,221,212,213,215,224,216,217,218,219,220,222,228,223,225,
【202】
226,224,227,229,240,230,231,232,233,234,235,236,238,239,237,242,
【22222,240,242,243,237,242,239,233,233,233,239,236,234,233,236,236,238,238,233,236,238,236,236,238,238,233,236,233ページ
241,243,242,244,245,246,247,248,249,250,251,252,252,253,254,255,
【220】【22,250,248,248,250,240,248,248,250,240,248,253,250,250,253,248,250,248,248,254ページ
Figure 25: Alternative state transition table for Range coding.
範囲符号化用の代替状態遷移表
The end of the bitstream of the Frame is padded with zeroes until the bitstream contains a multiple of eight bits.
ビットストリームが8ビットの倍数を含むまで、フレームのビットストリームの終わりにはゼロが埋め込まれています。
This coding mode uses Golomb Rice codes. The VLC is split into two parts: the prefix and suffix. The prefix stores the most significant bits or indicates if the symbol is too large to be stored (this is known as the ESC case, see Section 3.8.2.1.1). The suffix either stores the k least significant bits or stores the whole number in the ESC case.
この符号化モードはゴローム米コードを使用しています。VLCは2つの部分に分割されます。プレフィックスとサフィックス。接頭辞は最も重要なビットを保存するか、記憶が大きすぎるかどうかを示します（これはESCケースとして知られています。セクション3.8.2.1.1を参照）。接尾辞は、K個の最下位ビットを記憶するか、または整数をESCケースに格納する。
int get_ur_golomb(k) {
for (prefix = 0; prefix < 12; prefix++) {
if (get_bits(1)) {
return get_bits(k) + (prefix << k);
}
}
return get_bits(bits) + 11;
}
Figure 26: A pseudocode description of the read of an unsigned integer in Golomb Rice mode.
図26：ゴロームライスモードにおける符号なし整数の読み取りの擬似コード記述
int get_sr_golomb(k) {
v = get_ur_golomb(k);
if (v & 1) return - (v >> 1) - 1;
else return (v >> 1);
}
Figure 27: A pseudocode description of the read of a signed integer in Golomb Rice mode.
図27：ゴロームライスモードにおける符号付き整数の読み取りの擬似コード記述。
+================+=======+
| bits | value |
+================+=======+
| 1 | 0 |
+----------------+-------+
| 01 | 1 |
+----------------+-------+
| ... | ... |
+----------------+-------+
| 0000 0000 01 | 9 |
+----------------+-------+
| 0000 0000 001 | 10 |
+----------------+-------+
| 0000 0000 0001 | 11 |
+----------------+-------+
| 0000 0000 0000 | ESC |
+----------------+-------+
Table 1: Description of the coding of the prefix of signed Golomb Rice codes.
表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.
ESCは、保存されるシンボルが通常の保存に大きすぎ、代替の記憶方法が使用されていることを示すためのエスケープシンボルです。
+---------+----------------------------------------+
| non-ESC | the k least significant bits MSB first |
+---------+----------------------------------------+
| ESC | the value - 11, in MSB first order |
+---------+----------------------------------------+
Table 2: Description of the coding of the suffix of signed Golomb Rice codes.
表2：署名されたゴローム米の符号の接尾辞のコーディングの説明。
ESC MUST NOT be used if the value can be coded as non-ESC.
値が非ESCとしてコーディングできる場合は、ESCを使用しないでください。
Table 3 shows practical examples of how signed Golomb Rice codes are decoded based on the series of bits extracted from the bitstream as described by the method above:
上記の方法で説明したように、ビットストリームから抽出された一連のビットに基づいて、署名されたゴローム米コードがどのように復号されるかの実例の実例を示す。
+=====+=======================+=======+
| k | bits | value |
+=====+=======================+=======+
| 0 | 1 | 0 |
+-----+-----------------------+-------+
| 0 | 001 | 2 |
+-----+-----------------------+-------+
| 2 | 1 00 | 0 |
+-----+-----------------------+-------+
| 2 | 1 10 | 2 |
+-----+-----------------------+-------+
| 2 | 01 01 | 5 |
+-----+-----------------------+-------+
| any | 000000000000 10000000 | 139 |
+-----+-----------------------+-------+
Table 3: Examples of decoded, signed Golomb Rice codes.
表3：復号化されたゴロン米の命令の例。
Run mode is entered when the context is 0 and left as soon as a nonzero difference is found. The Sample Difference is identical to the predicted one. The run and the first different Sample Difference are coded as defined in Section 3.8.2.4.1.
実行モードは、ゼロ以外の差が見つかったらすぐにコンテキストが0のときに入力されます。サンプル差は予測されたものと同じです。実行と最初の異なるサンプル差は、3.8.2.4.1項で定義されているように符号化されています。
The run value is encoded in two parts. The prefix part stores the more significant part of the run as well as adjusting the "run_index" that determines the number of bits in the less significant part of the run. The second part of the value stores the less significant part of the run as it is. The "run_index" is reset to zero for each Plane and Slice.
実行値は2つの部分でエンコードされます。プレフィックス部分は、実行のより重要な部分を記憶していても、ランの有意な部分ではかなりの部分のビット数を決定する「RUN_INDEX」を調整するだけでなく、「RUN_INDEX」を調整します。値の2番目の部分には、実行の有意な部分がそのままになります。「run_index」は、各平面とスライスについてゼロにリセットされます。
log2_run[41] = {
0, 0, 0, 0, 1, 1, 1, 1,
2, 2, 2, 2, 3, 3, 3, 3,
4, 4, 5, 5, 6, 6, 7, 7,
8, 9,10,11,12,13,14,15,
16,17,18,19,20,21,22,23,
24,
};
if (run_count == 0 && run_mode == 1) {
if (get_bits(1)) {
run_count = 1 << log2_run[run_index];
if (x + run_count <= w) {
run_index++;
}
} else {
if (log2_run[run_index]) {
run_count = get_bits(log2_run[run_index]);
} else {
run_count = 0;
}
if (run_index) {
run_index--;
}
run_mode = 2;
}
}
The "log2_run" array is also used within [ISO.14495-1.1999].
「LOG2_RUN」アレイは[ISO.14495-1.1999]内でも使用されます。
"sign_extend" is the function of increasing the number of bits of an input binary number in two's complement signed number representation while preserving the input number's sign (positive/negative) and value, in order to fit in the output bit width. It MAY be computed with the following:
"sign_extend"は、出力ビット幅にフィットするために、入力番号の符号（正/負）と値を保持しながら、2の補数符号付き数表現で入力2進数のビット数を増やす機能です。それは次のように計算されるかもしれません：
sign_extend(input_number, input_bits) {
negative_bias = 1 << (input_bits - 1);
bits_mask = negative_bias - 1;
output_number = input_number & bits_mask; // Remove negative bit
is_negative = input_number & negative_bias; // Test negative bit
if (is_negative)
output_number -= negative_bias;
return output_number
}
Each difference is coded with the per context mean prediction removed and a per context value for "k".
各差は、コンテキストごとの平均予測が削除され、「K」の間のコンテキスト値で符号化される。
get_vlc_symbol(state) {
i = state->count;
k = 0;
while (i < state->error_sum) {
k++;
i += i;
}
v = get_sr_golomb(k);
if (2 * state->drift < -state->count) {
v = -1 - v;
}
ret = sign_extend(v + state->bias, bits);
state->error_sum += abs(v);
state->drift += v;
if (state->count == 128) {
state->count >>= 1;
state->drift >>= 1;
state->error_sum >>= 1;
}
state->count++;
if (state->drift <= -state->count) {
state->bias = max(state->bias - 1, -128);
state->drift = max(state->drift + state->count,
-state->count + 1);
} else if (state->drift > 0) {
state->bias = min(state->bias + 1, 127);
state->drift = min(state->drift - state->count, 0);
}
return ret;
}
Level coding is identical to the normal difference coding with the exception that the 0 value is removed as it cannot occur:
レベル符号化は、0値が発生することができないので、0値が削除されたことを除いて、通常の差分符号化と同じである。
diff = get_vlc_symbol(context_state);
if (diff >= 0) {
diff++;
}
Note that this is different from JPEG-LS (lossless JPEG), which doesn't use prediction in run mode and uses a different encoding and context model for the last difference. On a small set of test Samples, the use of prediction slightly improved the compression rate.
これはJPEG-LS（ロスレスJPEG）とは異なるため、ランモードで予測は使用されず、最後の違いには異なるエンコードとコンテキストモデルを使用します。小さな試験サンプルのセットでは、予測の使用は圧縮率をわずかに改善した。
When "keyframe" (see Section 4.4) value is 1, all VLC coder state variables are set to their initial state.
「キーフレーム」（セクション4.4を参照）の値が1のとき、すべてのVLCコーダ状態変数は初期状態に設定されます。
drift = 0;
error_sum = 4;
bias = 0;
count = 1;
An FFV1 bitstream is composed of a series of one or more Frames and (when required) a "Configuration Record".
FFV1ビットストリームは、一連の1つ以上のフレームと（必要な場合） "構成レコード"で構成されています。
Within the following subsections, pseudocode as described in Section 2.2.1 is used to explain the structure of each FFV1 bitstream component. Table 4 lists symbols used to annotate that pseudocode in order to define the storage of the data referenced in that line of pseudocode.
以下のサブセクションの中で、セクション2.2.1に記載されている疑似コードを使用して、各FFV1ビットストリームコンポーネントの構造を説明する。表4に、その擬似コードの行で参照されているデータの格納を定義するために、疑似コードを注釈に付すために使用される記号を示します。
+========+==================================================+
| symbol | definition |
+========+==================================================+
| u(n) | Unsigned, big-endian integer symbol using n bits |
+--------+--------------------------------------------------+
| br | Boolean (1-bit) symbol that is range coded with |
| | the method described in Section 3.8.1.1 |
+--------+--------------------------------------------------+
| ur | Unsigned scalar symbol that is range coded with |
| | the method described in Section 3.8.1.2 |
+--------+--------------------------------------------------+
| sr | Signed scalar symbol that is range coded with |
| | the method described in Section 3.8.1.2 |
+--------+--------------------------------------------------+
| sd | Sample Difference symbol that is coded with the |
| | method described in Section 3.8 |
+--------+--------------------------------------------------+
Table 4: Definition of pseudocode symbols for this document.
表4：この文書の擬似コードシンボルの定義。
The following MUST be provided by external means during the initialization of the decoder:
次のことは、デコーダの初期化中に外部手段によって提供されなければなりません。
"frame_pixel_width" is defined as Frame width in pixels.
「frame_pixel_width」は、フレーム幅としてピクセル単位で定義されています。
"frame_pixel_height" is defined as Frame height in pixels.
"frame_pixel_height"はピクセル単位のフレームの高さとして定義されています。
Default values at the decoder initialization phase:
デコーダ初期化フェーズでのデフォルト値
"ConfigurationRecordIsPresent" is set to 0.
"ConfigurationRecordSpresent"は0に設定されています。
The Quantization Table Sets store a sequence of values that are equal to one less than the count of equal concurrent entries for each set of equal concurrent entries within the first half of the table (represented as "len - 1" in the pseudocode below) using the method described in Section 3.8.1.2. The second half doesn't need to be stored as it is identical to the first with flipped sign. "scale" and "len_count[ i ][ j ]" are temporary values used for the computing of "context_count[ i ]" and are not used outside Quantization Table Set pseudocode.
量子化テーブルセットは、テーブルの前半内の等しい同時エントリの各セットについて、等しい同時エントリの数よりも1つ以下の一連の値を格納します（下の疑似コードの「LEN-1」として表した）。3.8.1.2項に記載されている方法。第1の半分は最初の符号付きの最初のものと同じであるので保存する必要はありません。「スケール」と「LEN_COUNT [i] [j] "は、「context_count [i]」の計算に使用される一時的な値であり、汎用テーブルセット疑似コードでは使用されません。
Example:
例：
Table: 0 0 1 1 1 1 2 2 -2 -2 -2 -1 -1 -1 -1 0
Stored values: 1, 3, 1
保存値：1,3,1
"QuantizationTableSet" has its own initial states, all set to 128.
"QuantizationTableset"はそれ自身の初期状態を持ち、すべて128に設定されています。
pseudocode | type
--------------------------------------------------------------|-----
QuantizationTableSet( i ) { |
scale = 1 |
for (j = 0; j < MAX_CONTEXT_INPUTS; j++) { |
QuantizationTable( i, j, scale ) |
scale *= 2 * len_count[ i ][ j ] - 1 |
} |
context_count[ i ] = ceil( scale / 2 ) |
} |
"MAX_CONTEXT_INPUTS" is 5.
"max_context_inputs"は5です。
pseudocode | type
--------------------------------------------------------------|-----
QuantizationTable(i, j, scale) { |
v = 0 |
for (k = 0; k < 128;) { |
len - 1 | ur
for (n = 0; n < len; n++) { |
quant_tables[ i ][ j ][ k ] = scale * v |
k++ |
} |
v++ |
} |
for (k = 1; k < 128; k++) { |
quant_tables[ i ][ j ][ 256 - k ] = \ |
-quant_tables[ i ][ j ][ k ] |
} |
quant_tables[ i ][ j ][ 128 ] = \ |
-quant_tables[ i ][ j ][ 127 ] |
len_count[ i ][ j ] = v |
} |
"quant_tables[ i ][ j ][ k ]" indicates the Quantization Table value of the Quantized Sample Difference "k" of the Quantization Table "j" of the Quantization Table Set "i".
「QUANT_TABLES [i] [j] [k]は、量子化テーブルセット「i」の量子化テーブル「j」の量子化サンプル差「k」の量子化テーブル値を示す。
"context_count[ i ]" indicates the count of contexts for Quantization Table Set "i". "context_count[ i ]" MUST be less than or equal to 32768.
"context_count [i]"は、量子化テーブルセット "i"のコンテキストの数を示します。"context_count [i]"は32768以下でなければなりません。
The "Parameters" section, which could be in a global header of a container file that may or may not be considered to be part of the bitstream, contains significant characteristics about the decoding configuration used for all instances of Frame (in FFV1 versions 0 and 1) or the whole FFV1 bitstream (other versions), including the stream version, color configuration, and Quantization Tables. Figure 28 describes the contents of the bitstream.
ビットストリームの一部であると考えることができる、または考慮されていてもいなくてもよく、フレームのすべてのインスタンスに使用されるデコード構成に関する重要な特性（FFV1バージョン0では、パラメータ "セクションは、（FFV1バージョン0と）。1）またはストリームバージョン、カラー構成、および量子化テーブルを含む、FFV1ビットストリーム全体（他のバージョン）。図28は、ビットストリームの内容を説明しています。
"Parameters" has its own initial states, all set to 128.
「パラメータ」には独自の初期状態があり、すべて128に設定されています。
pseudocode | type
--------------------------------------------------------------|-----
Parameters( ) { |
version | ur
if (version >= 3) { |
micro_version | ur
} |
coder_type | ur
if (coder_type > 1) { |
for (i = 1; i < 256; i++) { |
state_transition_delta[ i ] | sr
} |
} |
colorspace_type | ur
if (version >= 1) { |
bits_per_raw_sample | ur
} |
chroma_planes | br
log2_h_chroma_subsample | ur
log2_v_chroma_subsample | ur
extra_plane | br
if (version >= 3) { |
num_h_slices - 1 | ur
num_v_slices - 1 | ur
quant_table_set_count | ur
} |
for (i = 0; i < quant_table_set_count; i++) { |
QuantizationTableSet( i ) |
} |
if (version >= 3) { |
for (i = 0; i < quant_table_set_count; i++) { |
states_coded | br
if (states_coded) { |
for (j = 0; j < context_count[ i ]; j++) { |
for (k = 0; k < CONTEXT_SIZE; k++) { |
initial_state_delta[ i ][ j ][ k ] | sr
} |
} |
} |
} |
ec | ur
intra | ur
} |
} |
Figure 28: A pseudocode description of the bitstream contents.
ビットストリームコンテンツの擬似コードの説明。
CONTEXT_SIZE is 32.
context_sizeは32です。
"version" specifies the version of the FFV1 bitstream.
"version" ffv1ビットストリームのバージョンを指定します。
Each version is incompatible with other versions: decoders SHOULD reject FFV1 bitstreams due to an unknown version.
各バージョンは他のバージョンと互換性がありません。デコーダは、未知のバージョンのためにFFV1ビットストリームを拒否する必要があります。
Decoders SHOULD reject FFV1 bitstreams with "version <= 1 && ConfigurationRecordIsPresent == 1".
デコーダは、「バージョン<= 1 && configurationRecordPresent == 1」でFFV1ビットストリームを拒否する必要があります。
Decoders SHOULD reject FFV1 bitstreams with "version >= 3 && ConfigurationRecordIsPresent == 0".
デコーダは、「バージョン> = 3 && configurationRecordSpresent == 0」でFFV1ビットストリームを拒否する必要があります。
+=======+=========================+
| value | version |
+=======+=========================+
| 0 | FFV1 version 0 |
+-------+-------------------------+
| 1 | FFV1 version 1 |
+-------+-------------------------+
| 2 | reserved* |
+-------+-------------------------+
| 3 | FFV1 version 3 |
+-------+-------------------------+
| Other | reserved for future use |
+-------+-------------------------+
Table 5: The definitions for "version" values.
表5：「バージョン」値の定義。
* Version 2 was experimental and this document does not describe it.
* バージョン2は実験的で、この文書はそれを説明していません。
"micro_version" specifies the micro-version of the FFV1 bitstream.
"micro_version"は、FFV1ビットストリームのマイクロバージョンを指定します。
After a version is considered stable (a micro-version value is assigned to be the first stable variant of a specific version), each new micro-version after this first stable variant is compatible with the previous micro-version: decoders SHOULD NOT reject FFV1 bitstreams due to an unknown micro-version equal or above the micro-version considered as stable.
バージョンが安定した後（マイクロバージョン値が特定のバージョンの最初のバージョンの最初のバリアントに割り当てられます）、この最初の安定したバリアントの後の新しいマイクロバージョンは、前のマイクロバージョンと互換性があります。デコーダはFFV1を拒否しないでください。セットストリームは、マイクロバージョンが安定していると考えられるマイクロバージョン以上のものによるビットストリームです。
Meaning of "micro_version" for "version" 3:
"バージョン" 3の "micro_version"の意味：
+=======+=========================+
| value | micro_version |
+=======+=========================+
| 0...3 | reserved* |
+-------+-------------------------+
| 4 | first stable variant |
+-------+-------------------------+
| Other | reserved for future use |
+-------+-------------------------+
Table 6: The definitions for "micro_version" values for FFV1 version 3.
表6：FFv1バージョン3の "micro_version"値の定義。
* Development versions may be incompatible with the stable variants.
* 開発バージョンは安定した変種と互換性がないかもしれません。
"coder_type" specifies the coder used.
"coder_type"さんのコーダを指定します。
+=======+=================================================+
| value | coder used |
+=======+=================================================+
| 0 | Golomb Rice |
+-------+-------------------------------------------------+
| 1 | Range coder with default state transition table |
+-------+-------------------------------------------------+
| 2 | Range coder with custom state transition table |
+-------+-------------------------------------------------+
| Other | reserved for future use |
+-------+-------------------------------------------------+
Table 7: The definitions for "coder_type" values.
表7： "coder_type"値の定義。
Restrictions:
制限：
If "coder_type" is 0, then "bits_per_raw_sample" SHOULD NOT be > 8.
"coder_type"が0の場合は、 "bits_per_raw_sample"を見つけません> 8。
Background: At the time of this writing, there is no known implementation of FFV1 bitstream supporting the Golomb Rice algorithm with "bits_per_raw_sample" greater than eight, and range coder is preferred.
背景：この書き込み時には、8倍を超える「BITS_PER_RAW_SAMPLE」を用いてゴロン米アルゴリズムをサポートするFFV1ビットストリームの既知の実施はなく、範囲コーダが好ましい。
"state_transition_delta" specifies the range coder custom state transition table.
"state_transition_delta"は、範囲コーダカスタム状態遷移テーブルを指定します。
If "state_transition_delta" is not present in the FFV1 bitstream, all range coder custom state transition table elements are assumed to be 0.
FFV1ビットストリームに "STATE_TRANSITION_DELTA"が存在しない場合、すべての範囲コーダーカスタム遷移表要素は0となると仮定されます。
"colorspace_type" specifies the color space encoded, the pixel transformation used by the encoder, the extra Plane content, as well as interleave method.
「colorspace_type」は、エンコーダによって使用される色空間、エンコーダによって使用されるピクセル変換、ならびにインターリーブ方法を指定します。
+=======+==============+================+==============+============+
| value | color space | pixel | extra Plane | interleave |
| | encoded | transformation | content | method |
+=======+==============+================+==============+============+
| 0 | YCbCr | None | Transparency | Plane then |
| | | | | Line |
+-------+--------------+----------------+--------------+------------+
| 1 | RGB | JPEG 2000 RCT | Transparency | Line then |
| | | | | Plane |
+-------+--------------+----------------+--------------+------------+
| Other | reserved | reserved for | reserved for | reserved |
| | for future | future use | future use | for future |
| | use | | | use |
+-------+--------------+----------------+--------------+------------+
Table 8: The definitions for "colorspace_type" values.
表8：「ColorSpace_Type」の値の定義。
FFV1 bitstreams with "colorspace_type == 1 && (chroma_planes != 1 || log2_h_chroma_subsample != 0 || log2_v_chroma_subsample != 0)" are not part of this specification.
"colorspace_type == 1 &&（chroma_planes！|| log2_h_chroma_subsample！= 0 || log2_v_chroma_subsample！= 0）"がこの仕様の一部ではありません。
"chroma_planes" indicates if chroma (color) Planes are present.
「Chroma_planes」は、Chroma（Color）プレーンが存在するかどうかを示します。
+=======+===============================+
| value | presence |
+=======+===============================+
| 0 | chroma Planes are not present |
+-------+-------------------------------+
| 1 | chroma Planes are present |
+-------+-------------------------------+
Table 9: The definitions for "chroma_planes" values.
表9：「Chroma_Planes」の値の定義。
"bits_per_raw_sample" indicates the number of bits for each Sample. Inferred to be 8 if not present.
「bits_per_raw_sample」は、各サンプルのビット数を示します。存在しない場合は8と推測されています。
+=======+=================================+
| value | bits for each Sample |
+=======+=================================+
| 0 | reserved* |
+-------+---------------------------------+
| Other | the actual bits for each Sample |
+-------+---------------------------------+
Table 10: The definitions for "bits_per_raw_sample" values.
表10：「bits_per_raw_sample」値の定義。
* Encoders MUST NOT store "bits_per_raw_sample = 0". Decoders SHOULD accept and interpret "bits_per_raw_sample = 0" as 8.
* エンコーダは「bits_per_raw_sample = 0」を保存してはいけません。デコーダは、「BITS_PER_RAW_SAMPLE = 0」を受け入れ、解釈する必要があります。
"log2_h_chroma_subsample" indicates the subsample factor, stored in powers to which the number 2 is raised, between luma and chroma width ("chroma_width = 2 ^ -log2_h_chroma_subsample * luma_width").
"log2_h_chroma_subSample"はサブサンプル要因を示し、LumaとChroma幅の間で数値2が上昇している電力に格納されています（ "chroma_width = 2 ^ -log2_h_chroma_subsample * luma_width"）。
"log2_v_chroma_subsample" indicates the subsample factor, stored in powers to which the number 2 is raised, between luma and chroma height ("chroma_height = 2 ^ -log2_v_chroma_subsample * luma_height").
"log2_v_chroma_subsample"はサブサンプルファクタを示し、ルーマ2が発生し、LumaとChromaの高さの間に、数2が発生した電力に格納されています（ "chroma_height = 2 ^ -log2_v_chroma_subsample * luma_height"）。
"extra_plane" indicates if an extra Plane is present.
「Extra_Plane」は、余分な平面が存在するかどうかを示します。
+=======+============================+
| value | presence |
+=======+============================+
| 0 | extra Plane is not present |
+-------+----------------------------+
| 1 | extra Plane is present |
+-------+----------------------------+
Table 11: The definitions for "extra_plane" values.
表11：「Extra_Plane」値の定義。
"num_h_slices" indicates the number of horizontal elements of the Slice raster.
「NUM_H_SLICES」は、スライスラスタの水平要素数を示す。
Inferred to be 1 if not present.
存在しない場合は1になると推論されます。
"num_v_slices" indicates the number of vertical elements of the Slice raster.
「NUM_V_SLICES」は、スライスラスタの垂直要素の数を示す。
Inferred to be 1 if not present.
存在しない場合は1になると推論されます。
"quant_table_set_count" indicates the number of Quantization Table Sets. "quant_table_set_count" MUST be less than or equal to 8.
"quant_table_set_count"は、量子化テーブルセットの数を示します。"quant_table_set_count"は8以下でなければなりません。
Inferred to be 1 if not present.
存在しない場合は1になると推論されます。
MUST NOT be 0.
0にしてはいけません。
"states_coded" indicates if the respective Quantization Table Set has the initial states coded.
「state_coded」は、それぞれの量子化テーブルセットに初期状態が符号化されているかどうかを示す。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
+=======+================================+
| value | initial states |
+=======+================================+
| 0 | initial states are not present |
| | and are assumed to be all 128 |
+-------+--------------------------------+
| 1 | initial states are present |
+-------+--------------------------------+
Table 12: The definitions for "states_coded" values.
表12： "state_coded"値の定義。
"initial_state_delta[ i ][ j ][ k ]" indicates the initial range coder state, and it is encoded using "k" as context index for the range coder and the following pseudocode:
"Initial_State_Delta [i] [j] [k]"は初期範囲コーダ状態を示し、範囲コーダのコンテキストインデックスとして "k"を使用して符号化され、次の擬似コードが符号化される。
pred = j ? initial_states[ i ][j - 1][ k ] : 128
Figure 29: Predictor value for the coding of "initial_state_delta[ i ][ j ][ k ]".
図29：「INITIAL_STATE_DELTA [i] [j] [k]の符号化の予測値。
initial_state[ i ][ j ][ k ] = ( pred + initial_state_delta[ i ][ j ][ k ] ) & 255
initial_state [i] [j] [k] =（Pred Initial_State_Delta [i] [j] [k]）＆255
Figure 30: Description of the coding of "initial_state_delta[ i ][ j ][ k ]".
図30： "Initial_State_Delta [i] [j] [k]"のコーディングの説明。
"ec" indicates the error detection/correction type.
「EC」は、誤り検出/補正タイプを示す。
+=======+=================================================+
| value | error detection/correction type |
+=======+=================================================+
| 0 | 32-bit CRC in "ConfigurationRecord" |
+-------+-------------------------------------------------+
| 1 | 32-bit CRC in "Slice" and "ConfigurationRecord" |
+-------+-------------------------------------------------+
| Other | reserved for future use |
+-------+-------------------------------------------------+
Table 13: The definitions for "ec" values.
表13：「EC」値の定義。
"intra" indicates the constraint on "keyframe" in each instance of Frame.
「イントラ」は、フレームの各インスタンス内の「キーフレーム」の制約を示します。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
+=======+=======================================================+
| value | relationship |
+=======+=======================================================+
| 0 | "keyframe" can be 0 or 1 (non keyframes or keyframes) |
+-------+-------------------------------------------------------+
| 1 | "keyframe" MUST be 1 (keyframes only) |
+-------+-------------------------------------------------------+
| Other | reserved for future use |
+-------+-------------------------------------------------------+
Table 14: The definitions for "intra" values.
表14：「イントラ」値の定義。
In the case of a FFV1 bitstream with "version >= 3", a "Configuration Record" is stored in the underlying container as described in Section 4.3.3. It contains the "Parameters" used for all instances of Frame. The size of the "Configuration Record", "NumBytes", is supplied by the underlying container.
「バージョン> = 3」のFFv1ビットストリームの場合、セクション4.3.3で説明されているように、基礎となるコンテナに「構成レコード」が格納されています。フレームのすべてのインスタンスに使用される「パラメータ」が含まれています。「構成レコード」、「NUMBYTES」のサイズは、基礎となるコンテナによって提供されます。
pseudocode | type
-----------------------------------------------------------|-----
ConfigurationRecord( NumBytes ) { |
ConfigurationRecordIsPresent = 1 |
Parameters( ) |
while (remaining_symbols_in_syntax(NumBytes - 4)) { |
reserved_for_future_use | br/ur/sr
} |
configuration_record_crc_parity | u(32)
} |
"reserved_for_future_use" is a placeholder for future updates of this specification.
"reserved_for_future_use"は、この仕様の将来の更新のためのプレースホルダーです。
Encoders conforming to this version of this specification SHALL NOT write "reserved_for_future_use".
この仕様のこのバージョンに準拠したエンコーダは、 "reserved_for_future_use"を書いてはいけません。
Decoders conforming to this version of this specification SHALL ignore "reserved_for_future_use".
この仕様のこのバージョンに準拠したデコーダは、 "reserved_for_future_use"を無視します。
"configuration_record_crc_parity" is 32 bits that are chosen so that the "Configuration Record" as a whole has a CRC remainder of zero.
"configuration_record_crc_parity"は、全体としての「設定レコード」にCRCの残りのゼロを持つように選択された32ビットです。
This is equivalent to storing the CRC remainder in the 32-bit parity.
これは、CRCの残りを32ビットパリティに格納することと同じです。
The CRC generator polynomial used is described in Section 4.9.3.
使用されているCRCジェネレータ多項式は4.9.3節で説明されています。
This "Configuration Record" can be placed in any file format that supports "Configuration Records", fitting as much as possible with how the file format stores "Configuration Records". The "Configuration Record" storage place and "NumBytes" are currently defined and supported for the following formats:
この「構成レコード」は、ファイルのフォーマットに「構成レコード」をどのように保存するかをできるだけできる限り、できるだけ適合させるファイル形式で配置できます。「構成レコード」の記憶場所と「NUMBYTES」は現在定義され、次の形式でサポートされています。
The "Configuration Record" extends the stream format chunk ("AVI ", "hdlr", "strl", "strf") with the "ConfigurationRecord" bitstream.
「構成レコード」は、「ConfigurationRecord」ビットストリームでストリームフォーマットチャンク（ "AVI"、 "HDLR"、 "STRL"、 "STRF"）を拡張します。
See [AVI] for more information about chunks.
チャンクの詳細については[AVI]を参照してください。
"NumBytes" is defined as the size, in bytes, of the "strf" chunk indicated in the chunk header minus the size of the stream format structure.
「NUMBYTES」は、チャンクヘッダに示されている「STRF」チャンクのサイズ（バイト単位）として定義されている。
The "Configuration Record" extends the sample description box ("moov", "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box that contains the "ConfigurationRecord" bitstream. See [ISO.14496-12.2020] for more information about boxes.
「構成レコード」は、「ConfigurationRecord」ビットストリームを含む「GLBL」ボックスで、サンプル記述ボックス（ "moov"、 "trak"、 "minf"、 "stbl"、 "stsd"）を拡張します。ボックスの詳細については[ISO.14496-12.2020]を参照してください。
"NumBytes" is defined as the size, in bytes, of the "glbl" box indicated in the box header minus the size of the box header.
「NUMBYTES」は、ボックスヘッダに表示されている「GLBL」ボックスのサイズ（BYS）として定義されています。
The "codec_specific_data" element (in "stream_header" packet) contains the "ConfigurationRecord" bitstream. See [NUT] for more information about elements.
"SODEC_SPECIFIC_DATA"要素（ "stream_header"パケット）には "ConfigurationRecord"ビットストリームが含まれています。要素の詳細については、[ナット]を参照してください。
"NumBytes" is defined as the size, in bytes, of the "codec_specific_data" element as indicated in the "length" field of "codec_specific_data".
「NUMBYTES」は、「codec_specific_data」の「length」フィールドに示されているように、 "codec_specific_data"要素のサイズ（バイト単位）として定義されています。
FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" Element MUST contain the FFV1 "Configuration Record" structure and no other data. See [Matroska] for more information about elements.
FFV1はMatroska "Codec ID"として "v_ffv1"を使用する必要があります。FFV1バージョン2以下の場合、Matroska "codecprivate"要素は使用しないでください。FFV1バージョン3以上の場合、Matroska "codecprivate"要素には、FFV1 "構成レコード"構造と他のデータが含まれていなければなりません。要素の詳細については[Matrioska]を参照してください。
"NumBytes" is defined as the "Element Data Size" of the "CodecPrivate" Element.
「NUMBYTES」は、「codecprivate」要素の「要素データサイズ」として定義されています。
A "Frame" is an encoded representation of a complete static image. The whole "Frame" is provided by the underlying container.
「フレーム」は、完全な静的画像の符号化表現である。全体の「フレーム」は、基礎となるコンテナによって提供されます。
A "Frame" consists of the "keyframe" field, "Parameters" (if "version <= 1"), and a sequence of independent Slices. The pseudocode below describes the contents of a "Frame".
「フレーム」は、「キーフレーム」フィールド「パラメータ」（「バージョン<= 1」）、および一連の独立スライスで構成されています。以下の擬似コードは「フレーム」の内容を表しています。
The "keyframe" field has its own initial state, set to 128.
「キーフレーム」フィールドには独自の初期状態があり、128に設定されています。
pseudocode | type
--------------------------------------------------------------|-----
Frame( NumBytes ) { |
keyframe | br
if (keyframe && !ConfigurationRecordIsPresent { |
Parameters( ) |
} |
while (remaining_bits_in_bitstream( NumBytes )) { |
Slice( ) |
} |
} |
The following is an architecture overview of Slices in a Frame:
以下は、フレーム内のスライスのアーキテクチャの概要です。
+-----------------------------------------------------------------+
| first Slice header |
+-----------------------------------------------------------------+
| first Slice content |
+-----------------------------------------------------------------+
| first Slice footer |
+-----------------------------------------------------------------+
| --------------------------------------------------------------- |
+-----------------------------------------------------------------+
| second Slice header |
+-----------------------------------------------------------------+
| second Slice content |
+-----------------------------------------------------------------+
| second Slice footer |
+-----------------------------------------------------------------+
| --------------------------------------------------------------- |
+-----------------------------------------------------------------+
| ... |
+-----------------------------------------------------------------+
| --------------------------------------------------------------- |
+-----------------------------------------------------------------+
| last Slice header |
+-----------------------------------------------------------------+
| last Slice content |
+-----------------------------------------------------------------+
| last Slice footer |
+-----------------------------------------------------------------+
A "Slice" is an independent, spatial subsection of a Frame that is encoded separately from another region of the same Frame. The use of more than one "Slice" per Frame provides opportunities for taking advantage of multithreaded encoding and decoding.
「スライス」は、同じフレームの他の領域とは別に符号化されているフレームの独立した空間サブセクションです。フレームごとに複数の「スライス」を使用することは、マルチスレッド符号化および復号化を利用する機会を提供する。
A "Slice" consists of a "Slice Header" (when relevant), a "Slice Content", and a "Slice Footer" (when relevant). The pseudocode below describes the contents of a "Slice".
「スライス」は、「スライスヘッダー」（関連する場合）、「スライスコンテンツ」、「スライスフッター」（関連する場合）で構成されています。以下の擬似コードは「スライス」の内容を説明しています。
pseudocode | type
--------------------------------------------------------------|-----
Slice( ) { |
if (version >= 3) { |
SliceHeader( ) |
} |
SliceContent( ) |
if (coder_type == 0) { |
while (!byte_aligned()) { |
padding | u(1)
} |
} |
if (version <= 1) { |
while (remaining_bits_in_bitstream( NumBytes ) != 0) {|
reserved | u(1)
} |
} |
if (version >= 3) { |
SliceFooter( ) |
} |
} |
"padding" specifies a bit without any significance and used only for byte alignment. "padding" MUST be 0.
"Padding"は重要なことなくビットを指定し、バイトアライメントにのみ使用されます。「パディング」は0でなければなりません。
"reserved" specifies a bit without any significance in this specification but may have a significance in a later revision of this specification.
「予約済み」は、この仕様において重要なことなくビットを指定しますが、この仕様の後のリビジョンにおいて重要性があります。
Encoders SHOULD NOT fill "reserved".
エンコーダは「予約」を記入してはいけません。
Decoders SHOULD ignore "reserved".
デコーダは「予約済み」を無視する必要があります。
A "Slice Header" provides information about the decoding configuration of the "Slice", such as its spatial position, size, and aspect ratio. The pseudocode below describes the contents of the "Slice Header".
「スライスヘッダ」は、その空間位置、サイズ、およびアスペクト比などの「スライス」の復号化構成に関する情報を提供する。以下の疑似コードは、「スライスヘッダー」の内容を説明しています。
"Slice Header" has its own initial states, all set to 128.
「スライスヘッダ」はそれ自身の初期状態を持ち、すべて128に設定されています。
pseudocode | type
--------------------------------------------------------------|-----
SliceHeader( ) { |
slice_x | ur
slice_y | ur
slice_width - 1 | ur
slice_height - 1 | ur
for (i = 0; i < quant_table_set_index_count; i++) { |
quant_table_set_index[ i ] | ur
} |
picture_structure | ur
sar_num | ur
sar_den | ur
} |
"slice_x" indicates the x position on the Slice raster formed by "num_h_slices".
「SLICE_X」は、「NUM_H_SLICES」によって形成されたスライスラスタ上のX位置を示す。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
"slice_y" indicates the y position on the Slice raster formed by "num_v_slices".
「SLICE_Y」は、「NUM_V_SLICES」によって形成されたスライスラスタ上のY位置を示す。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
"slice_width" indicates the width on the Slice raster formed by "num_h_slices".
"slice_width"は、 "num_h_slices"によって形成されたスライスラスタ上の幅を示します。
Inferred to be 1 if not present.
存在しない場合は1になると推論されます。
"slice_height" indicates the height on the Slice raster formed by "num_v_slices".
"slice_height"は、 "num_v_slices"によって形成されたスライスラスタ上の高さを示します。
Inferred to be 1 if not present.
存在しない場合は1になると推論されます。
"quant_table_set_index_count" is defined as the following:
"quant_table_set_index_count"は次のように定義されています。
1 + ( ( chroma_planes || version <= 3 ) ? 1 : 0 )
+ ( extra_plane ? 1 : 0 )
"quant_table_set_index" indicates the Quantization Table Set index to select the Quantization Table Set and the initial states for the "Slice Content".
"quant_table_set_index"は、量子化テーブルセットと「スライスコンテンツ」の初期状態を選択するための量子化テーブルセットインデックスを示します。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
"picture_structure" specifies the temporal and spatial relationship of each Line of the Frame.
「picture_structure」フレームの各行の時間的および空間的関係を指定します。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
+=======+=========================+
| value | picture structure used |
+=======+=========================+
| 0 | unknown |
+-------+-------------------------+
| 1 | top field first |
+-------+-------------------------+
| 2 | bottom field first |
+-------+-------------------------+
| 3 | progressive |
+-------+-------------------------+
| Other | reserved for future use |
+-------+-------------------------+
Table 15: The definitions for "picture_structure" values.
表15：「picture_structure」の値の定義。
"sar_num" specifies the Sample aspect ratio numerator.
「SAR_NUM」は、サンプルアスペクト比分子を指定します。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
A value of 0 means that aspect ratio is unknown.
値0は、アスペクト比が不明であることを意味します。
Encoders MUST write 0 if the Sample aspect ratio is unknown.
サンプルアスペクト比が不明の場合は、エンコーダが0を書き込む必要があります。
If "sar_den" is 0, decoders SHOULD ignore the encoded value and consider that "sar_num" is 0.
"sar_den"が0の場合、デコーダはエンコードされた値を無視し、 "sar_num"が0であると考える必要があります。
"sar_den" specifies the Sample aspect ratio denominator.
「SAR_DEN」は、サンプルアスペクト比分母を指定します。
Inferred to be 0 if not present.
存在しない場合は0になると推論されます。
A value of 0 means that aspect ratio is unknown.
値0は、アスペクト比が不明であることを意味します。
Encoders MUST write 0 if the Sample aspect ratio is unknown.
サンプルアスペクト比が不明の場合は、エンコーダが0を書き込む必要があります。
If "sar_num" is 0, decoders SHOULD ignore the encoded value and consider that "sar_den" is 0.
"sar_num"が0の場合、デコーダはエンコードされた値を無視し、 "sar_den"が0であると考える必要があります。
A "Slice Content" contains all Line elements part of the "Slice".
「スライスコンテンツ」には、「スライス」のすべての行要素部分が含まれています。
Depending on the configuration, Line elements are ordered by Plane then by row (YCbCr) or by row then by Plane (RGB).
構成に応じて、線要素は平面によって行（YCBCR）によって、または平面（RGB）によって平面によって順序付けされます。
pseudocode | type
--------------------------------------------------------------|-----
SliceContent( ) { |
if (colorspace_type == 0) { |
for (p = 0; p < primary_color_count; p++) { |
for (y = 0; y < plane_pixel_height[ p ]; y++) { |
Line( p, y ) |
} |
} |
} else if (colorspace_type == 1) { |
for (y = 0; y < slice_pixel_height; y++) { |
for (p = 0; p < primary_color_count; p++) { |
Line( p, y ) |
} |
} |
} |
} |
"primary_color_count" is defined as the following:
"primary_color_count"は次のように定義されています。
1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 )
"plane_pixel_height[ p ]" is the height in pixels of Plane p of the "Slice". It is defined as the following:
「PLANGE_PIXEL_HEIGHT [P] "は、「スライス」の平面Pのピクセルの高さです。これは次のように定義されています。
chroma_planes == 1 && (p == 1 || p == 2)
? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))
: slice_pixel_height
"slice_pixel_height" is the height in pixels of the Slice. It is defined as the following:
"slice_pixel_height"はスライスのピクセル単位の高さです。これは次のように定義されています。
floor( ( slice_y + slice_height ) * slice_pixel_height / num_v_slices ) - slice_pixel_y.
フロア（（slice_y slice_height）* slice_pixel_height / num_v_slices） - slice_pixel_y。
"slice_pixel_y" is the Slice vertical position in pixels. It is defined as the following:
"slice_pixel_y"は、ピクセル単位のスライス垂直位置です。これは次のように定義されています。
floor( slice_y * frame_pixel_height / num_v_slices )
A "Line" is a list of the Sample Differences (relative to the predictor) of primary color components. The pseudocode below describes the contents of the "Line".
「線」は、一次色成分の（予測因子に対する）サンプル差のリストです。以下の疑似コードは「行」の内容を表しています。
pseudocode | type
--------------------------------------------------------------|-----
Line( p, y ) { |
if (colorspace_type == 0) { |
for (x = 0; x < plane_pixel_width[ p ]; x++) { |
sample_difference[ p ][ y ][ x ] | sd
} |
} else if (colorspace_type == 1) { |
for (x = 0; x < slice_pixel_width; x++) { |
sample_difference[ p ][ y ][ x ] | sd
} |
} |
} |
"plane_pixel_width[ p ]" is the width in pixels of Plane p of the "Slice". It is defined as the following:
「PLANGE_PIXEL_WIDTH [P] "は、「スライス」の平面Pのピクセル単位である。これは次のように定義されています。
chroma_planes == 1 && (p == 1 || p == 2) ? ceil( slice_pixel_width / (1 << log2_h_chroma_subsample) ) : slice_pixel_width.
chroma_planes == 1 &&（p == 1 || p == 2）？CEIL（SLICE_PIXEL_WIDTH /（1 << LOG2_H_HROMA_SUBSAMPLE））：slice_pixel_width。
"slice_pixel_width" is the width in pixels of the Slice. It is defined as the following:
"slice_pixel_width"はスライスのピクセル単位の幅です。これは次のように定義されています。
floor( ( slice_x + slice_width ) * slice_pixel_width / num_h_slices ) - slice_pixel_x
Floor（（SLICE_X SLICE_WIDTH）* SLICE_PIXEL_WIDTH / NUM_H_SLICES） - SLICE_PIXEL_X
"slice_pixel_x" is the Slice horizontal position in pixels. It is defined as the following:
"slice_pixel_x"は、ピクセル単位のスライス水平位置です。これは次のように定義されています。
floor( slice_x * frame_pixel_width / num_h_slices )
"sample_difference[ p ][ y ][ x ]" is the Sample Difference for Sample at Plane "p", y position "y", and x position "x". The Sample value is computed based on median predictor and context described in Section 3.2.
「sample_difference [p] [y] [x]は、平面「P」、Y位置「Y」、X位置「X」のサンプルのサンプル差である。サンプル値は、セクション3.2で説明されている中央値およびコンテキストに基づいて計算されます。
A "Slice Footer" provides information about Slice size and (optionally) parity. The pseudocode below describes the contents of the "Slice Footer".
「スライスフッター」は、スライスサイズと（オプションで）パリティに関する情報を提供します。以下の疑似コードは、「スライスフッター」の内容を表しています。
Note: "Slice Footer" is always byte aligned.
注：「スライスフッター」は常にバイト整列しています。
pseudocode | type
--------------------------------------------------------------|-----
SliceFooter( ) { |
slice_size | u(24)
if (ec) { |
error_status | u(8)
slice_crc_parity | u(32)
} |
} |
"slice_size" indicates the size of the Slice in bytes.
"slice_size"はスライスのサイズをバイト単位で示します。
Note: this allows finding the start of Slices before previous Slices have been fully decoded and allows parallel decoding as well as error resilience.
注：これにより、以前のスライスが完全に復号されている前にスライスの開始を見つけることができ、エラー回復力だけでなく並列復号化を可能にします。
"error_status" specifies the error status.
"error_status"エラーステータスを指定します。
+=======+=======================================+
| value | error status |
+=======+=======================================+
| 0 | no error |
+-------+---------------------------------------+
| 1 | Slice contains a correctable error |
+-------+---------------------------------------+
| 2 | Slice contains an uncorrectable error |
+-------+---------------------------------------+
| Other | reserved for future use |
+-------+---------------------------------------+
Table 16: The definitions for "error_status" values.
表16： "error_status"値の定義。
"slice_crc_parity" is 32 bits that are chosen so that the Slice as a whole has a CRC remainder of 0.
"slice_crc_parity"は、スライス全体がCRCの残りを持つように選択された32ビットです。
This is equivalent to storing the CRC remainder in the 32-bit parity.
これは、CRCの残りを32ビットパリティに格納することと同じです。
The CRC generator polynomial used is the standard IEEE CRC polynomial (0x104C11DB7) with initial value 0, without pre-inversion, and without post-inversion.
使用されるCRCジェネレータ多項式は、標準のIEEE CRC多項式（0x104C11DB7）であり、初期値0、プリインバイダンスがなく、転倒後もあります。
To ensure that fast multithreaded decoding is possible, starting with version 3 and if "frame_pixel_width * frame_pixel_height" is more than 101376, "slice_width * slice_height" MUST be less or equal to "num_h_slices * num_v_slices / 4". Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF (Common Intermediate Format) frame size format.
バージョン3から始まり、 "frame_pixel_width * frame_pixel_height"が101376を超える場合は、 "slice_width * slice_height"が "slice_width * num_v_slices / 4"にしてください。注：101376は、CIF（Common Intermate Format）フレームサイズフォーマットとも呼ばれ、352 x 288フレームのピクセル単位です。
For each Frame, each position in the Slice raster MUST be filled by one and only one Slice of the Frame (no missing Slice position and no Slice overlapping).
各フレームについて、スライスラスタ内の各位置は、フレームのスライス（欠けていないスライス位置とスライスの重なりなし）を1つだけ充填する必要があります。
For each Frame with a "keyframe" value of 0, each Slice MUST have the same value of "slice_x", "slice_y", "slice_width", and "slice_height" as a Slice in the previous Frame.
「キーフレーム」値が0の各フレームに対して、各スライスは、前のフレームのスライスとして、同じ値 "SLICE_X"、 "slice_y"、 "slice_width"、および "slice_height"の値を持たなければなりません。
Like any other codec (such as [RFC6716]), FFV1 should not be used with insecure ciphers or cipher modes that are vulnerable to known plaintext attacks. Some of the header bits as well as the padding are easily predictable.
他のコーデック（RFC6716]など）と同様に、FFV1は、既知の平文攻撃に対して脆弱な不安な暗号または暗号モードで使用しないでください。ヘッダービットのいくつかとパディングは簡単に予測できます。
Implementations of the FFV1 codec need to take appropriate security considerations into account. Those related to denial of service are outlined in Section 2.1 of [RFC4732]. It is extremely important for the decoder to be robust against malicious payloads. Malicious payloads MUST NOT cause the decoder to overrun its allocated memory 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 the encoder to misbehave because this would allow an attacker to attack transcoding gateways. A frequent security problem in image and video codecs is failure to check for integer overflows. An example is allocating "frame_pixel_width * frame_pixel_height" in pixel count computations without considering that the multiplication result may have overflowed the range of the arithmetic type. The range coder could, if implemented naively, read one byte over the end. The implementation MUST ensure that no read outside allocated and initialized memory occurs.
FFV1コーデックの実装は、適切なセキュリティ上の考慮事項を考慮に入れる必要があります。サービス拒否に関連するものは、[RFC4732]のセクション2.1で概説されています。デコーダが悪意のあるペイロードに対して堅牢であることは非常に重要です。悪意のあるペイロードは、デコーダに割り当てられたメモリをオーバーランさせること、またはデコードするために過剰なリソースを取り除く必要があります。割り当てられたメモリのオーバーランは、攻撃者による任意のコード実行につながる可能性があります。エンコーダ内の問題が典型的にはRARERであっても、エンコーダについても同様である。悪意のあるビデオストリームは、攻撃者がトランスコーディングゲートウェイを攻撃することを可能にするので、エンコーダに不正行為を引き起こさないでください。画像およびビデオコーデックの頻繁なセキュリティ問題は、整数オーバーフローをチェックできないことです。例は、乗算結果が算術型の範囲をオーバーフローした可能性があることを考慮せずに、ピクセルカウント計算で「frame_pixel_width * frame_pixel_height」を割り当てています。範囲コーダは、不自由に実装された場合に、最後に1バイトを読み取ることができる。実装は、読み取られた読み出しおよび初期化メモリが発生しないようにする必要があります。
None of the content carried in FFV1 is intended to be executable.
FFV1で実行されているコンテンツはどれも実行可能であることを意図していません。
IANA has registered the following values.
IANAは以下の値を登録しました。
This registration is done using the template defined in [RFC6838] and following [RFC4855].
この登録は、[RFC6838]で定義されているテンプレートを使用して[RFC4855]を使用して行われます。
Type name: video
タイプ名：ビデオ
Subtype name: FFV1
サブタイプ名：FFv1
Required parameters: None.
必要なパラメータ：なし。
Optional parameters: These parameters are used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose.
オプションのパラメータ：これらのパラメータは、受信側実装の機能を知らせるために使用されます。これらのパラメータは他の目的には使用しないでください。
"version": The "version" of the FFV1 encoding as defined by Section 4.2.1.
"バージョン"：4.2.1項で定義されているFFV1エンコーディングの "バージョン"。
"micro_version": The "micro_version" of the FFV1 encoding as defined by Section 4.2.2.
"micro_version"：セクション4.2.2で定義されているFFV1エンコーディングの "micro_version"。
"coder_type": The "coder_type" of the FFV1 encoding as defined by Section 4.2.3.
"coder_type"：セクション4.2.3で定義されているFFv1エンコーディングの "coder_type"。
"colorspace_type": The "colorspace_type" of the FFV1 encoding as defined by Section 4.2.5.
"colorspace_type"：セクション4.2.5で定義されているFFv1エンコーディングの "colorspace_type"。
"bits_per_raw_sample": The "bits_per_raw_sample" of the FFV1 encoding as defined by Section 4.2.7.
"bits_per_raw_sample"：セクション4.2.7で定義されているFFv1エンコーディングの "bits_per_raw_sample"。
"max_slices": The value of "max_slices" is an integer indicating the maximum count of Slices within a Frame of the FFV1 encoding.
"max_slices"： "max_slices"の値は、FFV1エンコーディングのフレーム内のスライスの最大数を示す整数です。
Encoding considerations: This media type is defined for encapsulation in several audiovisual container formats and contains binary data; see Section 4.3.3. This media type is framed binary data; see Section 4.8 of [RFC6838].
エンコードに関する考慮事項：このメディアタイプは、いくつかの視聴覚コンテナフォーマットでのカプセル化に対して定義されており、バイナリデータが含まれています。セクション4.3.3を参照してください。このメディアタイプは2値データです。[RFC6838]のセクション4.8を参照してください。
Security considerations: See Section 6 of this document.
セキュリティに関する考慮事項：この文書の6章を参照してください。
Interoperability considerations: None.
相互運用性の考慮事項：なし。
Published specification: RFC 9043.
公開仕様：RFC 9043。
Applications that use this media type: Any application that requires the transport of lossless video can use this media type. Some examples are, but not limited to, screen recording, scientific imaging, and digital video preservation.
このメディアタイプを使用するアプリケーション：ロスレスビデオのトランスポートが必要なアプリケーションは、このメディアタイプを使用できます。いくつかの例は、スクリーン記録、科学的イメージング、およびデジタルビデオの保存に限定されない。
Fragment identifier considerations: N/A.
フラグメント識別子の考慮事項：N / A。
Additional information: None.
追加情報：なし。
Person & email address to contact for further information: Michael Niedermayer (mailto:michael@niedermayer.cc)
詳細については、お問い合わせ先：Michael Niedermayer（mailto：michael@niedermayer.cc）
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: None.
使用制限：なし。
Author: Dave Rice (mailto:dave@dericed.com)
Change controller: IETF CELLAR Working Group delegated from the IESG.
変更コントローラ：IESGから委任されたIETF Cellarワーキンググループ。
[ISO.9899.2018] International Organization for Standardization, "Information technology - Programming languages - C", ISO/ IEC 9899:2018, June 2018.
[ISO.9899.2018]国際標準化組織「情報技術 - プログラミング言語 - C」、ISO / IEC 9899：2018、2018年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <https://www.rfc-editor.org/info/rfc4732>.
[RFC4732]ハンドリー、M.、ED。、RESCORLA、E.、ED。、およびIAB、「インターネット拒否サービス考慮事項」、RFC 4732、DOI 10.17487 / RFC4732、2006年12月、<https：// www。rfc-editor.org/info/rfc4732>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S.、RTPペイロードフォーマットの「メディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<https：//www.rfc-editor.org/info/rfc4855>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[AddressSanitizer] Clang Project, "AddressSanitizer", Clang 12 documentation, <https://clang.llvm.org/docs/AddressSanitizer.html>.
[addressSAnitizer] clangプロジェクト、 "addresssAnitizer"、clang 12のドキュメント、<https：//clang.llvm.org/docs/addresssanitizer.html>。
[AVI] Microsoft, "AVI RIFF File Reference", <https://docs.microsoft.com/en-us/windows/win32/directshow/avi-riff-file-reference>.
[AVI]マイクロソフト、「AVI RIFFファイルリファレンス」、<https：//docs.microsoft.com/en-us/windows/win32/directshow/avi-riff-file-reference>。
[FFV1GO] Buitenhuis, D., "FFV1 Decoder in Go", 2019, <https://github.com/dwbuiten/go-ffv1>.
[FFV1GO] Buitenhuis、D.、 "FFV1デコーダin Go"、2019、<https：//github.com/dwbuiten/go-ffv1>。
[FFV1_V0] Niedermayer, M., "Commit to mark FFV1 version 0 as non-experimental", April 2006, <https://git.videolan.org/?p=ff mpeg.git;a=commit;h=b548f2b91b701e1235608ac882ea6df915167c 7e>.
[FFV1_v0] Niedermayer、M.、2006年4月、2006年4月、<https://git.videolan.org/?p=ff mpeg.git; a = commit; h = b548f2b701e1235608Ac882J701J1235608AC882B701E1235608AC882JJ16DF91560882JJ12J1235608AC882AJ16DF915682J16DF915682062J16DF9156082JJ16DF91567C7e>。
[FFV1_V1] Niedermayer, M., "Commit to release FFV1 version 1", April 2009, <https://git.videolan.org/?p=ffmpeg.git;a=commit;h=6 8f8d33becbd73b4d0aa277f472a6e8e72ea6849>.
[FFV1_v1] Niedermayer、M.、2009年4月、<https://git.videolan.org/?p=ffmpeg.git.A=Commit.h=68D33BeCBD73B4D0AA277F472A6E8B4D0A277F472A6E8B4D0AA277F472A6E8B4D0AA277F472A6E8B4D0AA277F472A6E8E72277F472A6E8E72277F472A6E8E72277F472A6E8E72277F472A6E8E722JA277F472A6E8E72JA6849>。
[FFV1_V3] Niedermayer, M., "Commit to mark FFV1 version 3 as non-experimental", August 2013, <https://git.videolan.org/?p=f fmpeg.git;a=commit;h=abe76b851c05eea8743f6c899cbe5f7409b0f 301>.
【FFV1_V3]Niedermayer、M.、2013年8月、<https://git.videolan.org/?p=ffmpeg.git"非実験としてFFV1バージョン3をマークするためにコミット";=コミット; H=abe76b851c05eea8743f6c899cbe5f7409b0f301>。
[HuffYUV] Rudiak-Gould, B., "HuffYUV revisited", December 2003, <https://web.archive.org/web/20040402121343/ http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>.
[Huffyuv] Rudiak-Gould、B.、 "Huffyuv Revisited"、2003年12月、<https://web.archive.org/web/20040402121343/ http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html>。
[ISO.14495-1.1999] International Organization for Standardization, "Information technology -- Lossless and near-lossless compression of continuous-tone still images: Baseline", ISO/IEC 14495-1:1999, December 1999.
[ISO.14495-1999]国際標準化、「情報技術 - 連続階調静止画の無損失、無損失圧縮：ベースライン」、ISO / IEC 14495-1：1999年12月、1999年12月。
[ISO.14496-10.2020] International Organization for Standardization, "Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding", ISO/IEC 14496-10:2020, December 2020.
[ISO.14496-10.2020]国際標準化のための国際機関「情報技術 - オーディオビジュアルオブジェクトの符号化 - 第10回：Advanced Video Coding」、ISO / IEC 14496-10：2020、2020年12月。
[ISO.14496-12.2020] International Organization for Standardization, "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/IEC 14496-12:2020, December 2020.
[ISO.14496-12.2020]国際標準化のための国際機関「情報技術 - オーディオビジュアルオブジェクトの符号化 - 第12報、ISO基本メディアファイル形式」、ISO / IEC 14496-12：2020年12月、2020年12月。
[ISO.15444-1.2019] International Organization for Standardization, "Information technology -- JPEG 2000 image coding system: Core coding system", ISO/IEC 15444-1:2019, October 2019.
[ISO.15444-1.2019]国際標準化のための国際機構「情報技術 - JPEG 2000画像符号化システム：コアコーディングシステム」、ISO / IEC 15444-1：2019年10月、2019年10月。
[Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media Container Format Specifications", Work in Progress, Internet-Draft, draft-ietf-cellar-matroska-07, 12 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-07>.
[Matroska] Lhomme、S.、Bunkus、M.、D.米、「Matroska Media Container形式の仕様」、進行中の作業、インターネットドラフト、ドラフト - IETF-Cellar-Matroska-07,12 4月12日、<HTTPS：//datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-07>。
[MediaConch] MediaArea.net, "MediaConch", 2018, <https://mediaarea.net/MediaConch>.
[Mediaconch] MediaAra.net、 "MediaConch"、2018、<https://mediaarea.net/mediaconch>。
[NUT] Niedermayer, M., "NUT Open Container Format", December 2013, <https://ffmpeg.org/~michael/nut.txt>.
[ナット] Niedermayer、M。、「ナットオープンコンテナフォーマット」、2013年12月、<https：//ffmpeg.org/~michael/nut.txt>。
[Range-Encoding] Martin, G. N. N., "Range encoding: an algorithm for removing redundancy from a digitised message", Proceedings of the Conference on Video and Data Recording, Institution of Electronic and Radio Engineers, Hampshire, England, July 1979.
[Range-encoding] Martin、G. N. N. N. N.、「デジタル化されたメッセージからの冗長性を除去するためのアルゴリズム」、ビデオデータの記録会議、電子電子およびラジオエンジニア、ハンプシャー州、イギリス、1979年7月。
[REFIMPL] Niedermayer, M., "The reference FFV1 implementation / the FFV1 codec in FFmpeg", <https://ffmpeg.org/doxygen/trunk/ffv1_8h.html>.
[Refimpl] Niedermayer、M.、FFMPEGのFFV1の実装/ FFV1コーデック "、<https：//ffmpeg.org/doxygen/trunk/ffv1_8h.html>。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <https://www.rfc-editor.org/info/rfc6716>.
[RFC6716] Valin、JM、VOS、K.、およびT.Treiberry、「Opus Audio Codecの定義」、RFC 6716、DOI 10.17487 / RFC6716、2012年9月、<https：//www.rfc-editor.org/ info / rfc6716>。
[Valgrind] Valgrind Developers, "Valgrind website", <https://valgrind.org/>.
[Valgrind] Valgrind開発者、「Valgrind Webサイト」、<https：//valgrind.org/>。
[YCbCr] Wikipedia, "YCbCr", 25 May 2021, <https://en.wikipedia.org/w/ index.php?title=YCbCr&oldid=1025097882>.
[YCBCR]ウィキペディア、「YCBCR」、2021年5月25日、<https：//en.wikipedia.org/w/ index.php？title = YCBCR＆Oldid = 1025097882>。
This appendix is informative.
この付録は有益です。
The FFV1 bitstream is parsable in two ways: in sequential order as described in this document or with the pre-analysis of the footer of each Slice. Each Slice footer contains a "slice_size" field so the boundary of each Slice is computable without having to parse the Slice content. That allows multithreading as well as independence of Slice content (a bitstream error in a Slice header or Slice content has no impact on the decoding of the other Slices).
FFV1ビットストリームは、この文書に記載されているような順序で、または各スライスのフッターの事前分析を行っている2つの方法で解析可能です。各スライスフッタは「スライス」フィールドを含み、各スライスの境界はスライスコンテンツを解析する必要なしに計算可能である。これにより、マルチスレッドとスライスコンテンツの独立性を可能にします（スライスヘッダーまたはスライスコンテンツ内のビットストリームエラーは、他のスライスの復号に影響を与えません）。
After having checked the "keyframe" field, a decoder should parse "slice_size" fields, from "slice_size" of the last Slice at the end of the "Frame" up to "slice_size" of the first Slice at the beginning of the "Frame" before parsing Slices, in order to have Slice boundaries. A decoder may fall back on sequential order e.g., in case of a corrupted "Frame" (e.g., frame size unknown or "slice_size" of Slices not coherent) or if there is no possibility of seeking into the stream.
「キーフレーム」フィールドをチェックした後、デコーダは、「フレーム」の最後のスライスの「slice_size」から「フレーム」の終わりに「SLICE_SIZE」から「SLICE_SIZE」から解析する必要があります。スライスを解析する前にスライス境界を持つために。デコーダは、破損した「フレーム」の場合（例えば、コヒーレントではないフレームサイズ不明または「スライス」」の場合、またはストリームに求める可能性がない場合には、順次順序で立ち上げてもよい。
Appendix B. Future Handling of Some Streams Created by Nonconforming Encoders
付録B.不適合エンコーダによって作成されたいくつかのストリームの将来の処理
This appendix is informative.
この付録は有益です。
Some bitstreams were found with 40 extra bits corresponding to "error_status" and "slice_crc_parity" in the "reserved" bits of "Slice". Any revision of this specification should avoid adding 40 bits of content after "SliceContent" if "version == 0" or "version == 1", otherwise a decoder conforming to the revised specification could not distinguish between a revised bitstream and such buggy bitstream in the wild.
「スライス」の「Reserved」ビットの「error_status」と「slice_crc_parity」に対応する40の追加ビットが見つかりました。「バージョン== 0」または「version == 1」の場合、この仕様の改訂は40ビットのコンテンツを追加しないでください。そうしないと、改訂された仕様に準拠したデコーダが改訂されたビットストリームとそのようなバグのビットストリームを区別できませんでした。野生で。
This appendix provides references to a few notable implementations of FFV1.
この付録では、FFv1のいくつかの注目すべき実装への参照を提供します。
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.
このリファレンス実装[Refimpl]には、特別に細工されたパケットまたはビデオセグメントがCPU負荷の大幅な増加を引き起こす可能性がある既知のバッファオーバーフローまたはケースが含まれていません。
The reference implementation [REFIMPL] was validated in the following conditions:
参照実装[refimpl]は、次の条件で検証されました。
* 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.
* FFV1ではないデコーダのランダムパケットを送信します。
In all of the conditions above, the decoder and encoder was run inside the Valgrind memory debugger [Valgrind] as well as the Clang AddressSanitizer [AddressSanitizer], which tracks 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.
上記のすべての条件では、デコーダとエンコーダは、バルグランドメモリデバッガ[valgrind]とClang AddressSanitizer [AddentsAnitizer]の内部で実行されていました。これは、不可能なメモリ領域への読み書きと未初期化メモリの使用を追跡します。テストされた条件のいずれにも報告されていませんでした。
An FFV1 decoder [FFV1GO] was written in Go by Derek Buitenhuis during the work to develop this document.
この文書を開発するために、仕事中にDerek BuitenhuisによってFFV1デコーダ[FFV1GO]が書かれました。
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 draft versions of this document. These issues are addressed by Section 3.3.1, Section 3.7.2.1, and Appendix B.
MediaConchプロジェクトの開発者[Mediaconch]は、FFV1ビットストリームを検証するためにそのプロジェクトの一部として独立したFFV1デコーダを作成しました。この作業により、この文書の既存のFFV1実装とドラフトバージョンの間の3つの矛盾が発見されました。これらの問題はセクション3.3.1、セクション3.7.2.1、および付録Bによって対処されています。
Authors' Addresses
著者の住所
Michael Niedermayer
Michael Niedermayer
Email: michael@niedermayer.cc
Dave Rice
デイブライト
Email: dave@dericed.com
Jérôme Martinez
JérômeMartinez
Email: jerome@mediaarea.net