- 映画界の呼称
- DARとPARとSAR
- 一般的な SAR:
- なぜx264にDARが無いのか。
- AVIとQuickTimeとMPEG規格
映 画界の呼称
スクリーン・サイズの種類と縦横比（アスペクト比）：りおなのVIVA!WIDESCREENよ り作成。
| 名 称 |
縦x横 |
備考 |
| スタンダード |
1×1.37 |
35mm写真フィルムとほぼ同じ。TVもこれに倣った。 |
| 不詳 |
1×1.2 |
ほぼ正方形。トーキーの音声をフィルム上に収録するため、ちょっ と映像を削った。不評で消えた。 |
| ヨーロッパ・ビスタ |
1×1.66 |
フランス映画に多い。 |
| アメリカン・ビスタ |
1×1.85 |
シネマスコープを除くほとんどのアメリカ映画。日本、イギリス、 イタリア映画にも多い。 |
| マスキングビスタ |
1×1.66〜1×1.85 |
35mm（スタンダード・サイズ）フィルムでの撮影または上映時に上下にマスクをかける。
純 正のビスタビジョンと区別するため“ビスタ サイズ”と言う。
1960年代のフィルムの品質向上で実用化。
1980年代のビデオ普及に より、撮影はスタンダード、上映はマスキングビスタが主流となる。 |
| シネマスコープ |
1×2.35 |
基準は1×2.35だが、通常は 1×2以上のアスペクト比を「スコープ・サイズ」と呼ぶ。
撮影は専用のアナモルフィック・レンズか、スーパー 35方式（マスキングビスタ的なもの）を使う。 |
4: 3なら1.33だし、16:9は1.78だ。勘定が合わない。「なんですかこれわ？」という数字だらけ。恐るべし映画百年の歴史。
これら多彩な縦横比をどうやってデジタルの世界に持って来るか。
DVD（と言うかMPEG-2のMain Profile @ Main Level）の720x480はアスペクト比1.5。表の中のどれにも合わない。
なぜこれを採用し たかは知らないが、720x480の画素数は僅か34万5,600画素。
恐らくは、規格制定当時、ご家庭で買える範囲のお値 段で再生機を作るには35万画素を30fpsで動かす程度が限界と予想された、という事だろう。画素数とfpsがCPUパ ワーとバッファメモリ搭載量に直結するからだ（MPEG規格は半導体の価格動向予測も考慮して決める）。
だから、まず画素数とfps。次に、どのアスペクト比の映画でも、720x480を有効に使いきる、仕組み。
例えばデータ上の解像度（サンプル数）は720x480 で固定しておいて、表示上のアスペクトは別に指定してやる。など。これならどのアスペクト比の映画でも、720x480を無駄なく使いきれる。画質最優先 ならどのアスペクトに対しても個別に最適な縦横のピクセル数を決めるべきだが、家庭用DVDプレイヤでそこまでカヴァーするのは無謀だったという事だろう。
DAR とPARとSAR
| 名 称 |
種別 |
対応規格 |
根拠 |
DAR
Display Aspect Ratio
ディスプレイ・アスペクト・レシオ |
画面表示のアスペクト比。 |
MPEG-1/2/4 |
MEncoder
- mpegoptsのvaspect=<1 | 4/3 | 16/9 | 221/100>
-xvidencopts のaspect=<x/y | f (float value)> |
PAR
Pixel Aspect Ratio
ピクセル・アスペクト・レシオ |
ピクセルのアスペクト比。 |
MPEG-4 ASP? |
MEncoder
-xvidencoptsのpar=<mode>
DAR = PAR * (width/height)。 |
SAR
Sample Aspect Ratio
サンプル・アスペクト・レシオ |
ピクセルのアスペクト比。 |
MPEG-4 AVC |
x264cli
Input/Output:の --sar
※ 規格上はVideo Usability Info (Annex E):だが、
ここではcore:54 svn-611M --longhelpに従った。
MEncoder -x264encoptsには見当たらない。 |
アスペクト比はスクリーン（画面全体）で指定するものと、ピクセル単位で指定するものの２種類がある。PARとSARは、規格上の呼び方が違うだけで同じ ものだろう。手許では実際に-xvidencoptsの
par=<mode>を 使った事は無いが、modeには
ntsc169 や
pal43 などのプリセットを入れる。ここに
ext と入れると、
par_width=<1-255> や
par_height=<1-255> で独自の縦横比を指定する事ができるようだ。恐らく は、これがSAR。
一般的な SAR:
x264cli のSARは「8:9」のような書式で指定するようだ。-xvidencoptsの書式で書くと、par_width:par_height に相当するだろう。
DAR= (par_width / par_height) * (width/height)
Encoding H.264 using the x264 Command Line Interface（Zero 1氏）の一般的な SAR表から作成。
| 素 材解像度 |
DAR |
SAR（PAR_W : PAR_H） |
一 般名
（縦横比など） |
少数表記
（高さを1とした時の横幅） |
PAR_W |
PAR_H |
| 720x480 (NTSC) |
4:3 |
1.33 |
8 |
9 |
| 16:9 |
1.77(*1) |
32 |
27 |
| アメリカン・ビスタ(*2) |
1.85 |
100 |
81 |
| シネスコ |
2.35 |
69 |
44 |
| 704x480 (NTSC Crop) |
4:3 |
1.33 |
10 |
11 |
| 16:9 |
1.77(*1) |
40 |
33 |
| アメリカン・ビスタ(*2) |
1.85 |
125 |
99 |
| シネスコ |
2.35 |
85 |
53 |
| 720x576 (PAL) |
4:3 |
1.33 |
16 |
15 |
| 16:9 |
1.77(*1) |
64 |
45 |
| アメリカン・ビスタ(*2) |
1.85 |
40 |
27 |
| シネスコ |
2.35 |
32 |
17 |
| 704x576 (PAL Crop) |
4:3 |
1.33 |
12 |
11 |
| 16:9 |
1.77(*1) |
16 |
11 |
| アメリカン・ビスタ(*2) |
1.85 |
50 |
33 |
| シネスコ |
2.35 |
102 |
53 |
なお、
『改訂版 H.264/AVC 教科書』 を見ると、VUI（ビデオ表示パラメータ、309ページ）の項に、aspect_ratio_idc、sar_width、sar_height、という ものがあった。aspect_ratio_idcはプリセット。0は定義無し、1は1:1、2は12:11、、、という具合。13まである。14〜254 はreserved（将来の拡張用）。ここが255だったら、
sar_width、sar_heightの値からSARを計算する。 とある。
上の表の「一般的なSAR」は16通りある事から、x264cliの--sarオプションは、sar_width、 sar_heightを入力するものと思われる。
なぜx264にDARが無いの か。
DARがありゃ便利なのにと思うのだが、どうもH.264/AVC規格にも無いらしい。例え ば、
H.264/AVC規格概要：レベルにある以下の記述。
規 格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt （maximum frame size * 8）以下でなければならない事を除けば規格には無い。
もしもAVCのレベルにフレームの縦横は720x480といった規定が無く、制限は1フレームあたりのピクセル数だけで、かつ、ピクセルに縦横比情報を持 たせる事ができるのなら、ヨーロッパ・ビスタだろうがアメリカン・ビスタだろうがマスキングビスタだろうがシネスコだろうがそれ以外の変形素材だろうが、 オリジナルのフィルムから起こす場合に限っては、もうちょっとだけ、素材に忠実な解像度で作る事ができそうだ。それなら、MPEG-4 ASPの"PAR"の名称を変える必要性が納得できる。
あと、
4kシネマ（4,096×2,160ドット）とか2kシネマ（2,048×1,080ドット）とかも睨んでるのかもしれないなと思った。
AVIと QuickTimeとMPEG規格
MEncoderは
AVIヘッダにアスペクトを書き込む事 ができる。しかしそれをちゃんと解釈できるのはMPlayerくらいらしい。オプションにある通り、rawvideo.xvidにDARやPARを埋め込 む事もできる。しかしこれも、AVIコンテナではちゃんと解釈できるのはMPlayerくらいらしい。DARやPARは.MP4コンテナが安全だろう。
一方、QuickTimeはコンテナにはアスペクトヘッダを埋め込め、正しい解釈もできる筈だが、インフラ全般に渡って映像データと付加情報は分離すべ し、という一貫した思想がある（オブ ジェクト指向）。これはかなり徹底したもので「アスペクト情報を持った映像ストリーム」に対応困難らしい。結果的に.MP4であっても、SAR指定の入っ たH.264サ ポートをQuickTimeコンポーネントとして実装するのは難しいようだ（
考察：SARとQT（My cometG3））。
Appleが国際標準規格の推進をアピールするのは自由だが、
Apple - h.264 だけが H.264/AVCであるかのような印象操作は 不愉快だ。
MPEG （Motion Pictures Expert Group）規格はその名の通り、動画に関する規格だ。.MP4はAppleの.movベース（Appleが唯一MPEGに提供しているパテント）とはい え、発想は異なる。上位団体はISO（International Organization for Standardization、国際標準化機構）と仰々しいがなんのことは無い。
JISだJIS。「2Bの鉛筆」とか「単 ３の乾電池」とか「M３のボルト」などと本質的な違いは無い。ISO-MPEGの仕事は
「産 業界における汎用的な実用性を持った規格を定める事」だ。ひらたく言えば妥協がお仕事。できるだけ高いレベルで。
手許ではSARを使わずにスケーリングしてしまうが、過去に720x480のMPEG-2PS（TVキャプチャ）の黒帯を、16:9にするべくcropし て、スケーリングを間違えて640x480でエンコードした事がある（
ソルティレイ#01 オーロラの降る街）。
-vf pullup,softskip,crop=702:352:8:64,scale=640:480,hqdn3d=2:1:4,pp=l5,harddup
記録が残っていないがSARもPARも滅茶苦茶なハズだ。
 |
 |
 |
| QT Player + avcdecoder 0.5.1 |
VLC 0.8.6 |
MPlayer OSX 1.0 pre 8 |
これを正しいアスペクトで表示できる方が狂っているのだが、なぜかこうなった。
QT Playerは素直に640x480。VLCとMPlayer OSX 1.0は、縦480を軸に、横幅を852に拡大している。当時（2005/10月）はMain profileで作っていたので、素のQT7（Apple-H.264）でもこうだった。偶然に正しいSARにでもなったのだろうか。
ところでこのファイルは「こんなこともあろうかと」取って置いたというわけでは無く、何気なくme=ext、me_range=64を試して122時間 34分49秒かかった後に、やり直す気力が残ってなかっただけです^^;。
余談：
なにげなくISOのスペルを 辞書でひいたらこういうものがあった。
ISO standard cup of tea : ISOで決められた「標準紅茶」。
ISO 0（砂糖を入れないミルク紅茶）。
ISO 2（砂糖を2スプーン入れたミルク紅茶）。
冗談かと思ったら、
本物でした。
ISOで規格書も売っている。紅茶好きの間では有名な話らしく「ISO 3103:1980」で検索するとちょっと大変な事になっている。イギリス人め！安倍政権はISO国際標準すし規格の策定に全力を注ぐべきだ。
△ETOP | ▲PTOP
None