本文へスキップ
yt-dlp

4K 動画のダウンロード — yt-dlp コマンドジェネレーター

チャプターとメタデータを保ったまま 2160p の動画を取るための yt-dlp コマンドを組み立てます。

任意です。空のままにするとコマンドは URL で終わるので、あとから自分で埋められます。

あなたのコマンド

yt-dlp -f 'bv*[height<=2160]+ba/b[height<=2160]' --merge-output-format mkv --no-playlist --embed-metadata --embed-chapters -N 4 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'
基本

音声のみを選ぶと音声トラックを取り出し、映像は捨てます。

動画と画質

高さの上限を決めます。yt-dlp はその上限以下で最良のストリームを選びます。

分かれている映像と音声のストリームを結合して入れるファイル形式です。

詳細オプション(3)

画質のプルダウンを上書きします。format の書き方をすでに知っている人向けです。

再エンコードせず入れ直すだけです。速く、劣化もありません。

映像を再エンコードします。遅く、劣化もします —— remux で足りないときだけ使ってください。

音声

音声を変換する先のファイル形式です。

VBR はサイズと品質の比がいちばん良く、固定 bitrate はサイズが読みやすいです。

字幕

埋め込みは字幕を動画の中に入れ、保存は隣に別の .srt ファイルを書き出します。

カンマ区切りで指定します。利用できる全言語が欲しいときは all と書きます。

再生リストとチャンネル

URL が動画と再生リストの両方に属している場合の動作です。

範囲もリストも使えます。たとえば 1-10,15、あるいは末尾から 1 つ飛ばしで取る -5::2 など。

詳細オプション(1)

ダウンロード済みの項目を記録するので、再実行時にはそれらを飛ばします。チャンネルを同期させ続ける方法がこれです。

区間とチャプター
詳細オプション(2)

*00:01:30-00:03:00 のような時間範囲、またはチャプター名です。先頭のアスタリスクは時刻であることを示します。

メタデータとカバー画像
詳細オプション(3)
SponsorBlock

SponsorBlock のデータをもとに、コミュニティが印を付けた区間をファイルから切り取ります。

詳細オプション(1)

区間は残したまま印を付けるので、自分で飛ばせます。

ファイルとフォルダ

フィールド名は %(...)s の中に書きます。スラッシュはフォルダを作ります。

詳細オプション(4)

ファイルを書き出す場所です。上のテンプレートと組み合わせるとサブフォルダも作れます。

ファイル名の最大長(文字数)です。

フィルタ
詳細オプション(5)

YYYYMMDD、または now-1month のような相対日付です。

YYYYMMDD、または相対日付です。

これより小さいものは飛ばします。5M、500K などが使えます。

これより大きいものは飛ばします。

停止するまでにダウンロードするファイル数です。

ネットワーク

たとえば 2M や 500K。残りの帯域を他のことに使いたいときに役立ちます。

詳細オプション(5)

分割されたストリームを速くします。まずは 4 くらいが妥当です。

失敗した部分を何回やり直すか。infinite も指定できます。

HTTP・HTTPS・SOCKS proxy の URL です。

リクエストを実際のブラウザからのものに見せます。突然 403 が出たときの定番の対処です。

ログインと cookies

ログイン中のセッションを直接読みます。非公開・年齢制限・メンバー限定のコンテンツには必要です。

詳細オプション(1)

ブラウザから書き出した Netscape 形式の cookies.txt です。

ライブ配信
詳細オプション(2)

予定されている配信が始まるまで問い合わせ続けます。MIN-MAX は確認の間隔(秒)です。

回避策
詳細オプション(3)

非推奨で、--add-headers に置き換わりました。古い解説記事がまだ多く使っているので残してあります。

非推奨で、--add-headers に置き換わりました。

サイトごとの専用オプションです。たとえば youtube:player_client=web。

出力とデバッグ
詳細オプション(2)
リセット

4K が実際に必要とするもの

2160p では映像と音声が必ず別ストリームなので、結合のために ffmpeg が必須です。MKV のほうが安全な container です:MP4 は 4K で配信される一部のコーデックを収められず、無理に使うと yt-dlp が再エンコードすることになります —— 遅く、劣化し、HDR のメタデータはたいていこうして失われます。

4K が出てこないなら、その解像度でアップロードされたことがない可能性が高いです。コマンドが間違っていると決める前にフォーマット一覧を見てください。1 時間あたり数 GB を見込み、それが問題ならサイズ上限か時間範囲を使ってください。

container の選択は HDR の決断です。4K HDR は VP9.2 や AV1 —— MP4 が常に収められないコーデック —— で届き、MP4 を無理に使うと yt-dlp がトランスコードします:数時間の仕事、目に見える品質の落ち、そして HDR メタデータは消える。MKV はすべてをそのまま収めます。このプリセットが既定で MKV にするのは、まさにその理由です。SDR のプレイヤーは HDR ファイルを色あせたように再生します —— それはプレイヤーのせいであってファイルのせいではなく、HDR から SDR へのまともな変換はフィルタの仕事であって、フラグではありません。

帯域は、4K が理論でなくなる場所です:2160p はまともなビットレートで 1 時間の映像につき 40–90 GB になり、並列 fragment は回線が許す限り速くダウンロードします —— それはまさにプラットフォームの速度制限を引き当てるものです。実行が這うように遅くなったら、fragment の数を半減させて長く走らせてください。4K のファイルは大きいので、遅く終わるほうが再開よりまだ勝ります。サイズ上限のオプションは、ディスクが止める前に暴走した実行を止めるためにあります。

チャプターとメタデータは、4K の保存が実益を示すところです:チャプターのない 2 時間の映画は 1 本のファイルで、あればたどれます。SponsorBlock もここで接続します —— 贊助区間は 4K コンテンツにもほかと同じく印が付きます。映画一本分のファイルでそれを飛ばすことは、それより短いどのものよりも時間を節約します。サムネイルをカバー画像として埋め込んでください。そうしないとメディアライブラリはすべての 4K ファイルを空白のタイルで表示します。

4K にできないことがひとつあります。拡大です。上向きに上限をかけられた 1080p のソースは 1080p のままです —— 上限は最大値であって、yt-dlp はその値以下の最良のストリームを文句なく選びます。-F が 1080p より上を何も示さないなら、それが投稿者がプラットフォームに与えたもののすべてです。YouTube の本物の 4K ソースはたいてい VP9 か AV1 で、古い GPU はソフトウェアでデコードします —— 重いプレイヤーはしばしばファイルではなくコーデックの問題で、MKV は元のコーデックに一切触れません。

よくある質問

この動画に 4K がないのはなぜ?
4K でアップロードされていないか、プラットフォームがその版を制限しています。コマンドが間違っていると決める前に -F で何があるか確認してください。
4K にはどの container を使うべき?
MKV はどのコーデックの組み合わせでも収められます。MP4 は互換性が高い一方で一部の 4K コーデックを収められず、その場合 yt-dlp は再エンコードすることになります —— 遅く、劣化します。
4K のダウンロードはどれくらいの大きさ?
1 時間あたり数 GB になることが多いです。それが問題ならサイズ上限か時間範囲を使ってください。
HDR は保たれますか?
元にあれば保たれます。元のコーデックを維持してください —— 再エンコードこそが HDR のメタデータを壊す典型的な原因です。