このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。 !!!x264-changelog-jp r2100-r2199 r2100-r2199のchangelogの日本語訳。その他のリビジョンと注意事項については[[x264-changelog-jp]]へどうぞ。 前:[[x264-changelog-jp r2000-r2099]] - 次:[[x264-changelog-jp r2200-r2299]] !x264r2199 {{bq 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 }} {{bq ビット深度変換フィルタにRGBフォーマットのサポートを追加。 }} !x264r2198 **STABLE** //STABLE {{bq git-id : 1c97f3570fba02f768fbf649b9f7d48beb720048 Author : Anton Mitrofanov Date: Sat May 12 13:57:49 2012 +0400 Fix some bugs in mb_info code }} {{bq mb_infoコードのバグを幾つか修正。 }} !x264r2197 //HEAD {{bq 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. }} {{bq 固定のマクロブロックの符号化のためのmb_info APIを追加。 x264の幾つかのユースケースでは、フレームの大きな固定エリアのエンコードを含む。 時に、呼び出し側はどのエリアがそれであるかを知っており、x264に告げることが可能である。 このAPIは、呼び出し側がこれを行えるようにし、問題を避けるための、マクロブロックへの変更の内部的な追跡を追加する。 これはB-frameなしにのみ本当に適する。 VNCにx264を使用するのがユースケースのサンプルの一つだろう。 }} !x264r2196 {{bq 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. }} {{bq chroma weightのコスト計算を高速化。 absolute sum of differencesのためのSSE2, SSSE3とXOPでの新たなアセンブラ関数の実装。 }} !x264r2195 {{bq git-id : cce88ebc9e517b0fa8735b81ac30b4e6a79c8154 Author : Lucien Date: Sat Mar 31 13:42:49 2012 +0100 Add Level 5.2 support }} {{bq Level 5.2のサポートを追加。 }} !x264r2194 {{bq 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. }} {{bq Extended Profileへの全ての言及を根絶。 x264はそれをサポートしたことは一切なく、誰も使わないので今後サポートすることもない。 }} !x264r2193 {{bq 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 }} {{bq 2passエンコードとzonesを使用時のmbtreeの無効化を修正。 }} !x264r2192 {{bq 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. }} {{bq configure: i386/x86-64に対してgccオプションの-mXXの選択を強制。 multilibコンパイルをより便利に。 }} multilibとは所謂過去のMacにあったユニバーサルバイナリのようなもの。って説明を以前にもした気がする。 !x264r2191 {{bq 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 }} {{bq config.guessとconfig.subを更新。 以下を含む、多数のターゲットのサポートを追加: aarch64 (armv8) arm-linux-androideabi }} ビルドにのみ影響。 !x264r2190 {{bq 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 }} {{bq configure: RC変数の使用を正し、--extra-rcflagsを追加した。 }} ビルドにのみ影響。 !x264r2189 //STABLE {{bq 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. }} {{bq ICL/MSVS: 共有ライブラリの生成と使用方法を修正。 MSVSはエクスポートされる変数がDATAキーワードで宣言される必要があり、インポートされる変数がdllimportで宣言される必要がある。 しかしながら、これはx264 cliが、ICLでビルドされた共有ライブラリを使用できないことを修正しない。 }} X264_BUILD 123。 共有ライブラリ(つまりDLL)でx264を使用するコードは、x264.hをincludeする前に #define X264_API_IMPORTSをすべきとされた。 !x264r2188 {{bq git-id : 259a6e57ae25c71acc1669e0aefde7ffe7e235ec Author : Kieran Kunhya Date: Tue Mar 27 17:38:56 2012 +0100 Fix intra-refresh + hrd }} {{bq intra-refresh + hrdを修正 }} !x264r2187 {{bq git-id : e0351cdfeb45bf7f891eeb1dc475292154bb9d82 Author : Anton Mitrofanov Date: Sun Mar 25 17:34:24 2012 +0400 Fix frame input colorspace check }} {{bq フレーム入力色空間のチェックを修正。 }} !x264r2186 {{bq 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. }} {{bq deblock.cのコメントを修正。 当該コードは、実際には、既にCAVLC+8x8dctを正しく扱っていた。 }} バイナリに影響なし。 !x264r2185 {{bq 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). }} {{bq sliced-threadsのレートコントロールのバグを修正。 qscaleの代わりにqpを使用していた; NANを引き起こし得た(言うまでもなく精度低下となる)。 }} !x264r2184 //HOTFIX {{bq 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. }} {{bq mutex/cvsの破壊を修正。 r2183でのレグレッション。 おかしなことに多くのプラットフォームで動作していたようだが、win64ではクラッシュし、遅かったと思われる。 エンコードの最中ではsliced threadsにのみ影響していたが、sliced threadsを伴わないx264のエンコーダーの終了時(訳注:実際にはx264_encoder_close関数の呼び出しを指していると思われる)にクラッシュを引き起こし得た。 }} クラッシュが発生するのは終了時だが、修正は初期化時のシーケンス。 !x264r2183 //HEAD {{bq 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. }} {{bq Sliced-threads: hpelとdeblockをreturn後に行う。 superfastのプリセットでsliced threadsモードにおけるエンコーディングレイテンシを約14%低減する。 加えて、フレーム間で待ち時間がない場合においても、hpel+deblockは(シングルスレッドである)lookaheadの間隙に行われるため、これは並列度を高める。 デバッグの容易性のために、dump-yuvは、b_full_reconを設定する代わりに、全てのスレッドが待って完了するように強制する。 }} なんだか危なそうな変更だな〜と思ったら、案の定何かおかしいとかの話が出ているらしい。 !x264r2182 {{bq 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. }} {{bq full-recon APIのオプションを追加。 dump-yuvなしでもフレームを完全に再構築。 }} X264_BUILD 122。 libx264を使用するアプリケーションで、x264が想定する「デコーダーの出力」と同じものが得られる。 例えば、エンコーダーであるx264では参照されないBフレームにデブロック処理を行う必要はないが、このオプションを使用することでデブロックされたフレームを得ることができる。 !x264r2181 {{bq 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. }} {{bq x86inc: amdnopsに変更。 最近のAMDのCPUの命令デコーダーは極端に長いnops(すなわち4つのプレフィックス)で酷く苦しくなってしまう。 ALIGNをそれほど使っていないので、大きく影響はしないだろう。 }} intelnop→amdnop。 intelnopは非常に長いプレフィックスを許すとのこと。 逆アセンブルコードを眺める趣味のある人には、古くは90(h)と言えばわかるNOP。 最近のCPUは命令のアラインのために、より長い無処理命令(0F(h) 1F(h))を用意しているらしい。 他にも「無処理」を表現するためにはいくつかの方法があり、推奨される方法がCPUにより異なる。 これまではIntel式を使用していたが、それではAMDで苦しくなる事があるらしく、AMD式をyasmに指示するようになった。 !x264r2180 {{bq 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. }} {{bq BMI1版のdecimate(間引き)関数。 tzcntをrep bsfと同等にし、下位互換としたIntelは、なかなかやりおる。 つまり、我々はこれを動かすために、実際には新たな関数を追加しなくてよいということだ。 }} !x264r2179 {{bq git-id : ac31c59a98c6c690894670b9c9af2612f799d85b Author : Jason Garrett-Glaser Date: Tue Feb 14 15:07:10 2012 -0800 Minor asm changes }} {{bq 小さなasmの変更。 }} !x264r2178 {{bq 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. }} {{bq 精度の向上のためrow再エンコーディングのサポートをVBVに追加。 極端に精密であり、ほぼ100%である(困難なVBVであっても失敗させることができなかった)。 slice境界での行の分割はまだサポートしていない(slice-max-size/mbsでは頻繁に発生する)。 sliced threadsではまだ精密ではないが、以前よりはよい。 }} [[CBRの幻想]]で述べた「CBRモード」の精度が向上(ブレが低減)する。 つまりnal-hrd=cbrで行われるパディングにも、無駄がとても少なくなるはず。 VBVを使ったエンコードでより最適なビット配分が行われるようになる。 !x264r2177 {{bq 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. }} {{bq 抽象的なビットストリームのバックアップ/レストア関数。 行の再エンコーディングに必要。 }} !x264r2176 {{bq 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. }} {{bq 小さな、「MBごとのコスト」のペナルティをlowresに対し付加。 非常に低コストなMBに対してVBV予測機がおかしくなってしまう事を回避するのに役立つ。 これが修正する特徴的なケースの一つは、ゼロコストのMBである: adaptive quantization(訳注:AQ)がQPを大きく減少させても、ゼロに何をかけてもゼロであるため、(このパッチ以前では)コストのペナルティは織り込まれない。 }} エンコーディングアルゴリズムの核心の一つに触れるものなので、猫研で正しい解説ができるかは自信がない。 そのため以下の解説が的を射ているかは'''全力で'''''保証しない''。 lowresでの解析段階ではMBのビットコストがゼロになってしまうが、 実際のエンコーディングではゼロにならないケースが存在する。 その場合、AQが「どこまでQP下げてもよいものか?」を判定するにあたって、 ゼロに何を掛け算してもゼロであるがために、実際にはゼロコストでないのに、 極端にQPを下げる結果となり、フレーム内でのビット配分がおかしくなってしまう。 これを回避するため、lowresの段階でゼロコストとなったMBに対しても、 予防的に小さなコストを計上しておくことで、適正なQPを選択しようというものだと思われる。 !x264r2175 {{bq 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. }} {{bq coeff_level_runから明示的なrunの計算を削除。 ゼロrunのコードに対してはCAVLCの表引きでは不要。 }} いわゆるlevel/run符号化の部分だけれど、勉強してないのでよくわからない。 !x264r2174 {{bq git-id : 9f1ac3b36eb2666e9d2ec4b859f3b63f60827bf0 Author : Jason Garrett-Glaser Date: Mon Feb 13 13:20:06 2012 -0800 Export PSNR/SSIM in x264 API }} {{bq PSNR/SSIMをx264のAPIとしてエクスポート。 }} X264_BUILD 121。 libx264を使用するプログラムで、libx264で測定されたPSNR/SSIMを得ることができるようになった。 !x264r2173 {{bq 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. }} {{bq x86inc: yasm -f win64のサポート。 -m amd64が適切に動くのでx264には不要であるが、x86incの他の使用者によって使用される。 }} x264としては影響なし。 !x264r2172 {{bq 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. }} {{bq x86_64のアセンブラコードにおける不正な「ゼロ拡張の仮定」を修正。 いくつかのx264のアセンブラコードはint値を含むレジスタの上位32bitがゼロであると仮定していた。 これは大凡常にそのとおりであるし、gccではうまくいくようだが、ABIによって保証されているわけでは*ない*。 結果として、これを最適化において利用する、Clangのような他のいくつかのコンパイラでは壊れてしまう。 従って、必要な部分ではmovsxdを使用、またはintの代わりにintptr_tを使用することで全てのx86コードを修正。 また、アセンブラ関数が32bit整数は64bitにゼロ拡張されると不正に仮定している場合に、それを検出するhackをcheckasmに追加。 }} これはBugfixではあるが、まだ十分であるかわかっていないために、stableとタグ付けされていないことに注意。 !x264r2171 //STABLE {{bq 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. }} {{bq MSVCからリンクする場合のアラインメントによるクラッシュの可能性を修正。 x264_cavlc_initはスタックがアラインされている必要があるようになった。 }} !x264r2170 {{bq 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 }} {{bq 10-bitのintra_satd_x3_16x16のアセンブラコードでの稀なオーバーフローを修正。 }} !x264r2169 {{bq 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 }} {{bq 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 {{bq git-id : d3efb00abbedd2bbb70156bd989beefe06468116 Author : Oka Motofumi Date: Mon Feb 6 06:07:34 2012 +0900 Add error handling for out-of-tree build }} {{bq out-of-treeビルドにエラー処理を追加。 }} ビルドにのみ影響。 !x264r2167 {{bq git-id : ec41b19edc67ee4eca09c0e3b37e6290844c5e1f Author : Anton Mitrofanov Date: Tue Mar 6 17:34:02 2012 +0400 Fix RGB colorspace input BGR/BGRA input was correct. }} {{bq 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 {{bq 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. }} {{bq interlaced + 極値slice-max-sizeを修正。 スライス内の最初のマクロブロックが設定されたslice-max-sizeを超えた場合に壊れていた。 }} 殆どないような極端なケースの修正。 !x264r2165 {{bq 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. }} {{bq r2141でのレグレッションを修正。 x264_cpu_cpuidとx264_cpu_xgetbvでレジスタ保存を壊していた。 (訳注:出力としては)何も問題はなかった。 }} !x264r2164 //HEAD {{bq 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. }} {{bq TBM, AVX2, FMA3, BMI1, BMI2のCPU検出をサポート。 TBMとBMI1はTrinity/Piledriverによってサポートされる。 その他(とBMI1)は恐らくIntelの来るHaswellで登場するだろう。 また、x86incをAVX2関連で更新。 }} 色々と新しい命令セットに対する準備。 !x264r2163 {{bq 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 }} {{bq x86inc: 一般的なasmのイディオムを抽象化するためTAIL_CALLマクロを追加。 }} !x264r2162 {{bq git-id : a7e6e1793b4d2b49c9449d767320c71daa855cb6 Author : Jason Garrett-Glaser Date: Wed Jan 25 16:44:38 2012 -0800 Minor asm optimizations/cleanup }} {{bq 小さなasmの最適化・整理。 }} !x264r2161 {{bq 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. }} {{bq weightpを整理し最適化、加えてSB/BDZでSSSE3の重み付けを有効化。 また、不使用のAVXのゴミコードを削除。 }} SD/BDZはSandyBridgeとBulldozerのことらしいですよ。 !x264r2160 {{bq 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. }} {{bq XOP版のframe_init_lowres。 8-bitも16-bitもカバーし、Bulldozerで〜5-10%速い。 }} !x264r2159 {{bq 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 }} {{bq XOP版の8x8 zigzag。 Field: 35(mmx) ->16(xop) cycles Frame: 32(ssse3)->20(xop) cycles }} Fieldと言っているのはMBAFFによるインタレ処理の場合のこと。 Frameと言っているのはインタレ処理ではない場合のこと。 !x264r2158 {{bq 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. }} {{bq AVX版32-bitのhpel_fileter_h。 Sandy Bridgeで高速。 これらの関数内で成功しなかった最適化に関しても詳細を追加。 }} !x264r2157 {{bq 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. }} {{bq x86inc: 上位半ワードレジスタのサポートを追加。 いくらかのケースでは有用だろう。 }} !x264r2156 {{bq 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. }} {{bq *.asmファイル内での%ifdefディレクティブを%ifディレクティブに変更。 これによって複数の条件を1つのステートメントに合わせることができる。 }} !x264r2155 {{bq 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. }} {{bq ビット深度変換のアルゴリズムにTVレンジを使用。 そういった素材がより一般的なので、一般的なケースに対して正しくある方がより良い。 これはTVレンジのケースに対し(訳注:誤った処理として)以前のアルゴリズムが出力していたものよりも、フルレンジに対して(訳注:変更後のアルゴリズムが誤った処理を行なっても)比較的に誤差の小さな出力をする。 }} !x264r2154 {{bq git-id : 83c371deba853a4ebb28739e868df86b3153fb3e Author : Hii Date: Wed Jan 25 16:29:22 2012 +0800 Bump dates to 2012 }} {{bq 日付を2012年に上げた。 }} !x264r2153 {{bq 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. }} {{bq Windowsのリソースファイルの追加。 Windows Explorerでバージョン情報を表示する。 }} !x264r2152 {{bq 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. }} {{bq win32のpthread_cond_signalの修正。 x264では現在使用されていないので、問題は起こしていなかった。 libavからのバックポート。 }} !x264r2151 //STABLE {{bq 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. }} {{bq ARM: asm関数を4byteにアライン。 いくつかのリンカはThumbコードと混ぜた場合にARMの関数を正しくアラインするのに失敗するようだ。 }} ARMにのみ影響。 !x264r2150 {{bq 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 }} {{bq 入力がpacked YUV 4:2:2である場合の色空間の平準化を修正。 }} !x264r2149 {{bq 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. }} {{bq Blu-rayでkeyint-min 1を強制。 何やらいたたまれない事情でBlu-rayでは禁止されている、Iフレームを超えて参照を行う問題を修正する。 }} Blu-rayの理不尽な仕様に対しては、もう怒りを通り越して哀れみになってしまったらしい。 この修正方法は本質的というよりはややworkaround的な気がするが、仕方ないところか。 !x264r2148 {{bq git-id : 8a1189abd1355c4cf6f786fbc2a4b8c22f398710 Author : Oka Motofumi Date: Sun Jan 29 20:34:41 2012 +0900 Fix crash in --demuxer y4m with unsupported colorspace }} {{bq サポートしていない色空間での--demuxer y4mのクラッシュを修正。 }} !x264r2147 {{bq git-id : 1ab0877a40417a2f4f26ff0356e8b02182d9d996 Author : Anton Mitrofanov Date: Mon Jan 16 14:02:53 2012 -0800 Fix overread/possible crash with intra refresh + VBV }} {{bq intra refresh + VBVでの過剰読み込み・潜在的なクラッシュを修正。 }} !x264r2146 {{bq 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. }} {{bq trellis 2 + subme >= 8を修正。 Trellisは期待されるブール値を返していなかった。 r2143-r2145でのレグレッション。 }} !x264r2145 //HEAD {{bq 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). }} {{bq CABAC trellisの最適化パート4: x86_64のasm。 更に20%高速化。 コードサイズが18k->12kに。 この一連のパッチはエンコード速度に大きな影響があるだろう。 例えば、720pのparkjoy(訳注:有名なテストデータの名前)に--preset slower --crf 23で24%高速である。 全体の速度向上はtrellisのコストに比例する(ビットレートに比例し、--trellis 2ではよりその傾向となる)。 }} !x264r2144 {{bq 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 }} {{bq CABAC trellisの最適化パート3: いくつかの配列をstaticでなくした。 }} !x264r2143 {{bq 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. }} {{bq 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 {{bq 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. }} {{bq CABAC trellisの最適化パート1: 出力のちょっとした変更。 tie-break順の相違による。 }} ここでいうtie-breakとはなんですか。 CABACのアルゴリズムを理解していないのでわからず。 !x264r2141 {{bq 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 }} {{bq 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 {{bq 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. }} {{bq 高ビット深度のSSE2/AVX版add8x8_idct8とadd16x16_idct8。 Google Code-Inより。 }} !x264r2139 {{bq 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. }} {{bq MMX/SSE2/AVX版のpredict_8x16_pと高ビット深度fdct8。 Google Code-Inより。 }} !x264r2138 {{bq 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. }} {{bq XOP 8-bit fDCT。 SUMSUBのパスの一つに整数MACを使用。16x16に対して1ダースサイクルほど高速。 }} 1ダースサイクル=12クロック? MACはXOPで使える命令っぽいが詳しく調べる時間がなかった。 !x264r2137 {{bq 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. }} {{bq 高ビット深度のintra_sad_x3_4x4。 Google Code-Inより。 }} !x264r2136 {{bq 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). }} {{bq CAVLCのzero-run bitのコードに大きなLUTを使用。 trellisとRDに最も役立つが、ビットストリームの書き込みにも役立つ。 L2キャッシュの小さいCPU(例えばARM Cortex A8)のような極端なケースでも、最悪、同等のようだ。 }} 主題が書かれていないが、高速化したということ。 ちなみにARM Cortex A8は少し前のAndroid等に載っていたCPU。 !x264r2135 {{bq 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. }} {{bq 高ビット深度のintra_sad_x3_8x8, intra_satd_x3_4x4/8x8c/16x16。 また、accumulator-induced add-or-swapをより簡潔に扱うためにACCUMマクロを追加。 }} 主題が書かれていないが、アセンブラコードの追加。 accumulator-inducedというのは、要は加算またはスワップの違いだけで 同型な処理の記述をマクロでまとめたということらしい。 !x264r2134 {{bq 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. }} {{bq MMX版の10-bit predict_8x8c_hとpredict_8x16c_h。 Google Code-Inから。 }} !x264r2133 {{bq 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. }} {{bq いくつかのMBAFF x86アセンブラ関数。 deblock_chroma_420_mbaffに加え422/422_intra_mbaffが既存の関数を使用して実装された。 Google Code-Inから。 }} !x264r2132 {{bq 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. }} {{bq 更なる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 {{bq 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! }} {{bq 更なる4:2:2のasm関数。 deblock_h_chroma_422の高ビット深度バージョン。 deblock_h_chroma_intra_422の標準・高ビット深度バージョン。 高ビット深度のpixel_vsad。 SSE2版の高ビット深度・MMX 8-bitのpredict_8x8_vl。 今年初のGCIパッチ! }} !x264r2130 {{bq 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 }} {{bq sub8x16_dct_dcのSSE2とSSSE3バージョン。 また、sub8x8_dct_dcを僅かに高速化。 }} !x264r2129 {{bq 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 }} {{bq リサイズフィルタのアップデート。 あらゆるピクセルフォーマットに対し、最もx264と互換性のある色空間を採用するためにAVPixFmtDescriptorを使用。 非推奨のav_set_intの使用を修正。 libavutil >= 51.19.0が必要となった。 }} !x264r2128 {{bq git-id : bc6c98cf4f76c779c8c07f43aa97ac29b1150bc0 Author : Oka Motofumi Date: Thu Jan 5 14:23:50 2012 -0800 Add out-of-tree build support }} {{bq 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 {{bq 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). }} {{bq SSIMを100dbに制限。 infinite SSIM (lossless)での浮動小数点エラーを回避する。 }} !x264r2126 {{bq 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. }} {{bq inttypes.hの間違った条件付きincludeを修正。 inttypes.hはencoder/ratecontrol.cでSCNxxxマクロのために必要だが、HAVE_STDINT_Hはinttypes.hがあることを暗示しない。 stdint.hはinttypes.hのサブセットであり、x264にとって十分ではない。 この変更はAndroidのツールチェインによるx264のビルドを修正する。 }} ビルドにのみ影響。 !x264r2125 {{bq git-id : b081d179e741ceffee2217f6fda06779693dce56 Author : Anton Mitrofanov Date: Wed Dec 21 11:08:56 2011 +0400 Fix crash with sliced threads and input height <= 112 }} {{bq sliced threadsで入力高さ<=112の場合のクラッシュを修正。 }} !x264r2124 {{bq 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 }} {{bq 4:4:4でのカスタム8x8 chroma量子化マトリックスの読み込みを修正。 }} !x264r2123 {{bq git-id : 4c08e42504af81cdbe5789a309e868ca8eda2c1f Author : Anton Mitrofanov Date: Fri Dec 16 01:48:07 2011 +0400 Fix PCM cost overflow }} {{bq PCMコストのオーバーフローを修正。 }} !x264r2122 {{bq git-id : 489a9b2d04c4828877930d2a9104ce93dde8cb85 Author : Anton Mitrofanov Date: Fri Dec 9 01:54:22 2011 +0400 Fix overflow in 8-bit x86 vsad asm function }} {{bq 8-bit vsadのx86 asm版関数でのオーバーフローを修正。 }} !x264r2121 {{bq 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. }} {{bq 最近のffmpegに対してコンパイルされた場合の--fullhelpでのクラッシュを修正。 すべてのピクセルフォーマットに説明があるとは仮定しないようにした。 }} !x264r2120 //HEAD {{bq 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. }} {{bq r2118のレグレッションを修正。 i16x16マクロブロックでのtrellisを壊していた。 }} !x264r2119 {{bq 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. }} {{bq MBAFF chroma deblock関数をU/Vを同時に扱うよう変更。 より便利なasmの実装を可能にする。 }} !x264r2118 {{bq 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. }} {{bq CABAC trellisの最適化: SIMDによる量子化を使用。 有意に速度が向上し、出力には丸めによる小さな違いが出る。 }} !x264r2117 {{bq 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). }} {{bq YUVのレンジの検出とx264CLIでのサポート。 二つの新オプション: --input-rangeと--range。 --input-rangeは検出ミス時に入力のレンジを強制する; デフォルトでは自動。 --rangeは出力のレンジを設定する; x264cliは必要なら変換を行い、デフォルトではTV。 --fullrangeはCLIのオプションとしては削除された(ただしlibx264のAPIは変更なし)。 }} 所謂TVスケール・PCスケールと呼ばれるYUV色空間のレンジが自動検出となった(たぶん)。 強制するオプションは入力・出力で別に指定可能で、入出力が合わない場合には自動変換される。 !x264r2116 {{bq git-id : 00df989cc06208050230756525633438d76b5a6a revision : r2116 Author : Kieran Kunhya Date: Fri Nov 4 20:09:13 2011 +0000 Pass through user data }} {{bq ユーザーデータをパススルー。 }} X264_BUILD 120。 ここで言うユーザーデータは、libx264の仕組みの一部として、 アプリケーション側のデータをフレームと一緒に持ち運べるようになっているものを指している。 ライブラリの使い勝手の問題なので、一般ユーザーには関係ないと思っていい。 !x264r2115 {{bq git-id : 04a0aeefd2f5b152c5dbca4a1c6569bd27c9f721 revision : r2115 Author : Jason Garrett-Glaser Date: Thu Oct 27 14:05:56 2011 -0700 Remove unpredictable branch in CABAC dqp }} {{bq CABAC dqp内の予測不能な分岐を削除。 }} !x264r2114 {{bq 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. }} {{bq 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 //STABLE {{bq 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 }} {{bq checkasm: gccの警告を黙らせ、結果中として幾つかの関数の名前を修正した。 }} checkasmの変更なので一般ユーザーに影響なし。 !x264r2112 {{bq 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. }} {{bq checkasm: ARM上でのビルドを修正。 ARM上でのALIGNED_ARRAY_16の定義方法が原因で、配列の初期化子が使用不能である。代わりにmemset()を使用。 }} checkasmの変更なので一般ユーザーに影響なし。 !x264r2111 {{bq 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. }} {{bq makefileのルールを改善。 ほとんどの再設定の後で"make clean"が不要に。 }} makefileの改善なのでビルドしない人には影響なし。 !x264r2110 {{bq git-id : e6d33a931c08918e78dcae97e4d80d0c3411bf2c revision : r2110 Author : Anton Mitrofanov Date: Sat Nov 12 00:47:48 2011 +0400 Mark some local functions as static, cosmetics }} {{bq いくつかのローカル関数をstaticにするコスメティックス。 }} !x264r2109 {{bq git-id : e0c11dc6e283569606aaa97767401c6a13c2529d revision : r2109 Author : Anton Mitrofanov Date: Fri Nov 11 23:19:02 2011 +0400 Fix crash if timecode file opening fails }} {{bq タイムコードファイルのオープンが失敗した場合のクラッシュを修正。 }} !x264r2108 {{bq 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 }} {{bq Configure: PARISCとMIPS上の共有ビルドではPICを強制。 }} ビルドにのみ影響。 !x264r2107 {{bq 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. }} {{bq yasmのバージョンチェックを改善。 以前のチェックは、完全な互換のない、特定の若いバージョンを許していた。 }} ビルドにのみ影響。 !x264r2106 //HEAD {{bq 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. }} {{bq fencのプリフェッチをadaptive quant(訳注:AQ)に追加。 キャッシュミスの回数を大きく低下、adaptive quantを高速化。 }} !x264r2105 {{bq 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. }} {{bq 色空間でprefetch_fencを分割。 4:2:2バージョンを追加。 }} !x264r2104 {{bq 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 }} {{bq 幾つかの更なる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 {{bq 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). }} {{bq intra_mbcmp_x3の廃れたバージョンを削除。 intra_mbcmp_x3はx9が存在すれば不要である(SSSE3以降)。 }} !x264r2102 {{bq 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 }} {{bq 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 {{bq 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. }} {{bq SSSE3/SSE4/AVX版の9-way完全統合i8x8解析(sad_x9)。 現在の解析よりも〜3倍高速であることに加え、(intra_sad_x9_4x4のように)全てのモードをショートカットなしで解析する。 }} 少し前に同様の高速化が行われていたものの適用対象が広がった。 !x264r2100 {{bq 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. }} {{bq i4x4予測をintra_mbcmp_x9_4x4に統合。 解析後の冗長な予測を回避。 }} 前:[[x264-changelog-jp r2000-r2099]] - 次:[[x264-changelog-jp r2200-r2299]]