名 称 | 縦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方式(マスキングビスタ的なもの)を使う。 |
名 称 | 種別 | 対応規格 | 根拠 |
---|---|---|---|
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には見当たらない。 |
素 材解像度 | 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 | |
大半とは言いませんが、多くのワイドスクリーンDVDは、厳密には16:9ではなく、1.85:1 か 2.35:1 (シネスコープ)。これは、映像の中にクロップすべき黒帯が含まれていると言う事になります。MEncoder Documents/DVD映像を高画質なMPEG-4 ("DivX")にする方法よ り。従って16:9とは各種ビスタやシネスコを包含する汎用比と思われる。
規 格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt (maximum frame size * 8)以下でなければならない事を除けば規格には無い。もしもAVCのレベルにフレームの縦横は720x480といった規定が無く、制限は1フレームあたりのピクセル数だけで、かつ、ピクセルに縦横比情報を持 たせる事ができるのなら、ヨーロッパ・ビスタだろうがアメリカン・ビスタだろうがマスキングビスタだろうがシネスコだろうがそれ以外の変形素材だろうが、 オリジナルのフィルムから起こす場合に限っては、もうちょっとだけ、素材に忠実な解像度で作る事ができそうだ。それなら、MPEG-4 ASPの"PAR"の名称を変える必要性が納得できる。
-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 |
※何れもffmpegX0.0.9x同梱版より新しい。
$ /Users/USERNAME/Desktop/EvalVid/MP4Box -version
MP4Box - GPAC version 0.4.3-DEV
GPAC Copyright: (c) Jean Le Feuvre 2000-2005
(c) ENST 2005-200X
$ /Users/USERNAME/Desktop/EvalVid/MP4Box -h generalMEncoder -x264encoptsに無い--sarをmux時に後付けできそう。 いや、実は720x480のままでスケーリングしなけりゃMEncoderが自動でx264 [info]: using SAR=8/9っ てしてくれ るんだけども。
General Options:
//
-par tkID=PAR: sets visual track pixel aspect ratio (PAR=N:D or "none")
===MENCODER_PASS1===
/usr/local/bin/mencoder CM_pan720x480.mpeg -nosound -ovc x264 -x264encopts てきとう -vf yadif=2,pp=l5,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o /dev/null
===MENCODER_PASS2===
/usr/local/bin/mencoder CM_pan720x480.mpeg -nosound -ovc x264 -x264encopts てきとう -vf yadif=2,pp=l5,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o CM_pan720x480.264
===FFMPEG_AUDIO===
/usr/local/bin/ffmpeg -i CM_pan720x480.264 -i CM_pan720x480.mpeg -y -vn -f mp4 -acodec aac -ar 48000 -ac 2 -ab 64 -map 1.1:0.0 CM_pan720x480.aac.mp4
===MP4BOX_--mux===
/Users/USERNAME/Desktop/EvalVid/mp4box -fps 29.970030 -par 1=8:9 -add CM_pan720x480.264 -add CM_pan720x480.aac.mp4 -new CM_pan720x480.mp4
===MP4BOX_--info===
/Users/USERNAME/Desktop/EvalVid/mp4box -info CM_pan720x480.mp4
* Movie Info *
Timescale 600 - Duration 00:00:29.795
Fragmented File no - 2 track(s)
File Brand isom - version 1
Created: GMT Sun Jan 28 04:53:28 2007
File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD
Track # 1 Info - TrackID 1 - TimeScale 30000 - Duration 00:00:29.796
Media Info: Language "Undetermined" - Type "vide" - Sub Type "avc1" - 893 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 720 x 480 - Profile High @ Level 5.1
NAL Unit length bits: 32
Pixel Aspect Ratio 8:9 - Indicated track size 640 x 480
Self-synchronized
Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:00:29.653
Media Info: Language "Undetermined" - Type "soun" - Sub Type "mp4a" - 1390 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1
1 | 2 | 3 |
---|---|---|
![]() |
![]() |
![]() |
VLC 0.8.6a 720x540で表示。横幅に合わせて縦を拡大している。 720x576のPALに合わせた挙動なのだと思う。 素材のMPEG-2もこうなる。 |
QuickTime Player Pro 7.1.3 + avc1 Decorder 0.6.0 720x480そのままで表示。 これは「国際標準規格」準 拠の動作では無い。 素材のMPEG -2は640x480で表示する。 |
Lanczos4使用、640x480で作成したもの。 640x480で表示。 |
QTの林檎+Jで"ビジュアル設定"を見ると、"表示サイズ"は720x480のまま。なんだか良く解らない。これSARと違うの か。とりあえずおいといて、、、
主 観的な「画質」は640x480(上記3のファイル)のほうが良かった。
bitrateはどちらも同じなのでその分の差はあるが、インタレ解除とデノイズは同一。
VLCで比べた感想としては、迫力は表示面積の大きい720x480の方が上なものの、奇麗さでは640x480の方が良いと感じた。720x480
は地味に文字がボケる。ボケはコマによって変動し、時に目にうざい。文字以外の部分でも同様の現象がおきているようで、それで全体的になんと
なく画質が悪いと感じたのだと思う。全画面表示では38,400画
素の差がある720x480の方が有利かと思ったが、面白い事にさらに差が目立った。
720x480維持のほうが素材に"忠実"なのだが、実感としてはハテナな感じ。そういえばDoom9氏も640x480を推奨して いたような記憶が、、、。
VUIを使うと言う事は、再生時にリアルタイム拡縮が入ると言う事だ。
もちろん家電プレイヤはハードウェアでリアルタイム拡縮をやるわけだし、Winでも正しくグラボを設定すればできるようだ。これが--sar指定付き
720(or
704)x480の人が多い理由だと思う。その方が素材に"忠実"だし、たぶんそれで問題の無い画質になるのだろう。インタレ保持で作るにも便利だし。
だ
がMacで同じ事ができるとは期待し難い。モデルに拠ってはWinに遜色の無いグラボが付いてはいるものの(おいらのはショボイ)、Apple
の垂直統合ビジネスモデルでは、ドライバもファームウェアも基本的には門外不出だ。最悪の場合、TerraSoftがYDLの開発でやってたように、モデ
ル毎に搭載ハードウェアにリバースエンジニアリングかけ
る事になりかねん。
もちろん、グラボの差を吸収してくれるCoreVideo APIをVLCやQuickTime Player
Proがバリバリにを使い倒すのを待つという道もあるが、何年もかかる。
エンコ時に手間かけて、スクエア・ピクセルで4:3や16:9に直してしまう方が良いように思った。