ストリーミングからローカルMP4へ:4つの変換ルートを実際に試して比較

目次

  1. 検証条件
  2. ルート1:ブラウザ内変換
  3. ルート2:ストリームコピー
  4. ルート3:再エンコード
  5. ルート4:画面収録
  6. 結果の整理と使い分け

検証条件

今回は「10分程度のH.264+AACのHLS配信を、手元のMP4に落とす」を共通課題にして、4つのルートを同じ土俵で試しました。評価軸は所要時間・画質・面倒くささの3つです。ソースは複数ビットレートのマスタープレイリスト付きで、CORSは許可済みという、比較的扱いやすい条件です。あなたの環境でも条件が近ければ、似た傾向になるはずです。

ルート1:ブラウザ内変換

最初に試したのはM3U8→MP4変換ツールを使う方法です。URLを貼ってボタンを押すだけで、セグメント取得からMP4生成までがブラウザの中で完結します。インストールもコマンドも不要で、所要は体感2〜3分。出力はそのままダウンロードフォルダへ落ちてきました。

処理は手元で完結するためソースが外部に流出しないのが大きな安心材料です。ただしブラウザのメモリ上限があるため、30分を超える長尺では途中で失敗しやすい点には注意が必要です。

ルート2:ストリームコピー

FFmpegの-c copyを使う方法です。セグメントを順に取得しながら、中身を再エンコードせずMP4コンテナに詰め直します。

ffmpeg -i "https://example.com/master.m3u8" -c copy -bsf:a aac_adtstoasc output.mp4

所要は実測で再生時間より大幅に短く、画質はソースと同一。暗号化なしのTS構成なら、まずこの方法で間に合います。失敗するのはセグメントがfMP4以外の特殊構成のときや、音声コーデックがMP4に収まらないケースのみです。

ルート3:再エンコード

互換性やファイルサイズを整えたいなら、エンコードし直すルートです。

ffmpeg -i "https://example.com/master.m3u8" \
  -c:v libx264 -crf 20 -preset veryfast -c:a aac -b:a 128k output.mp4

-crf 20は品質優先の指定で、数値を上げるほど軽く荒くなります。時間はコピー方式の数倍かかりますが、出来上がりはどの環境でも再生しやすい標準的なMP4になり、古い端末や編集ソフトへの持ち込みにも強い。時短したければ-presetをultrafastへ、サイズを優先するならveryfastのまま-crfを上げるのが手早い調整です。

ルート4:画面収録

最後はOS標準の画面録画で再生画面を取り込む方法です。CORSや暗号化の制限を受けないのが唯一の強みですが、再生と同じ時間がかかり、画質も音もPCの再生環境次第です。他の3ルートがすべて通らなかったときの最終手段として位置づけるのが現実的です。

結果の整理と使い分け

ルート所要画質向いている場面
ブラウザ内変換短いほぼ無劣化短いクリップを手早く
ストリームコピー最短無劣化長尺・暗号化なしの定番
再エンコード長め調整可能互換性・サイズを整えたい
画面収録再生と同等環境依存他が通らないときの保険

結論としては、まずブラウザかストリームコピーで試し、うまくいかなければ再エンコード、最後に画面収録という順番が最も無駄がありません。再生での確認はオンラインプレーヤーが便利です。関連の手法はチュートリアル一覧に他の記事もあります。