YouTubeとNetflix、SafariとChromeで異なる動作をする理由
興味を持ったきっかけ
以前、こんな記事を見たことがあった。
「Mac基準でChromeで音楽を聴いたり、動画を見ると損をする。」
調べた当時はChromeにいくつかの制限があり、それによって音質の低下や解像度の制限があるというものだった。
ただし、正確には調べなかったし、まあそういうものかと思って流していた。
そんな中、先日同僚たちとの食事の席でこれに関連する話が出て...ちゃんと確認しなかったせいで恥をかいてしまった。
だから、ふと気になって、ちゃんと調べてみることにした。
MacのChromeではNetflix 4Kが再生できない？
驚くことに、そうだ。MacのChromeではNetflix 4Kが再生できない。
サブスクリプションプランに関係なく、正常に4Kが出力されない。
DRMとNetflix
Netflixは著作権保護のためにDRM（Digital Rights Management）技術を活用している。
Netflixは高画質コンテンツを保護するために非常に厳格なDRMシステムを運営している。
このシステムではハードウェアレベルのセキュリティが必要であり、そのためには特別なセキュリティチップやハードウェアベースのコンテンツ保護技術が必要だ。
ここで重要な違いが現れる。
SafariはAppleが直接開発したブラウザとしてmacOSと深く統合されており、システムレベルのハードウェアセキュリティ機能に直接アクセスできる。
一方、ChromeはGoogleが開発したクロスプラットフォームブラウザとして、このような深いシステム統合が難しい。
具体的に見ると、Netflixは4Kコンテンツを再生するためにHDCP（High-bandwidth Digital Content Protection）2.2というセキュリティプロトコルを要求する。
これは単にソフトウェアレベルで実装できるものではなく、グラフィックカード、ディスプレイ、そしてオペレーティングシステムがすべて協力しなければならないハードウェアベースのセキュリティシステムだ。
このため、Chromeでは一般的に最大1080pまでしかサポートされない。
ユーザーがプレミアムプランに加入し、4Kモニターを使用し、十分なインターネット速度を持っていても、ブラウザ自体の制限により4K再生がブロックされる。
でも...Windowsではちゃんと動くのでは？
Windows環境ではChromeでも特定の条件下で4K Netflix視聴が可能な場合がある。
これはMicrosoftとNetflixが協力してWindows 10以上で特別なDRMサポートを提供しているためだ。
しかしmacOSではこのような例外的サポートは提供されていない。
それでは、Macで Netflix 4Kを見るにはどうすればいいだろうか？
最も簡単にアクセスできる方法はSafariを使うことだ。
このような制限が存在する理由は、結局コンテンツ保護のためだ。
映画スタジオとコンテンツ制作会社は自分たちの高画質コンテンツが違法コピーされることを非常に懸念しており、したがって最も安全なプラットフォームでのみ最高画質を許可するポリシーを要求する。
Appleのエコシステムはハードウェアからソフトウェアまですべてをコントロールできるため、このようなセキュリティ要件を満たしやすいが、オープンソースベースのChromeは相対的に制約が多い（Appleが制限しているものもある）。
つまり、まとめると技術的性能の違いではなく、セキュリティポリシーとプラットフォーム統合の違いである。
HDCP セキュリティプロトコルとは？
YouTubeについて調べる前に、HDCPについてもう少し深く見てみよう。
HDCPとは何か、なぜ登場したのか？
HDCP（High-bandwidth Digital Content Protection）はデジタルコンテンツを保護するためのセキュリティプロトコルだ。
より理解しやすくするために、デジタルコンテンツの根本的な問題をまず想像してみよう。
例えば、映画制作会社が数百億ウォンをかけて作ったブロックバスター映画があるとしよう。
この映画をNetflixや他のストリーミングサービスを通じて提供する時、制作会社が最も心配することは何だろうか？
まさに誰かがその高画質映像をそのままコピーして違法に配布することだ。特に4Kや8Kのような超高画質コンテンツはより厳格な保護が必要だ。
過去のアナログ時代にはコピーするたびに画質が落ちたため、自然な保護メカニズムがあった。（いわゆるデジタル風化とも言う。）
しかしデジタル時代にはコピーしても原本と同じ品質を維持できるため、このような自然な保護膜がなくなった。
この問題を解決するために人為的なセキュリティシステムが必要になったのだ。
HDCPの動作方式
HDCPが動作する方式を段階的に見てみよう。
このプロトコルはIntelで開発され、デジタルコンテンツが転送されるすべての経路で暗号化された状態を維持するように設計されている。
まるで貴重な宝石を運ぶ時、出発地から目的地まですべての区間でセキュリティ要員が見守っているような概念だ。
具体的な動作過程を理解するために、Netflixで4K映画を見る状況を例にしてみよう。
まずNetflixサーバーから暗号化された映像データがインターネットを通じてコンピュータに転送される。
この時、ブラウザやアプリでこのデータを解読した後、グラフィックカードに転送する。
グラフィックカードはこの映像を処理してモニターに送るが、まさにこのグラフィックカードからモニターへ行く区間がHDCPの核心保護領域だ。
ここで重要な概念が出てくる。HDCPは単にソフトウェア的な暗号化ではなく、ハードウェアレベルで実装されるセキュリティシステムだ。
グラフィックカードとモニターが互いに「ハンドシェイク」という過程を経て、相手が正当なHDCPサポートデバイスかどうかを確認する。
これは二人が互いに身分証を確認し、パスワードをやり取りして信頼を構築する過程と似ている。
HDCPが正しく動作するためには、全体の接続チェーンのすべての構成要素がこれをサポートする必要がある。
グラフィックカード、ケーブル、モニターだけでなく、オペレーティングシステム、ブラウザ、さらにはドライバまですべてがHDCPをサポートしなければならない。
この中の一つでもサポートしなければ、全体システムがセキュリティ上脆弱と判断されて高画質再生がブロックされる。
HDCP 2.2の特徴
HDCPは基本的に公開鍵暗号化方式を採用している。
公開鍵暗号化システムの核心アイデアをまず考えてみよう。
従来の暗号化では暗号を作る鍵と解く鍵が同じだった（対称鍵方式）。
しかし公開鍵暗号化では二つの異なる鍵がペアを成す。
一つは公開鍵で誰でも知ることができ、もう一つは秘密鍵で所有者だけが知ることができる。
これは郵便ポストに例えることができる。郵便ポストの位置は公開されているので誰でも手紙を入れることができるが、鍵は所有者だけが持っているので手紙を取り出すことができるのと同じだ。
HDCP 2.2はこのような公開鍵暗号化の概念を基にしているが、デジタルコンテンツ保護という特殊な目的に合わせて設計されたシステムだ。4Kのような大容量、高画質をサポートするためのセキュリティプロトコルと見ればよい。
このシステムの最も重要な特徴はリアルタイムで動作しなければならない点だ。
映画を見ている間、毎瞬間絶え間なく暗号化と復号化が行われなければならないので、速度と効率性が非常に重要だ。
HDCP 2.2の初期化過程を段階別に見てみよう。
1. 認証過程
コンピュータをモニターに接続した時に何が起こるか想像してみよう。
最初に起こることは「認証」過程だ。
これは二人が初めて会った時に互いの身元を確認する過程と似ている。
グラフィックカードがモニターに「こんにちは、私はHDCP 2.2をサポートする正当な送信デバイスです」と挨拶をする。
この時グラフィックカードは自分のデジタル証明書を提示するが、この証明書はDigital Content Protection LLCという機関が発行した証明書だ。
モニターはこの証明書を検証し、有効であれば自分の証明書もグラフィックカードに提示する。
つまり、最初にお互いの証明書を確認する過程を経るのだ。
これらの証明書は単純な身分証ではなく、それぞれ固有の暗号化キーを含んでいる。
各HDCPサポートデバイスは製造過程で固有のキーセットを付与されるが、これは指紋のように世界で唯一の識別子の役割を果たす。
このような方式でシステムは正規品デバイスと違法コピー品を区別できるようになる。
2. キー交換過程
認証が完了すると次の段階である「キー交換」過程が始まる。
これは非常に精巧な数学的アルゴリズムを使用するが、ディフィー・ヘルマン鍵交換という方法に基づいている。
この過程を日常的な例で見てみよう。
二人が公開された場所で秘密のパスワードを作らなければならないと想像してみよう。
周りに盗聴する人々がいるが、彼らが聞いても秘密のパスワードを知ることができてはいけない。
ディフィー・ヘルマン鍵交換はまさにこのような状況で使用できる非常に賢い方法だ。
グラフィックカードとモニターはそれぞれ秘密の数字を一つずつ持っている。
これらの数字は絶対に相手に直接教えない。
代わりにこれらの秘密の数字を特別な数学的公式に入れて変換された結果だけを互いに交換する。
驚くことに、このように変換された数字をやり取りするだけで、両側とも同じ共通の秘密鍵を計算することができる。
途中で盗聴する人は変換された数字だけを見ることができるだけで、実際の秘密鍵を知ることはできない。
では実際のコンテンツ保護がどのように行われるか見てみよう。
キー交換が完了すると、グラフィックカードとモニターは共通の暗号化キーを持つことになる。
このキーは非常に短い時間だけ有効であり、定期的に新しいキーに交換される。これは銀行のワンタイムパスワード（OTP）と同じ概念だ。
実際の映像データが転送される時はAES（Advanced Encryption Standard）という対称暗号化アルゴリズムを使用する。
これは非常に高速に大容量データを暗号化できる方法だ。
4K映像は毎秒膨大な量のデータを転送しなければならないので、このような高速暗号化が必須だ。
3. リンク検証過程
HDCP 2.2の特別な点の一つは「リンク検証」システムだ。
これは接続が維持されている間、継続してセキュリティ状態をチェックするメカニズムだ。
まるで警備員が定期的に巡回するように、システムは数秒に一度ずつ接続状態を確認する。
もし途中で誰かが信号を傍受しようとしたり、承認されていないデバイスが接続されると即座に検知されて映像転送が中断される。
このリンク検証過程では「チャレンジ・レスポンス」方式を使用する。
グラフィックカードがモニターにランダムに生成された質問を送ると、モニターは自分だけが知ることができる正しい答えを計算して返す。
この過程が失敗するとシステムは即座に緊急モードに切り替わり、低画質映像だけを転送するか、転送自体を中断する。
HDCP 2.2の核心的な改善点
HDCP 2.2が以前のバージョンと区別される核心的な改善点を理解してみよう。
最も重要な変化は暗号化強度の増加だ。
HDCP 1.4では56ビットキーを使用していたが、HDCP 2.2では128ビットAES暗号化を使用する。
これはセキュリティ強度を幾何級数的に増加させる効果をもたらす。
56ビットキーをブルートフォース攻撃で破るのにかかる時間が数日だとすれば、128ビットキーは宇宙の年齢よりも長くかかるほど強力だ。
またHDCP 2.2では「リピーター」処理方式が改善された。
リピーターとは信号を中継するデバイスを意味するが、例えばAVレシーバーやHDMI分配器のようなデバイスがこれに該当する。
以前のバージョンではこのような中継デバイスがセキュリティチェーンの弱いリンクになる可能性があったが、HDCP 2.2では各リピーターも個別に認証を受けなければならず、全体の接続チェーンのセキュリティ性を損なわないように設計された。（つまり、ハードウェア認証が必要なため、この地点でNetflix視聴時にHDCP 2.2対応ケーブルが要求されることもある。）
HDCP 2.2の実際の実装とハードウェア的考慮事項
実際の実装過程で考慮すべきハードウェア的要素も見てみよう。
HDCP 2.2は単にソフトウェアだけで実装することはできない。
グラフィックカードのチップセットレベルでサポートされなければならず、これは暗号化演算をハードウェアで加速化するためだ。
ソフトウェアだけでこのような複雑な暗号化をリアルタイムで処理しようとするとCPUに過度な負担がかかり、システム性能が大きく低下する可能性がある。
モニター側でも同様に専用チップが必要だ。
このチップは受け取った暗号化された信号をリアルタイムで復号化して画面に表示しなければならない。
4K 60fps映像の場合、毎秒約12ギガビットのデータを処理しなければならないので、これは非常に高性能のハードウェアを要求する。
ケーブルの役割も考える必要がある。HDCP 2.2ではケーブル自体がセキュリティシステムの一部になる。高品質HDMIケーブルには認証チップが内蔵されており、システムが正規品ケーブルかどうか確認できる。
これは誰かが特殊製作されたケーブルを使用して信号を傍受することを防止するためだ。
さらに、HDCP 2.2では「地理的制限」機能も含まれている。
これはコンテンツが特定の地域でのみ再生されるように制限する機能で、各デバイスは自分の地域コードを持っており、該当地域でのみ高画質コンテンツを再生できる。
HDCP 2.2の改善されたエラー処理メカニズムと現実的な問題の理解
システムのエラー処理メカニズムも非常に精巧に実装されている。
もし暗号化過程でエラーが発生すると、システムは即座に「グレースフル・デグラデーション」モードに切り替わる。
これは完全に再生を中断する代わりに、より低い画質で再生を続ける方式だ。
例えば、4K再生に問題が生じると自動的に1080pに切り替わり、それもダメなら720pに下がる。
最後にHDCP 2.2の限界と現実的な問題点も理解する必要がある。
理論的には完璧なセキュリティシステムだが、実際には互換性の問題が頻繁に発生する。
特に異なるメーカーのデバイスを接続する時、微妙な実装の違いによりハンドシェイク過程が失敗する場合がある。
このような問題のために、時には正当なユーザーも購入したコンテンツを正しく見ることができない状況が発生することもある。
YouTubeもChromeで4Kが使えないのか？
実はこの部分が私が混乱していた部分だ。NetflixはHDCP 2.2を要求するため、Chromeで4Kができないということは理解した。
だから、私は当然YouTubeもそうだろうと思って、普段からChrome使っていて映像を見る時だけSafariを使っていた。
しかし、調べてみると実はそうではなかった。YouTubeはMac Chromeで4Kがちゃんと動く。
なぜそうなのか見てみよう。
YouTubeとNetflixの異なる哲学
Netflixが「セキュリティとコンテンツ保護」を最優先にするなら、YouTubeは「アクセシビリティと互換性」を最優先にする。
これは二つのプラットフォームのビジネスモデルの違いから来ている。
Netflixは購読料を受け取ってプレミアムコンテンツを提供する一方、YouTubeは広告収益をベースにしているので、できるだけ多くのユーザーが簡単にアクセスできなければならない。
このような哲学的違いは技術的実装でも明確に現れる。
YouTubeはHDCPのようなハードウェアベースのセキュリティシステムをほとんど使用しない。
代わりにWeb標準技術を最大限活用してどのブラウザでも似たような体験を提供しようと努力する。
YouTubeの映像ストリーミング方式
YouTubeの映像ストリーミング方式を段階別に見てみよう。
YouTubeは「アダプティブストリーミング」という技術を使用する。
これは水が自然に最も楽な道を探して流れるように、システムが現在の状況に最も適した画質を自動的に選択する方式だ。
具体的に説明すると、YouTubeにアップロードされた一つの映像は実際にはいくつかの異なる画質と圧縮方式に変換されて保存される。
例えば同じ映像が360p、720p、1080p、1440p、4Kなど様々な解像度で存在し、それぞれまたH.264、VP9、AV1など複数のコーデックでエンコードされる。
ユーザーが映像を再生する時、システムはネットワーク速度、デバイス性能、ブラウザサポート能力などを総合的に判断して最も適切なバージョンを選択して提供する。
「ブラウザ別コーデックサポートの違い」に注目しよう。
コーデックとは映像を圧縮して解凍する方式を意味するが、これはまるで異なる言語のようなものだ。
すべてのブラウザがすべての言語を理解できるわけではないので、YouTubeは各ブラウザが理解できる言語で映像を提供しなければならない。
SafariとChromeの異なるコーデック
MacのSafariはハードウェアアクセラレーションによるH.264デコードに非常に優れている。
これはAppleが自社シリコンにH.264専用デコーダを内蔵しているためだ。
したがってSafariではH.264でエンコードされた高画質映像を非常に効率的に再生できる。
バッテリー消費も少なく、発熱も低く、CPU使用量も最小化される。
一方、Chromeの状況は少し複雑だ。
ChromeはGoogleが開発したブラウザなので、Googleが開発したVP9コーデックを積極的にサポートする。
VP9はH.264より圧縮効率が良いので、同じ画質をより少ない帯域幅で転送できる。
しかしVP9デコードは主にソフトウェアで処理されるため、CPU使用量が高くなりバッテリー消費が増加する可能性がある。
最近ではAV1という次世代コーデックも登場した。
これはVP9よりも効率的な圧縮を提供するが、まだハードウェアサポートが制限的でソフトウェアデコードに依存しなければならない場合が多い。
したがって高画質AV1映像を再生する時はかなりのシステムリソースが必要な問題がある。
時々「SafariでYouTubeがよりスムーズに再生される」と感じる場合がある。
これは単に画質自体の問題ではなく、デコード効率性の違いだ。
Safariではハードウェアアクセラレーションのおかげで高いフレームレートを安定的に維持できるが、Chromeではソフトウェアデコードにより時々フレームドロップが発生することがある。
しかしここで一つ考慮すべき点がある。ChromeでVP9やAV1を使用する時は実際にはより良い画質を体験できることもある。
同じ帯域幅でより多くの情報を転送できるからだ。特にネットワークが制限的な環境ではChromeがより良い体験を提供できる。
YouTubeの画質選択アルゴリズム
YouTubeの画質選択アルゴリズムも見てみよう。
YouTubeは単に最高画質を提供することが目標ではない。
代わりに「知覚的画質」を最適化しようとする。
これはユーザーが実際に感じる画質を意味するが、理論的画質とは異なる場合がある。
例えば、ネットワークが不安定な状況で4K映像を再生しようとするとバッファリングが頻繁に発生して実際には悪い視聴体験を提供する可能性がある。
このような場合、YouTubeはむしろ1440pや1080pに画質を下げて途切れのない再生を保証することを選択する。
これは「完璧な画質の数秒」よりは「適度な画質の連続的な再生」がより良い体験を提供するという判断に基づいている。（一時は、これによって4G使用時に勝手に360pに変える場合もあった。）
ブラウザ別ハードウェアアクセラレーションの違い
ブラウザ別ハードウェアアクセラレーションサポートの違いもついでに見てみよう。
ハードウェアアクセラレーションとはCPUの代わりにグラフィックカードや専用チップを使用して映像を処理する技術だ。
これは手で計算する代わりに計算機を使うのと同じ効果を与える。
SafariはmacOSと深く統合されているのでAppleシリコンのすべてのハードウェアアクセラレーション機能を活用できる。
M1、M2、M3チップにはProRes、H.264、HEVCなど様々なコーデック用の専用エンジンが内蔵されており、Safariはこれらのエンジンを直接活用できる。
Chromeもハードウェアアクセラレーションをサポートするが、汎用的なアプローチ方式を使用しなければならない。
様々なオペレーティングシステムとハードウェアで動作しなければならないので、特定プラットフォームの固有の機能を完全に活用するのは難しい。
これはまるで複数の国で使用される製品が各国の特殊な環境を完全に活用するのが難しいのと同じだ。
YouTubeでコーデックを確認する
YouTubeの品質設定メニューを詳しく見ると、より興味深い事実を発見できる。
設定で「詳細」を選択すると、単に解像度だけでなくコーデック情報も確認できる。
例えば「1080p60（VP9）」と表示されると、1080p解像度に60fpsでありVP9コーデックを使用するという意味だ。
同じ解像度でも使用するコーデックによって実際のデータ量と画質が異なる。
H.264でエンコードされた1080pとVP9でエンコードされた1080pを比較すると、一般的にVP9がより少ないビットレートで似たかより良い画質を提供する。
しかしデコードに必要な演算量はVP9がより多い。
まとめ
NetflixはChromeで4Kサポートができず、YouTubeはできる。
この二つの違いは、YouTubeとNetflixの経営哲学と技術的アプローチ方式の違いから来ている。
最初は何も考えずにまあそういうものか、と流していたが、このように詳しく見てみると本当に興味深い。
関連して調べてみると本当に様々な要素が存在するので、この記事で扱えなかった部分も多い。
現在調べるべき知識が多い関係で、簡単に好奇心を満たす程度だけ見てみた。
それにもかかわらず、この記事を通じて簡単にでもHDCP 2.2の基本概念とYouTubeとNetflixの違いを理解するのに役立てば幸いだ。