superfast/fast/mediumで最も顕著。SkipやDirectなMBでない限りは必ず通るパスの高速化なので、地味ながら着実に性能を上げる。OpenCLのサポートはデフォルトでコンパイルされるが、--openclのコマンドラインフラグで実行時に有効にする必要がある。OpenCLサポートのコンパイルにはperlが必要である。--disable-openclを使うこと。有効にされた場合、lookaheadのスレッドは、大部分がOpenCLを利用可能なGPUデバイスにオフロードされる。intraコスト予測、Lowres動き検索(サブピクセルを含む)、bidirコスト予測は全てGPUで行われる。MB-treeと最終的なスライス決定はまだCPUで行われる。ultrafast)はOpenCLを全く使わない。データの依存関係から、GPUはCPUが行うよりも総量の多い作業である、反復的動き検索を使わねばならず、そのためこれは作業的にまたは電力的に効率的ではない。そこに割り振り可能な余剰なGPUサイクルがあるのであれば、それはエンコードを高速化できることが多い。lookaheadが有効時の出力クオリティは、(同じくデータの依存関係によって、)ごくわずかにCPUでのクオリティよりも悪いことが多い。FNAMEでオーバーライド可能)にキャッシュする。このキャッシュファイルは、デバイス、ドライバ、またはOpenCLのソースが変わった際は無視される。x264は、カーネルが要求する、必要なcl_image機能をサポートする最初のGPUデバイスを使う。ほとんどの現代的な外部GPUと、全てのAMDの統合されたGPUは動作することだろう。Intelの統合されたGPU(IvyBridgeまで)はそれらの必要な機能をサポートしない。Nを使いその数を指定する。Enduro)は、いくつかのOpenCLドライバにバグがあり、出力が暗に不正となるため、現在のところサポートされない。AMDとTelestreamのサポートを受けMulticoreWareが開発。おや、X264_BUILDが変わってない...?けどいいのかな?x264としては初のGPUを使うエンコードの公式サポート。これまでにもGPU支援を実装する話は何度もあったが、みな途中で頓挫していたため、期待する向きも多かったろう。真の意味で効率が良いかは別として、確かに一定の範囲で高速化するようだ。ドライバやライブラリの整備状況の問題から、現在のところWindows環境でのみサポートされる。メガパッチではあるが、libx264本体に対する変更は驚くほど少ない。いう意味ではGPUの進化を褒めるべきなのか、OpenCLのラッパーを褒めるべきなのか。上記で書いてあるもの以外では、weightpも一応GPUで実施されるようだ。内部的には、結構細かな単位でGPU側の機能を関数化して呼んでいる。本来であればx264としての処理ステージごとにGPUに丸投げしてしまいたいのだろうが、流石にそうもいかないようだ。動き検索なら、x264的には全動き検索が終わった結果だけくれればいいのだろうが、実装は動き検索内でのiterationごとに制御が返り、再びGPUを呼ぶようになっている模様。詳しく見ていないが、計算自体はGPUに投げても、結果の評価はCPU側で行うしかないのかもしれない。訳者は実はGPU支援にあまり興味がないというか、苦労の割に貰いが少ないと思っていて、下手に書くとケチを付けることになってしまいそうなので多くは書かないでおこう。chromaのscale/offsetの検索を改善。factorをrescaleする。これは白へ、または白からのフェード(や、その他の大きなオフセットを要するシチュエーション)でのweightpをより効果的にする。factor、1より大きいoffsetを検索する。chromaの分母をハードコーディングせず最適な値を検索しようと試みる。TLAからのサンプルのようにフェードの重いクリップにおいて、数%。otherwise.slices-maxの機能を追加。H.264の仕様は技術的には1フレーム内のスライス数に制限を有している。多数のスライスを要求するほとんどのユースケースは、敢えてそうしているため、x264は通常、その制限を無視する。ある一定のslice-max-size/mbs設定では発生し得るような、極端に多数のスライスでは、特定のデコーダーがおかしくなる。設定された場合、例えslice-max-size/mbsでの要求が矛盾しようとも、x264は最大値を超えるスライスを作成することを拒否する。warning.slice-min-mbsの機能を追加。slice-max-mbsやslice-max-sizeと複合で動作し過渡に小さなスライスを回避する。極端に小さなスライスがお口に合わない、特定のデコーダに有用。slice-max-sizeの結果にslice-min-mbsが違反する場合、x264はslice-max-sizeの側を破り、警告を表示する。そもそもスライスはRD比の悪化につながるので、画質・圧縮率の観点では可能な限りスライス数は小さいほうがよい。処理の並列可能度が高まるので高速化の可能性は高まるが、x264が一時期スライスベースのスレッディングサポートをやめていたように、我々の業界(どこだよ)ではあまり好まれていない。世の中にはそれを好むというか、積極的に使う業界もあり、そういった所でも使われるx264としてはそういった関連のオプションも増えていくのだろう。個人的にはBlu-rayで要求される4を超えるスライスを使うことはないと思うので、興味を惹かれない。results.cpu-independentオプションでmbtreeのasmを無効化。丸め処理の結果が異なることにより、バージョン間で結果が変化してしまう。ビルド時(configure)の表示にのみ影響。非推奨のAVStreamのフィールドを使わないようにした。projectの新しめのlibavcodecに対するビルドを修正する。colorspaceC420paldv色空間でのy4m入力を修正。Atomのhadamard_acに対し正しくスタックアラインメントのチェックをするようにした。r2265でのレグレッション(win32でのICLのような、壊れたスタックアラインメントのコンパイラにのみ影響していた)。SWAPのいくつかのコーナーケースを修正。3つ以上の名前付き(順序付きではなく)引数でのSWAP。2つの名前付き引数でのSWAPが直後に来るPERMUTE。誤った置換を生じていた。コーナーケースというのは、通常は発生しない、例外的な問題のあるケースのこと。訳者はyasmのマクロを知らないので、どういうことなのかはよくわからんです。4.8でコンパイルミスを発生させていた配列の過剰読み込みを修正プリプロセッサをあまり使い込むとffmpeg/libavのように実態がなんだかよくわからなくなってしまう恐れが...。トークン結合演算子を使い出したら危険。いや、便利なんだけれども、書いた人にしか意図がわからなくなりがち。x264_ratecontrol_mbx264_ratecontrol_mbでの未定義の動作を修正。多重代入は右結合なんじゃなかったっけ?と思うのだけども。x264_quant_4x4x4_neonのバグを修正。r2273でのレグレッション。NEON版mc_chromaをNV12でも動くように更新し、再有効化。全体で10-15%高速化。新しいbit-iteratingマクロをここでも使用。ひとつの8x8ブロックを一度に量子化。decimateなどなどに対し、より少量の分岐で済むようにする。新関数のNEONとx86のバージョンを含む。このような大きく統合された関数を使用することは、AVX2のように、より処理幅の広いSIMDをより効果的にする。lavabit.com)AviSynth入力モジュールにAvxSynthのサポートを追加。XではAvxSynthをロードするためにdlopenを使用。avsを使うことを可能にするが、ソースフィルタは現状で唯一FFMS2だけである。avxsynth_c.hとその依存ヘッダのローカルコピーををextras/に追加したので、AvxSynthのサポートを有効化するために、ユーザーが開発用ヘッダを実際にインストールする必要はない(AviSynthの真似である)。lavabit.com)のパッチに基づく。mispredictions.ME/analysisで幾つか分岐を除去。高速で、分岐予測ミスを減少させる。他にも非常に多数あるが、ほとんどは修正不能であるか、簡単な回避方法がない。stallはインテルのサイトに説明がある。Processor(もちろん英語)。これによると、あるメモリ領域に書き込み、直後にそこから別のサイズで読みだすと、キャッシュの更新を待ってしまい、実行が滞るらしい。16bitで書いて、同じ番地からすぐ32bitで読み出すなど。AVX版のsatd/sa8d/sa8d_satd/hadamard_acを高速化。BridgeもBulldozerもmovddupをロードユニットで行うため、これで問題はない。Bobcatの検出、Atom最適化の改善、flagsの再編。これを検出して適切なフラグを適用する。palignr偏重な関数における多大なペナルティを避けるため、これに対するフラグを作成。Atomの関数選択を改善し、SLOW_ATOMフラグが何をカバーするかをドキュメント化した。他のSIMD乗算と並びAtomでは遅いpmaddubswを避けるため、単純に、ssse3最適化をsse2のアルゴリズムと統合した。x264で役立つことはない。1つのCPU(Conroe)にしか適用されないので。MMX2がありCMOVがないチップ上で実行しようとする際、より穏やかな失敗にするため、CMOVを検出するようにした。flagsが再編されたため。x264ではATOMは最適化の対象とされていなかった。それがr1611で多少考慮されるようになり、今回もう少しだけ進められ、ATOM用の最適化関数も作成された。最後の一文は婉曲的で意味が取りづらいが、要はクラッシュせずエラーメッセージを出すようにした、ということかと思われる。CMOVはasmが有効なx264で必須(CMOVなし版のasmも検討されたことはあるが、あまりに広範に使われており切り分けるのは妥当ではないという結論だったはず)であり、MMX2があればCMOVもあるものと仮定していたことによる。そのため、CPUの機能としてはCMOVを検出するが、それで実行されるasm関数が変わることはない。SA8D/SATDのdsp関数を統合。速度向上は8-bitで最も顕著(〜30%)だが、10-bitでもいくらか改善(〜12%)する。現在のところ64-bitのみ。SSE2+のSATD関数を高ビット深度に移植。4x4以外のすべてのpartitionサイズにわたり、SATDを20-50%高速化。高ビット深度のssdを高速化。平均で15%程度高速。predictorチェックの最適化と整理。asmにおいて候補の除去を分岐なしで扱う。丸め部分がないこと以外はroudclipと類似であるasm関数を追加。Cコードを最適化・構造化し、subme3以上・未満を一貫させた。説明的なコメントを数多く追加し、少しはわかりやすくするように努めてみた。subme>=3で〜5-10%高速、subme<3で〜15-20%高速。いうパッチはペンギン様かと思ったら、Dark_Shikari氏だった。patch.predictorのチェック時のバグを2つ修正。pmvはいくつかのケースで正しくチェックされていなかった。続くパッチの、出力を変える部分。same)lookahead-threadsの自動選択を向上。2-passエンコードにおいてfast-first-passの性能を向上させる、より賢い決定方法。マルチコアシステムにおけるCPUの利用効率を劇的に向上させる。〜9%高速(その他も同様)lookaheadに使うスレッド数を、処理の重さのバランスから自動的に決定する。2-passエンコードにおいて、fast-first-passは解析が目的である。後段の実エンコード部分に対し、前段であるlookahead部分(主な解析部分)の処理が、1-passのエンコードよりも重くなる。前段の処理が終わらなければ後段の処理ができないため、場合によっては後段に割り当てられたスレッドが手持ち無沙汰となるケースが発生する。ここのスレッド数の配分がおかしいと、いくら合計スレッド数が多くとも、CPUを使い切れない。b-framesなどの主要な解析オプションの内容から、最適と思われるスレッド数を決定するのが今回のパッチ。b-adapt=2で、submeが低く(後段で行うRefinement/RDO系機能が少ないためだろう)、b-framesが多い(動き補償解析が重い)ほど、lookaheadに多くスレッドが割かれる。128)も設定されている。sliced-threadsの際はスレッドの考え方が異なるため、自動決定はしない。データのコピーにSSE2の代わりにSSEを使用。movaps/movupsはmovdqa/movdquよりも1バイト短いので、コードサイズを削減。MMXとSSEのバージョンのmemcpy_alignedを1つのマクロに統合。