こんにちは、Habr！
ビデオを圧縮/再生するときのテレビ/ PCの範囲の不一致の問題を調査した最近の研究についてお話したいと思います。 この問題はかなりささいなものですが、同時に非常に大規模であるため、以前は色を変えることで圧縮コーデックを非難することがよくありました。
例
あなたが休暇から戻ったばかりで、あなたがNにいて、イベントMであなたの間違いなく素晴らしいカメラFで素晴らしい写真を撮ったと想像してください。 。 それは言われています-完了、お気に入りのビデオエディタをインストールし、コントラスト、色域を調整し、可能な限り美しくなるようにすべてを行います。 これでプロジェクトの準備が整いました。焼きたてのビデオファイルができました。 確認して実行してください...コントラストと彩度が低下したかのように、何かが間違っています。 別のコーデックがある場合はどうなりますか？ 別のコーデックを試してみました-同じことです。 さて、主なことは、DVDのすべてが正常であることです。 ビデオクリップをDVDに記録しますが、実際に色が所定の位置に落ちました。
背景
これはすべて、アナログテレビの時代から消えており、キネスコープのような驚くべきものがありました。 最初の受像管は無色でした。つまり、明るさの陰影が表示されました。特定のポイントに電子銃を送るストリームが強ければ強いほど、このポイントは明るくなり、すべてが単純になります。 同じ方法で、彼らはこのテレビに信号を送信しました。つまり、彼らは写真の輝度成分を放送します。
しかし、白黒写真は人々を本当に満足させるものではありませんでしたが、色覚を持っていたため、すぐにカラーテレビが登場しました。 カラーテレビではキネスコープも使用されていましたが、色の伝達には、現代のモニターのように赤緑青ピクセルが使用されていました。 白黒テレビとの下位互換性が維持されるように信号を送信する方法について質問がありましたか？ もちろん、輝度に加えて3つのカラーチャネルに加えて、隣接する周波数でブロードキャストすることも可能ですが、第一に、チャネルに割り当てられた周波数範囲が非常に狭く、第二に、結果が得られるため、より困難です4つのカラーチャンネル。 そこで、数学者とエンジニアは、輝度チャネルに加えて、2つの色「クロマティック」カラーを送信するというアイデアを思い付きました。青と赤は、対応するカラーチャネルとの輝度の差として取得され、RGBから色空間を取得します（Y、Cb = BY、Cr = RY）。 これら3つのチャネルから色範囲全体を計算できます。 さらに、人の視覚は色にあまり敏感ではないため、ほとんどの場合、画像の品質を損なうことなく、色チャンネルの解像度を半分にすることができます。 つまり、PALフレームの輝度チャネルの解像度は720x576であり、その色は360x576の解像度（いわゆる4：2：2色サブサンプリング）で送信されました。 しかし、明るさ（Y）と色彩チャンネル（Cb、Cr）をRGBに、またはその逆にどのように正確に変換できますか？
そのため、1982年にYCbCr <=> RGB変換標準が制定されました。これはCCIR 601（1992年からBT.601）と呼ばれています。 多数の人間の色知覚実験の結果に基づいて、明るさは、係数77 / 256、150 / 256、および29/256をそれぞれ持つ赤、緑、および青の合計として定義されます。
RGB => YCbCrからの変換の結果、明るさ（16-235）と色（16-240）の範囲が縮小されます。 標準で示されているように、値0と255は同期に使用でき、値1〜15と236〜254は正しくないと見なされ、白黒で表示されます。 後に、これらの狭い範囲はデジタルビデオに転送され、その結果、狭い範囲がビデオの標準になりました。 高解像度のビデオ用に、色変換のための別の標準BT.709を開発しました。これは、係数のみがBT.601と異なります。
ビデオをどのように正しく圧縮して再生する必要がありますか？ ビデオファイルが明るいクロマティックスキームの1つで圧縮されている場合（これがコーデックの大部分であり、RGBは非圧縮ビデオでのみ使用されます）、狭いテレビ範囲の輝度（16-235）でエンコードする必要があります。 モニターは引き続きRGB出力を使用するため、デコーダーはYCbCrを0〜255のフルレンジでRGBに変換する必要があります。 これはほぼ完璧なスキームですが、なぜほとんどですか？ 理由は次のとおりです。
- 人工的な範囲の圧縮-256階調のグレーから220（8ビットから、実際には7ビットより少し多く）が得られ、互換性を除いて、範囲を圧縮する必要がある客観的な理由はありません。 写真の品質を故意に低下させます。
- ビデオの各ピクセルは、さまざまなフィルター（デコーダー、プレーヤープログラム、レンダリング、ビデオドライバー）を介してファイルからモニター上のポイントに渡されます。 途中で、この長いチェーンで多くの変換を行うことができ、その結果、範囲が常に狭くなるため品質が低下します。
- 一部のフィルターは範囲の縮小を無視し、一部のビデオは全範囲で誤ってエンコードされるため、他のフィルターはそれを修正しようとするため、さらに混乱が生じます。
実験
私は、標準の狭い範囲（16-235）を再生するときと、完全な（0-255）範囲でエンコードされたビデオに対して、異なるプレーヤー/ドライバーがどのように動作するかをテストする実験を行うことにしました。 これを行うために、0〜255のグレーグラデーションのPNG画像を撮影し、AviSynthを介して最も人気のある最新のエンコーダx264に渡しました。 私は3つのavsスクリプトを使用しました。最初のスクリプトは画像を読み取り、それを「そのまま」、RGB形式で（非圧縮ビデオとして）提供しました。
rgb.avs
ImageReader（ "palette.png"、end = 24）
2番目と3番目のファイルでは、BT.601とBT.709の2つの標準に従って、全範囲でYV12色空間に変換しました。
pc601.avs
ImageReader（ "palette.png"、end = 24） ConvertToYV12（マトリックス= "PC.601"）
pc709.avs
ImageReader（ "palette.png"、end = 24） ConvertToYV12（マトリックス= "PC.709"）
次に、いくつかの方法で圧縮しました。 実際、x264には、結果に影響を与える可能性のある2つのパラメーターがあります：--input-range [TV、PC]および--range [TV、PC]。 古いx264バージョンでは、-fullrangeオプションがこれを担当していました。
colortest.cmd
x264.exe --preset veryslow --crf 1 --output rgb.mp4 rgb.avs x264.exe --preset veryslow --crf 1 --input-range TV --range TV --output rgb-tv-tv.mp4 rgb.avs x264.exe --preset veryslow --crf 1 --input-range TV --range PC --output rgb-tv-pc.mp4 rgb.avs x264.exe --preset veryslow --crf 1 --input-range PC --range TV --output rgb-pc-tv.mp4 rgb.avs x264.exe --preset veryslow --crf 1 --input-range PC --range PC --output rgb-pc-pc.mp4 rgb.avs x264.exe --preset veryslow --crf 1 --output pc601.mp4 pc601.avs x264.exe --preset veryslow --crf 1 --input-range TV --range TV --output pc601-tv-tv.mp4 pc601.avs x264.exe --preset veryslow --crf 1 --input-range TV --range PC --output pc601-tv-pc.mp4 pc601.avs x264.exe --preset veryslow --crf 1 --input-range PC --range TV --output pc601-pc-tv.mp4 pc601.avs x264.exe --preset veryslow --crf 1 --input-range PC --range PC --output pc601-pc-pc.mp4 pc601.avs x264.exe --preset veryslow --crf 1 --output pc709.mp4 pc601.avs x264.exe --preset veryslow --crf 1 --input-range TV --range TV --output pc709-tv-tv.mp4 pc709.avs x264.exe --preset veryslow --crf 1 --input-range TV --range PC --output pc709-tv-pc.mp4 pc709.avs x264.exe --preset veryslow --crf 1 --input-range PC --range TV --output pc709-pc-tv.mp4 pc709.avs x264.exe --preset veryslow --crf 1 --input-range PC --range PC --output pc709-pc-pc.mp4 pc709.avs
その結果、15個のファイルを受け取りました。 AviSynthでヒストグラムをチェックした後、-rangeおよび--input-rangeパラメーターを指定せずにビデオをそのまま圧縮します。それ以外の場合、範囲はx264を使用して変換されます。 つまり、pc601.mp4およびpc709.mp4ファイルのみが滑らかなヒストグラムを提供しますが、これらの標準は有彩色チャネルの係数のみが異なるため、グレースケールではそれらの間に違いはないため、2つのファイル（rgb.mp4およびpc601.mp4（それぞれ狭い範囲と完全な範囲）。
これらのファイルの再生を4台のコンピューターでテストしました。Windows7と、ffdswowおよびK-Lite Codec Packコーデックはどこにでもあります。 結果はタブレットにリストされます：
表の説明：
通常-正しい表示
in-誤った表示、範囲16〜235は0〜255にスケーリングされない
out-誤った表示、範囲0〜255が誤ってスケーリングされ、範囲がトリミングされます。
MPC-HCプレーヤーの結果のスクリーンショットは次のとおりです。
範囲設定がほとんどすべてのフィルターにあることに注意してください。 私の場合、この設定はffdshowビデオデコーダー、Lav、Haaliレンダリング、ビデオカードドライバーの設定にもあり、プレーヤーで範囲を強制的に変換することもできます（特別なシェーダーがあります）。 ただし、何らかの理由で、ffdshowビデオデコーダーの範囲を切り替えても結果に影響しませんでした。 ドライバーの設定が常に結果に影響するとは限りません。影響を受けた場所で、テーブルに入力しました（ビデオカードの設定行）。 さらに、DXVAおよびCUDAハードウェアアクセラレーションでは、テレビはもちろんのこと、16〜235の範囲のみが正しいと見なされます。
また、2つのビデオエディターをテストしました。
- VirtualDub-YV12 / YUV2からRGBへ、またはその逆への変換がない場合、範囲は接触しません。そうでない場合、プログラムで表示される場合、範囲の変換、フィルターはRGBで動作し、TV-> PCの変換を行います。
- AviDemux-範囲は変更されず（RGBソースでは機能しません）、フィルターはYUV2で機能します。プログラムで表示される場合、変換はTV-> PCです。
まとめ
この表は、完全に混乱していることを示しています。ビデオの表示方法は、使用するコーデック、プレーヤー、レンダリングタイプ、ドライバーなどの多くのパラメーターに依存します。 ここでの主なことは、問題が何であるかを理解し、可能であればそれを修正することです。
ビデオ圧縮の正しい（完全ではありませんが）範囲はTV（16-235）です。それ以外の場合、ほとんどの場合、ビデオは正しく表示されません（白黒の範囲をトリミングして）。 また、デジタルビデオの観点からは、変換なしで全範囲を保存および表示する方が論理的ですが、現在の段階では、ほとんどのデバイスで正しく表示されないような標準があります。
これに対処する方法は？ すぐに思い浮かびます-メタタグで使用される範囲を示すために、このメソッドは既に実装されています（fullrangeフラグが存在します）が、残念ながら、このフラグは非常に頻繁に無視されます。 したがって：
- 開発者-範囲変換が必要な場合、そのようなフラグの影響の実装に注意し、プレーヤー/コーデックでビデオを正しく表示する必要があります。
- ユーザーが色に問題がある場合は、設定を構成する（コーデック/プレーヤー/ドライバーで）か、別のプレーヤーを試してください。
- ビデオハンドラーは、このような問題の存在を認識し、正しく圧縮する必要があります（16〜235の範囲でエンコードするか、少なくともフルレンジフラグを指定します）。
実験でアーカイブをダウンロードする
参照資料
ウィキペディアYCbCr
ウィキペディアRec。 601
ウィキペディアRec。 709
ウィキペディア4：2：2
ウィキペディアのカラーサブサンプリング