このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。
x264-changelog-jp r2100-r2199
r2100-r2199のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。
前:x264-changelog-jp r2000-r2099 - 次:x264-changelog-jp r2200-r2299
x264r2199
git-id : ecfbf9d8025e39783bc4262dc1972ca742d8a993
Author : Anton Mitrofanov
Date: Fri May 4 17:18:12 2012 +0400
Add support for RGB formats in bit-depth conversion filter
ビット深度変換フィルタにRGBフォーマットのサポートを追加。
x264r2198 **STABLE**
git-id : 1c97f3570fba02f768fbf649b9f7d48beb720048
Author : Anton Mitrofanov
Date: Sat May 12 13:57:49 2012 +0400
Fix some bugs in mb_info code
mb_infoコードのバグを幾つか修正。
x264r2197
git-id : 69a0443e7d8ab032a7f3c3468a42177d5e64daa2
Author : Jason Garrett-Glaser
Date: Thu Mar 29 14:14:07 2012 -0700
Add mb_info API for signalling constant macroblocks
Some use-cases of x264 involve encoding video with large constant areas of the frame.
Sometimes, the caller knows which areas these are, and can tell x264.
This API lets the caller do this and adds internal tracking of modifications to macroblocks to avoid problems.
This is really only suitable without B-frames.
An example use-case would be using x264 for VNC.
固定のマクロブロックの符号化のためのmb_info APIを追加。
x264の幾つかのユースケースでは、フレームの大きな固定エリアのエンコードを含む。
時に、呼び出し側はどのエリアがそれであるかを知っており、x264に告げることが可能である。
このAPIは、呼び出し側がこれを行えるようにし、問題を避けるための、マクロブロックへの変更の内部的な追跡を追加する。
これはB-frameなしにのみ本当に適する。
VNCにx264を使用するのがユースケースのサンプルの一つだろう。
x264r2196
git-id : df6252cfed7c23fbe883456f4e0607a7f8e91ad8
Author : Henrik Gramner
Date: Sat Apr 7 00:40:09 2012 +0200
Faster chroma weight cost calculation
New assembly function with SSE2, SSSE3 and XOP implementations for calculating absolute sum of differences.
chroma weightのコスト計算を高速化。
absolute sum of differencesのためのSSE2, SSSE3とXOPでの新たなアセンブラ関数の実装。
x264r2195
git-id : cce88ebc9e517b0fa8735b81ac30b4e6a79c8154
Author : Lucien
Date: Sat Mar 31 13:42:49 2012 +0100
Add Level 5.2 support
Level 5.2のサポートを追加。
x264r2194
git-id : ee30c84e38b30896ffa6ddc417f3b4c281a86d1a
Author : Henrik Gramner
Date: Thu Apr 12 19:14:43 2012 +0200
Eradicate all mention of Extended Profile
x264 never supported it and never will because nobody uses it.
Extended Profileへの全ての言及を根絶。
x264はそれをサポートしたことは一切なく、誰も使わないので今後サポートすることもない。
x264r2193
git-id : 8ca49cc5c40813d8b98544989eb684e167b06aa0
Author : Anton Mitrofanov
Date: Tue Apr 3 21:46:52 2012 +0400
Fix disabling of mbtree when using 2pass encoding and zones
2passエンコードとzonesを使用時のmbtreeの無効化を修正。
x264r2192
git-id : 3691332c0b33a68f9d6f519edaa2b848ed34a38c
Author : Alexander Prikhodko
Date: Sat Mar 31 12:06:21 2012 +0300
configure: force select -mXX gcc option for i386/x86-64
Makes multilib compilation more convenient.
configure: i386/x86-64に対してgccオプションの-mXXの選択を強制。
multilibコンパイルをより便利に。
multilibとは所謂過去のMacにあったユニバーサルバイナリのようなもの。って説明を以前にもした気がする。
x264r2191
git-id : e1ccbf9bb3abdd25d3f0c76682926ec49f3f8001
Author : Rafa谷l Carr辿
Date: Sun Apr 15 21:20:14 2012 -0400
Update config.guess and config.sub
Adds support for a bunch of targets, including:
aarch64 (armv8)
arm-linux-androideabi
config.guessとconfig.subを更新。
以下を含む、多数のターゲットのサポートを追加:
aarch64 (armv8)
arm-linux-androideabi
ビルドにのみ影響。
x264r2190
git-id : f87619768dba73c1effbcfb08875d096575e079e
Author : Alexander Prikhodko
Date: Sat Mar 31 11:33:41 2012 +0300
configure: correct use of RC variable and add --extra-rcflags
configure: RC変数の使用を正し、--extra-rcflagsを追加した。
ビルドにのみ影響。
x264r2189
git-id : 35cf912671fddcb3e701bf667a75f77dd8b28264
Author : Steven Walters
Date: Wed Mar 28 21:15:04 2012 -0400
ICL/MSVS: Fix shared library generation and usage
MSVS requires exported variables to be declared with the DATA keyword, and requires that imported variables be declared with dllimport.
This does not fix x264 cli being unable to use a shared library built by ICL however.
ICL/MSVS: 共有ライブラリの生成と使用方法を修正。
MSVSはエクスポートされる変数がDATAキーワードで宣言される必要があり、インポートされる変数がdllimportで宣言される必要がある。
しかしながら、これはx264 cliが、ICLでビルドされた共有ライブラリを使用できないことを修正しない。
X264_BUILD 123。
共有ライブラリ（つまりDLL）でx264を使用するコードは、x264.hをincludeする前に #define X264_API_IMPORTSをすべきとされた。
x264r2188
git-id : 259a6e57ae25c71acc1669e0aefde7ffe7e235ec
Author : Kieran Kunhya
Date: Tue Mar 27 17:38:56 2012 +0100
Fix intra-refresh + hrd
intra-refresh + hrdを修正
x264r2187
git-id : e0351cdfeb45bf7f891eeb1dc475292154bb9d82
Author : Anton Mitrofanov
Date: Sun Mar 25 17:34:24 2012 +0400
Fix frame input colorspace check
フレーム入力色空間のチェックを修正。
x264r2186
git-id : 7392c8c31f791e9b4c10e4959f8715c8a8233d25
Author : Jason Garrett-Glaser
Date: Thu Mar 22 13:56:50 2012 -0700
Fix comment in deblock.c
The code does, in fact, handle CAVLC+8x8dct correctly already.
deblock.cのコメントを修正。
当該コードは、実際には、既にCAVLC+8x8dctを正しく扱っていた。
バイナリに影響なし。
x264r2185
git-id : 6979713216d792e44e3cbaeeba74b455e0a07c62
Author : Jason Garrett-Glaser
Date: Tue Mar 13 14:37:26 2012 -0700
Fix sliced-threads ratecontrol bug
Was using qp instead of qscale; could cause NANs (not to mention less accurate results).
sliced-threadsのレートコントロールのバグを修正。
qscaleの代わりにqpを使用していた; NANを引き起こし得た（言うまでもなく精度低下となる）。
x264r2184
git-id : 5c85e0a2b7992fcaab09418e3fcefc613cffc743
Author : Anton Mitrofanov
Date: Sun Mar 11 23:08:18 2012 -0700
Fix clobbering of mutex/cvs
Regression in r2183.
Bizarrely seemed to work on many platforms, but crashed on win64 and may have been slower.
Only affected sliced threads during encoding, but could cause crashes on x264 encoder close even without sliced threads.
mutex/cvsの破壊を修正。
r2183でのレグレッション。
おかしなことに多くのプラットフォームで動作していたようだが、win64ではクラッシュし、遅かったと思われる。
エンコードの最中ではsliced threadsにのみ影響していたが、sliced threadsを伴わないx264のエンコーダーの終了時（訳注：実際にはx264_encoder_close関数の呼び出しを指していると思われる）にクラッシュを引き起こし得た。
クラッシュが発生するのは終了時だが、修正は初期化時のシーケンス。
x264r2183
git-id : c522ad1fed167d0e985e4f9dcdee042473cf74db
Author : Jason Garrett-Glaser
Date: Fri Feb 24 13:34:39 2012 -0800
Sliced-threads: do hpel and deblock after returning
Lowers encoding latency around 14% in sliced threads mode with preset superfast.
Additionally, even if there is no waiting time between frames, this improves parallelism, because hpel+deblock are done during the (singlethreaded) lookahead.
For ease of debugging, dump-yuv forces all of the threads to wait and finish instead of setting b_full_recon.
Sliced-threads: hpelとdeblockをreturn後に行う。
superfastのプリセットでsliced threadsモードにおけるエンコーディングレイテンシを約14%低減する。
加えて、フレーム間で待ち時間がない場合においても、hpel+deblockは（シングルスレッドである）lookaheadの間隙に行われるため、これは並列度を高める。
デバッグの容易性のために、dump-yuvは、b_full_reconを設定する代わりに、全てのスレッドが待って完了するように強制する。
なんだか危なそうな変更だな〜と思ったら、案の定何かおかしいとかの話が出ているらしい。
x264r2182
git-id : 6a27a481d4c3508ce778a61a139a4734bb8126f7
Author : Jason Garrett-Glaser
Date: Fri Feb 24 13:16:52 2012 -0800
Add full-recon API option
Fully reconstruct frames even without dump-yuv.
full-recon APIのオプションを追加。
dump-yuvなしでもフレームを完全に再構築。
X264_BUILD 122。
libx264を使用するアプリケーションで、x264が想定する「デコーダーの出力」と同じものが得られる。例えば、エンコーダーであるx264では参照されないBフレームにデブロック処理を行う必要はないが、このオプションを使用することでデブロックされたフレームを得ることができる。
x264r2181
git-id : e856755d2a67f45249c24cb51aa38fc4fa192321
Author : Jason Garrett-Glaser
Date: Wed Feb 22 13:33:36 2012 -0800
x86inc: switch to amdnops
Recent AMD CPUs' instruction decoders choke horribly on extremely long nops (i.e. with 4 prefixes).
Won't affect much, since we don't use ALIGN much.
x86inc: amdnopsに変更。
最近のAMDのCPUの命令デコーダーは極端に長いnops（すなわち4つのプレフィックス）で酷く苦しくなってしまう。
ALIGNをそれほど使っていないので、大きく影響はしないだろう。
intelnop→amdnop。intelnopは非常に長いプレフィックスを許すとのこと。
逆アセンブルコードを眺める趣味のある人には、古くは90(h)と言えばわかるNOP。最近のCPUは命令のアラインのために、より長い無処理命令（0F(h) 1F(h)）を用意しているらしい。他にも「無処理」を表現するためにはいくつかの方法があり、推奨される方法がCPUにより異なる。これまではIntel式を使用していたが、それではAMDで苦しくなる事があるらしく、AMD式をyasmに指示するようになった。
x264r2180
git-id : 5a242c5862baaa4bd5829bd1b43dc11cf5c86344
Author : Jason Garrett-Glaser
Date: Tue Feb 14 16:54:03 2012 -0800
BMI1 decimate functions
Intel was nice enough to make tzcnt equal to "rep bsf", which is backwards-compatible.
This means we don't actually have to add new functions to make it work.
BMI1版のdecimate（間引き）関数。
tzcntをrep bsfと同等にし、下位互換としたIntelは、なかなかやりおる。
つまり、我々はこれを動かすために、実際には新たな関数を追加しなくてよいということだ。
x264r2179
git-id : ac31c59a98c6c690894670b9c9af2612f799d85b
Author : Jason Garrett-Glaser
Date: Tue Feb 14 15:07:10 2012 -0800
Minor asm changes
小さなasmの変更。
x264r2178
git-id : 83561e55dde06f3247aa9b99fa62ead38d7a406e
Author : Jason Garrett-Glaser
Date: Thu Feb 9 14:23:52 2012 -0800
Add row-reencoding support to VBV for improved accuracy
Extremely accurate, possibly 100% so (I can't get it to fail even with difficult VBVs).
Does not yet support rows split on slice boundaries (occurs often with slice-max-size/mbs).
Still inaccurate with sliced threads, but better than before.
精度の向上のためrow再エンコーディングのサポートをVBVに追加。
極端に精密であり、ほぼ100%である（困難なVBVであっても失敗させることができなかった）。
slice境界での行の分割はまだサポートしていない（slice-max-size/mbsでは頻繁に発生する）。
sliced threadsではまだ精密ではないが、以前よりはよい。
CBRの幻想で述べた「CBRモード」の精度が向上（ブレが低減）する。つまりnal-hrd=cbrで行われるパディングにも、無駄がとても少なくなるはず。VBVを使ったエンコードでより最適なビット配分が行われるようになる。
x264r2177
git-id : 5a69f8e105663497794d4bb4e58cf7baa5cd29cb
Author : Jason Garrett-Glaser
Date: Thu Feb 9 12:38:44 2012 -0800
Abstract bitstream backup/restore functions
Required for row re-encoding.
抽象的なビットストリームのバックアップ／レストア関数。
行の再エンコーディングに必要。
x264r2176
git-id : 037d123cf62c4af2dc13742b8606882b6d0d3d9e
Author : Anton Mitrofanov
Date: Thu Feb 9 15:27:53 2012 -0800
Add an small per-MB cost penalty for lowres
Helps avoid VBV predictors going nuts with very low-cost MBs.
One particular case this fixes is zero-cost MBs: adaptive quantization decreases the QP a lot, but (before this patch), no cost penalty gets factored in for this, because anything times zero is zero.
小さな、「MBごとのコスト」のペナルティをlowresに対し付加。
非常に低コストなMBに対してVBV予測機がおかしくなってしまう事を回避するのに役立つ。
これが修正する特徴的なケースの一つは、ゼロコストのMBである: adaptive quantization（訳注：AQ）がQPを大きく減少させても、ゼロに何をかけてもゼロであるため、（このパッチ以前では）コストのペナルティは織り込まれない。
エンコーディングアルゴリズムの核心の一つに触れるものなので、猫研で正しい解説ができるかは自信がない。そのため以下の解説が的を射ているかは全力で保証しない。
lowresでの解析段階ではMBのビットコストがゼロになってしまうが、実際のエンコーディングではゼロにならないケースが存在する。その場合、AQが「どこまでQP下げてもよいものか？」を判定するにあたって、ゼロに何を掛け算してもゼロであるがために、実際にはゼロコストでないのに、極端にQPを下げる結果となり、フレーム内でのビット配分がおかしくなってしまう。これを回避するため、lowresの段階でゼロコストとなったMBに対しても、予防的に小さなコストを計上しておくことで、適正なQPを選択しようというものだと思われる。
x264r2175
git-id : de5a0adca1a7d08b1233b317ec092dbf19263d2f
Author : Jason Garrett-Glaser
Date: Mon Feb 13 18:31:51 2012 -0800
Remove explicit run calculation from coeff_level_run
Not necessary with the CAVLC lookup table for zero run codes.
coeff_level_runから明示的なrunの計算を削除。
ゼロrunのコードに対してはCAVLCの表引きでは不要。
いわゆるlevel/run符号化の部分だけれど、勉強してないのでよくわからない。
x264r2174
git-id : 9f1ac3b36eb2666e9d2ec4b859f3b63f60827bf0
Author : Jason Garrett-Glaser
Date: Mon Feb 13 13:20:06 2012 -0800
Export PSNR/SSIM in x264 API
PSNR/SSIMをx264のAPIとしてエクスポート。
X264_BUILD 121。
libx264を使用するプログラムで、libx264で測定されたPSNR/SSIMを得ることができるようになった。
x264r2173
git-id : 7e85ec036df4290697239f5dc9f4a793313ceebc
Author : Ronald S. Bultje
Date: Wed Feb 8 13:10:31 2012 -0800
x86inc: support yasm -f win64
Not necessary for x264, as -m amd64 already does the right thing, but used by external users of x86inc.
x86inc: yasm -f win64のサポート。
-m amd64が適切に動くのでx264には不要であるが、x86incの他の使用者によって使用される。
x264としては影響なし。
x264r2172
git-id : 02c3d5ec58d6bcbc5e22715ae80d53d8556f3c8f
Author : Henrik Gramner
Date: Wed Feb 1 23:52:48 2012 +0100
Fix incorrect zero-extension assumptions in x86_64 asm
Some x264 asm assumed that the high 32 bits of registers containing "int" values would be zero.
This is almost always the case, and it seems to work with gcc, but it is *not* guaranteed by the ABI.
As a result, it breaks with some other compilers, like Clang, that take advantage of this in optimizations.
Accordingly, fix all x86 code by using intptr_t instead of int or using movsxd where neccessary.
Also add checkasm hack to detect when assembly functions incorrectly assumes that 32-bit integers are zero-extended to 64-bit.
x86_64のアセンブラコードにおける不正な「ゼロ拡張の仮定」を修正。
いくつかのx264のアセンブラコードはint値を含むレジスタの上位32bitがゼロであると仮定していた。
これは大凡常にそのとおりであるし、gccではうまくいくようだが、ABIによって保証されているわけでは*ない*。
結果として、これを最適化において利用する、Clangのような他のいくつかのコンパイラでは壊れてしまう。
従って、必要な部分ではmovsxdを使用、またはintの代わりにintptr_tを使用することで全てのx86コードを修正。
また、アセンブラ関数が32bit整数は64bitにゼロ拡張されると不正に仮定している場合に、それを検出するhackをcheckasmに追加。
これはBugfixではあるが、まだ十分であるかわかっていないために、stableとタグ付けされていないことに注意。
x264r2171
git-id : 01f7a333e6c6a6d91a7fe977b491a448ddf4c117
Author : Jason Garrett-Glaser
Date: Thu Feb 23 09:11:23 2012 -0800
Fix possible alignment crash when linking from MSVC
x264_cavlc_init needs to be stack-aligned now.
MSVCからリンクする場合のアラインメントによるクラッシュの可能性を修正。
x264_cavlc_initはスタックがアラインされている必要があるようになった。
x264r2170
git-id : b17c247178a24c218843639c3f46bcfde0edab0a
Author : Anton Mitrofanov
Date: Tue Feb 21 12:58:22 2012 -0800
Fix rare overflow in 10-bit intra_satd_x3_16x16 asm
10-bitのintra_satd_x3_16x16のアセンブラコードでの稀なオーバーフローを修正。
x264r2169
git-id : 1446fe7c47cf660d764b4cbf53694bc3df9b04de
Author : Steven Walters
Date: Sat Feb 11 22:56:43 2012 -0500
ICL: fix out of tree building and resource file usage on Windows
ICL: Windows上でのリソースファイルの使用方法とout of treeビルドを修正。
ビルドにのみ影響。
そう言えば今までICL（またはICC）の話を書いたことがない気がするが、ICLとはインテル製のコンパイラのことを指している。より強力な最適化がなされると言われるし、実際に作成物がGCCより速い事は多い。一方で他社製x86プロセッサでは遅くなるようになっている…という真しやかな噂もあったりする。速度の必要なマルチメディア界では、コンパイラコアとしてGCCの代わりに好んで使われることがある。クリティカルパスが殆どアセンブラ化されているx264では、それほど効用は大きくない。
インテルは64bit化にあたり当初はx64(x86-64、AMD64、Intel64、EM64T、IA-32e)ではなくIA-64を推しており、そのEPICと呼ばれるVLIWアーキテクチャでは、プロセッサの真価を発揮するためにコンパイラによる最適化が非常に重要だった（過去形じゃないだろうが）。そのためにコンパイラ技術を持っていることはインテルにとって重要だったりもする。
x264r2168
git-id : d3efb00abbedd2bbb70156bd989beefe06468116
Author : Oka Motofumi
Date: Mon Feb 6 06:07:34 2012 +0900
Add error handling for out-of-tree build
out-of-treeビルドにエラー処理を追加。
ビルドにのみ影響。
x264r2167
git-id : ec41b19edc67ee4eca09c0e3b37e6290844c5e1f
Author : Anton Mitrofanov
Date: Tue Mar 6 17:34:02 2012 +0400
Fix RGB colorspace input
BGR/BGRA input was correct.
RGB色空間入力を修正。
BGR/BGRA入力は正しかった。
一口にRGBと呼ばれるが、RGBデータは各色のデーターの並び順の違うケースがよくある。つまり、R→G→Bが通常期待される順序だが、B→G→Rという逆順のケースが存在する。x264はその両者を区別していたが、x264内部で扱いやすい様に並べ替える操作が間違っていたものを修正している。
Bが最初に来るというのは感覚的に奇妙に思えるが、そういったデーターの多くはWindowsのビットマップ形式がBが最初であることに由来しているのだろう。Windowsビットマップは他にも左下がスキャン開始点であるなどの特異な点がある。
なお、Gが最初に来るG→B→RやG→R→Bは筆者は目にしたことがないが、今回の修正を見ると、x264内部ではG→B→Rの順でデーターを保持している。これは恐らく、一般にYUVと呼ばれている形式が、もう少し正確に呼ぶならYCbCrと呼ばれる形式であり、Cbは「輝度に対する青の色差」、Crは「輝度に対する赤の色差」であることから来ている。メトリックが異なるので対応もへったくれもないわけではあるが、敢えて言うなら、Y(Y)→Green、U(Cb)→Blue、V(Cr)→Redと対応するということだろう。
x264r2166
git-id : 39a4c6fecaaa0d6cde8d89d31ef6cd1d25ab802b
Author : Jason Garrett-Glaser
Date: Mon Feb 13 16:40:32 2012 -0800
Fix interlaced + extremal slice-max-size
Broke if the first macroblock in the slice exceeded the set slice-max-size.
interlaced + 極値slice-max-sizeを修正。
スライス内の最初のマクロブロックが設定されたslice-max-sizeを超えた場合に壊れていた。
殆どないような極端なケースの修正。
x264r2165
git-id : 3f72c99a15a07511b758d9e94217223480865124
Author : Henrik Gramner
Date: Sun Feb 5 20:43:09 2012 +0100
Fix regression in r2141
Broke register preservation in x264_cpu_cpuid and x264_cpu_xgetbv.
Did not cause any problems.
r2141でのレグレッションを修正。
x264_cpu_cpuidとx264_cpu_xgetbvでレジスタ保存を壊していた。
（訳注：出力としては）何も問題はなかった。
x264r2164
git-id : da19765d723b06a1fa189478e9da61a1c18490f8
Author : Jason Garrett-Glaser
Date: Thu Jan 19 14:56:54 2012 -0800
TBM, AVX2, FMA3, BMI1, and BMI2 CPU detection support
TBM and BMI1 are supported by Trinity/Piledriver.
The others (and BMI1) will probably appear in Intel's upcoming Haswell.
Also update x86inc with AVX2 stuff.
TBM, AVX2, FMA3, BMI1, BMI2のCPU検出をサポート。
TBMとBMI1はTrinity/Piledriverによってサポートされる。
その他（とBMI1）は恐らくIntelの来るHaswellで登場するだろう。
また、x86incをAVX2関連で更新。
色々と新しい命令セットに対する準備。
x264r2163
git-id : efef20090a06a38f9d95755588d7830fb92a2a02
Author : Loren Merritt
Date: Fri Feb 3 06:27:18 2012 +0000
x86inc: add TAIL_CALL macro to abstract a common asm idiom
x86inc: 一般的なasmのイディオムを抽象化するためTAIL_CALLマクロを追加。
x264r2162
git-id : a7e6e1793b4d2b49c9449d767320c71daa855cb6
Author : Jason Garrett-Glaser
Date: Wed Jan 25 16:44:38 2012 -0800
Minor asm optimizations/cleanup
小さなasmの最適化・整理。
x264r2161
git-id : 56ba096141d16ffcbabd805e2d27014f62f0d722
Author : Jason Garrett-Glaser
Date: Tue Jan 24 19:03:58 2012 -0800
Clean up and optimize weightp, plus enable SSSE3 weight on SB/BDZ
Also remove unused AVX cruft.
weightpを整理し最適化、加えてSB/BDZでSSSE3の重み付けを有効化。
また、不使用のAVXのゴミコードを削除。
SD/BDZはSandyBridgeとBulldozerのことらしいですよ。
x264r2160
git-id : 961a278e0123eb662b46a6f136a48a43f6a2d427
Author : Jason Garrett-Glaser
Date: Mon Jan 23 18:57:58 2012 -0800
XOP frame_init_lowres
Covers both 8-bit and 16-bit, ~5-10% faster on Bulldozer.
XOP版のframe_init_lowres。
8-bitも16-bitもカバーし、Bulldozerで〜5-10%速い。
x264r2159
git-id : c5809994990df6c63b4250546844dc77181fee0f
Author : Jason Garrett-Glaser
Date: Tue Jan 17 15:25:10 2012 -0800
XOP 8x8 zigzags
Field: 35(mmx) ->16(xop) cycles
Frame: 32(ssse3)->20(xop) cycles
XOP版の8x8 zigzag。
Field: 35(mmx) ->16(xop) cycles
Frame: 32(ssse3)->20(xop) cycles
Fieldと言っているのはMBAFFによるインタレ処理の場合のこと。Frameと言っているのはインタレ処理ではない場合のこと。
x264r2158
git-id : 14dc11f7c52fa29576e0003c8c16857a78bf5fbf
Author : Jason Garrett-Glaser
Date: Mon Jan 23 15:09:38 2012 -0800
AVX 32-bit hpel_filter_h
Faster on Sandy Bridge.
Also add details on unsuccessful optimizations in these functions.
AVX版32-bitのhpel_fileter_h。
Sandy Bridgeで高速。
これらの関数内で成功しなかった最適化に関しても詳細を追加。
x264r2157
git-id : 2fcd0446b5d91ae52e143682c30000a49441e4a1
Author : Jason Garrett-Glaser
Date: Fri Jan 27 16:29:30 2012 -0800
x86inc: add high halfword register support
Might be useful in a few cases.
x86inc: 上位半ワードレジスタのサポートを追加。
いくらかのケースでは有用だろう。
x264r2156
git-id : 5c4b8484ea9aaabfb70523ba1f9c4d8343ad3221
Author : Ronald S. Bultje
Date: Wed Jan 25 13:53:59 2012 +0800
Change %ifdef directives to %if directives in *.asm files
This allows combining multiple conditionals in a single statement.
*.asmファイル内での%ifdefディレクティブを%ifディレクティブに変更。
これによって複数の条件を1つのステートメントに合わせることができる。
x264r2155
git-id : 1b558de42dc08a303c2faf79fc9999b48a876370
Author : Anton Mitrofanov
Date: Sun Jan 22 22:13:52 2012 +0400
Use TV range algorithm for bit-depth conversions
Such sources are more common, so better to be correct for the common case.
This also produces less error for the case of full range than the previous algorithm produced for the case of TV range.
ビット深度変換のアルゴリズムにTVレンジを使用。
そういった素材がより一般的なので、一般的なケースに対して正しくある方がより良い。
これはTVレンジのケースに対し（訳注：誤った処理として）以前のアルゴリズムが出力していたものよりも、フルレンジに対して（訳注：変更後のアルゴリズムが誤った処理を行なっても）比較的に誤差の小さな出力をする。
x264r2154
git-id : 83c371deba853a4ebb28739e868df86b3153fb3e
Author : Hii
Date: Wed Jan 25 16:29:22 2012 +0800
Bump dates to 2012
日付を2012年に上げた。
x264r2153
git-id : a2925c5a707e833c34fa0a64d497c02e6dcfe6e6
Author : Henrik Gramner
Date: Sat Jan 28 21:38:27 2012 +0100
Add Windows resource file
Displays version info in Windows Explorer.
Windowsのリソースファイルの追加。
Windows Explorerでバージョン情報を表示する。
x264r2152
git-id : 98ade832d053f6bfca4d0dd2ab0cd1c88531721d
Author : Sergey Radionov
Date: Mon Jan 16 13:22:44 2012 -0800
Fix win32 pthread_cond_signal
Isn't used by x264 currently, so didn't cause a problem.
Fix backported from libav.
win32のpthread_cond_signalの修正。
x264では現在使用されていないので、問題は起こしていなかった。
libavからのバックポート。
x264r2151
git-id : a3f44077dc238dea92c0894d352b5a8723b9201b
Author : Mans Rullgard
Date: Wed Feb 1 15:55:25 2012 -0800
ARM: align asm functions to 4 bytes.
Some linkers apparently fail to correctly align ARM functions when mixing with Thumb code.
ARM: asm関数を4byteにアライン。
いくつかのリンカはThumbコードと混ぜた場合にARMの関数を正しくアラインするのに失敗するようだ。
ARMにのみ影響。
x264r2150
git-id : d3a39c92f5c130cad6d45e9daffa5a2beb145ebb
Author : Anton Mitrofanov
Date: Sun Jan 22 13:00:23 2012 +0400
Fix normalization of colorspace when input is packed YUV 4:2:2
入力がpacked YUV 4:2:2である場合の色空間の平準化を修正。
x264r2149
git-id : 236763e39d8a756db0e8179745396ed88c1bfc2d
Author : Jason Garrett-Glaser
Date: Sat Jan 21 12:54:40 2012 -0800
Force keyint-min 1 with Blu-ray
Fixes an issue with referencing across I-frames that's prohibited in Blu-ray for some godforsaken reason.
Blu-rayでkeyint-min 1を強制。
何やらいたたまれない事情でBlu-rayでは禁止されている、Iフレームを超えて参照を行う問題を修正する。
Blu-rayの理不尽な仕様に対しては、もう怒りを通り越して哀れみになってしまったらしい。
この修正方法は本質的というよりはややworkaround的な気がするが、仕方ないところか。
x264r2148
git-id : 8a1189abd1355c4cf6f786fbc2a4b8c22f398710
Author : Oka Motofumi
Date: Sun Jan 29 20:34:41 2012 +0900
Fix crash in --demuxer y4m with unsupported colorspace
サポートしていない色空間での--demuxer y4mのクラッシュを修正。
x264r2147
git-id : 1ab0877a40417a2f4f26ff0356e8b02182d9d996
Author : Anton Mitrofanov
Date: Mon Jan 16 14:02:53 2012 -0800
Fix overread/possible crash with intra refresh + VBV
intra refresh + VBVでの過剰読み込み・潜在的なクラッシュを修正。
x264r2146
git-id : bcd41dbcaa4430b2118d9f6828c2b9635cf9d58d
Author : Loren Merritt
Date: Wed Jan 18 15:47:07 2012 -0800
Fix trellis 2 + subme >= 8
Trellis didn't return a boolean value as it was supposed to.
Regression in r2143-5.
trellis 2 + subme >= 8を修正。
Trellisは期待されるブール値を返していなかった。
r2143-r2145でのレグレッション。
x264r2145
git-id : 748fe16c1303b89d2a1d0378addd83fb4198f51a
revision : r2145
Author : Loren Merritt
Date: Fri Jan 6 15:53:29 2012 +0000
CABAC trellis opts part 4: x86_64 asm
Another 20% faster.
18k->12k codesize.
This patch series may have a large impact on encoding speed.
For example, 24% faster at --preset slower --crf 23 with 720p parkjoy.
Overall speed increase is proportional to the cost of trellis (which is proportional to bitrate, and much more with --trellis 2).
CABAC trellisの最適化パート4: x86_64のasm。
更に20%高速化。
コードサイズが18k->12kに。
この一連のパッチはエンコード速度に大きな影響があるだろう。
例えば、720pのparkjoy（訳注：有名なテストデータの名前）に--preset slower --crf 23で24%高速である。
全体の速度向上はtrellisのコストに比例する（ビットレートに比例し、--trellis 2ではよりその傾向となる）。
x264r2144
git-id : cfdb36ece729209631f7213506685ae733d7f5d4
Author : Loren Merritt
Date: Fri Jan 6 15:53:04 2012 +0000
CABAC trellis opts part 3: make some arrays non-static
CABAC trellisの最適化パート3: いくつかの配列をstaticでなくした。
x264r2143
git-id : 65bd12ae875a768a06b67ec6297dec18323e0768
Author : Loren Merritt
Date: Thu Dec 22 17:56:06 2011 +0000
CABAC trellis opts part 2: C optimizations
Hoist the branch on coef value out of the loop over node contexts.
Special cases for each possible coef value (0,1,n).
Special case for dc-only blocks.
Template the main loop for two common subsets of nodes, to avoid a bunch of branches about which nodes are live.
Use the nonupdating version of cabac_size_decision in more cases, and omit those bins from the node struct.
CABAC offsets are now compile-time constants.
Change TRELLIS_SCORE_MAX from a specific constant to anything negative, which is cheaper to test.
Remove dct_weight2_zigzag[], since trellis has to lookup zigzag[] anyway.
60% faster on x86_64.
25k->18k codesize.
CABAC trellisの最適化パート2: C言語の最適化。
ノードコンテキストをまたがるループから生ずる係数値における分岐を削除。
各、取りうる係数値(0,1,n)に対する特別ケース（の考慮）。
dc成分のみのブロックに対する特別ケース（の考慮）。
2つの汎的なノードのサブセットに対するメインループをテンプレート化し、どちらのノードが生きているかという分岐の山を回避。
非更新性のcabac_size_decisionをより多くのケースで使用し、ノードの構造体からそれらのバイナリを省略。
CABACオフセットはコンパイル時の定数となった。
TRELLIS_SCORE_MAXを特定の定数から、テストが簡単ななにがしかの負数とした。
trellisはいずれにせよzigzag[]を見なければならないため、dct_weight2_zigzag[]を削除。
x86_64で60%高速。
コードサイズが25k->18kに。
ペンギン様の英語がネイティブ感大な上に、技術的にも高度で、このコミットに関しては全く以て訳に自信がないと言っておこう…。相変わらずの超人っぷり。
x264r2142
git-id : e176619d010fc32c970c7ab7a769bbfbe2665f61
Author : Loren Merritt
Date: Thu Dec 22 17:55:06 2011 +0000
CABAC trellis opts part 1: minor change in output
Due to different tie-break order.
CABAC trellisの最適化パート1: 出力のちょっとした変更。
tie-break順の相違による。
ここでいうtie-breakとはなんですか。CABACのアルゴリズムを理解していないのでわからず。
x264r2141
git-id : 4e87f36a0e1a78242f04db611e06f80b6b38d900
Author : Henrik Gramner
Date: Sun Jan 8 04:14:10 2012 +0100
x86inc improvements for 64-bit
Add support for all x86-64 registers
Prefer caller-saved register over callee-saved on WIN64
Support up to 15 function arguments
x86incの64-bit向けの改善。
すべてのx86-64向けのレジスタのサポートを追加。
WIN64においてcallee-savedよりもcaller-savedなレジスタを優先するように。
最大15個までの関数引数をサポート。
caller/callee-saved registerとは、ABIの関数呼び出し規約で定められる破壊可・不可なレジスタの事。例えば普通eaxは関数戻り値のために使用されるので、caller-savedであり、破壊可能レジスタである。呼び出し側では関数呼び出しから戻ったらeaxの内容が書き換わっていることを予期すべきであり、逆に呼び出され側ではeaxは好きに上書き（破壊）していいレジスタである。逆にcallee-saved、つまり破壊不能レジスタでは、呼び出し側は関数呼び出しから戻ったら以前の値のままであると予期し、呼び出され側では、そのレジスタを使うのであればreturn時には元の値に戻さねばならない。
x264r2140
git-id : 84a06e611aff1267a720bf9552b3bcf263bd83b5
Author : Ilia Valiakhmetov
Date: Sun Jan 15 04:47:58 2012 -0600
High bit depth SSE2/AVX add8x8_idct8 and add16x16_idct8
From Google Code-In.
高ビット深度のSSE2/AVX版add8x8_idct8とadd16x16_idct8。
Google Code-Inより。
x264r2139
git-id : c605e3174410ba5c7d1d0a777082e2397734d637
Author : Edward Wang
Date: Wed Jan 4 15:35:54 2012 -0800
MMX/SSE2/AVX predict_8x16_p, high bit depth fdct8
From Google Code-In.
MMX/SSE2/AVX版のpredict_8x16_pと高ビット深度fdct8。
Google Code-Inより。
x264r2138
git-id : 6b06f6d3f7f800dca1a4ea154f54427d5b3cea2b
Author : Jason Garrett-Glaser
Date: Thu Dec 22 14:03:15 2011 -0800
XOP 8-bit fDCT
Use integer MAC for one of the SUMSUB passes. About a dozen cycles faster for 16x16.
XOP 8-bit fDCT。
SUMSUBのパスの一つに整数MACを使用。16x16に対して1ダースサイクルほど高速。
1ダースサイクル＝12クロック？MACはXOPで使える命令っぽいが詳しく調べる時間がなかった。
x264r2137
git-id : c4b54c83629bb92af6c4836a8859e9432dc7333a
Author : Cristian Militaru
Date: Wed Jan 4 12:38:08 2012 -0800
High bit depth intra_sad_x3_4x4
From Google Code-In.
高ビット深度のintra_sad_x3_4x4。
Google Code-Inより。
x264r2136
git-id : c032fbaa3801fb4cf8dd1dd95a6479ca5bd262e2
Author : Jason Garrett-Glaser
Date: Thu Dec 8 13:45:41 2011 -0800
Use a large LUT for CAVLC zero-run bit codes
Helps the most with trellis and RD, but also helps with bitstream writing.
Seems at worst neutral even in the extreme case of a CPU with small L2 cache (e.g. ARM Cortex A8).
CAVLCのzero-run bitのコードに大きなLUTを使用。
trellisとRDに最も役立つが、ビットストリームの書き込みにも役立つ。
L2キャッシュの小さいCPU（例えばARM Cortex A8）のような極端なケースでも、最悪、同等のようだ。
主題が書かれていないが、高速化したということ。
ちなみにARM Cortex A8は少し前のAndroid等に載っていたCPU。
x264r2135
git-id : ebb1429e2d24f57aa4ea75284386a15f2eab553e
Author : Matt Habel
Date: Fri Dec 16 23:16:09 2011 -0800
High bit depth intra_sad_x3_8x8, intra_satd_x3_4x4/8x8c/16x16
Also add an ACCUM macro to handle accumulator-induced add-or-swap more concisely.
高ビット深度のintra_sad_x3_8x8, intra_satd_x3_4x4/8x8c/16x16。
また、accumulator-induced add-or-swapをより簡潔に扱うためにACCUMマクロを追加。
主題が書かれていないが、アセンブラコードの追加。accumulator-inducedというのは、要は加算またはスワップの違いだけで同型な処理の記述をマクロでまとめたということらしい。
x264r2134
git-id : 6d921c5bdefae1a733a3a4c29d88ea15fcece76e
Author : Shitiz Garg
Date: Sat Dec 3 15:34:57 2011 -0800
MMX 10-bit predict_8x8c_h and predict_8x16c_h
From Google Code-In.
MMX版の10-bit predict_8x8c_hとpredict_8x16c_h。
Google Code-Inから。
x264r2133
git-id : 47cdaa9c3d8197d4deb711d9bcc4af869ef8a426
Author : Aaron Schmitz
Date: Wed Nov 30 00:15:45 2011 -0600
Some MBAFF x86 assembly functions.
deblock_chroma_420_mbaff, plus 422/422_intra_mbaff implemented using existing functions.
From Google Code-In.
いくつかのMBAFF x86アセンブラ関数。
deblock_chroma_420_mbaffに加え422/422_intra_mbaffが既存の関数を使用して実装された。
Google Code-Inから。
x264r2132
git-id : 027b05e0a22421e477847506a205a49b151ae5bf
Author : George Stephanos
Date: Thu Dec 1 16:53:45 2011 -0800
More ARM NEON assembly functions
predict_8x8_v, predict_4x4_dc_top, predict_8x8_ddl, predict_8x8_ddr, predict_8x8_vl, predict_8x8_vr, predict_8x8_hd, predict_8x8_hu.
From Google Code-In.
更なるARM NEONアセンブラ関数。
predict_8x8_v, predict_4x4_dc_top, predict_8x8_ddl, predict_8x8_ddr, predict_8x8_vl, predict_8x8_vr, predict_8x8_hd, predict_8x8_hu。
Google Code-Inから。
ARMにのみ影響。
x264r2131
git-id : 658a3585b74f77fd8f78588f3f39e0abefb104c4
Author : Ilia
Date: Mon Nov 28 05:20:09 2011 -0800
More 4:2:2 asm functions
High bit depth version of deblock_h_chroma_422.
Regular and high bit depth versions of deblock_h_chroma_intra_422.
High bit depth pixel_vsad.
SSE2 high bit depth and MMX 8-bit predict_8x8_vl.
Our first GCI patch this year!
更なる4:2:2のasm関数。
deblock_h_chroma_422の高ビット深度バージョン。
deblock_h_chroma_intra_422の標準・高ビット深度バージョン。
高ビット深度のpixel_vsad。
SSE2版の高ビット深度・MMX 8-bitのpredict_8x8_vl。
今年初のGCIパッチ！
x264r2130
git-id : 978abe065737089913feccffece483bc69a9e5b0
Author : Henrik Gramner
Date: Thu Dec 8 16:14:35 2011 +0100
SSE2 and SSSE3 versions of sub8x16_dct_dc
Also slightly faster sub8x8_dct_dc
sub8x16_dct_dcのSSE2とSSSE3バージョン。
また、sub8x8_dct_dcを僅かに高速化。
x264r2129
git-id : 61a78a1b417595c4b5d7ef6831692904a243a9fc
Author : Steven Walters
Date: Mon Dec 5 08:46:34 2011 -0500
Resize filter updates
Use AVPixFmtDescriptors to pick the most compatible x264 csp for any pixel format.
Fix deprecated use of av_set_int.
Now requires libavutil >= 51.19.0
リサイズフィルタのアップデート。
あらゆるピクセルフォーマットに対し、最もx264と互換性のある色空間を採用するためにAVPixFmtDescriptorを使用。
非推奨のav_set_intの使用を修正。
libavutil >= 51.19.0が必要となった。
x264r2128
git-id : bc6c98cf4f76c779c8c07f43aa97ac29b1150bc0
Author : Oka Motofumi
Date: Thu Jan 5 14:23:50 2012 -0800
Add out-of-tree build support
out-of-tree buildのサポートを追加。
ビルドにのみ影響。
out-of-tree buildとは、ソースコードのディレクトリツリー以外でのビルドを指す。つまり、これまでのビルドではx264のソースコードディレクトリで各種ビルドコマンドを打たなければならなかったものが、それ以外の「ビルド用ディレクトリ」を作成してそこで実行できるようになる。
例えばこれまではほぼ固定的に
- git clone
- cd x264
- configure
- make
としていたものが、
- git clone
- mkdir x264build
- cd x264build
- ../x264/configure
- make
とできるようになる。
メリットは様々だが、色々な設定でビルドを行う人には、それぞれの設定によるビルドをソースコードとは別に1つのディレクトリで管理できるため、何かと便利になる。例えば8bitと10bitの両方のビルドを、1つのソースのセットから、make distcleanすることなく、中間ファイルを削除せずにできる。
builderにとっては、ソースコードは基本的に触ることのない「材料」であり、中間ファイルやバイナリは「自分の作成物」である。その両者が切り離せると管理が楽だ。ビルドによって作成されるファイルが明確であるため、ビルド時に発生する問題の切り分けなどもしやすくなる。
x264r2127
git-id : f33c8cb0f8fff7a83100b3e9d15baba53c6f6a35
Author : Anton Mitrofanov
Date: Fri Dec 16 18:17:00 2011 +0400
Limit SSIM to 100db
Avoids floating point error for infinite SSIM (lossless).
SSIMを100dbに制限。
infinite SSIM (lossless)での浮動小数点エラーを回避する。
x264r2126
git-id : c0d698859c36be611d465f968762f042853be817
Author : Reynaldo H. Verdejo Pinochet
Date: Wed Jan 4 13:16:12 2012 -0300
Fix wrong conditional inclusion of inttypes.h
inttypes.h is required by encoder/ratecontrol.c for SCNxxx macros, and HAVE_STDINT_H does not imply having inttypes.h.
stdint.h is a subset of inttypes.h, but this isn't enough for x264.
This change fixes building x264 with Android's toolchain.
inttypes.hの間違った条件付きincludeを修正。
inttypes.hはencoder/ratecontrol.cでSCNxxxマクロのために必要だが、HAVE_STDINT_Hはinttypes.hがあることを暗示しない。
stdint.hはinttypes.hのサブセットであり、x264にとって十分ではない。
この変更はAndroidのツールチェインによるx264のビルドを修正する。
ビルドにのみ影響。
x264r2125
git-id : b081d179e741ceffee2217f6fda06779693dce56
Author : Anton Mitrofanov
Date: Wed Dec 21 11:08:56 2011 +0400
Fix crash with sliced threads and input height <= 112
sliced threadsで入力高さ<=112の場合のクラッシュを修正。
x264r2124
git-id : 64da5f9df46ac33a5a6b56ca1510d2082e6fbb62
Author : Phillip Blucas
Date: Mon Dec 19 17:43:41 2011 -0600
Fix loading custom 8x8 chroma quant matrices in 4:4:4
4:4:4でのカスタム8x8 chroma量子化マトリックスの読み込みを修正。
x264r2123
git-id : 4c08e42504af81cdbe5789a309e868ca8eda2c1f
Author : Anton Mitrofanov
Date: Fri Dec 16 01:48:07 2011 +0400
Fix PCM cost overflow
PCMコストのオーバーフローを修正。
x264r2122
git-id : 489a9b2d04c4828877930d2a9104ce93dde8cb85
Author : Anton Mitrofanov
Date: Fri Dec 9 01:54:22 2011 +0400
Fix overflow in 8-bit x86 vsad asm function
8-bit vsadのx86 asm版関数でのオーバーフローを修正。
x264r2121
git-id : c291a9d09263708e9d9f02e28f8442fdbe46bb06
Author : Anton Mitrofanov
Date: Wed Dec 7 19:14:52 2011 +0400
Fix crash in --fullhelp when compiled against recent ffmpeg
Don't assume all pixel formats have a description.
最近のffmpegに対してコンパイルされた場合の--fullhelpでのクラッシュを修正。
すべてのピクセルフォーマットに説明があるとは仮定しないようにした。
x264r2120
git-id : 0c7dab9c2a106ce3ee5d6ad7282afb49e1cc3954
revision : r2120
Author : Jason Garrett-Glaser
Date: Tue Dec 6 14:39:21 2011 -0800
Fix regression in r2118
Broke trellis with i16x16 macroblocks.
r2118のレグレッションを修正。
i16x16マクロブロックでのtrellisを壊していた。
x264r2119
git-id : 0637cd67cb245fce5ba190fa4b9c341319ea2b37
revision : r2119
Author : Jason Garrett-Glaser
Date: Wed Nov 30 13:02:12 2011 -0800
Modify MBAFF chroma deblock functions to handle U/V at the same time
Allows for more convenient asm implementations.
MBAFF chroma deblock関数をU/Vを同時に扱うよう変更。
より便利なasmの実装を可能にする。
x264r2118
git-id : 67f1fdc4d9c030568eac8cf9ab9d0bb249f520db
revision : r2118
Author : Jason Garrett-Glaser
Date: Thu Nov 10 16:16:13 2011 -0800
CABAC trellis optimizations: use SIMD quant
Significant speed increase, minor change in output due to rounding.
CABAC trellisの最適化: SIMDによる量子化を使用。
有意に速度が向上し、出力には丸めによる小さな違いが出る。
x264r2117
git-id : e047b3c475cd42b6647397a244e239ebfca53bf6
revision : r2117
Author : Steven Walters
Date: Sun Nov 6 09:48:30 2011 -0800
YUV range detection and support for x264CLI
Two new options: --input-range and --range.
--input-range forces the range of the input in case of misdetection; auto by default.
-- range sets the range of the output; x264cli will convert if necessary, TV by default.
--fullrange is now removed as a CLI option (but the libx264 API is unchanged).
YUVのレンジの検出とx264CLIでのサポート。
二つの新オプション: --input-rangeと--range。
--input-rangeは検出ミス時に入力のレンジを強制する; デフォルトでは自動。
--rangeは出力のレンジを設定する; x264cliは必要なら変換を行い、デフォルトではTV。
--fullrangeはCLIのオプションとしては削除された（ただしlibx264のAPIは変更なし）。
所謂TVスケール・PCスケールと呼ばれるYUV色空間のレンジが自動検出となった（たぶん）。強制するオプションは入力・出力で別に指定可能で、入出力が合わない場合には自動変換される。
x264r2116
git-id : 00df989cc06208050230756525633438d76b5a6a
revision : r2116
Author : Kieran Kunhya
Date: Fri Nov 4 20:09:13 2011 +0000
Pass through user data
ユーザーデータをパススルー。
X264_BUILD 120。
ここで言うユーザーデータは、libx264の仕組みの一部として、アプリケーション側のデータをフレームと一緒に持ち運べるようになっているものを指している。ライブラリの使い勝手の問題なので、一般ユーザーには関係ないと思っていい。
x264r2115
git-id : 04a0aeefd2f5b152c5dbca4a1c6569bd27c9f721
revision : r2115
Author : Jason Garrett-Glaser
Date: Thu Oct 27 14:05:56 2011 -0700
Remove unpredictable branch in CABAC dqp
CABAC dqp内の予測不能な分岐を削除。
x264r2114
git-id : 4185ee883b04d9cee57a64fdebd153830b7b27ba
revision : r2114
Author : Loren Merritt
Date: Sun Oct 23 23:15:11 2011 +0000
x86inc: AVX symmetry optimization
3-arg AVX ops with a memory arg can only have it in src2,
whereas SSE emulation of 3-arg prefers to have it in src1 (i.e. the move).
So, if the op is symmetric and the wrong one is memory, swap them.
Eliminates redundant moves in some cases when using 3-operand without AVX with memory arguments.
Also fix movss and movsd in some cases, and flag shufps correctly as float.
x86inc: AVX symmetry optimization（AVXの対称性による最適化）。
3-arg AVX ops（AVXの3オペランド命令）で、メモリ引数はsrc2にのみ取ることが可能だが、SSEによる3-argのエミュレーションではsrc1にあることが好ましい（つまりmove）。
そのため命令がsymmetricで、メモリがよろしくない側である場合に、それらをスワップする。
メモリ引数を取り、AVX以外で3オペランドを使用するようないくつかのケースで、冗長なmoveを削減。
また、幾つかのケースでのmovssとmovsdを修正し、shufpsに正しくfloatのフラグ付けをした。
命令の制約に合わせてオペランドを交換することでより最適な動作をするようにしたということ。
巷で今話題の掛け算の順番の問題（8x6=48と6x8=48は意味が違う、みたいな）ではないが、結果は同じでも順序が異なると動作が違う、ということがCPU内では起こりうる。具体的には、SIMD系命令では、8や6というデーターがメモリにあるかレジスタにあるかで速度、あるいは動作の可否そのものが決まることがある。このコミットはそのあたりの整合性をより最適にしたということ。
なお、文中のsymmetricとは、掛け算のように、与えるデーターの順序が異なっても結果が同じ、ということを指している。
x264r2113
git-id : cc129adcaaf5604f3d4fea9ebcb289403192a741
revision : r2113
Author : Anton Mitrofanov
Date: Tue Nov 29 13:45:13 2011 -0800
checkasm: shut up gcc warnings, fix some naming of functions in results
checkasm: gccの警告を黙らせ、結果中として幾つかの関数の名前を修正した。
checkasmの変更なので一般ユーザーに影響なし。
x264r2112
git-id : f0ccc98bb747b8ee0fe9329f4205cf382788bb89
revision : r2112
Author : Mans Rullgard
Date: Mon Nov 28 16:29:12 2011 -0800
checkasm: fix build on ARM
Because of how ALIGNED_ARRAY_16 is defined on ARM, array initialisers cannot be used here. Use memset() instead.
checkasm: ARM上でのビルドを修正。
ARM上でのALIGNED_ARRAY_16の定義方法が原因で、配列の初期化子が使用不能である。代わりにmemset()を使用。
checkasmの変更なので一般ユーザーに影響なし。
x264r2111
git-id : d8d8e756b1fee72b4771761d6aa4cfb31edc0b67
revision : r2111
Author : Anton Mitrofanov
Date: Sat Nov 12 01:31:49 2011 +0400
Improve makefile rules
Remove the need for "make clean" after most reconfigures.
makefileのルールを改善。
ほとんどの再設定の後で"make clean"が不要に。
makefileの改善なのでビルドしない人には影響なし。
x264r2110
git-id : e6d33a931c08918e78dcae97e4d80d0c3411bf2c
revision : r2110
Author : Anton Mitrofanov
Date: Sat Nov 12 00:47:48 2011 +0400
Mark some local functions as static, cosmetics
いくつかのローカル関数をstaticにするコスメティックス。
x264r2109
git-id : e0c11dc6e283569606aaa97767401c6a13c2529d
revision : r2109
Author : Anton Mitrofanov
Date: Fri Nov 11 23:19:02 2011 +0400
Fix crash if timecode file opening fails
タイムコードファイルのオープンが失敗した場合のクラッシュを修正。
x264r2108
git-id : a14db080c3fdba4cadc38152a292bb1fa216d50e
revision : r2108
Author : Fabian Greffrath
Date: Fri Nov 11 13:25:43 2011 -0800
Configure: force PIC for shared build on PARISC and MIPS
Configure: PARISCとMIPS上の共有ビルドではPICを強制。
ビルドにのみ影響。
x264r2107
git-id : 6a0bd421bf5fd006012ddcd1be2072a8736b2d27
revision : r2107
Author : Anton Mitrofanov
Date: Sat Oct 22 19:41:07 2011 +0400
Improve yasm version check
Previous check allowed certain earlier versions that weren't fully compatible.
yasmのバージョンチェックを改善。
以前のチェックは、完全な互換のない、特定の若いバージョンを許していた。
ビルドにのみ影響。
x264r2106
git-id : 07efeb45db224b7757880d4d63bb549fb454f6db
Author : Jason Garrett-Glaser
Date: Tue Oct 18 14:30:26 2011 -0700
Add fenc prefetching to adaptive quant
Many fewer cache misses, faster adaptive quant.
fencのプリフェッチをadaptive quant（訳注：AQ）に追加。
キャッシュミスの回数を大きく低下、adaptive quantを高速化。
x264r2105
git-id : 81a99842b76834c11a46438f354d7f2a9e89752a
Author : Jason Garrett-Glaser
Date: Tue Oct 18 14:14:03 2011 -0700
Split prefetch_fenc between colorspaces
Add 4:2:2 version.
色空間でprefetch_fencを分割。
4:2:2バージョンを追加。
x264r2104
git-id : 9f872e137c16e8ee0a46d8ca00ac5d670c219d5f
Author : Jason Garrett-Glaser
Date: Tue Oct 11 17:04:32 2011 -0700
Some more 4:2:2 x86 asm
coeff_last8, coeff_level_run8, var2_8x16, predict_8x16c_dc, satd_4x16, intra_mbcmp_8x16c_x3, deblock_h_chroma_422
幾つかの更なる4:2:2 asm。
coeff_last8, coeff_level_run8, var2_8x16, predict_8x16c_dc, satd_4x16, intra_mbcmp_8x16c_x3, deblock_h_chroma_422。
x264r2103
git-id : f52aa86c184d69b4e97b0f63f5f27166b19aa280
Author : Loren Merritt
Date: Tue Oct 11 18:12:43 2011 +0000
Remove obsolete versions of intra_mbcmp_x3
intra_mbcmp_x3 is unnecessary if x9 exists (SSSE3 and onwards).
intra_mbcmp_x3の廃れたバージョンを削除。
intra_mbcmp_x3はx9が存在すれば不要である（SSSE3以降）。
x264r2102
git-id : 2f0384dcd68bb85f98fb566b70b863b40082c83e
Author : Loren Merritt
Date: Mon Oct 10 05:42:36 2011 +0000
SSSE3/SSE4/AVX 9-way fully merged i8x8 analysis (sa8d_x9)
x86_64 only for now, due to register requirements (like sa8d_x3).
i8x8 analysis cycles (per partition):
penryn sandybridge bulldozer
616->600 482->374 418->356 preset=faster
892->632 725->387 598->373 preset=medium
948->650 789->409 673->383 preset=slower
SSSE3/SSE4/AVX版の9-way完全統合i8x8解析(sa8d_x9)。
今のところx86_64のみ、というのは（sa8d_x3と同様に）レジスタの要件による。
i8x8解析のサイクル数（パーティション毎）：
penryn sandybridge bulldozer
616->600 482->374 418->356 preset=faster
892->632 725->387 598->373 preset=medium
948->650 789->409 673->383 preset=slower
x264r2101
git-id : 46d1f3ab24e8aead7ccb3f89a382e7c92721ba96
Author : Jason Garrett-Glaser
Date: Fri Sep 30 19:09:19 2011 -0700
SSSE3/SSE4/AVX 9-way fully merged i8x8 analysis (sad_x9)
~3 times faster than current analysis, plus (like intra_sad_x9_4x4) analyzes all modes without shortcuts.
SSSE3/SSE4/AVX版の9-way完全統合i8x8解析(sad_x9)。
現在の解析よりも〜3倍高速であることに加え、（intra_sad_x9_4x4のように）全てのモードをショートカットなしで解析する。
少し前に同様の高速化が行われていたものの適用対象が広がった。
x264r2100
git-id : 077d4532c9d9c7914e31ef9250096cc379042bcb
Author : Loren Merritt
Date: Wed Oct 5 13:29:21 2011 -0700
Merge i4x4 prediction with intra_mbcmp_x9_4x4
Avoids a redundant prediction after analysis.
i4x4予測をintra_mbcmp_x9_4x4に統合。
解析後の冗長な予測を回避。
前:x264-changelog-jp r2000-r2099 - 次:x264-changelog-jp r2200-r2299
最終更新時間：2012年05月30日 01時30分22秒