製品概要
サブ製品の説明
基本概念
製品機能
ユースケース
製品の優位性
使用制限
ビデオラグの最適化（V2）
原因1：プッシュフレームレートが低すぎる
キャスターのスマートフォンのパフォーマンスが低い場合、またはバックグラウンドでCPU使用率の高いプログラムを実行中の場合は、ビデオのフレームレートを著しく低下させてしまうことがあります。通常、スムーズな表示を保証するためには、FPSが毎秒15フレーム以上のビデオストリームが必要です。FPSが10フレーム未満の場合は、フレームレートが低すぎると判断できます。このことによって、すべての視聴者の視聴体験に大幅なラグが生じます。もちろん、静的画面またはPPT再生等のケースのように、キャスター側の画面自体の変化が非常に少ない場合は、この原因の影響を受けません。
原因2: アップロードの渋滞
プッシュ時に、キャスターのスマートフォンでは、オーディオおよびビデオデータが継続的に生成されますが、スマートフォンのアップロードスピードが遅すぎると、生成されたオーディオおよびビデオデータがキャスターのスマートフォンに蓄積され送信できなくなります。アップロード時の渋滞によって、すべての視聴者の視聴体験に大幅なラグが生じます。
中国本土キャリアで提供されるブロードバンドパッケージでは、ダウンロード速度は10Mbps、20Mbps、さらには100Mbps、200Mbpsに達していますが、アップロード速度は制限されています。多くの小都市での最大上り速度は512Kbpsです（つまり、毎秒、64KBを上限とするデータしかアップロードできません）。
Wi-Fiは、IEEE 802.11が規定する搬送波感知多重アクセス／衝突回避方式（CSMA/CA）に準拠します。つまり、1つのWi-Fiホットスポットは1台のスマートフォンとしか同時に通信できず、スマートフォンはホットスポットと通信する前にまず通信できるかどうかを確認または照会する必要があるため、1つのWi-Fiホットスポットを使用する人数が多いほど速度が遅くなります。またWi-Fi信号は建物の壁によって著しく遮断されますが、通常、中国の平均的な家庭では内装時にWi-Fiルーターの位置と各部屋の信号の強度の問題をほとんど考慮していないため、キャスター自身もライブストリーミングを実行する部屋が屋内のルーターからいくつの壁を隔てているか、よくわかっていない可能性があります。
原因3： 下り接続の不良
例えばCSSストリームのビットレートが2Mbps、つまり毎秒2Mビットのデータストリームのダウンロードで、視聴者の帯域幅が不足している場合のように、視聴者のダウンロード帯域幅が不足またはネットワーク状態が不安定なときは、視聴者側の再生体験に著しいラグが生じることとなります。下り接続の不良は現在のネットワーク環境下の視聴者にのみ影響を及ぼします。
SDKステータスプロンプト情報を確認
Tencent Cloud MLVB SDKを使用してプッシュする場合、このSDKは2秒ごとに内部の各ステータスパラメータをフィードバックするステータスフィードバックメカニズムを提供します。 V2TXLivePusherObserverで監視装置を登録し、その後、コールバック関数onStatisticsUpdateを介して、これらのステータスを取得することができます。 V2TXLivePusherStatisticsの関連ステータスの説明は次のとおりです。
プッシュ状態 | 定義と説明 |
appCpu | 現在のAppのCPU使用率（％） |
systemCpu | 現在のシステムのCPU使用率（％） |
width | ビデオの幅 |
height | 画像高さ |
fps | フレームレート （fps） |
audioBitrate | オーディオビットレート（Kbps） |
videoBitrate | ビデオビットレート（Kbps） |
フレームレートが低すぎる問題を解決
1. フレームレートが低すぎるかどうかの判断
MLVB SDKのV2TXLivePusherObserverのonStatisticsUpdate コールバックにおけるV2TXLivePusherStatistics.fpsのステータスデータを介して、現在、プッシュするビデオフレームレートを取得することができます。通常、毎秒15フレーム以上のビデオストリームを使用することで、スムーズな視聴が保証されます。標準的なプッシュのFPSが10フレーム以下の場合、視聴者は明らかに画面にラグが発生したように感じます。
2. 的を絞った最適化計画
2.1 appCpuとsystemCpuのサイズの観察
MLVB SDKのV2TXLivePusherObserverのonStatisticsUpdate コールバックにおけるV2TXLivePusherStatistics.appCpuとV2TXLivePusherStatistics.systemCpuのステータスデータを介して、現在のプッシュSDKのCPU使用状況と現在のシステムのCPU使用状況を取得することができます。現在のシステム全体的のCPU使用率が80%を超える場合は、ビデオのキャプチャとコーディングがいずれも影響を受け、正常に機能することができません。CPU使用率が100%に達した場合は、キャスター自体に極めて大きなラグが発生しているため、視聴者はスムーズな視聴体験ができなくなります。
2.2 CPUを消費しているものを確認
ライブストリーミングAppでCPUを使用するのは、プッシュSDKだけではなく、弾幕、キラキラエフェクト、テキストメッセージのやり取りなども一定量のCPUを消費する可能性があり、これらはいずれも避けようがありません。プッシュSDKのCPU利用状況を測定したいだけの場合は、当社のツールキットDEMOを使用して観察と評価を行うことができます。
2.3 高解像度を盲目的に追及しない
ビデオ解像度が高すぎても、必ずしも鮮明な画質が得られるとは限りません。まず高解像度の効果を発揮させるためには、高ビットレートと整合させる必要があります。多くの場合、低ビットレート高解像度の明瞭度は、高ビットレート低解像度には及びません。次に、約5インチの平均的なスマートフォン画面で1280 x 720の解像度にメリットを見出すことはできません。960 x 540の解像度との違いを明確に感じ得るのは、PCのフルスクリーンで表示した場合だけです。しかし、高解像度は、SDKのCPU使用率を著しく上昇させるため、通常、MLVB SDKにおけるV2TXLivePusherのsetVideoQualityを使用してHDレベルに設定してください。高解像度を盲目的に追跡しても意図する目標に到達しない場合があります。
アップロードの渋滞問題の解決
統計によると、ビデオクラウド顧客グループのライブストリーミングルームにおけるラグトラブルの80%以上は、キャスターのアップロードの渋滞が原因です。
1. キャスターへの自発的な促し
解像度が重要なシーンでは、「現在のネットワーク品質が非常に不良であるため、ルーターの近くに移動し、Wi-Fi信号を壁で隔てないことをお勧めする」のが最良の選択であるというプロンプトを、適切なUIを介してキャスターに表示します。
MLVB SDKのプッシュ機能ドキュメントにはイベント処理の説明が含まれており、これを利用して実行することができます。推奨されるアプローチは次のとおりです。Appが短時間に複数のMLVB SDKのV2TXLIVE_WARNING_NETWORK_BUSYイベントを継続的に受信する場合は、現在のネットワーク品質に注意を払うようキャスターのネットワークにプロンプトを表示します。これは、キャスターがビデオのパフォーマンスから上りの渋滞を認識できず、視聴者の通知またはAppの通知を受けて初めて認識できるためです。
2. 合理的なエンコードの設定
ユースケース | resolution | resolutionMode |
ショーライブストリーミング | V2TXLiveVideoResolution960x540 V2TXLiveVideoResolution1280x720 | 横画面または縦画面 |
モバイルライブストリーミング | V2TXLiveVideoResolution1280x720 | 横画面または縦画面 |
マイク接続（メイン画面） | V2TXLiveVideoResolution640x360 | 横画面または縦画面 |
マイク接続（小画面） | V2TXLiveVideoResolution480x360 | 横画面または縦画面 |
ブルーレイライブストリーミング | V2TXLiveVideoResolution1920x1080 | 横画面または縦画面 |
再生端末の最適化
1. ラグ&ディレイ
上図に示すとおり、下りネットワークが不安定である場合、または下り帯域幅が滞る場合は、いずれも再生中に飢餓時間が出現します（App はこの期間中は再生可能なオーディオおよびビデオデータを取得できません）。視聴端末でのビデオラグを最小限に抑制し、この「飢餓時間」を無事にやり過ごすためには、Appにできるだけ多くのビデオデータをキャッシュさせる必要があります。しかし、Appにオーディオおよびビデオデータを多くキャッシュさせ過ぎると、新たな問題 高ディレイが生じるおそれがあります。これはインタラクティブ性の要件が高いシナリオにとって非常に悪いニュースです。またディレイが修正、制御されない場合、ラグによって引き起こされたディレイには累積効果があり、再生時間が長くなればなるほど、ディレイも大きくなります。ディレイの修正が適切に行われるかどうかがプレーヤーの優劣を判断する重要な指標となります。したがって、ディレイとスムーズさはバランスが重要であり、低ディレイを強調しすぎると、軽微なネットワークの不安定性を引き起こし、顕著な再生端末のラグを発生させてしまいます。反対に、スムーズさを強調しすぎると、多くのディレイ（典型的なケースでは、HLS（m3u8）が20秒から30秒のディレイの発生により、スムーズな再生体験を実現します）が発生してしまうことになります。
2. 的を絞った最適化計画
マルチストリーム制御処理の知識が充分になくとも、より良い再生体験を最適化できるようにするため、Tencent Cloud MLVB SDKは、複数バージョンでの改良を経て、一連の自動調整技術が最適化されており、それをベースとして、3種類の優良な遅延制御スキームがリリースされています。V2TXLivePlayerのsetCacheParams で設定することができます。
自動モード：主なシーンが確定していない場合は、このモードを直接選択できます。
説明：
このモードでは、充分にスムーズな状況で視聴者とキャスター間の遅延を最小限に抑えることを保証し、優れたインタラクティブ体験を確保するために、プレーヤーは現在のネットワーク状況に応じて、遅延を自動的に調整します（デフォルトでは、プレーヤーは1秒～5秒の間隔で遅延の大きさを自動的に調整しますが、setCacheParamsを介してデフォルト値を変更することもできます）。
超高速モード：ショーのライブストリーミングなどのインタラクティブ性が高く、ディレイ要件が厳しいシーンに最適です。
説明：
超高速モードの設定方法は、minTime = maxTime = 1sであり、自動モードと超高速モードの違いはmaxTimeがやや異なるだけです（超高速モードのmaxTimeは通常やや低く、自動モードのmaxTimeはやや高くなっています）。この柔軟性は主にSDK内部の自動調節技術によるもので、ラグの原因とならずにディレイサイズを自動的に修正できます。maxTimeは調節速度を反映し、maxTimeの値が大きいほど、調節速度も保守的となり、ラグの確率も低くなります。
スムーズモード：主にゲームライブストリーミングなどの高ビットレートHDライブストリーミングシーンに最適です。
説明：
このモードでプレーヤーが採用する処理ポリシーはAdobe Flashカーネルのキャッシュアウトポリシーと同じです。ビデオにラグが出現すると、バッファが一杯になるまでloading状態となり、抑止できないネットワークの不安定さが次に生じるまでplaying状態となります。デフォルトではバッファサイズは5秒ですが、setCacheParamsを介して変更できます。
ディレイ要件が高くないシーンでは、この一見シンプルなモードの方が信頼性は高くなります。このモードが本質的にわずかなディレイを犠牲にしてラグ率を低下させるためです。
フィードバック