ほとんどの人は、色彩理論の基本を知っています。いくつかの原色の明るさを組み合わせることで、人が見えるあらゆる色を再現できます。多くの人は、個々の色が単に電磁スペクトルの波長であることを知っています。しかし、色を正確に記録して再現しようとすると、状況がどれほど困難になるかを理解していない人は少なくありません。
RGB 3 成分値を特定の波長の光に変換するシステムは数多くあります。この変換を標準化して、すべてのソフトウェア、すべてのビデオ デコーダー、ビデオ カード、およびモニター (異なる年代の異なるメーカーによって製造されたものでも) が同じ入力データから同じ結果を生成できるようにする必要があります。この課題に対応するために、色の標準が開発されました。ただし、ディスプレイやその他のテクノロジーは時間とともに進化してきました。テレビはデジタル化され、圧縮が始まり、CRT を捨てて LCD と OLED を選びました。新しい機器は、より高い輝度でより多くの色を表示することができましたが、受信した信号は依然として古いディスプレイの機能に適合していました。
この問題の解決策は、新しい「色空間」を作成することでした。新しい HD コンテンツを新しい色空間で作成し、新しい HD ディスプレイで表示できます。また、古い色空間が表示される前に新しい色空間に変換されても、古いコンテンツとの互換性は失われません。
これは実用的なソリューションですが、ビデオ作成プロセスを複雑にします。キャプチャ、記録、編集、エンコード、デコード、合成、および表示のプロセスのすべてのステップで、使用している色空間を考慮する必要があります。また、プロセスの少なくとも 1 つの段階で古い機器が使用されている場合、または色空間が考慮されていないソフトウェアのバグがある場合、結果は正しくない画像になる可能性があります。ビデオは引き続き視聴できますが、色が暗すぎたり、薄かったりする場合があります。
現在、最も一般的な 2 つのカラー スペースは、SD コンテンツの標準となっている BT.601 (smpte170m とも呼ばれます。この記事では両方の名前を使用します) と、SD コンテンツの標準となっている BT.709 です。 HDコンテンツ。 HDR および UHD コンテンツのおかげで、より人気が高まっている BT.2020 もあります。ここで、HD/SD 分割に少し欠陥があることは注目に値します。技術的な制限はありません。これは単なる伝統的なアプローチです。 HD コンテンツは BT.601 で、SD コンテンツは BT.709 でエンコードできます。 1080p のビデオ ファイルを 480p に縮小しても、色空間は自動的に変更されません。色空間の変更は、プロセスの一部として実行される追加の手順です。
プロセスが正しく実行されないとどうなりますか? 実験をしてみましょう。
ffmpeg プログラムは、私たちの時代の真の奇跡です。これは非常に人気のあるデジタル ビデオ ツールであり、業界全体がその開発者に多くを負っています。私の実験では、このツールを使用してビデオ ファイルを作成および変更します。
まず、ffmpeg を使用して簡単なテスト ファイルを作成します。
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -color_range pc -y 601.mp4
このコマンドの簡単な説明:
ffmpeg
—
-f rawvideo
— ffmpeg, , .
-s 320x240
— . , . .
-pix_fmt yuv420p
— . Yuv420p — . , yuv(0,0,0) . RGB, , .
-t 1
— 1
-i /dev/zero
— . /dev/zero — , mac. , .
-an
— , .
-vcodec libx264
— libx264.
-profile:v baseline
— h.264. h.264, .
-preset:v placebo
— libx264, . , . , .
-color_range pc
— 0 255. 16-235. - , . ,pc
,tv
.
-crf 18
- 一定レート係数オプションは、高品質のビデオ ファイルを作成し、品質を確保するために必要なだけ多くのビットを使用するように libx264 に指示します18
。数値が低いほど、品質が高くなります。18は非常に高品質です。
-y
- 存在する場合、ファイルを上書きする権限を ffmpeg に与えます。
601.mp4
- 結果のファイルの名前。
このコマンドは、開いて再生できる 1 秒の長さの 601.mp4 ファイルを作成します。このコマンドを実行した後、次のコマンドを実行して出力を調べることで、ffmpeg がピクセル値を歪めていないことを確認できます。
ffmpeg -i 601.mp4 -f rawvideo - | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000
00000010: 0000 0000 0000 0000 0000 0000 0000 0000
00000020: 0000 0000 0000 0000 0000 0000 0000 0000
00000030: 0000 0000 0000 0000 0000 0000 0000 0000
00000040: 0000 0000 0000 0000 0000 0000 0000 0000
00000050: 0000 0000 0000 0000 0000 0000 0000 0000
...
...
この 16 進数のデータは、デコード後のすべてのピクセル値がゼロであることを示しています。
Safari でビデオをレンダリングすると、次のようなスクリーンショットが表示されます。
問題が発生します。この色空間は何ですか?ファイルに 601.mp4 という名前を付けましたが、コマンドのどこにも色空間を指定していません。Safari はどのようにしてレンダリングする緑の色合いを知ったのでしょうか?ブラウザは yuv (0,0,0) が rgb (0,135,0) と等しくなければならないことをどのようにして知るのでしょうか?明らかに、これらの値を計算するためのアルゴリズムがあります。実際、これは単純な行列乗算です。 (注: yuv420p を含む一部のピクセル形式では、変換の前処理と後処理の手順が必要ですが、このデモではそのような微妙な点は省略します。)各色空間には独自のマトリックスがあります。ビデオをエンコードするときにカラー スペース マトリックスを指定しなかったため、Safari は単に仮定を立てます。すべての行列を反復処理し、すべての RGB 値を逆行列で乗算して、それらが対応するものを確認できます。しかし、より視覚的なアプローチを試して、Safari が何をしているかを理解できるかどうか見てみましょう。
これを行うには、メタデータをファイルに挿入して、Safari が使用されている色空間を認識し、推測する必要がないようにします。
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -color_range pc -y 601vui.mp4
ffmpeg コマンドはほぼ同じままですが、以下を追加しました。
-color_trc smpte170m
-colorspace smpte170m
-color_primaries smpte170m
これは、ファイルがエンコードされる色空間のメタデータです。これには別の記事が必要になるため、これらのオプションの違いについては説明しません。今のところ、必要な色空間をすべて設定するだけです。smpte170mはBT.601と同じです。
色空間を指定してもファイルのエンコード方法には影響せず、ピクセル値は引き続き yuv (0,0,0) としてエンコードされます。これを確認するために、新しいファイルでコマンドを実行できます
ffmpeg -i zero.mp4 -f rawvideo - | xxd
。色空間フラグは無視されませんが、ビデオ ストリームのヘッダーの「ビデオ ユーザビリティ情報」(VUI) セクション内の数ビットに単純に書き込まれます。デコーダーは VUI を検索し、それを使用して目的のマトリックスをロードします。
結果は次のとおりです。
VUI の有無にかかわらず、ビデオは同じ色でレンダリングされます。BT.709 ファイルを試してみましょう。
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -y 709.mp4
新しいオプション:
-i 601vui.mp4
— 601vui.mp4
-vf "colorspace=all=BT.709"
— ffmpeg, . yuv rgb, . «all» — color_primaries, colorspace color_trc.
ここでは、601vui.mp4 ビデオを取得し、カラー スペース フィルターを使用して BT.709 に変換します。カラー スペース フィルターは、入力データのカラー スペースを vui ファイル 601vui.mp4 から読み取ることができるため、出力で受け取りたいカラー スペースを指定するだけです。
このファイル
ffmpeg -i 709.mp4 -f rawvideo - | xxd
のコマンドを実行することにより、色空間の変換後にピクセル値 yuv (93,67,68) を取得します 。ただし、ファイルをレンダリングするとき は、同じように見える。各ピクセルのエンコードに引き続き 24 ビットを使用し、BT.709 の色の範囲がわずかに広いため、最終結果が同一ではない可能性があることに注意してください。その結果、BT.709 の一部の色は BT.601 に正確にマッピングされず、その逆も同様です。
結果を見ると、明らかに何かが間違っていることがわかります。新しいファイルは、入力ファイルよりもはるかに明るい 0.157.0 の RGB 値でレンダリングされます。
ffprobe アプリケーションを使用してファイルのプロパティを詳しく見てみましょう。
ffprobe 601vui.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 320x240, 9 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
そして
ffprobe 709.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc), 320x240, 5 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
ここでの情報のほとんどは重要ではありませんが、601vui.mp4 が「yuvj420p (pc、smpte170m)」ピクセル形式であることに気付くでしょう。これは、ファイルに正しい VUI があることを理解する方法です。ただし、709.mp4 には「yuvj420p (pc)」しか含まれていません。出力ファイルに色空間メタデータが含まれていないようです。カラー スペース フィルターは元のカラー スペースを読み取ることができ、新しいスペースを明示的に指定しましたが、ffmpeg は正しい vui を最終ファイルに書き込みませんでした。
これはまずい... Ffmpeg は最も人気のあるビデオ変換ツールです。そして、色情報が欠落しています。これがおそらく、多くのビデオに色空間メタデータが含まれていないため、多くのビデオが不一致の色でレンダリングされる理由です。 ffmpeg を弁護するには、これは厄介な問題です。エンコーダーを初期化するには、事前に色空間を知っておく必要があります。また、ビデオフィルターで色空間を変更することもできます。これはコードで解決するのが難しい問題ですが、この動作が標準であることは残念です。
色空間メタデータを手動で追加することで回避できます。
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -colorspace bt709 -color_primaries bt709 -color_trc bt709 -color_range pc -y 709vui.mp4
その結果、709vui.mp4 のカラー値は rgb (0.132.0) になります。緑チャンネルの明るさは 601vui.mp4 よりやや劣りますが、色空間変換がロスを伴い、結果的に私には合っているので成功と呼べます。
このことから、ファイルで色空間が指定されていない場合、Safari は BT.601 であると見なすことができます。そして、Safari 側では、これは非常に適切な想定です。ただし、前述のとおり、BT.601 は SD ビデオ規格であり、BT.709 は HD ビデオ規格です。 VUI の有無にかかわらず HD ビデオをチェックして、Safari がそれらをどのようにレンダリングするかを見てみましょう。同じ ffmpeg コマンドを使用して、解像度を 1920x1080 に変更しただけです。
SD と HD の両方で、同じ色がレンダリングされます。Safari は、色空間を想定するときに解像度を考慮しません。Apple は長い間メディアと出版の分野に携わってきたので、私はこの会社の製品がまともな結果をもたらすと期待していました。しかし、Safari ではすべてが非常に賢くても、他のブラウザーでは状況がどうなっているのかは興味深いです。
クロム：
Chrome はビデオ 601 を Safari より少し暗くレンダリングしますが、709 は同じように見えます。違いは浮動小数点計算の速度の最適化によるものだと思いますが、これは私たちのテストには関係ありません。
経験上、設定でハードウェア アクセラレーションが無効になっていると、Chrome のレンダリングが異なることがわかっています。
この結果を調べると、601 の値は前の値と非常に類似してレンダリングされますが、709 ファイルは VUI を持たないかのようにレンダリングされていることがわかります。このことから、ハードウェア アクセラレーションが無効になっている Chrome は、単に VUI を無視し、すべてのファイルを 601 形式であるかのようにレンダリングすると結論付けることができます。これは、すべての 709 ファイルが正しく再生されないことを意味します。
最後に、Firefox を調べてみましょう。
ここでわかることはたくさんあります。 709.mp4 と 709vui.mp4 は同じように見えるので、VUI が利用できない場合、Firefox は BT.709 形式を想定すると結論付けることができます。 601vui.mp4 を正しくレンダリングするということは、BT.601 コンテンツの場合、VUI セクションが考慮されることを意味します。ただし、VUI のない BT.601 ファイルを 709 としてレンダリングすると、非常に暗くなります。明らかに、必要なすべての情報がなければ画像を正しくレンダリングすることはできませんが、Firefox が選択した方法は、Safari および Chrome ブラウザが選択した方法よりも色を歪めます。
ご覧のとおり、ビデオの演色状況はまだ西部開拓時代です。残念ながら、問題の一部しかカバーしていません。私たちはまだ Windows を研究していません。そうしよう。
マイクロソフトエッジ：
Edge (少なくとも私のコンピューターでは) は VUI を無視し、すべてを 601 としてレンダリングしているように見えます。Chrome
(ハードウェア アクセラレーションが有効になっている場合):
状況は Mac と大差ありません。VUI が存在する場合は正しく処理されますが、存在しない場合は、SD コンテンツの場合は BT.601、HD コンテンツの場合は BT.709 と見なされます。これは私がこれを見た唯一のブラウザですが、特定のロジックがあります。レンダリングは Mac とは異なる方法で行われるため、問題は OS にあるか、おそらくビデオ カード ドライバーのレベルにあるものと思われますが、この選択は Chrome 開発チームによって行われたものではありません。
Firefox は、Mac と同じように動作します。
Linux、iOS、Android、Roku、Fire TV、スマート TV、ゲーム コンソールなどの場合、これは読者の演習として残します。
私たちは何を学びましたか?最も重要： 常にビデオに色空間メタデータを含めます。 ffmpeg を使用していて、カラー フラグを設定していない場合、正しく動作していません。第二に、ffmpeg は素晴らしいプログラムですが、その人気、使いやすさ、不適切に選択されたデフォルトが不利益をもたらしています。ソフトウェアがそれ自体で解決できるほど賢いと思ってはいけません。 Ffmpeg、Google、Mozilla、Microsoft (およびおそらく Nvidia と AMD) のプロジェクト マネージャーは、1 つの方法を見つけるために団結して協力する必要があります。ここには良い解決策がないことは理解していますが、悪いと予測可能なものは、悪いとランダムよりも優れています。個人的には、VUI セクションがない場合は常に BT.601 フォーマットを想定することをお勧めします。これにより、歪みが最小限に抑えられます。このFOMS規格に合わせて選択できます 、またはAOMでさえ、 これらの組織はかなりよく代表されています。
最後になりましたが、カラー情報のないビデオがあり、それを変換またはレンダリングする必要がある場合は、頑張ってください!
広告
VDSina は、日払いで安価なサーバーを提供します 。各サーバーのインターネット チャネルは 500 メガビットであり、DDoS 攻撃に対する保護は料金に含まれており、Windows、Linux、または一般的な OS をイメージからインストールする機能、および非常に便利な独自のサーバー コントロール パネル . 試す時が来ました;) Telegram のチャットに
参加して ください。
