| 名 称 | 縦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 |
MEncoder の場合、SARは自動計算のため調整できません。手許の素材は地上波アナログTV録画のMPEG-2（4:3）のみなのですが、どうやらMPEG-2の DAR情報を元にしているようです。映画などで上下の黒帯をゲンミツにクロップアウトしたり、スケーリングを行う場合は便利です。例えば：
5と6で使った640:352は厳密には16:9ではありません。縦横とも16の倍数でなければならないというMPEG系圧縮のキホン原則に従ったものですが、x264では守らなくても目で見て解る違いは無いという人が多いようです。
7と8は意味の無いリサイズですが、VLC/MPlayerともに16:9で再生します。「理想のSAR」的にゲンミツに測れば歪んでいるかもしれませんが、違和感は感じませんでした。
なお、横幅720と704で同じSARを使っているケースは、ブラウン管用の無効領域の扱いが絡んでいると思われます。2chでテンプレとなっているSAR表同様に、横幅720と704の値が揃っていますが、適用値自体は異なっています。
SAR は Sample Aspect Ratio の略。これを指定するとアナモルフィックビデオ～すなわち、サンプル解像度に関わらず正しいアスペクトレシオ（＊映像の縦横比＊）に引き延ばして再生できるようになる。SARはアスペクトレシオを指定するものではなく、引き延ばす係数の指定である事に注意。
例えばSAR 32:27 は720x480映像をアスペクトレシオ 16:9 で再生するためのものだ。32/27=1.185185... となるので、1.185185...x720 = 853.3くらい。従って再生は853x480となる。
アナモルフィック映像を扱った経験者は多いと思う。NTSC-DVDでは一般的に、ワイドスクリーン映像はNTSC 4:3の 720x480 に押しつぶしてある。
アナモルフィック素材を扱う方法にはいろいろなものがある。
１）640x360 にリサイズ（そして 16 の倍数である 352 にクロップ）。
２）852x480 にリサイズ（同じく 848 にクロップ）。
前者では大量のディテイルを失う事になる。後者では拡大による汚れが出る。アナモルフィックでは 720x480 または 704x480 でエンコードして、再生時に概ね 853x480 に引き延ばすタグをつけておく事ができる（playerによって異なる）。再生サイズは 853x480 でも、実際のデータ量は 720x480 または 704x480 だ。拡大するわけでは無いのでbitの節約になり、縮小では無いのでディテイルは維持できる。再生負荷もエンコード前に拡大するよりは低い。と言うように SARは理論上は良いものだが、AMV（＊アニメ・ミュージック・ビデオ、原文はこれを想定しているが、概ね一般論として通じる＊）を間違ったアスペクトレシオで編集すると、変な形にリサイズされてしまう事を忘れないように。ただし、編集ソフトにそのへんの面倒を見てくれるモードがあれば別です。
一般的な SAR：（＊下表の内容はweb上の他の情報と矛盾します。『疑問点』参照＊）
| Source Resolution | Display Aspect Ratio |
Sample Aspect Ratio | 備考 |
|---|---|---|---|
| 720x480 (NTSC) | 1.33（4:3） | 8:9 | スタンダード |
| 1.77（16:9） | 32:27 | ヨーロッパビスタ（1.66）とアメリカンビスタ（1.85）の中間比 | |
| 1.85 | 100:81 | アメリカンビスタ | |
| 2.35 | 69:44 | シネマスコープ | |
| 704x480 (NTSC Crop) | 1.33 | 10:11 | |
| 1.77 | 40:33 | ||
| 1.85 | 125:99 | ||
| 2.35 | 85:53 | ||
| 720x576 (PAL) | 1.33（4:3） | 16:15 | |
| 1.77（16:9） | 64:45 | ||
| 1.85 | 40:27 | ||
| 2.35 | 32:17 | ||
| 704x576 (PAL Crop) | 1.33（4:3） | 12:11 | |
| 1.77（16:9） | 16:11 | ||
| 1.85 | 50:33 | ||
| 2.35 | 102:53 |
例えば解像度が 704x480（720x480 NTSC の黒帯をクロップしたもの）で、アスペクトが 16:9 の映像なら、 --sar 40:33。
SARは MP4box でも指定できます（推奨）。MP4box ガイドも参照して下さい。
＊原文にMP4box ガイド未発見。
＊ageha MP4Boxの主要コマンド に
-par trackID=PAR というオプションがある。
--sar
Usage: --sar <numerator:denominator> (default=1:1) [1 - 255]
SAR
means Sample Aspect Ratio. Setting this allows anamorphic video to be
played back at the correct aspect ratio since the video is stretched on
playback. Note that SAR does not work by specifying the aspect ratio,
it works specifiying the factor to be stretched by. For example 32:27
is the SAR to make 720x480 video play back at 16:9 aspect ratio. This
is because 32/27=1.185185.... Therefore 1.185185...x720 = 853.3r. You
now have 853x480.
You will probably have encountered anamorphic
video before, it's widescreen material that is usually squashed into a
4:3 frame size for example 720x480 which is NTSC 4:3 for DVDs.
There are a number of ways you might have dealt with anamorphic material in the past, you might have resized to 640x360 (and cropped to 352 for mod16), or some people might have resized to 852x480 (848 for mod 16). With the first method you lose a lot of detail, the second wastes data because you are upsizing the image. Anamorphic allows you to encode it as 720x480 or 704x480 and set the tag for it to be stretched on playback. The result is a video that will be resized to approx 853x480 on playback (may depend on the player), but will only require the equivalent amount of data as a 720x480 or 704x480 encode. This way you save bits since you aren't encoding an upscaled image, and save quality because you aren't downscaling. The playback requirements are also lower than the upscaled encode. SAR is goon in theory, but editing AMVs at the wrong aspect ratio whilst bearing in mind that it will be resized may be tricky, unless your editing software has some sort of mode to help with this.
Here are some common SARs:
（表略）
If for instance I had a 704x480 video (720x480 NTSC after
cropping the
black bars) and is a 16:9 video, I would set --sar 40:33.
You may also set the SAR in MP4box (recommended). You can check out the
MP4box guide for muxing.
アスペクト比 part3 http://pc11.2ch.net/test/read.cgi/avi/1174473555/-100
32 ：孫極右：2007/03/23(金) 22:00:24
>>26
720x480(無効領域なし)の16:9 - 32:27
720x480(無効領域あり)の16:9 - 40:33
704x480(無効領域Crop)の16:9 - 40:33
720x480(無効領域なし)の4:3 - 8:9
720x480(無効領域あり)の4:3 - 10:11
704x480(無効領域Crop)の4:3 - 10:11
例 DAR(Display Aspect Ratio)を4:3、画素数が720*480の場合、
par_x = DAR_x * hight = 4 * 480 = 1920
par_y = DAR_y * width = 3 * 720 = 2160
1920:2160→8:9
(4 * 480):(3 * 352)=20:11
これは以下２点とも整合します。
引用文中の式では横幅720と704で数字が変わりますが、無効領域（乱暴に言うとブラウン管用のマージン）の扱いに注意が必要と思われます。無効領域の有無の見分け方は不詳。
原文の表は下記に従ったものと思われます。
＊x264のsvnソースコード内/doc/vui.txtより
SAR_x DAR_x * height
----- = --------------
SAR_y DAR_y * width
for example:
width x height = 704x576, DAR = 4:3 ==> SAR = 2304:2112 or 12:11
これに従う限り、横幅 720と704ではSARを変える必要があるのですが、これに続いて "素材がデジタル化されたアナログ信号の場合はこの式を使うな"。とも書いてあります。
Please note that if your material is a digitized analog signal, you shouldこのリンク先を読むとどうやらかなり広汎な、むしろ現在身の回りにあるほとんどの素材がこれに該当するようです。
not use this equation to calculate the SAR. Refer to the manual of your
digitizing equipment or this link instead.
A Quick Guide to Digital Video Resolution and Aspect Ratio Conversions
http://www.iki.fi/znark/video/conversion/
QuickTime7はH.264のsarを受け付けませんが、QTP/iTunesで再生できるアナモルフィック・エンコードは一応可能です。
アナモルフィック・エンコードとは、720x480 や 704x480 の素材をそのままのサンプルサイズでエンコードするものです。サンプルサイズとは輝度情報の数字。それが 720x480 個並んでいますよというほどの意味。実際の表示サイズは720x480でも 704x480 でもないのですが、世の中の MPEG-2 はほとんどこのサイズです。プレイヤは別途 4:3 や 16:9 などの DAR 情報を読み込んで、正しい縦横比に直して表示します。
H.264/AVC規格には、720x480 のような特定サイズ制限がありません。ぶっちゃけ DAR もないです。SAR（サンプル・アスペクト・レシオ）。輝度サンプルいっこいっこに縦横比を持たせるとゆう イッチャッタ 、あわわ、自由な仕様。サンプルサイズも縦横比も、規格上はかなりフレキシブルです。
ただし頭書の通り QuickTime は受け付けません。それでも一応、Mac でもアナモルフィックはできますよとゆーハナシ。手許の素材は MPEG-2 TVキャプチャ（CaptyTV）のみ、つまり 4:3 指定の付いた 720x480 なので細かい数値はケースバイケースだと思います。
例えば
-vf pullup,softskip,pp=l5,crop=704:480:8:0,hqdn3d=4:3:6,harddup
※MEncoderは自動で sar 値を書き込む。この素材は両サイドの黒帯をクロップアウトした。この場合のSARは
x264 [info]: using SAR=8/9と出た。この記事にある値のどれとも合わないが、最終的に見た感じでは問題無いようだ。
林檎+ i で情報表示すると下の方にこういう表示がある。
この「現在のサイズ」というものを QuickTime Player Pro で変更する。
ちなみにVLCとMPlayer (OSX) は4:3、きちんとした縦横比で表示する。
林檎+ j でプロパティを出し、ビデオトラックのタブ「ビジュアル設定」を下図のように変更。
※Bフレームを使っている場合は、一旦ビデオトラックを取り出して冒頭の白紙フレームを削除しておく。手許ではweight_b を使うので２フレーム。
このファイルはQTP（+ avc1Decorder）、iTunes、VLCともに受け付けた。
なお、QT系が 640x480で表示したのに対し、VLCは 704x528 で表示した。コンテナの「調整後のサイズ」ではなくビデオストリーム内の sar値を読んでいると思われる。規格上、どっちが正しい挙動なのかは不詳。
エンコード前の拡大は映像の汚れを生み、縮小はディテイルの損失を生むため、アナモルフィック・エンコードの方が素材に対して忠実、つまり高画質とされています。例えば：http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-quicktime-7.html#menc-feat-quicktime-7-constraints など。
『素材を極力弄るな』はエンコードのキホンですから、これが定石です。ただしこれは徹底的な画質追求をする際の固定条件であって、体感画質と一致するとは限りません。
１）現実に目にする画質はプレイヤの性能次第です。
720 (or702)x480は輝度情報の数字が720x480個並んでいますよという事で、正しい縦横比で表示するには縦か横を拡大 /縮小する必要があります。実用上、Mac OSXで SARを解釈できるプレイヤは VLC かMPlayer (OSX) くらいなのですが [*1]、これらオープンソース系は CoreVideo [*2] 対応がまだ厳しいです。
これはデコード終了後、画面に映像を出す段階で差がつくようです。右図→
上段は 横幅702でエンコードしたものを VLC と QuickTime PlayerPro で同サイズ表示したもの。下段は横幅640に縮小してからエンコードしたものです。スクショを jpg化していますが違いは見て取れると思います。
上段はヘルメット部分に画質差があります。この差は下段ではやや詰まっています。つまり、エンコード前に正しい縦横比に縮小 /拡大してしまった方がプレイヤのリアルタイムスケーリングに任せるよりキレイに見える、事もある、ということです。VLCの方は初期設定を弄ればなんとかなるかもしれません。ただし、この素材ではコマ単位で見比べなければそうそう目にとまるとは思いませんでした。
２）また当然ながら、ビットレートが同じなら縮小した方が数値画質は有利です。上下とも1024kbpsでやった結果は以下。
| No. | disc. | SSIM | PSNR（Y） | AVG QP（P） | SAR |
|---|---|---|---|---|---|
| 01 | 702x480 no scaling | 0.9519027 | 40.499 | 25.42 | 8/9 |
| 02 | 702x480 to 640x480 | 0.9537451 | 40.662 | 24.71 | 48/49 |
| - | diff | 0.0018424 | 0.163 | -0.71 | - |
サンプル解像度が異なるのに同じビットレートで画質や PSNR や SSIM を比べても意味が無いのですが、要求条件にファイルサイズを加える場合は効いてきます。SAR がどうだろうが QT系は無視して1/1で表示します。VLC / MPlayer (OSX)もそんなに悪く無い縦横比で表示します。どのみち表示サイズは 704x480 ではない、と考えるなら、事前にスケーリングしてしまう方が潰しが効くファイルになります。なお、アニメに 1024kbps与えて SSIM 0.95台ってのは酷いです。以前は悪くても0.977は出ていたのですが…。
最後にファナティックな事を言えば、もとよりサクヒンは4:3や16:9 [*3]で見られる事を意図しています。つまり忠実であるべきは素材のデータか、作り手の意思か。720x480のようなサンプリング解像度は作り手の意思というわけではありません。4:3には過剰、16:9には不適合な10年以上前の技術的妥協点ですから、特にそれに縛られる必要は無いと考える事もできます。
[*1]：QuickTime の構造上、avc1Decorder, Perianともに対応困難な模様です。
[*2]：グラフィックカードの機能を呼び出すOSのAPI。
[*3]：さらにファナティックにいえば16:9もアナログハイビジョンの都合です。16:9の映画は存在しません。
おおきく振りかぶって_15_先取点_070720~.mpeg ===MENCODER_PASS1=== $ mencoder おおきく振りかぶって_15_先取点_070720~.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=19:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:8x8dct:turbo=1 -passlogfile おおきく振りかぶって_15_先取点_070720~.264.log -vf pullup,softskip,pp=l5,crop=704:480:8:0,hqdn3d=4:3:6,harddup -vfm ffmpeg -sws 9 -ofps 24000/1001 -of rawvideo -o /dev/null x264 [info]: using SAR=8/9 x264 [info]: using cpu capabilities: Altivec x264 [info]: slice I:17 Avg QP:25.53 size: 24999 PSNR Mean Y:41.28 U:48.87 V:49.79 Avg:42.70 Global:41.47 x264 [info]: slice P:747 Avg QP:27.46 size: 7770 PSNR Mean Y:38.60 U:46.93 V:48.02 Avg:40.08 Global:39.65 x264 [info]: slice B:666 Avg QP:28.94 size: 1155 PSNR Mean Y:38.37 U:47.12 V:48.22 Avg:39.87 Global:39.46 x264 [info]: mb I I16..4: 16.8% 45.9% 37.3% x264 [info]: mb P I16..4: 9.8% 8.0% 2.6% P16..4: 61.7% 7.6% 2.3% 0.0% 0.0% skip: 7.9% x264 [info]: mb B I16..4: 0.1% 0.2% 0.0% B16..8: 11.8% 0.0% 0.0% direct:13.5% skip:74.3% x264 [info]: final ratefactor: 23.81 x264 [info]: 8x8 transform intra:40.1% inter:33.7% x264 [info]: direct mvs spatial:94.3% temporal:5.7% x264 [info]: SSIM Mean Y:0.9496788 x264 [info]: PSNR Mean Y:38.524 U:47.046 V:48.138 Avg:40.017 Global:39.577 kb/s:938.68 Video stream: 938.848 kbit/s (117355 B/s) size: 6999453 bytes 59.643 secs 1789 frames SEC ; 109 TIME; 0:1.49 ===MENCODER_PASS2=== $ mencoder おおきく振りかぶって_15_先取点_070720~.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=19:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=p8x8,b8x8,i8x8,i4x4:trellis=2:brdo:bime -passlogfile おおきく振りかぶって_15_先取点_070720~.264.log -vf pullup,softskip,pp=l5,crop=704:480:8:0,hqdn3d=4:3:6,harddup -vfm ffmpeg -sws 9 -ofps 24000/1001 -of rawvideo -o おおきく振りかぶって_15_先取点_070720~.264 x264 [info]: using SAR=8/9 x264 [info]: using cpu capabilities: Altivec x264 [info]: slice I:17 Avg QP:23.53 size: 27251 PSNR Mean Y:43.15 U:49.45 V:50.37 Avg:44.46 Global:43.85 x264 [info]: slice P:747 Avg QP:25.42 size: 8479 PSNR Mean Y:39.55 U:47.36 V:48.49 Avg:41.00 Global:40.78 x264 [info]: slice B:666 Avg QP:27.00 size: 1234 PSNR Mean Y:38.90 U:47.50 V:48.68 Avg:40.40 Global:40.15 x264 [info]: mb I I16..4: 3.5% 92.3% 4.2% x264 [info]: mb P I16..4: 0.1% 2.6% 0.3% P16..4: 66.9% 13.3% 6.4% 0.0% 0.0% skip:10.4% x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 23.2% 0.4% 1.4% direct: 2.0% skip:73.0% x264 [info]: 8x8 transform intra:89.3% inter:77.3% x264 [info]: direct mvs spatial:86.3% temporal:13.7% x264 [info]: ref P 60.6% 19.7% 12.4% 7.2% x264 [info]: ref B 82.1% 10.7% 5.4% 1.7% x264 [info]: SSIM Mean Y:0.9519027 x264 [info]: PSNR Mean Y:39.293 U:47.450 V:48.602 Avg:40.764 Global:40.499 kb/s:1021.97 Video stream: 1022.145 kbit/s (127768 B/s) size: 7620464 bytes 59.643 secs 1789 frames SEC ; 362 TIME; 0:6.2
scale=640:480:::3 -sws 9 はタップ数3のlanczos、の、ハズ。
おおきく振りかぶって_15_先取点_070720~.mpeg ===MENCODER_PASS1=== $ mencoder おおきく振りかぶって_15_先取点_070720~.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=19:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:8x8dct:turbo=1 -passlogfile おおきく振りかぶって_15_先取点_070720~.264.log -vf pullup,softskip,pp=l5,crop=704:480:8:0,scale=640:480:::3,hqdn3d=4:3:6,harddup -vfm ffmpeg -sws 9 -ofps 24000/1001 -of rawvideo -o /dev/null x264 [info]: using SAR=48/49 x264 [info]: using cpu capabilities: Altivec x264 [info]: slice I:17 Avg QP:24.94 size: 24954 PSNR Mean Y:40.97 U:48.50 V:49.36 Avg:42.38 Global:41.29 x264 [info]: slice P:735 Avg QP:26.74 size: 7763 PSNR Mean Y:38.68 U:46.94 V:48.01 Avg:40.16 Global:39.72 x264 [info]: slice B:678 Avg QP:28.21 size: 1224 PSNR Mean Y:38.50 U:47.17 V:48.26 Avg:40.01 Global:39.60 x264 [info]: mb I I16..4: 20.4% 36.1% 43.5% x264 [info]: mb P I16..4: 9.6% 6.5% 2.8% P16..4: 63.3% 8.3% 2.8% 0.0% 0.0% skip: 6.7% x264 [info]: mb B I16..4: 0.2% 0.2% 0.1% B16..8: 12.6% 0.0% 0.0% direct:15.8% skip:71.2% x264 [info]: final ratefactor: 23.06 x264 [info]: 8x8 transform intra:34.6% inter:29.3% x264 [info]: direct mvs spatial:97.5% temporal:2.5% x264 [info]: SSIM Mean Y:0.9514350 x264 [info]: PSNR Mean Y:38.626 U:47.066 V:48.145 Avg:40.114 Global:39.683 kb/s:933.47 Video stream: 933.639 kbit/s (116704 B/s) size: 6960617 bytes 59.643 secs 1789 frames SEC ; 116 TIME; 0:1.56 ===MENCODER_PASS2=== $ mencoder おおきく振りかぶって_15_先取点_070720~.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=19:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=p8x8,b8x8,i8x8,i4x4:trellis=2:brdo:bime -passlogfile おおきく振りかぶって_15_先取点_070720~.264.log -vf pullup,softskip,pp=l5,crop=704:480:8:0,scale=640:480:::3,hqdn3d=4:3:6,harddup -vfm ffmpeg -sws 9 -ofps 24000/1001 -of rawvideo -o おおきく振りかぶって_15_先取点_070720~.264 x264 [info]: using SAR=48/49 x264 [info]: using cpu capabilities: Altivec x264 [info]: slice I:17 Avg QP:23.12 size: 27106 PSNR Mean Y:42.39 U:49.03 V:49.88 Avg:43.73 Global:43.23 x264 [info]: slice P:735 Avg QP:24.71 size: 8582 PSNR Mean Y:39.69 U:47.40 V:48.48 Avg:41.13 Global:40.92 x264 [info]: slice B:678 Avg QP:26.24 size: 1315 PSNR Mean Y:39.10 U:47.56 V:48.69 Avg:40.59 Global:40.35 x264 [info]: mb I I16..4: 4.1% 85.0% 11.0% x264 [info]: mb P I16..4: 0.1% 2.4% 0.4% P16..4: 67.2% 13.0% 7.3% 0.0% 0.0% skip: 9.6% x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 23.3% 0.5% 1.5% direct: 2.9% skip:71.8% x264 [info]: 8x8 transform intra:83.9% inter:67.5% x264 [info]: direct mvs spatial:90.0% temporal:10.0% x264 [info]: ref P 61.1% 19.6% 12.4% 6.8% x264 [info]: ref B 84.1% 9.6% 5.0% 1.3% x264 [info]: SSIM Mean Y:0.9537451 x264 [info]: PSNR Mean Y:39.440 U:47.493 V:48.598 Avg:40.903 Global:40.662 kb/s:1027.43 Video stream: 1027.606 kbit/s (128450 B/s) size: 7661175 bytes 59.643 secs 1789 frames SEC ; 379 TIME; 0:6.19