このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。 !!!x264-changelog-jp r1300-r1399 r1300-r1399のchangelogの日本語訳。その他のリビジョンと注意事項については[[x264-changelog-jp]]へどうぞ。 前:[[x264-changelog-jp r1200-r1299]] - 次:[[x264-changelog-jp r1400-r1499]] !x264r1399 {{bq git-id : 952aa77c8c7980614cbaa4800e865f4f6a701043 Author : Jason Garrett-Glaser Date: Mon Jan 18 20:29:33 2010 -0800 Various performance optimizations Simplify and compact storage of direct motion vectors, faster --direct auto. Shrink various arrays to save a bit of cache. Simplify and reorganize B macroblock type writing in CABAC. Add some missing ALIGNED macros. }} {{bq 様々な性能上の最適化。 direct動きベクタの格納領域を小さくシンプルにし、--direct autoを高速化。 キャッシュのビットを節約するために様々な配列を縮小。 CABACでのBマクロブロックタイプの書き込みをシンプル化&再構成。 いくつかの欠けていたALIGNEDマクロを追加。 }} !x264r1398 {{bq git-id : bef4e3e601970c9bfd0c94d6621f100cf015e1f8 Author : Jason Garrett-Glaser Date: Mon Jan 18 15:50:06 2010 -0800 Fix crash on new AMD M300 and similar CPUs Apparently these CPUs have SSE4a, but not misaligned SSE. }} {{bq AMD M300やそれと同等の新しいCPU上でのクラッシュを修正。 どうやらこれらのCPUはSSE4aを搭載しているが、非アラインSSEではないようだ。 }} !x264r1397 {{bq git-id : 6cb6086269d789a184cb6262fedb8205d821a44f Author : Jason Garrett-Glaser Date: Sun Jan 17 19:11:05 2010 -0500 Fix intra refresh with subme < 6 Also improve the quality of intra masking. }} {{bq subme < 6でのintra refreshを修正。 また、intra maskingの質を改善。 }} !x264r1396 {{bq git-id : cc65eaba97bb46923dec665e5a91855ac1d97dbf Author : Jason Garrett-Glaser Date: Sat Jan 16 20:11:29 2010 -0500 Add support for multiple --tune options Tunes apply in the order they are listed in the case of conflicts. Psy tunings, i.e. film/animation/grain/psnr/ssim, cannot be combined. Also clarify --profile, which forces the limits of a profile, not the profile itself. }} {{bq 複数の--tuneオプションのサポートを追加。 tuneがコンフリクト(競合・矛盾)する場合には並べられた順番に適用する。 Psyチューニング、つまりfilm/animation/grain/psnr/ssimは組み合わせられない。 また、--profileがプロファイルそのものを強制するのではなく、プロファイルの制限を強制するものだと明示。 }} オプションの指定方法にのみ影響。 Psyの調整がかからないものはfastdecodeとzerolatencyくらいなので、それほど大きな恩恵があるわけではない。複数指定時には"--tune film,fastdecode"というようにカンマで区切る。内部的には区切り文字は",./-+"のどれかであれば良いが、混乱の元なのでまぁカンマがいいだろう。 !x264r1395 {{bq git-id : e4acb95b119743cc933ff3c8f0410aa7ffe20ed2 Author : Jason Garrett-Glaser Date: Sat Jan 16 02:50:15 2010 -0500 Various bugfixes and tweaks in analysis Fix the oldest-ever bug in x264: b16x8 analysis used the wrong width for predict_mv. Fix cache_ref calls for slightly better MV prediction in bsub16x16 analysis. Make B-partition analysis consider reference frame costs. Various other minor changes. Overall very slightly improved mode decision and motion search in B-frames. }} {{bq 解析部の調整と様々なバグ修正。 x264の最も古いバグを修正:b16x8解析はpredict_mvに対して誤った幅を使用していた。 bsub16x16解析で僅かに良好なMV予測のためにcache_refの呼び出しを修正。 Bパーティション解析が参照フレームコストを考慮するようにした。 その他色々と小さな変更。 全体的にBフレームにおけるモード決定と動き検索を非常に僅かに改善。 }} !x264r1394 {{bq git-id : 6662db34e524a6ff1f935cce779473d3882d046c Author : Loren Merritt Date: Thu Jan 14 14:52:12 2010 -0500 More --me tesa optimizations }} {{bq --me tesaの更なる最適化。 }} !x264r1393 {{bq git-id : 7ff686756e042f625fae904d9e059cd489406ed8 Author : Jason Garrett-Glaser Date: Thu Jan 14 10:39:10 2010 -0500 Fix typo in configure }} {{bq configureのタイポ(誤植)を修正。 }} ビルドにのみ影響。 !x264r1392 {{bq git-id : 1d3ab22126c1369a75fc8d5b933159c4a53f35c9 Author : Jason Garrett-Glaser Date: Thu Jan 14 00:07:30 2010 -0500 Make --fps force CFR mode }} {{bq --fpsでCFRモードを矯正するようにした。 }} オプションの指定方法にのみ影響。 !x264r1391 {{bq git-id : 3d0f1108f982867dde5079bbbf90553487de2ed0 Author : Jason Garrett-Glaser Date: Wed Jan 13 20:21:31 2010 -0500 Eliminate intentional array overflow in quant matrix handling While it probably never caused problems, it was incredibly ugly and evil. }} {{bq 量子化マトリックス処理における意図的な配列のオーバーフローを除去。 何も問題は起こしていなかっただろうが、非常に見苦しく邪悪だった。 }} !x264r1390 {{bq git-id : 918ca1e55351446478d4dcee5936c5843bf79925 Author : Jason Garrett-Glaser Date: Wed Jan 13 20:16:13 2010 -0500 Faster --me tesa }} {{bq --me tesaを高速化。 }} !x264r1389 {{bq git-id : d26e79d982ec6d0aea40e6d0b21ee799994007ca Author : Anton Mitrofanov Date: Wed Jan 13 15:44:00 2010 -0500 Fix static pthreads + dynamically linked x264 on win32 Add the necessary static pthread initialization code to a new DLLmain function. }} {{bq win32においてdynamicリンクのx264に対するstaticなpthreads(の処理)を修正。 staticなpthreadに必要な初期化コードを新しいDLLmain関数に追加。 }} pthreadはstaticで、かつlibx264がDLLとしてビルドされる際のコードに、static pthreadに必要な初期化コードが追加された。 x264dll.cが追加。 !x264r1388 {{bq git-id : eda7bf0d97786c04a8563606fd43eab4494490d6 Author : Steven Walters Date: Tue Jan 12 22:55:10 2010 -0500 Add getopt_long to the included getopt.c Fixes option handling on OSs that have a nonworking/missing getopt (e.g. Solaris). }} {{bq includeされたgetopt.cにgetopt_longを追加。 getoptが動かない、または存在しないOS(例:Solaris)でのオプション処理を修正。 }} !x264r1387 {{bq git-id : ecca2f572b584f8f0e006a0f82048e30ada75b9c Author : Jason Garrett-Glaser Date: Tue Jan 12 20:14:35 2010 -0500 Faster psy-trellis init Remove some unncessary zigzags. }} {{bq psy-trellisの初期化を高速化。 いくつかの不要なzigzagを除去。 }} !x264r1386 {{bq git-id : f6d92e5180bc87747475946efdb888cde254b94f Author : Jason Garrett-Glaser Date: Tue Jan 12 19:19:07 2010 -0500 Simplfy intra mode availability handling Slightly faster, 1.5kb smaller binary size, less code. }} {{bq intraモードの利用可能性の処理をシンプル化。 僅かに速く、バイナリサイズが1.5kb小さくなり、コードが少なくなった。 }} 意外と変更量は大きい。 !x264r1385 {{bq git-id : d260e6bf125e2a3b8541bf589c5d41094601fd21 Author : Jason Garrett-Glaser Date: Sun Jan 10 15:14:02 2010 -0500 Fix free callback, add x264_encoder_parameters function x264 would try to use the passed param struct after freeing if the param_free callback was set. Probably didn't cause any issues, as probably no programs used the callback in this location yet. A new x264_encoder_parameters function is now available in the API. This function lets the calling application grab the current state of the encoder's parameters. Use this in x264cli to ensure that the param struct used for set_param is updated with whatever changes x264_encoder_open has made to it. Patch partially by Anton Mitrofanov . }} {{bq freeのコールバックを修正、x264_encoder_parameters関数を追加。 param_freeコールバックが設定されていた場合、x264はfreeの後に渡されたパラメータ構造体を使おうとしていた。 恐らくこの領域のコールバックを使用するプログラムはまだなかったため、多分問題は起きていなかっただろう。 新しい関数、x264_encoder_parametersが利用可能に。 この関数は呼び出し側アプリケーションが現在のエンコーダパラメータの状態を把握することができるようにする。 x264cliではこれを、set_paramに使用されるパラメータ構造体に対してx264_encoder_openが行う変更に関わらず、それ(パラメータ構造体)が最新であることを保証するために使用する。 }} X264_BUILD 83。 encoder_reconfig等が起こった場合にも、libx264を使用するアプリケーションがその内容を知ることができるように。 !x264r1384 {{bq git-id : 846694224797ade9fe3dc8861d68b56a95af6148 Author : David Conrad Date: Sat Jan 9 01:52:33 2010 -0500 Fix x264 compilation on Apple GCC Apple's GCC stupidly ignores the ARM ABI and doesn't give any stack alignment beyond 4. }} {{bq Apple GCCでのx264のコンパイルを修正。 AppleのGCCはおかしく、ARMのABIを無視して、4を超えるスタックアラインを行わない。 }} ARMのABIは8バイトのスタックアラインのみを要求しており、無印のgccとarmccはそれ以上のアラインが行えない。armccはその主張をするだけまだマシ。 Appleのgccは4バイトアラインしか行えない。 LLVMはsvn版ならスタックアラインを行えるが、他の点でバグバグである。 といったことがソースコードのコメントに書いてある。 TODO:LLVMを初めて知ったが面白そうなのでいじってみたい。GCC互換レイヤもあり試し易いし、BSDライセンスなので使い回し易い。でも似たような(中間出力の)アプローチはGCCでも採用していたような…。 !x264r1383 {{bq git-id : a48a48aea05315bb8944e7e8f92fa2a6e30006a4 Author : Jason Garrett-Glaser Date: Sat Jan 2 03:27:46 2010 -0500 Faster weightp motion search For blind-weight dupes, copy the motion vector from the main search and qpel-refine instead of doing a full search. Fix the p8x8 early termination, which had unexpected results when combined with blind weighting. Overall, marginally reduces compression but should potentially improve speed by over 5%. }} {{bq weightpの動き検索を高速化。 blind重みにおける複製では、全検索をする代わりにメインの検索とqpel-refineから動きベクタをコピー。 p8x8の早期終了を修正、blind重みとの組み合わせで予期せぬ結果になっていた。 全体的に、わずかに圧縮率を減少させるが、潜在的にはスピードを5%超改善するはず。 }} 複製参照はblind weightedな事を除けば単なる複製なのだから、基本的にはほぼ同じMVとなるはずであり、再度やり直すのは無駄だから処理を省こう、ということ。 仮訳の時点では"For blind-weight dupes"のdupesの解釈を誤っており、どうやら本当はduplicatesの意味だったようなので訳を修正した。 !x264r1382 {{bq git-id : e9f998b97db6e498faa62a60c6fddf3cabfea214 Author : Jason Garrett-Glaser Date: Thu Dec 31 13:45:27 2009 -0500 More correct padding constants for lowres planes Since lowres analysis isn't interlace-aware, we don't need to double the vertical padding for interlaced video. }} {{bq 低解像度プレーンにより正しいパディング定数を使用。 低解像度解析はインターレースを意識しないので、インターレースビデオのために垂直パディングを二重化する必要はない。 }} !x264r1381 {{bq git-id : 1b68cbd27b24759f64c72effdae42f184a20546e Author : Jason Garrett-Glaser Date: Thu Dec 31 02:57:45 2009 -0500 Fix some invalid reads caught by valgrind Temporal predictor calculation was misled by invalid reference counts for I-frames. }} {{bq valgrindで見つかったいくつかの不正な読込を修正。 不正なIフレームの参照カウントによってTemporal(時間軸)予測器の計算がミスリードされて(間違った方向に導かれて)いた。 }} !x264r1380 {{bq git-id : 52a4fbe142926435571fbf2fb3d535e8873627d3 Author : Jason Garrett-Glaser Date: Tue Dec 22 18:59:29 2009 -0500 Periodic intra refresh Uses SEI recovery points, a moving vertical "bar" of intra blocks, and motion vector restrictions to eliminate keyframes. Attempt to hide the visual appearance of the intra bar when --no-psy isn't set. Enabled with --intra-refresh. The refresh interval is controlled using keyint, but won't exceed the number of macroblock columns in the frame. Greatly benefits low-latency streaming by making it possible to achieve constant framesize without intra-only encoding. Combined with slice-max size for one slice per packet, tests suggest effective resiliance against packet loss as high as 25%. x264 is now the best free software low-latency video encoder in the world. Accordingly, change the API to add b_keyframe to the parameters present in output pictures. Calling applications should check this to see if a frame is seekable, not the frame type. Also make x264's motion estimation strictly abide by horizontal MV range limits in order for PIR to work. Also fix a major bug in sliced-threads VBV handling. Also change "auto" threads for sliced threads to "cores" instead of "1.5*cores" after performance testing. Also simplify ratecontrol's checking of first pass options. Also some minor tweaks to row-based VBV that should improve VBV accuracy on small frames. }} {{bq Periodic intra refresh(PIR:周期的intra更新)。 SEIリカバリーポイントと、移動する垂直的なイントラブロックの「バー」、そして動きベクタ制限を使用してキーフレームを撤廃する。 --no-psyが設定されていない場合はintraバーが視覚的に現れるのを隠すように試みる。 --intra-refreshで有効。 リフレッシュ間隔はkeyintでコントロールされるが、フレーム内のマクロブロックの列数を超えない。 intra-onlyエンコードなしに不変のフレームサイズを成立可能にすることで、低レイテンシ(低遅延)ストリーミングに非常に利益がある。 slice-maxサイズと組み合わせパケットごとに1スライスとすることで、パケットロスに対する有効耐性が25%にもなると、テストは示唆している。 x264は今や世界最高の低レイテンシなフリーソフトウェアビデオエンコーダになった。 これに伴ない、b_keyframeを出力ピクチャのパラメータに追加するようAPIを変更。 呼び出し側アプリケーションはフレームがシーク可能であるかを知るために、フレームタイプではなくこれをチェックすべき。 また、PIRが働くようにするため、x264の動き見積もりが水平MV range制限を厳密に守るようにした。 また、sliced-threadsのVBV処理中の大きめなバグを修正。 また、性能テストによりsliced threadsに対する"auto"スレッド数を「1.5xコア数」ではなく「コア数」に変更。 また、1stパス指定のレートコントロールのチェックを単純化。 また、rowベースのVBVに、小さなフレームでVBVの精度を向上するであろういくつかの小さな調整。 }} X264_BUILD 82。 まず、--intra-refreshとは''関係ない''が、keyint-minが(keyint/2)+1でキャップされる(割り算部分は切り捨て)ようになった。 オプションに--intra-refreshが追加、シークしやすく、すぐに再生開始できる動画が作成可能に。MVの制限がなされること等を考慮すれば、RD的には性能劣化すると思われる。 使用時の注意点は以下の通り。 *b-pyramid normalと併用不可、指定していた場合はstrictにされる。 *ref>1との併用不可、指定していた場合はref=1にされる。 *keyint自体が(width/16)-1でキャップされる(割り算部分は切り上げ)。 訳者はPIRのなんたるかをよく知らないため、このリビジョンの訳は精度が悪いかも知れない。 ストリーミング配信以外では重要でないだろうから、あまり興味が湧かない。 sliced-threadのVBVで大きめのバグが修正されたようだが、sliced-threadも使うことがない…。 !x264r1379 {{bq git-id : 8b9dcd8d50be201f1bedc9b19331432969f37d98 Author : Kieran Kunhya Date: Mon Dec 28 10:42:17 2009 -0500 LAVF/FFMS input support, native VFR timestamp handling libx264 now takes three new API parameters. b_vfr_input tells x264 whether or not the input is VFR, and is 1 by default. i_timebase_num and i_timebase_den pass the timebase to x264. x264_picture_t now returns the DTS of each frame: the calling app need not calculate it anymore. Add libavformat and FFMS2 input support: requires libav* and ffms2 libraries respectively. FFMS2 is _STRONGLY_ preferred over libavformat: we encourage all distributions to compile with FFMS2 support if at all possible. FFMS2 can be found at http://code.google.com/p/ffmpegsource/. --index, a new x264cli option, allows the user to store (or load) an FFMS2 index file for future use, to avoid re-indexing in the future. Overhaul the muxers to pass through timestamps instead of assuming CFR. Also overhaul muxers to correctly use b_annexb and b_repeat_headers to simplify the code. Remove VFW input support, since it's now pretty much redundant with native AVS support and LAVF support. Finally, overhaul a large part of the x264cli internals. --force-cfr, a new x264cli option, allows the user to force the old method of timestamp handling. May be useful in case of a source with broken timestamps. Avisynth, YUV, and Y4M input are all still CFR. LAVF or FFMS2 must be used for VFR support. Do note that this patch does *not* add VFR ratecontrol yet. Support for telecined input is also somewhat dubious at the moment. Large parts of this patch by Mike Gurlitz , Steven Walters , and Yusuke Nakamura . }} {{bq LAVF/FFMS入力のサポートとネイティブなVFRタイムスタンプ処理。 libx264が3つの新しいAPIパラメータを受け取るように。 b_vfr_input(訳注:内部変数名であってオプションではない)は入力がVFRであるかを示し、1がデフォルト。 i_timebase_numとi_timebase_den(訳注:同上)はtimebaseをx264に渡す。 x264_picture_tが各フレームのDTSを返すように:呼び出し側アプリでは計算する必要が無くなった。 libavformatとFFMS2入力のサポートを追加:libav*とffms2のライブラリがそれぞれ必要。 libavformatはFFMS2を通して使用することが_強く_望まれる:ディストリビューション(訳注:バイナリ配布)は、可能である限りFFMS2のサポート付きでコンパイルすることを推奨する。 FFMS2は http://code.google.com/p/ffmpegsource/ にある。 x264cliの新オプション、--indexは、将来の再インデックス化を避けるため、FFMS2のインデックスファイルの保存(または読込)を可能にする。 CFRと決めつけるのではなくタイムスタンプを渡すため、muxerをオーバーホール。 また、コードのシンプル化のため、b_annexbとb_repeat_headers(訳注:これらも内部変数)を正しく使用するようにmuxerをオーバーホール。 ネイティブなAVSのサポートとLAVFのサポートにより、VFW入力のサポートは今やかなり不要となったため、削除。 そしてx264cli内部を大きくオーバーホール。 x264cliの新オプション、--force-cfrでは、旧方式のタイムスタンプ処理を強制することが可能。タイムスタンプの壊れたソースの場合に有効だろう。 Avisynth, YUV, Y4M入力はCFRのまま。VFRのサポートにはLAVFまたはFFMS2を使わねばならない。 このパッチはVFR対応のレートコントロールをまだ追加*していない*ことに注意。 テレシネ入力のサポートも今のところ幾分怪しい。 このパッチの大部分はMike Gurlitz, Steven Walters, Yusuke Nakamuraによる。 }} X264_BUILD 81。 少し前に言及されていたlibav*とそのラッパであるFFMS2(FFMpegSourceで有名)による入力のサポート。 x264が様々な動画ファイルを''直接読める''ようになると同時に、タイムスタンプ情報を得ることで直接的に''VFRにも対応''となった。 タイムスタンプが怪しい動画は''--force-cfr''で従来通りCFRとして扱える。 他に、--muxer, --demuxer(--stdin, --stdout相当)が追加。 このリビジョンでの変更は大きいが、基本的にはエンコードエンジンに手を加えるものではない。 FFMS2はラッパ(インターフェースを扱い易くするための薄いライブラリ)とはいっても、libav*の問題のある挙動を矯正していたりもするので、''強く推奨''とされているのだろう。 また、''--index''で出力されるインデックスにより外部ツールとの連携も行いやすくなるかも。 x264としてはこれまで「エンコーダの機能ではない」としてあまり強化してこなかった部分が、これで非常に強くなる。 VFRに関して、ビットレートは時間に従属するものなので、1秒あたりのフレーム数が一定にならないVFRではCFRのように単純に計算ができない。そのためこの部分は未実装とされている。 mp4出力で然るべき場合に''edtsが挿入''されるようになり、これにより''初期ディレイが正しく''なった。 が、巷に出回っているmp4スプリッタでこれに対応しているものが少ないため、一見、''逆に音ズレを発生させるように見える''ケースが有る。 某巨大掲示板によればフリーのスプリッタは対応予定を立てているそうなので、それらの動向に注意されたい。(2010/04/07追記)2010/03/27にリリースされた[Haali Media Splitter|http://haali.su/mkv/]では対応がなされたらしい。 ソースレベルではinput/ffms.cとinput/lavf.cが追加され、input/vfw.cが除去された。 ffmpegのライブラリのうち実際に使用されるライブラリはlibavformat, libavcodec, libswscaleで、ffmpeg r18351以上の物が必要。 FFMS2はC++で書かれたライブラリなので、環境によってはLDFLAGSに-lstdc++が入る。 !x264r1378 {{bq git-id : 27355a2ba90516b0c280e026eb9c35fbf5f27a57 Author : Jason Garrett-Glaser Date: Tue Dec 15 16:59:00 2009 -0800 More help typo fixes }} {{bq 更なるヘルプのタイポ(誤植)修正。 }} !x264r1377 {{bq git-id : b9823cafed9e0cbc887e5fbc27b78a892cb43de1 Author : Loren Merritt Date: Thu Jan 14 03:07:30 2010 +0000 Fix x264_clz on inputs > 1<<31 (though x264 never generates such inputs) }} {{bq 入力が1<<31を超える場合のx264_clzを修正。 (x264がそのような入力を生成することはないが) }} 「1<<31を超える」とは32bitをオーバーフローしているようなデータということ。 !x264r1376 {{bq git-id : 3feaec244c11ad4496ac4f6a630200a89db2d308 Author : Jason Garrett-Glaser Date: Sun Dec 13 03:16:04 2009 -0800 Don't do sum/ssd analysis if weightp == 1 Typo fixes in comments and help. }} {{bq weightp == 1の場合にsum/ssd解析を行わない。 コメントとヘルプのタイポ(誤植)を修正。 }} プログラミングをしない人に注釈すると、「==」はC言語において「等しい」の意味で、このchangelog自体はタイポしているわけではない。 !x264r1375 {{bq git-id : c9cafc75352f036bdcb90f2a26e7233920567b13 Author : Jason Garrett-Glaser Date: Fri Dec 11 17:22:18 2009 -0800 Fix two bugs in 2-pass ratecontrol last_qscale_for wasn't set during the 2pass init code. abr_buffer was way too small in the case of multiple threads, so accordingly increase its buffer size based on the number of threads. May significantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames, such as anime. }} {{bq 2-passレートコントロールのバグを2つ修正。 last_qscale_forは2passの初期化コードで設定されていなかった。 abr_bufferは複数スレッドのケースであまりに小さすぎだったので、スレッド数に基づいて適宜バッファサイズを増加。 多スレッドの2-passモード、特にアニメのような極端に大きなIフレームの場合に、著しく画質を上昇するかもしれない。 }} ここでいうスレッドは通常のスレッドでsliced_threadsではない模様。 "way too small"のwayは強調。 !x264r1374 {{bq git-id : 85eb4007f2ed36477b7fdc04ed2d63fbb2b7a0fb Author : Steven Walters Date: Thu Dec 10 19:48:51 2009 -0800 Avisynth-MT and 2.6 compatibility fixes Explain to the user why YV12 conversion is forced with Avisynth 2.6. Fix encoding with Avisynth-MT scripts by inserting the necessary Distributor() call; speeds such scripts back up to expected levels. }} {{bq Avisynth-MTと2.6の互換性を修正。 なぜAvisynth 2.6でYV12変換が強制されるかをユーザに説明。 必要なDistributor()の呼び出しを追加することによりAvisynth-MTスクリプトでのエンコードを修正;そのようなスクリプトでの速度が期待するレベルに戻った。 }} !x264r1373 {{bq git-id : 4322f630325dd8baf48fef45c19789a9d1614c16 Author : Steven Walters Date: Wed Dec 9 16:03:19 2009 -0800 Fix zone parsing on mingw Due to MinGW evidently being in the hands of a pack of phenomenal idiots, MinGW does not have strtok_r, a basic string function. As such, remove the dependency on strtok_r in zone parsing. Previously, using zones for anything other than ratecontrol failed. }} {{bq mingwによるzone解析の修正。 どうやら、MinGWは並外れたおバカさん達一味の手にあるようなので、MinGWは基本的な文字列関数であるstrtok_rを持たない。 そういうことなので、zoneの解析に於けるstrtok_rへの依存を除去。 以前は、レートコントロール以外のzoneの使用は失敗していた。 }} MinGWがMincrosoft製のmsvcrt.dllに依存していることから「並外れた〜」と表現している。まぁ、商業的・一般的意味でMicrosoftが善か悪かはともかくも、Microsoft製品の実装・仕様はGeek達にとって''技術的に納得がいかない''ことが多々あるのは確か。 evidentlyは基本的には「明らかに」という意味だが、「証拠が指し示すところでは」というような婉曲的表現のようで、若干の皮肉のニュアンスがある模様。 これを「どうやら」「見たところ」と訳すことがあるので、こちらを採用した。 !x264r1372 {{bq git-id : 28c1d446bc0df176b99a150ca02d91ff7945410c Author : Jason Garrett-Glaser Date: Wed Dec 9 15:03:44 2009 -0800 More lookahead optimizations Under subme 1, don't do any qpel search at all and round temporal MVs accordingly. Drop internal subme with subme 1 to do fullpel predictor checks only. Other minor optimizations. }} {{bq lookaheadの更なる最適化。 subme 1において、qpel検索を全く行わず、それに従いtemporal MVを丸める。 fullpel(1ピクセル単位)予測チェックのみを行うために、subme 1では内部のsubmeをやめた。 その他の小さな最適化。 }} 今更だがふと思いついたので注釈すると、qpel検索とは1/4ピクセル単位での動き検索のことを指している。1/2ピクセル単位だとhpelなので、つまりはq=quarter、h=halfの意味。pelは、正確なところが不明だが、pixelの略だと思われる。 !x264r1371 {{bq git-id : 385df7f0103d57198d09a1f76c7289cd0a902ae8 Author : Jason Garrett-Glaser Date: Wed Dec 9 05:56:35 2009 -0800 Various minor missing changes from previous commits Boolify sliced threads too Remove unused constants from dct-a.asm Fix a few typos/minor errors in preset documentation }} {{bq 以前のコミットで不足していた雑多で小さな変更群。 sliced threadもbool(真偽値)化。 不使用の整数をdct-a.asmから除去。 presetのドキュメント内の少数のタイポ(誤植)/小さな間違いを修正。 }} スライスベースのスレッド化はsliced threadと記載されることが多いようだが、 これの訳に困るので今後は訳さない方向で。 !x264r1370 {{bq git-id : 65b3d0fd9f8167a6d0772a29e8fcf1a66ee7f8af Author : Jason Garrett-Glaser Date: Thu Dec 10 16:52:39 2009 -0800 Fix regression in direct=auto/temporal in r1364 Bug caused rare race condition in frame reference handling. This resulted in invalid bitstreams in some B-frames and, very rarely, crashes. }} {{bq r1364でのdirect=auto/temporalのレグレッションを修正。 バグはフレーム参照の処理に於いて稀な条件の競合を引き起こしていた。 これはBフレームに於いて無効なビットストリームをもたらすことがあり、非常に稀にはクラッシュしていた。 }} やっぱりあったかといったところで。 !x264r1369 {{bq git-id : ec8e58637b97edaea00f022e11d15ee8a81466ab Author : Jason Garrett-Glaser Date: Tue Dec 8 17:46:55 2009 -0800 Add fast pskip to x264 SEI info header }} {{bq x264のSEI情報ヘッダにfast pskipを追加。 }} !x264r1368 {{bq git-id : 11cfc44b338d914b5ec2337db37ba4d532295e43 Author : Steven Walters Date: Tue Dec 8 11:36:25 2009 -0800 Minor seeking fix with Avisynth input Seeking past the end of the input with --seek would result in the same frame being repeated over and over. }} {{bq Avisynth入力に小さなシークの修正。 入力の最後で--seekで過去にシークするのは同じフレームが延々と繰り返される結果になる。 }} !x264r1367 {{bq git-id : de5beaec2078967d08da8ae2483c9f982b0ab07e Author : Jason Garrett-Glaser Date: Tue Dec 8 03:08:17 2009 -0800 Add support for MB-tree + B-pyramid Modify B-adapt 2 to consider pyramid in its calculations. Generally results in many more B-frames being used when pyramid is on. Modify MB-tree statsfile reading to handle the reordering necessary. Make differing keyint or pyramid between passes into a fatal error. }} {{bq MB-tree + B-pyramidのサポートを追加。 B-adapt 2をその計算上pyramidを考慮するように修正。 一般的にpyramidがonの場合により多くのBフレームが使用される結果になる。 必要な並べ替えを扱えるようにMB-treeのstatsファイルの読み込みを修正。 パス間でkeyintまたはpyramidを違わせると致命的エラーになる。 }} !x264r1366 {{bq git-id : ca1112b373bd6c16a57350913a4a6cc4611b2d16 Author : Jason Garrett-Glaser Date: Mon Dec 7 18:34:05 2009 -0800 Use aliasing-avoidance macros in array_non_zero }} {{bq エイリアシング回避マクロをarray_non_zeroで使用。 }} !x264r1365 {{bq git-id : 77fc51070b3c916b3b16888e8ead0f3cb3e09eaa Author : Cleo Saulnier Date: Mon Dec 7 12:40:14 2009 -0800 MMX version of 8x8 interlaced zigzag Just as fast as SSSE3 on Nehalem (and faster on Conroe/Penryn), so remove the SSSE3 version. }} {{bq 8x8 interlace zigzagのMMXバージョン。 Nehalem上でSSSE3と同じくらい速い(そしてConroe/Penrynではより速い)ので、SSSE3バージョンを削除。 }} !x264r1364 {{bq git-id : e8b73a9a4db4dd703528a1eee247b84ac335e395 Author : Jason Garrett-Glaser Date: Mon Dec 7 00:49:41 2009 -0800 Bring back slice-based threading support Enabled with --sliced-threads Unlike normal threading, adds no encoding latency. Less efficient than normal threading, both performance and compression-wise. Useful for low-latency encoding environments where performance is still important, such as HD videoconferencing. Add --tune zerolatency, which eliminates all x264 encoder-side latency (no delayed frames at all). Some tweaks to VBV ratecontrol and lookahead (in addition to those required by sliced threading). Commit sponsored by a media streaming company that wishes to remain anonymous. }} {{bq スライスベースのスレッド分割のサポートを復活。 --sliced-threadsで有効になる。 通常のスレッド分割とは異なり、エンコーディングレイテンシ(遅延)が足されない。 性能(速度)と圧縮率の両観点で通常のスレッドより非効率。 HDビデオ会議のように性能がいまだ重要である、低レイテンシエンコーディングの環境で有用。 x264の全てのエンコーダ側レイテンシを排除する--tune zerolatency(遅延フレームが皆無)を追加。 VBVレートコントロールとlookaheadに(スライスベースのスレッド分割に必要なもの以上の)いくつかの調整。 コミットは匿名希望のメディアストリーミング企業によるスポンサード(提供)。 }} X264_BUILD 80。 --tune zerolatencyの内容は、rc-lookahead=0, sync-lookahead=0, bframe=0, sliced-threads=1。 広範な変更なのでエンバグの可能性に注意。 !x264r1363 {{bq git-id : a8f670b66ac89d75ef09ff87c940cfe3b328ad2d Author : Alex Jurkiewicz Date: Mon Dec 7 18:17:29 2009 -0800 Add more detailed help for presets/tunes/profiles Shows what options they represent. }} {{bq presets/tunes/profilesにより詳細なヘルプを追加。 それらが何のオプションを使用しているかを表示。 }} !x264r1362 {{bq git-id : e5faf712fccefd1f29319b1547714f3d894e4dba Author : Jason Garrett-Glaser Date: Sat Dec 5 03:19:44 2009 -0800 qpel RD no longer needs mbcmp_unaligned }} {{bq qpel RDがmbcmp_unalignedを必要としないように。 }} !x264r1361 {{bq git-id : 733b660f44fa4e8982cb83447f1d2cd7e31b4386 Author : Loren Merritt Date: Wed Dec 9 00:37:09 2009 +0000 ensure that all boolean options are {0,1} so they print consistently in the options SEI }} {{bq 全てのbooleanオプションが{0,1}であることを保証し、SEIオプションで一貫した表示に。 }} プログラマ以外に解説すると、booleanとは数値や文字列ではなく、on/offやyes/noで表される値で、 訳す場合には「真偽値」と表現される。 蛇足だが、若干プログラミング論を語りたい。 プログラミング上、false=0だと見なすのは多くの言語処理系で問題ないが、 ''true=1だと思いこむのは若干危険''だ。 殆どのシステムではbooleanに1bit超の記憶域を割り当てるので、 0と1以外の値をどう考えるかが問題になる。 例えばC言語ではtrue=1(比較演算子がint型の1を生成する:"yields 1 if the specified relation is true and 0 if it is false")であるが、VBではtrue=-1だ。 C言語上で、VBから受け取ったある変数(ここではfooとする)を真偽値として条件判断をするのに {{pre if(foo == TRUE) }} と書いた場合、VB側でtrueを渡しているとこの条件は成立しなくなる。 実際には''殆どの処理系が制御構文上、0=false, 非0=true''として扱っているため、 {{pre if(foo) }} と書くのが無難に思える。 しかし世の中は広く、コーディング規約(ソースコードの書き方のルール)で この様な''単項での真偽値判断を禁止''する開発現場がある。 曰く、「条件として曖昧で、何を判断しているのかわからない」というのだ。 筆者はこのようなルール(と主張)には今一同意しかねるが、 このような現場では非難を避ける意味で、 {{pre if(foo != FALSE) // あるいは0と比較 }} という若干回りくどい表現が無難になってくる。 ソースコードの理解のしやすさという意味では、本末転倒ではないだろうか。 こういう問題を避けるため、比較的抽象度の高い一部の言語処理系(Ruby等)では ''数値と真偽値を非可換''としていたりする。 すなわち、真偽値を数値として解釈しないし、数値を真偽値として解釈しない、 あるいは数値型の値は全てtrueとして処理する(数値という「データが存在している」という意味で0でもtrue)ようにしていたりする。 !x264r1360 {{bq git-id : 528c100957ae929ae466ec54309cbb1e6193f66e Author : Jason Garrett-Glaser Date: Sat Dec 5 02:27:30 2009 -0800 Actually do r1356 Somehow commit r1356 got lost in the ether. I'm not sure how, but now it's fixed. }} {{bq r1356をホントに実施。 なぜかr1356のコミットは煙のごとく消えて無くなった。どうしてかは分からないが、これで修正された。 }} r1356ではx264_me_refine_bidir_rdの修正が中途半端で、さらにchangelogに書いてあった題目である、x264_me_refine_qpel_rdの修正が全くなされていなかった。 大意に影響はないが、"in the ether"の日本語訳が難しい。 学術史も絡み、訳者のキャパシティを超える話題になるが、一応説明してみる。 なお、''x264には全く無関係''で脱線が激しいので、読まなくていい。 "ether"は"aether"とも(表示できる環境ではaとeをくっつけた文字でも)表記される。 ギリシャ語由来の言葉で、元の意味は「天、上空」や「清浄な空気」らしい。 しかし非常に古い時代に学術上で扱われた言葉であるため、転用や意味の拡大により、とても抽象的というか、''幻想的''なイメージさえ持つ言葉になっている。 「非常に古い時代の学術」とは、化学や物理学はおろか、「科学」の定義が曖昧だった(あるいは成立していなかった)ような時代だ。 全ての学術が今で言う哲学の範疇にあった頃で、人物で言えば''アリストテレス''の時代にあたる。 この頃の科学(?)と言えば''四大元素説''や''五行説''であり、「全てのものは空・水・土・火(風・木・金などを含む場合もある)からできている」等と考えられていた。 思わず''「クリスタルか?」''と言いたくなってしまうが、アリストテレスがここに加えたのが"aether"で、イメージとしては''「天」''が近い。 地上のものは直線運動をするのに対し、天球は円運動をすることを説明するためだったとか。 ここから「宇宙空間を占める・統べる存在」というイメージのわかりづらい言葉になったようだ。 現代の辞書では詩的な「天」、「ラジオ」、古典物理学上の「エーテル」、現在の化学上の「エーテル」、あるいは一般的な「溶剤」のような意味がある。 いずれにしてもメタファー(暗喩)なので、ここでは直喩に置き換えて「煙のごとく」と訳した。 コンピュータ用語としては"ether"はEthernet(イーサネット)を想起させるが、これも古典物理学上のエーテル(光を媒介する存在)が名前の由来らしい。 当初のEthernet(10BASE5〜10BASE2の時代)は、1繋ぎの同軸ケーブルに全ての機器がぶら下がるバス型(論理的にも物理的にも)だった。 しかしEthernetのバス制御にはマスタが存在しなかった(CSMA/CD方式)ので、Ethernetバス空間が"ether"だとイメージされていたのが元のようだ。 EthernetのCSMA/CD方式は無線通信・放送での制御方法に類似しており、辞書の訳に「ラジオ」とあるのは、無線分野で同様の思考がなされた結果だろう。 あるいは無線分野が先に、周波数空間、または宇宙空間や大気圏の層を"ether"と表現していたのかもしれない。 なお、現代のハブにぶら下がる形のスター型配線でも、論理的にはバス型が基本になっている。 ただし、現在のハブは殆どがレイヤ2以上のスイッチングハブなので、実運用上はスター型というかピアツーピアに近い動作の方が多い。 現在一般にLANケーブルと呼ばれるものは、形状から言えばRJ-45端子のTwisted Pair Cable(ツイストペアケーブル)であり、100BASE-TなどのTはこの頭文字から来ている。 10BASE5の頃には同軸だったのだし、そもそもEthernet以外のLANもあったのだから、本当はRJ-45のツイストペアケーブルをLANケーブルと呼ぶのは若干乱暴だ。 !x264r1359 {{bq git-id : 495177138cdaf8360156f4d3cb45a14f1abf3266 Author : Steven Walters Date: Fri Dec 4 12:17:56 2009 -0800 Remove some unused code from x264.c }} {{bq x264.cの不使用のコードを除去。 }} 出力に影響なし。 !x264r1358 {{bq git-id : 77d0631c35b7e6928759eda0b3d7d229b18f27c9 Author : Jason Garrett-Glaser Date: Thu Dec 3 15:36:52 2009 -0800 SSSE3 version of zigzag_8x8_field Slightly faster interlaced encoding with 8x8dct. Helps most on Nehalem, somewhat disappointing on Conroe/Penryn. }} {{bq zigzag_8x8_fieldのSSSE3バージョン。 8x8dct付きのinterlaced符号化を僅かに高速化。 Nehalemで最も効き、Conroe/Penfynではいささか期待はずれ。 }} !x264r1357 {{bq git-id : 225d1dcd4973cfb8e2be39dc40da26f869814a62 Author : Jason Garrett-Glaser Date: Wed Dec 2 19:55:45 2009 -0800 Fix crash in interlaced with >8 refs Crash introduced in weightp. }} {{bq ref>8のinterlacedでのクラッシュを修正。 クラッシュはweightpで持ち込まれた。 }} !x264r1356 {{bq git-id : 4bf27ffa3e5b40d49e201e4e39c4f3b57a84c737 Author : Jason Garrett-Glaser Date: Tue Dec 1 16:15:15 2009 -0800 Significantly faster qpel-RD Cache the results of MC, like in bidir-RD. Slightly changes output due to the necessary reordering of satd/RD calls. 5-10% faster qpel-RD. }} {{bq qpel-RDを顕著に高速化。 bidir-RDと同様にMCの結果をキャッシュする。 satd/RDの呼び出しを並べ替える必要性により出力が僅かに変わる。 qpel-RDを5-10%高速化。 }} !x264r1355 {{bq git-id : 83bda2ea78c9aa145a8d6fc7cb122ca4439c822d Author : David Conrad Date: Tue Dec 1 12:23:09 2009 -0800 Add x264 prefix to functions with ffmpeg equivalents Not important now, but will be when we add libav* input support. }} {{bq ffmpegと同等の関数群にx264のプレフィックスを追加。 今は重要ではないが、libav*による入力をサポートした際に重要になる。 }} 将来性を考えたシンボルの変更で、出力に影響なし。 今回プレフィックスが付いたのはバイトストリーム出力系の関数のみ。 !x264r1354 {{bq git-id : 636f98f1b06cc51da8399e79ce08bab8c56b82b7 Author : Jason Garrett-Glaser Date: Mon Nov 30 01:41:24 2009 -0800 10L in r1353 Broke mp4 output. }} {{bq r1353の10L。 mp4出力を破壊していた。 }} !x264r1353 {{bq git-id : 380a201e8e8ba5a13022aeeeaf4b7501e1c79279 Author : Steven Walters Date: Thu Nov 26 22:37:18 2009 -0800 Enhanced Avisynth input support Requires avisynth_c.h from the Avisynth API headers. Reports errors properly from Avisynth script input. Automatically construct input scripts for almost any input file. Tries ffmpegsource2, DSS2, directshowsource, and many other sourcing methods, based on the input file extension. Automatically converts to YV12. }} {{bq Avisynth入力のサポートを強化。 AvisynthのAPIヘッダより、avisynth_c.hを必要とする。 Avisynthスクリプト入力の適正なエラーを報告する。 ほぼ全ての入力ファイルに対して自動的に入力用スクリプトを作成する。 入力ファイルの拡張子に基づき、ffmpegsource2, DSS2, directshowsourceその他、多くの読み込み手法を試みる。 自動的にYV12に変換する。 }} AvisynthをVfWベースではなくネイティブにサポートするようになり、.avsを自分で書かなくとも自動的にAvisynth経由の入力が可能になった。上記の他にAVISource, MPEG2Source, AVCSourceに対応する。ネイティブ対応により、入力に関するエラー表示がある程度詳細になった。 configureの--disable-''avis''-inputは--disable-''avs''-inputという名前に変更。 ソース上はこれまでのinput/avis.cがinput/vfw.cになり、extras/avisynth_c.hとinput/avs.cが追加。 調べて試して努力してAVSを書けるようになっていたユーザは、「今更不要」とか「フィルタにこそ意味がある」と言いたくなるかも知れないが、ここは素直に喜んでおきたいと思う。しかし、x264のソースでLoadLibraryだのGetProcAddressだののWindows臭いソースを見ると、不思議な気分だ…。 !x264r1352 {{bq git-id : d487de421807a0d384b29a0d9dc6c90f180f0e7b Author : Jason Garrett-Glaser Date: Wed Nov 25 10:40:08 2009 -0800 Much faster weightp Move sum/ssd calculation out of lookahead and do it only once per frame. Also various minor optimizations, cosmetics, and cleanups. }} {{bq weightpをかなり高速化。 sum/ssd計算をlookaheadから移動しフレームごとに1度だけ実施。 色々と小さな最適化、コスメティックス、クリーンアップも。 }} !x264r1351 {{bq git-id : f3cdc6a4878450850eb07ed0122b9836122bdbe0 Author : Kieran Kunhya Date: Wed Nov 25 01:26:02 2009 -0800 Fix bugs in fps/timestamp handling in FLV muxer }} {{bq FLV muxerのfps/タイムスタンプ処理のバグを修正。 }} !x264r1350 {{bq git-id : 626affea98f4db9208cbf0e3db78f23804defd0c Author : Jason Garrett-Glaser Date: Tue Nov 24 22:37:02 2009 -0800 Fix bug in weightp analysis Weights weren't reset upon early terminations, so old (wrong) weights could stick around. Small compression improvement. }} {{bq weightp解析部のバグを修正。 早期終了時に重みがリセットされておらず、そのため古い(誤った)重みが居座っていたかも知れない。 圧縮率を小改善。 }} !x264r1349 {{bq git-id : a1705b68f5e88e083411d1d1d8fc77cb09304753 Author : Jason Garrett-Glaser Date: Tue Nov 24 20:24:14 2009 -0800 Minor deblocking optimization, update comments }} {{bq 小さなデブロッキングの最適化、コメントの更新。 }} !x264r1348 {{bq git-id : 1c2c5688b64fcd62f307b9e00fde228324a0162d Author : Jason Garrett-Glaser Date: Tue Nov 24 16:21:07 2009 -0800 Fix weightb with delta_poc_bottom Has no effect yet, but will be required once we add TFF/BFF signalling support in interlaced mode. Gives 0.5-0.7% better compression with proper TFF/BFF signalling. }} {{bq delta_poc_bottom付きのweightbを修正。 まだ何の効果もないが、インターレースモードでTFF/BFF符号化をサポートしたら必要になる。 適切なTFF/BFF符号化で0.5-0.7%の圧縮率向上。 }} 今更だが念のため、TFF/BFFはTop Field FirstとBottom Field Firstの略。 !x264r1347 {{bq git-id : 5ddd61bbfecb6e782b096ddebef127ab73bee006 Author : Jason Garrett-Glaser Date: Fri Nov 20 23:27:51 2009 -0800 Give more meaningful error if 1st/2nd pass resolution differ }} {{bq 1st/2ndパスの解像度が異なる場合により分かりやすいエラーを表示。 }} !x264r1346 {{bq git-id : 0b0f4a3470c58061d09ee26037314c2f8a4d049b Author : Steven Walters Date: Fri Nov 20 12:04:13 2009 -0800 Fix extremely rare deadlock with sync-lookahead Patch partially by Anton Mitrofanov. }} {{bq sync-lookaheadでの極稀なデッドロックを修正。 パッチは一部Anton Mitrofanovによる。 }} !x264r1345 {{bq git-id : ed0467756f5a842249d86fb9622006f3939c72a2 Author : Jason Garrett-Glaser Date: Fri Nov 20 08:04:28 2009 -0800 Only print weightp stats if there were P-frames }} {{bq Pフレームがある場合のみweightpの統計を表示。 }} 表示面のみなので出力ビットストリームに影響なし。 !x264r1344 {{bq git-id : 4a31a47d88ca01b63d8a06be2592beaedc78b8f3 Author : Jason Garrett-Glaser Date: Wed Nov 18 13:47:04 2009 -0800 Faster lookahead with subme=1 If it hasn't been clear already, don't use subme=1 as a "fast first pass" option. Use subme=2 instead; 1 and below now enable a fast (lower quality) lookahead mode. }} {{bq subme=1でのlookaheadを高速化。 よく分かっていない場合には、subme=1を「高速な1st pass」のオプションとして使用しないこと。 subme=2を代わりに使用すること;1以下では高速な(そして低質な)lookaheadモードが有効になる。 }} "If it hasn't been clear already"のclearの訳に困ったが、多分外してはいないと思う。 changelogに書くべき内容ではないだろうが、ちょっと日本語訳にあたっての''愚痴''を。 訳を考えるにあたっては、往々にして、一見基本的で簡単そうに見える語の訳に困る。 口語上、簡単な語はその語の抽象的な「イメージ」をベースに意味が多く派生するが、そのイメージ(本質的な意味と言ってもいい)の真髄は母国語ではないものには身に付きにくい("clear"は比較的分かりやすいだろうが)。 日本語では共通するイメージの語(例えば訓読みの「とる」)を、意味を表す漢字(取る・採る・撮る・捕る・執る・盗る・獲る・摂る・録る)でより正確に表現する。 これらは「主体に対象の事物を帰属させる」という意味で共通のイメージを持っている。 同じように英語(というかアルファベット圏の言語)では、単純なgetやtakeに替えてより正確な意味を表す語(retrieve, adopt, capture, steal等)で表すだろう。 日本語でただ「とる」と言われた時に、外国人がどの「とる」であるか分かりづらいように、ただ"clear"と言われた時に、日本人がその本意を知ることは意外に難しい。 通常はコンテキスト(「とる」の場合、写真を〜、応募者を〜、ビタミンを〜、魚を〜、など)で判断するが、ここでのclearのコンテキストはただitとしか表されず、このitが後の節を受けているのか不定的なitなのかも判断しづらい。 clearではなくsure(確信している)と書いてあれば上記の訳に自信が持てるのだが、広い意味を持つclearと書かれると、訳す立場としてはつらい。 加えて、基本的な語は成句を生じる事が非常に多く、これによりさらに意味の取りうる範囲が広がる。 訳者の能力を問われる部分だと言えばその通りなのだが、例えば上記のgetやtake、他にはgiveを辞書で引いてみれば、戸惑う気持ちも少しは分かってもらえないだろうか。 !x264r1343 {{bq git-id : c0215c8a83aa9b543dd6930185d589d0ed835816 Author : Jason Garrett-Glaser Date: Mon Nov 16 15:23:58 2009 -0800 Faster weightp analysis Modify pixel_var slightly to return the necessary information and use it for weight analysis instead of sad/ssd. Various minor cosmetics. }} {{bq weightp解析を高速化。 pixel_varが必要な情報を返すように若干変更し、それをsad/ssdの代わりに重み解析に使用。 色々と小さなコスメティックス。 }} !x264r1342 {{bq git-id : e8501efbd235b1b5321adda8926e7a859beafd3c Author : Dylan Yudaken Date: Sun Nov 15 16:14:50 2009 -0800 Fix two issues in weightp If analysis decided on an offset of -128, x264 would create non-compliant streams. Fix some cases with nearly all intra blocks where analysis could pick very weird weights. Also add some asserts to check compliancy. }} {{bq weightpの2つの問題を修正。 解析部がオフセットを-128に決定した場合に、x264は規格に適合しないストリームを作成していた。 ほぼ全てがintraブロックの場合に解析部が非常におかしな重みを選び得るケースを修正。 また、規格適合性をチェックするいくつかのアサートを追加。 }} 「ほぼ全てがintraブロックの場合に…」の方の修正は、やや無理矢理直した形(恣意的な閾値を設定した)になっている。なお、上記の訳は直訳ではなく、ソースコード上のコメントにある"weird weights in frames that are mostly intra"を加味して意訳している。 このリビジョンでweightpが大分安定した模様だが、まだ油断はできない。 !x264r1341 {{bq git-id : 4f0a545fa7528b4820141ac6d0b8bbe2e643d905 Author : Alexander Strange Date: Sat Nov 14 22:16:18 2009 -0800 Allow compilation with non-Apple GCC on OS X }} {{bq OS X上で非AppleのGCCでのコンパイルを許可。 }} OS Xのビルドにのみ影響。 !x264r1340 {{bq git-id : 1d54b2c7f9110cb7c7af1059cf595db17ed96273 Author : Alexander Strange Date: Sat Nov 14 22:13:28 2009 -0800 Use __attribute__((may_alias)) for type-punning GCC thinks pointer casts to unions aren't valid with strict aliasing. See http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html#Type_002dpunning. Also use M32() in y4m.c. Enable -Wstrict-aliasing again since all such warnings are fixed. }} {{bq type-punning(型もじり)に__attibute__((may_alias))を使用。 GCCは共用体へのポインタのキャストはstrict aliasingで有効ではないと考える。 http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html#Type_002dpunningを見よ。 M32()をy4m.cでも使用。 係る警告が修正されたので-Wstrict-aliasingを再び有効に。 }} r1334の訳の注釈で「共用体にキャストすること自体がtype-punであると思う」と書いたのが的中した模様。-Wstrict-aliasingも戻されたのでこれで本当に解決したはず。 上記URLはGCCのマニュアルで、そこでは以下のように述べている。 {{bq access by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior, even if the cast uses a union type }} {{bq アドレスを取得して、その結果のポインタをキャストし、その結果の参照を外すことによるアクセスは、たとえそのキャストが共用体型を使用していても、未定義の動作となる。 }} そして具体的に以下のようなコードはダメだとハッキリ例示されている。 {{pre union a_union { int i; double d; }; int f() { double d = 3.0; return ((union a_union *) &d)->i; } }} r1334ではまさにこの共用体ポインタへのキャストで回避した''つもり''になっていた。 一応、osdep.hでGCC3.3.0以上の場合に #define MAY_ALIAS __attibute__((may_alias)) とし、それ以外ではMAY_ALIASを空定義としているが、他のコンパイラではどうしたらよいのだろうか。 TODO:共用体ポインタへのキャスト経由でのアクセスでは未定義の動作になるというのはGCC固有の仕様なのか、C言語の規格なのかは未確認。共用体にtype-punすること自体が未定義なのだろうか。それともaliasing ruleは最適化による問題だからそもそも規格では扱わない問題の可能性もあるだろうか。 !x264r1339 {{bq git-id : 82b80ef96b0ae74187f6f6a482bddb3f859df4f5 Author : Jason Garrett-Glaser Date: Sat Nov 14 19:58:46 2009 -0800 100l in deadlock fix }} {{bq デッドロックの修正での100l。 }} 10Lどころか100Lレベルの大ポカでしたということで。 !x264r1338 {{bq git-id : 6f5f8c02aa3d64e45d17e97d24a6593e8a13c2b2 Author : Kieran Kunhya Date: Sat Nov 14 19:01:09 2009 -0800 FLV muxing support }} {{bq FLVのmuxをサポート。 }} 出力形式にFLVが選択できるようになったということ。出力ファイル名の拡張子.flvを認識するようになり、--stdoutにはflvが追加。 以下のソースファイルが追加。 *output/flv.c *output/flv_bytestream.c *output/flv_bytestream.h !x264r1337 {{bq git-id : e76a4adb1c8ee27748847656450c815f60d2fe6d Author : Jason Garrett-Glaser Date: Sat Nov 14 18:40:22 2009 -0800 Fix rare deadlock introduced in weightp }} {{bq weightpによる稀なデッドロックを修正。 }} !x264r1336 {{bq git-id : 2a35a019c5e5710fddcee36976921347ef5ae7a7 Author : Jason Garrett-Glaser Date: Thu Nov 12 12:40:40 2009 -0800 Actually add -Wno-strict-aliasing to configure }} {{bq ホントに-Wno-strict-aliasingをconfigureに追加。 }} ビルド時の警告表示にのみ影響。エンドユーザには関係ない。 r1334ではchangelogに「追加」と書いてあったのに追加されてなかったということ。個人的にはこの警告が本当にGCC側のバグであるなら、x264では抑制せず残しておくべきだと思う。悪いのはGCCなのにx264側で警告を消してしまうと、いつかまたこのエイリアシング問題を忘れかけて、問題のある実装をしてしまった場合に気づくことができないからだ。 !x264r1335 {{bq git-id : 0e706cc9f3814f817b6bdef25e35ad1060d369b1 Author : Dylan Yudaken Date: Thu Nov 12 07:03:46 2009 -0800 Various weightp fixes Make weightp results match in threaded vs non-threaded mode. Fix two-pass with slow-firstpass. }} {{bq 様々なweightpの修正。 weightpがスレッド・非スレッドのモードで同じ結果になるようにした。 slow-firstpassでの2パスを修正。 }} !x264r1334 {{bq git-id : cbd43d1e31fae533de121c7c0dfcc13ebf41aa24 Author : Jason Garrett-Glaser Date: Thu Nov 12 05:25:32 2009 -0800 Fix all aliasing violations New type-punning macros perform write/read-combining without aliasing violations per the second-to-last part of 6.5.7 in the C99 specification. GCC 4.4, however, doesn't seem to have read this part of the spec and still warns about the violations. Regardless, it seems to fix all known aliasing miscompilations, so perhaps the GCC warning generator is just broken. As such, add -Wno-strict-aliasing to CFLAGS. }} {{bq 全てのエイリアシング違反を修正。 新しいtype-punning(型もじり)マクロは、C99仕様の6.5.7の最後から2つめの部に従い、エイリアシング違反なしのwrite/read-combining(合成書込・読込)を実行する。 しかしGCC 4.4は仕様のこの部を読んでいないようで、違反に関してそれでも警告する。 それでも、判明している全てのエイリアシングのコンパイルミスは直るようで、恐らくは単にGCCの警告生成部が壊れているのだろう。 そういうわけで、CFLAGSに-Wno-strict-aliasingを追加。 }} r1303の訳の注釈で「strict-aliasing ruleを破る可能性がある」と書いたのが的中したようで、r1303のコードは今回の修正対象に入っている。 ''2009/11/16追記:実際には修正できていなかった模様''、次の段落の記述はこのリビジョンの誤った主張に基づいているため、同様に誤っている。r1340を見よ。 今回の対策は、write/read-combiningを行うためのマクロを用意し、これらは当然type-punを行うため、共用体経由でアクセスするように実装することでエイリアシング問題を回避している。 共用体はtype-punを行うためにあるようなものなので、共用体の使用によってエイリアシング問題が出てはならない(問題が出るならコンパイラのバグである)。 C99の仕様はまだ読んでいないが、恐らくその6.5.7にはそういった趣旨のことが書いてあるのだろう。 TODO:C99の仕様書が手に入ったら上記を確認。あと、共用体にキャストすること自体がtype-punであると思うのだが、それは問題ないのだろうか。 エイリアシング問題はそれを意識していないと気づけない点が、プログラマとしては怖い。 ソースコード上では一見、問題ないように思えてしまう。 実際どうして問題になるのかは[[gcc option]]の-f(no)-strict-aliasingの項目を参照。 !x264r1333 {{bq git-id : b28d98bbc3174e6f38caea49a7c545204e3930d3 Author : David Conrad Date: Wed Nov 11 20:53:49 2009 -0800 Fix 10l in weightp on ARM }} {{bq ARM上のweightp内の10lを修正。 }} 変更しているコード自体は共通部のもの。 !x264r1332 {{bq git-id : 70f8869f1936558b33ee2ec58dbd85004aa6298b Author : Jason Garrett-Glaser Date: Mon Nov 9 21:22:41 2009 -0800 Fix one (of possibly many) miscompilations in weightp Use NOINLINE and some emms calls to fix emms reordering issues. This issue occurred with some GCC versions if threads > 1 and the phase of the moon was right. Also a cosmetic in x264.c. }} {{bq weightpの(もしかしたら多数のうちの)1つのコンパイルミスを修正。 NOINLINEといくつかのemms呼び出しを使用しemmsの再配置問題を修正。 この問題はいくつかのバージョンのGCCでthreads > 1、かつある月齢の場合に発生していた。 また、x264.cのコスメティックス。 }} ''「ある月齢の場合」''って何だよ、と思うだろうが、これは"the phase of the moon was right"という冗談めかした言い回しを直訳したもの。特定できない原因や入り組んでいて説明しづらいものを誤魔化した表現で、''「ご機嫌によって」''くらいが妥当な訳になる。もうちょっと冗談のニュアンスを残すなら「猫がくしゃみをしたら」等の表現でもいいかも。 emms命令はMMX命令の1つで、MMXでの計算終了後、MMXではない通常の浮動小数点演算を行う前に呼び出すべき命令だ。これがコンパイラの最適化によって実行順序を変更され、それによって浮動小数点演算がおかしくなるバグを修正したということ。インライン関数の展開(埋め込み)時に発生することがあるのでNOINLINEを使用している。 インテルは初代Pentiumからx87命令の実行ユニットを全ラインナップで搭載・統合したが、あまり使用されていなかった。MMXはそのx87命令用のレジスタを使いまわしており、x87の浮動小数点命令と同時に使用することができない。そしてx87演算からMMX演算へは自動で状態が切り替わるが、MMX演算からx87演算への切り替えにはemms命令が必要だ。この切り替えにはかなりクロック数がかかるので無駄にemmsを発行したくはないが、バグを生じては元も子もない。なお、後のSSE系列は専用のレジスタを持つためemms命令も切り替え自体もない。このあたりを語りだすと長くなるので以下略。 !x264r1331 {{bq git-id : c3e72f64021e535658f61e86dc3a21325e88ae11 Author : Jason Garrett-Glaser Date: Mon Nov 9 09:18:03 2009 -0800 Fix pixel_ssd on win64 Didn't preserve XMM registers, may or may not have caused problems. }} {{bq win64上のpixel_ssdを修正。 XMMレジスタを保存していなかったが、問題を起こしていたか否かは不明。 }} !x264r1330 {{bq git-id : af612d79aaaddfaac486d602ce3303836c45bbc6 Author : Steven Walters Date: Sun Nov 8 22:18:35 2009 -0800 Fix weightp logfile parsing on MinGW }} {{bq MinGW上のweightpのログファイル解析を修正。 }} !x264r1329 {{bq git-id : 03639d08bb4a1b93d2c4529a3bfec517dd905879 Author : Loren Merritt Date: Mon Nov 9 05:27:29 2009 +0000 cosmetics }} {{bq コスメティックス。 }} 大きめのコスメティックスでコードが若干変わっていたりするので注意。10Lがないとは限らない。 !x264r1328 {{bq git-id : 2bedf8945f921774714dacf5f0668e01c1810b46 Author : David Conrad Date: Sun Nov 8 20:12:54 2009 -0800 Fix weightp on ARM + PPC No ARM or PPC assembly yet though. }} {{bq ARM + PPC上のweightpを修正。 ただしARMもPPCもアセンブリはまだ。 }} !x264r1327 {{bq git-id : 87de2346225721e8ca68a1b59bc87133fc598a42 Author : Dylan Yudaken Date: Sun Nov 8 17:59:08 2009 -0800 Weighted P-frame prediction Merge Dylan's Google Summer of Code 2009 tree. Detect fades and use weighted prediction to improve compression and quality. "Blind" mode provides a small overall quality increase by using a -1 offset without doing any analysis, as described in JVT-AB033. "Smart", the default mode, also performs fade detection and decides weights accordingly. MB-tree takes into account the effects of "smart" analysis in lookahead, even further improving quality in fades. If psy is on, mbtree is on, interlaced is off, and weightp is off, fade detection will still be performed. However, it will be used to adjust quality instead of create actual weights. This will improve quality in fades when encoding in Baseline profile. Doesn't add support for interlaced encoding with weightp yet. Only adds support for luma weights, not chroma weights. Internal code for chroma weights is in, but there's no analysis yet. Baseline profile requires that weightp be off. All weightp modes may cause minor breakage in non-compliant decoders that take shortcuts in deblocking reference frame checks. "Smart" may cause serious breakage in non-compliant decoders that take shortcuts in handling of duplicate reference frames. Thanks to Google for sponsoring our most successful Summer of Code yet! }} {{bq Weighted P-frame(重み付きPフレーム)予測。 DylanのGoogle Summer of Code 2009のツリーをマージ(統合)。 フェードを検出し重み付き予測を使用することで圧縮(率)と質を向上。 "Blind"モードは、JVT-AB033にあるように、一切の解析無しに-1のオフセットを使用することで全体的に小さな質の上昇を生む。 デフォルトである"Smart"モードは、フェード検出も実施し適宜に重みを決定する。 MB-treeは"smart"解析の結果をlookaheadで考慮に入れ、さらにフェードの質を向上する。 psyがon、mbtreeがon、interlacedがoff、そしてweightpがoffである場合、それでもフェードの検出は実施される。 ただし実際の重みを作るのではなく質を調整するために使用される。 これはベースラインプロファイルでエンコードする際のフェードの質を向上する。 weightpでのインターレース符号化のサポートはまだ追加していない。 lumaの重みのサポートのみの追加であり、chromaの重みはない。 chromaの重み用の内部コードは入っているが、まだ解析部が存在しない。 ベースラインプロファイルではweightpがoffである必要がある。 全てのweightpのモードは、参照フレームのデブロッキングチェックでショートカット(省略処理)をする規格に適合しないデコーダで、小さな破損を引き起こしうる。 "Smart"は、参照フレームの複写処理でショートカット(省略処理)をする規格に適合しないデコーダで、深刻な破損を引き起こしうる。 我々のこれまでで最も成功したSummer of Codeを支援してくれたGoogleに感謝! }} X264_BUILD 79。 mbtreeの追加以来、期待が非常に高まっていたweight'''p'''がコミットされた。 weight''b''は重み付きBフレームだったが、これはPフレームを重み付けでエンコードする機能になる。 コマンドラインオプションに''--weightp''が追加。0=無効, 1=Blind, 2=Smart。 フェードの質が大きく改善することが期待できるが、''lumaのみ、interlaced(MBAFF)との併用不可''、内部的にはFIXMEやTODOが多く残っているなど、まだ荒削りに感じられる。 パッチも非常に大きいので、個人的には安定するまでしばらく掛かると思う。 デコーダ側の実装によっては再生映像がおかしくなるケースが普通にあるようなので、''映像が破綻=x264のバグと即断'''''しないように'''。もちろんx264のバグの可能性も多々あるが、デコーダのバグの可能性もある。訳者自身は確認していないが、CoreAVCでは既に問題発生が確認されているようだ。 フェードは画(映っているオブジェクト)的には同じであっても明るさが異なる画の連続であり、weightpなしではこれらを同じ画と認識しづらかった。このため、''似た画なのにIフレームになる、Pになってもintra MBが多い、動き検索が正しく当たらずMVが錯綜する(結果としてCRFやmbtreeが混乱する)''、などの問題が発生していたはず。weightpによりこれらが解決するため、まず''GOP構造とビット配分が適正になり、Pフレーム自身のRDも飛躍的に改善され、ひいてはこれらを参照するBフレームにも良い影響を与える''だろう。 [JVT-AB033(英文)|http://wftp3.itu.int/av-arch/jvt-site/2008_07_Hannover/JVT-AB033.zip]はJVTへのcontribution(寄稿)の一つで、題は"Weighted Prediction Alternative to Adaptive Interpolation Mechanisms"。 内容は重み付き予測(Pに限らない)の効果を述べたもので、オフセットが-1という簡単なもの(上記Blindに相当)でも、H.264のリファレンスソフトであるJMでかなりの効果(最大で''約8%のRD性能改善'')があったと示されている。 この文書で読む限りは、''特にHD映像で有効''な点も特徴だ。 あくまでJMでの結果なのでx264に直接は当てはめられないが、効果は非常に大きいと見ていい。 余談だが、JVT-AB033は[アサナシオス・レオンタリス(Athanasios Leontaris)|http://www.code.ucsd.edu/~aleontar/]という JVT、Dolby、UCSD(カリフォルニア大学サンディエゴ校)に所属する電気・計算機の工学博士が主な著者。 こういう文書を読むと、偉い人の研究成果が訳者のような下々の者に降りてきているんだなぁ、としみじみ実感する。 !x264r1326 {{bq git-id : 3daa02e9c79ec46fd980bcfcd317df45539c91f6 Author : Steven Walters Date: Sun Nov 8 11:53:48 2009 -0800 Fix assert failure in the case of forced i-frames Note that this applies to non-IDR i-frames, not IDR-frames. This fix is also required for future open-gop. }} {{bq 強制iフレームの場合のアサート失敗を修正。 これはIDRフレームではなく、非IDRのiフレームに適用されることに注意。 この修正は将来のopen-gopにも必要。 }} !x264r1325 {{bq git-id : 02fe6a5fe20b71d712c14525b14f95f1e7927a91 Author : Steven Walters Date: Sat Nov 7 17:07:28 2009 -0800 Fix issues relating to input/output files being pipes/FIFOs }} {{bq パイプ/FIFOである入力/出力ファイルに関連する問題の修正。 }} --stdout/--stdinというオプションが追加。 パイプ等ではfseek等ができないため、入出力可能な形式が限られる。 stdoutはraw, mkvから選択、stdinはyuv, y4mから選択。 !x264r1324 {{bq git-id : 3d1a1287721a3a8bfd85d0557e4fe8edbd138adc Author : David Conrad Date: Sat Nov 7 09:25:18 2009 -0800 Various ARM-related fixes Fix comment for mc_copy_neon. Fix memzero_aligned_neon prototype. Update NEON (i)dct_dc prototypes. Duplicate x86 behavior for global+hidden functions. }} {{bq 様々なARM関係の修正。 mc_copy_neonのコメントを修正。 memzero_aligned_neonのプロトタイプを修正。 NEONの(i)dct_dcプロトタイプを更新。 global+hidden関数につき、x86の振る舞いを再現。 }} !x264r1323 {{bq git-id : 820380f981da35ae4f8fc124cb8b5ee1c4cbad4b Author : Jason Garrett-Glaser Date: Wed Nov 4 00:03:14 2009 -0800 Fix miscompilation with gcc 4.3 on ARM Aliasing violation in spatial prediction caused nasty artifacts. Shut up two other GCC warnings while we're at it. }} {{bq ARMのgcc 4.3でのコンパイルミスを修正。 spatial予測でのエイリアシング違反が汚いアーティファクトを引き起こしていた。 その際の、その他GCCの警告2つを黙らせた。 }} エイリアシング違反については[[gcc option]]の-f(no)-strict-aliasingを参照。 !x264r1322 {{bq git-id : bea99fbf88cc0da3f85f6ae6cccaf483c5d1fc1b Author : Jason Garrett-Glaser Date: Tue Nov 3 23:15:35 2009 -0800 Fix extremely rare infinite loop in 2-pass VBV Implicit conversion from double->float lost enough precision to cause the loop termination condition to never trigger. Bug report by Tal Aloni. }} {{bq 2-pass VBVでの極希な無限ループを修正。 double→floatの暗黙的な変換は十分な精度を失い、ループの終了条件を決して発生させなくしていた。 Tal Aloniによるバグレポート。 }} !x264r1321 {{bq git-id : 028b3ffa9071042468f2cc51580fa6ef65d6ff95 Author : Anton Mitrofanov Date: Sat Oct 31 19:51:14 2009 -0700 Fix large file support, broken in r1302 }} {{bq 大きなファイルのサポートを修正、r1302で破壊していた。 }} !x264r1320 {{bq git-id : 96bad1a71c656f4f05632d685d4b91bd54d5ce58 Author : Jason Garrett-Glaser Date: Fri Oct 30 18:58:03 2009 -0700 Dramatically reduce size of pixel_ssd_* asm functions ~10k of code size eliminated. }} {{bq pixel_ssd_*のアセンブラ関数のサイズを劇的に削減。 コードサイズを〜10K除去。 }} !x264r1319 {{bq git-id : 678a703fd9528d2b508b542ce5e289b4f0bae3b7 Author : Loren Merritt Date: Sat Nov 7 06:09:47 2009 +0000 fix bottom-right pixel of lowres planes, which was uninitialized. weirdly, valgrind reported this only with --no-asm. }} {{bq 初期化されていなかった低解像度プレーンの右下のピクセルを修正。 おかしな事に、valgrindは--no-asmの場合のみこれを報告した。 }} !x264r1318 {{bq git-id : fe83a906ee1bb5170b112de717818e278ff59ddb Author : Jason Garrett-Glaser Date: Thu Oct 29 12:28:37 2009 -0700 Further reduce code size in bime ~7-8 kilobytes saved, ~0.6% faster subme 9. }} {{bq bimeの更なるコードサイズ削減。 〜7・8kb程度を節約、subme 9を〜0.6%高速化。 }} これもループ再ロール・非インライン化による高速化だ。Dark Shikari氏の中で流行してるのかもしれない。 !x264r1317 {{bq git-id : 5c7133b0607b220a02e37cf72612c97484384cd8 Author : Anton Mitrofanov Date: Wed Oct 28 12:57:11 2009 -0700 Fix case in which MB-tree didn't propagate all data correctly Should improve quality in all cases. Also some minor cosmetic improvements. }} {{bq MB-treeが全データを正しくpropagate(伝播)しないケースの修正。 全てのケースで質が改善するはず。 また、いくつかの小さなコスメティック的改善。 }} !x264r1316 {{bq git-id : 7016c83611ade1f0d54d62eec3a03fccdb43700d Author : Jason Garrett-Glaser Date: Tue Oct 27 16:01:46 2009 -0700 Take into account chroma MV offset during interlaced motion search Small improvement in interlaced compression. }} {{bq インターレースでの動き検索中にchroma MV offsetを考慮する。 インターレース圧縮の小さな改善。 }} !x264r1315 {{bq git-id : d4b7db5c840661a5853369300e704b20c7c3ff53 Author : Jason Garrett-Glaser Date: Tue Oct 27 15:08:37 2009 -0700 Slightly faster ssse3 width4 chroma MC Cacheline-aware in the same fashion as width8, but not conditional. }} {{bq SSSE3 width4 chroma MCを若干高速化。 width8と同様のやり方でキャッシュラインを意識、ただし条件付ではない。 }} !x264r1314 {{bq git-id : 40a4708b9d869d7b13cb1f1afc65590d2fc90f9b Author : Jason Garrett-Glaser Date: Tue Oct 27 14:01:46 2009 -0700 Eliminate some rare cases where MB-tree gave incorrect results in B-frames Also get rid of some unnecessary memcpies. }} {{bq MB-treeがBフレームで不正な結果を出していたいくつかの稀なケースを排除。 また、いくつかの不要なmemcpyを除去。 }} !x264r1313 {{bq git-id : 35146ef7d37a04e1f43ddb425f0e43311e24c5fc Author : Anton Mitrofanov Date: Tue Oct 27 12:28:07 2009 -0700 Fix cases in which b-adapt 1 could result in AUTO-type frames. This didn't actually cause any issues, but it removes the need for the fixing-up code that prevented said issues. }} {{bq b-adapt 1が結果として自動タイプのフレームに帰着する可能性があるケースを修正。 これは実際には問題を引き起こしてはいなかったが、(この修正は)上記問題を防いでいたコードを修正する必要性を除去する。 }} 言い回しがわかり辛いが、「内部的には意図しておらず望ましくない動作だが、外部的にはなんとかなっていた」部分を修正したということだろう。 !x264r1312 {{bq git-id : 1f9c733dc27ae279943a3ddd7eaf8a50cbf4dc2d Author : Jason Garrett-Glaser Date: Mon Oct 26 12:53:07 2009 -0700 Motion compensation optimizations Turning off inlining saves a whole boatload of code size for near-zero speed cost. Simplify offset calculation. Various other optimizations. }} {{bq 動き補償の最適化。 非インライン化はほぼゼロの速度コストでコードサイズの量を節約する。 オフセットの計算をシンプル化。 その他様々な最適化。 }} boatloadは直訳で「(船の)最大積載量、船荷」という意味だが、修飾的表現法と思われるのでここでは単に「量」と訳した。 C/C++言語の初心者や、最適化初心者の方は「''非''インライン化でどうして遅くならないのか?」と疑問に思うかも知れない。''教科書的には、インライン化が高速化手法''であり、それを解除すると言うことは「遅くすること」のように思えるだろう。非インライン化でも高速になる理屈を理解するためには、そもそも、''どうしてインライン化すると一般的には高速になるのか''を理解していなければならない。そしてCPUの内部動作に関する知識・想像力と少々のアセンブラ知識が必要だ。 インライン化は、端的に言って''命令の取得段階が効率的に動作する''ことと、''関数呼び出し手続きが省略される''ことによって高速化する。 「命令の取得段階が効率的に動作する」とは、命令コードが連続していることにより、コードキャッシュに先読みされている命令がそのままCPUのコアに投入され実行されること、そしてそれにより命令のプリフェッチ&デコードのパイプラインがストール(キャンセル)せず、全体的に言ってCPUの''投機的動作が無駄にならない''ことを指す。 関数呼び出し手続きに関しては、関数への引数をスタックに積んだり、[[gcc option]]の-f(no-)omit-frame-pointerで説明しているスタックフレームの確保・解放のような、一般の関数で作成される''命令そのものが省略・減少''することを指す。 しかし、インライン化された関数が大きなもので、その関数をループ以外で複数回呼び出すことを想像してほしい。この場合、呼び出し元の関数が非常に肥大化することは想像が着くだろう。こうなると、キャッシュ〜デコードの投機的動作自体は上手く動作するが、せっかくのキャッシュが''再利用はされない''ので、命令を読み込む''メモリアクセスが常に発生し、足を引っ張られてしまう''。また、呼び出される関数が大きい場合、関数呼び出し手続きのオーバーヘッドは処理本体に比べて割合が低く、''省略することによる恩恵が小さくなる''。 つまり、一定の大きさを持ち、ループ以外で複数回呼び出される関数は、インライン化しない方が''コードキャッシュの再利用率の観点から高速''になる。ここで「一定の大きさ」とは、「コードキャッシュには収まるが関数呼び出し手続きのオーバーヘッドが割合的に重要でない程度」の大きさを指す。なお、ループで複数回呼ばれる関数は、大きさが一定以下であればコードキャッシュが有効に働くため、インライン化した方が若干高速になる。 今回の変更は、実質的にはr1193の''ループ再ロール''(これも一般的には''ループアンロール''が高速化の手法だがその逆を行っている)と同じ意味を持つ。そしてループ再ロールにはソースコードが読みやすくなる副次的効果もある。が、ループ再ロールも非インライン化も、その効果はCPUのコードキャッシュのサイズに依存するので、難しい部分でもある。 !x264r1311 {{bq git-id : e361348b54d636d2bffd622c96d2255c0640c220 Author : Jason Garrett-Glaser Date: Sun Oct 25 19:41:10 2009 -0700 Minor CAVLC optimizations }} {{bq CAVLCの小さな最適化。 }} !x264r1310 {{bq git-id : ec46ace7eab97cbde6fd50ae18de5c6e063fe1de Author : Loren Merritt Date: Sun Oct 25 19:34:12 2009 +0000 cosmetics }} {{bq コスメティックス。 }} !x264r1309 {{bq git-id : 6a4277ea792be0c51ccd195df61d92a12b60f02a Author : Jason Garrett-Glaser Date: Sun Oct 25 09:14:27 2009 -0700 ISC-license x86inc.asm As the assembly abstraction layer is very useful in non-x264 projects, it is now ISC (simplified BSD) so that others, even in commercial projects, can use it as well. }} {{bq x86inc.asmをISCライセンスに。 アセンブリの抽象化レイヤはx264以外のプロジェクトでも非常に有用なので、ISC(単純化したBSD)にし、これによって他の、商用プロジェクトでさえ、使用することが可能に。 }} コメント部のライセンス文の変更のみなのでバイナリに影響なし。 !x264r1308 {{bq git-id : c9d2c06872347b519f44262bb4ed85198c9ca1b1 Author : Jason Garrett-Glaser Date: Fri Oct 23 16:20:39 2009 -0700 Various minor CABAC optimizations }} {{bq 色々と小さなCABACの最適化。 }} !x264r1307 {{bq git-id : ece74ca07cd4f7729bdf6ba5b8be06c30da3a1af Author : Lamont Alston Date: Fri Oct 23 11:01:13 2009 -0700 Fix bug in b-pyramid strict Bug caused invalid streams in some situations. }} {{bq b-pyramid strictのバグを修正。 バグはいくつかのシチュエーションで無効なストリームを生んでいた。 }} !x264r1306 {{bq git-id : b1ad8d06bcff3f14ddfc6e550d4d50f2d4847a96 Author : Jason Garrett-Glaser Date: Fri Oct 23 02:34:49 2009 -0700 Remove non-mod16 warning Compression only "suffers" by an extremely marginal amount and too many people misinterpret the warning. }} {{bq non-mod16の警告を除去。 圧縮(率)は非常に取るに足らない量で"suffer"なのであるが、あまりにも多くの人々が警告を誤解している。 }} 出力に影響なし。 幅・高さが16の倍数ではない場合に"width or height not divisible by 16 (WxH), compression will suffer."と表示していた警告を削除したということ。 "suffer"は「苦しむ、(被害・存在を)被る」という意味だが、ここでは警告文の一部の引用とみなして訳さずにおいた。 !x264r1305 {{bq git-id : b89ca0413c5a7114111ba0c76bcd7e52eb0ede93 Author : Jason Garrett-Glaser Date: Thu Oct 22 22:38:32 2009 -0700 Fix two warnings + some minor optimizations }} {{bq 警告の修正2つ+小さな最適化をいくつか。 }} hackyな手段で配列のインデックスが負の値になる場合の対策をしていたものを、マクロに置き換えることで正当な方法に修正している。 標準Cでどう定義されているのかは知らないが、負の添字で配列にアクセスした場合の動作は、コンパイラや動作プラットフォームによっては未定義かもしれないので、こういう修正は地味に重要だろう。 !x264r1304 {{bq git-id : ec3b5bfa4f1e5e53ab962db4341b9f78b9e50c86 Author : Jason Garrett-Glaser Date: Mon Oct 19 22:38:01 2009 -0700 Fix a typo in b-pyramid help And an errant space in common/macroblock.c }} {{bq b-pyramidのhelpのタイポ(誤植)を修正。 それとcommon/macroblock.cの変なスペース文字も。 }} 出力に影響なし。 !x264r1303 {{bq git-id : 3679792d621cc95222d0aef3097c6d16e72852b8 Author : Henrik Gramner Date: Mon Oct 19 12:57:47 2009 -0700 A bit more write-combining in macroblock_cache_load }} {{bq macroblock_cache_loadでさらにもう少しwrite-combining。 }} write-combiningとは、複数の項目を一括して書き込む高速化手法のこと。 ここでは、本来8bit×4回のアクセスをすべきメモリ領域に32bitアクセスで一括書き込みをしている。 これによってメモリアクセス回数を減らすと同時に、32bitCPUでは最も高速に扱えるネイティブな幅のメモリアクセス手段を用いていることになる。 アラインの確証があれば比較的良く使う手段だが、strict-aliasing rule([[gcc option]]の-f(no)-strict-aliasingの項目を参照)を破る可能性があるので注意したほうが良い。 !x264r1302 {{bq git-id : 6169a3f6c01ca95ac5f17d65c76af6830954789d Author : Steven Walters Date: Sat Oct 24 00:23:50 2009 +0000 split muxers.c into one file per format simplify internal muxer API }} {{bq muxers.cをフォーマットごとに1つのファイルに分割。 内部のmuxer APIをシンプル化。 }} !x264r1301 {{bq git-id : bcba15dbbc0d6be28129b85d541a0bc5050bab40 Author : Jason Garrett-Glaser Date: Mon Oct 19 02:43:48 2009 -0700 Update fprofile with the latest change to b-pyramid }} {{bq b-pyramidへの最近の変更に伴いfprofileを更新。 }} 一般のユーザには関係ないテスト用設定の変更。 "latest"の直訳は「最新の」だが、b-pyramidにモード指定が必要になったことへの対応なので「最近の」と訳した。 !x264r1300 {{bq git-id : 909bdedba6077a90a361641232ba1840094f19fe Author : Steven Walters Date: Sat Oct 17 12:54:41 2009 -0700 Fix assertion fail and incorrect costs with pyramid+VBV Deal properly with QPfile'd B-refs. x264 should handle multiple B-refs per minigop now, though only via forced frametypes. }} {{bq pyramid+VBVでのアサーションの失敗と不正コストを修正。 QPfileによるB-refを正しく扱う。フレームタイプ強制の場合のみ、x264がminigop中の複数B-refを処理するようになるはず。 }}