RTMPとは

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

配信の流れはシンプルです。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 入力をネイティブ（実時間）のフレームレートで読み込む。ファイルを入力にするときに必須（Webカメラなどのデバイスには通常付けない）
-i input.mp4 入力ファイル（後述するWebカメラなどデバイスも指定可）
-c:v libx264 映像をH.264でエンコード
-preset veryfast エンコード速度と画質のバランス。リアルタイム処理向けに速めの設定
-b:v 4500k 目標映像ビットレート
-maxrate 4500k 最大ビットレート
-bufsize 9000k レート制御バッファサイズ（maxrateの約2倍が目安）
-pix_fmt yuv420p ピクセルフォーマット。互換性のため必須
-g 60 キーフレーム（GOP）間隔
-c:a aac -b:a 128k -ar 44100 音声をAAC・128kbps・44.1kHzでエンコード
-f flv 出力コンテナをFLVに指定。RTMPに必須

-re：実時間で読み込む

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

-f flv：RTMPのコンテナ

RTMPはFLVコンテナをトランスポートに使います。出力先がRTMP URLでも、FFmpegには明示的に-f flvを渡す必要があります。これを忘れると Unable to choose an output format for 'rtmp://…' というエラーになります。

-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の推奨（H.264）は、1080p・30fpsで10Mbps、1080p・60fpsで12Mbps、720p以下・30fpsで4Mbpsです（YouTube ヘルプ）。このコマンドの4500kbpsは720p向けの値に近いので、1080p・30fpsで配信するときは、回線に余裕があれば-b:vと-maxrateを10000k、-bufsizeを20000kにします。-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ならほぼどこでも通ります。YouTubeはHEVCやAV1の映像、MP3の音声も受け付けます。YouTube ヘルプ）
  • 解像度・フレームレート・ビットレートがプラットフォームの許容範囲内であること
  • 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 / 接続拒否

Operation not permitted は、サーバーには届いたものの、配信を拒否されたときのエラーです。その直前の Server error: の行に、サーバーが返した理由が出ます。よくある原因は次のとおりです。

  • ストリームキーの誤り：ダッシュボードから最新のキーを正確にコピーし直してください。キーは定期的に再生成されることがあります。

サーバーにまったくつながらないときは、代わりに Cannot open connection tcp://… と出ます。

  • ファイアウォール／回線のブロック：RTMPの送出ポート（標準は1935）がファイアウォールやネットワーク機器でブロックされていないか確認します。

Broken pipe

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

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

設定ビットレートが回線やプラットフォーム上限を超えていると、視聴側で頻繁にバッファリングが起きたり配信が不安定になります。-b:v・-maxrateをプラットフォームの推奨値内（YouTubeのH.264なら1080p・30fpsで10Mbps、720p・30fpsで4Mbps、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に設定してください。

関連記事

よくある質問

-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を指定します。長すぎると視聴開始や画質切替が遅くなります。

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

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