この記事でわかること

  • MPEG-DASHの基本的なセグメント生成コマンド
  • 複数ビットレートの適応型ストリーミング（ABR）構成
  • セグメント長（-seg_duration）と初期化ファイルの設定
  • HLSとMPEG-DASHの主な違い
  • VOD向けとライブ向けのオプション比較

動作確認: FFmpeg 8.1 / Windows — 本記事のコマンド 4 件を検証スクリプトで実行し、全て成功しました（2026-09-06） 対象 OS: Windows / macOS / Linux

MPEG-DASHの基本概念

MPEG-DASH（Dynamic Adaptive Streaming over HTTP）はHTTP経由で動画を小さなセグメントファイルに分割して配信する規格です。

要素 説明
MPDファイル マニフェスト（プレイリスト相当）
セグメントファイル 実際の映像・音声データ（通常2〜10秒）
Representation ビットレート・解像度の組み合わせ
AdaptationSet 映像/音声の種別グループ

基本コマンド（シングルビットレート）

ffmpeg -i input.mp4 -c:v libx264 -b:v 1500k -c:a aac -b:a 128k -f dash -seg_duration 4 output.mpd

実行すると以下が生成されます：

  • output.mpd — マニフェストファイル
  • init-stream0.m4s — 映像の初期化セグメント
  • init-stream1.m4s — 音声の初期化セグメント
  • chunk-stream0-XXXXX.m4s — 映像セグメント（連番）
  • chunk-stream1-XXXXX.m4s — 音声セグメント（連番）

複数ビットレートのABR構成

適応型ストリーミングの真価は複数品質の並行生成にあります。-map オプションで同一入力から複数のビットレートに出力します。

ffmpeg -i input.mp4 \
  -map 0:v -map 0:a -map 0:v -map 0:a \
  -c:v libx264 \
  -b:v:0 2500k -s:v:0 1280x720 \
  -b:v:1 800k  -s:v:1 854x480 \
  -c:a aac -b:a 128k \
  -f dash \
  -seg_duration 4 \
  -adaptation_sets "id=0,streams=v id=1,streams=a" \
  output.mpd

上記は720p（2500kbps）と480p（800kbps）の2ビットレート構成です。プレイヤーはネットワーク状況に応じて自動的に切り替えます。

主要オプション一覧

オプション 例 説明
-seg_duration 4 セグメント長（秒）。通常2〜6秒
-use_timeline 1 タイムラインセグメント（VOD推奨）
-use_template 1 テンプレートURL（ライブ推奨）
-window_size 5 ライブ時の保持セグメント数
-adaptation_sets "id=0,streams=v" セットのグループ化
-init_seg_name "init_$RepresentationID$.m4s" 初期化セグメントのファイル名テンプレート
-media_seg_name "seg_$Number$.m4s" メディアセグメントのファイル名テンプレート

VOD向け設定

ffmpeg -i input.mp4 \
  -c:v libx264 -b:v 1500k \
  -c:a aac -b:a 128k \
  -f dash \
  -seg_duration 4 \
  -use_timeline 1 \
  -use_template 1 \
  output.mpd

実測: 処理時間とサイズ

実際に計測したのは次のコマンドです。

ffmpeg -i input.mp4 -c:v libx264 -b:v 2500k -c:a aac -b:a 128k -f dash -seg_duration 4 output.mpd

処理時間は 22.66 秒。今回のランで記録したのは時間だけです。DASH の出力は MPD と多数のセグメントファイルに分かれるため、比較できる「出力ファイル1個のサイズ」が存在しません。この節にあった「約39MB」は計測値ではなく推定だったので削除しました。

同じ計測ランの他の操作と並べると位置づけが分かります。

操作 処理時間
このDASHセグメント化（4秒セグメント） 22.66 s
フィルタなしの再エンコード（libx264 CRF 23 / preset medium、音声なし） 27.97 s
ストリームマッピング（-c copy） 0.41 s
moov atom の先頭移動（-c copy） 0.49 s
音声フェード（映像は -c copy） 1.03 s

計測環境: Intel Core i9-14900KF（32スレッド）/ Windows / FFmpeg 8.1（gyan.dev）。素材は 1920x1080・30fps・120秒・351.4MB（Big Buck Bunny をループ、CC BY 3.0）。2026-09-05 に逐次実行。生データはデータセットで公開しています。

22.66秒の中身

22.66秒のほとんどは H.264 エンコードの時間です。-f dash がやっているのはセグメント境界での分割と MPD の生成だけで、画素に触る処理は1つも増えていません。だから数字は再エンコードを伴うコマンドの帯（このランでは 14〜729 秒）に落ち、フィルタなしの再エンコード 27.97 秒と同じオーダーになります。「再エンコードするDASH化は通常のH.264エンコードとほぼ同じコスト」という以前の説明は、実測で裏づけられた形です。

ただし 22.66 秒と 27.97 秒は条件を揃えた A/B ではありません。ベースラインは -crf 23 で音声を捨てており、こちらは -b:v 2500k 指定に AAC エンコードが乗っています。「同じオーダー」と読むべきで、差分を DASH 化の効果として読んではいけません。

効くのはパッケージングではなくエンコーダ

同じランで -c copy を使った操作は 0.41〜1.03 秒で終わっています。パッケージング（分割・多重化・マニフェスト生成）そのものは、この程度の仕事量です。DASH化が22.66秒かかったのは分割したからではなく、映像を作り直したからです。

したがって速度を上げたいなら、削るべきはセグメント設定ではなくエンコードです。素材がすでに配信要件を満たす H.264 + AAC で、キーフレーム間隔がセグメント長に揃っているなら、-c copy でのセグメント化が最短経路になります。なお今回のランでは -c copy でのDASH化は計測していないので、その秒数はここでは示せません。

HLS vs MPEG-DASHの選択

比較項目 HLS MPEG-DASH
Apple Safari標準対応 ○（ネイティブ） △（要JS）
セグメント形式 .ts / .m4s .m4s / .mp4
標準化団体 Apple独自 ISO国際標準
動的ABR切替 ○ ○
主な用途 iOS・Safari向け 汎用・OTT向け

関連記事

動作確認: FFmpeg 8.1 / Windows — 本記事のコマンド 4 件を検証スクリプトで実行し、全て成功しました（2026-09-06） 一次ソース: ffmpeg.org/ffmpeg-formats.html#dash / trac.ffmpeg.org/wiki/Create%20a%20DASH%20playlist

よくある質問

DASH と HLS、どっちを使う？

iOS / Safari は HLS が最も無難です。デスクトップブラウザやスマート TV では DASH が使われることも多いです。最広範囲をカバーするなら、-f hls と -f dash の2系統を別々に生成してください。

セグメント長は何秒がいい？

4〜6 秒が起動時間と切替遅延のバランス点。短い（2 秒）と高速チャンネル切替できるが、マニフェスト更新と CDN コストが増える。

DASH プレーヤーが品質切替時に毎回バッファする

画質間で keyframe が揃ってない可能性が大。各レンディションに -force_key_frames "expr:gte(t,n_forced*4)" を強制してください。

FFmpeg だけでライブ DASH できる？

可能です — -f dash -window_size 5 -extra_window_size 10 でスライディングライブウィンドウ生成。CDN ingest エンドポイントへ HTTP PUT で送る形に。

音声を別セグメントにする必要は？

複数ビットレートや多言語音声があるなら必要。-adaptation_sets "id=0,streams=v id=1,streams=a" で映像セットと音声セットを分割します。