はかせ、ライブ配信が途切れて映像も荒れるよ。見るときは平気なのに、どうして？
この記事が扱うのは、自分が配信者として映像を送り、配信ソフトのドロップフレームが増える、ビットレートが保てない、配信先から切断される状態じゃ。視聴者として動画が止まる症状、双方向のビデオ会議、ゲーム画面そのもののフレームレート低下は別の意図じゃぞ。まずネットワークで落ちたのか、映像を作る処理で間に合わなかったのかを分けるんじゃ。
先に結論
はかせ、まずは何を確かめればいい？
配信ソフトの統計で、ネットワークドロップ、エンコード遅延、レンダリング遅延のどれが増えたかを見るのじゃ。同時に有線LANで非公開テストを行い、配信ビットレート、上り速度の最低値、CPU・GPU負荷、配信先サーバーを1つずつ変えれば、次の対処が決まるぞ。
配信者側の統計が正常で視聴者だけ止まるなら動画視聴のバッファリング診断、会議アプリで自分の映像だけ途切れるならビデオ会議の送受信切り分けへ進んでくれ。
| 配信ソフト・視聴側の結果 | 主な候補 | 次の行動 |
|---|---|---|
| ネットワークドロップが増え、送信ビットレートも落ちる | 上り回線、Wi-Fi、経路、配信先 | 有線化、同時送信停止、ビットレート低下 |
| エンコード遅延・スキップが増える | CPU・GPUのエンコード負荷 | 解像度・fps・プリセット・ゲーム負荷を下げる |
| レンダリング遅延が増える | GPU負荷、複雑なシーン・ソース | ゲームfps、シーン、フィルターを見直す |
| 配信ソフトは正常で、多くの視聴者が止まる | 配信サービス、変換品質、視聴条件 | 配信先の健康状態と出力設定を確認する |
| 1つの配信先だけ切れ、別配信先は安定 | 接続サーバーまたはサービス経路 | 推奨サーバー・公式障害情報を確認する |
| 複数配信先で有線でも切れる | 自宅機器または回線 | 時刻・上り・ロスを記録して回線へ相談する |
考えられる主な原因
なるほど。どうしてこんなことが起きるの？
ライブ配信は設定したビットレートを長時間送り続けるため、速度測定の最高値より継続性が大事じゃ。さらに映像を合成・圧縮する端末処理も必要ゆえ、回線とPCのどちらが詰まっても「コマ落ち」に見えるんじゃな。
ネットワークドロップと処理落ちは別の指標
OBS公式の配信接続トラブル解説では、Dropped Framesは配信先サーバーとの接続が不安定、または設定ビットレートを維持できないときに増えると説明されています。一方、エンコード過負荷は映像圧縮、レンダリング遅延はシーン描画の処理が間に合わない状態です。
配信ソフトによって統計項目の名前は異なります。ドロップ総数だけで決めず、ネットワーク、エンコード、レンダリングの分類と、増え始めた時刻を記録してください。
上り速度には余白が必要になる
速度測定で配信ビットレートと同じ値が一度出ても、揺らぎやほかの上り通信があれば維持できません。YouTube公式の配信準備ガイドでは、合計配信ビットレートが利用可能な上り帯域を超えないことに加え、20%の余裕を推奨しています。
これはYouTubeの案内であり、すべてのサービスの保証値ではありません。バックアップ配信、音声、複数同時配信も上りを使うため、利用するサービスの最新要件と合計送信量を確認します。
高画質・低遅延ほど余裕が小さくなる
解像度、フレームレート、コーデックに応じて推奨ビットレートは変わります。YouTube公式のライブエンコーダー設定は、解像度・fps・コーデック別の範囲を示し、本番前のテストと配信中のストリーム状態監視を案内しています。
視聴者とのやり取りを優先した低遅延モードは、回線の揺らぎを吸収できる時間が短くなる場合があります。高い数値を選ぶことを目的にせず、配信内容と回線が継続できる設定を選んでください。
順番に試したい対処法
わかった、ぼくも試してみる！どの順番でやればいい？
本番中に複数の設定を変えず、非公開または限定公開のテストで一つずつ比べるのじゃ。音声と実際に近い動きも入れ、静止画だけのテストで終えんことが大事じゃぞ。
1. 統計とログで落ちた種類を確認する
配信ソフトの統計を開き、ネットワークドロップ、エンコード遅延、レンダリング遅延、送信ビットレート、CPU・GPU使用率を確認してください。問題が始まった時刻と、ゲーム開始、シーン切替、バックアップ開始などの操作を対応させます。
ネットワークドロップなら接続の手順へ、エンコード・レンダリングなら端末負荷の手順へ進みます。両方増える場合は、一度に直そうとせず、有線化と軽い配信設定で基準を作ってください。
2. 上り速度を複数回測り合計ビットレートと比べる
配信に使う端末・接続方法で上り速度を複数回測り、最高値ではなく低い結果と変動幅を見てください。配信ビットレートには映像だけでなく音声、バックアップ、同時配信も足して考えます。
下り・上り・Ping・Jitterの意味を整理したい場合は速度測定結果の読み方を確認します。短時間の測定が良くても長時間配信で落ちるなら、配信ログの時系列を優先してください。
3. 有線LANにして上り通信を止める
配信端末をルーターへ有線接続し、クラウド同期、写真・動画バックアップ、ファイル送信、別端末の配信を一時停止してください。同じシーン・ビットレートでテストし、ネットワークドロップが変わるか確認します。
有線で直るならWi-Fi区間が候補です。Wi-Fiマーク自体が消える場合はWi-Fiが頻繁に切れるときの切り分けを優先します。有線でも短い欠損が疑われる場合はパケットロスの発生区間を調べる手順へ進んでください。
4. ビットレート・解像度・fpsを一段ずつ下げる
まず配信先の公式推奨範囲内でビットレートを一段下げ、ネットワークドロップが減るか確認してください。次に解像度または60fpsから30fpsのようにフレームレートを一つだけ下げ、エンコード・レンダリングの変化を見ます。
ビットレート低下でネットワークドロップだけ改善すれば上りの余裕、解像度・fps低下で処理遅延だけ改善すれば端末負荷が主な候補です。変更前後の設定画面と10〜15分の統計を保存します。
5. ゲーム負荷とシーンを軽くして比較する
エンコードまたはレンダリング遅延が増える場合は、ゲームのフレームレートを制限し、不要なブラウザソース、動画素材、フィルター、プレビューを一時的に減らしてください。同じ場面でGPU・CPU使用率と遅延を比べます。
OBS公式のエンコード性能トラブル解説も、ゲームのfps・画質、出力解像度・fps、複雑なシーンを順に軽くする方法を案内しています。ハードウェアエンコーダーの可否はGPUとOSで異なるため、対応表と公式ドライバーを確認します。
6. 配信先サーバーと公式状態を確認する
サービスが推奨接続先の自動選択や地域選択を提供している場合は、公式手順で別の近い接続先を試してください。1つの配信先だけ悪いか、別サービスへの短い非公開テストでも悪いかを比較します。
Pingが高いだけで欠損がない場合はPing値が高い区間の比較方法を確認します。業務・学校の回線やVPNを使う場合は、ポート開放や保護機能の解除を自己判断で行わず、配信先、時刻、ログを管理者へ渡してください。
改善しない場合の判断基準
ここまで試しても直らなかったら、次はどうすればいい？
有線・同時送信なし・公式推奨内の低めの設定でも、複数の配信先でネットワークドロップが増えるなら、回線事業者へ相談する段階じゃ。発生日時、上り速度の複数回結果、配信ビットレート、ロス率、有線比較、ルーター・ONU型番を伝えるのじゃぞ。
特定サービスだけならサービス窓口へ、エンコード・レンダリングだけなら配信ソフト、GPU、PCメーカーのサポートへ相談します。ログにはソフト版、OS、エンコーダー、解像度、fps、シーン切替時刻を含め、ストリームキーは必ず除いてください。
復旧確認は非公開テストを本番と同じ解像度、fps、音声、動きで15〜30分行います。配信ソフトのドロップが増えず、配信先の健康状態が正常で、別端末の視聴でも音ずれや停止がないことを確かめてください。
まとめ
はかせ、今日もひとつ分かったよ！忘れないように、大事なことをもう一度教えて！
ライブ配信のコマ落ちは、ネットワークドロップ、エンコード、レンダリングのどれかを先に見るのじゃ。有線化と上り通信停止で回線を比べ、ビットレート・解像度・fpsを一つずつ下げれば、通信と端末負荷を分けられるぞ。
最高の上り速度より、設定した送信量を本番時間ずっと保てる余裕が肝じゃ。統計、時刻、変更前後の設定を残し、秘密情報を除いたログで適切な窓口へ相談するのじゃぞ。
