x264-changelog-jp r1400-r1499

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

x264-changelog-jp r1400-r1499

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

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

x264r1499

git-id : 8a919f81065cccb65ff7c989fffec9258362900b

Author : Henrik Gramner

Date: Tue Mar 16 01:46:00 2010 +0100

Cosmetics: use sizeof() where appropriate

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

x264r1498

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.

analyse_initを分割。

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

x264r1497

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.

b-adapt 2のtrellisのスタック使用量を削減。

また、いくつかの冗長なコードを削除。

スタックとはメモリの一種だが、これでプログラムが使用する総メモリ使用量が削減されているとは限らない。ただし、一般的に言ってメインメモリへのアクセスが減って高速化することは期待できる。

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

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

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

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

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

x264r1496

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.

動き見積もりの様々な最適化。

MV rangeをチェックする手法を高速化。

bidir qpel-RDに対しMVの予測とMV/MVDのキャッシュ。

その他小さな最適化を多数。

僅かに高速化・圧縮率向上。

x264r1495

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.

macroblock_cache_rectのオーバーホール。

矩形（訳注：四角形のこと）関数群をffmpegのfill_rectangleと同様の一つの関数に統合。

可変サイズであるcache_rectの呼び出しケースを全て除去；そのようなケースの処理のために関数ポインタベースのシステムを作成。

そのような呼び出しに必要なコードサイズを劇的に減少するはず。

common/rectangle.cとcommon/rectangle.hが追加。

x264r1494

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.

小さい関数群をALWAYS_INLINEに。

恐らく今現在は現実的な効果はないが、次のパッチに必要。

x264r1493

git-id : 6b585097ec92eb40e5785d8beee8b236781d5d86

Author : Loic Minier

Date: Wed Mar 10 05:26:46 2010 -0800

Two compatibility fixes

Add IA64 support in configure.

互換性の修正を2つ。

configureにIA64のサポートを追加。

ビルドにのみ影響。

x264r1492

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.

x264_macroblock_encode_pskipを高速化。

GCCはどうやら変数が使用されていない場合にその計算を最適化することができないようだ。

ソースコードを確認したが、2行目の意味するところがよく分からなかった。GCCが出力したアセンブリまでは確認していない。

x264r1491

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.

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にNon-local RD optimizationという項目があった。ここでは主に「現在のMBへの決定が将来に及ぼす影響を考える場合の最適化」、つまり時間軸の意味で語られているようだ。

x264r1490

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.

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

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

ヘルプの表示にのみ影響。

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

x264r1489

git-id : 632af6683de604141c636d659a2d229b61ba5ecb

Author : James Darnley

Date: Sat Mar 6 18:28:07 2010 -0800

Fix typo in configure

configureのタイポ（誤植）を修正。

FFMS2関連。

x264r1488

git-id : ea93d786162b7cd77a3254cf48dba356be74cf76

Author : David Conrad

Date: Sat Mar 6 10:29:57 2010 -0800

Add support for spaces to iPhone GAS preprocessor script

iPhone GASプリプロセッサスクリプトにスペースのサポートを追加。

GASプリプロセッサスクリプトとはr1439のPerlスクリプト。

x264r1487

git-id : d84a1a95f4db132a374d550c98fa85e00075e7a8

Author : Yusuke Nakamura

Date: Sat Mar 6 19:25:30 2010 +0900

Fix slightly wrong mp4 duration.

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

x264r1486

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.

最新のgpacのcvsとのリンクエラーを修正。

gpacは勝手にAPIを破壊し、我々に彼ら独自のmallocとfreeを使うよう要求することを決めた。

ビルドにのみ影響。

x264r1485

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.

スライスヘッダで数ビットを節約。

最大参照インデックスがデフォルトと同じならば、スライスヘッダ内でこれをオーバーライドしない。

また、PPS内の関連する変数の名前を更新。

x264r1484

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.

x264_t内のいくつかの配列を縮小。

また、cache_loadから不要な代入を削除。

x264r1483

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

fprintfの代わりにx264_logをより多くの箇所で使用。

出力データに影響なし。

x264r1482

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.

非決定性を2つ修正。

ノイズリダクションデータをスレッド固有のデータに移動。

L1のtemporal（時間軸）予測器に正しい参照リストを使用。

以前にも書いたけれど、決定性とは、再現性とも言い換えられる。何回エンコードを行っても同じ出力が再現されるように修正したということ。

x264r1481

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.

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

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.

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

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.

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

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.

Bフレームに対するMixed-refsをサポート。

小さな速度コスト、通常ではせいぜい数%程度。一般的にはこれが有用でない場合に最も低いコストになる。高度に複雑なソースにおいて、全体で最大〜2%の圧縮率向上。

また、Bフレーム解析のいくつかの小さなバグ修正とクリーンアップを色々。

これまでPフレームにしか有効ではなかったmixed-refsがBフレームにも有効になった。地味に結構重要だろう。

x264r1477

git-id : e5b108a3de97650ad4bbeb4f3ff13cff916d6052

Author : Henrik Gramner

Date: Mon Mar 1 22:01:04 2010 +0100

Faster rounding of chroma DC coefficients

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

x264r1476

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.

cabac_encode_decision_asmの高速化。

命令数を最小化、コードも小さくなるということ。

命令レベルの並列性を向上する、その他様々の僅かな変更。

x264r1475

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.

hpel_filterの高速化。

SSSE3において、hのフィルタにもpmaddubswを使用（vのフィルタと同様）。

32-bitのvとcのフィルタが結果を非テンポラルに書き込むように変更。

コメントアウト状態で非テンポラル処理を無効にするためのdefineを追加。

ここには殆ど黒魔術はないのだが、それでも、特にSSSE3に対して一定の優位がある。

アセンブラレベルの最適化の話なので、このchangelogを素人がそのまま読むのは少々難しい。

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

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

x264r1474

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

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

y4mscalerはXYSCSSが444の4:2:0ファイルを生成するようだ。

y4mscalerとやらまでは調べていないが、y4m(yuv4mpeg)形式のヘッダには、色空間の指定としてCタグ（新しく標準的）とXYSCSSタグ（古く非標準的）があるらしい。

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

x264r1473

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.

r1450でのレグレッションを修正。

I_PCMブロックはx264をクラッシュさせるか、不良な出力を生成させていた。PCM処理をシンプル化。

x264r1472

git-id : 7d533c57ee25a73c79b10ef7fb36324727e38582

Author : Jason Garrett-Glaser

Date: Sat Feb 27 14:26:02 2010 -0800

Fix crash with intra-refresh + aq-mode 0

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

x264r1471

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

r1453でのレグレッションを修正。

r1453は--trellis 2でのpsy-trellisを壊していた。

x264r1470

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).

r1449でのレグレッションを修正。

スレッドMVチェックの不正な配置が稀に、特に--non-deterministicで、スレッドMVの内部エラーを起こしていた。

これらは致命的なエラーではない（x264はこれを回復して、僅かな圧縮率のロスだけで処理を継続できた）。

x264r1469

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.

MVD配列のサイズを再び2の係数で削減。

各MBのエッジのMVDのみを格納。

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

x264r1468

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

--disable-asmが指定された場合、AltivecとVISの最適化を無効化。

PowerPCにのみ影響。

x264r1467

git-id : 4091b29c0dcaa2ceaedbdf5be9c283beb70fe327

Author : Loren Merritt

Date: Tue Feb 23 23:50:23 2010 -0800

Fix a buffer overread on odd input resolutions

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

x264r1466

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.

VBVが困窮するケースでのバグを1つ修正。

qp_novbvがBフレームに対し正しく設定されていなかった。

複雑性がゼロであるフレームに対してABRコードを無効化。

CBRモードに対してABRコードを無効化；完全に不要で、マイナスの影響をもたらしうる。

x264r1465

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

ffmpegからMans RullgardのNEON版intra予測関数を移植。

ARMにのみ影響。

x264r1464

git-id : e29c75837c72a0ed387441ffa6bab339dbe3de9f

Author : Jason Garrett-Glaser

Date: Tue Feb 23 13:52:15 2010 -0800

Remove unused function

Two other minor fixes.

不使用の関数を削除。

他に2つの小さな修正。

出力に影響なし。

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

x264r1463

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.

可能なシチュエーションで短いスタートコードを更に使用。

以前のパッチはB.1.2によって可能な用途の全てをカバーしていなかった。

r1458で「最初のスライス（以外）」と言っていたのが「最初のNAL（以外）」になったようだ。

x264r1462

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.

fastfirstpassを修正。

どうやら、不注意でlibx264のプリセットが"fastfirstpass"を"fastsecondpass"に変更していたようだ。

inadvertantlyはinadvertentlyのタイポ。

x264r1461

git-id : ad64d48f17335e820d7a0a563a88436f38ccb813

Author : Anton Mitrofanov

Date: Tue Feb 23 09:10:26 2010 -0800

Fix various silly errors in the previous patches

最近のパッチにおける様々なくだらないエラーを修正。

内容からpreviousは「最近の」と訳した。

x264r1460

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.

preset/tune/profileが不正な場合に、ちゃんとエラーになるように。

libx264ベースのプリセットに移行する際のどこかで消えていた。

パラメータチェックだけなので出力に影響なし。

x264r1459

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.

より高速な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

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.

可能な場合には短いスタートコードを使用。

最初以外の各スライスで、フレームごとに1バイトを節約。

Annex-B出力モードにのみ適用。

x264r1457

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.

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

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.

MinCRのレベル制限を遵守。

いくつかのBlu-ray解析機がこれにケチを付けていた。

X264_BUILD 88。

MinCRはmin compression ratioらしい。

x264r1455

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).

b-pyramid normalをデフォルトにした。

今やb-pyramidはMB-treeと同時に動き、かつ仕様を満たしているので、デフォルトにしない正統な理由がない。

映像によるが、圧縮率を0〜5%改善。

また、none/strict/normalのエイリアス（別名）として0/1/2を使用可能にした（簡潔さのため）。

X264_BUILD 87。

x264r1454

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.

preset, tune, profileをlibx264内に移動。

libx264を呼ぶ任意のアプリケーションがこれらを使用可能に。

完全なドキュメントと使用方法のガイドラインはx264.hに含まれている。

X264_BUILD 86。

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

x264r1453

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.

高速でより精密なpsy-RDキャッシング。

アダマール変換スコアキャッシュの変数をより多く保持し、必要な場合のみそれらを計算する。

計算が多くなるが、lookup（表引き）がより単純に。

SATDとSA8D関数内の丸め処理に起因して、僅かに精密になる。

x264r1452

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.

かなり高速で効率的なMVD処理。

MV deltaをクリップされた絶対値として格納。

これはMVコンテキスト選択において、CABACはもはや絶対値を計算する必要がない事を意味する。

これはまた、MVDに費やすメモリを2の係数で削減することを可能にし、（それによって・その結果として）cache_mvdを高速化、メモリ使用量を32*<スレッド数>*<マクロブロック数>バイト減少させる。

Core i7での1080pのエンコードで、これは約3メガバイトの節約になる。

x264r1451

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

interlacedエンコードにtemporal予測器のサポートを追加。

interlacedモードにおいて0.5〜1%の圧縮率改善。

TODO:r1430では足りていなかったということ？

x264r1450

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.

マクロブロックパーティションのtrack（追跡）を保持。

動き補償とdirect MVの計算を広くシンプル化可能に。

これも注意した方がいいコードに当たるだろうなぁ…。

+    /* 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

git-id : 4574b58c7d66d793bd28e3ce506165ca1c9e7680

Author : Jason Garrett-Glaser

Date: Tue Feb 16 10:13:33 2010 -0800

Much faster and simpler direct spatial calculation

direct spatialの計算をかなり高速化＆シンプル化。

注意した方がいいかもしれない表現。

-    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が

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 Commondefinitions <stddef.h>でマクロとしてのNULLが"expands to an implementation-defined 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）。なお、if(!NULL)という表現に関しても、同様に考えられる。論理否定の「!」演算子は6.5.3.3 Unaryarithmetic operatorsで"The expression !E is equivalent to (0==E)."とされている。つまりif(!NULL)はif((0==NULL)!=0)と展開され、…以下同文。

x264r1448

git-id : 1a6d32b4a42f490ec817aa2ddb543dda8d9a8c9e

Author : Jason Garrett-Glaser

Date: Sun Feb 21 14:21:26 2010 -0800

SimpleBlock requires Matroska Doctype v2

SimpleBlockはMatroska Doctype v2を必要とする。

mkv出力でヘッダが変わる。

x264r1447

git-id : 966fd12a2a9beb3bba294dc4a91a45bbafc4799f

Author : Yusuke Nakamura

Date: Tue Feb 16 11:05:21 2010 -0800

Add GPAC version check

GPACのバージョンチェックを追加。

ビルドにのみ影響。

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

x264r1446

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.

r1430におけるinterlaced時のアホくさいレグレッションを修正。

ref > 8またはb-pyramidで、配列の過大読込が僅かに不正なBフレームを引き起こしていたかもしれない。

x264r1445

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.

スクラッチバッファの過大読込を修正。

非mod16なフレームにおいてクラッシュを引き起こしていたかもしれない。

x264r1444

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.

chroma SSDチェックにおける整数のオーバーフローを修正。

極端な入力における非常に高いquantizerで、不正なスキップを引き起こしていたかもしれない。

quantizerには妥当な日本語訳があるのだろうか。「量子化値」が妥当かとも思うが、QP（量子化パラメータ）と紛らわしくなってしまう。

x264r1443

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.

スレッド使用時のI/BフレームのQPを修正。

スレッド有効時に丸めエラーが結果として僅かに誤ったQPになっていた。

QPが上がり気味になっていたっぽい。

x264r1442

git-id : 781d300ab73671bb2176ef2c3e6c0f2df425cee9

Author : David Conrad

Date: Mon Feb 15 01:02:46 2010 -0800

Fix compilation on ARM

ARMでのコンパイルを修正。

ARMのビルドにのみ影響。

x264r1441

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

不要な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

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.

不正な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

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

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

git-id : 2b5a0c693faa4b807d02b923f596a2aff6778760

Author : David Conrad

Date: Fri Jan 8 22:40:09 2010 -0500

ARM NEON versions of weightp functions

weightp関数のARM NEONバージョン。

ARMにのみ影響。

x264r1437

git-id : 40dce15a622a82e6cce0e7233aa75831162635b1

Author : David Conrad

Date: Sat Feb 13 01:25:56 2010 -0800

Use #ifdef instead of #if in checkasm

checkasmにて#ifではなく#ifdefを使用。

対象がcheckasmでコスメティックスな上にARCH_PPCに対するものなので一般にはほぼ関係ない。

x264r1436

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.

ABRバッファが映像の終端までの距離を考慮するようにした。

2-passモードにおけるビットレートの精度が向上するはず。

ファイル中でより多くのバリエーションを早期に許可することで僅かに画質をも向上するかもしれない。

また、1-passでのabr_bufferを修正：2-passにおいて行う事とは非常に異なる事をする。

そのため、スレッドに基づいて増加する早期の変更は1-pass ABRに対していくらかの精度低下を引き起こしていた。

少し自信がないのだが、最後の文をより意訳すると、「スレッド数に応じて早期にバリエーションが増加してしまうことで…」といった意味だと思われる。

x264r1435

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

cli_input/output_t変数を可能な場合にはconstにした。

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

x264r1434

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.

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

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

x264r1433

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).

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

mkvtoolnixは2009/04/13以来、デフォルトでこれを書き込んでいる。

僅かにmuxerをシンプル化、Bフレームを'B'として表示（B-refフレームではなく）するために'mkvinfo -s'を許可。

x264r1432

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.

psy-rdとpsy-trellisの値のセパレータ（区切り）として、「|」を許可。

mencoderのオプションにおいてzoneでpsy-trellisを設定する場合に[,:/]が全て受け付けられる。

また、コメントのタイポ（誤植）を修正し、コードの無意味な行を削除した。

ちょっと良くわからないのだが、なぜ「|」が許可されると書いて[,:/]になるのだろう？[,:|]の間違い？

x264r1431

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.

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

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.

direct temporal + interlacedを実装。

これは想像していたよりかなり簡単だった。

上手く動作するためにはdelta_poc_bottomが正しく設定される必要があるため、基本的にTFF/BFFのサポートが入らなければ役に立たない。

コメントにある通り、えぇぇぇホントに？と思うほどdiffは小さい。訳者自身は動き補償関連でフィールドを意識するようなコードがもっと必要なのかと想像していたのだが。

x264r1429

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.

intra refreshでより長いkeyintを許可。

より長いkeyint（マクロブロック単位での幅-1より長い）が指定されたら、refreshは単に全く発生しない。

換言すれば、あるrefreshが起こったら、別のrefreshを開始するために、x264はkeyintが終了するまで待つ。

x264r1428

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.

sliced-threadのVBVをオーバーホール。

predictor（予測器）をスレッドローカルにし、各スレッドが他のスレッドを調査し予測されたサイズを得られるようにした。

その他、小さなVBVとsliced threadでの質を向上する調整を多々。

これはそういった極端なシチュエーション（単一フレームVBV）においてVBVアンダーフローの危険性をいくらか増加させることに注意。

殆どの関係するユースケースでは、一貫した低画質よりも、少数の稀なアンダーフローが（例えそれがスライスをドロップしなければならないとしても）あった方が良いため、これは許容できる。

x264r1427

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

SEIのユーザデータにpsy-rd, psy-trellisをより詳細に表示。

具体的には表示桁数を増やした模様。

x264r1426

git-id : 8ab4907f5a550ac17356609522b3426650ba3029

Author : Jason Garrett-Glaser

Date: Mon Feb 15 00:55:16 2010 -0800

More formatting fixes in x264 help

更なるx264のヘルプフォーマットの修正。

出力に影響なし。

x264r1425

git-id : 16a1fddbd43ec2352a6cb44c7890c38c6535b726

Author : Henrik Gramner

Date: Mon Feb 8 15:53:52 2010 -0800

Faster 2x2 chroma DC dequant

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

x264r1424

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.

mp4のmuxでPASP atomを書き込み。

mp4に対しコンテナレベルのアスペクト比のサポートを追加。

x264r1423

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.

statsファイルがないケースでの2-passレートコントロールの継続性を修正。

MB-treeが有効な場合に正しく動作しなかった。

x264r1422

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%.

より賢いQPRD。

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

x264r1421

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.

Bフレーム解析とsubme 6/8におけるsubpelのイテレーションカウントの修正。

subme 6の意味は「PフレームでのRDを除きsubmeと同様」なのだから、subme 6ではBフレーム解析がRD subpelカウントを使用するべきではない。

subme 8も同様である。

subme 6と8で圧縮が僅かに高速化（だが極僅かに圧縮率が悪化）。

x264r1420

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.

macroblock_encodeにおけるdecimate（間引き）チェックをシンプル化。

また、誤解の恐れがあるコメントを修正。

ここで言っているdecimateはオプションのdct-decimateのこと。

x264r1419

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).

bidir検索を改善、フェードにおけるアーティファクトを修正。

L0/L1とは異なる動きベクタをbidirが使用できるように解析部を変更。

bidirに対し、常に<0,0,0,0>動きベクタを試行する。

フェードにおける誤った動きベクタのほぼ全てを排除。

さらにPSNRを僅かに改善（〜0.015db）。

フェードにおいてMVが錯綜したりiのMBが増えてしまう可能性があることは、以前にweightpのところで述べた通り。今回はこれの対策を更に増強したものと思われる。

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

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

x264r1418

git-id : 08d4a999b0300e50196afb3ee0e310834028b537

Author : Jason Garrett-Glaser

Date: Mon Feb 1 13:04:47 2010 -0800

Slightly faster predictor_difference_mmxext

predictor_difference_mmxextを僅かに高速化。

x264r1417

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.

レートコントロールのパラメータをオンザフライで調整する機能を追加。

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

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.

r1406でのレグレッションを修正。

いくつかの入力フレームレートでビットレートが不正に表示されていた。

x264r1415

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.

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

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.

x264.cの抽象化違反を修正。

いかなる呼び出し側アプリケーション−−x264cliでさえ−−も、x264_tの内部を見るべきではない。

x264r1413

git-id : 2d2c8616c03586575529bb19cacfd8b6b01c3508

Author : Diogo Franco

Date: Thu Jan 28 17:28:03 2010 -0800

Move -D CFLAGS to config.h

-D CFLAGSをconfig.hに移動

ビルドにのみ影響。

x264r1412

x264r1412

git-id : 3838c301e1ee1718e6f1e037d21bb21525b3eab6

Author : Steven Walters

Date: Thu Jan 28 17:26:40 2010 -0800

Fix stat with large file support

大きなファイルをサポートするようstatを修正。

#include <sys/stat.h>が#define _LARGEFILE_SOURCE 1と#define _FILE_OFFSET_BITS 64の後に来るようにした。

x264r1411

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.

ffms2のバージョンチェックを実装。

ffms2 version 2.13.1 (r272)に依存。

pkg-configのビルトインバージョンチェックを最初に試す。

クロスコンパイルの問題を避けるためプリプロセッサのみを使用する。

x264r1410

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.

潜在的CBRのメッセージをABRモード時のみ表示するよう修正。

また、デバッグモード以外で表示するように。

以下の条件で強制的にパラメータを変更される。

• ABR（ビットレート指定）でvbv-maxrateを指定していない場合。
  • CBRと見なされ、vbv-maxrateにビットレートと同じ値が使われる。
• vbv-bufsizeを指定しているがvbv-maxrateを指定していない場合。
  • vbv-bufsizeの指定は無意味なものとして無視される。

x264r1409

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.

log2のサポートに対するチェックをconfigureに追加。

FreeBSDのようないくつかの非常にイカれたOSでは、明らかにCの仕様を無視して、ISO Cで要求されている特定の関数を除外している。

log2fは、そういったOSで定期的に失われる、これらの関数の1つである。

お怒りは大変ご尤もです…。

x264r1408

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.

config.logのサポートを追加。

configureが失敗した場合に、なぜかを知ることができるようになった。

ビルドにのみ影響。

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

x264r1407

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.

lavfでのクロスコンパイルを修正、ffms2.pcのサポートを追加。

また、最新のffmsで動作するようconfigureスクリプトを更新。

ビルドにのみ影響。

x264r1406

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.

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

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.

様々なスレッド関連のコスメティックス。

多くのコードを単純化、いくつかの不要な変数を削除。

x264r1404

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.

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

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

x264r1403

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).

パイプと静止画シーケンスでのlavf入力を修正。

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

x264r1402

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.

複数スライスでのビットストリームのアラインメントを修正。

非アラインアクセスのないCPUでマルチスライス符号化を壊していた。

新しいシステムは単純に、各書き込み関数の先頭においてビットストリームの再アラインメントを強制し、最後にフラッシュする。

x264r1401

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.

nnz_backupをスクラッチバッファに統合。

僅かにメモリ使用量を減少。

x264r1400

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

クロスコンパイルのためにpkg-configに対し正しくcross-prefixを使用。

ビルドにのみ影響。