DataStorageInAviSynth
Part 1: 実際のメモリ格納 †
警告: 技術論です。 大半のユーザーは、Part2を読む（そして理解する）だけでかまいません。
AviSynthにおいて、我々は、ビデオデータのピクセルを処理します。これらは、データ配列の形式でメモリの中に格納されます。他のところ（AviSynthFAQなど）で記されているように、v1.0x/2.0xには、RGBとYUY2という、2つの異なる色空間があり、さらにv2.5では、3つ目の色空間としてYV12が追加されています。v2.6では、次のカラーフォーマットが追加されます: Y8, YV411, YV16 and YV24。これらの色空間は、異なる方法でデータを格納します。
Interleaved formats †
RGB（RGB24としても知られる）: すべてのピクセルは、3バイトのデータに関連付けられます: 1つは赤（R）、1つは緑（G）、そして、もう1つは青（B）。それらのデータは、RGBRGBRGBRGBというように、メモリの中にインターリーブ（ミックス）されます。データは、ワードが4バイトの時にもっとも容易に読み込まれるため、ほとんどの関数は、3ワードを1列で読み込むことができるように、実際には、4ピクセルを同時に処理します。通常、メモリはアラインされて（aligned）*1割り当てられます。つまり、それは、4バイトのワードにメモリを割り当てるということです。3から4への関係（the 3 to 4 relation）はマップ（map）するのが容易ではないため、RGB24は非常に扱うのが難しく、一般には推奨されません。
RGBA（RGB32としても知られる）: これは、4つ目のカラーチャンネルが追加された、RGBの拡張版です。このチャンネルは、アルファチャンネルと呼ばれ、ピクセルにおける透過度を定義します。アルファチャンネルがどのように使われるかの説明は、MaskとLayerを見てください。しかし一般には、フィルタがアルファを正しく処理することを当てにすべきではありません。いくつかのケースにおいて、フィルタは、このチャンネルにゴミを作り出しさえするでしょうから。
またRGBAは、1ピクセルあたり4バイトを要求するため、これを大変容易にします。したがって、1ワード毎のメモリアクセスは、正確に1ピクセルに相当するでしょう。事実、RGBが使われるのは、RGBを返すソースを持っているか、明示的に（ConvertToRGB24を）使う場合に限られるでしょう。ConvertToRGBは、デフォルトでRGBを作り出します。これは、RGBデータに関しては、推奨されるフォーマットです。
YUY2: この色空間では、一対のピクセルが、それぞれ色データを共有していて、データはYUYV|YUYV|YUYV|YUYVのようにインターリーブされて（差し挟まれて）います。1ワードのメモリアクセスは、2ピクセル分のすべてのデータを取得します。ピクセルのペアは、決して分割されるべきではありません。ほとんどすべての関数は、YUY2において、すべてのワードを読み込んで処理すると仮定するため、これ（ペアのピクセルを分割すること）は奇妙な人工物（artifacts）を作り出しかねないのです。たとえ、それらの関数が実行される時に正しい幅を返したとしても、おそらく関数は、有効なピクセルを処理する時に、無効なデータを使ってしまうでしょう。
Planar formats †
さあ、本当の楽しみが始まります。これは、PlanarImageFormatなのです。これは、データがインターリーブされておらず、各色チャンネルに独立して格納されているということを意味します。フィルタ作者にとって、このことは、シンプルな関数を書くことができることを意味します。その関数は、（いつもそうではないが）演算がチャンネルごとに独立していると仮定して、各色チャンネルに1回ずつ、計3回呼び出されます。さらに、色と輝度の両チャンネルをアラインして（aligned）使用することは、メモリアクセスを容易にするでしょう。
Y8: このカラーフォーマットは、グレースケールです。すなわち、色を含みません。planarでもinterleavedでもある、唯一のフォーマットです。
YV12: 4つのピクセルが、色データを共有します。これら4つのピクセルは、2x2のブロック、すなわち、同じフィールドの隣接したラインの2ペアです。フィールド自体はインターリーブされているので、フィールドベースのビデオでは、ライン1と3が色データを共有することになります。ライン2と4も同様に共有します。もっとも、フレームベースのビデオは、色の共有に関して、より直観的な方法を取ります。ライン1と2、ライン3と4が、それぞれ色データを共有します。また、奇妙な人工物（artifacts）を作り出しかねないため、2x2のブロックは、決して分割されるべきではありません。
YV411: 4つのピクセルが、色データを共有します。これらの4つのピクセルは、1x4のブロックです。すなわち、4つの部分から成ります。奇妙な人工物（artifacts）を作り出しかねないため、1x4のブロックは、決して分割されるべきではありません。
YV16: この色空間では、それぞれ一対のピクセルが、色データを共有します。奇妙な人工物（artifacts）を作り出しかねないため、そのペアは、決して分割されるべきではありません。それは、YUY2のplanarバージョンです。
YV24: このカラーフォーマットは、フルカラーを持ちます。すなわち、（ちょうどRGBやRGBAのように）各ピクセルが、独自の色を持っています。
Part 2: これは、ユーザーの私に影響しますか？ †
- あなたが色を共有している単位を分割しない限り、ラインの最後におけるメモリの読み込みに関する問題に気をつけるかどうかは、フィルタ作者次第です。
- インターレース（フィールドベース）のビデオは、高さが2の倍数であることを必要とします。
- 異なるカラーフォーマットでは、Moduloが必要となります。
- RGB(A)
- 幅 1の倍数 （制限なし）
- 高さ 1の倍数 （制限なし） プログレッシブの場合
- 高さ 2の倍数 （偶数値） インターレースの場合
- YUY2
- 幅 2の倍数 （偶数値）
- 高さ 1の倍数 （制限なし） プログレッシブの場合
- 高さ 2の倍数 （偶数値） インターレースの場合
- Y8
- 幅 1の倍数 （制限なし）
- 高さ 1の倍数 （制限なし） プログレッシブの場合
- 高さ 2の倍数 インターレースの場合
- YV411
- 幅 4の倍数
- 高さ 1の倍数 （制限なし） プログレッシブの場合
- 高さ 1の倍数 （制限なし） インターレースの場合
- YV12
- 幅 2の倍数 （偶数値）
- 高さ 2の倍数 （偶数値） プログレッシブの場合
- 高さ 4の倍数 インターレースの場合
- YV16
- 幅 2の倍数 （偶数値）
- 高さ 1の倍数 （制限なし） プログレッシブの場合
- 高さ 2の倍数 （偶数値） インターレースの場合
- YV24
- 幅 2の倍数 （制限なし）
- 高さ 1の倍数 （制限なし） プログレッシブの場合
- 高さ 2の倍数 （偶数値） インターレースの場合
- RGB(A)
- 320x240のプログレッシブ・ソースに関する、有効なCropの例
- RGB(A)
- Crop(1,7,-32,-19)
- Crop(2,4,300,196)
- YUY2
- Crop(2,7,-32,-19)
- Crop(2,4,300,196)
- YV12
- Crop(2,8,-32,-18)
- Crop(2,4,300,196)
- RGB(A)
- 最終的に出力されるビデオは、ほかの制限を受けるかもしれないということに注意してください。ほとんどのMPEG-nの実装は、あらゆる解像度に関して、16の倍数であることを要求する、など。
さらなる情報 †
ColorSpacesについて、もっと多くのことを参照してください。
WorkingWithImagesの一般的なイントロダクションを参照してください。
このページは、[Doom9フォーラムにおけるこのスレッド]の編集された要約です。
註: このページは、http://www.avisynth.nl/DataStorageInAviSynthの日本語訳です。
