r2100-r2199このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。r2100-r2199r2100-r2199のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。filterビット深度変換フィルタにRGBフォーマットのサポートを追加。codemb_infoコードのバグを幾つか修正。x264の幾つかのユースケースでは、フレームの大きな固定エリアのエンコードを含む。時に、呼び出し側はどのエリアがそれであるかを知っており、x264に告げることが可能である。このAPIは、呼び出し側がこれを行えるようにし、問題を避けるための、マクロブロックへの変更の内部的な追跡を追加する。これはB-frameなしにのみ本当に適する。VNCにx264を使用するのがユースケースのサンプルの一つだろう。weightのコスト計算を高速化。SSSE3とXOPでの新たなアセンブラ関数の実装。5.2のサポートを追加。Profileへの全ての言及を根絶。x264はそれをサポートしたことは一切なく、誰も使わないので今後サポートすることもない。zones2passエンコードとzonesを使用時のmbtreeの無効化を修正。i386/x86-64に対してgccオプションの-mXXの選択を強制。multilibコンパイルをより便利に。multilibとは所謂過去のMacにあったユニバーサルバイナリのようなもの。説明を以前にもした気がする。(armv8)arm-linux-androideabiconfig.guessとconfig.subを更新。(armv8)arm-linux-androideabiビルドにのみ影響。RC変数の使用を正し、--extra-rcflagsを追加した。共有ライブラリの生成と使用方法を修正。MSVSはエクスポートされる変数がDATAキーワードで宣言される必要があり、インポートされる変数がdllimportで宣言される必要がある。cliが、ICLでビルドされた共有ライブラリを使用できないことを修正しない。X264_API_IMPORTSをすべきとされた。checkフレーム入力色空間のチェックを修正。already.deblock.cのコメントを修正。当該コードは、実際には、既にCAVLC+8x8dctを正しく扱っていた。results).sliced-threadsのレートコントロールのバグを修正。NANを引き起こし得た(言うまでもなく精度低下となる)。threads.mutex/cvsの破壊を修正。r2183でのレグレッション。おかしなことに多くのプラットフォームで動作していたようだが、win64ではクラッシュし、遅かったと思われる。threadsを伴わないx264のエンコーダーの終了時(訳注:実際にはx264_encoder_close関数の呼び出しを指していると思われる)にクラッシュを引き起こし得た。クラッシュが発生するのは終了時だが、修正は初期化時のシーケンス。hpelとdeblockをreturn後に行う。threadsモードにおけるエンコーディングレイテンシを約14%低減する。加えて、フレーム間で待ち時間がない場合においても、hpel+deblockは(シングルスレッドである)lookaheadの間隙に行われるため、これは並列度を高める。デバッグの容易性のために、dump-yuvは、b_full_reconを設定する代わりに、全てのスレッドが待って完了するように強制する。なんだか危なそうな変更だな〜と思ったら、案の定何かおかしいとかの話が出ているらしい。APIのオプションを追加。dump-yuvなしでもフレームを完全に再構築。libx264を使用するアプリケーションで、x264が想定する「デコーダーの出力」と同じものが得られる。エンコーダーであるx264では参照されないBフレームにデブロック処理を行う必要はないが、このオプションを使用することでデブロックされたフレームを得ることができる。amdnopsに変更。最近のAMDのCPUの命令デコーダーは極端に長いnops(すなわち4つのプレフィックス)で酷く苦しくなってしまう。ALIGNをそれほど使っていないので、大きく影響はしないだろう。intelnop→amdnop。intelnopは非常に長いプレフィックスを許すとのこと。逆アセンブルコードを眺める趣味のある人には、古くは90(h)と言えばわかるNOP。1F(h))を用意しているらしい。他にも「無処理」を表現するためにはいくつかの方法があり、推奨される方法がCPUにより異なる。これまではIntel式を使用していたが、それではAMDで苦しくなる事があるらしく、AMD式をyasmに指示するようになった。work.BMI1版のdecimate(間引き)関数。bsfと同等にし、下位互換としたIntelは、なかなかやりおる。我々はこれを動かすために、実際には新たな関数を追加しなくてよいということだ。changes小さなasmの変更。before.精度の向上のためrow再エンコーディングのサポートをVBVに追加。極端に精密であり、ほぼ100%である(困難なVBVであっても失敗させることができなかった)。slice境界での行の分割はまだサポートしていない(slice-max-size/mbsでは頻繁に発生する)。threadsではまだ精密ではないが、以前よりはよい。CBRの幻想で述べた「CBRモード」の精度が向上(ブレが低減)する。nal-hrd=cbrで行われるパディングにも、無駄がとても少なくなるはず。VBVを使ったエンコードでより最適なビット配分が行われるようになる。re-encoding.抽象的なビットストリームのバックアップ/レストア関数。行の再エンコーディングに必要。zero.小さな、「MBごとのコスト」のペナルティをlowresに対し付加。非常に低コストなMBに対してVBV予測機がおかしくなってしまう事を回避するのに役立つ。quantization(訳注:AQ)がQPを大きく減少させても、ゼロに何をかけてもゼロであるため、(このパッチ以前では)コストのペナルティは織り込まれない。エンコーディングアルゴリズムの核心の一つに触れるものなので、猫研で正しい解説ができるかは自信がない。そのため以下の解説が的を射ているかは全力で保証しない。lowresでの解析段階ではMBのビットコストがゼロになってしまうが、実際のエンコーディングではゼロにならないケースが存在する。その場合、AQが「どこまでQP下げてもよいものか?」を判定するにあたって、ゼロに何を掛け算してもゼロであるがために、実際にはゼロコストでないのに、極端にQPを下げる結果となり、フレーム内でのビット配分がおかしくなってしまう。これを回避するため、lowresの段階でゼロコストとなったMBに対しても、予防的に小さなコストを計上しておくことで、適正なQPを選択しようというものだと思われる。codes.coeff_level_runから明示的なrunの計算を削除。ゼロrunのコードに対してはCAVLCの表引きでは不要。いわゆるlevel/run符号化の部分だけれど、勉強してないのでよくわからない。APIPSNR/SSIMをx264のAPIとしてエクスポート。libx264を使用するプログラムで、libx264で測定されたPSNR/SSIMを得ることができるようになった。win64のサポート。amd64が適切に動くのでx264には不要であるが、x86incの他の使用者によって使用される。x264としては影響なし。64-bit.x86_64のアセンブラコードにおける不正な「ゼロ拡張の仮定」を修正。いくつかのx264のアセンブラコードはint値を含むレジスタの上位32bitがゼロであると仮定していた。これは大凡常にそのとおりであるし、gccではうまくいくようだが、ABIによって保証されているわけでは*ない*。結果として、これを最適化において利用する、Clangのような他のいくつかのコンパイラでは壊れてしまう。従って、必要な部分ではmovsxdを使用、またはintの代わりにintptr_tを使用することで全てのx86コードを修正。アセンブラ関数が32bit整数は64bitにゼロ拡張されると不正に仮定している場合に、それを検出するhackをcheckasmに追加。これはBugfixではあるが、まだ十分であるかわかっていないために、stableとタグ付けされていないことに注意。now.MSVCからリンクする場合のアラインメントによるクラッシュの可能性を修正。x264_cavlc_initはスタックがアラインされている必要があるようになった。asm10-bitのintra_satd_x3_16x16のアセンブラコードでの稀なオーバーフローを修正。treeビルドを修正。言えば今までICL(またはICC)の話を書いたことがない気がするが、ICLとはインテル製のコンパイラのことを指している。強力な最適化がなされると言われるし、実際に作成物がGCCより速い事は多い。一方で他社製x86プロセッサでは遅くなるようになっている...という真しやかな噂もあったりする。速度の必要なマルチメディア界では、コンパイラコアとしてGCCの代わりに好んで使われることがある。クリティカルパスが殆どアセンブラ化されているx264では、それほど効用は大きくない。インテルは64bit化にあたり当初はx64(x86-64、AMD64、Intel64、EM64T、IA-32e)ではなくIA-64を推しており、そのEPICと呼ばれるVLIWアーキテクチャでは、プロセッサの真価を発揮するためにコンパイラによる最適化が非常に重要だった(過去形じゃないだろうが)。そのためにコンパイラ技術を持っていることはインテルにとって重要だったりもする。buildout-of-treeビルドにエラー処理を追加。correct.RGB色空間入力を修正。BGR/BGRA入力は正しかった。一口にRGBと呼ばれるが、RGBデータは各色のデーターの並び順の違うケースがよくある。R→G→Bが通常期待される順序だが、B→G→Rという逆順のケースが存在する。x264はその両者を区別していたが、x264内部で扱いやすい様に並べ替える操作が間違っていたものを修正している。Bが最初に来るというのは感覚的に奇妙に思えるが、そういったデーターの多くはWindowsのビットマップ形式がBが最初であることに由来しているのだろう。Windowsビットマップは他にも左下がスキャン開始点であるなどの特異な点がある。Gが最初に来るG→B→RやG→R→Bは筆者は目にしたことがないが、今回の修正を見ると、x264内部ではG→B→Rの順でデーターを保持している。これは恐らく、一般にYUVと呼ばれている形式が、もう少し正確に呼ぶならYCbCrと呼ばれる形式であり、Cbは「輝度に対する青の色差」、Crは「輝度に対する赤の色差」であることから来ている。メトリックが異なるので対応もへったくれもないわけではあるが、敢えて言うなら、Y(Y)→Green、U(Cb)→Blue、V(Cr)→Redと対応するということだろう。極値slice-max-sizeを修正。スライス内の最初のマクロブロックが設定されたslice-max-sizeを超えた場合に壊れていた。殆どないような極端なケースの修正。problems.r2141でのレグレッションを修正。x264_cpu_cpuidとx264_cpu_xgetbvでレジスタ保存を壊していた。(訳注:出力としては)何も問題はなかった。BMI2のCPU検出をサポート。TBMとBMI1はTrinity/Piledriverによってサポートされる。その他(とBMI1)は恐らくIntelの来るHaswellで登場するだろう。x86incをAVX2関連で更新。新しい命令セットに対する準備。一般的なasmのイディオムを抽象化するためTAIL_CALLマクロを追加。optimizations/cleanup小さなasmの最適化・整理。cruft.weightpを整理し最適化、加えてSB/BDZでSSSE3の重み付けを有効化。不使用のAVXのゴミコードを削除。SD/BDZはSandyBridgeとBulldozerのことらしいですよ。Bulldozer.XOP版のframe_init_lowres。8-bitも16-bitもカバーし、Bulldozerで〜5-10%速い。cyclesFieldと言っているのはMBAFFによるインタレ処理の場合のこと。Frameと言っているのはインタレ処理ではない場合のこと。functions.AVX版32-bitのhpel_fileter_h。これらの関数内で成功しなかった最適化に関しても詳細を追加。上位半ワードレジスタのサポートを追加。いくらかのケースでは有用だろう。statement.*.asmファイル内での%ifdefディレクティブを%ifディレクティブに変更。これによって複数の条件を1つのステートメントに合わせることができる。range.ビット深度変換のアルゴリズムにTVレンジを使用。いった素材がより一般的なので、一般的なケースに対して正しくある方がより良い。これはTVレンジのケースに対し(訳注:誤った処理として)以前のアルゴリズムが出力していたものよりも、フルレンジに対して(訳注:変更後のアルゴリズムが誤った処理を行なっても)比較的に誤差の小さな出力をする。2012日付を2012年に上げた。Explorer.Windowsのリソースファイルの追加。Explorerでバージョン情報を表示する。libav.win32のpthread_cond_signalの修正。x264では現在使用されていないので、問題は起こしていなかった。libavからのバックポート。asm関数を4byteにアライン。いくつかのリンカはThumbコードと混ぜた場合にARMの関数を正しくアラインするのに失敗するようだ。4:2:2である場合の色空間の平準化を修正。何やらいたたまれない事情でBlu-rayでは禁止されている、Iフレームを超えて参照を行う問題を修正する。Blu-rayの理不尽な仕様に対しては、もう怒りを通り越して哀れみになってしまったらしい。この修正方法は本質的というよりはややworkaround的な気がするが、仕方ないところか。y4mのクラッシュを修正。VBVでの過剰読み込み・潜在的なクラッシュを修正。Trellisは期待されるブール値を返していなかった。r2143-r2145でのレグレッション。x86_64のasm。コードサイズが18k->12kに。この一連のパッチはエンコード速度に大きな影響があるだろう。23で24%高速である。2ではよりその傾向となる)。いくつかの配列をstaticでなくした。ノードコンテキストをまたがるループから生ずる係数値における分岐を削除。各、取りうる係数値(0,1,n)に対する特別ケース(の考慮)。dc成分のみのブロックに対する特別ケース(の考慮)。2つの汎的なノードのサブセットに対するメインループをテンプレート化し、どちらのノードが生きているかという分岐の山を回避。非更新性のcabac_size_decisionをより多くのケースで使用し、ノードの構造体からそれらのバイナリを省略。CABACオフセットはコンパイル時の定数となった。TRELLIS_SCORE_MAXを特定の定数から、テストが簡単ななにがしかの負数とした。trellisはいずれにせよzigzag[]を見なければならないため、dct_weight2_zigzag[]を削除。x86_64で60%高速。コードサイズが25k->18kに。ペンギン様の英語がネイティブ感大な上に、技術的にも高度で、このコミットに関しては全く以て訳に自信がないと言っておこう...。相変わらずの超人っぷり。出力のちょっとした変更。tie-break順の相違による。ここでいうtie-breakとはなんですか。CABACのアルゴリズムを理解していないのでわからず。argumentsx86incの64-bit向けの改善。すべてのx86-64向けのレジスタのサポートを追加。WIN64においてcallee-savedよりもcaller-savedなレジスタを優先するように。最大15個までの関数引数をサポート。registerとは、ABIの関数呼び出し規約で定められる破壊可・不可なレジスタの事。普通eaxは関数戻り値のために使用されるので、caller-savedであり、破壊可能レジスタである。呼び出し側では関数呼び出しから戻ったらeaxの内容が書き換わっていることを予期すべきであり、逆に呼び出され側ではeaxは好きに上書き(破壊)していいレジスタである。逆にcallee-saved、つまり破壊不能レジスタでは、呼び出し側は関数呼び出しから戻ったら以前の値のままであると予期し、呼び出され側では、そのレジスタを使うのであればreturn時には元の値に戻さねばならない。Code-In.高ビット深度のSSE2/AVX版add8x8_idct8とadd16x16_idct8。Code-In.MMX/SSE2/AVX版のpredict_8x16_pと高ビット深度fdct8。