r1800-r1899このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。r1800-r1899r1800-r1899のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。frames.x264cliの進捗情報の更新間隔を改善。Nフレーム毎ではなく0.25秒毎に更新する。エンコード後に元のコンソールタイトルを復帰させる。MSDNのドキュメントはSetConsoleTitleの効果はプロセス終了後に取り消されると言うが、これは必ずしも正しく動作しない。このため、エンコード終了時に手動でコンソールタイトルを戻すようにした。yet.インターレースモードでWEIGHTP_FAKEを許可。本物のweightpはinterlaceをまだサポートしていないが、これはそのままで上手く動くようだ。APIでpic_structの情報を出力。CPUでFastShuffleを有効にした。configureconfigureの小さなコスメティックス。cosmetics--helpの様々なコスメティックス。重複する関数でエラー。同じ名前の関数が2つある場合に、黙ってその片方をリネームするのではなく、コンパイルエラーとする。AVXAVXを扱うため、yasmの要求バージョンを上げた。r1881.subme=10での稀な破壊を修正。scalingにおける間抜けなバグを修正。r1881でのレグレッション。predでのオーバーフローを修正。パッチはffmpegからのバックポート。framesVFR入力でいくつかのフレームに対する不正なdurationを修正。durationは(以下略。r1873.mkvとflvのmuxerにおけるcloseでのゼロ除算の可能性を修正。ouput.set_param以前に何か(例えばx264_encoder_openによって拒否される不正なパラメータ)で失敗した場合にクラッシュとなりうる。r1873で持ち込まれたバグ。ratio.SPSを変更するパラメータの再設定を修正。今は、これはアスペクト比だけである。threadが無効化された場合のPhenom上でのクラッシュの可能性を修正。ミスアラインマスクはメインスレッドでもエントリに設定される必要がある。emergencyでのいくつかのバグのホットフィックス。cpu.ccpu.cでの警告を修正。later.CPUIDに加え、OSのAVXのサポートをチェック。ymmレジスタを使用しない場合でさえも、非サポートのOSではAVXの処理がSIGILLを引き起こす。SP1以降でのみ利用可能。SIGILLは要はクラッシュ。レートコントロールが最大値を超える"quantizer"を選択可能にする。underflowを回避するために、進行的にソースを間引く。x264は今や、/dev/randomのような極悪な入力に対してさえ、VBVを順守するようになった。mode"も"quantizers"も訳さなかった。ソース映像をひん曲げてでもVBVを守ってやろうというモードの実装。/dev/randomでVBVを守るなんて凄い事ですよ...。benefits.初期的なAVXのサポート。SSEとAVXの抽象化と、3オペランド命令を自動的に扱う。初期テストとして1つの関数(denoise_dct)をこれで実装。x264はAVXの256-bitサポートをあまり活用できない(浮動小数点のみであるため)が、3オペランドはいくらか小さな利益を生むかもしれない。denoise_dctは--nrで使われてるらしいですよ(未確認)。used.frame-sequentialな3Dファイルに対しベースのフレームレートを二倍に。60fpsのframe-sequentialな3Dファイルは実際には30fpsで、両目に交互に映るだけである。従って、レートコントロールはそれが実際には30fpsであるかのように扱うべきである。5が使用されている場合に、そのような映像に対しては、同じCRFのレベルでもビットレートは増加することになる。format.lavf入力に--input-fmtオプションを追加。ffmpegの"-f"オプションと同様。lavfが入力形式の推測に失敗する場合に使うと良い。branch.レグレッションテストスクリプトに2つの改善。OSのファイル名の制限を超えないよう、一時ファイルの名前にSHA-1ハッシュを使用。ブランチ上にいた場合、テスト後にオリジナルのブランチに正しく戻るように。table非拡張SARテーブルに欠けていた値を足した。2011日付を2011に更新。SEIのフラグをより正しく書きこむように。バグはNeroによる報告。cleanup).x264_encoder_encodeでエラーが発生した場合にx264_encoder_closeで死なないようにした。x264.cで正しくクリーンアップするようにした(ほぼクリーンアップでのバグを見つける用)。B-frames.b_tffのreconfigを修正。エンコーディング中にフィールドオーダーを変更しようとするのは少々不正になりうる。B-frame無しでインターレースモードが使用された場合にdelta_poc_bottomが正しく設定されるように修正。anyways.Windowsにおける64以上のCPUでのx264のCPU検出を修正。x264は一つのプロセッサグループ分のCPUしか実際には使用しない。いずれにしても一つのx264のインスタンスは64コアをフル活用できないため、これは問題ではない。sse2であるpmuludqを使用していたが、その関数はpmuludqなしには成り立たない。cache32でのキャッシュラインチェックを修正。不正な出力にはなっておらず、少数の旧式のシステム上でわずかに速度が落ちていたのみ。overflow.高ビット深度のssd_nv12_mmxextでの不正な命令を修正。不幸にもpaddqはmmxextでは利用不可で、sse2とそれ以上でのみ利用可能。本当にオーバーフローなしに幅を最大16416/32832まで許すよう修正。timestamps.VFR/framerateを考慮するratecontrol、その2。MB-treeとqcompの複雑性見積もりはその計算上、フレームのdurationを考慮するようになった。長時間持続するフレームは生来的に、品質観点でより重要であることから、これは視覚的最適化にとって非常に重要である。極端なテストケースでは、VFRを考慮したPSNRで1-2db相当、より一般的なVFRクリップ(例えばdedupされたアニメエピソード)では〜0.5dbを改善する。警告:この変更はx264内部の品質計測を再定義する。x264は前述のフレームduration理論に従い、その品質を映像のフレームレートを基準にスケールする。Xは、30fpsの映像より60fpsの映像に対して、フレームあたりの品質をより低くするということである。これは以前よりも--crfを一定な(訳注:「変動しづらい」の意味であり「ある任意の」という意味ではない)知覚的画質に近づける。この変更の「中心」は25fpsである:これは、25fps未満の映像は同じCRFにおいて画質が上がり、25fps超の映像は下がるということ。この選択は完全に任意である。これを完璧に活用するために、x264はあなたの映像を正しいフレームレートとタイムスタンプでエンコードしなければならないことに注意。r1763で準備がなされていたものを更に進めた実装。durationとは、分かりやすく言えば表示期間である。MP4の実装を行なっている訳者的には「表示期間」という訳し方は若干危険かもしれないので、訳文中ではdurationのままとした。若干分かりにくくなってしまうが、L-SMASHメンバーの中ではdurationに対し「持続時間」という訳語を使用していたりする。VFRとはつまり、フレームごとにその表示されている期間が異なる映像だ。他のフレームより2倍の時間表示されるフレームには、倍のデータを割り当てるのが適正なんじゃないのか、というような考え方を形にしたのがこの実装である。この変更により、--crfが考える「品質」の基準が変更される。これまでの--crfとは、フレームレートによって、1フレームあたりの品質(とサイズ)が変わった。目安として「これまでと同じCRF値で同じフレームあたりの品質が再現される」フレームレートが25fpsとされており、30fpsの場合は、以前と同じCRF値を使用すると、1フレームあたりの品質とサイズが低下する。videoで参照の整序を改善。低ビットレートでかつB-framesなしの場合にはより役立つ。3Dだとx264に告げられなければ、この最適化を行わない事に注意。packingが3Dコンテンツを圧縮するための圧倒的に最良な手段であることを、テストは一貫して示している。これは分離ストリームやtop/bottom、left/right符号化に比較して〜35-50%の圧縮率の利得を生み出す。reorderingのサポートを追加した。ref0に対するサポートを追加した;将来的には他の事柄にも有用であろう。3Dというのは、3D映像の符号化方式の一種だろう。確認していないが、名前からすると2つの視点の映像を時間的に交互に格納する方式だろうか。reorderingが非常に気になる。これも確認していないが、内容を読む限り(前revの内容も合わせて)BフレームのL1がこれまで未来方向のみ指していたものを、過去方向も自由に指せるようにしたのかも。すれば、規格では許されているがx264の実装的に制限していた部分の一つで、比較的大きなものが変わったことになると思われる。確証が取れていないが、BugMaster氏と話した限りでは、過去のフレームをL1として使うものではなく、L1の参照リストに含まれる未来のフレームの順序を変更可能にした、ということのようだ。easier.コスメティックス:fref0/1→fref[2]とi_ref0/1→i_ref[2]。必要とされたリファクタリングであり、そして次のパッチをより楽にする。2.weightpの解析中に追加のオフセットをチェック。Code-In.SSE2版の高ビット深度用SSIM関数群。Code-In.SSE2版の高ビット深度用intra_predict_(8x8c|16x16)_p。Code-In.MMX版の高ビット深度用coeff_last4。Code-In.SSE2版の高ビット深度用zigzag_interleave_cavlc。Code-In.MMX/SSE2/SSSE3版の高ビット深度用frame_init_lowres関数群。intra予測関数群。DDRとHD方向、そしてHUを高速化。追加されていたが正しく有効化されていなかった、いくつかの高ビット深度関数のSSE2バージョンを有効化。intra予測関数群。HD方向と8x8フィルタ。