このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。
x264-changelog-jp r1300-r1399
r1300-r1399のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。
前:x264-changelog-jp r1200-r1299 - 次:x264-changelog-jp r1400-r1499
x264r1399
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.
様々な性能上の最適化。
direct動きベクタの格納領域を小さくシンプルにし、--direct autoを高速化。
キャッシュのビットを節約するために様々な配列を縮小。
CABACでのBマクロブロックタイプの書き込みをシンプル化＆再構成。
いくつかの欠けていたALIGNEDマクロを追加。
x264r1398
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.
AMD M300やそれと同等の新しいCPU上でのクラッシュを修正。
どうやらこれらのCPUはSSE4aを搭載しているが、非アラインSSEではないようだ。
x264r1397
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.
subme < 6でのintra refreshを修正。
また、intra maskingの質を改善。
x264r1396
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.
複数の--tuneオプションのサポートを追加。
tuneがコンフリクト（競合・矛盾）する場合には並べられた順番に適用する。
Psyチューニング、つまりfilm/animation/grain/psnr/ssimは組み合わせられない。
また、--profileがプロファイルそのものを強制するのではなく、プロファイルの制限を強制するものだと明示。
オプションの指定方法にのみ影響。
Psyの調整がかからないものはfastdecodeとzerolatencyくらいなので、それほど大きな恩恵があるわけではない。複数指定時には"--tune film,fastdecode"というようにカンマで区切る。内部的には区切り文字は",./-+"のどれかであれば良いが、混乱の元なのでまぁカンマがいいだろう。
x264r1395
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.
解析部の調整と様々なバグ修正。
x264の最も古いバグを修正：b16x8解析はpredict_mvに対して誤った幅を使用していた。
bsub16x16解析で僅かに良好なMV予測のためにcache_refの呼び出しを修正。
Bパーティション解析が参照フレームコストを考慮するようにした。
その他色々と小さな変更。
全体的にBフレームにおけるモード決定と動き検索を非常に僅かに改善。
x264r1394
git-id : 6662db34e524a6ff1f935cce779473d3882d046c
Author : Loren Merritt
Date: Thu Jan 14 14:52:12 2010 -0500
More --me tesa optimizations
--me tesaの更なる最適化。
x264r1393
git-id : 7ff686756e042f625fae904d9e059cd489406ed8
Author : Jason Garrett-Glaser
Date: Thu Jan 14 10:39:10 2010 -0500
Fix typo in configure
configureのタイポ（誤植）を修正。
ビルドにのみ影響。
x264r1392
git-id : 1d3ab22126c1369a75fc8d5b933159c4a53f35c9
Author : Jason Garrett-Glaser
Date: Thu Jan 14 00:07:30 2010 -0500
Make --fps force CFR mode
--fpsでCFRモードを矯正するようにした。
オプションの指定方法にのみ影響。
x264r1391
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.
量子化マトリックス処理における意図的な配列のオーバーフローを除去。
何も問題は起こしていなかっただろうが、非常に見苦しく邪悪だった。
x264r1390
git-id : 918ca1e55351446478d4dcee5936c5843bf79925
Author : Jason Garrett-Glaser
Date: Wed Jan 13 20:16:13 2010 -0500
Faster --me tesa
--me tesaを高速化。
x264r1389
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.
win32においてdynamicリンクのx264に対するstaticなpthreads（の処理）を修正。
staticなpthreadに必要な初期化コードを新しいDLLmain関数に追加。
pthreadはstaticで、かつlibx264がDLLとしてビルドされる際のコードに、static pthreadに必要な初期化コードが追加された。
x264dll.cが追加。
x264r1388
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).
includeされたgetopt.cにgetopt_longを追加。
getoptが動かない、または存在しないOS（例：Solaris）でのオプション処理を修正。
x264r1387
git-id : ecca2f572b584f8f0e006a0f82048e30ada75b9c
Author : Jason Garrett-Glaser
Date: Tue Jan 12 20:14:35 2010 -0500
Faster psy-trellis init
Remove some unncessary zigzags.
psy-trellisの初期化を高速化。
いくつかの不要なzigzagを除去。
x264r1386
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.
intraモードの利用可能性の処理をシンプル化。
僅かに速く、バイナリサイズが1.5kb小さくなり、コードが少なくなった。
意外と変更量は大きい。
x264r1385
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 .
freeのコールバックを修正、x264_encoder_parameters関数を追加。
param_freeコールバックが設定されていた場合、x264はfreeの後に渡されたパラメータ構造体を使おうとしていた。
恐らくこの領域のコールバックを使用するプログラムはまだなかったため、多分問題は起きていなかっただろう。
新しい関数、x264_encoder_parametersが利用可能に。
この関数は呼び出し側アプリケーションが現在のエンコーダパラメータの状態を把握することができるようにする。
x264cliではこれを、set_paramに使用されるパラメータ構造体に対してx264_encoder_openが行う変更に関わらず、それ（パラメータ構造体）が最新であることを保証するために使用する。
X264_BUILD 83。
encoder_reconfig等が起こった場合にも、libx264を使用するアプリケーションがその内容を知ることができるように。
x264r1384
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.
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
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%.
weightpの動き検索を高速化。
blind重みにおける複製では、全検索をする代わりにメインの検索とqpel-refineから動きベクタをコピー。
p8x8の早期終了を修正、blind重みとの組み合わせで予期せぬ結果になっていた。
全体的に、わずかに圧縮率を減少させるが、潜在的にはスピードを5%超改善するはず。
複製参照はblind weightedな事を除けば単なる複製なのだから、基本的にはほぼ同じMVとなるはずであり、再度やり直すのは無駄だから処理を省こう、ということ。
仮訳の時点では"For blind-weight dupes"のdupesの解釈を誤っており、どうやら本当はduplicatesの意味だったようなので訳を修正した。
x264r1382
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.
低解像度プレーンにより正しいパディング定数を使用。
低解像度解析はインターレースを意識しないので、インターレースビデオのために垂直パディングを二重化する必要はない。
x264r1381
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.
valgrindで見つかったいくつかの不正な読込を修正。
不正なIフレームの参照カウントによってTemporal（時間軸）予測器の計算がミスリードされて（間違った方向に導かれて）いた。
x264r1380
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.
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
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 .
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では対応がなされたらしい。
ソースレベルではinput/ffms.cとinput/lavf.cが追加され、input/vfw.cが除去された。ffmpegのライブラリのうち実際に使用されるライブラリはlibavformat, libavcodec, libswscaleで、ffmpeg r18351以上の物が必要。FFMS2はC++で書かれたライブラリなので、環境によってはLDFLAGSに-lstdc++が入る。
x264r1378
git-id : 27355a2ba90516b0c280e026eb9c35fbf5f27a57
Author : Jason Garrett-Glaser
Date: Tue Dec 15 16:59:00 2009 -0800
More help typo fixes
更なるヘルプのタイポ（誤植）修正。
x264r1377
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)
入力が1<<31を超える場合のx264_clzを修正。
（x264がそのような入力を生成することはないが）
「1<<31を超える」とは32bitをオーバーフローしているようなデータということ。
x264r1376
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.
weightp == 1の場合にsum/ssd解析を行わない。
コメントとヘルプのタイポ（誤植）を修正。
プログラミングをしない人に注釈すると、「==」はC言語において「等しい」の意味で、このchangelog自体はタイポしているわけではない。
x264r1375
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.
2-passレートコントロールのバグを2つ修正。
last_qscale_forは2passの初期化コードで設定されていなかった。
abr_bufferは複数スレッドのケースであまりに小さすぎだったので、スレッド数に基づいて適宜バッファサイズを増加。
多スレッドの2-passモード、特にアニメのような極端に大きなIフレームの場合に、著しく画質を上昇するかもしれない。
ここでいうスレッドは通常のスレッドでsliced_threadsではない模様。
"way too small"のwayは強調。
x264r1374
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.
Avisynth-MTと2.6の互換性を修正。
なぜAvisynth 2.6でYV12変換が強制されるかをユーザに説明。
必要なDistributor()の呼び出しを追加することによりAvisynth-MTスクリプトでのエンコードを修正；そのようなスクリプトでの速度が期待するレベルに戻った。
x264r1373
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.
mingwによるzone解析の修正。
どうやら、MinGWは並外れたおバカさん達一味の手にあるようなので、MinGWは基本的な文字列関数であるstrtok_rを持たない。
そういうことなので、zoneの解析に於けるstrtok_rへの依存を除去。
以前は、レートコントロール以外のzoneの使用は失敗していた。
MinGWがMincrosoft製のmsvcrt.dllに依存していることから「並外れた〜」と表現している。まぁ、商業的・一般的意味でMicrosoftが善か悪かはともかくも、Microsoft製品の実装・仕様はGeek達にとって技術的に納得がいかないことが多々あるのは確か。
evidentlyは基本的には「明らかに」という意味だが、「証拠が指し示すところでは」というような婉曲的表現のようで、若干の皮肉のニュアンスがある模様。これを「どうやら」「見たところ」と訳すことがあるので、こちらを採用した。
x264r1372
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.
lookaheadの更なる最適化。
subme 1において、qpel検索を全く行わず、それに従いtemporal MVを丸める。
fullpel（1ピクセル単位）予測チェックのみを行うために、subme 1では内部のsubmeをやめた。
その他の小さな最適化。
今更だがふと思いついたので注釈すると、qpel検索とは1/4ピクセル単位での動き検索のことを指している。1/2ピクセル単位だとhpelなので、つまりはq＝quarter、h＝halfの意味。pelは、正確なところが不明だが、pixelの略だと思われる。
x264r1371
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
以前のコミットで不足していた雑多で小さな変更群。
sliced threadもbool（真偽値）化。
不使用の整数をdct-a.asmから除去。
presetのドキュメント内の少数のタイポ（誤植）/小さな間違いを修正。
スライスベースのスレッド化はsliced threadと記載されることが多いようだが、これの訳に困るので今後は訳さない方向で。
x264r1370
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.
r1364でのdirect=auto/temporalのレグレッションを修正。
バグはフレーム参照の処理に於いて稀な条件の競合を引き起こしていた。
これはBフレームに於いて無効なビットストリームをもたらすことがあり、非常に稀にはクラッシュしていた。
やっぱりあったかといったところで。
x264r1369
git-id : ec8e58637b97edaea00f022e11d15ee8a81466ab
Author : Jason Garrett-Glaser
Date: Tue Dec 8 17:46:55 2009 -0800
Add fast pskip to x264 SEI info header
x264のSEI情報ヘッダにfast pskipを追加。
x264r1368
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.
Avisynth入力に小さなシークの修正。
入力の最後で--seekで過去にシークするのは同じフレームが延々と繰り返される結果になる。
x264r1367
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.
MB-tree + B-pyramidのサポートを追加。
B-adapt 2をその計算上pyramidを考慮するように修正。
一般的にpyramidがonの場合により多くのBフレームが使用される結果になる。
必要な並べ替えを扱えるようにMB-treeのstatsファイルの読み込みを修正。
パス間でkeyintまたはpyramidを違わせると致命的エラーになる。
x264r1366
git-id : ca1112b373bd6c16a57350913a4a6cc4611b2d16
Author : Jason Garrett-Glaser
Date: Mon Dec 7 18:34:05 2009 -0800
Use aliasing-avoidance macros in array_non_zero
エイリアシング回避マクロをarray_non_zeroで使用。
x264r1365
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.
8x8 interlace zigzagのMMXバージョン。
Nehalem上でSSSE3と同じくらい速い（そしてConroe/Penrynではより速い）ので、SSSE3バージョンを削除。
x264r1364
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.
スライスベースのスレッド分割のサポートを復活。
--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
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.
presets/tunes/profilesにより詳細なヘルプを追加。
それらが何のオプションを使用しているかを表示。
x264r1362
git-id : e5faf712fccefd1f29319b1547714f3d894e4dba
Author : Jason Garrett-Glaser
Date: Sat Dec 5 03:19:44 2009 -0800
qpel RD no longer needs mbcmp_unaligned
qpel RDがmbcmp_unalignedを必要としないように。
x264r1361
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
全ての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とする）を真偽値として条件判断をするのに
if(foo == TRUE)
と書いた場合、VB側でtrueを渡しているとこの条件は成立しなくなる。実際には殆どの処理系が制御構文上、0=false, 非0=trueとして扱っているため、
if(foo)
と書くのが無難に思える。しかし世の中は広く、コーディング規約（ソースコードの書き方のルール）でこの様な単項での真偽値判断を禁止する開発現場がある。曰く、「条件として曖昧で、何を判断しているのかわからない」というのだ。筆者はこのようなルール（と主張）には今一同意しかねるが、このような現場では非難を避ける意味で、
if(foo != FALSE) // あるいは0と比較
という若干回りくどい表現が無難になってくる。ソースコードの理解のしやすさという意味では、本末転倒ではないだろうか。
こういう問題を避けるため、比較的抽象度の高い一部の言語処理系(Ruby等)では数値と真偽値を非可換としていたりする。すなわち、真偽値を数値として解釈しないし、数値を真偽値として解釈しない、あるいは数値型の値は全てtrueとして処理する（数値という「データが存在している」という意味で0でもtrue）ようにしていたりする。
x264r1360
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.
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
git-id : 495177138cdaf8360156f4d3cb45a14f1abf3266
Author : Steven Walters
Date: Fri Dec 4 12:17:56 2009 -0800
Remove some unused code from x264.c
x264.cの不使用のコードを除去。
出力に影響なし。
x264r1358
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.
zigzag_8x8_fieldのSSSE3バージョン。
8x8dct付きのinterlaced符号化を僅かに高速化。
Nehalemで最も効き、Conroe/Penfynではいささか期待はずれ。
x264r1357
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.
ref>8のinterlacedでのクラッシュを修正。
クラッシュはweightpで持ち込まれた。
x264r1356
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.
qpel-RDを顕著に高速化。
bidir-RDと同様にMCの結果をキャッシュする。
satd/RDの呼び出しを並べ替える必要性により出力が僅かに変わる。
qpel-RDを5-10%高速化。
x264r1355
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.
ffmpegと同等の関数群にx264のプレフィックスを追加。
今は重要ではないが、libav*による入力をサポートした際に重要になる。
将来性を考えたシンボルの変更で、出力に影響なし。
今回プレフィックスが付いたのはバイトストリーム出力系の関数のみ。
x264r1354
git-id : 636f98f1b06cc51da8399e79ce08bab8c56b82b7
Author : Jason Garrett-Glaser
Date: Mon Nov 30 01:41:24 2009 -0800
10L in r1353
Broke mp4 output.
r1353の10L。
mp4出力を破壊していた。
x264r1353
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.
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
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.
weightpをかなり高速化。
sum/ssd計算をlookaheadから移動しフレームごとに1度だけ実施。
色々と小さな最適化、コスメティックス、クリーンアップも。
x264r1351
git-id : f3cdc6a4878450850eb07ed0122b9836122bdbe0
Author : Kieran Kunhya
Date: Wed Nov 25 01:26:02 2009 -0800
Fix bugs in fps/timestamp handling in FLV muxer
FLV muxerのfps/タイムスタンプ処理のバグを修正。
x264r1350
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.
weightp解析部のバグを修正。
早期終了時に重みがリセットされておらず、そのため古い（誤った）重みが居座っていたかも知れない。
圧縮率を小改善。
x264r1349
git-id : a1705b68f5e88e083411d1d1d8fc77cb09304753
Author : Jason Garrett-Glaser
Date: Tue Nov 24 20:24:14 2009 -0800
Minor deblocking optimization, update comments
小さなデブロッキングの最適化、コメントの更新。
x264r1348
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.
delta_poc_bottom付きのweightbを修正。
まだ何の効果もないが、インターレースモードでTFF/BFF符号化をサポートしたら必要になる。
適切なTFF/BFF符号化で0.5-0.7%の圧縮率向上。
今更だが念のため、TFF/BFFはTop Field FirstとBottom Field Firstの略。
x264r1347
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
1st/2ndパスの解像度が異なる場合により分かりやすいエラーを表示。
x264r1346
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.
sync-lookaheadでの極稀なデッドロックを修正。
パッチは一部Anton Mitrofanovによる。
x264r1345
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
Pフレームがある場合のみweightpの統計を表示。
表示面のみなので出力ビットストリームに影響なし。
x264r1344
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.
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
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.
weightp解析を高速化。
pixel_varが必要な情報を返すように若干変更し、それをsad/ssdの代わりに重み解析に使用。
色々と小さなコスメティックス。
x264r1342
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.
weightpの2つの問題を修正。
解析部がオフセットを-128に決定した場合に、x264は規格に適合しないストリームを作成していた。
ほぼ全てがintraブロックの場合に解析部が非常におかしな重みを選び得るケースを修正。
また、規格適合性をチェックするいくつかのアサートを追加。
「ほぼ全てがintraブロックの場合に…」の方の修正は、やや無理矢理直した形（恣意的な閾値を設定した）になっている。なお、上記の訳は直訳ではなく、ソースコード上のコメントにある"weird weights in frames that are mostly intra"を加味して意訳している。
このリビジョンでweightpが大分安定した模様だが、まだ油断はできない。
x264r1341
git-id : 4f0a545fa7528b4820141ac6d0b8bbe2e643d905
Author : Alexander Strange
Date: Sat Nov 14 22:16:18 2009 -0800
Allow compilation with non-Apple GCC on OS X
OS X上で非AppleのGCCでのコンパイルを許可。
OS Xのビルドにのみ影響。
x264r1340
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.
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のマニュアルで、そこでは以下のように述べている。
access by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior, even if the cast uses a union type
アドレスを取得して、その結果のポインタをキャストし、その結果の参照を外すことによるアクセスは、たとえそのキャストが共用体型を使用していても、未定義の動作となる。
そして具体的に以下のようなコードはダメだとハッキリ例示されている。
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
git-id : 82b80ef96b0ae74187f6f6a482bddb3f859df4f5
Author : Jason Garrett-Glaser
Date: Sat Nov 14 19:58:46 2009 -0800
100l in deadlock fix
デッドロックの修正での100l。
10Lどころか100Lレベルの大ポカでしたということで。
x264r1338
git-id : 6f5f8c02aa3d64e45d17e97d24a6593e8a13c2b2
Author : Kieran Kunhya
Date: Sat Nov 14 19:01:09 2009 -0800
FLV muxing support
FLVのmuxをサポート。
出力形式にFLVが選択できるようになったということ。出力ファイル名の拡張子.flvを認識するようになり、--stdoutにはflvが追加。
以下のソースファイルが追加。
- output/flv.c
- output/flv_bytestream.c
- output/flv_bytestream.h
x264r1337
git-id : e76a4adb1c8ee27748847656450c815f60d2fe6d
Author : Jason Garrett-Glaser
Date: Sat Nov 14 18:40:22 2009 -0800
Fix rare deadlock introduced in weightp
weightpによる稀なデッドロックを修正。
x264r1336
git-id : 2a35a019c5e5710fddcee36976921347ef5ae7a7
Author : Jason Garrett-Glaser
Date: Thu Nov 12 12:40:40 2009 -0800
Actually add -Wno-strict-aliasing to configure
ホントに-Wno-strict-aliasingをconfigureに追加。
ビルド時の警告表示にのみ影響。エンドユーザには関係ない。
r1334ではchangelogに「追加」と書いてあったのに追加されてなかったということ。個人的にはこの警告が本当にGCC側のバグであるなら、x264では抑制せず残しておくべきだと思う。悪いのはGCCなのにx264側で警告を消してしまうと、いつかまたこのエイリアシング問題を忘れかけて、問題のある実装をしてしまった場合に気づくことができないからだ。
x264r1335
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.
様々なweightpの修正。
weightpがスレッド・非スレッドのモードで同じ結果になるようにした。
slow-firstpassでの2パスを修正。
x264r1334
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.
全てのエイリアシング違反を修正。
新しい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
git-id : b28d98bbc3174e6f38caea49a7c545204e3930d3
Author : David Conrad
Date: Wed Nov 11 20:53:49 2009 -0800
Fix 10l in weightp on ARM
ARM上のweightp内の10lを修正。
変更しているコード自体は共通部のもの。
x264r1332
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.
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
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.
win64上のpixel_ssdを修正。
XMMレジスタを保存していなかったが、問題を起こしていたか否かは不明。
x264r1330
git-id : af612d79aaaddfaac486d602ce3303836c45bbc6
Author : Steven Walters
Date: Sun Nov 8 22:18:35 2009 -0800
Fix weightp logfile parsing on MinGW
MinGW上のweightpのログファイル解析を修正。
x264r1329
git-id : 03639d08bb4a1b93d2c4529a3bfec517dd905879
Author : Loren Merritt
Date: Mon Nov 9 05:27:29 2009 +0000
cosmetics
コスメティックス。
大きめのコスメティックスでコードが若干変わっていたりするので注意。10Lがないとは限らない。
x264r1328
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.
ARM + PPC上のweightpを修正。
ただしARMもPPCもアセンブリはまだ。
x264r1327
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!
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の追加以来、期待が非常に高まっていたweightpがコミットされた。weightbは重み付き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（英文）はJVTへのcontribution（寄稿）の一つで、題は"Weighted Prediction Alternative to Adaptive Interpolation Mechanisms"。内容は重み付き予測（Pに限らない）の効果を述べたもので、オフセットが-1という簡単なもの（上記Blindに相当）でも、H.264のリファレンスソフトであるJMでかなりの効果（最大で約8%のRD性能改善）があったと示されている。この文書で読む限りは、特にHD映像で有効な点も特徴だ。あくまでJMでの結果なのでx264に直接は当てはめられないが、効果は非常に大きいと見ていい。
余談だが、JVT-AB033はアサナシオス・レオンタリス(Athanasios Leontaris)というJVT、Dolby、UCSD（カリフォルニア大学サンディエゴ校）に所属する電気・計算機の工学博士が主な著者。こういう文書を読むと、偉い人の研究成果が訳者のような下々の者に降りてきているんだなぁ、としみじみ実感する。
x264r1326
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.
強制iフレームの場合のアサート失敗を修正。
これはIDRフレームではなく、非IDRのiフレームに適用されることに注意。
この修正は将来のopen-gopにも必要。
x264r1325
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
パイプ/FIFOである入力/出力ファイルに関連する問題の修正。
--stdout/--stdinというオプションが追加。
パイプ等ではfseek等ができないため、入出力可能な形式が限られる。stdoutはraw, mkvから選択、stdinはyuv, y4mから選択。
x264r1324
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.
様々なARM関係の修正。
mc_copy_neonのコメントを修正。
memzero_aligned_neonのプロトタイプを修正。
NEONの(i)dct_dcプロトタイプを更新。
global+hidden関数につき、x86の振る舞いを再現。
x264r1323
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.
ARMのgcc 4.3でのコンパイルミスを修正。
spatial予測でのエイリアシング違反が汚いアーティファクトを引き起こしていた。
その際の、その他GCCの警告2つを黙らせた。
エイリアシング違反についてはgcc optionの-f(no)-strict-aliasingを参照。
x264r1322
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.
2-pass VBVでの極希な無限ループを修正。
double→floatの暗黙的な変換は十分な精度を失い、ループの終了条件を決して発生させなくしていた。
Tal Aloniによるバグレポート。
x264r1321
git-id : 028b3ffa9071042468f2cc51580fa6ef65d6ff95
Author : Anton Mitrofanov
Date: Sat Oct 31 19:51:14 2009 -0700
Fix large file support, broken in r1302
大きなファイルのサポートを修正、r1302で破壊していた。
x264r1320
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.
pixel_ssd_*のアセンブラ関数のサイズを劇的に削減。
コードサイズを〜10K除去。
x264r1319
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.
初期化されていなかった低解像度プレーンの右下のピクセルを修正。
おかしな事に、valgrindは--no-asmの場合のみこれを報告した。
x264r1318
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.
bimeの更なるコードサイズ削減。
〜7・8kb程度を節約、subme 9を〜0.6%高速化。
これもループ再ロール・非インライン化による高速化だ。Dark Shikari氏の中で流行してるのかもしれない。
x264r1317
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.
MB-treeが全データを正しくpropagate（伝播）しないケースの修正。
全てのケースで質が改善するはず。
また、いくつかの小さなコスメティック的改善。
x264r1316
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.
インターレースでの動き検索中にchroma MV offsetを考慮する。
インターレース圧縮の小さな改善。
x264r1315
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.
SSSE3 width4 chroma MCを若干高速化。
width8と同様のやり方でキャッシュラインを意識、ただし条件付ではない。
x264r1314
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.
MB-treeがBフレームで不正な結果を出していたいくつかの稀なケースを排除。
また、いくつかの不要なmemcpyを除去。
x264r1313
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.
b-adapt 1が結果として自動タイプのフレームに帰着する可能性があるケースを修正。
これは実際には問題を引き起こしてはいなかったが、（この修正は）上記問題を防いでいたコードを修正する必要性を除去する。
言い回しがわかり辛いが、「内部的には意図しておらず望ましくない動作だが、外部的にはなんとかなっていた」部分を修正したということだろう。
x264r1312
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.
動き補償の最適化。
非インライン化はほぼゼロの速度コストでコードサイズの量を節約する。
オフセットの計算をシンプル化。
その他様々な最適化。
boatloadは直訳で「（船の）最大積載量、船荷」という意味だが、修飾的表現法と思われるのでここでは単に「量」と訳した。
C/C++言語の初心者や、最適化初心者の方は「非インライン化でどうして遅くならないのか？」と疑問に思うかも知れない。教科書的には、インライン化が高速化手法であり、それを解除すると言うことは「遅くすること」のように思えるだろう。非インライン化でも高速になる理屈を理解するためには、そもそも、どうしてインライン化すると一般的には高速になるのかを理解していなければならない。そしてCPUの内部動作に関する知識・想像力と少々のアセンブラ知識が必要だ。
インライン化は、端的に言って命令の取得段階が効率的に動作することと、関数呼び出し手続きが省略されることによって高速化する。「命令の取得段階が効率的に動作する」とは、命令コードが連続していることにより、コードキャッシュに先読みされている命令がそのままCPUのコアに投入され実行されること、そしてそれにより命令のプリフェッチ＆デコードのパイプラインがストール（キャンセル）せず、全体的に言ってCPUの投機的動作が無駄にならないことを指す。関数呼び出し手続きに関しては、関数への引数をスタックに積んだり、gcc optionの-f(no-)omit-frame-pointerで説明しているスタックフレームの確保・解放のような、一般の関数で作成される命令そのものが省略・減少することを指す。
しかし、インライン化された関数が大きなもので、その関数をループ以外で複数回呼び出すことを想像してほしい。この場合、呼び出し元の関数が非常に肥大化することは想像が着くだろう。こうなると、キャッシュ〜デコードの投機的動作自体は上手く動作するが、せっかくのキャッシュが再利用はされないので、命令を読み込むメモリアクセスが常に発生し、足を引っ張られてしまう。また、呼び出される関数が大きい場合、関数呼び出し手続きのオーバーヘッドは処理本体に比べて割合が低く、省略することによる恩恵が小さくなる。
つまり、一定の大きさを持ち、ループ以外で複数回呼び出される関数は、インライン化しない方がコードキャッシュの再利用率の観点から高速になる。ここで「一定の大きさ」とは、「コードキャッシュには収まるが関数呼び出し手続きのオーバーヘッドが割合的に重要でない程度」の大きさを指す。なお、ループで複数回呼ばれる関数は、大きさが一定以下であればコードキャッシュが有効に働くため、インライン化した方が若干高速になる。
今回の変更は、実質的にはr1193のループ再ロール（これも一般的にはループアンロールが高速化の手法だがその逆を行っている）と同じ意味を持つ。そしてループ再ロールにはソースコードが読みやすくなる副次的効果もある。が、ループ再ロールも非インライン化も、その効果はCPUのコードキャッシュのサイズに依存するので、難しい部分でもある。
x264r1311
git-id : e361348b54d636d2bffd622c96d2255c0640c220
Author : Jason Garrett-Glaser
Date: Sun Oct 25 19:41:10 2009 -0700
Minor CAVLC optimizations
CAVLCの小さな最適化。
x264r1310
git-id : ec46ace7eab97cbde6fd50ae18de5c6e063fe1de
Author : Loren Merritt
Date: Sun Oct 25 19:34:12 2009 +0000
cosmetics
コスメティックス。
x264r1309
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.
x86inc.asmをISCライセンスに。
アセンブリの抽象化レイヤはx264以外のプロジェクトでも非常に有用なので、ISC（単純化したBSD）にし、これによって他の、商用プロジェクトでさえ、使用することが可能に。
コメント部のライセンス文の変更のみなのでバイナリに影響なし。
x264r1308
git-id : c9d2c06872347b519f44262bb4ed85198c9ca1b1
Author : Jason Garrett-Glaser
Date: Fri Oct 23 16:20:39 2009 -0700
Various minor CABAC optimizations
色々と小さなCABACの最適化。
x264r1307
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.
b-pyramid strictのバグを修正。
バグはいくつかのシチュエーションで無効なストリームを生んでいた。
x264r1306
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.
non-mod16の警告を除去。
圧縮（率）は非常に取るに足らない量で"suffer"なのであるが、あまりにも多くの人々が警告を誤解している。
出力に影響なし。
幅・高さが16の倍数ではない場合に"width or height not divisible by 16 (WxH), compression will suffer."と表示していた警告を削除したということ。"suffer"は「苦しむ、（被害・存在を）被る」という意味だが、ここでは警告文の一部の引用とみなして訳さずにおいた。
x264r1305
git-id : b89ca0413c5a7114111ba0c76bcd7e52eb0ede93
Author : Jason Garrett-Glaser
Date: Thu Oct 22 22:38:32 2009 -0700
Fix two warnings + some minor optimizations
警告の修正2つ＋小さな最適化をいくつか。
hackyな手段で配列のインデックスが負の値になる場合の対策をしていたものを、マクロに置き換えることで正当な方法に修正している。標準Cでどう定義されているのかは知らないが、負の添字で配列にアクセスした場合の動作は、コンパイラや動作プラットフォームによっては未定義かもしれないので、こういう修正は地味に重要だろう。
x264r1304
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
b-pyramidのhelpのタイポ（誤植）を修正。
それとcommon/macroblock.cの変なスペース文字も。
出力に影響なし。
x264r1303
git-id : 3679792d621cc95222d0aef3097c6d16e72852b8
Author : Henrik Gramner
Date: Mon Oct 19 12:57:47 2009 -0700
A bit more write-combining in macroblock_cache_load
macroblock_cache_loadでさらにもう少しwrite-combining。
write-combiningとは、複数の項目を一括して書き込む高速化手法のこと。ここでは、本来8bit×4回のアクセスをすべきメモリ領域に32bitアクセスで一括書き込みをしている。これによってメモリアクセス回数を減らすと同時に、32bitCPUでは最も高速に扱えるネイティブな幅のメモリアクセス手段を用いていることになる。アラインの確証があれば比較的良く使う手段だが、strict-aliasing rule（gcc optionの-f(no)-strict-aliasingの項目を参照）を破る可能性があるので注意したほうが良い。
x264r1302
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
muxers.cをフォーマットごとに1つのファイルに分割。
内部のmuxer APIをシンプル化。
x264r1301
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
b-pyramidへの最近の変更に伴いfprofileを更新。
一般のユーザには関係ないテスト用設定の変更。
"latest"の直訳は「最新の」だが、b-pyramidにモード指定が必要になったことへの対応なので「最近の」と訳した。
x264r1300
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.
pyramid+VBVでのアサーションの失敗と不正コストを修正。
QPfileによるB-refを正しく扱う。フレームタイプ強制の場合のみ、x264がminigop中の複数B-refを処理するようになるはず。
最終更新時間：2010年01月26日 03時46分03秒