x264はH.264/AVC video streamをエンコードするためのフリーなライブラリです。エンコードを始める前に、MEncoderをセットアップしてください。
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html
x264 is a free library for encoding H.264/AVC video streams. Before starting to encode, you need to set up MEncoder to support it.
14.5.1. x264のエンコードオプション
まず最初に MPlayer の man page にある x264セクションを読んで下さい。以下の情報はその補助で、多くの人が関心を持つと思われるオプションのヒントが書いてあります。 man page はもっと簡潔ですが、徹底的でもあり技術的な詳細に及ぶ事もあります。
＊man page -x264encopts試訳：http://agehatype0.blog50.fc2.com/blog-date-20070802.html
14.5.1.1. イントロダクション
このガイドではオプションを二つのカテゴリに分けます。
結局のところ、自分の目的にベストなオプションを決められるのは自分だけなのですが、１の分類のオプションを決めるのは簡単です。速 度低下に見合った画質向上が得られるどうか。それだけです。２の分類のオプションを決めるのは、条件がより主観的になり、またより多くの要素も絡んできま す。この分類のオプションの中にも速度や画質に大きく影響するものがあるのですが、そのオプションの主目的はそこでは無い事に注意して下さい。２の分類の オプションには、画質が良くなるという意見と悪くなるという意見の両方が存在するものすらあります。
先に進む前に、このガイドで使う唯一の画質指標「global PSNR」について。PSNRの詳細な説明は wikipedia (en) のPSNR を見て下さい。global PSNRはエンコード終了後にターミナルの末尾に出て来る数値で、オプションでpsnr計算をさせた時に出るものです。以後PSNRに言及している場合 は、常に同一ビットレートでの比較と考えて下さい。
このガイドのほぼ全文が、two pass を前提に書かれています。オプション比較において two pass エンコードを行う理由は主に二つ。第一は、 two pass はPSNRが1dBほど高くなる事。これは大きな違いです。第二は、one pass エンコードでオプションの影響を比べるのは混乱しがちな事です。エンコードの度にビットレートが大きく変わる事が多いので、画質が良くなったのがオプションを弄ったせいなのか、それともビットレートが変わったせいなのか、見極めが難しい事があるからです。
＊ageha | SSIMとPSNRとは http://agehatype0.blog50.fc2.com/blog-entry-181.html
14.5.1. Encoding options of x264：http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html#menc-feat-x264-encoding-options
Please begin by reviewing the x264 section of MPlayer's man page. This section is intended to be a supplement to the man page. Here you will find quick hints about which options are most likely to interest most people. The man page is more terse, but also more exhaustive, and it sometimes offers much better technical detail.
14.5.1.1. Introduction：http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html#menc-feat-x264-encoding-options-intro
This guide considers two major categories of encoding options:
1. Options which mainly trade off
encoding time vs. quality
2. Options which may be useful for fulfilling
various personal preferences and special requirements
Ultimately, only you can decide which options are best for your purposes. The decision for the first class of options is the simplest: you only have to decide whether you think the quality differences justify the speed differences. For the second class of options, preferences may be far more subjective, and more factors may be involved. Note that some of the “personal preferences and special requirements“ options can still have large impacts on speed or quality, but that is not what they are primarily useful for. A couple of the “personal preference“ options may even cause changes that look better to some people, but look worse to others.
Before continuing, you need to understand that this guide uses only one quality metric: global PSNR. For a brief explanation of what PSNR is, see the Wikipedia article on PSNR. Global PSNR is the last PSNR number reported when you include the psnr option in x264encopts. Any time you read a claim about PSNR, one of the assumptions behind the claim is that equal bitrates are used.
Nearly all of this guide's comments assume you are using two pass. When comparing options, there are two major reasons for using two pass encoding. First, using two pass often gains around 1dB PSNR, which is a very big difference. Secondly, testing options by doing direct quality comparisons with one pass encodes introduces a major confounding factor: bitrate often varies significantly with each encode. It is not always easy to tell whether quality changes are due mainly to changed options, or if they mostly reflect essentially random differences in the achieved bitrate.
subq:速度と画質を取引するオプションの中では、一般的に subq と frameref が最も重要です。速度であれ画質であれ調整したいと思ったらこの二つを最初に弄りましょう。速度については、この二つは非常に密接な関係を持っています。
過去の実験では、デフォルト設定（frameref=1:subq=5）は frameref=1:subq=1 よりも35%ほど時間がかかります。 frameref=6 なら時間は60%以上かかります。subqがPSNRに与える影響は、参照フレーム数に関わらず非常にコンスタントなようです。一般的に subq=5 のPSNRは subq=1 より0.2-0.5 dB高くなりますが、これは充分に目で見て解る違いです。
subq=6 は妥当なコスト（低速化）でよりよい画質をもたらします。通常、subq=5 より global PSNR が 0.1-0.4 dB 向上し、速度は 25%-100% 低下します。subqの他のレベルとは異なり subq=6 はあまり frameref や me の値の影響を受けませんが、主に Bフレーム数の影響を受けます。一般的な使い方では、subq=6 は複雑で動きの多い場面では速度と画質の両方に大きな影響が出るが、動きの少ない場面では大した影響が無い事を意味します。なお、bframes は常に0以外にするのがお奨めです。
subq=7 は最も遅く、最も高画質になるモードです。一般にglobal PSNR は subq=6 より 0.01-0.05 dB 向上し、速度低下は 15%-33% くらいです。この取引は非常に分が悪いので時間を気にせずbit単位で節約したいのでも無い限り使う必要はないでしょう。
subq: Of the options which allow you to trade off speed for quality, subq and frameref (see below) are usually by far the most important. If you are interested in tweaking either speed or quality, these are the first options you should consider. On the speed dimension, the frameref and subq options interact with each other fairly strongly. Experience shows that, with one reference frame, subq=5 (the default setting) takes about 35% more time than subq=1. With 6 reference frames, the penalty grows to over 60%. subq's effect on PSNR seems fairly constant regardless of the number of reference frames. Typically, subq=5 achieves 0.2-0.5 dB higher global PSNR in comparison subq=1. This is usually enough to be visible.
subq=6 is slower and yields better quality at a reasonable cost. In comparison to subq=5, it usually gains 0.1-0.4 dB global PSNR with speed costs varying from 25%-100%. Unlike other levels of subq, the behavior of subq=6 does not depend much on frameref and me. Instead, the effectiveness of subq=6 depends mostly upon the number of B-frames used. In normal usage, this means subq=6 has a large impact on both speed and quality in complex, high motion scenes, but it may not have much effect in low-motion scenes. Note that it is still recommended to always set bframes to something other than zero (see below).
subq=7 is the slowest, highest quality mode. In comparison to subq=6, it usually gains 0.01-0.05 dB global PSNR with speed costs varying from 15%-33%. Since the tradeoff encoding time vs. quality is quite low, you should only use it if you are after every bit saving and if encoding time is not an issue.
framerefのデフォルトは1ですが、妥当な理由があるわけではありません。
・frameref=2にしただけでもPSNRは約0.15db向上し、5-15%の速度低下があります。これは良い取引だと思います。
・frameref=3ではPSNR向上は約0.25db（frameref=1に対して）、これは目で見て解る違いです。速度低下は約15%（これも frameref=1に対して）。残念ながら、ここから効果は急速に減少していきます。
・frameref=6のPSNRはframeref=3に対してたった0.05-0.1 dBくらいしか向上しません。一方、速度低下は約15%追加です。
・frameref=6より上となると画質向上は非常に僅かです（とはいえ素材次第で全く異なる事に注意して下さい）。一般論としては、frameref=12のPSNRはframeref=6に対してたった0.02dB、速度低下は約15-20%追加です。こうした大きなframeref指定について言えそうな事は「PSNRが下がる事はまず確実に無い、画質向上は計測できるギリギリで、目で見てわかるかどうか」くらいです。
ノート：
CABACオフの場合、不必要にframerefを高くすると符号化効率が落ちる可能性があり、実際、通常は落ちます。
CABACオンの場合（デフォルト）、いまのところframerefを「高くしすぎる」心配はしなくて良いようですが今後の開発の進捗で変わる可能性があります。
速度を考えて妥協するなら、subqとframerefを 1stパス では低く抑えて 2nd で上げるという手があります。一般的に最終的な画質低下は無視できる範囲におさまります。PSNRにして0.1dB 以下。これは目で見て解るには小さ過ぎます。しかし、1st と 2nd で frameref を変えると、フレームタイプの決定に影響が出る事があります。例外的なケースのようではありますが、確実を期すなら、素材映像にスクリーン全体を覆うフラッシング・パターンや、Iフレームが入りそうな非常に長いシーンの繰り返しが無いかを確認し、1stパスのframerefをフラッシュサイクルや繰り返しが入るくらいに大きくして下さい。例えば、3フレームに渡るフラッシュ有りとナシの繰り返しがあったら、1stパスのframerefを3以上に。実写素材では非常に稀なケースだと思いますが、ビデオゲームのキャプチャではよくあります。
frameref is set to 1 by default, but this should not be taken to imply that it is reasonable to set it to 1. Merely raising frameref to 2 gains around 0.15dB PSNR with a 5-10% speed penalty; this seems like a good tradeoff. frameref=3 gains around 0.25dB PSNR over frameref=1, which should be a visible difference. frameref=3 is around 15% slower than frameref=1. Unfortunately, diminishing returns set in rapidly. frameref=6 can be expected to gain only 0.05-0.1 dB over frameref=3 at an additional 15% speed penalty. Above frameref=6, the quality gains are usually very small (although you should keep in mind throughout this whole discussion that it can vary quite a lot depending on your source). In a fairly typical case, frameref=12 will improve global PSNR by a tiny 0.02dB over frameref=6, at a speed cost of 15%-20%. At such high frameref values, the only really good thing that can be said is that increasing it even further will almost certainly never harm PSNR, but the additional quality benefits are barely even measurable, let alone perceptible.
Note:
Raising frameref to unnecessarily high values can and usually does hurt
coding efficiency if you turn CABAC off. With CABAC on (the default
behavior), the possibility of setting frameref “too high“ currently
seems too remote to even worry about, and in the future, optimizations
may remove the possibility altogether.
If you care about speed, a reasonable compromise is to use low subq and frameref values on the first pass, and then raise them on the second pass. Typically, this has a negligible negative effect on the final quality: You will probably lose well under 0.1dB PSNR, which should be much too small of a difference to see. However, different values of frameref can occasionally affect frametype decision. Most likely, these are rare outlying cases, but if you want to be pretty sure, consider whether your video has either fullscreen repetitive flashing patterns or very large temporary occlusions which might force an I-frame. Adjust the first-pass frameref so it is large enough to contain the duration of the flashing cycle (or occlusion). For example, if the scene flashes back and forth between two images over a duration of three frames, set the first pass frameref to 3 or higher. This issue is probably extremely rare in live action video material, but it does sometimes come up in video game captures.
me: このオプションは動き予測に使うサーチ方式の選択で、速度と画質の取引に直結します。
me=diaはデフォルトより数パーセント速いだけで、global PSNRの低下は0.1dB以下。
me=hex（デフォルト）はまずまず妥当な取引です。
me=umhの速度低下は frameref に依存しますが、global PSNRの向上は0.1dBをやや切るくらい。
frameref が12のように高いと速度低下はデフォルトの40% くらいになります。 frameref=3 では 25%-30%くらいの低下。
me=esa は徹底的なサーチを行いますが、実用には遅過ぎます。
This option is for choosing the motion estimation search method. Altering this option provides a straightforward quality-vs-speed tradeoff. me=dia is only a few percent faster than the default search, at a cost of under 0.1dB global PSNR. The default setting (me=hex) is a reasonable tradeoff between speed and quality. me=umh gains a little under 0.1dB global PSNR, with a speed penalty that varies depending on frameref. At high values of frameref (e.g. 12 or so), me=umh is about 40% slower than the default me=hex. With frameref=3, the speed penalty incurred drops to 25%-30%.
me=esa uses an exhaustive search that is too slow for practical use.
partitions=all: このオプションは予測されたマクロブロックの中のサブパーティションサイズに、8x4, 4x8, 4x4 を加えるものです。コンスタントに 10%-15% の速度低下があります。ローモーション素材ではまず無意味ですが、一部のハイモーション素材、特に細かい動く物体が大量にある場面では 0.1dB 程度のPSNRゲインが期待できます。
＊まるも製作所さんはp4x4を非推奨としている事に注意。
This option enables the use of 8x4, 4x8 and 4x4 subpartitions in predicted macroblocks (in addition to the default partitions). Enabling it results in a fairly consistent 10%-15% loss of speed. This option is rather useless in source containing only low motion, however in some high-motion source, particularly source with lots of small moving objects, gains of about 0.1dB can be expected.
bframes: 他のコデックでのエンコードに慣れている人なら、Bフレームは良い事ばかりでは無いと考えているかもしれません。H.264ではこの常識は異なります。Bフレームには様々なあたらしい技術とブロックタイプが導入されました。多くの場合、単純なB選択アルゴリズムでさえ目覚ましいPSNRの向上をもたらします。また面白い事に、通常はBを使うと2ndパスがやや高速化します。またシングルパスエンコードも適応的B挿入を切れば高速化が望めます。
適応的B挿入を切った場合（nob_adapt）、bframesの設定は1以下が最適です。さもないとハイモーション・シーンで苦しむ事になるでしょう。適応的B挿入を使う場合（b_adapt、デフォルト）はbframesの数を増やしても安心です。圧縮効率の悪くなる場面ではコデックがBの使用を控えます。x264が3~4以上のBフレームを連続させることは稀ですから、それ以上を指定してもあまり効果はありません。
If you are used to encoding with other codecs, you may have found that B-frames are not always useful. In H.264, this has changed: there are new techniques and block types that are possible in B-frames. Usually, even a naive B-frame choice algorithm can have a significant PSNR benefit. It is interesting to note that using B-frames usually speeds up the second pass somewhat, and may also speed up a single pass encode if adaptive B-frame decision is turned off.
With adaptive B-frame decision turned off (x264encopts's nob_adapt), the optimal value for this setting is usually no more than bframes=1, or else high-motion scenes can suffer. With adaptive B-frame decision on (the default behavior), it is safe to use higher values; the encoder will reduce the use of B-frames in scenes where they would hurt compression. The encoder rarely chooses to use more than 3 or 4 B-frames; setting this option any higher will have little effect.
b_adapt: このオプションは（デフォルトでenabled）あまり効果の無い場面でBの使用を控えるもので、判断精度も速度もそこそこ妥当です。間引き具合の調整にはb_biasを使います。適応的B挿入の速度低下は今のところ慎ましいものですが、画質向上もそれなりです。通常は害はありませんが、このオプションは1stパスの速度とフレームタイプ決定にしか影響がない事に注意して下さい。b_adapt と b_biasは後続パスにはなんの影響もありません。
With this option enabled, the encoder will use a reasonably fast decision process to reduce the number of B-frames used in scenes that might not benefit from them as much. You can use b_bias to tweak how B-frame-happy the encoder is. The speed penalty of adaptive B-frames is currently rather modest, but so is the potential quality gain. It usually does not hurt, however. Note that this only affects speed and frametype decision on the first pass. b_adapt and b_bias have no effect on subsequent passes.
14.5.1.3. 個人の好みや特定の要望に関わるオプション
14.5.1.3. Options pertaining to miscellaneous preferences
本ガイドの冒頭で2パスの常用を推奨しましたが、それが不適当なケースも存在します。例えば、TVキャプチャをリアルタイムでエンコードしているような場合は、1パスしか使えません。また当然ですが1パスは2パスよりはやいです。各パスを同一設定で走らせれば、ちょうど倍の時間がかかります。
それでも２パスにはメリットがあります。
第一に、シングルパスのレートコントロールは人間の印象にそぐうものではありません。重要な絵とそうでないものの区別を付けられないので、妥当な判断ができない事が多いです。例えば２分のビデオがあるとします。前半１分は非常に動きが多く、キレイに圧縮するなら 2500kbps は必要な場面、それに続く一分はローモーション場面で 300kbps で充分だったとしましょう。
これは普通に考えれば 1400kbps で充分なはずですがシングルパスの場合、前半には非常に高い量子化が掛かかって、堪え難く、妥当とも言い難いほどブロックノイズにまみれます。後半は非常に低い量子化が掛かかります。見た目はパーフェクトでしょうが、その為に費消されるビットレートはまったく妥当とは言えないものです。
さらに、両場面の境目という難しい問題があります。ローモーション場面の冒頭数秒間ではレートコントロールが前場面のようなハイモーションが来ると思っているままですから、非常に高い量子化が掛かかります。
こうした「誤認区間」は相当に目障りで、ビットレートも必要な300kbpsに達する事がありません。シングルパスエンコードの欠点を補う方法はいろいろありますが、そうした手段はビットレート予測の誤差が増える傾向があります。
シングルパスに比べると、マルチパスのレートコントロールは大きなメリットがあります。
1st パスで集めた統計ファイルを使って、qp設定値がいくつでも、各フレームに与えるべきコスト（bit）を妥当な精度で予測できます。これにより、（コストの高い）ハイモーション場面と（コストの安い）ローモーション場面の間のビット配分を、より合理的に行う事ができます。このビット配分方針を調整するには、後述の qcomp を読んで下さい。
なお、2パスに２倍の時間を掛けなくても可能です。1stパスのオプションを弄って高速、かつ低画質化する事ができます。調整するオプションを選べば1stは非常に速くなります。サイズ予測の精度が落ちるので最終的な2ndパスの画質はやや落ちますが、通常は目で見て解るほどではありません。
一例を上げると：
1st subq=1:frameref=1
2nd subq=6:frameref=15:partitions=all:me=umh
Three pass encoding?
x264では任意のパス数を使う事ができます。最初のパスに pass=1 を指定し、次のパスに pass=3 を指定します。このパスでは最初の統計ファイルの読み込みと、独自の統計ファイルの書き出しを同時に行います。さらにこの後に続くパスでは、アップデートされた統計ファイルを使って、指定したQPの範囲で各フレームに与えるべきコスト（bit）をより高精度に予測できます。
実用上、全体的な画質向上はほとんどゼロか、2ndより global PSNRが落ちます。一般的に3パスが役に立つのは、2passではビットレート予測が巧くいかない場合か、場面転換が汚く見える場合です。これは非常に短いクリップでありがちなようです。他にも3（以上の）パスが役立つ特殊なケースがいくつかあるのですが、ここでは深入りしません。
x264 offers the ability to make an arbitrary number of consecutive passes. If you specify pass=1 on the first pass, then use pass=3 on a subsequent pass, the subsequent pass will both read the statistics from the previous pass, and write its own statistics. An additional pass following this one will have a very good base from which to make highly accurate predictions of framesizes at a chosen quantizer. In practice, the overall quality gain from this is usually close to zero, and quite possibly a third pass will result in slightly worse global PSNR than the pass before it. In typical usage, three passes help if you get either bad bitrate prediction or bad looking scene transitions when using only two passes. This is somewhat likely to happen on extremely short clips. There are also a few special cases in which three (or more) passes are handy for advanced users, but for brevity, this guide omits discussing those special cases.
qcomp:
qcompは一定量のビットを“コストのかかる“動きの多いシーンと、“コストの安い“動きの少ないシーンの間でやりとりするものです。極端な例をあげると、qcomp=0 で真の固定ビットレートになります。一般的にはこれは、動きの多いシーンが酷い物になる一方、動きの少ないシーンはたぶん完璧になります。しかし必要なビットレートの何倍も無駄にビットを喰っているハズです。反対の極端例。qcomp=1 はほとんどconstant quantization (QP)（＊画質固定、一定画質など＊）です。Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に“コストのかかる“シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。
qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。
qcomp trades off the number of bits allocated to "expensive" high-motion versus "cheap" low-motion frames. At one extreme, qcomp=0 aims for true constant bitrate. Typically this would make high-motion scenes look completely awful, while low-motion scenes would probably look absolutely perfect, but would also use many times more bitrate than they would need in order to look merely excellent. At the other extreme, qcomp=1 achieves nearly constant quantization parameter (QP). Constant QP does not look bad, but most people think it is more reasonable to shave some bitrate off of the extremely expensive scenes (where the loss of quality is not as noticeable) and reallocate it to the scenes that are easier to encode at excellent quality. qcomp is set to 0.6 by default, which may be slightly low for many peoples' taste (0.7-0.8 are also commonly used).
keyint:
keyintはシーク（＊早送りや巻き戻し＊）のやり易さと符号化効率の取引です。他の目的はありません。デフォルトの keyintは250にセットされています。25fps素材では、これで10秒以下の精度でシークできるようになります。5秒精度のシークが重要と考えるなら、keyint=125。ビットレートあたりの品質は僅かに落ちます。重要なのは画質だけで、シークなど気にしないなら、もっと大きな値にできます（値を大きくすればするほど、効果は漸減します。無視できるほど小さく、あるいは0にもなり得ます。）それでも、ビデオストリームにシーンチェンジがある限り、そこがシークポイントになります。
keyint is solely for trading off file seekability against coding efficiency. By default, keyint is set to 250. In 25fps material, this guarantees the ability to seek to within 10 seconds precision. If you think it would be important and useful to be able to seek within 5 seconds of precision, set keyint=125; this will hurt quality/bitrate slightly. If you care only about quality and not about seekability, you can set it to much higher values (understanding that there are diminishing returns which may become vanishingly low, or even zero). The video stream will still have seekable points as long as there are some scene changes.
このトピックはやや議論のあるところだと思います。
H.264規格の定義するデブロッキング手段は、各I-ブロックのQPに応じてプリセットした強度と閾値を使うシンプルなものです。デフォルトでは、QPの高いブロックは強く、低いブロックは全くデブロックしません。H.264規格が定めたプリセット強度は良くできており、どんな素材でも良いPSNRが出る確率が高いです。deblockオプションは、このプリセットの閾値をイジるものです。
多くの人がデブロック強度を大幅に下げるのが良いと考えているようです（-3とか）。しかしこれは全くと言ってよいほど良い考えではありません。多くの場合、デフォルトでの動作原理を解っていないように見えます。
第一に、そして最も重要な事は、デフォルトの閾値はほとんどの場合で最適なPSNRになると言う事です。最適にならないレアケースでも、望ましい調整範囲は +-1。これを超えてデブロッキング・パラメータを弄ると、先ず確実にPSNRが下がります。高くするとディテイルにスミアノイズ（擦ったような汚れ）が増え、弱めればブロックノイズが目に見えるようになります。
ディテイルやノイズが少ない（空間軸の複雑さが少ない）素材の場合デブロックの閾値を下げるのは確実にマズいです。むしろこうした素材ではデブロック・フィルタは非常に巧くアーティファクトを封じ込めます。 空間軸の複雑さが多い素材でも、アーティファクトはあまり目立ちません。これはリンギングノイズはディテイルやノイズに見える傾向がある為です。人間の視覚はディテイルが無くなる事には敏感ですが、間違ったノイズが描き出されても簡単には気が付きません。これは「画質」という点ではノイズとディテイルにはなにがしかの互換性があると言う事です。デブロック強度を下げるとリンギング・アーティファクトが増える傾向がありますが、人間の目はこれを「ディテイル」と誤認して気が付きません。
しかし、これもデブロック強度を弱める理由にはなりません。一般的にもっと良いノイズがポストプロセスで得られるからです。もし出力結果にブラーやスミアが多かったら、MPlayerの再生で'-vf noise' を使って見て下さい。-vf noise=8a:4aで一般的でマイルドなアーティファクトは封じ込められます。デブロッキングフィルタをあれこれ弄るよりキレイに見える事はほぼ確実だと思います。
This topic is going to be a bit controversial.
H.264 defines a simple deblocking procedure on I-blocks that uses pre-set strengths and thresholds depending on the QP of the block in question. By default, high QP blocks are filtered heavily, and low QP blocks are not deblocked at all. The pre-set strengths defined by the standard are well-chosen and the odds are very good that they are PSNR-optimal for whatever video you are trying to encode. The deblock allow you to specify offsets to the preset deblocking thresholds.
Many people seem to think it is a good idea to lower the deblocking filter strength by large amounts (say, -3). This is however almost never a good idea, and in most cases, people who are doing this do not understand very well how deblocking works by default.
The first and most important thing to know about the in-loop deblocking filter is that the default thresholds are almost always PSNR-optimal. In the rare cases that they are not optimal, the ideal offset is plus or minus 1. Adjusting deblocking parameters by a larger amount is almost guaranteed to hurt PSNR. Strengthening the filter will smear more details; weakening the filter will increase the appearance of blockiness.
It is definitely a bad idea to lower the deblocking thresholds if your source is mainly low in spacial complexity (i.e., not a lot of detail or noise). The in-loop filter does a rather excellent job of concealing the artifacts that occur. If the source is high in spacial complexity, however, artifacts are less noticeable. This is because the ringing tends to look like detail or noise. Human visual perception easily notices when detail is removed, but it does not so easily notice when the noise is wrongly represented. When it comes to subjective quality, noise and detail are somewhat interchangeable. By lowering the deblocking filter strength, you are most likely increasing error by adding ringing artifacts, but the eye does not notice because it confuses the artifacts with detail.
This still does not justify lowering the deblocking filter strength, however. You can generally get better quality noise from postprocessing. If your H.264 encodes look too blurry or smeared, try playing with -vf noise when you play your encoded movie. -vf noise=8a:4a should conceal most mild artifacting. It will almost certainly look better than the results you would have gotten just by fiddling with the deblocking filter.
以下は、ビットレートが同じ場合の設定例です。”速度と画質に関わるオプション”のみ。
素材映像は720x448 @30000/1001 fps , ビットレートは900kbps、マシンはAMD-64 3400+（2400 Mhz）の64 bitモードです。それぞれの設定で計測したエンコード速度（frames per seconds）と“very high quality“ に対するPSNR の低下分（dB）も書いてあります。素材、マシン、それから開発の進捗で結果は全く変わる事もあります。
| Description | Encoding options | speed (in fps) |
Relative PSNR loss (in dB) |
|---|---|---|---|
| Very high quality | subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b | 6fps | 0dB |
| high quality | subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b | 13fps | -0.89dB |
| Fast | subq=4:bframes=2:b_pyramid:weight_b | 17fps | -1.48dB |
The following settings are examples of different encoding option combinations that affect the speed vs quality tradeoff at the same target bitrate.
All the encoding settings were tested on a 720x448 @30000/1001 fps video sample, the target bitrate was 900kbps, and the machine was an AMD-64 3400+ at 2400 MHz in 64 bits mode. Each encoding setting features the measured encoding speed (in frames per second) and the PSNR loss (in dB) compared to the "very high quality" setting. Please understand that depending on your source, your machine type and development advancements, you may get very different results.