世界を動かす技術を、日本語で。

Yt-dlp: YouTubeダウンロードの新しい要件について

概要

YouTubeの仕様変更により、yt-dlpでの通常ダウンロードには Deno のインストールが必須となる見込み 従来の 組み込みJavaScriptインタープリタ では対応不可 ユーザーの インストール方法ごと に追加対応が必要 PyInstaller版、PyPI版、zipimport版、サードパーティパッケージ で対応内容が異なる 今後の 変更内容と対応方法 についての解説

YouTubeダウンロード継続利用のためのDeno導入案内

  • YouTube側の大幅な仕様変更 により、yt-dlpの従来のJavaScriptインタープリタでは JSチャレンジの解読が困難 となる
  • 今後は Deno などの本格的なJavaScriptランタイムが 必須要件
  • yt-dlp本体 はDenoを通じてJavaScriptチャレンジを 安全かつ確実に処理

インストール方法別の対応

  • PyInstallerバンドル実行ファイル利用者 (例: yt-dlp.exe, yt-dlp_macos, yt-dlp_linux)
    • Denoのインストールのみ必須
    • JavaScriptコンポーネントは 全て実行ファイルに同梱
  • PyPIパッケージ利用者 (pip, pipx等でインストール)
    • pip install -U "yt-dlp[default]"オプション依存関係含めアップグレード が必要
    • Denoの 別途インストール必須
  • 公式zipimportバイナリ利用者 (yt-dlp Unix実行ファイル)
    • yt-dlp実行時に 追加フラグ でDenoによるnpm依存関係のダウンロードを許可
    • または Python環境にyt-dlp専用JSソルバーパッケージをインストール
    • ※フラグ名・パッケージ名は 近日公開予定
  • サードパーティパッケージ利用者 (pacman, brew等でインストール)
    • 各リポジトリの対応方針に依存
    • 基本的に 公式zipimportバイナリ向けの対応方法を参考に対応可能

今後の注意点

  • Deno未導入の場合、YouTubeからのダウンロードが失敗 する可能性
  • yt-dlpの 公式アナウンスやドキュメントの継続確認 が重要
  • Denoのインストール方法yt-dlpのアップデート手順 についても事前確認推奨

Hackerたちの意見

Denoを選んだのには驚いたけど、Denoは単一の実行ファイルで配布されてるから、いろんな面倒が省けるんだよね。これは時間の問題だったと思う。元々のPythonのインタープリタは素晴らしいハックだったけど、機能には限界があったし。数年前にYouTube-dlプロジェクトについて話題になってたよね。

NodeにはDenoのようなセキュリティや隔離の概念がないんだよね。同じスレッドにメンテナーのコメントもあったよ。

Denoのサンドボックス機能も、その選択に影響を与えたみたいだね。セキュリティレイヤーとしてはあまり信頼できないけど、何もないよりはマシだよね。

私はYouTubeプレミアムの有料会員なんだけど、先週末に何かをダウンロードして電車の中で見ようと思ったんだ。アプリがiPadで「ダウンロード待機中…」で止まっちゃって、iPhoneでも同じだった。再起動してもダメだったし、1時間後に諦めたよ(30分は試行錯誤、30分は放置)。yt-dlpを使って動画をダウンロードして、USB-Cのフラッシュドライブに転送して見た。家族が広告なしで楽しんでるから、「プレミアムは家庭外の人と共有できません」ってポリシーが来るのを待ってる。そしたらやっと解約できる。

YouTube Kidsで広告なしが機能しなくなって解約したよ(ShieldTVで)。多分バグだったんだろうけど、実質的にカスタマーサービスの選択肢がなくて、解決策は解約しかなかった。プレイミュージックの有料会員からの移行組だったし、YouTubeに音楽が移行した直後だったから、もう我慢の限界だった。

さらに面白いのは、YouTubeにアップロードしてからクリエイターダッシュボードからダウンロードしようとすると(例えば、ライブ配信しててローカルコピーを保存するのを忘れたとか、マシンに負担がかかりすぎるとか)、720pのクソみたいな画質しか手に入らないのに、yt-dlpならクライアントが利用できる最高の画質をゲットできるってこと。

私も同じ状況のプレミアムユーザーだよ。デスクトップではuBlock OriginとSponsorblockを使って、テレビではSmartTubeを使ってる。プレミアムにお金を払ってるのは、技術に詳しくない家族と広告なしの体験を共有するためと、彼らのiOSアプリを使うためなんだ。もしプレミアムのファミリーシェアリングのルールが厳しくなったら、すぐにサブスクリプションをやめるよ。

私もYouTubeプレミアムにお金を払ってるけど、自動翻訳を無効にするためにスマホではReVancedを使ってる。公式アプリでこれを設定できないのは本当におかしいよね。

「プレミアムは家庭外の人と共有できません」っていうポリシーを待ってるから、やっとキャンセルできる。 それ、しばらく前からのポリシーだよ。サインアップページには「プランメンバーは同じ家庭にいる必要があります」ってはっきり書いてある。でも、実際に施行されてるかは分からない。

私もプレミアム会員だけど、iPadアプリで同じ問題に悩まされてる。子供のためにいくつかの番組をダウンロードしておきたいんだけど、ダウンロード機能が最初の試みでは全然うまくいかない。もう我慢できなくなって、eBayで50ドルでSamsung Galaxy Tab A7を買って、LineageOSをインストールした。これで、1TBのSDカードに好きなメディアを入れられるようになった。5年前のハードウェアでも、VLCアプリで動画は問題なく再生できるし、ボーナスとして、F-Droidストアからインストールした代替YouTubeクライアントのNewPipeが、公式クライアントよりも動画のダウンロードがずっと信頼できることを発見した。SDカードにデータを入れるためにyt-dlpを使うつもりだったけど、今はそれすら必要ない。

「プレミアムは家庭外の人と共有できません」っていうポリシーを待ってるから、やっとキャンセルできる。 それなら、いいニュースがあるよ! https://lifehacker.com/tech/youtube-family-premium-crackdown 実際、これについてのメールもすでに受け取ってる。私のYTはまだ広告なしだけど、いつ本当に適用されるのかは分からない。

私はプレミアム会員だから、yt-dlpでエラーや警告なしにダウンロードできる。私たちは同じじゃない。

スタートアップを運営している人に提案したいライフスタイルの福利厚生が2つあるんだ。1. 無制限のYouTubeプレミアム 2. 無制限の飲み物の払い戻し(コーヒー、紅茶、スムージー、なんでも)この2つのことから感じる心理的な喪失感は、5%の昇給よりも大きいと思うよ。

私もYouTubeプレミアムを使っていて、主にiPadとテレビで見てるよ。YouTubeは毎日少なくとも一回は私をログアウトさせるんだ。広告がまた流れ始めるから気づくんだけど(RSSリーダーから動画を開くから、彼らのサイトは使わない)、プレミアムじゃなかった頃はこんなことなかった。何をやってるのか分からないけど、ほぼ1年経った今の印象は、広告が出るよりはちょっとだけマシって感じだね。今のところ、更新しないで広告ブロックを使った方がいいかも。

この「JavaScriptインタープリタ」にかけられたエンジニアリングの努力には本当に感謝してるよ。

へぇ、それは結構クールだね。

へぇ、実際にどれだけのJavaScriptを解釈してるのか気になるな。1000行未満だし、コンパイラの入門コースに使えるかもしれないね。

モバイルで見てるけど、これはオブジェクトと算術だけを扱う実際のJSインタープリターみたいだね。ここまで進んでるのはすごいわ。

どのくらいで独自のプロジェクトに分かれるのか気になるな。今のところ、もっとドキュメントが必要だね。少なくとも、テストはあるみたいだけど!

この発表の中で一番驚いたのは、彼らがすでにそんなことをしていたなんて知らなかったこと。ほんとにすごいよね!

ちょっとコードを見てみることにしたら、PythonのChainMapを発見したよ。

昔、動画生成モデルに取り組んでたんだけど、YouTube以外の動画を見つけるのがどれだけ大変かにショックを受けた。YouTubeは一度に数本以上の動画をダウンロードするのが不可能に近いし。

複数の引数を与えないといけないし、レート制限や長い待ち時間もある。最近のアップデートはJSインタープリター以外にあったかどうかはわからないけど、セッションクッキーを渡すためにブラウザのDockerインスタンスを立ち上げる必要があったよ。

Nsig/sig - APIコールに渡す必要がある特別なトークンで、base.js(プレイヤーコード)内のコードによって生成されるんだ。これがyt-dlpや他のサードパーティクライアントで壊れちゃった。以前は正規表現を使ってそのトークンを生成するコードを抽出してたけど、今はプレイヤーコード全体を実行しないとトークンが取得できないんだ。PoToken - Googleが最近、すべてのクライアントに対して強制している起源証明トークンで、これがないと動画リクエストは403エラーで失敗する。AndroidではDroidGuardを使い、iOSでは組み込みのアプリ整合性APIを使う。ウェブでは、ブラウザでJavaScriptコードのスニペット(チャレンジ)を実行してボットじゃないことを証明する必要がある。以前は外部ツールが必要だったけど、Denoの変更でyt-dlpは近い将来自力でこれらのトークンを生成できるはず。SABR - サーバーサイドの適応ビットレートストリーミングで、GoogleのUMPプロトコルと一緒に使われて、サーバーがバッファリングをよりコントロールできるようにする技術。クライアントから現在の再生位置やバッファ範囲などのデータを受け取る。これを使ってサーバーサイドの広告挿入も行われる。サードパーティクライアントがこの技術と連携できるようにする作業はまだ進行中(うまくいく時もあれば、そうでない時もある)。Nsig/sigの抽出例: - https://github.com/yt-dlp/yt-dlp/blob/4429fd0450a3fbd5e89573... - https://github.com/yt-dlp/yt-dlp/blob/4429fd0450a3fbd5e89573... PoToken生成: - https://github.com/yt-dlp/yt-dlp/wiki/PO-Token-Guide - https://github.com/LuanRT/BgUtils SABR: - https://github.com/LuanRT/googlevideo EDIT2: 特定のコード例やガイドへのリンクを追加したよ。

GoogleやCloudflareがなぜウェブをいくつかの署名された、整合性チェックされたブラウザ実装に制限したいのか、今ならわかるね。

ウェブでは、ボットじゃないことを証明するためにブラウザでJavaScriptコードのスニペット(チャレンジ)を実行する必要がある。これでどうやってボットじゃないって証明できるの?クライアントサイドのJSなら、ヘッドレスChromiumで動かない理由は何?

簡単にリッピングできる時代は終わりが近いね。長期間保存したいYouTubeのコンテンツがあるなら、今のうちに https://www.tubearchivist.com/ みたいなものでアーカイブしておくことをおすすめするよ。

彼らはYouTube映画用の適切なDRM技術を何年も前から持ってたのに、どうしてすべてのコンテンツにそれをオンにしなかったの?

同感だし、今こそYTが独占的な手段で手に入れた本当に価値のある文化的・教育的コンテンツをアーカイブする時だと思う。この解決策は面白そうだけど、設定や維持が面倒そうなのはわかる。今のところ、サブ付きチャンネルからすべてをダウンロードすることに焦点を当てているみたいだね。今はダウンロードした動画のフォルダがあれば、動画名を解釈してリンク付きの整理されたページを作るローカルウェブサーバーが必要なんだけど、そういう軽量なものってあるかな?

ウェブからデータを取るだけの日々は終わりつつあるね。今や、すべてが何千行もの難読化されたJSコードを実行するフルブラウザを必要としてる。だから、1KBのJSONをキャッシュできるはずのウェブサイトが、今はフルブラウザスタックを立ち上げて、100リクエストで10MBを送信する羽目になって、分析やセキュリティプロファイルがめちゃくちゃになって、みんな損してる。やったね。

Accelerateって何か知ってる?もっとやりすぎてほしいんだ。ビッグテックにはこの手のことを思いっきりやってほしい。壊れたシステムや意味不明なことが必要なんだよ。そうしないと、何か良いものは手に入らないから。

つい最近、hnに「YouTubeは密かにダウンローダーに働いてほしいと思っている」という話が投稿されてたよね。YouTubeがダウンロードを止めるために「ちょうどいい」ことをしているのは明らかだし、3億人のユーザーを支えている。もし世界中の人が最新のiPhoneやAndroidを持っていたら、すぐに全コンテンツにDRMをかけるだろうね。

具体的には、yt-dlpは古いスマートテレビ向けのレガシーAPI機能を使っていて、これらのテレビはソフトウェアのアップデートを受け取らないんだ。最終的にそのトラフィックがほぼゼロに近づいたら、その機能は消えていくことになるよ。

ほとんど笑えるけど、悲しいことに、彼らのプレイヤーやページが変更されて、たくさんのJSで重くなってるのが問題だよね。しばらくの間、i3の第4世代で480pで見るために「watch?v=」を「/embed/」に変えなきゃいけなかったけど、ダウンロードした同じ動画はCPUの約3%しか使わないんだよね。でも、残念ながら、もうそれがうまくいかないことも多い。ユーザー体験が悪化する一方で、他のサイトはプレイヤーを最適化していて、ダウンローダーのことを気にしてないみたい(例えば、アダルトサイトとか)。

GitHubの隣に置いておいて。アプリはi5の第8世代ではほとんど使えないし、よくローカルでブラウズするためにスナップショットをダウンロードしてる。

個人的にはYouTubeから離れて、PeerTubeやピアベースのプラットフォームに目を向けようと思ってる。

Ronsor [1] と seproDevの返信: > なぜQuickJSのような軽量インタープリターを埋め込めないの? > @Ronsor #14404(コメント) リンクされたコメント [2]: > @dirkf この解決策はQuickJSでテストされて、動画ごとの実行時間が20分を超えたんだ。Denoと比べてどうしてこんなにひどいのか理解できないよ。

どうしてそんなにひどいの?[>20分] Denoと比べて。QuickJSはバイトコードインタープリターを使っていて(Pythonみたいに、遅いことで有名)、シンプルさと正確さに最適化されているんだ。一方、DenoはJITコンパイラーを使っていて(Javaや.NET、WASMみたいに)。DenoはChromeと同じJITコンパイラーを使っていて、これは世界で最も最適化されたものの一つだ。通常、そんなに大きな時間差にはならないけど、ほとんどの理由を説明できるし、実行するコードの種類によっては、今回のケースではすべてを説明できるかもしれない。QuickJIT(TCCを使ったQuickJSのフォーク)はより良い結果を出すかもしれないけど、それでもDenoよりは遅いだろうね。

ほんとに恐ろしいね。Googleは他のインタープリターのパフォーマンスを殺すためにすごく頑張ったに違いない。