最初の部分へのリンク 。
エンコーダーはデコーダーではなく、テストするのが一般的な事前定義されたビデオシーケンスのセットがないため、最初からプロセス全体が複雑になることに注意してください。 しかし、一般的に使用されるものがあります。通常は、一部のコーデック（またはその実装）が他のコーデックよりも優れていることを証明します。
モスクワ州立大学の研究者たちによって大きな比較が行われています。ここで見ることができます： compression.ru
比較について話すと、品質（主観的または客観的）と生産性という2つの基準を区別できます。 まれなコーデックは、両方のカテゴリで一度に勝つことができます。 ただし、エンコーダのテストに焦点を当てます。
そのため、入力には非圧縮ビデオといくつかのコーデック（エンコーダー自体）の実装があり、出力は圧縮クリップです。 上記の入力についてはすでに少し説明しましたが、想像力とライセンスによってのみ制限されていることに注意してください。 つまり いつでも自分でビデオを撮影してから、それを使用してデコーダー/エンコーダーをモックできます。同じ目的でインターネットから映画をダウンロードできるとは限りません。 さらに、ノイズ、同じ色のフレームなど、人工的なシーケンスを作成すると便利です。
長い圧縮プロセスの後、検証された圧縮フローの厳密な仕様を取得します。 ソースデータにあったほとんどすべてのものがあります（非可逆圧縮について話している）。 このファイルを調査する必要があります。 また、仕様について話しているため、重要なチェックの1つは、クリップが規格に準拠していることを確認することです。
これはサードパーティのツールで行うのが最適です。したがって、サードパーティのユーザーの評価に対する信頼は高くなります。
しかし、イニシアチブは常に罰せられるわけではありません。願望があります-ファイルをそのコンポーネントに解析し、すべてを再確認することもできます。 これは、エンコーダーがすべてのパラメーターを希望の方法で記録し、いかなる方法でも記録しないようにするためにも行う必要があります。 もちろん、この場合、エンコーダー設定で「ひきつける」ことができる「ノブ」に限定されます。
X264ファンは少ないスイッチで我慢する必要があります
しかし、エンコードされたファイルに戻ります。 ユーザーに表示される画像の品質を評価する方法は？ すべてが最初の部分にあったものと非常に似ています：デコーダが必要です、
できればサードパーティのリファレンスを使用して、二重エラーを回避してください
その助けを借りて、圧縮されていないビデオシーケンスを取得します。このシーケンスは、既知のメトリックPSNRおよびSSIMを使用して元のビデオシーケンスと比較できます。
ただし、ここで重要な質問に行きます。ビデオの「類似性」のしきい値はどうあるべきでしょうか。 言い換えれば、どのPSNR / SSIM値が私たちを満足させ、どれが満足させないのでしょうか？ 一般的に、良いとは悪くないとき、つまり アーティファクトや歪みなど、目が嫌いなものはありません。 そして、私たちのメトリックがそれを捕まえたらそれは良いことです。 秘密の場所に目的の番号を書き留めて、次のチェックで使用することを忘れないでください-そして突然何かが壊れました。 しかし、「破壊」はさまざまな方法で行うことができます。
昨日、エンコーダーがYビットレートでX dBを与えたとしましょう（一定のビットレートでエンコードします）
他のすべてのパラメーターは考慮せず、固定のままにします
現在、当社のエンコーダは同じビットレートでX1 dBを生成します。 元気？ アラームを鳴らしますか？ 分ですが、X1はXよりも大きいですか？ もしそうなら、すべてが問題なく、エンコーダーはより良く動き始めました！ かどうか？ すべてが私たちが望むほど単純ではありません：一定のビットレートを使用するとき、それが実際に一定であるという保証はありません-わずかな逸脱が可能です（両方向）。 ここで、おそらくより高い品質はビットレートの増加によるものだと想像してください。 そして、これは実質的な改善がないことを意味します。エンコーダはより多くのビットを取得することで「ごまかし」、品質を改善するために使用していました。 また、Xと比較したX1の値の減少は、エンコーダーの劣化を示していません-ビットを節約した可能性があります。 道徳：より多くはより良いという意味ではなく、より少ないことはより悪いという意味ではありません。
しかし、画質について私たちは何ですか？ デコーダーについても考えてみましょう。そうすれば、エンコードされたこのすべてのかすを分解する必要があります。 エンコーダーは必要なすべてのパラメーターをストリームに入れましたか？ 彼はそれらを正しくしましたか？ 説明した標準のすべての要件と要件を順守しましたか？
これらすべてとそれ以上のことを確認し、再確認してから明確にする必要があります。 毎回、すべてのエンコーダーで。 しかし、これについてはすでに少し話しました。
そして、これですべてを完了することができるように見えますが、一つだけあります：同じSDKがあります！ これは、メモリ、スレッド、およびユーザーが変更できる他のすべてを操作するためのすべてのオプションをチェックする必要があることを意味します。 理論的には、ほとんどの場合、SDKを使用するすべての方法で同じ結果が得られます。
実は、ユーザーがシステムメモリではなくD3Dメモリを使用する場合、なぜ品質が低下するのでしょうか。 または、非同期の深さが変更されます。 または、より多くの（またはより少ない）スレッドを使用することにしました。
そのため、最もよく使用されるモデルのいくつかを非常によくテストし、残りのモデルを比較できます。 これは、デコード処理（生のビデオを取得するため）とメトリックの計算（生のファイルのみに基づく）を安く呼び出すことができないためです。
要約すると、デコーダーをテストする際に入力データに最も関心があり（より多様であるほど良い）、その後、エンコーダーをテストする際にすべてが重要であることに注意してください：入力データとエンコードパラメーターの両方が非常に多く存在する可能性があります また、2番目のケースのチェック自体は、よりインテリジェントである必要があります。
UPD
ビデオ前処理のテストアプローチのレビューに関する記事は、 ISNで読むことができます。