また、あなたが個人的に知っているコーデックはどれくらいありますか？ そして、あなたは自分自身を書き込もうとしましたか？ どの圧縮アルゴリズムが最も効果的ですか？
これらの問題およびその他の問題については、この記事では取り上げません。
パートゼロ、知人
こんにちは、コミュニティ
私の名前はアンドレイです。インテルで働いています。 いくつかの記事で、インテル®Media SDKプロジェクトでビデオコーデックをテストするときに使用するアプローチについて説明する予定です。
パート1、入門
少し前、同僚のDmitry Serkinが、ビデオコーデックの品質の評価に関する記事を書きました（ ISNへのリンク ）。 そこで彼は、検証プロセスについて簡単に言及しました。 この記事の目的は、この活動に光を当てることです。
インテル®Media SDKは、最新のプロセッサー（Sandy Bridge、Ivy Bridge）のマルチメディア機能を使用して、デコード（H.264（AVC、MVC）、MPEG2、VC1、JPEG / MJPEG）、エンコード（H.264（AVC、MVC ）、MPEG2）およびいくつかの前処理操作（インターレースのサイズ変更または削除など）。 しかし、最も重要なことは、これらすべてのアクションを組み合わせてトランスコーダチェーンを構築できることです （中間段階なしで、ある形式を別の形式に変換する）。 また、これにより、SD解像度（720x576、標準解像度）以下をサポートする電話へのFull HDビデオ（1920x1080、高解像度）の転送が高速化されます。
次に、テストの観点からすべてを見てみましょう：5つのデコーダー、3つのエンコーダー、エンコーダー、前処理操作、およびそれらを組み合わせるためのオプション。 すべてのコンポーネントについて、コンテンツも重要であることを忘れないでください-ビデオシーケンスの解像度、エンコードされたストリームのパラメーター（デコーダーの場合）、および使用したいパラメーター（エンコーダーの場合）。 チェックには多くのオプションがあります。 非常に多く。 これが、Dmitryが述べた最も弱いマシンから遠く離れた検証のための時代の始まりです。
はい、もう1つ。 ライブラリには2つの実装があります。1つはプロセッサの機能を使用する「アイアン」、もう1つはアイロンがなくても練習したい場合の2つ目の「ソフトウェア」です。 したがって、前のケースでカウントしたすべての列挙は、安全に2倍します。 当然、オペレーティングシステムは異なります。Win7（x86およびx64）と、これからは説明しません;）
恐怖には大きな目がありますが、ビジネスを行うことが必要です。 まず、考えられるテストシナリオの混乱を整理しましょう。 まず、SDKコンポーネントを互いに分離します。デコーダー、エンコーダー、および前処理操作があります。 次に、各パーツを最大数の意味のあるテストでカバーします。 そして再びすべてを単一の全体-トランスコーダチェーン-に組み立て、コンポーネントの相互作用が重要なテストの一部を繰り返します（このようなテストの定義は別の非常に難しいタスクです）。 次に、すべての詳細を検討します。 デコーダーから始めましょう。
デコーダー
ここではすべてが比較的簡単です。サポートを発表しているため、コーデック実装が正しくデコードするエンコードされたビデオシーケンスの特定のセット（適合セット）があります。 しかし、難しいのは、このセットが常に大きいとは限らず、実際にはもっと多くのオプションがあることです。
自分で多くのテストシーケンスを作成することを妨げるものは何もありません-適切なエンコーダを使用して
同時に、映画全体を再生しないでください。
数学的帰納法
もちろん、デコーダが3〜10秒ではなく、1.5〜3時間動作することを確認することは理にかなっています。
ただし、コーデックが標準に準拠していることだけをチェックするわけではありません。 同じSDKがあります！ また、たとえばシステムメモリとd3dの両方を使用してデコードできます。 はい、さまざまな非同期性がサポートされています。
この場合、これはマルチスレッドの「遠い同義語」です。複数の処理タスクを同時に実行できます（誰かがデコードされ、誰かが前処理され、誰かが既にエンコードされています）
ライブラリ実装の詳細に関連するいくつかの異なるモードがあります。 そして、ここで私たちは再び多くの多くのオプションを手に入れています。
デコード後、非圧縮ビデオシーケンスが得られます。これは品質を評価するのに便利です。 しかし、どのように？ 同じ PSNR（ピーク信号対雑音比、 wiki ）？ 計算的に重いSSIM（Structural Similarity、 wiki ）？
メトリクスに関する叙情的な余談：デコードされたシーケンスごとに主観的な分析を行うことは非常に困難です-目がぼやけており、見方が異なります。 したがって、客観的な指標が使用されます。 数学を集めています。 しかし、これらのメトリックスは非常に大きな名前が付けられていますが、メトリックスが1つのことを示し、目が何かを言う場合があります。
SSIMを使用したPSNRについては、これらは最も一般的な（読み取り、シンプルで便利な）品質メトリックであり、2つのデコードされた画像間の類似度を評価できます。
さて、何と比較しますか？ 誰が標準と見なされるべきですか？ 幸いなことに、すべてのコーデックが等しく間違っているわけではありません。
計算エラーについて話している-非整数計算を含むコーデックは、開始から開始まで異なる結果を与える可能性があります
したがって、たとえば、H.264 \ AVCは整数標準であり、何に関係なく、シーケンスのデコードと同じ結果を保証します。 これは素晴らしい！ シーケンスを参照デコーダーでデコードし（参照デコーダーがない場合は参照を割り当てる必要があります）、正しいと判断し（この場合、ストリーム全体を目で見る必要があります）、保存します。
展開されていないシーケンス全体を保存するのは高価です-スペースを取りすぎます。 したがって、CRC32などのチェックサムを計算できます
次の実行では、現在の結果を標準と単純に比較します。 偶然-すべては順調です。
標準が整数でない場合、手順はもう少し複雑です。参照デコーダを選択し、比較のためにPSNRメトリックを使用して、すべてがどれだけ良い（または悪い）かを評価します。 デコーダーが安定したら、上記の手順を繰り返します。
出力が少し異なることが判明した場合、デコーダーの何かが変更されたためです。 そしてそれは問題になる可能性があります:)
以上で、デコーダーが完成しました。
