このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。 !!!x264-changelog-jp r2200-r2299 r2200-r2299のchangelogの日本語訳。その他のリビジョンと注意事項については[[x264-changelog-jp]]へどうぞ。 前:[[x264-changelog-jp r2100-r2199]] - 次:[[x264-changelog-jp r2300-r2399]] 最近は全くと言っていいほどdiffを見ていないため、速報とか暫定訳とか仮訳とか書いてなくとも色々怪しいです。 !x264r2299 {{bq git-id : 255271fd7999b6b7ff7d65b7b8de1a2dc8919b1a Author : Henrik Gramner Date: Tue Apr 16 23:27:29 2013 +0200 x86: AVX memzero_aligned }} {{bq x86: AVX memzero_aligned。 }} !x264r2298 {{bq git-id : 43632cc8a9115c076204f46e31a5d5c3e58bf934 Author : Henrik Gramner Date: Tue Apr 16 23:27:25 2013 +0200 x86: AVX2 predict_16x16_dc }} {{bq x86: AVX2 predict_16x16_dc。 }} !x264r2297 {{bq git-id : dcad117131f0e0b5032bf5ca8c27def7fcdce17f Author : Henrik Gramner Date: Tue Apr 16 23:27:22 2013 +0200 x86: AVX2 predict_8x8c_p/predict_8x16c_p }} {{bq x86: AVX2 predict_8x8c_p/predict_8x16c_p。 }} !x264r2296 {{bq git-id : f5bff68b16e3125dc95705d060c89935a298f0ff Author : Henrik Gramner Date: Tue Apr 16 23:27:18 2013 +0200 x86: AVX2 predict_16x16_p Also fix the AVX implementation to correctly use the SSSE3 inline asm instead of SSE2. }} {{bq x86: AVX2 predict_16x16_p。 また、SSE2の代わりにSSSE3インラインasmを正しく使用するため、AVX実装を修正。 }} !x264r2295 {{bq git-id : 92eb201b65cb9338500135bda1e2ee4d6861727c Author : Henrik Gramner Date: Tue Apr 16 23:27:14 2013 +0200 x86: AVX high bit-depth predict_16x16_v Also restructure some code to reduce code size of various functions, especially in high bit-depth. }} {{bq x86: AVX高ビット深度predict_16x16_v。 また、特に高ビット深度において、様々な関数のコードサイズを削減するため、いくつかのコードを再構成。 }} !x264r2294 {{bq git-id : 16f3261076c7159aeea902e68ca064c6d0a2cfd8 Author : Henrik Gramner Date: Tue Apr 16 23:27:08 2013 +0200 x86: AVX2 high bit-depth predict_4x4_h }} {{bq x86: AVX2高ビット深度predict_4x4_h。 }} !x264r2293 {{bq git-id : a38b5fc6ec7348342d8ee4ff21abf3e82c5f7bbf Author : Henrik Gramner Date: Tue Apr 16 23:27:04 2013 +0200 x86: AVX2 high bit-depth predict_16x16_h }} {{bq x86: AVX2高ビット深度predict_16x16_h。 }} !x264r2292 {{bq git-id : 89f8263b141492a3b45274616fa0327289329c26 Author : Henrik Gramner Date: Tue Apr 16 23:27:00 2013 +0200 x86: AVX2 high bit-depth predict_8x8c_h/predict_8x16c_h }} {{bq x86: AVX2高ビット深度predict_8x8c_h/predict_8x16c_h。 }} !x264r2291 {{bq git-id : 78b8af872f49aeaa3727ac4e0c8d3b53f0716f51 Author : Henrik Gramner Date: Tue Apr 16 23:26:47 2013 +0200 x86util: Support ymm registers in HADD macros }} {{bq x86util: HADDマクロ内でymmレジスタのサポート。 }} !x264r2290 {{bq git-id : d07b421cf19fc4d77f0bff9d4d6b11db27d81374 Author : Jason Garrett-Glaser Date: Tue Feb 26 16:26:34 2013 -0800 x86: more AVX2 framework, AVX2 functions, plus some existing asm tweaks AVX2 functions: mc_chroma intra_sad_x3_16x16 last64 ads hpel dct4 idct4 sub16x16_dct8 quant_4x4x4 quant_4x4 quant_4x4_dc quant_8x8 SAD_X3/X4 SATD var var2 SSD zigzag interleave weightp weightb intra_sad_8x8_x9 decimate integral hadamard_ac sa8d_satd sa8d lowres_init denoise }} {{bq x86: さらなるAVX2フレームワーク、AVX2関数、そして既存asmの調整。 AVX2関数: mc_chroma intra_sad_x3_16x16 last64 ads hpel dct4 idct4 sub16x16_dct8 quant_4x4x4 quant_4x4 quant_4x4_dc quant_8x8 SAD_X3/X4 SATD var var2 SSD zigzag interleave weightp weightb intra_sad_8x8_x9 decimate integral hadamard_ac sa8d_satd sa8d lowres_init denoise }} ここからしばらく、Haswellで導入されるAVX2対応のコミットが続く。 どの程度の成果が期待されるかは [Dark_Shikari氏が書いている|http://ja.scribd.com/doc/137419114/Introduction-to-AVX2-optimizations-in-x264]し、それをrigaya氏が [rigayaの日記兼メモ帳 x264のAVX2最適化|http://rigaya34589.blog135.fc2.com/blog-entry-354.html]で要約してくれているので、そちらに譲る。 !x264r2289 {{bq git-id : e228f65488b02967bc450bbe3b92ac44eb0088d7 Author : Loren Merritt Date: Mon Feb 25 21:16:45 2013 +0000 x86inc: create xm# and ym#, analagous to m# For when we want to mix simd sizes within one function. }} {{bq x86inc: m#と類似の、xm#をym#作成。 一つの関数内でsimdのサイズを混在させたい場合のため。 }} analogous。 !x264r2288 {{bq git-id : e916dfb774059bc2b63dfe88e32fa21f51abd2b7 Author : Jason Garrett-Glaser Date: Fri Apr 5 16:08:35 2013 -0700 x86inc: fix AVX emulation of cmp(p|s)(s|d) }} {{bq x86inc: cmp(p|s)(s|d)のAVXエミュレーションを修正。 }} !x264r2287 {{bq git-id : 5b01ce105051144c4dd91866e1642cc8d7926c89 Author : Jason Garrett-Glaser Date: Tue Feb 5 17:15:00 2013 -0800 x86-64: cabac_block_residual assembly RDO: ~20% faster than C Bitstream: ~50% faster than C 1-2% faster overall, highest on preset superfast/fast/medium. }} {{bq x86-64: cabac_block_residualのアセンブリ。 RDO: Cより〜20%高速。 Bitstream: Cより〜50%高速。 全体で1〜2%高速、preset superfast/fast/mediumで最も顕著。 }} SkipやDirectなMBでない限りは必ず通るパスの高速化なので、地味ながら着実に性能を上げる。 !x264r2286 {{bq git-id : 3a5f6c0aeacfcb21e7853ab4879f23ec8ae5e042 Author : Steve Borho Date: Thu Feb 21 12:48:40 2013 -0600 OpenCL lookahead OpenCL support is compiled in by default, but must be enabled at runtime by an --opencl command line flag. Compiling OpenCL support requires perl. To avoid the perl requirement use: configure --disable-opencl. When enabled, the lookahead thread is mostly off-loaded to an OpenCL capable GPU device. Lowres intra cost prediction, lowres motion search (including subpel) and bidir cost predictions are all done on the GPU. MB-tree and final slice decisions are still done by the CPU. Presets which do not use a threaded lookahead will not use OpenCL at all (superfast, ultrafast). Because of data dependencies, the GPU must use an iterative motion search which performs more total work than the CPU would do, so this is not work efficient or power efficient. But if there are spare GPU cycles to spare, it can often speed up the encode. Output quality when OpenCL lookahead is enabled is often very slightly worse in quality than the CPU quality (because of the same data dependencies). x264 must compile its OpenCL kernels for your device before running them, and in order to avoid doing this every run it caches the compiled kernel binary in a file named x264_lookahead.clbin (--opencl-clbin FNAME to override). The cache file will be ignored if the device, driver, or OpenCL source are changed. x264 will use the first GPU device which supports the required cl_image features required by its kernels. Most modern discrete GPUs and all AMD integrated GPUs will work. Intel integrated GPUs (up to IvyBridge) do not support those necessary features. Use --opencl-device N to specify a number of capable GPUs to skip during device detection. Switchable graphics environments (e.g. AMD Enduro) are currently not supported, as some have bugs in their OpenCL drivers that cause output to be silently incorrect. Developed by MulticoreWare with support from AMD and Telestream. }} {{bq OpenCL lookahead。 OpenCLのサポートはデフォルトでコンパイルされるが、--openclのコマンドラインフラグで実行時に有効にする必要がある。 OpenCLサポートのコンパイルにはperlが必要である。perlの要求を避けるにはconfigure --disable-openclを使うこと。 有効にされた場合、lookaheadのスレッドは、大部分がOpenCLを利用可能なGPUデバイスにオフロードされる。 Lowres intraコスト予測、Lowres動き検索(サブピクセルを含む)、bidirコスト予測は全てGPUで行われる。 MB-treeと最終的なスライス決定はまだCPUで行われる。 threaded lookaheadを使わないpreset(superfast, ultrafast)はOpenCLを全く使わない。 データの依存関係から、GPUはCPUが行うよりも総量の多い作業である、反復的動き検索を使わねばならず、 そのためこれは作業的にまたは電力的に効率的ではない。 しかしそこに割り振り可能な余剰なGPUサイクルがあるのであれば、それはエンコードを高速化できることが多い。 OpenCL lookaheadが有効時の出力クオリティは、(同じくデータの依存関係によって、) ごくわずかにCPUでのクオリティよりも悪いことが多い。 x264はOpenCLカーネルを機器上で実行する前に、それらをコンパイルせなばならず、 そしてそれを毎回行うのを避けるため、コンパイルされたカーネルバイナリをx264_lookahead.clbinという名前のファイル (--opencl-clbin FNAMEでオーバーライド可能)にキャッシュする。 このキャッシュファイルは、デバイス、ドライバ、またはOpenCLのソースが変わった際は無視される。 x264は、カーネルが要求する、必要なcl_image機能をサポートする最初のGPUデバイスを使う。 ほとんどの現代的な外部GPUと、全てのAMDの統合されたGPUは動作することだろう。 Intelの統合されたGPU(IvyBridgeまで)はそれらの必要な機能をサポートしない。 デバイスの検出時に利用可能なGPUをスキップするには、--opencl-device Nを使いその数を指定する。 切り替え可能なグラフィック環境(例えばAMD 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支援にあまり興味がないというか、苦労の割に貰いが少ないと思っていて、 下手に書くとケチを付けることになってしまいそうなので多くは書かないでおこう。 !x264r2285 {{bq git-id : e436158903c6171ce4abe78f03f013fe04f193bd Author : Jason Garrett-Glaser Date: Mon Mar 4 15:19:47 2013 -0800 weightp: improve scale/offset search, chroma Rescale the scale factor if the offset clips. This makes weightp more effective in fades to/from white (and an other situation that requires big offsets). Search more than 1 scale factor and more than 1 offset, depending on --subme. Try to find the optimal chroma denominator instead of hardcoding it. Overall improvement: a few percent in fade-heavy clips, such as a sample from Avatar: TLA. }} {{bq weightp: chromaのscale/offsetの検索を改善。 offsetがクリップする場合、scale factorをrescaleする。 これは白へ、または白からのフェード(や、その他の大きなオフセットを要するシチュエーション)でのweightpをより効果的にする。 --submeによって、1より大きいscale factor、1より大きいoffsetを検索する。 chromaの分母をハードコーディングせず最適な値を検索しようと試みる。 全体の改善: 例えばAvatar: TLAからのサンプルのようにフェードの重いクリップにおいて、数%。 }} !x264r2284 {{bq git-id : 389d06e8f93916b4fe5766ee4503380f2632ef79 Author : Jason Garrett-Glaser Date: Tue Feb 19 13:48:44 2013 -0800 Add slices-max feature The H.264 spec technically has limits on the number of slices per frame. x264 normally ignores this, since most use-cases that require large numbers of slices prefer it to. However, certain decoders may break with extremely large numbers of slices, as can occur with some slice-max-size/mbs settings. When set, x264 will refuse to create any slices beyond the maximum number, even if slice-max-size/mbs requires otherwise. }} {{bq slices-maxの機能を追加。 H.264の仕様は技術的には1フレーム内のスライス数に制限を有している。 多数のスライスを要求するほとんどのユースケースは、敢えてそうしているため、x264は通常、その制限を無視する。 しかしながら、ある一定のslice-max-size/mbs設定では発生し得るような、極端に多数のスライスでは、特定のデコーダーがおかしくなる。 設定された場合、例えslice-max-size/mbsでの要求が矛盾しようとも、x264は最大値を超えるスライスを作成することを拒否する。 }} X264_BUILD 132。 !x264r2283 {{bq git-id : f546e98eb8f9afd15fb7e8f95ec02fcf65155079 Author : Jason Garrett-Glaser Date: Thu Feb 14 17:22:02 2013 -0800 Add slice-min-mbs feature Works in conjunction with slice-max-mbs and/or slice-max-size to avoid overly small slices. Useful with certain decoders that barf on extremely small slices. If slice-min-mbs would be violated as a result of slice-max-size, x264 will exceed slice-max-size and print a warning. }} {{bq slice-min-mbsの機能を追加。 slice-max-mbsやslice-max-sizeと複合で動作し過渡に小さなスライスを回避する。 極端に小さなスライスがお口に合わない、特定のデコーダに有用。 slice-max-sizeの結果にslice-min-mbsが違反する場合、x264はslice-max-sizeの側を破り、警告を表示する。 }} X264_BUILD 131。 そもそもスライスはRD比の悪化につながるので、''画質・圧縮率の観点では可能な限りスライス数は小さいほうがよい''。 処理の並列可能度が高まるので高速化の可能性は高まるが、x264が一時期スライスベースのスレッディングサポートをやめていたように、 我々の業界(どこだよ)ではあまり好まれていない。 しかし世の中にはそれを好むというか、積極的に使う業界もあり、 そういった所でも使われるx264としてはそういった関連のオプションも増えていくのだろう。 個人的にはBlu-rayで要求される4を超えるスライスを使うことはないと思うので、興味を惹かれない。 !x264r2282 **STABLE** //STABLE {{bq git-id : 1db46210d525856a8f9e59944913127287d956c5 Author : Anton Mitrofanov Date: Tue Mar 26 18:56:21 2013 +0400 Disable mbtree asm with cpu-independent option Results vary between versions because of different rounding results. }} {{bq cpu-independentオプションでmbtreeのasmを無効化。 丸め処理の結果が異なることにより、バージョン間で結果が変化してしまう。 }} !x264r2281 {{bq git-id : fceb3b197f5fcaded3943718c162b662b52b208f Author : Anton Mitrofanov Date: Tue Mar 26 18:30:00 2013 +0400 Show "avs: no" --disable-avs option instead of empty string }} {{bq --disable-avsオプションで空文字列の代わりに"avs: no"を表示。 }} ビルド時(configure)の表示にのみ影響。 !x264r2280 {{bq git-id : 68ee80a51f6f1de78877a9907e3efcbb1fe13ac6 Author : Tim Walker Date: Tue Mar 19 23:42:43 2013 +0100 lavf input: don't use deprecated AVStream fields Fixes building against newer libavcodecs from the Libav project. }} {{bq lavf input: 非推奨のAVStreamのフィールドを使わないようにした。 Libav projectの新しめのlibavcodecに対するビルドを修正する。 }} !x264r2279 {{bq git-id : 5980580d5a4d32eebf32b2f274807dd4aa68836b Author : Anton Mitrofanov Date: Tue Mar 26 19:54:36 2013 +0400 Fix y4m input with C420paldv colorspace }} {{bq C420paldv色空間でのy4m入力を修正。 }} !x264r2278 {{bq git-id : 580cc69707f6996dad8544d6ef0d5a8bbc1b5864 Author : Jason Garrett-Glaser Date: Sat Mar 2 01:22:29 2013 -0800 x86: correctly check stack alignment for Atom hadamard_ac Regression in r2265 (only affected compilers with broken stack alignment, like ICL on win32). }} {{bq x86: Atomのhadamard_acに対し正しくスタックアラインメントのチェックをするようにした。 r2265でのレグレッション(win32でのICLのような、壊れたスタックアラインメントのコンパイラにのみ影響していた)。 }} !x264r2277 {{bq git-id : b3c15fcf677a4ceb59c8f4adc39dc93ecd06ff8a Author : Loren Merritt Date: Mon Feb 25 21:23:55 2013 +0000 x86inc: fix some corner cases of SWAP SWAP with >=3 named (rather than numbered) args PERMUTE followed by SWAP with 2 named args used to produce the wrong permutation }} {{bq x86inc: SWAPのいくつかのコーナーケースを修正。 3つ以上の名前付き(順序付きではなく)引数でのSWAP。 2つの名前付き引数でのSWAPが直後に来るPERMUTE。 誤った置換を生じていた。 }} コーナーケースというのは、通常は発生しない、例外的な問題のあるケースのこと。 訳者はyasmのマクロを知らないので、どういうことなのかはよくわからんです。 !x264r2276 {{bq git-id : 89aecb440e2939be7fb72d8362eb12504711b94f Author : Jason Garrett-Glaser Date: Wed Feb 27 13:30:22 2013 -0800 Fix array overreads that caused miscompilation in gcc 4.8 }} {{bq gcc 4.8でコンパイルミスを発生させていた配列の過剰読み込みを修正 }} プリプロセッサをあまり使い込むとffmpeg/libavのように実態がなんだかよくわからなくなってしまう恐れが…。 トークン結合演算子を使い出したら危険。 いや、便利なんだけれども、書いた人にしか意図がわからなくなりがち。 !x264r2275 {{bq git-id : e355b0e12d6cb380c13cdce15b42093eb8eeef44 Author : Jason Garrett-Glaser Date: Thu Feb 28 13:32:37 2013 -0800 Fix undefined behavior in x264_ratecontrol_mb }} {{bq x264_ratecontrol_mbでの未定義の動作を修正。 }} 多重代入は右結合なんじゃなかったっけ?と思うのだけども。 !x264r2274 {{bq git-id : c832fe995bf3d41cae1d3d22e10cb2288e8a650a Author : Stefan Groenroos Date: Fri Mar 1 22:35:34 2013 +0200 ARM: Fix bug in x264_quant_4x4x4_neon Regression in r2273. }} {{bq ARM: x264_quant_4x4x4_neonのバグを修正。 r2273でのレグレッション。 }} !x264r2273 //MASTER {{bq git-id : b3065e660df391168067f13216d99825260939d4 Author : Stefan Groenroos Date: Mon Feb 25 23:43:09 2013 +0200 ARM: update NEON mc_chroma to work with NV12 and re-enable it Up to 10-15% faster overall. }} {{bq ARM: NEON版mc_chromaをNV12でも動くように更新し、再有効化。 全体で10-15%高速化。 }} !x264r2272 {{bq git-id : e82cf2c8e3bc0d7623f3e8ed9a4684bc3dc40b91 Author : Jason Garrett-Glaser Date: Thu Feb 14 15:00:48 2013 -0800 CABAC/CAVLC: use the new bit-iterating macro here too }} {{bq CABAC/CAVLC: 新しいbit-iteratingマクロをここでも使用。 }} !x264r2271 {{bq git-id : 253e2c3f7eab79d74450de4f88a8bf451fd01be4 Author : Jason Garrett-Glaser Date: Fri Feb 8 15:34:38 2013 -0800 quant_4x4x4: quant one 8x8 block at a time This reduces overhead and lets us use less branchy code for zigzag, dequant, decimate, and so on. Reorganize and optimize a lot of macroblock_encode using this new function. ~1-2% faster overall. Includes NEON and x86 versions of the new function. Using larger merged functions like this will also make wider SIMD, like AVX2, more effective. }} {{bq quant_4x4x4: ひとつの8x8ブロックを一度に量子化。 これはオーバーヘッドを低減し、zigzag, dequant, decimateなどなどに対し、より少量の分岐で済むようにする。 この新しい関数を使いmacroblock_encodeを大きく再構成・最適化。 全体で〜1-2%高速化。 新関数のNEONとx86のバージョンを含む。 このような大きく統合された関数を使用することは、 AVX2のように、より処理幅の広いSIMDをより効果的にする。 }} !x264r2270 {{bq git-id : eaae05ea3f104dc9fa948327e10649ec693adf0e Author : Stephen Hutchinson Date: Tue Feb 12 21:55:43 2013 -0500 Add AvxSynth support to the AviSynth input module. Uses dlopen to load AvxSynth on Linux and OS X. Allows the use of --demuxer avs for AvxSynth, though the only source filter it can currently use is FFMS2. Add a local copy of avxsynth_c.h and its dependent headers in extras/ so that users don't need to actually have AvxSynth development headers installed to enable support for it (mirroring the AviSynth behavior). Based on a patch by 0x09 (tab at lavabit.com) }} {{bq AviSynth入力モジュールにAvxSynthのサポートを追加。 LinuxとOS XではAvxSynthをロードするためにdlopenを使用。 AvxSynthに対し--demuxer avsを使うことを可能にするが、ソースフィルタは現状で唯一FFMS2だけである。 avxsynth_c.hとその依存ヘッダのローカルコピーををextras/に追加したので、 AvxSynthのサポートを有効化するために、 ユーザーが開発用ヘッダを実際にインストールする必要はない(AviSynthの真似である)。 0x09(tab at lavabit.com)のパッチに基づく。 }} !x264r2269 {{bq git-id : b2c70f6548a68b874006a176d48cd0ca4e03859a Author : Jason Garrett-Glaser Date: Fri Feb 8 00:13:15 2013 -0800 Eliminate some branchiness in ME/analysis Faster, fewer branch mispredictions. }} {{bq ME/analysisで幾つか分岐を除去。 より高速で、分岐予測ミスを減少させる。 }} !x264r2268 {{bq git-id : 9d600d64194e0b2a77a8d9aa3f05b141cf473af0 Author : Jason Garrett-Glaser Date: Wed Feb 6 16:55:39 2013 -0800 Fix some store forwarding stalls There's quite a few others, but most of them don't help to fix or there's no easy way to avoid them. }} {{bq いくつかのstore forwarding stallを修正。 他にも非常に多数あるが、ほとんどは修正不能であるか、簡単な回避方法がない。 }} 若干専門的な話になるが、store forwarding stallはインテルのサイトに説明がある。 [How to Avoid Store-Forwarding Stalls on the Pentium 4 Processor|http://software.intel.com/en-us/articles/how-to-avoid-store-forwarding-stalls-on-the-pentiumr-4-processor](もちろん英語)。 これによると、あるメモリ領域に書き込み、直後にそこから別のサイズで読みだすと、キャッシュの更新を待ってしまい、実行が滞るらしい。 例えば16bitで書いて、同じ番地からすぐ32bitで読み出すなど。 !x264r2267 {{bq git-id : 9fe40b1e0db6cd93652e3a45dbbd8f24dbe0b70e Author : Jason Garrett-Glaser Date: Tue Feb 5 01:23:23 2013 -0800 x86: faster AVX satd/sa8d/sa8d_satd/hadamard_ac Use Conroe-style movddup in AVX transforms; both Sandy Bridge and Bulldozer do movddup in the load unit, so it's totally free this way. On Sandy Bridge: ~6% faster sa8d_satd ~5% faster hadamard_ac ~9% faster 32-bit satd ~2% faster sa8d }} {{bq x86: AVX版のsatd/sa8d/sa8d_satd/hadamard_acを高速化。 AVXの変形においてConroeスタイルのmovddupを使用; Sandy BridgeもBulldozerもmovddupをロードユニットで行うため、これで問題はない。 Sandy Bridgeにおいて: sa8d_satdが〜6%高速化 hadamard_acが〜5%高速化 32-bit satdが〜9%高速化 sa8dが〜2%高速化 }} !x264r2266 {{bq git-id : 4f24bb34453fdedefd161063e20516d148b80f8b Author : Jason Garrett-Glaser Date: Sat Feb 2 12:37:08 2013 -0800 x86: detect Bobcat, improve Atom optimizations, reorganize flags The Bobcat has a 64-bit SIMD unit reminiscent of the Athlon 64; detect this and apply the appropriate flags. It also has an extremely slow palignr instruction; create a flag for this to avoid massive penalties on palignr-heavy functions. Improve Atom function selection and document exactly what the SLOW_ATOM flag covers. Add Atom-optimized SATD/SA8D/hadamard_ac functions: simply combine the ssse3 optimizations with the sse2 algorithm to avoid pmaddubsw, which is slow on Atom along with other SIMD multiplies. Drop TBM detection; it'll probably never be useful for x264. Invert FastShuffle to SlowShuffle; it only ever applied to one CPU (Conroe). Detect CMOV, to fail more gracefully when run on a chip with MMX2 but no CMOV. }} {{bq x86: Bobcatの検出、Atom最適化の改善、flagsの再編。 Bobcatは、Athlon 64を連想させる64-bit SIMDユニットを持つ; これを検出して適切なフラグを適用する。 また、極端に遅いpalignr命令を持つ; palignr偏重な関数における多大なペナルティを避けるため、これに対するフラグを作成。 Atomの関数選択を改善し、SLOW_ATOMフラグが何をカバーするかをドキュメント化した。 Atomに最適化したSATD/SA8D/hadamard_ac関数を追加: 他のSIMD乗算と並びAtomでは遅いpmaddubswを避けるため、単純に、ssse3最適化をsse2のアルゴリズムと統合した。 TBMの検出をやめた; 恐らくx264で役立つことはない。 FastShuffleをSlowShuffleに反転した; 1つのCPU(Conroe)にしか適用されないので。 MMX2がありCMOVがないチップ上で実行しようとする際、より穏やかな失敗にするため、CMOVを検出するようにした。 }} X264_BUILD 130。CPU flagsが再編されたため。 もともとx264ではATOMは最適化の対象とされていなかった。 それが[r1611|/x264%252Dchangelog%252Djp%2Br1600%252Dr1699.html#p89]で多少考慮されるようになり、今回もう少しだけ進められ、ATOM用の最適化関数も作成された。 最後の一文は婉曲的で意味が取りづらいが、要はクラッシュせずエラーメッセージを出すようにした、ということかと思われる。 もともと''CMOVはasmが有効なx264で必須''(CMOVなし版のasmも検討されたことはあるが、あまりに広範に使われており切り分けるのは妥当ではないという結論だったはず)であり、MMX2があればCMOVもあるものと仮定していたことによる。 そのため、CPUの機能としてはCMOVを検出するが、それで実行されるasm関数が変わることはない。 TBM: Trailing Bit Manipulation !x264r2265 {{bq git-id : d556d5540ab90b2c89a5ba0cd6ce393f87c19faf Author : Oskar Arvidsson Date: Sat Jan 19 01:47:09 2013 +0100 x86: combined SA8D/SATD dsp function Speedup is most apparent for 8-bit (~30%), but gives some improvements for 10-bit too (~12%). 64-bit only for now. }} {{bq x86: SA8D/SATDのdsp関数を統合。 速度向上は8-bitで最も顕著(〜30%)だが、10-bitでもいくらか改善(〜12%)する。 現在のところ64-bitのみ。 }} !x264r2264 {{bq git-id : 5c2ca5dee339a215cb331c426d40fa548675f088 Author : Oskar Arvidsson Date: Tue Jan 29 23:44:32 2013 +0100 x86: port SSE2+ SATD functions to high bit depth Makes SATD 20-50% faster across all partition sizes but 4x4. }} {{bq x86: SSE2+のSATD関数を高ビット深度に移植。 4x4以外のすべてのpartitionサイズにわたり、SATDを20-50%高速化。 }} !x264r2263 {{bq git-id : b09bc0cc936751f6ad1f20f5e11f523f6051ebc3 Author : Oskar Arvidsson Date: Wed Feb 6 02:07:53 2013 +0100 x86: faster high bit depth ssd About 15% faster on average. }} {{bq x86: 高ビット深度のssdを高速化。 平均で15%程度高速。 }} !x264r2262 {{bq git-id : 91049858f8a051e87efcbe97285657fa3ef9a639 Author : Jason Garrett-Glaser Date: Fri Jan 18 22:55:46 2013 -0800 x86: optimize and clean up predictor checking Branchlessly handle elimination of candidates in MMX roundclip asm. Add a new asm function, similar to roundclip, except without the round part. Optimize and organize the C code, and make both subme>=3 and subme<3 consistent. Add lots of explanatory comments and try to make things a little more understandable. ~5-10% faster with subme>=3, ~15-20% faster with subme<3. }} {{bq x86: predictorチェックの最適化と整理。 MMXのroundclip asmにおいて候補の除去を分岐なしで扱う。 丸め部分がないこと以外はroudclipと類似であるasm関数を追加。 Cコードを最適化・構造化し、subme3以上・未満を一貫させた。 説明的なコメントを数多く追加し、少しはわかりやすくするように努めてみた。 subme>=3で〜5-10%高速、subme<3で〜15-20%高速。 }} こういうパッチはペンギン様かと思ったら、Dark_Shikari氏だった。 !x264r2261 {{bq git-id : a216e5c92a1543e5d748928f7531cfd771739cbf Author : Jason Garrett-Glaser Date: Tue Jan 22 12:31:55 2013 -0800 Fix two bugs in predictor checking pmv wasn't checked properly in some cases, as well as zero vector. Output-changing portion of the following patch. }} {{bq predictorのチェック時のバグを2つ修正。 pmvはいくつかのケースで正しくチェックされていなかった。ゼロベクタの時も。 続くパッチの、出力を変える部分。 }} !x264r2260 {{bq git-id : 4d220bc18cb177b6812c381e7fb808f9ae3189e1 Author : Jason Garrett-Glaser Date: Thu Jan 10 13:15:52 2013 -0800 Improve lookahead-threads auto selection Smarter decision to improve fast-first-pass performance in 2-pass encodes. Dramatically improves CPU utilization on multi-core systems. Tested on a quad-core Ivy Bridge (12 threads, 1080p): Fast first pass: veryfast: ~7% faster faster: ~11% faster fast/medium: ~15% faster slow/slower: ~42% faster veryslow: ~55% faster CRF/1-pass: veryfast: ~9% faster (all others remained the same) }} {{bq lookahead-threadsの自動選択を向上。 2-passエンコードにおいてfast-first-passの性能を向上させる、より賢い決定方法。 マルチコアシステムにおけるCPUの利用効率を劇的に向上させる。 クアッドコアIvy Bridge上でのテスト(12スレッド、1080p): Fast first pass: veryfast: 〜7%高速 faster: 〜11%高速 fast/medium: 〜15%高速 slow/slower: 〜42%高速 veryslow: 〜55%高速 CRF/1-pass: veryfast: 〜9%高速 (その他も同様) }} lookaheadに使うスレッド数を、処理の重さのバランスから自動的に決定する。 特に2-passエンコードにおいて、fast-first-passは解析が目的である。 後段の実エンコード部分に対し、前段であるlookahead部分(主な解析部分)の処理が、1-passのエンコードよりも重くなる。 前段の処理が終わらなければ後段の処理ができないため、場合によっては後段に割り当てられた''スレッドが手持ち無沙汰''となるケースが発生する。 つまりここのスレッド数の配分がおかしいと、いくら合計スレッド数が多くとも、CPUを使い切れない。 そのため、b-adapt, subme, b-framesなどの主要な解析オプションの内容から、最適と思われるスレッド数を決定するのが今回のパッチ。 b-adapt=2で、submeが低く(後段で行うRefinement/RDO系機能が少ないためだろう)、b-framesが多い(動き補償解析が重い)ほど、lookaheadに多くスレッドが割かれる。 なお、''lookaheadのスレッド数は多すぎると精度低下につながる''ため、適当に上限(高さピクセル数 / 128)も設定されている。 また、sliced-threadsの際はスレッドの考え方が異なるため、自動決定はしない。 !x264r2259 {{bq git-id : c63a518d43bb3822342513eb4af109551e86fbd2 Author : Henrik Gramner Date: Sun Jan 27 23:01:59 2013 +0100 x86: Use SSE instead of SSE2 for copying data Reduces code size because movaps/movups is one byte shorter than movdqa/movdqu. Also merge MMX and SSE versions of memcpy_aligned into a single macro. }} {{bq x86: データのコピーにSSE2の代わりにSSEを使用。 movaps/movupsはmovdqa/movdquよりも1バイト短いので、コードサイズを削減。 また、MMXとSSEのバージョンのmemcpy_alignedを1つのマクロに統合。 }} 出力に影響なし。のはず。 !x264r2258 {{bq git-id : 0ce5b431b94f3934a7229ab264c12f1106e4330d Author : Henrik Gramner Date: Sun Jan 13 18:27:08 2013 +0100 64-bit cabac optimizations ~4% faster PIC WIN64: ~3% faster and 16 byte shorter cabac_encode_bypass ~8% faster cabac_encode_terminal Benchmarked on Ivy Bridge UNIX64: One instruction less in cabac_encode_bypass }} {{bq 64-bit cabac 最適化。 〜4%高速なPIC。 WIN64: 〜3%高速で16バイト短いcabac_encode_bypass。 〜8%高速なcabac_encode_terminal。 Ivy Bridge上でのベンチマーク。 UNIX64: cabac_encode_bypassで1命令削減。 }} 出力に影響なし。のはず。 FIXME: PICって?? !x264r2257 {{bq git-id : 51a5976144d80d9dc178fcaba2da5224809ee6ba Author : Mike Gorchak Date: Sat Feb 2 23:35:00 2013 -0800 configure: add QNX support }} {{bq configure: QNXのサポートを追加。 }} ほう、これは面白い。 QNX(きゅーにっくす)は''POSIX互換のリアルタイムOS''で、組み込み系に使用される。 訳者は以前に少しだけ扱ったことがあるが、日本では名前を聞くことも少なく、もう廃れたかと思っていたのだが…まだまだ現役であったか。 と書くとバカにしているように聞こえるかもしれないが、徹底したマイクロカーネル実装は若干堅苦しいくらいに洗練されていたし、公式のドキュメントは、独自製品としては(英語なら)とても充実していた。 一時のSymbianと同じで、プログラミングパラダイムが若干特殊であることを除けば、十分に普及するだけの基礎があるOSだと思う。 日本ではまだμITRONが強いのだろうか。 基本的なAPI仕様がオープンとは言え、μITRONはPOSIXよりかなり限定的な規格であるし、日本の組み込み界がガラパゴスでないことを祈ろう…。 ちなみに、最近では組み込みと言ってもリアルタイム性の不要な分野も多く、''組み込み経験者だからといってリアルタイムOS経験者とは限らない''。 !x264r2256 {{bq git-id : 486ff39f398401d126fbf0379287b1a7ca7fae6e Author : Henrik Gramner Date: Sun Jan 20 19:35:06 2013 +0100 Windows: Enable DEP and ASLR }} {{bq Windows: DEPとASLRを有効化。 }} 出力に影響なし。 いわゆるNXビットなどの対応。 !x264r2255 {{bq git-id : 8da42b78154304ef194747a375a7e1ff3021d0a9 Author : Henrik Gramner Date: Thu Jan 17 19:17:24 2013 +0100 x86inc: Set ELF hidden visibility for global constants }} {{bq x86inc: グローバル定数に対しELFの隠し属性(非可視)を設定。 }} 動作に影響なし。 !x264r2254 {{bq git-id : 989019209b2ccc828480f0e1f506747703134db3 Author : Diego Biurrun Date: Thu Jan 17 11:18:31 2013 +0100 x86inc: Add cvisible macro for C functions with public prefix This allows defining externally visible library symbols. Signed-off-by: Diego Biurrun }} {{bq x86inc: パブリックプレフィックスを持つC関数に対しcvisibleマクロを付加。 これは外部から見えるライブラリシンボルを定義することを可能にする。 Signed-off-by: Diego Biurrun }} 動作に影響なし。 !x264r2253 {{bq git-id : 91b0f0e6415b9cc56b625eb77dd5b471a59d3230 Author : Diego Biurrun Date: Thu Jan 17 11:30:37 2013 -0800 x86inc: rename program_name to private_prefix Synced from libav. The new name is more descriptive and will allow defining a separate public prefix for externally visible library symbols. }} {{bq x86inc: program_nameをprivate_prefixに変更した。 libavと同期。 新しい名前はより説明的で、外部から見えるライブラリのシンボルに対し、 個別のパブリックプレフィックスを定義することを可能にする。 }} 動作に影響なし。 !x264r2252 {{bq git-id : a4e77598d2e1e55483bf0918f6ec2fda51ee9507 Author : Jason Garrett-Glaser Date: Mon Jan 14 05:35:30 2013 -0800 x264.h: improve x264_encoder_reconfig documentation }} {{bq x264.h: x264_encoder_reconfigのドキュメントを改善。 }} バイナリに影響なし。 !x264r2251 {{bq git-id : ce9efeafaad38bc6795d4469c952af2d5bb75a84 Author : Henrik Gramner Date: Sat Feb 16 19:36:50 2013 +0100 Cosmetics: stricter definition of parameterless functions }} {{bq コスメティックス:パラメータなしの関数の定義をより厳密にした。 }} バイナリに影響なし。 コンパイル時にコードの問題を発見できるケースができる。 普通は間違えない部分なのであまり意味はないが、商業プログラミングでは必須とされることも。 !x264r2250 //STABLE {{bq git-id : e403db4f9079811f5a1f9a1339e7c85b41800ca7 Author : Neil Date: Mon Jan 28 10:47:38 2013 +0800 Update "Install and compile x264" in doc/regression_test.txt }} {{bq doc/regression_test.txtの"Install and compile x264"を更新。 }} バイナリに影響なし。 svn時代の表記を修正しただけ。 !x264r2249 {{bq git-id : c13fbaf279d41e6bb8db09e95aec1b638ff026e8 Author : Anton Mitrofanov Date: Thu Jan 24 12:11:26 2013 +0400 Fix possible non-determinism with mbtree + open-gop + sync-lookahead Code assumed keyframe analysis would only pull one frame off the list; this isn't true with open-gop. }} {{bq mbtree + open-gop + sync-lookaheadでの潜在的な非決定性を修正。 コードはキーフレーム解析がリストから1フレーム引くと仮定していた; これはopen-gopでは真でない。 }} !x264r2248 {{bq git-id : 736d69b5875587b61c03aa45438e19ddba1f7035 Author : Anton Mitrofanov Date: Mon Feb 25 19:28:19 2013 +0400 x86: don't use the red zone on win64 }} {{bq x86: win64上でレッドゾーンを使わないようにした。 }} ここでいうレッドゾーンとは、スタック(メモリ)の危険な領域、ということのようだ。 そういえばx86-64におけるABIはWindowsとLinux/U*ix系で違うと聞いたような気もする。 そこら辺の調整と思われる。 !x264r2247 {{bq git-id : 637005ebef9f36b816a9777183660ea17f5b249d Author : Jason Garrett-Glaser Date: Sun Feb 10 16:12:34 2013 -0800 x86-64: fix trellis asm with interlacing Regression in r2145. Assembly assumed array was [2][64] when it was actually [2][63]. Tiny (~0.1%) compression improvement. }} {{bq x86-64: インターレースでのtrellisのasmを修正。 r2145でのレグレッション。 アセンブリは配列が[2][64]であると仮定していたが実際には[2][63]であった。 僅かな(〜0.1%)圧縮率の向上。 }} !x264r2246 {{bq git-id : ba5ce76f7506b5f3d083a9eda8c4705e192f15ff Author : Ronald S. Bultje Date: Wed Jan 30 09:48:14 2013 -0800 x86-32: use simple nop codes for <= sse The "CentaurHauls family 6 model 9 stepping 8" family of CPUs (flags: fpu vme de pse tsc msr cx8 sep mtrr pge mov pat mmx fxsr sse up rng rng_en ace ace_en) SIGILLs on long nop codes. }} {{bq x86-32: <= sse に対して(訳注:SSE以下の環境において)単純なnopコードを使用。 "CentaurHauls family 6 model 9 stepping 8"ファミリーのCPU (flags: fpu vme de pse tsc msr cx8 sep mtrr pge mov pat mmx fxsr sse up rng rng_en ace ace_en) では長いnopコードでSIGILLとなる。 }} 一言で言えば、特定の古いx86互換CPUでのクラッシュを修正したということ。 nopとは''「何もしない」''命令のこと。 単純に考えると、何もしないというのは一見無駄なようにも思えるが、 最適化(例えばスーパースカラによる同時実行性など)を考えるときには、命令の組み合わせを調整するなどのために、意外とよく使用される。 ItaniumなどのVLIW系CPUではコンパイル時の命令配置が実行効率に大きく響くため、アーキテクチャ的に、NOPの存在がほぼ''必須''となっていたりする。 その他にもバイナリハックをする場合など、パディングや分岐潰しに使われ、結構重要な命令である。 x86系CPUにおいて、NOPのマシン語レベルでの表現にはいくつか方法がある。 x264がこれまで使っていた命令は、現在はVIA Technologies傘下となっているCentaur Technology(WinChip C6が有名)製のx86互換CPUで、SIGILL(不正命令:普通はクラッシュする)となるものだったので修正された。 SSE以下という括りはやや大雑把にも思えるが、簡単に対処したということかと思われる。 WinChipはx86命令をRISCで実装するという、これはこれで面白いCPUだったのだが、蛇足すぎるので割愛。 !x264r2245 //HEAD {{bq git-id : bc13772e21d0e61dea6ba81d0d387604b5b360df Author : Loren Merritt Date: Tue Jan 8 21:30:57 2013 +0000 Bump dates to 2013 }} {{bq 日付を2013に上げた。 }} !x264r2244 {{bq git-id : 3508f4a1446c408dcc0febe1a349ad303ae6628c Author : Henrik Gramner Date: Mon Dec 17 21:54:00 2012 +0100 x86inc: Drop tzcnt workaround It is no longer needed now that we've bumped the version requirement of yasm to 1.2.0. }} {{bq x86inc: tzcntのワークアラウンドをやめた。 yasmの要求バージョンを1.2.0に上げたため、不要になった。 }} !x264r2243 {{bq git-id : b924133cabd125286488e16cfa71488ad4105d63 Author : Jason Garrett-Glaser Date: Mon Nov 12 10:28:53 2012 -0800 AVX2/FMA3 version of mbtree_propagate First AVX2 function for testing. Bump yasm version to 1.2.0 for AVX2 support. }} {{bq mbtree_propagateのAVX2/FMA3バージョン。 最初のAVX2関数のテスト。 AVX2サポートのためyasmのバージョンを1.2.0に上げた。 }} !x264r2242 {{bq git-id : d967c09cd93a230e03ec1e0f0f696975d15a01c0 Author : Henrik Gramner Date: Tue Dec 11 16:05:34 2012 +0100 x86inc: Use VEX-encoded instructions in AVX functions Automatically use VEX-encoding in AVX/AVX2/XOP/FMA3/FMA4 functions for all instructions that exists in a VEX-encoded version. This change makes it easier to extend existing code to use AVX2. Also add support for AVX emulation of a few instructions that were missing before. }} {{bq x86inc: AVX関数でVEX符号化命令を使用。 AVX/AVX2/XOP/FMA3/FMA4関数では自動的に、VEX符号化バージョンが存在する全ての命令でVEX符号化を使用する。 この変更は、既存のコードをAVX2を使用するよう拡張するのをより簡単にする。 また、以前は存在しなかった命令群のAVXエミュレーションのサポートを追加。 }} !x264r2241 {{bq git-id : f6c628650558803ed65cb15c1853113cc589ae4a Author : Loren Merritt Date: Sun Dec 2 15:56:30 2012 +0000 x86inc: activate REP_RET automatically Now RET checks whether it immediately follows a branch, so the programmer dosen't have to keep track of that condition. REP_RET is still needed manually when it's a branch target, but that's much rarer. The implementation involves lots of spurious labels, but that's ok because we strip them. }} {{bq x86inc: REP_RETを自動的に有効化するようにした。 RETは分岐の直後であるかを調べるようになり、プログラマは条件を追っかける必要がなくなった。 REP_RETはまだ、それが分岐ターゲットである場合には手作業が必要であるが、それはとても稀である。 実装は大量の疑似ラベルを伴うが、stripするので大丈夫だ、問題ない。(。+・`Θ・´)キリッ }} !x264r2240 {{bq git-id : 755fece365c14135c2621585e761f5dfeedefc74 Author : Ronald S. Bultje Date: Thu Dec 6 15:40:13 2012 -0800 x86inc: support stack mem allocation and re-alignment in PROLOGUE Use this in 8-bit loopfilter functions so they can be used if there is no aligned stack (e.g. x86-32 MSVC or ICC 10.x). }} {{bq x86inc: PROLOGUEでのスタックメモリの確保と再アラインメントのサポート。 8-bitループフィルタ関数でこれを使用することで、アラインされたスタックがなくとも(例えばx86-32 MSVCやICC 10.xなど)それらが使用可能となる。 }} 一般ユーザにはあまり関係ない更新。対応環境の増加。 !x264r2239 {{bq git-id : c69e2d02c4a2ee171b6b8ca0a2e1032213e561bc Author : Henrik Gramner Date: Mon Dec 17 22:15:02 2012 +0100 Update config.guess and config.sub }} {{bq config.guessとconfig.subを更新。 }} !x264r2238 //STABLE {{bq git-id : 9c4ba4bde8965571159eae2d79f85cabbb47416c Author : Anton Mitrofanov Date: Tue Jan 8 13:29:49 2013 -0800 Fix crash if the first frame is forced to a non-keyframe This is obviously bad user input, but x264 shouldn't crash if it happens. }} {{bq 最初のフレームが非キーフレームを強制されている場合のクラッシュを修正。 これは明らかにユーザーの入力が悪いが、その場合でもx264はクラッシュすべきではない。 }} !x264r2237 {{bq git-id : 593e8cc0b374aa7b20d3d961c57feb9bab508979 Author : Bernhard Rosenkr辰nzer Date: Sun Dec 30 12:18:00 2012 -0800 Fix build on ARM with binutils >= GAS doesn't seem to like spaces in vld1 anymore, so remove those. }} {{bq binutils >=でのARMビルドの修正。 GASは最早、vld1内での空白を好まないようであるので、それらを削除。 }} ARMビルドにのみ影響。 !x264r2236 {{bq git-id : 55b5162d7ad9a70e2b6ae5ba3f743a35c2135aaf Author : Anton Mitrofanov Date: Fri Nov 23 18:26:53 2012 +0400 Fix pthread_join emulation on win32 and BeOS Doesn't actually affect x264, but it's more correct. }} {{bq win32とBeOS上でのpthread_joinのエミュレーションを修正。 実際にはx264には影響しないが、より正しい。 }} !x264r2235 {{bq git-id : 0059dcf938451134d8f9c8f1ad522a2c6071e7cd Author : Jason Garrett-Glaser Date: Tue Nov 27 07:50:51 2012 -0800 Fix typo in r2222 Slightly wrong numbers in level table. }} {{bq r2222でのタイポ(誤植)の修正。 levelテーブルで僅かに間違った値であった。 }} !x264r2234 {{bq git-id : 28ee1f47ed4366351477065a0f794f05402e69a7 Author : Sergio Basto Date: Thu Nov 22 18:02:50 2012 -0800 configure: fix gpac detection with -Wp,-D_FORTIFY_SOURCE=2 }} {{bq configure: -Wp,-D_FORTIFY_SOURCE=2でのgpacの検出を修正。 }} ビルドにのみ影響。 !x264r2233 {{bq git-id : 67a69c06d7bd7907b5d1e058a26284c06baa93d1 Author : Sean McGovern Date: Thu Nov 22 18:01:16 2012 -0800 Solaris: use sysconf to get processor count Solaris responds correctly to the same value as Cygwin, so let's use that. }} {{bq Solaris: プロセッサ数を得るためsysconfを使用するようにした。 SolarisはCygwinと同じ値を正しく返すため、それを使う。 }} !x264r2232 {{bq git-id : 6e68ab73908f339cdd91c40943fef46fd1f832fa Author : Anton Khirnov Date: Tue Nov 13 21:01:24 2012 +0100 lavf input: allocate AVFrame correctly Allocate AVFrames correctly with avcodec_alloc_frame(). This caused crashes with newer libavcodecs that try to free frame extradata. }} {{bq lavf input: AVFrameを正しく確保するようにした。 AVFrameをavcodec_alloc_frame()で正しく確保するように。 フレームのextradataを解放しようとする新しめのlibavcodecでクラッシュを起こしていた。 }} !x264r2231 {{bq git-id : a632fe1a57baccdf1bcb340197fe48281cd3117f Author : Anton Mitrofanov Date: Sun Nov 11 03:44:02 2012 +0400 Fix crash when using libx264.dll compiled with ICL for X86_64 }} {{bq ICLでx86_64向けにコンパイルされたlibx264.dllを使用する際のクラッシュを修正。 }} !x264r2230 {{bq git-id : 1cffe9f406cc54f4759fc9eeb85598fb8cae66c7 Author : Anton Mitrofanov Date: Fri Nov 9 02:31:10 2012 +0400 Fix possible issues with out-of-spec QP values Fixes a possible regression in r2228. }} {{bq 仕様外のQP値となる潜在的な問題を修正。 r2228での潜在的なレグレッションを修正する。 }} !x264r2229 //HEAD? {{bq git-id : 349b9bdefae84b006c4bdb7e07290b88a18bbbb2 Author : Jason Garrett-Glaser Date: Wed Sep 26 13:49:02 2012 -0700 Attempt to optimize PPS pic_init_qp in 2-pass mode Small compression improvement; up to ~0.5% in extreme cases. Helps more with small slice sizes (tiny resolutions or slice-max-size). Note that this changes the 2-pass stats file format. }} {{bq 2-passモードでPPSのpic_init_qpの最適化を試みるようにした。 小さな圧縮率の改善; 極端なケースで最大〜0.5%。 小さなスライスサイズ(小さな解像度またはslice-max-size)であるほどより有用。 この変更は2-passのstatsファイル形式を変更することに注意。 }} !x264r2228 {{bq git-id : 8437d0db5de43cf9cd11e02444c80984935e25dc Author : Jason Garrett-Glaser Date: Wed Sep 26 13:05:00 2012 -0700 Improve slice header QP selection Use the first macroblock of each slice instead of the last of the previous. Lets us pick a reasonable initial QP for the first slice too. Slightly improved compression. }} {{bq スライスヘッダのQP選択を改善。 一つ前のスライスの最後のマクロブロックではなく、各スライスの先頭のマクロブロックを使用。 最初のスライスに対しても妥当な初期QPを取るように。 僅かに圧縮率を改善。 }} !x264r2227 {{bq git-id : d2d8364ff48f789ef92135d24c6f185c4eccbeba Author : Jason Garrett-Glaser Date: Thu Oct 11 13:27:48 2012 -0700 Update level dpb size calculation to match newer H.264 spec Doesn't actually change encoding behavior, but makes it more correct. Warning messages should now be accurate at higher bit depths and non-4:2:0. Technically, since it redefines x264_level_t, this is an API version increment. }} {{bq levelのdpbサイズ計算をより新しいH.264の仕様に適合するよう更新。 エンコード動作は実際には変わらないが、より正しくした。 高ビット深度と非4:2:0で警告メッセージが精密になったはず。 技術的には、x264_level_tを再定義するため、これはAPIバージョンの増加である。 }} X264_BUILD 129。 !x264r2226 {{bq git-id : 28ddb0dd533154b58f9147932fb1dec4c74127c8 Author : Jan Ekstr旦m Date: Sun Oct 7 21:12:05 2012 +0300 Add support for the ffmpeg/vapoursynth high bit depth y4m extensions }} {{bq ffmpeg/vapoursynthの高ビット深度y4m拡張のサポートを追加。 }} !x264r2225 {{bq git-id : 64cbe75cf3cae2bbc8fb34bcda5a9742d22f83f2 Author : Diego Biurrun Date: Tue Nov 6 14:48:56 2012 +0100 x86inc: Rename 3dnow2 to 3dnowext The name "3dnowext" is more common than "3dnow2". Doesn't affect x264. }} {{bq x86inc: 3dnow2を3dnowextに名前変更。 "3dnow2"より"3dnowext"という名前のほうが一般的。x264に影響なし。 }} !x264r2224 {{bq git-id : f418867a8b76f31acf3a965eed34c5587294e948 Author : Diego Biurrun Date: Wed Oct 31 12:23:54 2012 -0700 x86inc: only define program_name if the macro is unset. This allows overriding the value from outside the file. This can be useful if x86inc.asm is used outside of x264. }} {{bq x86inc: program_nameをマクロが設定されていない場合のみ定義するようにした。 これはファイル外からの値のオーバーライドを可能にする。 x86inc.asmがx264以外で使用される場合に有用。 }} x264で使用する場合には特に影響なし。 !x264r2223 //STABLE? {{bq git-id : f6a8615ab0c922ac2cb5c82c9824f6f4742b1725 Author : David Wolstencroft Date: Mon Oct 29 09:07:39 2012 -0700 Disable ARM NEON MRC CPU test for Apple devices The Apple A6 CPU doesn't support performance counters, so this test caused a crash. }} {{bq Appleの機器に対するARM NEON MRC CPUテストを無効化。 Apple A6 CPUはパフォーマンスカウンタをサポートしないため、このテストはクラッシュしていた。 }} Apple機器向けのビルドにのみ影響。 !x264r2222 {{bq git-id : 6889f2cee49314aa380d4803991d645659efc01f Author : Jason Garrett-Glaser Date: Tue Nov 6 12:03:20 2012 -0800 Fix crash with no-scenecut + mbtree }} {{bq no-scenecut + mbtreeでのクラッシュを修正。 }} !x264r2221 {{bq git-id : 4dbfcd462ccdf065654d17c47e1d05d53f213bf1 Author : Anton Mitrofanov Date: Fri Oct 12 23:43:40 2012 +0400 Fix reconfiguring to crf=0 Lossless mode can't currently be enabled mid-stream. }} {{bq crf=0へのreconfigureを修正。 現在のところロスレスモードはストリーム途中で有効にできない。 }} libx264の修正。 !x264r2220 {{bq git-id : 2ec8c64580efc10bbfc343d4bec2cf6bbb7d68c7 Author : Derek Buitenhuis Date: Mon Sep 17 11:09:20 2012 -0700 Fix ALIGNED_ARRAY_EMU macros on ICL ICL's preprocessor doesn't handle it correctly. This fix is similar to libav's fix in 0db2d9. }} {{bq ICL上でのALIGNED_ARRAY_EMUマクロを修正。 ICLのプリプロセッサはこれを正しく扱わない。 この修正は0db2d9のlibavの修正と同様である。 }} 「0db2d9」というのはGitのハッシュ。 あるコミットを指すのに、リビジョン番号という概念は広く一般的ではあるが、Gitでは本来ハッシュで表す。 このchangelogにもgit-idという形で書いているが、その先頭の数文字を表している。 gitコマンド上、ハッシュは一意であれば必ずしも全てを書かなくてもよいため、省略表記されている。 !x264r2219 {{bq git-id : 2f154ac1652000afe16140cb12c35d777f0c60c8 Author : Jason Martens Date: Thu Sep 13 11:20:40 2012 -0700 Fix use of deprecated av_close_input_file call }} {{bq 非推奨となったav_close_input_file呼出の使用を修正。 }} !x264r2218 {{bq git-id : 9fc00654018ff9f8a13dbe66785e31568a0c3229 Author : Brad Smith Date: Wed Sep 26 14:13:27 2012 -0700 Fix pkg-config for dynamic vs static linking }} {{bq 静的・動的リンクに対してpkg-configを修正。 }} ビルドにのみ影響。 !x264r2217 {{bq git-id : b22f22fdb1f6d61ccc7b0c867b530322ea681133 Author : Brad Smith Date: Mon Sep 10 17:52:04 2012 -0700 Set libm in the configure script if the OS has libm Prerequisite for another configure patch after this. Idea copied from libpthread. }} {{bq OSにlibmがある場合にはconfigureスクリプトでlibmを設定するようにした。 この後の、別のconfigureのパッチで必要になる。 アイディアはlibpthreadから得た。 }} ビルドにのみ影響。 !x264r2216 //MASTER {{bq git-id : 198a7ea13ccb727d4ea24b29f5da9b0292387309 Author : Jason Garrett-Glaser Date: Thu Aug 16 13:40:32 2012 -0700 Enhance mb_info: add mb_info_update This feature lets the callee know which decoded macroblocks have changed. }} {{bq mb_infoの改善: mb_info_updateを追加。 この機能はどのデコードされたマクロブロックが変わったを呼び出され側が知ることができるようにする。 }} X264_BUILD 128。 先のr2213のpskipの部分を再度修正。こちらが本来の目的だったのだろうか? いずれにせよcalling applicationとlibx264間のI/Fに対する追加機能で、x264cliを使っている場合には関係ない。 !x264r2215 {{bq git-id : f6e9002dd03329b69ea56391b3f4197efca7a690 Author : Jason Garrett-Glaser Date: Thu Aug 16 13:01:17 2012 -0700 Fix mb_info_free with sliced threads x264 would free mb_info before it was completely done using it. }} {{bq sliced threadsでのmb_info_freeを修正。 x264はその使用が完全に終わる前にmb_infoを解放しようとしていた。 }} !x264r2214 {{bq git-id : de725e98eb87198542aae5b8c5ebab4f6c06446e Author : Jason Garrett-Glaser Date: Tue Aug 7 12:43:26 2012 -0700 Enhance nalu_process Add the input frame opaque pointer to the arguments. This makes it easier to use with multiple simultaneous x264 encodes. }} {{bq nalu_processを改善。 入力フレームのopaqueなポインタを引数に追加。 これは複数同時並行なx264のエンコードを容易にする。 }} X264_BUILD 127。 要は、1つのプロセス内でlibx264で2本以上のエンコードを同時に行う時、どのエンコードの出力であるかをコールバック関数内で区別できるよう、引数を追加したということ。 x264cliを使っている場合には関係ない。 !x264r2213 {{bq git-id : 174cfac6344a9fad1577cd1f449b7d0e625d6e28 Author : Jason Garrett-Glaser Date: Mon Aug 6 14:55:35 2012 -0700 Improve mb_info constant mb optimization Allow fast skipping even if the pskip MV isn't zero. }} {{bq mb_infoの固定mb最適化を改善。 pskipのMVがゼロではない場合であっても高速なスキップを可能にする。 }} !x264r2212 {{bq git-id : f57e7070d949b02e1a548382a549c34cf491e05e Author : Jason Garrett-Glaser Date: Mon Jul 30 12:58:34 2012 -0700 Export the average effective CRF of each frame Useful to judge the resulting quality of a frame when VBV is enabled. }} X264_BUILD 126。 各フレームの平均的な実効CRFをエクスポート。 VBVが有効にされている場合にフレームの出力品質の判定に役立つ。 x264cliを使っている場合には関係ない。 !x264r2211 {{bq git-id : d7fd6cc060b6ae3f3bcb9e09fc8bf532a8ed3a82 Author : Brad Smith Date: Mon Aug 20 23:58:19 2012 -0700 Remove special-casing for OpenBSD pthread handling Previously it was policy to use -pthread, but OpenBSD now recommends -lpthread. its been libpthread anyway and policy has changed to stop using -pthread. }} {{bq OpenBSDに対するpthreadの取り扱いの特殊化をやめた。 以前は-pthreadを使うポリシーであったが、OpenBSDは今は-lpthreadを推奨している。 いずれにせよlibpthreadなのであり、ポリシーは-pthreadを使うのを止めるように変わった。 }} OpenBSD向けのビルドにのみ影響。 pthreadが果たして、システムの一部(OSや標準ライブラリに含まれる)とみなすべきなのか、それとも追加機能のライブラリとみなすべきなのか、は(OpenBSDでの事情はともかく)何かと難しいところ。 コンパイラが中途半端に取り込んでしまっているのも混乱の原因と言って良い。 ただpthreadの名前の通りPOSIX標準なのであるから、素人目にはU*ix界隈ではシステムの一部と見なされるべきな気がする。 そもそも、コンパイルオプションでマルチスレッドの明示が必要というのも、時代的にそろそろどうなのかという気もするが、まあ…オーバーヘッド量的にまだまだ無視できないのか。 !x264r2210 {{bq git-id : 8f7644865010385efcb4cb5bd239b28edb4b49e2 Author : Ronald S. Bultje Date: Thu Jul 26 18:01:49 2012 -0700 x86inc: automatically insert vzeroupper for YMM functions Backported from libav. }} {{bq x86inc: YMM命令にvzeroupperを自動的に挿入。 libavからのバックポート。 }} !x264r2209 //STABLE {{bq git-id : 68dfb7b352c4d273e44668c1f6e4a9a283a37e84 Author : Kieran Kunhya Date: Tue Jul 24 08:47:45 2012 -0700 Free user supplied data when deleting a frame This eliminates a memory leak when calling x264_encoder_close. }} {{bq フレームの削除時にユーザーによって与えられたデーターをFree(解放)するように。 x264_encoder_closeを呼んだ際のメモリリークを廃絶する。 }} libx264に関する修正。 x264cliを使っている場合にはプロセス自体が終了するのであまり関係ない。 !x264r2208 //MASTER/HOTFIX {{bq git-id : d9d2288cabcfd1a90f29f2f11c8cce5450a08ffa Author : Jason Garrett-Glaser Date: Wed Jul 18 08:33:41 2012 -0700 Revert r2204 People don't seem to like this so I'm just going to get rid of it. }} {{bq r2204をrevert(取り消し)。 皆さんのお気に召さないようなのでやめようと思います。 }} !x264r2207 //MASTER {{bq git-id : 5f615f7f93d830e55e6fe4f04d214b93d8cb4b53 Author : Jason Garrett-Glaser Date: Tue Jul 10 14:10:44 2012 -0700 Faster predictor checking with subme<3 Fix a typo that made an early-skip less effective. Avoid a relatively unpredictable branch. Slightly changed output due to the typo-fix. ~50 cycles faster on Core i7. }} {{bq subme<3での予測機のチェックを高速化。 早期スキップの効果を薄めていたタイポ(誤植)を修正。 比較的に予測が不能である分岐を回避。 タイポの修正により僅かに出力に変化あり。 Core i7で〜50サイクル速い。 }} !x264r2206 {{bq git-id : 5af86bedd71c89fc48b50bbb7e8a8bec3d360d3a Author : Jason Garrett-Glaser Date: Mon Jun 25 18:01:29 2012 -0700 Try 8x8 transform analysis even when sub8x8 partitions are present Turn off the sub8x8 partitions, try it, and turn them back on if it didn't help. Small compression improvement with p4x4 on (~0.1-0.5%). Also update related comments. }} {{bq sub8x8パーティションが存在する場合にも8x8変換の解析を試行。 sub8x8パーティションをoffにし、試行し、ダメだったらonに戻す。 p4x4がonの場合に小さな圧縮率の向上(〜0.1-0.5%) 関連のコメントを更新。 }} !x264r2205 {{bq git-id : 913485d26b19dddb6340f7115843d63cde8bb836 Author : Jason Garrett-Glaser Date: Fri Jun 8 18:19:59 2012 -0700 Support changing resolutions between passes with macroblock-tree Implement a basic separable bilinear filter to rescale the quantizer offsets. Structure inspired by swscale, but floating-point instead of fixed-point. Not as optimized as it could be, but it's quite fast already. Example compression penalties on a 720p video game recording: First pass with 720p and second as 480p: ~-1.5% (vs. same res) First pass with 480p and second as 720p: ~-3% (vs. same res) }} {{bq マクロブロック・ツリー(mbtree)で、パス間の解像度の変更をサポート。 量子化オフセットを再スケールするために基本的な分離バイリニアフィルターを実装。 構造はswscaleにインスパイアされているが、固定少数点数でなく浮動小数点数としている。 可能な限りというほどの最適化はされていないが、既に十分速い。 720pのゲームのレコーディングにおける圧縮(率)のペナルティの一例は 1パス目を720pで2パス目を480pとした場合: 〜-1.5%(同解像度比) 1パス目を480pで2パス目を720pとした場合: 〜-3%(同解像度比) }} !x264r2204 {{bq git-id : 8b535d9006d87e32c4ff939691b920da823ae85a Author : Alexander Prikhodko Date: Tue Jun 12 20:21:35 2012 +0300 Print elapsed time in encoding progress indicator }} {{bq エンコード進捗インジケーターで経過時間を表示。 }} !x264r2203 {{bq git-id : 11e32c534a213168d8f466fb64bee75e1534d7af Author : Anton Mitrofanov Date: Sat Jun 2 21:27:50 2012 +0400 Cap ratecontrol predictor parameters Limits VBV mispredictions after long periods of relatively constant video. }} {{bq レートコントロール予測のパラメータをキャップ。 比較的に不変な動画が長く続いた後の、VBVの予測ミスを限定的にする。 }} !x264r2202 {{bq git-id : e21e9c972ed830ac7ad264912b41543adf7e720f Author : Loren Merritt Date: Tue Jul 3 14:38:04 2012 -0700 x86inc: import patches from libav Allow manual invocation of WIN64_SPILL_XMM even under INIT_MMX SSE version of mova is movaps rather than movdqa. YMM version of movnta. Add mp size for named arguments. Fix DEFINE_ARGS when used outside of a cglobal. Define a few more cpuflags. 3-argument wrappers for a few more instructions. }} {{bq x86inc: libavからパッチを取り込み。 INIT_MMXの許でも、手動でのWIN64_SPILL_XMMの発行は許可。 SSEバージョンのmovaはmovdqaよりもmovapsに。 YMMバージョンのmovnta。 名前付き引数にmpサイズを追加。 cglobal外で使われた場合のDEFINE_ARGSを修正。 更に幾つかのcpuflagsを定義。 更に幾つかの命令に対する3引数のラッパー。 }} x86incというのは、x264のx86向けアセンブラコードの、抽象化レイヤーを担うマクロアセンブラコード。 例えば、同じ目的にCPU種別ごとに違う命令を使う場合でも、同じコードでわかりやすく書くことが出来る。 r1309でISCライセンスとなり、libavでも使われているのだが、時々libav側で改善されるとバックポートされてくる。 x86incが改善されたからといって必ずしもユーザーに直結するメリットがあるとは限らないが、x264の多くのCPUに最適化されたコードはx86incの基盤があってこそのものである。 !x264r2201 //STABLE {{bq git-id : 37be55213a39db40cf159ada319bd482a1b00680 Author : Anton Mitrofanov Date: Fri Jun 22 22:02:24 2012 +0400 Fix crash with --fps 0 Fix some integer overflows and check input parameters better. Also fix incorrect type specifiers for demuxer info printing. }} {{bq --fps 0でのクラッシュを修正。 幾つかの整数オーバーフローを修正し、入力パラメータをよくチェックするように。 また、demuxer情報の表示時の誤った型指定を修正した。 }} !x264r2200 //HEAD {{bq git-id : 999b753ff0f4dc872077f4fa90d465e948cbe656 Author : Jason Garrett-Glaser Date: Tue May 8 15:42:56 2012 -0700 Threaded lookahead Split each lookahead frame analysis call into multiple threads. Has a small impact on quality, but does not seem to be consistently any worse. This helps alleviate bottlenecks with many cores and frame threads. In many case, this massively increases performance on many-core systems. For example, over 100% faster 1080p encoding with --preset veryfast on a 12-core i7 system. Realtime 1080p30 at --preset slow should now be feasible on real systems. For sliced-threads, this patch should be faster regardless of settings (~10%). By default, lookahead threads are 1/6 of regular threads. This isn't exacting, but it seems to work well for all presets on real systems. With sliced-threads, it's the same as the number of encoding threads. }} {{bq スレッド化lookahead(先読み)。 各lookaheadフレーム解析の呼び出しを複数のスレッドに分割。品質に小さな影響があるが、定常的に悪いというわけでもないようだ。 これは多コアかつframe threads(訳注:スライス単位ではなくフレーム単位でのスレッド化でx264ではデフォルトの方式)でのボトルネックを緩和するのに役立つ。 多くのケースで、これは多コアシステム上でのパフォーマンスを劇的に増大させる。 例えば、12コアi7システム上では--preset veryfastでの1080pエンコードが100%以上速い。 実際のシステム上で--preset slowでのリアルタイム1080p30が実現可能だろう。 sliced-threadsに対しては、このパッチは設定に関わらず速いはず(〜10%)である。 デフォルトでは、lookaheadスレッドは通常のスレッドの1/6である。 これは厳密なものではないが、実際のシステム上で全てのプリセットに対しよく効くようだ。 sliced-threadsではエンコードスレッドの数と同じである。 }} X264_BUILD 125。 --lookahead-threadsオプションが追加。 デフォルトであるエンコードスレッドの1/6という計算は切り捨て。 最低値は1、最大値は16。 表記してある以外にもdereferenceを減少させるなどの変更も含む。 いくつかアセンブラ化の余地がありそうな部分も見受けられる。 前:[[x264-changelog-jp r2100-r2199]] - 次:[[x264-changelog-jp r2300-r2399]]