r1400-r1499このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。r1400-r1499r1400-r1499のchangelogの日本語訳。その他のリビジョンと注意事項についてはx264-changelog-jpへどうぞ。appropriateコスメティックス:適切な場所でsizeof()を使用。init.analyse_initを分割。いくつかの不要な初期化を避け、その他をスレッドごとの初期化に移動することで時間を節約。2のtrellisのスタック使用量を削減。いくつかの冗長なコードを削除。スタックとはメモリの一種だが、これでプログラムが使用する総メモリ使用量が削減されているとは限らない。一般的に言ってメインメモリへのアクセスが減って高速化することは期待できる。「スタック」とは、より一般的にはLIFOのデータ構造を指す言葉だが、スタックフレームを指すことも非常に多く、ここではそちらの意味になる。スタックフレームとは、簡単に言えばC言語の関数の引数やローカル自動変数等に使用されるメモリ領域の事だ。これは「コンパイラがどのようにして現実のプログラムでC言語の仕様を実現するか」という命題に対する実装上の用語なので、C言語の初級的な教科書では教えないことも多い。スタックフレームが理解できているかどうかで、C言語の初級者と中級者の区別が付くことも非常に多い。スタックフレームは関数が呼ばれる時に確保され、関数から戻ると解放される。関数が呼ばれる度に積まれるので、データ構造としてのスタックと無関係な用語というわけでもない。スタックフレームの積み重なりによるスタックデータ構造全体(変な言い回しだが)をコールスタックと呼ぶ。main()関数を頂点とした関数呼び出しチェーンの木構造の中で、最もコールスタックが大きくなる経路でのサイズが、プログラムのスタック使用量となる。2のtrellisのスタック使用量」が減っても、他の経路でコールスタックがより大きくなるのであれば、プログラム全体のスタック使用量は減らない。これを手作業で調べるのは現実的ではないため、世の中にはソースコードを解析して調べるツールもあるが、x264も多用しているアセンブラや関数ポインタが使用されると解析できないケースも多い。結局のところ絶対的なスタック使用量は、関数呼び出しチェーンの木構造をすべて実行してみて、デバッガやOS側のメモリ管理機構(にそんな機能が用意されているかも謎だが)で調べるくらいしか手がない。2のtrellisがアクセスするメモリの範囲が小さくなった」ということは確実に言える。すると、少なくともCPUのキャッシュメモリがより効率的に動作することは期待できるし、通常で言えば、アルゴリズム(処理手順)自体の改善でメモリアクセスが減っている傾向も期待できるので、高速化しているんじゃないかとは期待できる。使用メモリの減少分をアクセス回数や命令数で補うような「苦しい」変更の場合はこの限りではない。あぁ、勢いで書いたけど細かく突っ込もうと思えばいくらでも突っ込める説明だなぁ。スタックをよく知らない初級者向けの概念的説明ということでご勘弁を。compression.動き見積もりの様々な最適化。rangeをチェックする手法を高速化。qpel-RDに対しMVの予測とMV/MVDのキャッシュ。その他小さな最適化を多数。calls.macroblock_cache_rectのオーバーホール。矩形(訳注:四角形のこと)関数群をffmpegのfill_rectangleと同様の一つの関数に統合。可変サイズであるcache_rectの呼び出しケースを全て除去;そのようなケースの処理のために関数ポインタベースのシステムを作成。そのような呼び出しに必要なコードサイズを劇的に減少するはず。common/rectangle.cとcommon/rectangle.hが追加。patch.小さい関数群をALWAYS_INLINEに。今現在は現実的な効果はないが、次のパッチに必要。configure.互換性の修正を2つ。configureにIA64のサポートを追加。used.x264_macroblock_encode_pskipを高速化。GCCはどうやら変数が使用されていない場合にその計算を最適化することができないようだ。ソースコードを確認したが、2行目の意味するところがよく分からなかった。GCCが出力したアセンブリまでは確認していない。7においてより精密なB-skip検出。x264がP-skipの検出に使用するのと同様の手法を使用。画質を有意に(1-6%)向上、ただし同様に優位な速度コスト(5-20%)による。これは、Bフレームにおける精密でないスキップ検出が僅かに外れたベクタを生じていたケースで、大変プラスの視覚効果を生む。高quantizerにおける低複雑度のフレームにおいて、僅かにボケたりスムーズでない動きを引き起こすかも知れない。この問題のすべての例は解決されていない:唯一の普遍的な解決方法は、x264が現在持っていない、non-locally-optimal(非局所的最適)モード決定である。「non-locally-optimal(非局所的最適)モード決定」は、ストレートに言い換えれば「大域的モード決定」という意味になる。周りのMB(時間軸でも空間軸でも)との相関的な影響を考えてのモード決定、ということだろう。optimizationという項目があった。ここでは主に「現在のMBへの決定が将来に及ぼす影響を考える場合の最適化」、つまり時間軸の意味で語られているようだ。list.--fullhelpにおけるプロファイル制約を再整形。lossless"がデフォルトオプションリストに出るのを避けるためこれらをその各ラインに配置。ヘルプの表示にのみ影響。lossless"はオプションそのものではないので改行して表示したということだろう。configureconfigureのタイポ(誤植)を修正。GASプリプロセッサスクリプトにスペースのサポートを追加。GASプリプロセッサスクリプトとはr1439のPerlスクリプト。duration.僅かに誤っていたmp4のdurationを修正。free.最新のgpacのcvsとのリンクエラーを修正。gpacは勝手にAPIを破壊し、我々に彼ら独自のmallocとfreeを使うよう要求することを決めた。PPS.スライスヘッダで数ビットを節約。最大参照インデックスがデフォルトと同じならば、スライスヘッダ内でこれをオーバーライドしない。PPS内の関連する変数の名前を更新。cache_load.x264_t内のいくつかの配列を縮小。cache_loadから不要な代入を削除。fprintffprintfの代わりにx264_logをより多くの箇所で使用。出力データに影響なし。predictors.非決定性を2つ修正。ノイズリダクションデータをスレッド固有のデータに移動。L1のtemporal(時間軸)予測器に正しい参照リストを使用。以前にも書いたけれど、決定性とは、再現性とも言い換えられる。何回エンコードを行っても同じ出力が再現されるように修正したということ。unstable.VBVで"CRF-max"をサポート。これは一見するよりも使い勝手のあるかもしれない、やや面白い機能だ。CRF-maxは、VBVが有効なCRFモードにおいて、VBVの作用によってさえエンコーダがそれ以下にはしない品質レベルをユーザが指定することを可能にする。これはシーンの複雑性のような課題を意識しないqpmaxとは異なる。これを設定することは、エンコーダがアンダーフローを避けるために対応するCRFを超えねばならない任意の状況において、VBVアンダーフローを引き起こしうる。VBVアンダーフローを引き起こしてでもこれを行いたいか?ストリーミング、特に超低レイテンシ(超低遅延)ストリーミングの場合、あまりに低画質なフレームを表示するよりも、フレームをドロップする方が好ましいことがありうる。そのため、極度に複雑なシーンにおいては、ストリーミングサーバは全くひどい映像を表示するよりも、単に低フレームレートにドロップをしうる。単一フレームVBVのような状況下では通常厳しい見た目であるシーンカットは、若干遅れて表示し、その分フレームをドロップするように処理されることが可能。言い換えれば、scenecutが、150msの間ブロック状のゴミのように見えているよりも、150ms遅延したように見えるほうがよい。呼び出し側では、x264のフレームの出力サイズを検出し、必要であれば将来のフレームをドロップすることで、これは取り扱われる。これは通常のエンコード時にも、単に(潜在的にアンダーフローを引き起こすというコストの元で)VBVが画質をあまりに害することがないことを確かにするために使うことができる。threadsと単一フレームVBVを使用する際にも大変有用である。--crf-maxが追加。要は、MPEG-4の特徴として当初謳われていた、フレームの画質と引き換えにフレームレートを落とすVFRを適応的に利用できるという話。個人的には全く興味が湧かない。ストリーミングに使うにしても、x264cliではそのまま使えない。libx264を使うようなアプリケーションを書いて、適切な処置を入れ、動的にVFR出力にする必要がある。1.21を使用してテストされた。<output>このコマンドはBlu-ray仕様の非常に複雑な制約によって、通常よりかなり複雑になっている。"tune"の後のほとんどのオプションは仕様によって要求されているもの。1または2の映像を不正にデコードするバグのある、既知のBlu-rayプレーヤ(特にMediatek)が存在する。その上なお、Blu-rayの仕様には許される解像度/fpsの組み合わせに大変厳しい制限があることに注意。FILM)と720p@60000/1001fpsを含んでいる。このパッチで導入される機能の詳細:完全なNAL-HRDへの規格準拠、VBR(fillerなし)とCBR(fillerあり)モード。vbr/cbrで有効にできる。libx264はx264_hrd_tの形式で呼び出し側にHRDタイミング情報を返すようになった。x264cliは現在のところこれを使用しないが、この情報は規格に適合するTSのmuxにはクリティカル(非常に重要)なので注意。これは、例え平均フレームレートを知らずとも、x264がビットレートを狙うモードで正しいビットレートを実現することができることを意味する。これはstatsファイルの形式を変更することに注意;このパッチ以前の1st-passエンコードは再度実行される必要がある。pulldownのサポート:libx264は呼び出し側アプリケーションが各フレームに対しpulldownモードを指定することを許可する。Flags)の働きと同様のやり方。libx264はタイムスタンプを修正しないことに注意:呼び出し側アプリケーションがpulldown用にタイムスタンプを正しく設定しているとみなす!x264cliは呼び出し側のpulldownコードの実装例を含んでいる。pic_structのサポート:pulldownに必要で、interlaced符号化を可能にするもの。delta_poc_bottomでTFF/BFFを符号化する:interlaced圧縮を有意に改善するはず。x264に使用すべきフィールドオーダを教えるためには、古い--interlacedよりも--tffと--bffが勧められる。Alstonに大変感謝する。今回の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は若干難しいので素材があって意味が分かる人用。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であったりするが、これらは同じものを指している(準拠する規格による?)。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を別に考えたとしても、このリビジョンの成果は非常に大きいと言えるだろう。well.timecode入力/出力。v1またはv2のファイルを指定することができる。VFR入力の取り扱い時、特にFFMS/LAVFサポートが利用の出来ない場合に有用。v2ファイルを書き出す。新しい--timebaseオプションはストリームのtimebaseをユーザが変更することを可能にする。必要時にtimecodeファイルでtimebaseを強制することを主に意図している。--seekを使用する場合、x264はtimecodeファイルも同様にシークすることに注意。今回のr1472〜r1510までの一連のパッチで、人によっては一番重要かもしれないもの。Author見ればわかるだろうけれど。猫研はあまりVFRに明るいわけでもなく、他によい解説はあるだろうから、余計なことは言わないでおく。libx264から使えるようにはなっていないみたい。ソースにinput/timecode.cが追加。cleanup.Bフレームに対するMixed-refsをサポート。小さな速度コスト、通常ではせいぜい数%程度。一般的にはこれが有用でない場合に最も低いコストになる。高度に複雑なソースにおいて、全体で最大〜2%の圧縮率向上。Bフレーム解析のいくつかの小さなバグ修正とクリーンアップを色々。これまでPフレームにしか有効ではなかったmixed-refsがBフレームにも有効になった。地味に結構重要だろう。DC係数の丸め処理を高速化。parallelism.cabac_encode_decision_asmの高速化。命令数を最小化、コードも小さくなるということ。命令レベルの並列性を向上する、その他様々の僅かな変更。ssse3.hpel_filterの高速化。SSSE3において、hのフィルタにもpmaddubswを使用(vのフィルタと同様)。32-bitのvとcのフィルタが結果を非テンポラルに書き込むように変更。コメントアウト状態で非テンポラル処理を無効にするためのdefineを追加。ここには殆ど黒魔術はないのだが、それでも、特にSSSE3に対して一定の優位がある。アセンブラレベルの最適化の話なので、このchangelogを素人がそのまま読むのは少々難しい。ここで言うtemporalはdirect-mvの話でも、そもそも動画エンコード上の話でもない。「非テンポラルに書き込む」とは、「すぐに再利用される予定がないデータを、キャッシュを通さず書き込む」という意味。少ないキャッシュを少しでも効率的に使用するための改善だ。sfenceという3つの命令を使用するが、その使用・不使用を簡単に切り替えられるようにdefineを用意したということ。444より新しい標準的なCタグが存在する場合にy4m中のXYSCSSを無視。y4mscalerはXYSCSSが444の4:2:0ファイルを生成するようだ。y4mscalerとやらまでは調べていないが、y4m(yuv4mpeg)形式のヘッダには、色空間の指定としてCタグ(新しく標準的)とXYSCSSタグ(古く非標準的)があるらしい。XYSCSSには間違ったカラースペースが指定されていることがあるようなので、Cタグの指定があればそちらに従うようにしたということ。handling.r1450でのレグレッションを修正。I_PCMブロックはx264をクラッシュさせるか、不良な出力を生成させていた。PCM処理をシンプル化。0でのクラッシュを修正。2r1453でのレグレッションを修正。2でのpsy-trellisを壊していた。loss).r1449でのレグレッションを修正。スレッドMVチェックの不正な配置が稀に、特に--non-deterministicで、スレッドMVの内部エラーを起こしていた。これらは致命的なエラーではない(x264はこれを回復して、僅かな圧縮率のロスだけで処理を継続できた)。idea.MVD配列のサイズを再び2の係数で削減。各MBのエッジのMVDのみを格納。Niedermayerに感謝する。specified--disable-asmが指定された場合、AltivecとVISの最適化を無効化。PowerPCにのみ影響。resolutions奇数の入力解像度におけるバッファの過大読込を修正。consequences.VBVが困窮するケースでのバグを1つ修正。qp_novbvがBフレームに対し正しく設定されていなかった。複雑性がゼロであるフレームに対してABRコードを無効化。CBRモードに対してABRコードを無効化;完全に不要で、マイナスの影響をもたらしうる。RullgardのNEON版intra予測関数を移植。fixes.不使用の関数を削除。他に2つの小さな修正。caseでできるようになっただけ)。B.1.2.可能なシチュエーションで短いスタートコードを更に使用。以前のパッチはB.1.2によって可能な用途の全てをカバーしていなかった。r1458で「最初のスライス(以外)」と言っていたのが「最初のNAL(以外)」になったようだ。inadvertantly.fastfirstpassを修正。不注意でlibx264のプリセットが"fastfirstpass"を"fastsecondpass"に変更していたようだ。inadvertantlyはinadvertentlyのタイポ。patches最近のパッチにおける様々なくだらないエラーを修正。内容からpreviousは「最近の」と訳した。presets.preset/tune/profileが不正な場合に、ちゃんとエラーになるように。libx264ベースのプリセットに移行する際のどこかで消えていた。パラメータチェックだけなので出力に影響なし。transform処理。DCTをdct_dcアセンブラ関数内に移動。dct_dcをprobe_skip内の早期終了の一部として使用。