このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。

!!!x264-changelog-jp r1400-r1499

r1400-r1499のchangelogの日本語訳。その他のリビジョンと注意事項については[[x264-changelog-jp]]へどうぞ。

前:[[x264-changelog-jp r1300-r1399]] - 次:[[x264-changelog-jp r1500-r1599]]

!x264r1499
{{bq
git-id : 8a919f81065cccb65ff7c989fffec9258362900b
Author : Henrik Gramner
Date: Tue Mar 16 01:46:00 2010 +0100

Cosmetics: use sizeof() where appropriate
}}

{{bq
コスメティックス：適切な場所でsizeof()を使用。
}}

!x264r1498
{{bq
git-id : ae92e7f589f5832078cf6ecfa510d41b1f6b3301
Author : Jason Garrett-Glaser
Date: Mon Mar 15 00:01:57 2010 -0700

Split up analyse_init
Save some time by avoiding some unnecessary inits and moving other parts to per-thread init.
}}

{{bq
analyse_initを分割。
いくつかの不要な初期化を避け、その他をスレッドごとの初期化に移動することで時間を節約。
}}

!x264r1497
{{bq
git-id : 5d767b111b505edd63dfcff51bd9de839df09f7b
Author : Henrik Gramner
Date: Mon Mar 15 01:19:45 2010 +0100

Reduce stack usage of b-adapt 2's trellis
Also remove some redundant code.
}}

{{bq
b-adapt 2のtrellisのスタック使用量を削減。
また、いくつかの冗長なコードを削除。
}}
スタックとはメモリの一種だが、これでプログラムが使用する総メモリ使用量が削減されているとは限らない。
ただし、一般的に言ってメインメモリへのアクセスが減って高速化することは期待できる。

「スタック」とは、より一般的にはLIFOの''データ構造''を指す言葉だが、''スタックフレーム''を指すことも非常に多く、ここではそちらの意味になる。
スタックフレームとは、簡単に言えばC言語の関数の引数やローカル自動変数等に使用されるメモリ領域の事だ。
これは「コンパイラがどのようにして現実のプログラムでC言語の仕様を実現するか」という命題に対する''実装上の用語''なので、C言語の初級的な教科書では教えないことも多い。
スタックフレームが理解できているかどうかで、C言語の初級者と中級者の区別が付くことも非常に多い。

スタックフレームは関数が呼ばれる時に確保され、関数から戻ると解放される。
関数が呼ばれる度に積まれるので、データ構造としてのスタックと無関係な用語というわけでもない。
スタックフレームの積み重なりによるスタックデータ構造全体（変な言い回しだが）を''コールスタック''と呼ぶ。
main()関数を頂点とした関数呼び出しチェーンの木構造の中で、
''最もコールスタックが大きくなる経路でのサイズが、プログラムのスタック使用量''となる。

つまり、例え「b-adapt 2のtrellisのスタック使用量」が減っても、他の経路でコールスタックがより大きくなるのであれば、プログラム全体のスタック使用量は減らない。
これを手作業で調べるのは現実的ではないため、世の中にはソースコードを解析して調べるツールもあるが、x264も多用している''アセンブラや関数ポインタが使用されると解析できない''ケースも多い。
結局のところ絶対的なスタック使用量は、関数呼び出しチェーンの木構造をすべて実行してみて、デバッガやOS側のメモリ管理機構（にそんな機能が用意されているかも謎だが）で調べるくらいしか手がない。

しかし一方で、「b-adapt 2のtrellisが''アクセスするメモリの範囲が小さくなった''」ということは確実に言える。
すると、少なくともCPUのキャッシュメモリがより効率的に動作することは期待できるし、通常で言えば、アルゴリズム（処理手順）自体の改善でメモリアクセスが減っている傾向も期待できるので、高速化しているんじゃないかとは期待できる。もちろん、使用メモリの減少分をアクセス回数や命令数で補うような「苦しい」変更の場合はこの限りではない。

あぁ、勢いで書いたけど細かく突っ込もうと思えばいくらでも突っ込める説明だなぁ。
あくまで、スタックをよく知らない初級者向けの概念的説明ということでご勘弁を。

!x264r1496
{{bq
git-id : 081b90d9b39eb273f16dd4fe75020048e91cbfcb
Author : Jason Garrett-Glaser
Date: Sun Mar 14 00:25:02 2010 -0800

Various motion estimation optimizations
Faster method of checking MV range.
Predict MVs and cache MVs/MVDs for bidir qpel-RD.
A whole bunch of other minor optimizations.
Slightly better performance and compression.
}}

{{bq
動き見積もりの様々な最適化。
MV rangeをチェックする手法を高速化。
bidir qpel-RDに対しMVの予測とMV/MVDのキャッシュ。
その他小さな最適化を多数。
僅かに高速化・圧縮率向上。
}}

!x264r1495
{{bq
git-id : e73a769dec58d69860998706b4f99808e18a376d
Author : Jason Garrett-Glaser
Date: Sun Mar 14 00:19:59 2010 -0800

Overhaul macroblock_cache_rect
Unify the rectangle functions into a single one similar to ffmpeg's fill_rectangle.
Remove all cases of variable-size cache_rect calls; create a function-pointer-based system for handling such cases.
Should greatly decrease code size required for such calls.
}}

{{bq
macroblock_cache_rectのオーバーホール。
矩形（訳注：四角形のこと）関数群をffmpegのfill_rectangleと同様の一つの関数に統合。
可変サイズであるcache_rectの呼び出しケースを全て除去；そのようなケースの処理のために関数ポインタベースのシステムを作成。
そのような呼び出しに必要なコードサイズを劇的に減少するはず。
}}
common/rectangle.cとcommon/rectangle.hが追加。

!x264r1494
{{bq
git-id : 4f42c3c55ff802c5b212b75317e332ce00cc4a90
Author : Jason Garrett-Glaser
Date: Sun Mar 14 16:48:22 2010 -0700

Make a bunch of small functions ALWAYS_INLINE
Probably no real effect for now, but needed for the next patch.
}}

{{bq
小さい関数群をALWAYS_INLINEに。
恐らく今現在は現実的な効果はないが、次のパッチに必要。
}}

!x264r1493
{{bq
git-id : 6b585097ec92eb40e5785d8beee8b236781d5d86
Author : Loic Minier
Date: Wed Mar 10 05:26:46 2010 -0800

Two compatibility fixes
Add IA64 support in configure.
}}

{{bq
互換性の修正を2つ。
configureにIA64のサポートを追加。
}}
ビルドにのみ影響。

!x264r1492
{{bq
git-id : 49eb50c11ca281146cebea36c7a39d12fa589d51
Author : Henrik Gramner
Date: Fri Mar 5 03:19:47 2010 +0100

Faster x264_macroblock_encode_pskip
GCC is apparently unable to optimize out the calculation of a variable when it isn't used.
}}

{{bq
x264_macroblock_encode_pskipを高速化。
GCCはどうやら変数が使用されていない場合にその計算を最適化することができないようだ。
}}
ソースコードを確認したが、2行目の意味するところがよく分からなかった。
GCCが出力したアセンブリまでは確認していない。

!x264r1491
{{bq
git-id : 513e9b95e81054606d505a7da7734b20ad628ba9
Author : Jason Garrett-Glaser
Date: Sun Mar 7 04:10:30 2010 -0800

Much more accurate B-skip detection at 2 < subme < 7
Use the same method that x264 uses for P-skip detection.
This significantly improves quality (1-6%), but at a significant speed cost as well (5-20%).
It also may have a very positive visual effect in cases where the inaccurate skip detection resulted in slightly-off vectors in B-frames.
This could cause slight blurring or non-smooth motion in low-complexity frames at high quantizers.
Not all instances of this problem are solved: the only universal solution is non-locally-optimal mode decision, which x264 does not currently have.

subme >= 7 or <= 2 are unaffected.
}}

{{bq
2 < subme < 7においてより精密なB-skip検出。
x264がP-skipの検出に使用するのと同様の手法を使用。
画質を有意に（1-6%）向上、ただし同様に優位な速度コスト（5-20%）による。
またこれは、Bフレームにおける精密でないスキップ検出が僅かに外れたベクタを生じていたケースで、大変プラスの視覚効果を生む。
高quantizerにおける低複雑度のフレームにおいて、僅かにボケたりスムーズでない動きを引き起こすかも知れない。
この問題のすべての例は解決されていない：唯一の普遍的な解決方法は、x264が現在持っていない、non-locally-optimal（非局所的最適）モード決定である。
subme >= 7または<= 2は影響を受けない。
}}
「non-locally-optimal（非局所的最適）モード決定」は、ストレートに言い換えれば「大域的モード決定」という意味になる。
つまり周りのMB（時間軸でも空間軸でも）との相関的な影響を考えてのモード決定、ということだろう。

と書いていたら、[x264の2010年のGoogle Summer of Code|http://wiki.videolan.org/SoC_x264_2010#Non-local_RD_optimization]にNon-local RD optimizationという項目があった。
ここでは主に「現在のMBへの決定が将来に及ぼす影響を考える場合の最適化」、つまり時間軸の意味で語られているようだ。

!x264r1490
{{bq
git-id : ec39f7b4566e768c7bad3023c00f9d130efae5bc
Author : Alexander Strange
Date: Sun Mar 7 02:57:04 2010 -0500

Reformat profile restrictions in --fullhelp.

Put "no interlaced", "no lossless" on their own line to avoid them
running into the default options list.
}}

{{bq
--fullhelpにおけるプロファイル制約を再整形。

"no interlaced", "no lossless"がデフォルトオプションリストに出るのを避けるためこれらをその各ラインに配置。
}}
ヘルプの表示にのみ影響。

"no interlaced"や"no lossless"はオプションそのものではないので改行して表示したということだろう。

!x264r1489
{{bq
git-id : 632af6683de604141c636d659a2d229b61ba5ecb
Author : James Darnley
Date: Sat Mar 6 18:28:07 2010 -0800

Fix typo in configure
}}

{{bq
configureのタイポ（誤植）を修正。
}}
FFMS2関連。

!x264r1488
{{bq
git-id : ea93d786162b7cd77a3254cf48dba356be74cf76
Author : David Conrad
Date: Sat Mar 6 10:29:57 2010 -0800

Add support for spaces to iPhone GAS preprocessor script
}}

{{bq
iPhone GASプリプロセッサスクリプトにスペースのサポートを追加。
}}
GASプリプロセッサスクリプトとはr1439のPerlスクリプト。

!x264r1487
{{bq
git-id : d84a1a95f4db132a374d550c98fa85e00075e7a8
Author : Yusuke Nakamura
Date: Sat Mar 6 19:25:30 2010 +0900

Fix slightly wrong mp4 duration.
}}

{{bq
僅かに誤っていたmp4のdurationを修正。
}}

!x264r1486
{{bq
git-id : d0c898a7a737c9a87cefc14b21bc6cfd44cc6b16
Author : Yusuke Nakamura
Date: Sat Mar 6 19:24:32 2010 +0900

Fix link errors with newest gpac cvs
gpac decided to randomly break API and require us to use their own custom malloc and free.
}}

{{bq
最新のgpacのcvsとのリンクエラーを修正。
gpacは勝手にAPIを破壊し、我々に彼ら独自のmallocとfreeを使うよう要求することを決めた。
}}
ビルドにのみ影響。

!x264r1485
{{bq
git-id : db2bae305ef658d053c7c174703c4631a2534b1a
Author : Kieran Kunhya
Date: Fri Mar 5 20:43:02 2010 +0000

Save a few bits in slice headers
Don't override the maximum ref index in the slice header if it's the same as the default.
Also update the naming of the relevant variables in the PPS.
}}

{{bq
スライスヘッダで数ビットを節約。
最大参照インデックスがデフォルトと同じならば、スライスヘッダ内でこれをオーバーライドしない。
また、PPS内の関連する変数の名前を更新。
}}

!x264r1484
{{bq
git-id : e19bef27581dcba813a20d37005ccdf4c285be69
Author : Jason Garrett-Glaser
Date: Thu Mar 4 09:59:09 2010 -0800

Shrink some arrays in x264_t
Also remove an unnecessary assignment from cache_load.
}}

{{bq
x264_t内のいくつかの配列を縮小。
また、cache_loadから不要な代入を削除。
}}

!x264r1483
{{bq
git-id : f36b1e49b3c4cd992080c13ff346f4846f8541b8
Author : Jason Garrett-Glaser
Date: Wed Mar 3 11:22:29 2010 -0800

Use x264_log in more places instead of fprintf
}}

{{bq
fprintfの代わりにx264_logをより多くの箇所で使用。
}}
出力データに影響なし。

!x264r1482
{{bq
git-id : 6951964c87029b4786ccbd558dfa4d3c5be353ae
Author : Anton Mitrofanov
Date: Wed Mar 3 10:14:20 2010 -0800

Fix two nondeterminisms
Move noise reduction data into thread-specific data.
Use correct reference list for L1 temporal predictors.
}}

{{bq
非決定性を2つ修正。
ノイズリダクションデータをスレッド固有のデータに移動。
L1のtemporal（時間軸）予測器に正しい参照リストを使用。
}}
以前にも書いたけれど、決定性とは、再現性とも言い換えられる。
何回エンコードを行っても同じ出力が再現されるように修正したということ。

!x264r1481
{{bq
git-id : 81eee062a4ce9aae1eceb3befcae855c25e5ec52
Author : Jason Garrett-Glaser
Date: Fri Mar 19 14:44:10 2010 -0700

"CRF-max" support with VBV
This is a rather curious feature that may have more use than is initially obvious.
In CRF mode with VBV enabled, CRF-max allows the user to specify a quality level which the encoder will never go below, even due to the effects of VBV.
This is not the same as qpmax, which is not aware of issues like scene complexity.
Setting this WILL cause VBV underflows in any situation where the encoder would have needed to exceed the relevant CRF to avoid underflow.

Why might one want to do this even if it would cause VBV underflows?
In the case of streaming, particularly ultra-low-latency streaming, it may be preferable to drop frames than to display frames that are of too low a quality.
Thus, in extremely complex scenes, rather than display completely awful video, the streaming server could simply drop to a lower framerate.
Scenecuts, which normally look terrible under situations like single-frame VBV, could be handled by just displaying them a bit later and dropping frames to compensate.
In other words, it's better to see the scenecut 150ms delayed than for it to look like a blocky mess for 150ms.

On the caller-side, this would be handled by detecting the output size of x264's frames and dropping future frames to compensate if necessary.

This can also be used in normal encoding simply to ensure that VBV does not hurt quality too much (at the cost of potentially causing underflows).
This can help quite a lot when using single-frame VBV and sliced threads, where VBV can often be somewhat unstable.
}}

{{bq
VBVで"CRF-max"をサポート。
これは一見するよりも使い勝手のあるかもしれない、やや面白い機能だ。
CRF-maxは、VBVが有効なCRFモードにおいて、VBVの作用によってさえエンコーダがそれ以下にはしない品質レベルをユーザが指定することを可能にする。
これはシーンの複雑性のような課題を意識しないqpmaxとは異なる。
これを設定することは、エンコーダがアンダーフローを避けるために対応するCRFを超えねばならない任意の状況において、VBVアンダーフローを引き起こしうる。

なぜ、VBVアンダーフローを引き起こしてでもこれを行いたいか？
ストリーミング、特に超低レイテンシ（超低遅延）ストリーミングの場合、あまりに低画質なフレームを表示するよりも、フレームをドロップする方が好ましいことがありうる。
そのため、極度に複雑なシーンにおいては、ストリーミングサーバは全くひどい映像を表示するよりも、単に低フレームレートにドロップをしうる。
単一フレームVBVのような状況下では通常厳しい見た目であるシーンカットは、若干遅れて表示し、その分フレームをドロップするように処理されることが可能。
言い換えれば、scenecutが、150msの間ブロック状のゴミのように見えているよりも、150ms遅延したように見えるほうがよい。

呼び出し側では、x264のフレームの出力サイズを検出し、必要であれば将来のフレームをドロップすることで、これは取り扱われる。

これは通常のエンコード時にも、単に（潜在的にアンダーフローを引き起こすというコストの元で）VBVが画質をあまりに害することがないことを確かにするために使うことができる。
これはVBVがしばしば不安定になるsliced threadsと単一フレームVBVを使用する際にも大変有用である。
}}
X264_BUILD 90。

--crf-maxが追加。要は、MPEG-4の特徴として当初謳われていた、フレームの画質と引き換えにフレームレートを落とすVFRを適応的に利用できるという話。

個人的には全く興味が湧かない。ストリーミングに使うにしても、x264cliではそのまま使えない。
libx264を使うようなアプリケーションを書いて、適切な処置を入れ、動的にVFR出力にする必要がある。

!x264r1480
{{bq
git-id : c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505
Author : Kieran Kunhya
Date: Tue Mar 2 00:57:10 2010 -0800

Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown
x264 can now generate Blu-ray-compliant streams for authoring Blu-ray Discs!
Compliance tested using Sony BD-ROM Verifier 1.21.
Thanks to The Criterion Collection for sponsoring compliance testing!

An example command, using constant quality mode, for 1080p24 content:
x264 --crf 16 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 -o

This command is much more complicated than usual due to the very complicated restrictions the Blu-ray spec has.
Most options after "tune" are required by the spec.
--weightp 0 is not, but there are known bugged Blu-ray player chipsets (Mediatek, notably) that will decode video with --weightp 1 or 2 incorrectly.
Furthermore, note the Blu-ray spec has very strict limitations on allowed resolution/fps combinations.
Examples include 1080p @ 24000/1001fps (NTSC FILM) and 720p @ 60000/1001fps.

Detailed features introduced in this patch:

Full NAL-HRD compliance, with both VBR (no filler) and CBR (filler) modes.
Can be enabled with --nal-hrd vbr/cbr.
libx264 now returns HRD timing information to the caller in the form of an x264_hrd_t.
x264cli doesn't currently use it, but this information is critical for compliant TS muxing.

Full VFR ratecontrol support: VBV, 1-pass ABR, and 2-pass modes.
This means that, even without knowing the average framerate, x264 can achieve a correct bitrate in target bitrate modes.
Note that this changes the statsfile format; first pass encodes make before this patch will have to be re-run.

Pulldown support: libx264 allows the calling application to specify a pulldown mode for each frame.
This is similar to the way that RFFs (Repeat Field Flags) work in MPEG-2.
Note that libx264 does not modify timestamps: it assumes the calling application has set timestamps correctly for pulldown!
x264cli contains an example implementation of caller-side pulldown code.

Pic_struct support: necessary for pulldown and allows interlaced signalling.
Also signal TFF vs BFF with delta_poc_bottom: should significantly improve interlaced compression.
--tff and --bff should be preferred to the old --interlaced in order to tell x264 what field order to use.

Huge thanks to Alex Giladi and Lamont Alston for their work on code that eventually became part of this patch.
}}

{{bq
Blu-rayのサポート：NAL-HRD, VFRのレートコントロール, filler, pulldown
x264はBlu-rayディスクのオーサリングのためにBlu-ray規格に適合するストリームを生成できるようになった！
規格適合性はSony BD-ROM Verifier 1.21を使用してテストされた。
規格適合性テストのスポンサーとしてCriterion Collectionに感謝する！

1080p24のコンテンツに対して固定品質モードを使用するコマンド例：
x264 --crf 16 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 <input> -o <output>

このコマンドはBlu-ray仕様の非常に複雑な制約によって、通常よりかなり複雑になっている。
"tune"の後のほとんどのオプションは仕様によって要求されているもの。
--weightp 0はそうではないが、--weightp 1または2の映像を不正にデコードするバグのある、既知のBlu-rayプレーヤ（特にMediatek）が存在する。
その上なお、Blu-rayの仕様には許される解像度/fpsの組み合わせに大変厳しい制限があることに注意。
例は1080p@24000/1001fps(NTSC FILM)と720p@60000/1001fpsを含んでいる。

このパッチで導入される機能の詳細：

完全なNAL-HRDへの規格準拠、VBR（fillerなし）とCBR（fillerあり）モード。
--nal-hrd vbr/cbrで有効にできる。
libx264はx264_hrd_tの形式で呼び出し側にHRDタイミング情報を返すようになった。
x264cliは現在のところこれを使用しないが、この情報は規格に適合するTSのmuxにはクリティカル（非常に重要）なので注意。

完全なVFRのレートコントロールのサポート：VBV, 1-pass ABR, 2-passモード。
これは、例え平均フレームレートを知らずとも、x264がビットレートを狙うモードで正しいビットレートを実現することができることを意味する。

これはstatsファイルの形式を変更することに注意；このパッチ以前の1st-passエンコードは再度実行される必要がある。

pulldownのサポート：libx264は呼び出し側アプリケーションが各フレームに対しpulldownモードを指定することを許可する。
これはMPEG-2でのRFF(Repeat Field Flags)の働きと同様のやり方。
libx264はタイムスタンプを修正しないことに注意：呼び出し側アプリケーションがpulldown用にタイムスタンプを正しく設定しているとみなす！
x264cliは呼び出し側のpulldownコードの実装例を含んでいる。

pic_structのサポート：pulldownに必要で、interlaced符号化を可能にするもの。
また、delta_poc_bottomでTFF/BFFを符号化する：interlaced圧縮を有意に改善するはず。
x264に使用すべきフィールドオーダを教えるためには、古い--interlacedよりも--tffと--bffが勧められる。

Alex GiladiとLamont Alstonに大変感謝する。
}}
X264_BUILD 89。

今回のr1472〜r1510までの一連のパッチで、一般人には恐らく一番重要なもの。
tff/bffで有名な''「PS3等でインターレースが解除できない」問題が改善''される。
nal-hrdで''Blu-ray規格に適合''するようになる。
pulldownでフィルム映画素材などの24pのソースをpulldown処理（いわゆる''テレシネ''処理の一部）することができるようになる。

まずは''使い方だけわかればいい''人向けに。
*インターレース素材には--tffか--bffを付ける。
**今はtffが多いが、昔はbffが多かったので素材による。
**pic-structは内部で使用されるのでオプションとしては不要。
*--nal-hrdは保存用動画には常に付けておくのが吉。
**基本はvbrで必要な場合のみcbrを指定。mp4にcbrは不可。
**余分なデータが付くのでストリーミング用途では付けない方がよいことも。
*--pulldownは若干難しいので素材があって意味が分かる人用。
**日本では24p素材に対し--pulldown 32を使うのが一般的。

以下、大分端折りつつも詳細。

x264はこれまでもMBAFF方式でインターレース映像をエンコードすることができたが、SEIにその''フレームがTFF/BFFのいずれかであるという情報''を記録していなかった。
このためPS3等（SEIを見て表示処理を決めている再生機器・ソフト）は、MBAFF自体はデコードできていても、その後の表示処理で''適切なインターレース解除処理を行えない''でいた。

pic-structはこのSEIにpic_struct情報を記録することを''強制する''ものだが、x264cliでは通常、--pic-structは不要だ。
その代わり同時に追加されている''--tff/--bffを指定すれば、内部でinterlacedがONになり、最終的にpic-structもONにされる''。
つまりこれまで非公式パッチ版を使用していた人は同じように扱える。
明示的に--pic-structを指定すべきなのはプログレッシブでもSEIにpic_structを記録したい場合くらいだろう。

nal-hrdは、H.264と関連する''各種の規格に対する適合性が上がり、互換性が向上する''オプションだ。
--nal-hrdにはcbr/vbrのどちらかを渡すが、特に必要でない限り、''基本的にはvbrでよい''だろう。
''cbrはmp4出力には使えず''、出力サイズが大きくなる。
なお、ここで言うcbrは従来のx264で言うCBRモードとは意味合いが異なるので、そのあたりを詳しく知りたい方は[[CBRの幻想]]を参照。
nal-hrd自体の詳細もここで説明するには若干重すぎるので、[[x264(nal-hrd),H.264/AVC(HRD),MPEG-1/2(VBV)]]を参照のこと。

TODO:r1272の「単一フレームVBVで固定フレームサイズ」が可能になったのだと言えるのかを確認したい。

pulldownは、一般的にはテレシネ処理で行われる、''fps変換''に使われる仕組みだ。
MPEG-2にも同様のRFFというフラグがあったのでご存知の方も多いかと思う。
日本で言えば多くの場合24fps→30fpsの変換（''2:3-pulldown''等と呼ばれる）に使用される。
これは実データは24fpsでエンコードしつつ、フラグによって同じフィールドを複数回表示させることで表示データを30fpsにし、テレビの表示方式とマッチングする方式だ。
名前の数値が2:3であったり3:2であったりするが、これらは同じものを指している（準拠する規格による？）。
x264cliでの指定は--pulldown 32となり、23とは指定出来ない。

pulldownを正しく（と言ってもH.264の規定も明確でない部分があるようだが）行うためには、フレーム毎にフィールド情報とタイムスタンプが必要になる。
フィールド情報はpic-structで与えるし、タイムスタンプはHRDに絡んでくるので、これら3つの機能はnal_hrd_pulldown_interlacedパッチとしてまとめて提供されていた。

実際には、''今回のパッチだけでpulldownを常に適正に扱えるかは難しい''部分もある。
いちいち「呼び出し側アプリが…」という表記が絡むのはそのためだ。
しかし、一般人が''普通に入手可能な素材は既に30fps化されている''ため、逆テレシネ処理（逆pulldown処理）をしない限りは24fps素材が手元にあることは少ない。
取り敢えずは30fpsのまま--tff/--bffとnal-hrdだけを使用しても、表示が大きく乱れず、Blu-ray適合なストリームが公式のx264で得られる。
そういう意味で、pulldownを別に考えたとしても、このリビジョンの成果は非常に大きいと言えるだろう。

!x264r1479
{{bq
git-id : a5f56908a0b153870c4f09cbf683fe85da3e44b4
Author : Yusuke Nakamura
Date: Sun Feb 28 21:42:19 2010 -0800

Timecode input/output
--tcfile-in allows a user to specify a timecode v1 or v2 file to override input timestamps.
Useful for dealing with VFR input, especially when FFMS/LAVF support isn't available.
--tcfile-out writes a timecode v2 file containing the timecodes of the output file.
New --timebase option allows a user to change the stream timebase.
Intended primarily for forcing timebase with timecode files if necessary.
When using --seek, note that x264 will seek in the timecode file as well.
}}

{{bq
timecode入力/出力。
--tcfile-inはユーザが入力タイムスタンプをオーバーライドするためにtimecode v1またはv2のファイルを指定することができる。
VFR入力の取り扱い時、特にFFMS/LAVFサポートが利用の出来ない場合に有用。
--tcfile-outは出力ファイルのtimecodeを含むtimecode v2ファイルを書き出す。
新しい--timebaseオプションはストリームのtimebaseをユーザが変更することを可能にする。
必要時にtimecodeファイルでtimebaseを強制することを主に意図している。
--seekを使用する場合、x264はtimecodeファイルも同様にシークすることに注意。
}}
今回のr1472〜r1510までの一連のパッチで、人によっては一番重要かもしれないもの。
Author見ればわかるだろうけれど。

猫研はあまりVFRに明るいわけでもなく、他によい解説はあるだろうから、余計なことは言わないでおく。

libx264から使えるようにはなっていないみたい。ソースにinput/timecode.cが追加。

!x264r1478
{{bq
git-id : ece1dd2e8e35a49883e26c7071d2ca3cec9c008f
Author : Alex Wright
Date: Sun Feb 28 01:29:15 2010 -0800

Mixed-refs support for B-frames
Small speed cost, usually a few percent at most. Generally has lowest cost in cases when it isn't very useful. Up to ~2% better compression overall on highly complex sources.

Also fix a few minor bugs in B-frame analysis and various bits of cleanup.
}}

{{bq
Bフレームに対するMixed-refsをサポート。
小さな速度コスト、通常ではせいぜい数%程度。一般的にはこれが有用でない場合に最も低いコストになる。高度に複雑なソースにおいて、全体で最大〜2%の圧縮率向上。

また、Bフレーム解析のいくつかの小さなバグ修正とクリーンアップを色々。
}}
これまでPフレームにしか有効ではなかったmixed-refsがBフレームにも有効になった。
地味に結構重要だろう。

!x264r1477
{{bq
git-id : e5b108a3de97650ad4bbeb4f3ff13cff916d6052
Author : Henrik Gramner
Date: Mon Mar 1 22:01:04 2010 +0100

Faster rounding of chroma DC coefficients
}}

{{bq
chroma DC係数の丸め処理を高速化。
}}

!x264r1476
{{bq
git-id : 8ec5a5ee10face5a1e64bf15364d1fdf2cf29ae5
Author : Holger Lubitz
Date: Wed Mar 24 00:54:39 2010 +0100

Faster cabac_encode_decision_asm
Minimizes instruction count, which also means smaller code.
Various other slight changes to allow more instruction level parallelism.
}}

{{bq
cabac_encode_decision_asmの高速化。
命令数を最小化、コードも小さくなるということ。
命令レベルの並列性を向上する、その他様々の僅かな変更。
}}

!x264r1475
{{bq
git-id : c572d28af6ba7addc0f1855ee5282435d8d37861
Author : Holger Lubitz
Date: Tue Mar 23 23:13:54 2010 +0100

Faster hpel_filter
On ssse3, use pmaddubsw for h filter too (similar to v filter).
Change 32-bit v and c filters to write the result non-temporal.
Add commented-out defines to disable non-temporal operation.
Hardly any black magic here, but still a measurable win especially for ssse3.
}}

{{bq
hpel_filterの高速化。
SSSE3において、hのフィルタにもpmaddubswを使用（vのフィルタと同様）。
32-bitのvとcのフィルタが結果を非テンポラルに書き込むように変更。
コメントアウト状態で非テンポラル処理を無効にするためのdefineを追加。
ここには殆ど黒魔術はないのだが、それでも、特にSSSE3に対して一定の優位がある。
}}
アセンブラレベルの最適化の話なので、このchangelogを素人がそのまま読むのは少々難しい。

ここで言うtemporalはdirect-mvの話でも、そもそも動画エンコード上の話でもない。
「非テンポラルに書き込む」とは、「すぐに再利用される予定がないデータを、キャッシュを通さず書き込む」という意味。
少ないキャッシュを少しでも効率的に使用するための改善だ。

この処理はmovntq, movntps, sfenceという3つの命令を使用するが、その使用・不使用を簡単に切り替えられるようにdefineを用意したということ。

!x264r1474
{{bq
git-id : 279c9d9dd90f18f229719ba09c4fab33f87b3f16
Author : David Conrad
Date: Sun Feb 28 20:34:09 2010 -0500

Ignore XYSCSS in y4m if the newer standard C tag is present

Apparently y4mscaler will generate 4:2:0 files with XYSCSS set to 444
}}

{{bq
より新しい標準的なCタグが存在する場合にy4m中のXYSCSSを無視。

y4mscalerはXYSCSSが444の4:2:0ファイルを生成するようだ。
}}
y4mscalerとやらまでは調べていないが、y4m(yuv4mpeg)形式のヘッダには、
色空間の指定としてCタグ（新しく標準的）とXYSCSSタグ（古く非標準的）があるらしい。

そしてXYSCSSには間違ったカラースペースが指定されていることがあるようなので、
Cタグの指定があればそちらに従うようにしたということ。

!x264r1473
{{bq
git-id : c8900a261508830e74187f379e7666cfc94f638b
Author : Jason Garrett-Glaser
Date: Tue Mar 2 10:51:15 2010 -0800

Fix regression in r1450
I_PCM blocks would cause x264 to crash or generate bad output. Simplify PCM handling.
}}

{{bq
r1450でのレグレッションを修正。
I_PCMブロックはx264をクラッシュさせるか、不良な出力を生成させていた。PCM処理をシンプル化。
}}

!x264r1472
{{bq
git-id : 7d533c57ee25a73c79b10ef7fb36324727e38582
Author : Jason Garrett-Glaser
Date: Sat Feb 27 14:26:02 2010 -0800

Fix crash with intra-refresh + aq-mode 0
}}

{{bq
intra-refresh + aq-mode 0でのクラッシュを修正。
}}

!x264r1471
{{bq
git-id : 11446152ba7c79774d65f8556f2282ad838942d7
Author : Jason Garrett-Glaser
Date: Fri Feb 26 05:04:48 2010 -0800

Fix regression in r1453
r1453 broke psy-trellis with --trellis 2
}}

{{bq
r1453でのレグレッションを修正。
r1453は--trellis 2でのpsy-trellisを壊していた。
}}

!x264r1470
{{bq
git-id : 7eac2495b2d32d6328bf68abbc4bb67006a0737a
Author : Jason Garrett-Glaser
Date: Thu Feb 25 02:07:48 2010 -0800

Fix regression in r1449
Incorrectly placed thread MV check could result in rare thread MV internal errors, esp. with --non-deterministic.
These weren't fatal errors (x264 could recover and continue with slight compression loss).
}}

{{bq
r1449でのレグレッションを修正。
スレッドMVチェックの不正な配置が稀に、特に--non-deterministicで、スレッドMVの内部エラーを起こしていた。
これらは致命的なエラーではない（x264はこれを回復して、僅かな圧縮率のロスだけで処理を継続できた）。
}}

!x264r1469
{{bq
git-id : 3ae44d9e19afccf3feb9ef3c33ae0538893f78e9
Author : Jason Garrett-Glaser
Date: Wed Feb 24 20:51:43 2010 -0800

Cut size of MVD arrays by a factor of 2 again
Only store the MVDs of the edges of each MB.

Thanks to Michael Niedermayer for the idea.
}}

{{bq
MVD配列のサイズを再び2の係数で削減。
各MBのエッジのMVDのみを格納。

このアイディアに関し、Michael Niedermayerに感謝する。
}}

!x264r1468
{{bq
git-id : 6a443d3cdf338408b1b39e7f336306d2a34703f6
Author : David Conrad
Date: Wed Feb 24 19:39:57 2010 -0500

Disable Altivec and VIS optimizations when --disable-asm is specified
}}

{{bq
--disable-asmが指定された場合、AltivecとVISの最適化を無効化。
}}
PowerPCにのみ影響。

!x264r1467
{{bq
git-id : 4091b29c0dcaa2ceaedbdf5be9c283beb70fe327
Author : Loren Merritt
Date: Tue Feb 23 23:50:23 2010 -0800

Fix a buffer overread on odd input resolutions
}}

{{bq
奇数の入力解像度におけるバッファの過大読込を修正。
}}

!x264r1466
{{bq
git-id : 479a9e8e4e39409b24b0517a1c155a767af63454
Author : Jason Garrett-Glaser
Date: Wed Feb 24 03:49:32 2010 -0800

Fix one bug, one corner case in VBV
qp_novbv wasn't set correctly for B-frames.
Disable ABR code for frames with zero complexity.
Disable ABR code for CBR mode; it is completely unnecessary and can have negative consequences.
}}

{{bq
VBVが困窮するケースでのバグを1つ修正。
qp_novbvがBフレームに対し正しく設定されていなかった。
複雑性がゼロであるフレームに対してABRコードを無効化。
CBRモードに対してABRコードを無効化；完全に不要で、マイナスの影響をもたらしうる。
}}

!x264r1465
{{bq
git-id : 4132e0bce60469bc7709d25d14b62b26c8fc112e
Author : David Conrad
Date: Wed Feb 24 00:29:21 2010 -0500

Port Mans Rullgard's NEON intra prediction functions from ffmpeg
}}

{{bq
ffmpegからMans RullgardのNEON版intra予測関数を移植。
}}
ARMにのみ影響。

!x264r1464
{{bq
git-id : e29c75837c72a0ed387441ffa6bab339dbe3de9f
Author : Jason Garrett-Glaser
Date: Tue Feb 23 13:52:15 2010 -0800

Remove unused function
Two other minor fixes.
}}

{{bq
不使用の関数を削除。
他に2つの小さな修正。
}}
出力に影響なし。

＋αはコスメティックスレベル（ヘルプの整形とplaceboの指定がignore caseでできるようになっただけ）。

!x264r1463
{{bq
git-id : f2428d26ecf182bcda1292191902861a66001574
Author : Jason Garrett-Glaser
Date: Tue Feb 23 10:00:41 2010 -0800

Use short startcode in more possible situations
Previous patch didn't cover all possible uses according to B.1.2.
}}

{{bq
可能なシチュエーションで短いスタートコードを更に使用。
以前のパッチはB.1.2によって可能な用途の全てをカバーしていなかった。
}}
r1458で「最初のスライス（以外）」と言っていたのが「最初のNAL（以外）」になったようだ。

!x264r1462
{{bq
git-id : 7fcffde1f5bdae55def6c36ef7d9743485adb72c
Author : Jason Garrett-Glaser
Date: Tue Feb 23 09:50:12 2010 -0800

Fix fastfirstpass
Apparently the libx264 preset changes made "fastfirstpass" into "fastsecondpass" inadvertantly.
}}

{{bq
fastfirstpassを修正。
どうやら、不注意でlibx264のプリセットが"fastfirstpass"を"fastsecondpass"に変更していたようだ。
}}
inadvertantlyはinadvert''e''ntlyのタイポ。

!x264r1461
{{bq
git-id : ad64d48f17335e820d7a0a563a88436f38ccb813
Author : Anton Mitrofanov
Date: Tue Feb 23 09:10:26 2010 -0800

Fix various silly errors in the previous patches
}}

{{bq
最近のパッチにおける様々なくだらないエラーを修正。
}}
内容からpreviousは「最近の」と訳した。

!x264r1460
{{bq
git-id : 9e35bd0f915e92c4a48f9ace2af561ae9a27f6e8
Author : Jason Garrett-Glaser
Date: Tue Feb 23 02:18:07 2010 -0800

Actually error out if preset/tune/profile is invalid
Got lost somewhere in the move to libx264-based presets.
}}

{{bq
preset/tune/profileが不正な場合に、ちゃんとエラーになるように。
libx264ベースのプリセットに移行する際のどこかで消えていた。
}}
パラメータチェックだけなので出力に影響なし。

!x264r1459
{{bq
git-id : 377814e109210a10b8c34bf358b40c59d3ca2757
Author : Jason Garrett-Glaser
Date: Mon Feb 22 17:33:17 2010 -0800

Faster probe_skip, 2x2 DC transform handling
Move the 2x2 DC DCT into the dct_dc asm function to avoid some store-to-load forwarding penalties and extra register loads.
Use dct_dc as part of the early termination in probe_skip.
x86 asm partially by Holger Lubitz.
ARM NEON asm by David Conrad.
}}

{{bq
より高速なprove_skip、2x2 DC transform処理。
store-to-load転送ペナルティと余分なレジスタ読込を避けるため、2x2 DC DCTをdct_dcアセンブラ関数内に移動。
dct_dcをprobe_skip内の早期終了の一部として使用。
x86アセンブラは一部Holger Lubitzによる。
ARM NEONアセンブラはDavid Conradによる。
}}

!x264r1458
{{bq
git-id : 6823cbc5359981ff2d7a9c538b9e8f861b9cf36c
Author : Jason Garrett-Glaser
Date: Sun Feb 21 17:30:52 2010 -0800

Use short startcodes whenever possible
Saves one byte per frame for every slice beyond the first.
Only applies to Annex-B output mode.
}}

{{bq
可能な場合には短いスタートコードを使用。
最初以外の各スライスで、フレームごとに1バイトを節約。
Annex-B出力モードにのみ適用。
}}

!x264r1457
{{bq
git-id : 74f2fd65af6840aced812e295e1a551ba295459f
Author : Anton Mitrofanov
Date: Sun Feb 21 13:21:11 2010 -0800

New algorithm for AQ mode 2
Combines the auto-ness of AQ2 with a new var^0.25 instead of log(var) formula.
Works better with MB-tree than the old AQ mode 2 and should give higher SSIM.
}}

{{bq
AQ mode 2に新アルゴリズム。
AQ2の自動化部分にlog(var)式ではなくvar^0.25を組み合わせ。
古いAQ mode 2よりもMB-treeと上手く動き、より高いSSIMを生むはず。
}}
ちゃんと追ってないが、これまでパッチで存在していた--aq-mode 4を取り込んだものと思われる。これまでの--aq-mode 2はmbtreeと相性が悪いと言われていたが、新しい--aq-mode 2はこれが大分マシなのではないかと期待される。

!x264r1456
{{bq
git-id : a6c91c9f2af09d666755eef0ac2cc18228ce7a7c
Author : Jason Garrett-Glaser
Date: Sun Feb 21 13:20:19 2010 -0800

Abide by the MinCR level limit
Some Blu-ray analyzers were complaining about this.
}}

{{bq
MinCRのレベル制限を遵守。
いくつかのBlu-ray解析機がこれにケチを付けていた。
}}
X264_BUILD 88。

MinCRはmin compression ratioらしい。

!x264r1455
{{bq
git-id : 1d94f305999864aaa1da79050da2f900f69b4365
Author : Jason Garrett-Glaser
Date: Sun Feb 21 03:56:06 2010 -0800

Make b-pyramid normal the default
Now that b-pyramid works with MB-tree and is spec compliant, there's no real reason not to make it default.
Improves compression 0-5% depending on the video.
Also allow 0/1/2 to be used as aliases for none/strict/normal (for conciseness).
}}

{{bq
b-pyramid normalをデフォルトにした。
今やb-pyramidはMB-treeと同時に動き、かつ仕様を満たしているので、デフォルトにしない正統な理由がない。
映像によるが、圧縮率を0〜5%改善。
また、none/strict/normalのエイリアス（別名）として0/1/2を使用可能にした（簡潔さのため）。
}}
X264_BUILD 87。

!x264r1454
{{bq
git-id : 1007cb7478a5e21facb7c23dc49770e2f02b9620
Author : Jason Garrett-Glaser
Date: Sun Feb 21 01:56:12 2010 -0800

Move presets, tunings, and profiles into libx264
Now any application calling libx264 can use them.
Full documentation and guidelines for usage are included in x264.h.
}}

{{bq
preset, tune, profileをlibx264内に移動。
libx264を呼ぶ任意のアプリケーションがこれらを使用可能に。
完全なドキュメントと使用方法のガイドラインはx264.hに含まれている。
}}
X264_BUILD 86。

TODO:libx264の使い方に関する記事を立ち上げる。

!x264r1453
{{bq
git-id : 7a7fbeab0f1f3b8187d1d8ce56def91f1582d5d7
Author : Anton Mitrofanov
Date: Fri Feb 19 10:45:22 2010 -0800

Faster, more accurate psy-RD caching
Keep more variants of cached Hadamard scores and only calculate them when necessary.
Results in more calculation, but simpler lookups.
Slightly more accurate due to internal rounding in SATD and SA8D functions.
}}

{{bq
高速でより精密なpsy-RDキャッシング。
アダマール変換スコアキャッシュの変数をより多く保持し、必要な場合のみそれらを計算する。
計算が多くなるが、lookup（表引き）がより単純に。
SATDとSA8D関数内の丸め処理に起因して、僅かに精密になる。
}}

!x264r1452
{{bq
git-id : 40284dfe7485e52769eca0614063b92315e9a5f5
Author : Jason Garrett-Glaser
Date: Thu Feb 18 17:01:38 2010 -0800

Much faster and more efficient MVD handling
Store MV deltas as clipped absolute values.
This means CABAC no longer has to calculate absolute values in MV context selection.
This also lets us cut the memory spent on MVDs by a factor of 2, speeding up cache_mvd and reducing memory usage by 32*threads*(num macroblocks) bytes.
On a Core i7 encoding 1080p, this is about 3 megabytes saved.
}}

{{bq
かなり高速で効率的なMVD処理。
MV deltaをクリップされた絶対値として格納。
これはMVコンテキスト選択において、CABACはもはや絶対値を計算する必要がない事を意味する。
これはまた、MVDに費やすメモリを2の係数で削減することを可能にし、（それによって・その結果として）cache_mvdを高速化、メモリ使用量を32*<スレッド数>*<マクロブロック数>バイト減少させる。
Core i7での1080pのエンコードで、これは約3メガバイトの節約になる。
}}

!x264r1451
{{bq
git-id : 10e9e95cb90f01fcbdb182c2ae05dac336b6eed3
Author : Jason Garrett-Glaser
Date: Thu Feb 18 10:37:57 2010 -0800

Add temporal predictor support to interlaced encoding
0.5-1% better compression in interlaced mode
}}

{{bq
interlacedエンコードにtemporal予測器のサポートを追加。
interlacedモードにおいて0.5〜1%の圧縮率改善。
}}
TODO:r1430では足りていなかったということ？

!x264r1450
{{bq
git-id : 8b67d5eb50a8b63c3c8732d5f053073dbb195e51
Author : Jason Garrett-Glaser
Date: Wed Feb 17 22:41:16 2010 -0800

Keep track of macroblock partitions
Allows vastly simpler motion compensation and direct MV calculation.
}}

{{bq
マクロブロックパーティションのtrack（追跡）を保持。
動き補償とdirect MVの計算を広くシンプル化可能に。
}}
これも注意した方がいいコードに当たるだろうなぁ…。
{{pre
+    /* Don't do any checks other than the ones we have to, based
+     * on the size of the colocated partitions.
+     * Depends on the enum order: D_8x8, D_16x8, D_8x16, D_16x16 */
+    int max_i8 = (D_16x16 - partition_col) + 1;
+    int step = (partition_col == D_16x8) + 1;
+    int width = 4 >> ((D_16x16 - partition_col)&1);
+    int height = 4 >> ((D_16x16 - partition_col)>>1);
}}
C99ではenum型は最低でもcharと互換性があることになっているので、本当は問題ない。
が、enumを演算に用いるのはあまり好ましくないとされる事が多い。

!x264r1449
{{bq
git-id : 4574b58c7d66d793bd28e3ce506165ca1c9e7680
Author : Jason Garrett-Glaser
Date: Tue Feb 16 10:13:33 2010 -0800

Much faster and simpler direct spatial calculation
}}

{{bq
direct spatialの計算をかなり高速化＆シンプル化。
}}
注意した方がいいかもしれない表現。
{{pre
-    if( i_refa == i_ref ) i_count++;
-    if( i_refb == i_ref ) i_count++;
-    if( i_refc == i_ref ) i_count++;
+    int i_count = (i_refa == i_ref) + (i_refb == i_ref) + (i_refc == i_ref);
}}
trueが1であることに依存している。

規格では確かに、比較演算子はint型の0/1を生成するので本当は問題ない。
が、規格に従順な処理系ばかりとは限らないし、古い処理系では謎かもしれないので注意した方がいい。そしてC言語以外の処理系との連携を考える場合はtrueが1であるとは限らない。

逆に、falseが0であると見なすのは多くの処理系（C言語以外を含む）で、問題ない。

ちなみに、C言語のif等の制御構文はtrue/falseではなく非0/0を受け取る。
ISO/IEC 9899:1999を紐解くと、6.8.4.1 The if statementで
"substatement is executed if the expression compares unequal to 0."とされている。

NULLも多くの場合0と見なすことができる。ただし厳密には、0→NULL（0はNULLであると言える）とNULL→0（NULLは0であると言える）では様相が違う。
0→NULLに関しては、6.3.2.3 Pointersで概念としてのnull pointer constantとinteger constantの0が
{{bq
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.
If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
}}
と規定されている。
が、NULL→0に関しては、7.17 Commonde&#64257;nitions <stddef.h>でマクロとしてのNULLが
"expands to an implementation-de&#64257;ned null pointer constant"と定義されている。つまりNULLポインタの値は実装依存であり、0である保証はない。

==if(NULL)というコードが通ることを考えれば、筆者の確認していないどこかで規定されているのかも知れない。==
if(NULL)はif(NULL!=0)と展開され、0が上記6.3.2.3 Pointersの定義に従いnull pointer constantであるため、実質的にif(NULL!=(void*)0)となるらしく、NULL→0と言えるかは関係ないとのこと（[C FAQ 5|http://www.kouno.jp/home/c_faq/c5.html]）。
なお、if(!NULL)という表現に関しても、同様に考えられる。
論理否定の「!」演算子は6.5.3.3 Unaryarithmetic operatorsで"The expression !E is equivalent to (0==E)."とされている。
つまりif(!NULL)はif((0==NULL)!=0)と展開され、…以下同文。

!x264r1448
{{bq
git-id : 1a6d32b4a42f490ec817aa2ddb543dda8d9a8c9e
Author : Jason Garrett-Glaser
Date: Sun Feb 21 14:21:26 2010 -0800

SimpleBlock requires Matroska Doctype v2
}}

{{bq
SimpleBlockはMatroska Doctype v2を必要とする。
}}
mkv出力でヘッダが変わる。

!x264r1447
{{bq
git-id : 966fd12a2a9beb3bba294dc4a91a45bbafc4799f
Author : Yusuke Nakamura
Date: Tue Feb 16 11:05:21 2010 -0800

Add GPAC version check
}}

{{bq
GPACのバージョンチェックを追加。
}}
ビルドにのみ影響。

2007-06-21 UTC以降（gf_isom_set_pixel_aspect_ratio()関数）が必要。

!x264r1446
{{bq
git-id : 482646af573829582403317f0cde0a46a4b48ab2
Author : Jason Garrett-Glaser
Date: Tue Feb 23 01:44:44 2010 -0800

Fix stupid regression in interlaced in r1430
With ref > 8 or b-pyramid, an array over-read could cause slightly incorrect B-frames.
}}

{{bq
r1430におけるinterlaced時のアホくさいレグレッションを修正。
ref > 8またはb-pyramidで、配列の過大読込が僅かに不正なBフレームを引き起こしていたかもしれない。
}}

!x264r1445
{{bq
git-id : f0da96145cb068ade0f0232d0682137c9065929f
Author : Jason Garrett-Glaser
Date: Mon Feb 22 13:04:47 2010 -0800

Fix overread of scratch buffer
Could cause crashes on non-mod16 frames.
}}

{{bq
スクラッチバッファの過大読込を修正。
非mod16なフレームにおいてクラッシュを引き起こしていたかもしれない。
}}

!x264r1444
{{bq
git-id : 28e6eb67ffaa002469f60c40e2b5d58b2a758f9c
Author : Jason Garrett-Glaser
Date: Mon Feb 22 11:21:51 2010 -0800

Fix integer overflow in chroma SSD check
Could cause bad skips at very high quantizers on extreme inputs.
}}

{{bq
chroma SSDチェックにおける整数のオーバーフローを修正。
極端な入力における非常に高いquantizerで、不正なスキップを引き起こしていたかもしれない。
}}
quantizerには妥当な日本語訳があるのだろうか。
「量子化値」が妥当かとも思うが、QP（量子化パラメータ）と紛らわしくなってしまう。

!x264r1443
{{bq
git-id : 4784723450ae1dd28ede1ff04a93f1849d6444e5
Author : Anton Mitrofanov
Date: Tue Feb 16 09:41:55 2010 -0800

Fix I and B-frame QPs with threads
Rounding errors resulted in slightly wrong QPs with threads enabled.
}}

{{bq
スレッド使用時のI/BフレームのQPを修正。
スレッド有効時に丸めエラーが結果として僅かに誤ったQPになっていた。
}}
QPが上がり気味になっていたっぽい。

!x264r1442
{{bq
git-id : 781d300ab73671bb2176ef2c3e6c0f2df425cee9
Author : David Conrad
Date: Mon Feb 15 01:02:46 2010 -0800

Fix compilation on ARM
}}

{{bq
ARMでのコンパイルを修正。
}}
ARMのビルドにのみ影響。

!x264r1441
{{bq
git-id : b8485e875ed3cb836ac41b11676940e2c6ff6caa
Author : Loren Merritt
Date: Thu Jan 28 18:09:07 2010 +0000

Remove unnecessary PIC support macros
yasm has a directive to enable PIC globally
}}

{{bq
不要なPICサポートマクロを削除。
yasmにはグローバルにPICを有効にするディレクティブがある。
}}
プログラミングに興味がある向きに説明しておくと、PICはPosition Independent Codeのこと。

モダンなOSでは共有ライブラリ（最も一般的な例で言えばWindowsのDLL）がサポートされている。
ビルド時にはこれらがメモリ空間のどこにロードされるか不明であるため、変数や関数のアドレスを参照するコードは、絶対アドレスに依存するものであってはならない（または、依存を解決する手段が必要である）。
そのために位置に依存しないコード＝PICが利用されるが、アーキテクチャ（CPU・OS）によっては自動でこれに対応せず、明示的にPICの生成を指定する必要があるケースがある（gccにも同様のオプションがある）。

x86では一般的にこの指定は不要なことが多いのだが、どうやらx86_64では必要らしい（もちろんOSによる可能性もある）。
これを必要時にマクロで個別指定するのではなく、yasmのディレクティブ（指示子：アセンブルオプションをコードで示すようなもの）で一括して解決するようにしたということ。

PICの指定は共有ライブラリに必須とは限らず、パフォーマンスに影響するだけの場合もある。これは対象とするアーキテクチャがサポートする共有ライブラリの形式によって、絶対アドレスへの依存問題を解決する方法が異なるためだ。

筆者はBinary Hacks等の低レベルな技術に必ずしも明るくないので、興味のある方はお使いのOS・プロセッサごとに、ご自身で調べていただきたい。ひとまずWindowsでいえば、IAT/INT(Import Address Table / Import Name Table)が関連する。dumpbinコマンドのオプション/FIXや/RELOCATIONSなども理解の助けになるかもしれない。

!x264r1440
{{bq
git-id : d2277586a7bce99caa448b3d461f6f42e8a20e6d
Author : Jason Garrett-Glaser
Date: Sat Feb 13 11:19:38 2010 -0800

Don't even try direct temporal when it would give junk MVs
In PbBbP pyramid structure, the last "b" cannot use temporal because L0Ref0(L1Ref0) != L0Ref0.
Don't even bother analyzing it, just use spatial.
Should improve speed and direct auto effectiveness in CRF and 1-pass modes when b-pyramid is used.
Also makes --direct temporal useful with --b-pyramid, since it will fall back to spatial for frames where temporal is broken.
}}

{{bq
不正なMVを生成しうる場合にはdirect temporalを試しもしないように。
PbBbPというピラミッド構造で、最後の"b"はL0Ref0(L1Ref0) != L0Ref0であるためtemporalを使用することができない。
いっそその解析に思い悩まず、単にspatialを使用する。
b-pyramidが使用されている場合のCRFと1-passモードにおいて、速度とdirect autoの高価が改善するはず。
また、temporalでおかしくなるフレームに対してはspatialにフォールバックすることで、--direct temporalが--b-pyramidで有用であるようにした。
}}
恐らくこれまでは一部のBフレームを参照するBフレーム(b)で不正なMVを参照し、バグに近い動作になっていたと思われる。

L0Ref0(L1Ref0) != L0Ref0は、上記の例で言えば最後のPが参照するL0Ref0フレーム（つまり最初のP）と最後のbが参照するL0Ref0（つまり真ん中のB）が違う、という事を言っているようだ。関数的に、L0Ref0(L1Ref0(this)) != L0Ref0(this)と考えれば良さそう。

!x264r1439
{{bq
git-id : 520ba2becf677d5ed8c1d7141eb25c65d08a3b3e
Author : David Conrad
Date: Sun Oct 4 07:24:42 2009 -0400

iPhone compilation support
Also add --sysroot to configure options

To build for iPhone 3gs / iPod touch 3g:
CC=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc ./configure --host=arm-apple-darwin --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk

For older devices, add
--extra-cflags='-arch armv6 -mcpu=arm1176jzf-s' --extra-ldflags='-arch armv6' --disable-asm
}}

{{bq
iPhone向けのコンパイルをサポート。
また、configureオプションに--sysrootを追加。

iPhone 3gs / iPod touch 3g向けにビルドするには：
CC=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc ./configure --host=arm-apple-darwin --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk

より古いデバイス向けには、追加で
--extra-cflags='-arch armv6 -mcpu=arm1176jzf-s' --extra-ldflags='-arch armv6' --disable-asm
}}
Appleのgasがショボく特殊であるために、通常のgasライクなプリプロセッサをperlで組んでいるというのが面白い。
x264でperlのコードを見ることがあろうとは。

!x264r1438
{{bq
git-id : 2b5a0c693faa4b807d02b923f596a2aff6778760
Author : David Conrad
Date: Fri Jan 8 22:40:09 2010 -0500

ARM NEON versions of weightp functions
}}

{{bq
weightp関数のARM NEONバージョン。
}}
ARMにのみ影響。

!x264r1437
{{bq
git-id : 40dce15a622a82e6cce0e7233aa75831162635b1
Author : David Conrad
Date: Sat Feb 13 01:25:56 2010 -0800

Use #ifdef instead of #if in checkasm
}}

{{bq
checkasmにて#ifではなく#ifdefを使用。
}}
対象がcheckasmでコスメティックスな上にARCH_PPCに対するものなので一般にはほぼ関係ない。

!x264r1436
{{bq
git-id : aa2626c567083432f56368bee9c9d43d7c8e1fef
Author : Jason Garrett-Glaser
Date: Sat Feb 13 00:52:31 2010 -0800

Make the ABR buffer consider the distance to the end of the video
Should improve bitrate accuracy in 2-pass mode.
May also slightly improve quality by allowing more variation earlier-on in a file.

Also fix abr_buffer with 1-pass: it does something very different than what it does for 2-pass.
Thus, the earlier change that increased it based on threads caused 1-pass ABR to be somewhat less accurate.
}}

{{bq
ABRバッファが映像の終端までの距離を考慮するようにした。
2-passモードにおけるビットレートの精度が向上するはず。
ファイル中でより多くのバリエーションを早期に許可することで僅かに画質をも向上するかもしれない。

また、1-passでのabr_bufferを修正：2-passにおいて行う事とは非常に異なる事をする。
そのため、スレッドに基づいて増加する早期の変更は1-pass ABRに対していくらかの精度低下を引き起こしていた。
}}
少し自信がないのだが、最後の文をより意訳すると、「スレッド数に応じて早期にバリエーションが増加してしまうことで…」といった意味だと思われる。

!x264r1435
{{bq
git-id : dcef20c00f1248beb7a6a55448976be6cbd3ee5b
Author : Alexander Strange
Date: Sat Feb 13 02:22:04 2010 -0500

Mark cli_input/output_t variables as const when possible
}}

{{bq
cli_input/output_t変数を可能な場合にはconstにした。
}}
「内容を変更することのない変数にはconst修飾子を付ける」という、
一般的に望ましいプログラミング上の慣習に従っただけで、処理内容に変化はない。

!x264r1434
{{bq
git-id : dffb2036daed615908ab666d7f6130abed6d0160
Author : Alexander Strange
Date: Sat Feb 13 02:00:57 2010 -0500

mkv: Write the x264 version into the file header

This only updates the "writing application"; matroska_ebml.c is the
"muxing application", but the version string for that is still hardcoded.
}}

{{bq
mkv: x264のバージョンをファイルヘッダに書き込み。

これは"sriting application"のみを更新する；matroska_ebml.cは"muxing application"だが、そのバージョン文字列はハードコード（固定）されている。
}}

!x264r1433
{{bq
git-id : f3de1741f1e38c6b0d4262e6290a20b3e35f6692
Author : Alexander Strange
Date: Sat Feb 13 01:41:41 2010 -0500

mkv: Write SimpleBlock instead of Block for frame headers

mkvtoolnix writes these by default since 2009/04/13.
Slightly simplifies muxer and allows 'mkvinfo -s' to show B-frames
as 'B' (but not B-ref frames).
}}

{{bq
mkv: フレームヘッダーに対しBlockの代わりにSimpleBlockを書き込み。

mkvtoolnixは2009/04/13以来、デフォルトでこれを書き込んでいる。
僅かにmuxerをシンプル化、Bフレームを'B'として表示（B-refフレームではなく）するために'mkvinfo -s'を許可。
}}

!x264r1432
{{bq
git-id : 9eb5b912e317b4d3d106a55080b7aafd3d0f4af7
Author : Alexander Strange
Date: Mon Nov 10 00:55:20 2008 -0500

Allow | as a separator between psy-rd and psy-trellis values.
[,:/] are all taken when setting psy-trellis in a zone in an mencoder option.

Also fix a comment typo and remove a useless line of code.
}}

{{bq
psy-rdとpsy-trellisの値のセパレータ（区切り）として、「|」を許可。
mencoderのオプションにおいてzoneでpsy-trellisを設定する場合に[,:/]が全て受け付けられる。

また、コメントのタイポ（誤植）を修正し、コードの無意味な行を削除した。
}}
ちょっと良くわからないのだが、なぜ「|」が許可されると書いて[,:/]になるのだろう？
[,:|]の間違い？

!x264r1431
{{bq
git-id : 41db4e8355e2390c430071c6f5ed9a2c8851e0a6
Author : Jason Garrett-Glaser
Date: Fri Feb 12 21:15:12 2010 -0800

Backport various speed tweak ideas from ffmpeg
Add mv0 early termination to spatial direct calculation
Up to twice as fast direct mv calculation on near-motionless video.

Branchless CAVLC level code adjustment based on trailing ones.
A few clocks faster.

Check tc value before clipping in C version of deblock functions.
Much faster, but nobody uses those anyways.

Thanks to Michael Niedermayer for the ideas.
}}

{{bq
ffmpegから様々な高速化のアイディアをバックポート。
spatial directの計算にmv0の早期終了を追加。
ほぼ動きのない映像でdirect mvの計算が最大2倍速い。

trailingに基づく無分岐のCAVLC level code adjustment。
数クロック速い。

Cバージョンのデブロック関数において、クリッピング前にtc値をチェック。
とても速いが、誰も使ってはいないだろう。

このアイディアについて、Michael Niedermayerに感謝する。
}}
申し訳ないが、訳者の知識では"CAVLC level code adjustment based on trailing ones"が何を指しているのか良く分からない。
level/run符号化のアルゴリズム上の話なのだろうが、そのあたりをきちんと理解していないのが痛い。
diffの内容と「無分岐の」というところから高速化であることは間違いない。

!x264r1430
{{bq
git-id : 58fd85453ec62d829663887b960ff7f2fbbc22d1
Author : Jason Garrett-Glaser
Date: Fri Feb 12 03:33:54 2010 -0800

Implement direct temporal + interlaced
This was much easier than I expected.
It will also be basically useless until TFF/BFF support gets in, since it requires delta_poc_bottom to be set correctly to work well.
}}

{{bq
direct temporal + interlacedを実装。
これは想像していたよりかなり簡単だった。
上手く動作するためにはdelta_poc_bottomが正しく設定される必要があるため、基本的にTFF/BFFのサポートが入らなければ役に立たない。
}}
コメントにある通り、えぇぇぇホントに？と思うほどdiffは小さい。
訳者自身は動き補償関連でフィールドを意識するようなコードがもっと必要なのかと想像していたのだが。

!x264r1429
{{bq
git-id : b3225125169210ee8982be05f3b90e3de0bdd95c
Author : Jason Garrett-Glaser
Date: Wed Feb 10 13:44:28 2010 -0800

Allow longer keyints with intra refresh
If a long keyint is specified (longer than macroblock width-1), the refresh will simply not occur all the time.
In other words, a refresh will take place, and then x264 will wait until keyint is over to start another refresh.
}}

{{bq
intra refreshでより長いkeyintを許可。
より長いkeyint（マクロブロック単位での幅-1より長い）が指定されたら、refreshは単に全く発生しない。
換言すれば、あるrefreshが起こったら、別のrefreshを開始するために、x264はkeyintが終了するまで待つ。
}}

!x264r1428
{{bq
git-id : 9f242312eb692831d716ed5772b5b832aac54866
Author : Jason Garrett-Glaser
Date: Wed Feb 10 12:12:29 2010 -0800

Overhaul sliced-threads VBV
Make predictors thread-local and allow each thread to poll the others to get their predicted sizes.
Many, many other tweaks to improve quality with small VBV and sliced threads.
Note this may somewhat increase the risk of a VBV underflow in such extreme situations (single-frame VBV).
This is tolerable, as most relevant use-cases are better off with a few rare underflows (even if they have to drop a slice) than consistent low quality.
}}

{{bq
sliced-threadのVBVをオーバーホール。
predictor（予測器）をスレッドローカルにし、各スレッドが他のスレッドを調査し予測されたサイズを得られるようにした。
その他、小さなVBVとsliced threadでの質を向上する調整を多々。
これはそういった極端なシチュエーション（単一フレームVBV）においてVBVアンダーフローの危険性をいくらか増加させることに注意。
殆どの関係するユースケースでは、一貫した低画質よりも、少数の稀なアンダーフローが（例えそれがスライスをドロップしなければならないとしても）あった方が良いため、これは許容できる。
}}

!x264r1427
{{bq
git-id : 8463781af4fa0f304865adb78a0e86c8a6536e0c
Author : Jason Garrett-Glaser
Date: Tue Feb 9 15:08:31 2010 -0800

Print psy-(rd|trellis) with more precision in userdata SEI
}}

{{bq
SEIのユーザデータにpsy-rd, psy-trellisをより詳細に表示。
}}
具体的には表示桁数を増やした模様。

!x264r1426
{{bq
git-id : 8ab4907f5a550ac17356609522b3426650ba3029
Author : Jason Garrett-Glaser
Date: Mon Feb 15 00:55:16 2010 -0800

More formatting fixes in x264 help
}}

{{bq
更なるx264のヘルプフォーマットの修正。
}}
出力に影響なし。

!x264r1425
{{bq
git-id : 16a1fddbd43ec2352a6cb44c7890c38c6535b726
Author : Henrik Gramner
Date: Mon Feb 8 15:53:52 2010 -0800

Faster 2x2 chroma DC dequant
}}

{{bq
2x2 chroma DC dequant（逆量子化）を高速化。
}}

!x264r1424
{{bq
git-id : ca954495e0f6cee187886a4213ca49bfd2b30be7
Author : Yusuke Nakamura
Date: Mon Feb 8 01:48:38 2010 -0800

Write PASP atom in mp4 muxing
Adds container-level aspect ratio support for mp4.
}}

{{bq
mp4のmuxでPASP atomを書き込み。
mp4に対しコンテナレベルのアスペクト比のサポートを追加。
}}

!x264r1423
{{bq
git-id : bb0990813c7fb047a322c5d463cde5ae8e22c756
Author : Jason Garrett-Glaser
Date: Wed Feb 3 20:27:57 2010 -0800

Fix 2-pass ratecontrol continuation in case of missing statsfile
Didn't work properly if MB-tree was enabled.
}}

{{bq
statsファイルがないケースでの2-passレートコントロールの継続性を修正。
MB-treeが有効な場合に正しく動作しなかった。
}}

!x264r1422
{{bq
git-id : 346165169775c5884a9e964afc253561bb11e2ca
Author : Jason Garrett-Glaser
Date: Wed Feb 3 20:01:16 2010 -0800

Smarter QPRD
Catch some cases in which RD checks can be avoided; reduces QPRD RD calls by 10-20%.
}}

{{bq
より賢いQPRD。
RDチェックが省略出来るケースを捉える；QPRDのRDの呼び出しを10-20%削減。
}}

!x264r1421
{{bq
git-id : da9b9d33425f0492235129ae8937fa7edd64e0a6
Author : Jason Garrett-Glaser
Date: Wed Feb 3 18:36:44 2010 -0800

Fix subpel iteration counts with B-frame analysis and subme 6/8
Since subme 6 means "like subme 5, except RD on P-frames", B-frame analysis
shouldn't use the RD subpel counts at subme 6. Similarly with subme 8.
Slightly faster (and very marginally worse) compression at subme 6 and 8.
}}

{{bq
Bフレーム解析とsubme 6/8におけるsubpelのイテレーションカウントの修正。
subme 6の意味は「PフレームでのRDを除きsubmeと同様」なのだから、subme 6ではBフレーム解析がRD subpelカウントを使用するべきではない。
subme 8も同様である。
subme 6と8で圧縮が僅かに高速化（だが極僅かに圧縮率が悪化）。
}}

!x264r1420
{{bq
git-id : 698bbac16e95a4a161a22b3a88e0aa6f9ed6333f
Author : Jason Garrett-Glaser
Date: Wed Feb 3 18:19:29 2010 -0800

Simplify decimate checks in macroblock_encode
Also fix a misleading comment.
}}

{{bq
macroblock_encodeにおけるdecimate（間引き）チェックをシンプル化。
また、誤解の恐れがあるコメントを修正。
}}
ここで言っているdecimateはオプションのdct-decimateのこと。

!x264r1419
{{bq
git-id : 1ec82b87c875c5fa6e66e9cbedb4ec04ac6c058c
Author : Jason Garrett-Glaser
Date: Tue Feb 2 03:15:18 2010 -0800

Improve bidir search, fix some artifacts in fades
Modify analysis to allow bidir to use different motion vectors than L0/L1.
Always try the <0,0,0,0> motion vector for bidir.
Eliminates almost all errant motion vectors in fades.
Slightly improves PSNR as well (~0.015db).
}}

{{bq
bidir検索を改善、フェードにおけるアーティファクトを修正。
L0/L1とは異なる動きベクタをbidirが使用できるように解析部を変更。
bidirに対し、常に<0,0,0,0>動きベクタを試行する。
フェードにおける誤った動きベクタのほぼ全てを排除。
さらにPSNRを僅かに改善（〜0.015db）。
}}
フェードにおいてMVが錯綜したりiのMBが増えてしまう可能性があることは、以前にweightpのところで述べた通り。
今回はこれの対策を更に増強したものと思われる。

画面構成は固定でフェードしている場合にはMVはゼロで構わないのに、誤ってMVが錯綜するのを避けるため、ゼロMVを常に試すようにしたということ。

これはr996あたりでオプションとしては無くなり、subme>=5で自動的に有効になるようになった、いわゆるbimeの改善と思われる。

!x264r1418
{{bq
git-id : 08d4a999b0300e50196afb3ee0e310834028b537
Author : Jason Garrett-Glaser
Date: Mon Feb 1 13:04:47 2010 -0800

Slightly faster predictor_difference_mmxext
}}

{{bq
predictor_difference_mmxextを僅かに高速化。
}}

!x264r1417
{{bq
git-id : f555cf3758f46f3c4f7a2f05094b16f8f3c25a27
Author : Jason Garrett-Glaser
Date: Fri Jan 29 02:40:41 2010 -0800

Add ability to adjust ratecontrol parameters on the fly
encoder_reconfig and x264_picture_t->param can now be used to change ratecontrol parameters.
This is extraordinarily useful in certain streaming situations where the encoder needs to adapt the bitrate to network circumstances.

What can be changed:
1) CRF can be adjusted if in CRF mode.
2) VBV maxrate and bufsize can be adjusted if in VBV mode.
3) Bitrate can be adjusted if in CBR mode.
However, x264 cannot switch between modes and cannot change bitrate in ABR mode.

Also fix a bug where x264_picture_t->param reconfig method would not always be frame-exact.

Commit sponsored by SayMama video calling.
}}

{{bq
レートコントロールのパラメータをオンザフライで調整する機能を追加。
encoder_reconfigとx264_picture_t->paramはレートコントロールパラメータを変更するために使用できるように。
これはエンコーダがネットワーク事情に適応する必要のあるような、特定のストリーミング環境で非常に有用である。

変更できるのは：
1)CRFモードではCRFが調整可能。
2)VBVモードではVBV maxrateとbufsizeが調整可能。
3)CBRモードではビットレートが調整可能。
ただし、モード間の変更と、ABRモードでのビットレートは変更できない。

x264_picture_t->paramの再設定メソッドが必ずしもフレームに正確ではないバグを修正。

コミットはSayMamaビデオ電話によるスポンサード（提供）。
}}
X264_BUILD 85。

リアルタイムエンコードでストリーミング配信するような用途にしか意味はない。

!x264r1416
{{bq
git-id : fcf70c2f9853d74ac077a7af016e28eef05e2f5a
Author : Yusuke Nakamura
Date: Sat Jan 30 13:53:01 2010 -0800

Fix regression in r1406
Bitrate was printed incorrectly for some input framerates.
}}

{{bq
r1406でのレグレッションを修正。
いくつかの入力フレームレートでビットレートが不正に表示されていた。
}}

!x264r1415
{{bq
git-id : 3f3343abfba8a2377a66b6a7f7a8c564ade86bc6
Author : Loren Merritt
Date: Sat Jan 30 12:01:51 2010 -0800

Fix log2f detection, include order, some gcc warnings
r1413 caused crashes on any system with malloc.h.
Also switch to std=c99 or std=gnu99 if supported by the compiler.
Fix visualize support.
}}

{{bq
log2fの検出、いくつかのGCCの警告、includeの順序を修正。。
r1413はmalloc.hのあるシステムでクラッシュを引き起こしていた。
また、コンパイラがサポートしていれば、std=c99またはstd=gnu99に切り替えるように。
visualize（視覚化）のサポートを修正。
}}
ユーザレベルではコスメティックス相当。

"-std=gnu99"が使えるならそれを、そうでなく"-std=c99"が使えるならそれをCFLAGSに追加。
"-std=c99"の場合には"-D_POSIX_C_SOURCE=200112L -D_BSD_SOURCE"も加えられるのでさらにffmpegっぽく…。

!x264r1414
{{bq
git-id : 63b74d874328e630ecb7eaa37cf780c45b992f0e
Author : Jason Garrett-Glaser
Date: Fri Jan 29 11:01:44 2010 -0800

Fix abstraction violations in x264.c
No calling application--not even x264cli--should ever look inside x264_t.
}}

{{bq
x264.cの抽象化違反を修正。
いかなる呼び出し側アプリケーション−−x264cliでさえ−−も、x264_tの内部を見るべきではない。
}}

!x264r1413
{{bq
git-id : 2d2c8616c03586575529bb19cacfd8b6b01c3508
Author : Diogo Franco
Date: Thu Jan 28 17:28:03 2010 -0800

Move -D CFLAGS to config.h
}}

{{bq
-D CFLAGSをconfig.hに移動
}}
ビルドにのみ影響。

!x264r1412
{{bq
x264r1412
git-id : 3838c301e1ee1718e6f1e037d21bb21525b3eab6
Author : Steven Walters
Date: Thu Jan 28 17:26:40 2010 -0800

Fix stat with large file support
}}

{{bq
大きなファイルをサポートするようstatを修正。
}}
#include <sys/stat.h>が#define _LARGEFILE_SOURCE 1と#define _FILE_OFFSET_BITS 64の後に来るようにした。

!x264r1411
{{bq
git-id : 6bd24a94c06ca81baa0156ff418be247e658a28f
Author : Diogo Franco
Date: Wed Jan 27 20:29:50 2010 -0800

Implement ffms2 version check
Depends on ffms2 version 2.13.1 (r272).
Tries pkg-config's built-in version checking first.
Uses only the preprocessor to avoid cross-compilation issues.
}}

{{bq
ffms2のバージョンチェックを実装。
ffms2 version 2.13.1 (r272)に依存。
pkg-configのビルトインバージョンチェックを最初に試す。
クロスコンパイルの問題を避けるためプリプロセッサのみを使用する。
}}

!x264r1410
{{bq
git-id : 38cfabe33e17940870099fcf5d60daae080a3880
Author : Jason Garrett-Glaser
Date: Wed Jan 27 19:41:27 2010 -0800

Fix implicit CBR message to only print when in ABR mode
Also make it print outside of debug mode.
}}

{{bq
潜在的CBRのメッセージをABRモード時のみ表示するよう修正。
また、デバッグモード以外で表示するように。
}}
以下の条件で強制的にパラメータを変更される。
*ABR（ビットレート指定）でvbv-maxrateを指定していない場合。
**CBRと見なされ、vbv-maxrateにビットレートと同じ値が使われる。
*vbv-bufsizeを指定しているがvbv-maxrateを指定していない場合。
**vbv-bufsizeの指定は無意味なものとして無視される。

!x264r1409
{{bq
git-id : d355878be5616dc871058cb931b281b1d5cfbfbc
Author : Diogo Franco
Date: Wed Jan 27 13:11:08 2010 -0800

Add configure check for log2 support
Some incredibly braindamaged operating systems, such as FreeBSD, blatantly ignore the C specification and omit certain functions that are required by ISO C.
log2f is one of these functions that periodically goes missing in such operating systems.
}}

{{bq
log2のサポートに対するチェックをconfigureに追加。
FreeBSDのようないくつかの非常にイカれたOSでは、明らかにCの仕様を無視して、ISO Cで要求されている特定の関数を除外している。
log2fは、そういったOSで定期的に失われる、これらの関数の1つである。
}}
お怒りは大変ご尤もです…。

!x264r1408
{{bq
git-id : 616900186aa2bf2e04205a010daaa2776bc0944a
Author : Diogo Franco
Date: Wed Jan 27 10:12:42 2010 -0800

Add config.log support
Now, if configure fails, you'll be able to see why.
}}

{{bq
config.logのサポートを追加。
configureが失敗した場合に、なぜかを知ることができるようになった。
}}
ビルドにのみ影響。

なんかビルドの構成がどんどんffmpegっぽくなってきた。

!x264r1407
{{bq
git-id : f20aace8d4fe7e35df9258e4c5fe773d08550f34
Author : Diogo Franco
Date: Wed Jan 27 09:26:35 2010 -0800

Fix cross-compiling with lavf, add support for ffms2.pc
Also update configure script to work with newest ffms.
}}

{{bq
lavfでのクロスコンパイルを修正、ffms2.pcのサポートを追加。
また、最新のffmsで動作するようconfigureスクリプトを更新。
}}
ビルドにのみ影響。

!x264r1406
{{bq
git-id : d81c26db6909e2e3d9b85b21a2618287dce29575
Author : Yusuke Nakamura
Date: Tue Jan 26 16:01:54 2010 -0800

Improve DTS generation, move DTS compression into libx264
This change fixes some cases in which PTS could be less than DTS.

Additionally, a new parameter, b_dts_compress, enables DTS compression.
DTS compression eliminates negative DTS (i.e. initial delay) due to B-frames.
The algorithm changes timebase in order to avoid duplicating DTS.
Currently, in x264cli, only the FLV muxer uses it. The MP4 muxer doesn't need it, as it uses an EditBox instead.
}}

{{bq
DTSの生成を改善、DTS圧縮をlibx264に移動。
この変更はPTSがDTSより小さくなりうるいくつかのケースを修正する。

加えて、新パラメータのb_dts_compress（訳注：libx264のパラメータでCLIのオプションではない）がDTS圧縮を有効にする。
DTS圧縮はBフレームに起因する負のDTS（つまり初期ディレイ）を排除する。
このアルゴリズムはDTSの重複を避けるためにタイムベースを変更する。
現在のところ、x264cliでは、FLV muxerのみがこれを使用する。MP4 muxerはEditBoxを使用するため、これを必要としない。
}}
X264_BUILD 84。

念のためおさらいしておくと、''PTS''(Presentation Time Stamp)は表示時刻のことで、''DTS''(Decoding Time Stamp)はデコード時刻のこと。
Bフレームの存在により格納順（デコード順）と表示順が異なるMPEG系の映像圧縮技術で、これらを管理するためにMPEG1の時代から存在している時刻情報だ。
当然、デコードより先に表示されるわけはないので、一つのフレームのPTSがDTSより先立つ時刻になるのは不正である。

MPEG-1またはMPEG-2 PS(Program Stream)の場合は''SCR''(System Clock Reference)、MPEG-2 TS(Transport Stream)の場合は''PCR''(Program Clock Reference)により復号機（デコーダ）で''STC''(System Time Clock)が再現され、このSTCとPTS/DTSを比較しながら同期処理を行う。

EditBoxとはr1379でMP4コンテナの初期ディレイの調整に使用されるようになったedtsのこと。
なお、MP4コンテナの規格(ISO/IEC 14496-12)では、PTSは規格書には登場しないらしく、''CTS''(Composition Time Stamp)に置き換わっている。
意味合いとしては名前の通りバッファ上へのComposition（合成）時刻であって、Presentation（表示）時刻ではない。
特に、オフセット値としての基準位置が違うらしく、''初期ディレイが絡むとPTS＝CTSではなくなる''が、CTSからの計算によって一応PTS相当のものは求まる。

今回の変更では、タイムスタンプに関連する場当たり的な泥臭い対応を廃し、内部的にはこのPTSに相当するものとDTSでシンプルに扱うようになった。
上記で言及されてるPTSとはその「PTS相当のもの」を指しているのだろう。
これらをmuxerで取り扱う際に、コンテナごとに適切な変形（MP4ならCTSに変換するなど）をするのみで、綺麗に処理できるようになっている。

しかし、日本人が書いたcommitのchangelogを日本語訳する日が来るとは…複雑な気持ちだ。

!x264r1405
{{bq
git-id : 3659b8124a809c39d61a28bdf1b235e81c02b06d
Author : Anton Mitrofanov
Date: Tue Jan 26 11:41:18 2010 -0800

Various threading-related cosmetics
Simplify a lot of code and remove some unnecessary variables.
}}

{{bq
様々なスレッド関連のコスメティックス。
多くのコードを単純化、いくつかの不要な変数を削除。
}}

!x264r1404
{{bq
git-id : 0f985245093047980c1b6148562222265b230dff
Author : Jason Garrett-Glaser
Date: Mon Jan 25 11:23:55 2010 -0800

Hardcode the bs_t in cavlc.c; passing it around is a waste

Saves ~1.5kb of code size, very slight speed boost.
}}

{{bq
cavlc.c中のbs_tをハードコード；これを渡して回るのは無駄。

コードサイズを〜1.5kb節約、非常に僅かに速度向上。
}}

!x264r1403
{{bq
git-id : 00f933f05df722e4b133d2c57f1f45dba285430c
Author : David Conrad
Date: Sat Jan 23 18:05:25 2010 -0800

Fix lavf input with pipes and image sequences
x264 should now be able to encode from an image sequence using an image2-style formatted string (e.g. file%02d.jpg).
}}

{{bq
パイプと静止画シーケンスでのlavf入力を修正。
image2形式の文字列書式（例えばfile%02d.jpgといった）を使用する静止画シーケンスからx264がエンコードをできるようになるはず。
}}

!x264r1402
{{bq
git-id : 1a1b356a2996629d2c5ad2b568df8df9bff32954
Author : Jason Garrett-Glaser
Date: Thu Jan 21 23:07:11 2010 -0800

Fix bitstream alignment with multiple slices
Broke multi-slice encoding on CPUs without unaligned access.
New system simply forces a bitstream realignment at the start of each writing function and flushes when it reaches the end.
}}

{{bq
複数スライスでのビットストリームのアラインメントを修正。
非アラインアクセスのないCPUでマルチスライス符号化を壊していた。
新しいシステムは単純に、各書き込み関数の先頭においてビットストリームの再アラインメントを強制し、最後にフラッシュする。
}}

!x264r1401
{{bq
git-id : 90a249aa40deec9234f9ea7554deb8a418183094
Author : Jason Garrett-Glaser
Date: Thu Jan 21 10:00:07 2010 -0800

Merge nnz_backup with scratch buffer
Slightly less memory usage.
}}

{{bq
nnz_backupをスクラッチバッファに統合。
僅かにメモリ使用量を減少。
}}

!x264r1400
{{bq
git-id : 20fa784d2d9e0d5e524d4e3834699e9ff9b57511
Author : Steven Walters
Date: Wed Jan 20 09:00:54 2010 -0800

Use cross-prefix properly with pkg-config for cross-compiling
}}

{{bq
クロスコンパイルのためにpkg-configに対し正しくcross-prefixを使用。
}}
ビルドにのみ影響。