このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。
x264-changelog-jp r2200-r2299
r2200-r2299のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。
前:x264-changelog-jp r2100-r2199 - 次:x264-changelog-jp r2300-r2399
最近は全くと言っていいほどdiffを見ていないため、速報とか暫定訳とか仮訳とか書いてなくとも色々怪しいです。
x264r2299
git-id : 255271fd7999b6b7ff7d65b7b8de1a2dc8919b1a
Author : Henrik Gramner
Date: Tue Apr 16 23:27:29 2013 +0200
x86: AVX memzero_aligned
x86: AVX memzero_aligned。
x264r2298
git-id : 43632cc8a9115c076204f46e31a5d5c3e58bf934
Author : Henrik Gramner
Date: Tue Apr 16 23:27:25 2013 +0200
x86: AVX2 predict_16x16_dc
x86: AVX2 predict_16x16_dc。
x264r2297
git-id : dcad117131f0e0b5032bf5ca8c27def7fcdce17f
Author : Henrik Gramner
Date: Tue Apr 16 23:27:22 2013 +0200
x86: AVX2 predict_8x8c_p/predict_8x16c_p
x86: AVX2 predict_8x8c_p/predict_8x16c_p。
x264r2296
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.
x86: AVX2 predict_16x16_p。
また、SSE2の代わりにSSSE3インラインasmを正しく使用するため、AVX実装を修正。
x264r2295
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.
x86: AVX高ビット深度predict_16x16_v。
また、特に高ビット深度において、様々な関数のコードサイズを削減するため、いくつかのコードを再構成。
x264r2294
git-id : 16f3261076c7159aeea902e68ca064c6d0a2cfd8
Author : Henrik Gramner
Date: Tue Apr 16 23:27:08 2013 +0200
x86: AVX2 high bit-depth predict_4x4_h
x86: AVX2高ビット深度predict_4x4_h。
x264r2293
git-id : a38b5fc6ec7348342d8ee4ff21abf3e82c5f7bbf
Author : Henrik Gramner
Date: Tue Apr 16 23:27:04 2013 +0200
x86: AVX2 high bit-depth predict_16x16_h
x86: AVX2高ビット深度predict_16x16_h。
x264r2292
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
x86: AVX2高ビット深度predict_8x8c_h/predict_8x16c_h。
x264r2291
git-id : 78b8af872f49aeaa3727ac4e0c8d3b53f0716f51
Author : Henrik Gramner
Date: Tue Apr 16 23:26:47 2013 +0200
x86util: Support ymm registers in HADD macros
x86util: HADDマクロ内でymmレジスタのサポート。
x264r2290
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
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氏が書いているし、それをrigaya氏がrigayaの日記兼メモ帳 x264のAVX2最適化で要約してくれているので、そちらに譲る。
x264r2289
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.
x86inc: m#と類似の、xm#をym#作成。
一つの関数内でsimdのサイズを混在させたい場合のため。
analogous。
x264r2288
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)
x86inc: cmp(p|s)(s|d)のAVXエミュレーションを修正。
x264r2287
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.
x86-64: cabac_block_residualのアセンブリ。
RDO: Cより〜20%高速。
Bitstream: Cより〜50%高速。
全体で1〜2%高速、preset superfast/fast/mediumで最も顕著。
SkipやDirectなMBでない限りは必ず通るパスの高速化なので、地味ながら着実に性能を上げる。
x264r2286
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.
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
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.
weightp: chromaのscale/offsetの検索を改善。
offsetがクリップする場合、scale factorをrescaleする。
これは白へ、または白からのフェード（や、その他の大きなオフセットを要するシチュエーション）でのweightpをより効果的にする。
--submeによって、1より大きいscale factor、1より大きいoffsetを検索する。
chromaの分母をハードコーディングせず最適な値を検索しようと試みる。
全体の改善: 例えばAvatar: TLAからのサンプルのようにフェードの重いクリップにおいて、数％。
x264r2284
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.
slices-maxの機能を追加。
H.264の仕様は技術的には1フレーム内のスライス数に制限を有している。
多数のスライスを要求するほとんどのユースケースは、敢えてそうしているため、x264は通常、その制限を無視する。
しかしながら、ある一定のslice-max-size/mbs設定では発生し得るような、極端に多数のスライスでは、特定のデコーダーがおかしくなる。
設定された場合、例えslice-max-size/mbsでの要求が矛盾しようとも、x264は最大値を超えるスライスを作成することを拒否する。
X264_BUILD 132。
x264r2283
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.
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**
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.
cpu-independentオプションでmbtreeのasmを無効化。
丸め処理の結果が異なることにより、バージョン間で結果が変化してしまう。
x264r2281
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
--disable-avsオプションで空文字列の代わりに"avs: no"を表示。
ビルド時(configure)の表示にのみ影響。
x264r2280
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.
lavf input: 非推奨のAVStreamのフィールドを使わないようにした。
Libav projectの新しめのlibavcodecに対するビルドを修正する。
x264r2279
git-id : 5980580d5a4d32eebf32b2f274807dd4aa68836b
Author : Anton Mitrofanov
Date: Tue Mar 26 19:54:36 2013 +0400
Fix y4m input with C420paldv colorspace
C420paldv色空間でのy4m入力を修正。
x264r2278
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).
x86: Atomのhadamard_acに対し正しくスタックアラインメントのチェックをするようにした。
r2265でのレグレッション（win32でのICLのような、壊れたスタックアラインメントのコンパイラにのみ影響していた）。
x264r2277
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
x86inc: SWAPのいくつかのコーナーケースを修正。
3つ以上の名前付き（順序付きではなく）引数でのSWAP。
2つの名前付き引数でのSWAPが直後に来るPERMUTE。
誤った置換を生じていた。
コーナーケースというのは、通常は発生しない、例外的な問題のあるケースのこと。
訳者はyasmのマクロを知らないので、どういうことなのかはよくわからんです。
x264r2276
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
gcc 4.8でコンパイルミスを発生させていた配列の過剰読み込みを修正
プリプロセッサをあまり使い込むとffmpeg/libavのように実態がなんだかよくわからなくなってしまう恐れが…。トークン結合演算子を使い出したら危険。いや、便利なんだけれども、書いた人にしか意図がわからなくなりがち。
x264r2275
git-id : e355b0e12d6cb380c13cdce15b42093eb8eeef44
Author : Jason Garrett-Glaser
Date: Thu Feb 28 13:32:37 2013 -0800
Fix undefined behavior in x264_ratecontrol_mb
x264_ratecontrol_mbでの未定義の動作を修正。
多重代入は右結合なんじゃなかったっけ？と思うのだけども。
x264r2274
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.
ARM: x264_quant_4x4x4_neonのバグを修正。
r2273でのレグレッション。
x264r2273
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.
ARM: NEON版mc_chromaをNV12でも動くように更新し、再有効化。
全体で10-15%高速化。
x264r2272
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
CABAC/CAVLC: 新しいbit-iteratingマクロをここでも使用。
x264r2271
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.
quant_4x4x4: ひとつの8x8ブロックを一度に量子化。
これはオーバーヘッドを低減し、zigzag, dequant, decimateなどなどに対し、より少量の分岐で済むようにする。
この新しい関数を使いmacroblock_encodeを大きく再構成・最適化。
全体で〜1-2%高速化。
新関数のNEONとx86のバージョンを含む。
このような大きく統合された関数を使用することは、
AVX2のように、より処理幅の広いSIMDをより効果的にする。
x264r2270
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)
AviSynth入力モジュールにAvxSynthのサポートを追加。
LinuxとOS XではAvxSynthをロードするためにdlopenを使用。
AvxSynthに対し--demuxer avsを使うことを可能にするが、ソースフィルタは現状で唯一FFMS2だけである。
avxsynth_c.hとその依存ヘッダのローカルコピーををextras/に追加したので、
AvxSynthのサポートを有効化するために、
ユーザーが開発用ヘッダを実際にインストールする必要はない（AviSynthの真似である）。
0x09(tab at lavabit.com)のパッチに基づく。
x264r2269
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.
ME/analysisで幾つか分岐を除去。
より高速で、分岐予測ミスを減少させる。
x264r2268
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.
いくつかのstore forwarding stallを修正。
他にも非常に多数あるが、ほとんどは修正不能であるか、簡単な回避方法がない。
若干専門的な話になるが、store forwarding stallはインテルのサイトに説明がある。How to Avoid Store-Forwarding Stalls on the Pentium 4 Processor（もちろん英語）。これによると、あるメモリ領域に書き込み、直後にそこから別のサイズで読みだすと、キャッシュの更新を待ってしまい、実行が滞るらしい。例えば16bitで書いて、同じ番地からすぐ32bitで読み出すなど。
x264r2267
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
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
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.
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で多少考慮されるようになり、今回もう少しだけ進められ、ATOM用の最適化関数も作成された。
最後の一文は婉曲的で意味が取りづらいが、要はクラッシュせずエラーメッセージを出すようにした、ということかと思われる。もともとCMOVはasmが有効なx264で必須（CMOVなし版のasmも検討されたことはあるが、あまりに広範に使われており切り分けるのは妥当ではないという結論だったはず）であり、MMX2があればCMOVもあるものと仮定していたことによる。そのため、CPUの機能としてはCMOVを検出するが、それで実行されるasm関数が変わることはない。
TBM: Trailing Bit Manipulation
x264r2265
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.
x86: SA8D/SATDのdsp関数を統合。
速度向上は8-bitで最も顕著（〜30%）だが、10-bitでもいくらか改善（〜12%）する。
現在のところ64-bitのみ。
x264r2264
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.
x86: SSE2+のSATD関数を高ビット深度に移植。
4x4以外のすべてのpartitionサイズにわたり、SATDを20-50%高速化。
x264r2263
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.
x86: 高ビット深度のssdを高速化。
平均で15%程度高速。
x264r2262
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.
x86: predictorチェックの最適化と整理。
MMXのroundclip asmにおいて候補の除去を分岐なしで扱う。
丸め部分がないこと以外はroudclipと類似であるasm関数を追加。
Cコードを最適化・構造化し、subme3以上・未満を一貫させた。
説明的なコメントを数多く追加し、少しはわかりやすくするように努めてみた。
subme>=3で〜5-10%高速、subme<3で〜15-20%高速。
こういうパッチはペンギン様かと思ったら、Dark_Shikari氏だった。
x264r2261
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.
predictorのチェック時のバグを2つ修正。
pmvはいくつかのケースで正しくチェックされていなかった。ゼロベクタの時も。
続くパッチの、出力を変える部分。
x264r2260
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)
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
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.
x86: データのコピーにSSE2の代わりにSSEを使用。
movaps/movupsはmovdqa/movdquよりも1バイト短いので、コードサイズを削減。
また、MMXとSSEのバージョンのmemcpy_alignedを1つのマクロに統合。
出力に影響なし。のはず。
x264r2258
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
64-bit cabac 最適化。
〜4%高速なPIC。
WIN64:
〜3%高速で16バイト短いcabac_encode_bypass。
〜8%高速なcabac_encode_terminal。
Ivy Bridge上でのベンチマーク。
UNIX64:
cabac_encode_bypassで１命令削減。
出力に影響なし。のはず。
FIXME: PICって？？
x264r2257
git-id : 51a5976144d80d9dc178fcaba2da5224809ee6ba
Author : Mike Gorchak
Date: Sat Feb 2 23:35:00 2013 -0800
configure: add QNX support
configure: QNXのサポートを追加。
ほう、これは面白い。QNX（きゅーにっくす）はPOSIX互換のリアルタイムOSで、組み込み系に使用される。訳者は以前に少しだけ扱ったことがあるが、日本では名前を聞くことも少なく、もう廃れたかと思っていたのだが…まだまだ現役であったか。
と書くとバカにしているように聞こえるかもしれないが、徹底したマイクロカーネル実装は若干堅苦しいくらいに洗練されていたし、公式のドキュメントは、独自製品としては（英語なら）とても充実していた。一時のSymbianと同じで、プログラミングパラダイムが若干特殊であることを除けば、十分に普及するだけの基礎があるOSだと思う。
日本ではまだμITRONが強いのだろうか。基本的なAPI仕様がオープンとは言え、μITRONはPOSIXよりかなり限定的な規格であるし、日本の組み込み界がガラパゴスでないことを祈ろう…。
ちなみに、最近では組み込みと言ってもリアルタイム性の不要な分野も多く、組み込み経験者だからといってリアルタイムOS経験者とは限らない。
x264r2256
git-id : 486ff39f398401d126fbf0379287b1a7ca7fae6e
Author : Henrik Gramner
Date: Sun Jan 20 19:35:06 2013 +0100
Windows: Enable DEP and ASLR
Windows: DEPとASLRを有効化。
出力に影響なし。
いわゆるNXビットなどの対応。
x264r2255
git-id : 8da42b78154304ef194747a375a7e1ff3021d0a9
Author : Henrik Gramner
Date: Thu Jan 17 19:17:24 2013 +0100
x86inc: Set ELF hidden visibility for global constants
x86inc: グローバル定数に対しELFの隠し属性（非可視）を設定。
動作に影響なし。
x264r2254
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
x86inc: パブリックプレフィックスを持つC関数に対しcvisibleマクロを付加。
これは外部から見えるライブラリシンボルを定義することを可能にする。
Signed-off-by: Diego Biurrun
動作に影響なし。
x264r2253
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.
x86inc: program_nameをprivate_prefixに変更した。
libavと同期。
新しい名前はより説明的で、外部から見えるライブラリのシンボルに対し、
個別のパブリックプレフィックスを定義することを可能にする。
動作に影響なし。
x264r2252
git-id : a4e77598d2e1e55483bf0918f6ec2fda51ee9507
Author : Jason Garrett-Glaser
Date: Mon Jan 14 05:35:30 2013 -0800
x264.h: improve x264_encoder_reconfig documentation
x264.h: x264_encoder_reconfigのドキュメントを改善。
バイナリに影響なし。
x264r2251
git-id : ce9efeafaad38bc6795d4469c952af2d5bb75a84
Author : Henrik Gramner
Date: Sat Feb 16 19:36:50 2013 +0100
Cosmetics: stricter definition of parameterless functions
コスメティックス：パラメータなしの関数の定義をより厳密にした。
バイナリに影響なし。
コンパイル時にコードの問題を発見できるケースができる。普通は間違えない部分なのであまり意味はないが、商業プログラミングでは必須とされることも。
x264r2250
git-id : e403db4f9079811f5a1f9a1339e7c85b41800ca7
Author : Neil
Date: Mon Jan 28 10:47:38 2013 +0800
Update "Install and compile x264" in doc/regression_test.txt
doc/regression_test.txtの"Install and compile x264"を更新。
バイナリに影響なし。
svn時代の表記を修正しただけ。
x264r2249
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.
mbtree + open-gop + sync-lookaheadでの潜在的な非決定性を修正。
コードはキーフレーム解析がリストから1フレーム引くと仮定していた; これはopen-gopでは真でない。
x264r2248
git-id : 736d69b5875587b61c03aa45438e19ddba1f7035
Author : Anton Mitrofanov
Date: Mon Feb 25 19:28:19 2013 +0400
x86: don't use the red zone on win64
x86: win64上でレッドゾーンを使わないようにした。
ここでいうレッドゾーンとは、スタック（メモリ）の危険な領域、ということのようだ。そういえばx86-64におけるABIはWindowsとLinux/U*ix系で違うと聞いたような気もする。そこら辺の調整と思われる。
x264r2247
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.
x86-64: インターレースでのtrellisのasmを修正。
r2145でのレグレッション。
アセンブリは配列が[2][64]であると仮定していたが実際には[2][63]であった。
僅かな（〜0.1%）圧縮率の向上。
x264r2246
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.
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
git-id : bc13772e21d0e61dea6ba81d0d387604b5b360df
Author : Loren Merritt
Date: Tue Jan 8 21:30:57 2013 +0000
Bump dates to 2013
日付を2013に上げた。
x264r2244
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.
x86inc: tzcntのワークアラウンドをやめた。
yasmの要求バージョンを1.2.0に上げたため、不要になった。
x264r2243
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.
mbtree_propagateのAVX2/FMA3バージョン。
最初のAVX2関数のテスト。
AVX2サポートのためyasmのバージョンを1.2.0に上げた。
x264r2242
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.
x86inc: AVX関数でVEX符号化命令を使用。
AVX/AVX2/XOP/FMA3/FMA4関数では自動的に、VEX符号化バージョンが存在する全ての命令でVEX符号化を使用する。
この変更は、既存のコードをAVX2を使用するよう拡張するのをより簡単にする。
また、以前は存在しなかった命令群のAVXエミュレーションのサポートを追加。
x264r2241
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.
x86inc: REP_RETを自動的に有効化するようにした。
RETは分岐の直後であるかを調べるようになり、プログラマは条件を追っかける必要がなくなった。
REP_RETはまだ、それが分岐ターゲットである場合には手作業が必要であるが、それはとても稀である。
実装は大量の疑似ラベルを伴うが、stripするので大丈夫だ、問題ない。(｡+・`Θ・´)ｷﾘｯ
x264r2240
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).
x86inc: PROLOGUEでのスタックメモリの確保と再アラインメントのサポート。
8-bitループフィルタ関数でこれを使用することで、アラインされたスタックがなくとも（例えばx86-32 MSVCやICC 10.xなど）それらが使用可能となる。
一般ユーザにはあまり関係ない更新。対応環境の増加。
x264r2239
git-id : c69e2d02c4a2ee171b6b8ca0a2e1032213e561bc
Author : Henrik Gramner
Date: Mon Dec 17 22:15:02 2012 +0100
Update config.guess and config.sub
config.guessとconfig.subを更新。
x264r2238
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.
最初のフレームが非キーフレームを強制されている場合のクラッシュを修正。
これは明らかにユーザーの入力が悪いが、その場合でもx264はクラッシュすべきではない。
x264r2237
git-id : 593e8cc0b374aa7b20d3d961c57feb9bab508979
Author : Bernhard Rosenkr辰nzer
Date: Sun Dec 30 12:18:00 2012 -0800
Fix build on ARM with binutils >= 2.23.51.0.6
GAS doesn't seem to like spaces in vld1 anymore, so remove those.
binutils >= 2.23.51.0.6でのARMビルドの修正。
GASは最早、vld1内での空白を好まないようであるので、それらを削除。
ARMビルドにのみ影響。
x264r2236
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.
win32とBeOS上でのpthread_joinのエミュレーションを修正。
実際にはx264には影響しないが、より正しい。
x264r2235
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.
r2222でのタイポ（誤植）の修正。
levelテーブルで僅かに間違った値であった。
x264r2234
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
configure: -Wp,-D_FORTIFY_SOURCE=2でのgpacの検出を修正。
ビルドにのみ影響。
x264r2233
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.
Solaris: プロセッサ数を得るためsysconfを使用するようにした。
SolarisはCygwinと同じ値を正しく返すため、それを使う。
x264r2232
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.
lavf input: AVFrameを正しく確保するようにした。
AVFrameをavcodec_alloc_frame()で正しく確保するように。
フレームのextradataを解放しようとする新しめのlibavcodecでクラッシュを起こしていた。
x264r2231
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
ICLでx86_64向けにコンパイルされたlibx264.dllを使用する際のクラッシュを修正。
x264r2230
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.
仕様外のQP値となる潜在的な問題を修正。
r2228での潜在的なレグレッションを修正する。
x264r2229
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.
2-passモードでPPSのpic_init_qpの最適化を試みるようにした。
小さな圧縮率の改善; 極端なケースで最大〜0.5%。
小さなスライスサイズ（小さな解像度またはslice-max-size）であるほどより有用。
この変更は2-passのstatsファイル形式を変更することに注意。
x264r2228
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.
スライスヘッダのQP選択を改善。
一つ前のスライスの最後のマクロブロックではなく、各スライスの先頭のマクロブロックを使用。
最初のスライスに対しても妥当な初期QPを取るように。
僅かに圧縮率を改善。
x264r2227
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.
levelのdpbサイズ計算をより新しいH.264の仕様に適合するよう更新。
エンコード動作は実際には変わらないが、より正しくした。
高ビット深度と非4:2:0で警告メッセージが精密になったはず。
技術的には、x264_level_tを再定義するため、これはAPIバージョンの増加である。
X264_BUILD 129。
x264r2226
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
ffmpeg/vapoursynthの高ビット深度y4m拡張のサポートを追加。
x264r2225
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.
x86inc: 3dnow2を3dnowextに名前変更。
"3dnow2"より"3dnowext"という名前のほうが一般的。x264に影響なし。
x264r2224
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.
x86inc: program_nameをマクロが設定されていない場合のみ定義するようにした。
これはファイル外からの値のオーバーライドを可能にする。
x86inc.asmがx264以外で使用される場合に有用。
x264で使用する場合には特に影響なし。
x264r2223
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.
Appleの機器に対するARM NEON MRC CPUテストを無効化。
Apple A6 CPUはパフォーマンスカウンタをサポートしないため、このテストはクラッシュしていた。
Apple機器向けのビルドにのみ影響。
x264r2222
git-id : 6889f2cee49314aa380d4803991d645659efc01f
Author : Jason Garrett-Glaser
Date: Tue Nov 6 12:03:20 2012 -0800
Fix crash with no-scenecut + mbtree
no-scenecut + mbtreeでのクラッシュを修正。
x264r2221
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.
crf=0へのreconfigureを修正。
現在のところロスレスモードはストリーム途中で有効にできない。
libx264の修正。
x264r2220
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.
ICL上でのALIGNED_ARRAY_EMUマクロを修正。
ICLのプリプロセッサはこれを正しく扱わない。
この修正は0db2d9のlibavの修正と同様である。
「0db2d9」というのはGitのハッシュ。あるコミットを指すのに、リビジョン番号という概念は広く一般的ではあるが、Gitでは本来ハッシュで表す。このchangelogにもgit-idという形で書いているが、その先頭の数文字を表している。gitコマンド上、ハッシュは一意であれば必ずしも全てを書かなくてもよいため、省略表記されている。
x264r2219
git-id : 2f154ac1652000afe16140cb12c35d777f0c60c8
Author : Jason Martens
Date: Thu Sep 13 11:20:40 2012 -0700
Fix use of deprecated av_close_input_file call
非推奨となったav_close_input_file呼出の使用を修正。
x264r2218
git-id : 9fc00654018ff9f8a13dbe66785e31568a0c3229
Author : Brad Smith
Date: Wed Sep 26 14:13:27 2012 -0700
Fix pkg-config for dynamic vs static linking
静的・動的リンクに対してpkg-configを修正。
ビルドにのみ影響。
x264r2217
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.
OSにlibmがある場合にはconfigureスクリプトでlibmを設定するようにした。
この後の、別のconfigureのパッチで必要になる。
アイディアはlibpthreadから得た。
ビルドにのみ影響。
x264r2216
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.
mb_infoの改善: mb_info_updateを追加。
この機能はどのデコードされたマクロブロックが変わったを呼び出され側が知ることができるようにする。
X264_BUILD 128。
先のr2213のpskipの部分を再度修正。こちらが本来の目的だったのだろうか？いずれにせよcalling applicationとlibx264間のI/Fに対する追加機能で、x264cliを使っている場合には関係ない。
x264r2215
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.
sliced threadsでのmb_info_freeを修正。
x264はその使用が完全に終わる前にmb_infoを解放しようとしていた。
x264r2214
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.
nalu_processを改善。
入力フレームのopaqueなポインタを引数に追加。
これは複数同時並行なx264のエンコードを容易にする。
X264_BUILD 127。
要は、1つのプロセス内でlibx264で2本以上のエンコードを同時に行う時、どのエンコードの出力であるかをコールバック関数内で区別できるよう、引数を追加したということ。x264cliを使っている場合には関係ない。
x264r2213
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.
mb_infoの固定mb最適化を改善。
pskipのMVがゼロではない場合であっても高速なスキップを可能にする。
x264r2212
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
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.
OpenBSDに対するpthreadの取り扱いの特殊化をやめた。
以前は-pthreadを使うポリシーであったが、OpenBSDは今は-lpthreadを推奨している。
いずれにせよlibpthreadなのであり、ポリシーは-pthreadを使うのを止めるように変わった。
OpenBSD向けのビルドにのみ影響。pthreadが果たして、システムの一部（OSや標準ライブラリに含まれる）とみなすべきなのか、それとも追加機能のライブラリとみなすべきなのか、は（OpenBSDでの事情はともかく）何かと難しいところ。コンパイラが中途半端に取り込んでしまっているのも混乱の原因と言って良い。
ただpthreadの名前の通りPOSIX標準なのであるから、素人目にはU*ix界隈ではシステムの一部と見なされるべきな気がする。
そもそも、コンパイルオプションでマルチスレッドの明示が必要というのも、時代的にそろそろどうなのかという気もするが、まあ…オーバーヘッド量的にまだまだ無視できないのか。
x264r2210
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.
x86inc: YMM命令にvzeroupperを自動的に挿入。
libavからのバックポート。
x264r2209
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.
フレームの削除時にユーザーによって与えられたデーターをFree（解放）するように。
x264_encoder_closeを呼んだ際のメモリリークを廃絶する。
libx264に関する修正。x264cliを使っている場合にはプロセス自体が終了するのであまり関係ない。
x264r2208
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.
r2204をrevert（取り消し）。
皆さんのお気に召さないようなのでやめようと思います。
x264r2207
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.
subme<3での予測機のチェックを高速化。
早期スキップの効果を薄めていたタイポ（誤植）を修正。
比較的に予測が不能である分岐を回避。
タイポの修正により僅かに出力に変化あり。
Core i7で〜50サイクル速い。
x264r2206
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.
sub8x8パーティションが存在する場合にも8x8変換の解析を試行。
sub8x8パーティションをoffにし、試行し、ダメだったらonに戻す。
p4x4がonの場合に小さな圧縮率の向上（〜0.1-0.5%）
関連のコメントを更新。
x264r2205
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)
マクロブロック・ツリー(mbtree)で、パス間の解像度の変更をサポート。
量子化オフセットを再スケールするために基本的な分離バイリニアフィルターを実装。
構造はswscaleにインスパイアされているが、固定少数点数でなく浮動小数点数としている。
可能な限りというほどの最適化はされていないが、既に十分速い。
720pのゲームのレコーディングにおける圧縮（率）のペナルティの一例は
1パス目を720pで2パス目を480pとした場合: 〜-1.5%（同解像度比）
1パス目を480pで2パス目を720pとした場合: 〜-3%（同解像度比）
x264r2204
git-id : 8b535d9006d87e32c4ff939691b920da823ae85a
Author : Alexander Prikhodko
Date: Tue Jun 12 20:21:35 2012 +0300
Print elapsed time in encoding progress indicator
エンコード進捗インジケーターで経過時間を表示。
x264r2203
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.
レートコントロール予測のパラメータをキャップ。
比較的に不変な動画が長く続いた後の、VBVの予測ミスを限定的にする。
x264r2202
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.
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
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.
--fps 0でのクラッシュを修正。
幾つかの整数オーバーフローを修正し、入力パラメータをよくチェックするように。
また、demuxer情報の表示時の誤った型指定を修正した。
x264r2200
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.
スレッド化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
最終更新時間：2013年05月06日 17時12分59秒