ライブ配信プッシュ完全ガイド：RTMP/SRT/WebRTCプロトコル比較とOBS設定

YouTubeで配信したいがOBSの設定方法がわからない？企業イベントの配信 — セルフホストかクラウドサービス？インタラクティブ配信の遅延が高すぎる？クロスリージョン配信が不安定？ライブ配信技術は見た目より複雑です。このガイドでは、3大プロトコル、OBS設定、サーバー構築、最適化のヒントをカバーします。

コア配信ワークフロー

ライブ配信は本質的に：キャプチャ → エンコード → ネットワーク伝送 → サーバー処理 → 視聴者再生：

1. キャプチャ：カメラ、マイク、画面、ビデオファイル
2. エンコード：H.264/H.265ビデオ + AACオーディオ
3. マルチプレクス：FLV（RTMP）、TS（SRT）、MP4（WebRTC）
4. プッシュ：RTMP/SRT/WebRTCでストリーミングサーバーに送信
5. サーバー処理：トランスコード（オプション）、録画、プロトコル変換（例：RTMP→HLS）
6. 配信：CDNまたはセルフホストノード
7. 再生：視聴者がHLS、FLV、WebRTCでプル

二つの主要ボトルネック： プッシュ側のアップロード帯域幅 + サーバー処理能力。前者はビデオ品質に、後者は視聴者数に影響します。

三つのプロトコル比較

プロトコル	年	典型的遅延	パケットロス耐性	コーデック	サーバー複雑度	使用ケース
RTMP	2002	2-5秒	中程度	H.264/AAC	低	プラットフォーム標準
SRT	2017	0.5-2秒	強い	任意	中	クロスリージョン
WebRTC	2011	0.1-0.5秒	強い	VP8/VP9/H.264	高	インタラクティブ

RTMP：古いがまだ主流

RTMP（Real-Time Messaging Protocol）はAdobeがFlash用に開発しました。Flashは終了しましたが、RTMPは生き続けています：

• 成熟したエコシステム：YouTube、Twitch、Facebook Live — ほぼすべてのプラットフォームがRTMPをサポート
• シンプルな実装：FFmpeg、OBS、XSplitがデフォルトでサポート
• 許容遅延：2-5秒はほとんどの配信に適しています

欠点：

• TCPベース：パケットロス耐性が弱く、弱ネットワークで顕著なカクつき
• 更新停止：Adobeが開発を終了
• エコシステムの老朽化：新プロトコル（SRT、WebRTC）が代替

結論： 第三者プラットフォームへのプッシュにはRTMPが依然として第一選択。独自の配信システムにはSRTを検討。

SRT：低遅延とパケットロス耐性

SRT（Secure Reliable Transport）はHaivisionの2017年オープンソースプロトコルで、ビデオストリーミング専用に設計：

• UDPベース：パケットロス耐性が強く、弱ネットワークで良好
• 低遅延：0.5-2秒、RTMPより低い
• 暗号化：AES-128/256暗号化内蔵
• クロスリージョン対応：長距離で安定した遅延

欠点：

• 小さなエコシステム：第三者プラットフォームのサポートが限定的
• 専用サーバー必要：SRTサーバーソフトウェア（SRT Live Serverなど）

結論： 企業配信、クロスリージョン制作、不安定なネットワークに適しています。日常のYouTube配信にはRTMPを使用。

WebRTC：超低遅延リアルタイム通信

WebRTC（Web Real-Time Communication）はGoogleのブラウザリアルタイム通信プロトコル：

• 超低遅延：0.1-0.5秒、インタラクティブ配信の唯一の選択肢
• ブラウザネイティブ：Chrome、Firefox、Safari、Edge — プラグイン不要
• P2P可能：小規模配信はピアツーピアで、サーバーを節約

欠点：

• 複雑なサーバー：Janus、mediasoupなどのSFU（Selective Forwarding Unit）が必要
• エコシステムの断片化：実装が少し異なる
• 大量配信不向き：10,000人以上の視聴者には専門CDNが必要

結論： インタラクティブ配信、コラボ配信、ビデオ会議の第一選択。大量視聴にはHLS/FLV配信がより安定。

OBS配信設定

OBS Studioは最も人気のあるオープンソース配信ソフトウェア — 無料、クロスプラットフォーム、強力。

基本設定

1. 設定 → ストリーム：

   • サービス：「カスタム」
   • サーバー：プラットフォームのRTMP URL（例：YouTube：rtmp://a.rtmp.youtube.com/live2）
   • ストリームキー：プラットフォーム提供のキー

2. 設定 → 出力：

   • 出力モード：「詳細」
   • エンコーダ：NVIDIA NVENC H.264（NVIDIA GPU） > AMD HW H.264（AMD GPU） > x264（CPU）
   • レート制御：CBR（固定ビットレート、プラットフォーム推奨）
   • ビットレート：1080p 30fps → 4000 kbps（下記ビットレート表参照）
   • キーフレーム間隔：2（プラットフォームが2秒Iフレームを要求）
   • プリセット：P4（NVENC）またはveryfast（x264）
   • プロファイル：high
   • Bフレーム：2（NVENC）または0（x264、一部プラットフォームが要求）

3. 設定 → ビデオ：

   • 基本解像度：1920x1080（キャプチャ解像度）
   • 出力解像度：1920x1080または1280x720
   • ダウンスケールフィルター：Lanczos（高品質）
   • FPS：30または60

4. 設定 → オーディオ：

   • サンプリングレート：48 kHz
   • エンコーダ：AAC
   • ビットレート：128または160

配信ビットレート推奨

解像度/FPS	推奨ビットレート（CBR）	最小アップロード帯域幅
720p 30fps	1800-2500 kbps	4 Mbps
720p 60fps	2500-3500 kbps	5 Mbps
1080p 30fps	3500-5000 kbps	7 Mbps
1080p 60fps	4500-6000 kbps	9 Mbps
4K 30fps	8000-15000 kbps	20 Mbps
4K 60fps	12000-20000 kbps	28 Mbps

注意： 配信ビットレートはアップロード帯域幅の70%を超えないようにしてください。超えるとカクつきます。まずSpeedtestでアップロード帯域幅をテストしてください。

FFmpegコマンドライン配信

OBSを使いたくない？FFmpegで配信：

# MP4ファイルをRTMPサーバーにプッシュ
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -maxrate 4000k -bufsize 8000k -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -ar 48000 -f flv "rtmp://live-push.example.com/live/streamkey"

# 画面キャプチャをRTMPにプッシュ（Linux）
ffmpeg -f x11grab -framerate 30 -video_size 1920x1080 -i :0.0 -f alsa -i default -c:v libx264 -preset veryfast -b:v 4000k -g 60 -c:a aac -b:a 128k -f flv "rtmp://live-push.example.com/live/streamkey"

# SRTサーバーにプッシュ
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -c:a aac -b:a 128k -f mpegts "srt://server.example.com:10080?streamid=live/streamkey"

パラメータ解説：

• -re：リアルタイム速度で読み込み（配信に必要）
• -g 60：キーフレーム間隔60フレーム（30fpsで2秒）
• -pix_fmt yuv420p：最も互換性の高い色空間
• -f flv：RTMPはFLVコンテナを使用
• -f mpegts：SRTはMPEG-TSコンテナを使用

FFmpegの使い方について詳しくは、FFmpeg入門チュートリアル をご覧ください。

ストリーミングサーバーオプション

オプション1：Nginx-RTMP（軽量）

Nginx + RTMPモジュール、小規模配信とテストに適しています：

# nginx.conf
worker_processes auto;

events {
    worker_connections 1024;
}

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        
        application live {
            live on;
            record off;
            
            # HLSを有効化
            hls on;
            hls_path /var/www/hls;
            hls_fragment 2s;
            hls_playlist_length 10s;
        }
    }
}

http {
    server {
        listen 80;
        
        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            root /var/www;
            add_header Access-Control-Allow-Origin *;
        }
    }
}

rtmp://your-server/live/testにプッシュ、視聴者はhttp://your-server/hls/test.m3u8からプル。

詳細な構築は、Nginx-RTMPストリーミングサーバーチュートリアル をご覧ください。

オプション2：SRS（本番向け）

SRSはRTMP、HLS、HTTP-FLV、WebRTCをサポートするオープンソースストリーミングサーバー：

# Docker一括デプロイ
docker run --rm -p 1935:1935 -p 8080:8080 ossrs/srs:5

# プッシュ
ffmpeg -re -i input.mp4 -c copy -f flv rtmp://localhost:1935/live/test

# 再生
# RTMP: rtmp://localhost:1935/live/test
# HLS: http://localhost:8080/live/test.m3u8
# HTTP-FLV: http://localhost:8080/live/test.flv
# WebRTC: http://localhost:8080/players/whep.html?app=live&stream=test

SRSの利点：シンプルな設定、優れたパフォーマンス、包括的なプロトコルサポート。中大規模配信運営に適しています。

オプション3：クラウドサービス（最も便利）

サーバーをメンテナンスしたくない？クラウド配信サービスを使用：

• 海外：AWS IVS、Mux、Vimeo Live Streaming
• 国内：Tencent Cloud Live、Alibaba Cloud Live

利点：ワンストップサービス（プッシュ → トランスコード → 配信 → プレーヤー）。欠点：トラフィック課金、大規模では高額。

配信プロトコル比較

視聴者側のプルプロトコル選択も重要：

プロトコル	遅延	互換性	使用ケース
HLS	5-30秒	すべて	デフォルトフォールバック
LL-HLS	1-2秒	iOS 15+、Chrome	低遅延配信
HTTP-FLV	2-5秒	Chrome、Firefox	国内（Bilibili）で人気
WebRTC	0.1-0.5秒	モダンブラウザ	インタラクティブ配信

中国のプラットフォーム（Bilibili、Douyu、Huya）はHTTP-FLV配信を広く使用 — HLSより低遅延、WebRTCより互換性が高いです。海外プラットフォーム（YouTube、Twitch）は主にHLSとLL-HLSを使用。

HLSの仕組みについて詳しくは、M3U8ファイル完全ガイド をご覧ください。

配信最適化のヒント

1. エンコーダ選択

• NVIDIA GPUユーザー：NVENC H.264（GPUエンコード、CPU使用率低）
• AMD GPUユーザー：AMD AMF H.264
• Intel iGPUユーザー：Intel QuickSync H.264
• ハードウェアアクセラレーションなし：x264エンコーダ、速度/品質バランスにveryfastプリセット使用

2. 主要パラメータ

• キーフレーム間隔（GOPサイズ）：2秒（30fpsで60フレーム、60fpsで120）
• Bフレーム：NVENCは2、x264は0（一部プラットフォームが要求）
• プロファイル：high（互換性良い）またはmain（遅延低）
• レート制御：CBR（配信推奨）またはVBR（VOD用）

3. ネットワーク最適化

• 有線ネットワーク使用、WiFi回避
• アップロード帯域幅は配信ビットレートの1.5倍以上
• ルーターでQoSを有効化、配信トラフィックを優先
• バックグラウンドダウンロード、クラウド同期、その他の帯域幅使用アプリを閉じる

4. 品質向上

• ビットレートを低く設定しすぎない、ビットレート表参照
• yuv420pを使用、yuv444pは避ける（互換性）
• OBS「遅延」オプションを無効化（必要な場合を除く）
• Lanczosダウンスケールフィルター使用、Bilinearより鮮明

よくある問題

問題	原因	解決策
配信がカクつく	アップロード帯域幅不足	スピードテスト、ビットレートを帯域幅の70%以内に下げる
ビデオが灰色がかる	色空間エラー	-pix_fmt yuv420pを追加
高遅延	プラットフォームがHLSデフォルト	HTTP-FLVまたはLL-HLS使用
配信が切断	ネットワーク不安定	OBS「自動再接続」を有効化
ビデオカクつくがビットレート正常	CPU使用率高	NVENC使用、プリセットを下げる
音ズレ	エンコードバッファ不一致	オーディオサンプリングレート確認（48kHz）
キーフレーム警告	キーフレーム間隔エラー	2秒に設定

まとめ

三つの配信プロトコルはそれぞれ適所があります：RTMPはプラットフォームプッシュ標準、SRTはプロフェッショナルなクロスリージョン伝送、WebRTCは超低遅延インタラクション。日常のYouTube/Twitch配信にはRTMPで十分。プロフェッショナルなクロスリージョン制作にはSRTを検討。インタラクティブコラボにはWebRTCが不可欠。

OBSの主要パラメータを覚える：ハードウェアエンコーダ、CBRレート制御、2秒キーフレーム間隔、yuv420p色空間、推奨表のビットレート。ストリーミングサーバー：小規模はNginx-RTMP、本番はSRSまたはクラウドサービス。

クイックリファレンス：

• プロトコル選択：RTMP（プラットフォーム）、SRT（クロスリージョン）、WebRTC（インタラクティブ）
• ビットレート参考：1080p 30fps → 4000 kbps
• 主要パラメータ：ハードウェアエンコーダ + CBR + 2秒キーフレーム + yuv420p
• サーバー選択：テストはNginx-RTMP、本番はSRS

参考文献

• RTMP — Wikipedia
• SRTプロトコル公式サイト
• WebRTC — Wikipedia
• OBS Studio公式サイト
• SRS GitHub