FFmpegでRTMPライブ配信する — YouTube Live / Twitchへ映像を送出する

この記事でわかること

• RTMPの仕組みと、FFmpegが配信プラットフォームへ映像を「プッシュ」する流れ
• 最小の送出コマンドと、各オプション（-re・-f flv・-g・-pix_fmt・-maxrate/-bufsize）の意味
• YouTube Live・Twitchそれぞれへの配信コマンド（推奨ビットレート付き）
• 素材が既にH.264/AACなら再エンコードせず送出する-c copyの使い方
• Webカメラ＋マイクをそのままライブ配信する方法（Linux/v4l2）
• よくあるエラーと対処法

テスト済みバージョン: FFmpeg 6.1（検証スクリプトで実 FFmpeg 実行確認）
対象 OS: Windows / macOS / Linux

RTMPとは

RTMP（Real-Time Messaging Protocol）は、Adobeが開発したライブ動画配信用のプロトコルです。YouTube Live・Twitch・Facebook Liveなど、主要なライブ配信プラットフォームはほぼすべてRTMP（およびTLSで包んだRTMPS）入力に対応しています。

配信の流れはシンプルです。FFmpegがRTMPクライアントとして動作し、ローカルの映像・音声をリアルタイムにエンコードしながら、プラットフォームのRTMPサーバーへ連続して送り込みます。サーバー側はそれを受け取り、視聴者へ再配信します。配信先のURLには各アカウント固有の**ストリームキー（STREAM-KEY）**が含まれ、これが「どのチャンネルの配信か」を識別します。

ストリームキーは配信ダッシュボード（YouTube Studio、Twitchのクリエイターダッシュボードなど）で取得します。ストリームキーはパスワードと同等の秘密情報です。漏れると第三者があなたのチャンネルへ配信できてしまうため、スクリーンショットや配信画面に映さないよう注意してください。

最小の送出コマンド

まずはローカルの動画ファイルを再エンコードしてYouTube Liveへ送出する、もっとも基本的な形です。

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/STREAM-KEY

STREAM-KEYの部分を自分のストリームキーに置き換えれば、input.mp4がリアルタイムでYouTube Liveに流れます。このコマンドには配信に必須の要素がすべて含まれているので、次のセクションで一つずつ意味を確認していきましょう。

各オプションの意味

-re：実時間で読み込む

-reは入力を「ネイティブのフレームレートで読み込む」フラグです。ファイルは本来ディスクから一気に読めてしまうため、これを付けないとFFmpegは数十秒の動画を数秒で全部送りつけてしまい、配信になりません。-reを付けると30fpsの動画は毎秒30フレームのペースで読み込まれ、実時間どおりに送出されます。ファイルを入力にしてライブ配信する場合は必須です（Webカメラなどのライブデバイスは元々実時間で入力されるため不要なこともあります）。

-f flv：RTMPのコンテナ

RTMPはFLVコンテナをトランスポートに使います。出力先がRTMP URLでも、FFmpegには明示的に-f flvを渡す必要があります。これを忘れるとUnable to find a suitable output formatなどのエラーになります。

-g：キーフレーム（GOP）間隔

-gはキーフレーム（Iフレーム）を何フレームごとに挿入するかを指定します。多くのプラットフォームはGOP 2秒を推奨しています。つまり「フレームレート × 2」を指定します。

• 30fps → -g 60
• 60fps → -g 120

キーフレームは視聴者が再生を開始したり、画質バリエーションを切り替えたりする際の起点になります。間隔が長すぎると視聴開始や画質切替に時間がかかり、短すぎるとビットレート効率が落ちます。

-pix_fmt yuv420p：互換性のため必須

H.264の入力素材によってはyuv444pやyuvj420pなどになっている場合があり、そのまま送ると一部プレーヤーやプラットフォームで再生できません。-pix_fmt yuv420pを指定して、広く互換性のあるフォーマットへ統一します。

-maxrate／-bufsize：疑似CBR化

ライブ配信は安定した帯域を保つため**一定ビットレート（CBR）**が推奨されます。libx264はデフォルトでは可変ビットレート（VBR）寄りなので、-b:vに加えて-maxrateを同じ値、-bufsizeをその約2倍に設定することで、ビットレートの上振れを抑えた疑似CBRにできます。これにより回線やプラットフォームの想定帯域からはみ出しにくくなります。

YouTube Liveへ配信する

YouTube StudioのライブダッシュボードでストリームキーをコピーしてURL末尾に貼り付けます。YouTubeのRTMPエンドポイントは rtmp://a.rtmp.youtube.com/live2/ です。

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/STREAM-KEY

YouTubeで1080pを配信する場合、映像ビットレートの目安は4500〜6000kbpsです。回線とPC性能に余裕があればこのレンジ内で調整してください。-g 60は30fpsを前提とした2秒GOPで、60fps配信なら-g 120に変更します。

Twitchへ配信する

Twitchへの送出はYouTubeと基本構造は同じで、配信先URLとビットレート上限が異なるだけです。Twitchのエンドポイントは rtmp://live.twitch.tv/app/ で、ストリームキーはクリエイターダッシュボードから取得します。

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 6000k -maxrate 6000k -bufsize 12000k -pix_fmt yuv420p -g 120 -c:a aac -b:a 160k -ar 44100 -f flv rtmp://live.twitch.tv/app/STREAM-KEY

Twitchの映像ビットレートはおおむね6000kbpsが上限の目安です。これを超えると視聴側のバッファリングや配信切断の原因になるため、-b:v・-maxrateを6000k以下に収めてください。ここでは60fps想定で-g 120（2秒GOP）、音声は160kbpsにしています。

再エンコードせずに送出する（-c copy）

入力素材が既にH.264映像／AAC音声で、しかも解像度・ビットレート・GOPがプラットフォーム要件に合っているなら、エンコードをやり直さずそのままパススルーで送出できます。映像を再圧縮しないのでCPU負荷が劇的に下がり、画質劣化もありません。

ffmpeg -re -i input.mp4 -c copy -f flv rtmp://server/app/STREAM-KEY

-c copyは映像・音声の両ストリームをそのままコピーします。ただし条件は厳しめです。

• 映像がH.264、音声がAACであること（VP9やOpusなどは不可）
• 解像度・フレームレート・ビットレートがプラットフォームの許容範囲内であること
• GOP（キーフレーム間隔）が要件を満たしていること（コピーでは-gで後から変更できないため、素材作成時に2秒GOPで作っておく必要がある）

条件が合わない場合は、結局このセクションより前のようにlibx264で再エンコードする必要があります。「とりあえず-c copyで送ったら配信が始まらない／映像が乱れる」というときは、ほぼこの要件不一致が原因です。

Webカメラのライブ配信

ファイルではなく、Webカメラの映像とマイクの音声をその場でライブ配信する例です。以下はLinuxのv4l2（映像）＋ALSA（音声）の組み合わせです。

ffmpeg -f v4l2 -i /dev/video0 -f alsa -i default -c:v libx264 -preset veryfast -b:v 3000k -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -f flv rtmp://a.rtmp.youtube.com/live2/STREAM-KEY

ポイントは入力が2つあることです。-f v4l2 -i /dev/video0がカメラ、-f alsa -i defaultがマイクで、FFmpegが両者を合成して1本のライブストリームとして送出します。カメラデバイスは環境により/dev/video1などになることもあるので、ls /dev/video*で確認してください。

Webカメラは元々実時間で入力されるため-reは付けていません。ビットレートはカメラ配信向けに3000kbpsへ抑えています。

Windowsでは-f dshow、macOSでは-f avfoundationがデバイス入力の指定方法になります。デバイス名の調べ方や指定フォーマットがOSごとに異なる点に注意してください。

よくあるエラーと対処

Operation not permitted / 接続拒否

サーバーへの接続自体が拒否されるケースです。主な原因は次の2つです。

• ストリームキーの誤り：ダッシュボードから最新のキーを正確にコピーし直してください。キーは定期的に再生成されることがあります。
• ファイアウォール／回線のブロック：RTMPの送出ポート（標準は1935）がファイアウォールやネットワーク機器でブロックされていないか確認します。

Broken pipe

配信中に接続が切れたときのエラーです。ネットワークの瞬断や、アップロード帯域不足でサーバーが受け取りきれずに切断した場合に発生します。iperf3などで実効アップロード帯域を測り、配信ビットレート（映像＋音声）に十分な余裕があるか確認してください。帯域が足りなければ-b:vを下げます。

ビットレート過大によるバッファリング

設定ビットレートが回線やプラットフォーム上限を超えていると、視聴側で頻繁にバッファリングが起きたり配信が不安定になります。-b:v・-maxrateをプラットフォームの推奨値内（YouTube 1080pなら4500〜6000kbps、Twitchなら6000kbps程度）へ下げ、-bufsizeはmaxrateの約2倍に揃えてください。

音声が出ない

映像は配信されるのに音声が無い場合、音声コーデックの指定漏れが典型です。-c:a aac -b:a 128kのように音声エンコードを明示してください。-c copyを使っているなら、元素材の音声がAAC以外（Opusなど）でプラットフォームが受け付けていない可能性があります。

GOPが長すぎて開始が遅い

-gを指定していない、または値が大きすぎると、視聴者が配信を開いてから映像が出るまで時間がかかります。視聴開始はキーフレームから始まるためです。フレームレート × 2（30fps→-g 60、60fps→-g 120）で2秒GOPに設定してください。

関連リソース

よく使うオプション・フィルタ・コーデック設定をまとめた PDF チートシートです。手元に置いておくと調べる時間を短縮できます。

FFmpeg チートシート

関連記事

• HLSセグメント生成 — Webストリーミング用セグメントとプレイリストの作成
• MPEG-DASHセグメントを生成する
• 動画の圧縮 — CRFとビットレート目標値
• フレームレートの変更
• GPUハードウェアエンコード（NVENC）

テスト環境: ffmpeg 6.1.1 / Ubuntu 24.04（検証スクリプトで実行確認）
一次ソース: trac.ffmpeg.org/wiki/StreamingGuide / ffmpeg.org/ffmpeg-formats.html

よくある質問

-reは本当に必要？

ファイルを入力にしてライブ配信する場合は必須です。-reが無いとFFmpegはファイルを実時間より遥かに速く読み込み、数十秒の動画を一瞬で送りつけてしまいます。一方、Webカメラやキャプチャデバイスは元から実時間で入力されるため、-reは不要なことが多いです。

-c copyと再エンコード、どちらを使うべき？

素材が既にH.264/AACで、解像度・ビットレート・GOPがプラットフォーム要件に合っているなら-c copyが最適です。CPU負荷がほぼゼロで画質劣化もありません。条件が一つでも外れる場合はlibx264で再エンコードしてください。

GOP（-g）はいくつにすればいい？

プラットフォーム推奨はGOP 2秒です。「フレームレート × 2」で計算し、30fpsなら-g 60、60fpsなら-g 120を指定します。長すぎると視聴開始や画質切替が遅くなります。

ストリームキーが漏れたらどうなる？

第三者があなたのチャンネルへ勝手に配信できてしまいます。パスワードと同等の秘密情報として扱い、配信画面やスクリーンショットに映さないでください。万一漏れた場合は、各プラットフォームのダッシュボードからストリームキーを再生成してください。