ライブストリーミングにおけるIP映像伝送の最適化と運用：プロトコル、エンコーディング、およびネットワークインフラの統合的分析
本番12分で配信が止まった
会場の有線回線をスピードテストで確認した。エンコーダーを立ち上げ、テスト送出も問題なく通過した。本番開始のコマンドを叩いて、最初の7分は順調だった。
しかし12分後、映像がカクつき始め、まもなく完全に止まった。
スイッチのリンクランプはグリーンのままだ。エンコーダーのCPU使用率も余裕がある。「帯域は足りているはずだ」——そう確信しながら設定を見直すと、エンコーダーのビットレートが実測アップロード速度の88%に設定されていた。
その数字が問題の全てだった。
なぜ88%で現場が止まるのか
帯域の「理論値」と「実測値」はまず一致しない。会場のインターネット回線は常に、プレゼン資料の送受信、ゲスト用Wi-Fi、バックヤードPCのバックグラウンド更新といったトラフィックと競合している。この競合により、使用可能な実効帯域が計測値を大きく下回る瞬間が本番中に必ず訪れる。
「実測アップロード速度の50〜70%を上限に設定する」が、プロの鉄則だ（参考：IP映像伝送の最適化と運用に関する技術資料）。実測20Mbpsなら安全上限は10〜14Mbps。88%は綱渡りに見えて、実際には転落を待っている数字だ。
しかも、このスピードテストは、実際に使用するアップ先のサーバーに対してまでの経路で計測したものでだ。
さらに深い問題がある。RTMPプロトコルを使った場合、TCP（伝送制御プロトコル）の再送制御によって遅延が累積し、通常でも2〜5秒の映像遅延が発生する（出典：同上技術資料）。ネットワークが混雑すれば、この遅延は数十秒に達する。その間、映像は止まり、視聴者は離れる。
帯域は「道路の広さ」ではない
ここで一度、イメージを切り替えてほしい。
帯域は道路の広さだ。しかし、映像が壊れる本当の理由は「道路が狭い」ことではない。「荷物（パケット）が途中で消えたり、バラバラの順番で届いたりする」ことが原因だ。道路を広げても、荷物の紛失は防げない。
これが、帯域を増やしても映像が安定しない現場が出てくる理由だ。帯域不足と感じていた問題の多くは、プロトコル選択の誤りか、ビットレート設定のミスに起因している。構造を知れば、解決策は単純だ。
解決策はある——ただし、知らなければ何も変わらない
正しい設定手順は存在する。ただし、設定値を1つ変えればすぐ解決するほど単純でもない。プロトコルの特性、ビットレートの制御方式、そしてネットワーク内の優先制御を組み合わせた設計が必要だ。
必須なのが
層1：トラフィックの分離（VLAN）
層2：優先度設定（QoS）
層3：マルチキャスト管理（IGMP）
知識があれば本番前に防げる。知識がなければ本番中に気づく。その差が、現場のプロとしての信頼に直結する。
この記事で得られること
有料部では、現場で即使える設定と手順をステップバイステップで解説する。
- 帯域不足が起きる4つの構造的原因と、それぞれの診断方法
- プロトコル（RTMP・SRT・NDI・WebRTC・HLS）の帯域特性比較表と、用途別選定基準
- CBRとVBRの違いおよび、ライブ配信でVBRが配信停止を引き起こす理由（数値根拠付き）
- SRTのレイテンシを計算する方法——RTTとパケットロス率から最適値を導く手順（計算式・早見表付き）
- ネットワーク設計の3層構造：VLAN・QoS・IGMPを組み合わせた帯域確保の実装手順
- 本番120分前チェックリスト——判定基準と所要時間付き
- 症状別トラブルシューティング早見表——現場で迷わず切り分けられる一覧
ここから先が本題だ
この設定を知らないまま次の本番を迎えると、映像停止の復旧作業に追われる。その間、配信は止まる。
コメント