【リンク】Esperance - a mpeg4 encoder
内部的にはffmpegとx264に作者Esperanceさんが手を加えたもの。コマンドライン版はlinux版もある上に、作者さんの手許では Win版も手がけているモヨリ。P2P分散エンコードという単語もblogにちらほら。GPLなのでソースコードも公開されている。
Esperance tab
グレイアウト部分はまだ動作しない。
1)サンプル・アスペクトレシオ(SAR)とかディスプレイ・アスペクトレシオ(DAR)とかの関係と思われる。
| 素材 (CaptyTV-MPEG2PS,15sec) | 結果(速度 は約50.16sec) |
![]() |
![]() |
![]() |
![]() |
CaptyTVのアスペクトフラグがおかしいか、適切に読み込めていないものと思われる。
手許ではここで悩むより、 MEncoderで一律に横幅640にスケーリングしてしまう。
再生前にMPlayer/VLCで正しいアスペクトレシオを指定する事もできるが、煩瑣ではある。
このへんは映像表示用の4:3, 16:9, シネスコの他に、保存規格の都合による中間形式(720x480)、さらに各国のTV規格や歴史的な経緯、パソコンとのしくみの差、、、などが入り乱れて いる。MyCometG3さんも書かれているが、ややこしく、できれば深入りした くないところだ。
但し、TVや未来のDVD再生機との互換性を重視する向きも多いらしく、x264cliにはSAR/DARをキープするオプションもあるようだ。
Video Usability Info (Annex E):入力値はガーベラ 趣味の花束ブログさんの「x264 CLI アスペクト比 SARについて」が 参考になると思われ。
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk.
--sar width:height Specify Sample Aspect Ratio
2)mp4boxでmuxした場合System Timescaleは600。QT/Esperanceの方が細かい。繊細なタイミングを追求する場合、System Timescaleは小刻みなほうが良さげ。
Quality Settings tab
グレイアウトの項目はまだ指定できない。


現状では1パスのみの実装。
| Esperance | MEncoder -x264encopts相当コマンド | |
![]() |
bitrate | 指定不能。 |
| qp_const | qp_constantと
思われ。 Constant Quantizer用だが、どうも評判がよろしくないらしく、Constant quantization (QP)(*画質固定、一定画質など*)にはqcomp=1 を使うとか、 また最近、crf=<1-50>を使ったQuality Based VBRなるものが増えた。 |
|
| qp_min | qp_minデ フォ10 | |
| qp_max | qp_maxデ フォ51 | |
| qp_step 範囲1-10 |
qp_step 範囲1-50 連続したフレームの間でのquantizerの変動幅。画質の急激な変化を抑止。 MeGUI2.0のデフォやDoom9コデックコンテストでは4。但しこれらは2パスの例。 |
|
| key_max 範囲1-30 |
keyintと
思われ。デフォ250。 keyint_minか も。デフォ25。 |
| Esperance | MEncoder -x264encopts相当コマンド | |
![]() |
threads 範囲1-4 |
threads 範囲同じ。 基本的にCPU/コア数と同じにすべきだが、Macでは1でQT再生不能になる例が数件。自分の常用は2。4だと数秒速くなり、極めて地味にPSNRが下 がる。PSNRは画質の目安とされる数値だが、人間の感覚と合わない事もあるようだ。 |
| subpel_refine 範囲1-6 |
subq 範囲同じ。デフォ5。 速度影響大。 (no)chroma_meを 効かせたければ5以上。 |
|
| frame
reference 範囲1-9 |
frameref 範囲1-16。常識的には3〜4。 速度影響大。 |
|
| motion
estimation 範囲1-4 |
me 範囲同じ。4は実用には遅すぎる。 |
|
| noise_reduction | 相当不明。 | |
| deblock_alphac0 範囲-6〜6 |
deblockalpha H.264 in-loop-filter。MPEG系は原理上ブロックノイズ発生が不可避。デブロッカを映像に埋め込むもの。 デブロッカの適用閾値。適正範囲-1〜1 |
|
| deblock_beta 範囲-6〜6 |
deblockbeta H.264 in-loop-filter。 デブロッカの適用強度。適正範囲-1〜1 |
| Esperance | MEncoder -x264encopts相当コマンド | |
![]() |
bframe_adaptive | (no)b_adapt Bフレーム使用枚数の自動決定。 Bが不適当な場合に間引く。その際はPを使う。 経験上、weight_bに優先する模様。x264のチューニング待ち? |
| psnr | PSNRの
表示。 Esperanceではどこに出てくるのか解らなかった。 |
|
| weighted_bipred | (no)weight_b フェード場面での圧縮効率向上。 MeGUI2.0のデフォもDoom9コデックコンテストも使っているが、経験上、b_adaptが先に効いてしまい、出番が少ない傾向。x264の チューニング待ち? |
|
| bidir_me | (no)bime Bフレームで使うモーションベクトルの精密化。 MeGUIの推奨値はenable |
|
| fast_pskip | 相当不明。 | |
| Analyse Matrix | 相当不明。
x264cliの
-Aと思われる。 (no)i4x4 (no)i8x8 なお、i8x8は8x8dctの使用が前提で、High profile。 |










昨日・今日と頑張っていろいろな機能を付け足してみました。よろしければ、また試してやって下さい。リサイズして小さくするとやはりエンコードが超高速になります。
1つ2つ、x264のノイズリダクション機能ですが、リビジョン398から付け足された機能で、ffmpegのlibなんちゃらのアルゴリズムをベースにノイズリダクションを行うみたいです。試しにその機能も利用できるようにしてみました。有効範囲はちょこっと不明で、とりあえずどこかのリンクにあった100という値までにしてみました。ただ強くかけすぎると、不自然な出力になってしまうこともあるみたいです。x264はデフォルトでも相当綺麗ですので、使わなくてもいいかもです。
また、key_maxはIフレームの挿入のタイミングで、GUIの値通りきちんと秒で判定されます。ただし、MP4のシンクロナイズフラグをかまって、シークが一発で出来るようなファイルを作成していますので、いまのところkey_maxは無意味です。理由は、このようにしないと私のマシンできちんとした再生すらできないためです。つまり駒落しても再生が続くようにそういう設定にしてあります。
fast_pskipは、これもよくわかりませんが、GUIのところが空いてて寂しげでしたので加えました。それと、是非この項目はみたいなものがありましたら、おっしゃって下さい。なるべく反映いたします。
しかし、このページの皆さん玄人の方多すぎて、みんなで集まれば凄い物が作れそうですね。最近Apple H.264に手を出そうとしていますが、mp4ファイルを操作する機能のところで葛藤(ヘッダの抽出(spsとpps)のしかたがわからないっす)があり、踏みとどまっています。私のマシン非力すぎて、AppleH.264の速さが魅力的にうつります。
とりあえず一点だけ質問が。
お手元のG4ノート、クロックとメモリを教えて頂けますか?
>このようにしないと私のマシンできちんとした再生すらできないためです。つまり駒落しても再生が続くように
そこに興味を持つ理由。
MovieVideoChartで確認したところ、仰る通り全フレームがIだったのですが、画質の良さと、それで1400kbpsに収まってる事にまたビビりました。XviDの2000kbps-2パスより全然良いと思います。
「この設定ならこのへんのCPUで再生イケル!!」って情報まとめれば、も少し多くの人が発病、あわわ、AVC/H.264に手を出すのでわないかと。
ウチにも素Cube(G4/450,mem1.5GB)が居るんで、追試もできます。
MovieVideoChart
http://blog.so-net.ne.jp/MyCometG3/2005-11-14-1
>是非この項目はみたいなものがありましたら
ちょっと考えてみます。
早速私のマシンですが、PowerPCG4 1.33GHz・メモリ512MB(泣)を搭載したノートタイプです。QP25とかのクオリティでビットレートが高いフレームがくると、コマ落ちして再生ができなくなってしまいます。ですので、MP4ファイルにビデオデータを追加するときに、(これは推測)Iフレームだよと嘘をついてデータを書き込むことによって、コマ落ちして画面が乱れても、再生が止まることのないように防止策を打ってあります。将来的に、フラグの選択をちゃんとできるようにしようとは思っています。
現在ビットレート関係をかまっていますが、どうもしっくりきません。CBRにすると、画質がかなり粗悪になってしまって、せっかくのH.264のパワーが発揮されませんし、Quality-based VBRのときはQP_MINの値を正しく設定しないとファイルサイズがぶっとんでしまいます。
でもせっかく高画質な出力結果を期待してエンコードすることが多いわけですので、ビットレートと画質のバランスがうまくつり合うような設定が望まれるわけで、そこのところで四苦八苦しています。
なんというか、ファイルサイズに目をつぶって一定のような画質を選択するのが一番良いような気がしています。ここのところは、ばるさんの意見もお聞かせ下さい。
いずれにせよ、また何かあったときには報告いたします。ではでは、、、