r2300-r2399このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。r2300-r2399r2300-r2399のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。r2400-r2499?最近は全くと言っていいほどdiffを見ていないため、速報とか暫定訳とか仮訳とか書いてなくとも色々怪しいです。violationを修正。Windowsでgdb配下においてクラッシュを引き起こし、その他の何がしかの問題を起こしていたかもしれない。WindowsWindows上でのGPACのサポートを修正。Unicodeサポート。x264はUTF-8向けに設計されているが、他のほとんどのオペレーティングシステムと異なり、WindowsはUnicode文字列にUTF-16を使用する。内部的に文字列をUTF-8として保持する。CLIコマンドラインをUTF-16として取得しそれをUTF-8に変換する。APIを使用し、呼び出し時に文字列をUTF-16に変換する。Unicodeサポートのない外部ライブラリに対しては、古い8.3の短いファイル名を使用しようと試みる。Artsimovich.AVC-Intraのサポート。この形式はリバースエンジニアリングされたもので、x264の出力はPanasonicのカメラやエンコーダーが作り出すものとほとんど同じビットストリームである。RP2027に適合しない。Quantelでテストされている。Artsimovichにより行われた。オプションに--avcintra-compatが追加。intraフレームだけで構成する、主に映像編集向けの形式。hugepageのサポート。フレームとmbデータのmallocを一つの大きなmallocに統合。加えて、hugepageのサポートのあるLinuxシステムでは、大きなmallocにおいてhugepageに問い合わせる。これはメモリフットプリントの小さな減少と共に、hugepageのサポートがないシステムで小さな性能向上(〜0.2-0.9%)をもたらす。hugepageサポートが有効化されている最近のLinuxカーネルにおいては、典型的な設定で7-12%のメモリ消費量を増加させるのと引き換えに、最大4%程度、性能を向上させる。ハードウェアによる、改善された2MBのページサポートがあるHaswellや他の最近のCPUでは、より有効だろう。メモリ管理の速度的コストを低減する実装。hugepageがどういったものであるかの説明がないためにわかりづらいが、これはソフトウェア的なメモリ管理のコストと、ハードウェア的なメモリ管理のコストの両面で有用な変更になる。ソフトウェア的な面から言うと、C言語上でメモリを確保するmallocというのは、内部的に排他処理やリスト管理が必要であるため、基本的でありながら速度的コストの高い処理である。使用することがわかっているメモリであれば、細かいサイズで複数回mallocを呼ぶよりも、一括して確保してしまえば効率がいい。mallocされた領域の管理コストもmallocの回数が多ければ多いほど高く付く。ハードウェア的な面から言うと、CPUはCPUで、プロセスが論理的なメモリ空間(32bitなら4GiBの空間)内のどこをどのくらい実際に使用しているか、というのを管理し、物理メモリと対応付けている。その管理はバイト単位ではなくページ単位で行っており(ページング)、1ページが4KiB(12bitのアドレス空間)である。ページ内オフセットの12bitアドレス空間)を9bitごとに4つに分け、さらに階層化がなされている。あるメモリにアクセスしようとした場合、上位から9bit分ずつのテーブルを4回参照して(PTE)4KiBのページに辿り着く。現在の巨大なメモリ空間では4KiBは小さすぎて、これまた効率が悪い。そこで登場するのがhugepageで、考え方としては上記の階層のうち最下層を無視して、12+9=21bit空間、つまり2MiBで1ページとしてしまう。すると、3回の参照でページまで辿り着くことができ、PTEとそのキャッシュであるTLEアクセスの省力化となる。2MiBのページを一体に扱うことで、フレームバッファなどの「メモリブロック中のどこかを参照する場合は、その中の他の場所も参照する可能性が高い」メモリにおいて、その一部が4KiBごとにフラグメントしてしまう可能性も排除できる。メモリを大きな単位で(大雑把に)扱うようになるため、2MiBがフルに活用されない場合は「CPU的には割り当て済みだけと実際には使われない」半端な領域ができる。このため、hugepageの仕組みは速度と容量のトレードオフとなる。全てのページが2MiBではあまりに非効率であるため、実際には従来の4KiBページとhugepageは共存し、確保するメモリサイズによって使い分けられる。組み込みシステムではよくある仕組みだ。hugepageは以前には特殊な仕掛けを使用し、ソフトウェア側でも意識してコードを書く必要があったが、LinuxがネイティブにサポートしたことでTransparent(透過的)、つまり殆ど意識すること無く使用可能になった。ソフトウェア面の工夫と、ハードウェアの機能・特性の活用という2面から、使用するメモリをまとめて大きなブロックとして扱おうというのがこのパッチになる。pixel_sad_x3とpixel_sad_x4のSSSE3実装。pixel_sad_x3とpixel_asd_x4を高速化。cygwin64をサポート。__OUTPUT_FORMAT__が"x64"の値を持つかをチェック。これはWIN64でも有効な値である。refreshが、許可されないピクセルからの予測を許可してしまっていたケースを修正。analyzer静的解析ツールで発見されたいくつかの小さなバグを修正。CPUID"が有効にされている場合のAVX2の検出バグを修正。X264_CPU_SSE_MISALIGN関数を削除。bitがクリアされていた場合のクラッシュを防ぐ。CPUでのみ使用され、その利得は非常に小さい。それらはMXCSRコントロールレジスタを修正することも要求するが、それら関数を削除することでその複雑性も共に取り除くことができる。VEX-encoded命令は非アラインメモリオペランドもサポートする。Bridge上では全く性能の向上がなかった。pixel_sad_x3とpixel_sad_x4には有意なコードサイズの減少があったため、それらは保持することとし、いくつかの小さなコスメティックスと調整を追加した。deblocking.i16x16-delta-quant-avoidanceのコードを調整。これはデブロックにより引き起こされる稀なflickering問題を修正する。コードを見たほうが良さそうだが時間がない。deblock_luma_h_intraを高速化。coefficientsを追加。今のところ使用する機会は少ないかもしれないが、HEVCで主に使われるであろうbt2020などが追加になっている。settings.segmentエンコーディングのために"--stitchable"オプションを追加。headerを最適化しようとするのを止め、ビデオの異なるsegmentが、同一のエンコーディング設定において、同一のヘッダを持つように保証する。同じヘッダを持っていれば、ヘッダ領域を除いたバイトデータを単に後ろに結合するだけで連続再生可能なデータとなる(ちょっと語弊があるけど)。それをstitchableと呼んでいる。x264を使用したシステムを組む場合、そうできたほうが便利なケースがあるので用意されたのだろう。同じ意味を持つヘッダでも、ビット単位で同一でないと、解析して意味を考慮しないと同一性を保証できないため、muxerにとっては負担となる。このオプションを指定すればヘッダが同一であることを簡単に確認できるので、扱いやすい。するよりもユーザーにとって妥当だろう。cosmeticsOpenCLのコスメティックス。NALUを書き込もうとする際にクラッシュする可能性を修正。Bitstream-reallocation関数はfillerのケースを扱っていなかった。systemsいくつかのシステムにおけるPICビルドの修正。denoise_dctにおける潜在的な非アラインによるクラッシュを修正。asmをサポートしないコンパイラでのビルドを修正。非アラインスタックでの高ビット深度ビルドにおけるクラッシュを修正。X上でのOpenCL付きコンパイルを修正。エンコード中にOpenCLエラーが発生した場合のクラッシュを修正。patch.OpenCLサポートの改善・リファクタリング。OpenCLのライブラリを自動読み込みすることでopenCL-enabledでビルドされたx264を実行する必要がなくなった。最初のパッチで変更されるべきだったのだが、X264_BUILDを更新。deblockからいくらかの命令を削減。dequant_4x4_dc。AVX2高ビット深度逆量子化。hpel_filterの64-bit版。32-bitより〜5%速い。AVX2高ビット深度denoise_dct。28→15サイクルに。Bridgeで3サイクル高速化。AVX2高ビット深度量子化。