すべてのプロダクト
Search

このプロダクト

    ApsaraVideo Live:高ストリーミング遅延の一般的な原因と解決策

    ドキュメントセンター

    ApsaraVideo Live:高ストリーミング遅延の一般的な原因と解決策

    最終更新日:Dec 19, 2024

    このトピックでは、Real-Time streaming (RTS) を使用する場合の、高いストリーミング遅延の一般的な原因と解決策について説明します。

    一般的な原因

    ライブストリーミングステージ

    発生原因

    ストリームingest

    • ソースストリームのキーフレーム間隔が大きすぎるか、ソースストリームにBフレームが含まれています。

    • ビデオキャプチャデバイスのCPUが過負荷になります。

    • Push SDK for Nativeが使用されていますが、SDKの設定は最適ではありません。

    ネットワーク伝送

    • ストリーム取り込みエンドは、劣悪なネットワーク条件を経験する。

    • 再生端は、劣悪なネットワーク条件を経験する。

    • Alibaba CloudのPOP (Point of presence) または内部接続のネットワーク状態が悪い場合。

    トランスコード

    • トランスコーディングは、ライブストリームのレイテンシを300 500ミリ秒増加させる可能性があります。

    • トランスコーディングがトリガーされると、余分なレイテンシが発生します。

    再生

    • ApsaraVideo Player SDK for Nativeが使用されていますが、SDKの設定は最適ではありません。

    • ApsaraVideo Player SDK for Webは、オーディオのみまたはビデオのみのストリームを再生するために使用されます。

    ストリームingest

    OBS Studioの推奨設定

    次の図は、ストリーム取り込みツールOBS Studioで推奨されるパラメーター設定を示しています。

    image.png

    vMixの推奨設定

    次の図は、ストリーム取り込みツールvMixで推奨されるパラメーター設定を示しています。

    image.png

    プッシュSDKの最適設定

    プッシュSDKで、グループオブピクチャ (GOP) サイズを1に設定し、他のパラメータのデフォルト設定を保持します。

    Android用プッシュSDK

    mAlivcLivePushConfig = new AlivcLivePushConfig();
mAlivcLivePushConfig.setVideoEncodeGop(AlivcVideoEncodeGopEnum.GOP_ONE);

    iOS用プッシュSDK

    AlivcLivePushConfig *pushConfig = [[AlivcLivePushConfig alloc] init];
pushConfig.videoEncodeGop = AlivcLivePushVideoEncodeGOP_1

    プッシュSDK for Web

    Push SDK For Webの場合、デフォルト設定が最適です。

    ネットワーク環境のストリーム取り込みの確認

    ストリームを取り込むときは、ストリーム取り込み側のネットワーク状態が良好であることを確認してください。 高いストリーミング遅延がネットワークの問題によるものかどうかわからない場合は、ネットワークを切り替えて同じデバイスを使用してストリームを再度取り込むことをお勧めします。 上記の操作を実行した後にレイテンシが正常に戻る場合、前のネットワークに問題がある可能性があります。

    ストリーム取り込みデバイスの負荷を確認する

    CPUやメモリの使用量が高すぎるなど、ストリーム取り込みデバイスが過負荷になっている場合、ビデオキャプチャとエンコード /デコードの効率が影響を受けます。 これは、ライブストリーミングのレイテンシにさらに影響します。 ストリーム取り込みデバイスが過負荷になっていることが確実な場合は、タイムリーにデバイスを交換してください。 ストリーム取り込みデバイスがオーバーロードされているかどうかわからない場合は、同じネットワーク環境とストリーム取り込み設定を維持し、検証に別のデバイスを使用することをお勧めします。

    再生

    ネイティブApsaraVideo Player SDKの最適設定

    RTSはWebRTC (Web Real-Time Communication) を使用してストリームを再生します。これにより、再生側でのパケット損失やジッタに対する優れた耐性が提供されます。 プレーヤーのバッファ制御をさらに最適化して、レイテンシを削減できます。

    • ApsaraVideo Player SDK V5.5.6.0以降を使用する場合、またはApsaraVideo Playerのデモを使用する場合は、最適な設定が既に適用されており、追加の調整は必要ありません。

    上記の設定を完了してもストリーミングの待ち時間が短縮されない場合は、SDKでさらに分析を実行します。

    • ストリーミング遅延の分析: ApsaraVideo Player SDK for AndroidまたはApsaraVideo Player SDK for iOSのログを有効にし、code=154ログのエンドツーエンドの遅延を照会します。 レイテンシはミリ秒単位で測定されます。 次のフィールドに注意してください。

      • gd (globalDelayMS): エンドツーエンドのレイテンシ。

      • td (transDelayMS): ストリーム取り込みレイテンシとCDN送信レイテンシ。 値が800ミリ秒を超える場合、ストリーム取り込みレイテンシまたはCDN送信レイテンシが大きくなりすぎます。

      • nd (ネットワーク遅延): CDN POPからプレーヤーまでのネットワーク遅延。 値が800ミリ秒を超える場合、ネットワークの問題が存在する可能性があります。

      • jd (jitterDelayMS): デジッタバッファの待ち時間。 値が800ミリ秒を超える場合、ネットワークの問題が存在する可能性があります。

      • ud: ユーザバッファの長さ。 ほとんどの場合、値は0です。 このフィールドは無視できます。

      • dd (decoder delay): プレーヤからの復号待ち時間。 値が800ミリ秒を超える場合、プレーヤーはデコードの問題を抱えている可能性があります。

      • rd (render delay): プレイヤーからのレンダリング待ち時間。 値が800ミリ秒を超える場合、プレーヤーはレンダリングの問題を抱えている可能性があります。

      • ut: このフィールドは無視できます。

    • 最初のフレーム遅延を分析する: SDKのcode=161ログで次のキーワードを照会します。

      st:0,init:1,sdns:0,rdns:2,sc:0,ced:12,sub:5,frsp:309,si:8,fp:13,ffc:5,ffo:416,sum:763

      sumの値が最初のフレームの待ち時間と大きく異なる場合、プレーヤーにはデコードとレンダリングの問題があります。 sumの値が最初のフレームの待ち時間に等しいか近い場合は、すべてのフィールドの値を分析します。 ced、frsp、ffcの値が通常よりも大きい場合、ネットワークの問題が存在します。

    ApsaraVideo Player SDK for Webの最適設定

    ApsaraVideo Player SDKをRTSベースのストリーミングに使用する場合、バッファはブラウザのデフォルトポリシーによって制御されます。 追加の設定は必要ありません。 ApsaraVideo Player SDK for Webを使用してストリームを再生するときにストリーミングの待ち時間または最初のフレームの待ち時間が長い場合は、Google Chromeを使用してchrome:// webrtc-internalsにアクセスし、プルされているWebRTCデータが異常かどうかを確認できます。

    image.png

    次のメトリックに注意してください。

    • inbound-rtp (kind=audio) およびinbound-rtp (kind=video): リアルタイムデータ受信状態およびフレーム復号状態。 framesDroppedの値が高い場合、またはframesDecoded/sの値が予想されるビットレートと異なる場合、デコードの問題が存在します。 ストリームの取り込みまたはトランスコード段階のトラブルシューティング。

    • 候補ペア: 接続ステータス。 currentRoundTripTimeの値が高い場合、またはinbound-rtpのpacketsLostの値が高い場合、ネットワークの問題が発生する可能性があります。

    オーディオのみまたはビデオのみのストリームを再生するときに発生するレイテンシ

    デフォルトでは、Alibaba Cloudは、オーディオのみまたはビデオのみのストリームを再生するときに、完全なオーディオおよびビデオデータを取得するまで5秒間待機します。 その結果、5秒の黒画面が表示される。 ストリーミングURLの末尾に @ subvideo=noまたは @ subaudio=noを追加することで、ビデオまたはオーディオのサブスクリプションを手動で解除できます。

    • ソースストリームがストリーミングURLがartc:// example.aliyundoc.com/app/stream?auth_key={Access token} のビデオのみのストリームである場合、ストリーミングURLをartc:// example.aliyundoc.com/app/stream?auth_key={Access token}@ subaudio=noに変更します。

    • ソースストリームがストリーミングURLがartc:// example.aliyundoc.com/app/stream?auth_key={Access token} のオーディオのみのストリームである場合、ストリーミングURLをartc:// example.aliyundoc.com/app/stream?auth_key={Access token}@ subvideo=noに変更します。

    ネットワーク環境の再生

    ストリームを再生するときは、再生側のネットワーク状態が良好であることを確認してください。 ネットワークが不安定な場合、ApsaraVideo Player SDKはローカルバッファのサイズを自動的に拡大し、よりスムーズな再生を実現します。 その結果、レイテンシが増大する。

    再生

    ライブストリーミング中にトランスコーディングを実行すると、ストリーミングの遅延が300〜500ミリ秒増加する可能性があります。 RTSは、次のタイプのトランスコーディングを提供します。

    • HTML5自動トランスコード: このタイプのトランスコードは、取り込まれたRTMPストリームがwebページで再生されるときに使用されます。 自動トランスコードによる遅延は避けられません。 ただし、それは比較的低く、全体的なストリーミング遅延に大きな影響を与えません。

    • カスタムトランスコード: ライブストリームに複数の仕様のトランスコードテンプレートを設定した場合、トランスコードされたストリームを再生すると、最大2つの部分からレイテンシが発生します。

      • トランスコード処理からの遅延: 遅延のこの部分は500ミリ秒300と推定され、回避できません。

      • トランスコード開始からの遅延: トランスコードテンプレートでトリガーされたトランスコードが有効になっている場合、ユーザーが初めてストリームをプルしたときにのみトランスコードが開始されます。 これにより、初めてストリームをプルするユーザーに追加の遅延が発生します。 待ち時間のこの部分は、200ミリ秒と推定される。

        説明

        トリガートランスコードは、トランスコードテンプレートの作成時に設定できるオプション機能です。 ストリームのトリガーコード変換を無効にするには、トリガーコード変換を無効にする新しいコード変換テンプレートを作成する必要があります。 次に、ストリームを再取り込みし、ストリーミング遅延を再度テストします。

    お問い合わせ

    前述のトラブルシューティング手順を実行しても遅延が減少しない場合は、チケットを起票してください。 通信効率を向上させるには、次の情報をチケットに追加します。

    • テストに使用した取り込みURLとストリーミングURL。

    • ストリームの取り込みと再生ツール。 例: ストリーム取り込み用のOBS Studioおよび再生用のApsaraVideo Player SDK for Web。

    • 前述のトラブルシューティング手順で説明したその他の有用な情報。