YouTubeがTV(TVHTML5)クライアントを使うすべての動画にDRMを追加中
(github.com/yt-dlp)- 一部のYouTubeアカウントで YouTube on TV にログインすると、通常の動画でも TVHTML5 Innertube クライアントでは DRM 形式のみが返される実験または A/B テストが観測されている
- この現象は yt-dlpに限らず、同じアカウントで PS3、Web ブラウザー、Apple TV など公式 YouTube TV クライアントを試しても、動画形式が DRM のみで提供される
- yt-dlp は現在 YouTube 動画データをリクエストする際に YouTube on TV のように動作するため、この実験対象アカウントでは通常の動画も
This video is DRM protectedエラーとして扱われる - 再現ログでは、Firefox の Cookie と
youtube:player-client=tv設定でaqz-KE-bpKQ動画を取得した際に DRM 保護エラーが発生し、開発者向けオプションで再生不可形式を表示すると、音声・映像形式全般に DRM 表示が付くことが示されている - このイシューはクローズ済みで、ページには関連 PR として #14122 と #13539 が紐付けられているが、本文には具体的な修正方法や最終的な動作変更は含まれていない
一部アカウントで TV クライアント形式が DRM のみで提供される
- 一部の YouTube アカウントで、通常の動画が
tvまたは TVHTML5 Innertube クライアントでは DRM 形式しか持たない現象が報告されている - 問題は YouTube が一部アカウントに適用中の 実験または A/B テスト とみられ、すべてのユーザーに適用されているとは断定されていない
- 明確化の説明では、YouTube on TV にログインした一部アカウントでは、すべての YouTube 動画が DRM で保護されているように見える
- YouTube on TV は TV、ゲーム機などで使われる大画面向けインターフェースまたはアプリであり、TV やゲーム機のユーザーエージェントで
https://www.youtube.com/tvにアクセスできる
yt-dlp への影響
- yt-dlp は現在 YouTube 動画データをリクエストする際に YouTube on TV として要求する方式を含んでいるため、この実験の影響を受ける
- 当該アカウントと
tvクライアントの組み合わせでは、yt-dlp は通常の動画も DRM 保護動画と判定する - 再現コマンドは Firefox ブラウザーの Cookie を使い、
--extractor-arg youtube:player-client=tvで TV クライアントを強制する- 対象 URL は
https://www.youtube.com/watch?v=aqz-KE-bpKQ - ログの yt-dlp バージョンは
nightly@2025.03.07.232704 - 実行結果は
ERROR: [youtube] aqz-KE-bpKQ: This video is DRM protected
- 対象 URL は
公式 YouTube TV クライアントでも同じ結果
- 同じアカウントで複数の 公式 YouTube TV クライアント をテストした場合も、DRM 形式のみが提供される
- PS3
- Web ブラウザー
- Apple TV
- したがって、観測された現象は yt-dlp 固有の実装問題には限定されない
開発者向けオプションで確認した形式一覧
- コード修正が必要な方法で DRM 形式を見えるようにしたうえで
--allow-unオプションを使うと、再生不可形式の一覧が出力される - 出力された形式には音声および映像項目全般に DRM 表示が付く
- 音声専用
m4a形式:148,149,148-drc,149-drc - 映像専用
mp4とwebm形式: 144p から 2160p60 までを含む - 例として
558形式は3840x2160 60fps,vp9, 約1.27GiB,DRM, 2160p60, TV, webm_dashと表示される
- 音声専用
--allow-unは開発者デバッグ用オプションであり、出力ログには再生不可形式の一覧化またはダウンロードを要求したという警告が含まれる
1件のコメント
Hacker News の意見
この問題が実際に何を意味するのか説明が必要
主要な論点が、技術に詳しい一般読者にも理解しにくい概念にまたがっているため、結局は人々がキーワードだけをつかんで、生産的でない議論に流れる可能性が高い
具体的には innertube クライアント、
tvinnertube クライアント、TVHTML5、「DRM 形式」、その形式が「利用可能」であることの意味、そしてそれが tv innertube クライアントにだけ提供される場合になぜ重要なのかが気になるこれが重要なのは、yt-dlp が通常動作の中でそれらのクライアントになりすますためで、yt-dlp は DRM ロック付き動画の復号をサポートする予定がないため、この変更はすべての動画ダウンロードを壊す可能性がある
innertube は非公開 YouTube API の名前で、複数種類の YouTube クライアントソフトウェアが使うために作られた API。例となるライブラリは https://github.com/tombulled/innertube/ で、yt-dlp は別のクライアントコードを持っている
「tv」クライアントはクライアント種別の一つで、例は https://github.com/tombulled/innertube/blob/main/innertube/c... で見られる
TVHTML5 は TVLITE や TVANDROID などとは区別される特定のクライアントで、テレビごとに特定の TV クライアントと特定の TV API を使っているように見える
yt-dlp が動画を取得するときは、おおまかには innertube がサポートするクライアントの一つを装い、最上位の動画オブジェクトを受け取ったうえで、利用可能な形式一覧をパースする。形式とは「MP4、1080p、AAC オーディオ付き」や「Ogg、音声のみ」のようなもの。基本的に yt-dlp は最高品質の音声ストリームと最高品質の動画ストリームを取得して一つのファイルに結合するが、設定で変更できる
DRM 形式はおそらく Widevine で保護された形式であり https://en.wikipedia.org/wiki/Widevine、yt-dlp はその復号をサポートしないと表明している
「利用可能」とは、yt-dlp クライアントからダウンロードの選択肢として見えるという意味。すべての動画がすべてのクライアントにすべての形式を提供するわけではなく、4K でアップロードされていなかったり、4K デコードをサポートしないクライアントでは、4K の選択肢が見えないことがある
今回の場合は、この特定の内部クライアント種別では動画を取得できないという意味。yt-dlp がリクエストすると DRM ロック形式だけを受け取るため。TV クライアントは、有効な YouTube ログイントークンなしでも YouTube API から高画質動画を得る方法なので注目に値する。Issue の下のほうで報告者は、トークンを提供すれば「web」innertube クライアントが動作すると述べている
今の状況は結局、人々がこの状態に満足しているから生まれたもの
映画、音楽、書籍を所有しなくてもよいと考え、その意味を理解していない人が多い。理解している側は少数派
ストリーミング自体に反対しているわけではないが、すべての提供者は合理的な価格で合法的なデジタルコピーを所有する選択肢を用意すべき。ここで所有とは、DRM のない単純なメディアファイルを持ち、好きな場所で再生できるという意味
何かを所有するためにお金を払うことにはまったく問題はないが、それまではこうした企業に一銭も払わない
20 億人がストリーミングすると仮定すれば、2,000,000,000 × 1095 = 2,190,000,000,000g、つまり 219 万トンの不要な二酸化炭素になる
海賊版なら一度で済むので、より環境にやさしく、地球を救えるという見方もできる
yt-dlp で購読チャンネルをダウンロードして mp3 に変換し、ローカルネットワーク内でポッドキャストフィードを提供するスクリプトを作ったことで、YouTube アプリの使用時間はすでに大きく減った
これがいつか壊れたら余暇に外へ出ることになるかもしれないが、まだ動いているので春までは持ってほしい
yt-dlp 以外にどんなツールを使っているのか気になる。たとえば RSS フィードの生成とホスティングに何を使っているのか知りたい
本当にひどいニュース。
こういうことが起きるのはかなり明らかだったし、Googleのかなり高レベルな戦略の一部だという点もかなり明らかに見える。Googleは何年も前から、クライアントとサーバーの両側でこの部分すべてに大きく投資してきた。
私にはエンシット化のにおいがするが、それ以上に、ロックされ閉ざされた技術の時代へまさに入ろうとしているように思える。全体の流れを見ると、DRMのないYouTubeは時代錯誤に感じられるほどだ。
ほとんどの人は、自分にできることをひどく制限するデバイスを喜んで買うので、消費者からの実質的な反発も期待していない。これを本当に気にする人たちは、原則のためにデジタル世界から自ら分かれて欠乏を受け入れるか、最小公分母のユーザーたちと同じ箱の中へ強制的に押し込まれるか、という選択肢に直面することになりそうだ。
Google経営陣に悪意がないと仮定するなら、AIが最後の引き金だったのかもしれないとも思う。Geminiの堀を築くには、データ収集者がYouTube動画にアクセスできないようにする必要があり、それを保証する唯一の「本当の」方法はDRMをかけることだ。X/Twitter、Reddit、Stack Overflowなども同じような理由で対策を取った。いずれにせよやりたかったことだろうから、AIは理由というより口実かもしれないが、まったく意味のない要因ではないはずだ。
私たちは、自分の鍋に自ら燃料を入れているカエルのような状態だ。
以前は、DRMはユーザーを代表しないためブラウザと衝突すると考えられていた。DRMがどうしても必要なら、Silverlightのような外部プラグインでプラットフォーム側が無理やり差し込むべきものだった。
FirefoxがEME拡張を導入したとき、終わりの始まりだと思った。DRMを単にオンにできるスイッチにしてしまえば、それは例外ではなく標準になる。何年も前から、フォントDRMのようなばかげた提案もあった。企業がDRMに固執するなら、本来ブラウザがサポートすべきでないことをさせるために生じる負担は、その企業が負うべきだ。
私たちが突き進んでいる悪夢は、動画を一度にごくわずかしかキャッシュできず、TPMの証明ハードウェアがすべてのHTTPリクエストにトークンを含めなければならない世界だ。ブラウザはただのソフトウェア版ケーブルテレビ端末になる。
彼らはURLも気に入っておらず、何かを共有するには、アプリ内で期限付きハッシュと閲覧回数制限の付いたURLを生成する、という形で自分たちの条件に従わせたがるだろう。もちろんインフルエンサーには、無制限の共有特権が残るかもしれない。
この10年でこうしたインフラがゆっくり敷かれてきたが、これは孤立した不便ではなく、棺に打ち込まれる釘だ。
GrayJay https://grayjay.app/ のような、かなりよくできたサードパーティ製YouTubeクライアントもある。
こうしたアプリは、複数の動画プラットフォームのクリエイターを1つのアプリでフォローできるようにするが、それはGoogleが望むYouTubeへの囲い込みにとっては都合が悪い。
しばらくの間、音声トラックを含むMP4動画であるitag 18と22が消え、itag 136や137のような動画のみの形式が好まれているように見えた。
この場合、ffmpegで音声トラックと動画を結合する必要があった。最近はitag 18が戻ってきたようだ。
例:
yt-dlp -f 137+140 '[https://www.youtube.com/watch?v=dQw4w9WgXcQ](<https://www.youtube.com/watch?v=dQw4w9WgXcQ>)'YouTubeは動画ダウンロードと戦っているようだ。
Torを使うと毎日「ログインしてボットではないことを証明しろ」というメッセージが出るし、TorなしではYouTubeにアクセスできない。広告を見るとかCAPTCHAを解くとかなら構わないが、YouTubeは最悪のやり方を選んだ。
認証まではしなくていいが、プロフィールは選ばなければならない。
数か月前から始まっていて特に気にしていなかったが、今見るとこの挙動は新しいDRM推進の前兆だったのかもしれない。
YouTubeは毎日、完全に避けるべき理由をさらに増やしている。
ちょうどここでも、YouTubeが「コミュニティ保護のため、ボットではないことを確認するにはログインしてください」と出迎えてきた。
首輪を締める方法はいくらでもある。
残念ながら、絶対にアカウントを作らない人もいるし、どんなDRMシステムも使わない人もいる。あの豊富な資料に間接的にアクセスする方法を見つける必要がある。
lofiやsynthwaveの音楽を見つけられるYouTubeの代替サービスをおすすめしてほしい。
アルバムを買えば、DRMなしのダウンロードを受け取れる。
https://bandcamp.com/discover/electronic+synthwave
https://www.di.fm/search?q=lofi
Firefox ユーザーはどうなるのか気になる
Firefox が対応している DRM は簡単に破られるが、YouTube は Firefox サポートを打ち切るのだろうか?
https://github.com/yuliskov/SmartTube/issues/4444 でも「メンバー限定」動画で確認されているが、やはりすべての動画ではなかった
おそらく Widevine L3 と L1、PlayReady SL2000 と SL3000 のようなソフトウェア DRM とハードウェア DRM の違いを指しているのだと思うが、これは厳密には Firefox 対 Chrome という構図ではない。Firefox も Windows でハードウェア DRM を利用できるよう取り組んでいたことが知られており、おそらく Media Foundation API 経由だったはず
Netflix のようなサービスで見られる最悪のシナリオは、Firefox のようにソフトウェア DRM しか使えないブラウザには低画質だけを提供し、より高画質なものはハードウェア DRM でしか得られない鍵で暗号化する方式。ただし YouTube が今そこまでやるのかは分からない。Netflix や Amazon は権利者とそうした保護措置を求める契約を結んでいるが、YouTube は幸いにも「YouTuber」たちと同じ種類の関係や契約を結んでいるわけではないと思う
今 YouTube が望んでいるのは、Web サイトやアプリを通さずにコンテンツを見る人、つまり広告を見ない人を大幅に減らすことのように見える。yt-dlp ユーザーよりも、YouTube-to-mp3 サイトや似たような簡単なツールに頼る、はるかに多くの人々を狙っている可能性が高い
ソフトウェア DRM を強制するだけでも、そうしたツールを少なくとも一時的に壊し、ユーザーをプラットフォームへ戻せる。そして「暗号化回避」メカニズムがツール内に組み込まれれば、開発者を訴えることもできるように思うが、法律の専門家ではない
そうなれば、yt-dlp が GitHub にホストされることも、apt リポジトリや pip、Homebrew などを通じて配布されることも終わる可能性が非常に高い
関連して、TubeArchivist がちょうど v0.5 をリリースしており、公式には機能凍結状態ではない