よりスマートで安全な Video API

リアルタイム・ビデオは難しいものです。参加者は、世界のさまざまな場所で、さまざまなデバイス、さまざまなネットワークから参加する。モバイル・デバイスがWi-Fiからセルラー・データ（5Gから4Gなど）に切り替わったり、企業のファイアウォールが特定のUDPパスをブロックしたり、ローエンドのラップトップがCPU負荷で苦労したりと、通話中に状況が変化することもある。

Vonage Video APIは、変化する状況に継続的にセッションを適応させるための、スマートで補完的な機能のセットを中心に構築されており、これらの機能は3つのレイヤーに編成され、それぞれがスタックの異なるレベルに対応しています：

• トポロジー・レベル:セッションのインフラストラクチャ、ルーティングの最適化、サーバーのライフサイクル。これらはセッションのすべての参加者に影響し、ストリームごとの設定は不要です。
• ピアコネクションレベル:個々のクライアントがメディアルータと接続し、ネゴシエートする方法。これらの設定はクライアントごとに適用されますが、同じエンドユーザーデバイス内に複数のクライアントが存在する場合があります。
• ストリームレベル:ストリームごとの品質ノブ：コーデック、解像度、ビットレートなど。これらは、各パブリッシャーとサブスクライバーごとに個別に調整できます。

ビルディング・ブロック

機能は3つの同心円状のレイヤーに編成されている。外側のレイヤーはすべての参加者に影響し、内側のレイヤーはストリームごとに調整できる。

╔══════════════════════════════════════════════════════════════════════╗
║  TOPOLOGY LAYER                                                      ║
║  Routed vs. Relayed · Adaptive media routing · Media Mesh            ║
║  Session migration                                                   ║
║  ┌──────────────────────────────────────────────────────────────┐    ║
║  │  PEER-CONNECTION LAYER                                       │    ║
║  │  Single peer connection (SPC) · Codec negotiation            │    ║
║  │  ┌────────────────────────────────────────────────────┐      │    ║
║  │  │  STREAM LAYER                                      │      │    ║
║  │  │  Scalable video · Bitrate presets                  │      │    ║
║  │  │  Publisher resolution/frame rate                   │      │    ║
║  │  │  Subscriber preferred resolution/frame rate        │      │    ║
║  │  │  Audio fallback · FEC / NACK / DTX                 │      │    ║
║  │  └────────────────────────────────────────────────────┘      │    ║
║  └──────────────────────────────────────────────────────────────┘    ║
║  Monitoring: client observability · sender-side stats · MOS          ║
╚══════════════════════════════════════════════════════════════════════╝

モニタリング・レイヤーは、この3つすべてにまたがり、あらゆるレベルで品質を可視化する。

アンダー・フード：WebRTCスタック

信頼性保証の多くは、明示的なAPIコールを必要としないWebRTCスタックに組み込まれた機能に由来します。これらを理解することで、品質の挙動を推論し、より上位のAPIをより効果的に使用することができます。

輻輳制御とレート適応

WebRTCの実装では、デフォルトでGoogle Congestion Control（GCC）が使用されます。GCCは、利用可能な帯域幅を継続的にプローブし、現在のボトルネックを推定し、エンコーダに目標ビットレートを上下させるよう信号を送ります。これは、一時的な輻輳によってセッションを維持するための主要なメカニズムです。ビットレートに影響する Vonage Video API の設定はすべて、GCC として機能します。 天井 そしてGCCは、その上限以下に動的に適応し続ける。

前方誤り訂正（FEC）

オーディオストリームは、デフォルトで Opus FEC をネゴシエートしようとします。Opusコーデックは、各オーディオフレームの低品質コピーを 次のページ フレームを受信する。最初のフレームが転送中に失われた場合、レシーバーは次のパケットのコピーからフレームを再構築する。これは、混雑したWi-Fiや携帯電話ネットワークで見られるようなランダムなパケットロスに特に効果的です。

ビデオについては、すべてのコーデックがRTP RED FECをサポートしている。FECはアプリケーションに対して透過的であり、メディアストリームに冗長性を追加し、再送信を必要とすることなく、レシーバーが失われたパケットや破損したパケットを回復できるようにします。詳細については RFC 8854.

NACKとRTX（再送信）

ビデオパケットが失われると、受信側は再送を要求するためにNACK（Negative ACK）を送信する。NACK/RTXはラウンドトリップタイムに比例したレイテンシを追加する（通常50～200ms）。

不連続伝送（DTX）

Opus DTX は、マイクの無音状態を検出し、無音状態の間はオーディオパケットの送信を停止し、オーディオ帯域幅をほぼゼロにします。DTX は enableDtx パブリッシャーを初期化する際に、SDK の設定を選択します。

DTLS-SRTPとセキュアリアルタイムトランスポートプロトコル

すべてのメディアはデフォルトで DTLS-SRTP を使用して暗号化されます。暗号化キーのネゴシエーションは、メディアが流れる前に、WebRTCハンドシェイクの一部として行われます。セキュリティを強化するために、AES-256 アドオン機能 は256ビット暗号化を提供する。これらのトランスポートレイヤー暗号化方式（DTLS-SRTPとAES-256）は、オプションのエンドツーエンド暗号化（E2EE）機能とともに動作する。詳細は エンド・ツー・エンド暗号化ガイド をご覧ください。

ICEとTURN

インタラクティブ接続確立（ICE）は、エンドポイント間の複数のパス（直接UDP、STUN-reflexive、TURNリレー）を試行し、最適なパスを選択します。通話中に最適なパスが変更された場合（モバイルデバイスがネットワークを切り替えた場合によくある）、ICEは通話を切断することなく、再起動して新しいパスを見つけることができます。制限のあるファイアウォールを通過するセッションについては 設定可能なTURNサーバーガイド そして 制限付きネットワークガイド.

トポロジーレベルの最適化

トポロジーレベルの特徴は、以下を決定する。 インフラ を経由してメディアが流れる。それらはセッションを作成するとき、あるいはセッションに接続するときに設定され、すべての参加者に等しく影響する。トポロジーを正しくすることは、他のすべての土台となる。

メディア・モードルーティング vs. リレー

最も基本的なトポロジーの決定は メディアモード.

• 中継セッション:ファイアウォールによって直接の経路が遮断された場合は、TURNリレーにフォールバックする。リレーされたセッションは、少人数のグループにとってはレイテンシーが低いですが、スケーラブルビデオ、加入者音声フォールバック、シングルピア接続、送信者側の統計は使用できません。
• ルーティング・セッション:メディアはVonage Video Media Routerを通ります。これにより、スケーラブル・ビデオ、加入者音声フォールバック、シングルピア接続 (SPC)、送信者側統計、ライブストリーミング放送、アーカイブ、SIP相互接続など、スマート機能スタックの全機能がアンロックされます。

3人以上の参加者がいるセッションでは、常にルーティングセッションを使用してください。セッションの セッションガイドの作成.

アダプティブ・メディア・ルーティング

ルーティングされたセッション（SDK v2.24.7以降（Web版）、v2.27.0以降（ネイティブ版））では、プラットフォームは自動的に アダプティブ・メディア・ルーティング を使用して、参加者間のトラフィックを最適化します。パブリッシャーに加入者が1人しかおらず、ルーティング専用機能（アーカイブ、ライブストリーミング、SIPなど）がアクティブでない場合、メディアはパブリッシャーと加入者間で直接ルーティングされ、前もってリレーセッションを宣言する必要はありません。パブリッシャーが複数の購読者を獲得したり、ルーティング専用機能がアクティブになると、メディア・ルーターがシームレスにルーティングを引き継ぎます。例えば、会話型のユースケース（すべての参加者が同時にパブリッシュとサブスクライブを行う）で、ルーティング専用の機能がない場合、3人目の参加者が参加するとすぐに、セッションはシームレスにメディア・ルーターに移動します。

つまり、実質的に、すべてのケースでルーティングされたセッションを宣言することができ、1:1の通話では、ほぼ中継に近いレイテンシーを得ることができる。アダプティブ・メディア・ルーティングはデフォルトで有効になっており、設定は不要です。詳細は セッションガイドの作成.

メディア・メッシュ

このプラットフォームは メディア・メッシュ をクリックすると、各参加者が最寄りのメディア・ルーター・データセンターに自動的に接続されます。 これ 利用可能なすべてのデータセンターのリスト）。地理的に分散したセッション（例えば、ニューヨーク、フランクフルト、シドニーに参加者がいる場合）では、Media Meshは、各クライアントが単一の、潜在的に遠いデータセンターを経由するのではなく、最も近い地域のサーバーを経由してメディアをルーティングするようにします。その結果、特に大規模な国際セッションにおいて、すべての参加者のレイテンシーが低減し、品質が向上します。

メディアメッシュはデフォルトで有効になっており、設定は不要です。メディアのルーティング先をもっとコントロールしたい場合は、2つのパーソナライズオプションがあります：

• ロケーション・ヒント（ベスト・エフォート）：希望するシグナリング・データセ ンターをヒントとして提供できる。プラットフォームは可能な限り要求されたロケーションを使おうとするが、保証はされず、可用性、キャパシティ、その他の運用上の考慮に基づいて別のデータセンターにフォールバックする可能性がある。を参照してください。 セッションガイドの作成 をご覧ください。

• リージョナル・メディア・ゾーン（強制）：メディア・ルーティングを特定の地域内 に維持する必要がある場合（データ・レジデンシーまたはコンプライアンス要件 のため）、リージョナル・メディア・ゾーンを設定する。この設定は強制です。シグナリングとメディアは、自動的に最も近いデータセンターを選択するのではなく、選択したゾーンを経由してルーティングされます。その他のドキュメントは 地域メディアゾーンガイド.

セッション移行

何をするのか？ 計画されたサーバーのローテーションが発生すると、セッションの参加者全員を切断することなく、新しいMedia Routerサーバーにトランスペアレントに転送します。アプリケーション側の処理は不要です（つまり、アプリケーションは独自の転送/再接続ロジックを実装する必要はなく、プラットフォームが代わりに実行します）。

なぜそれが重要なのか： クラウド・インフラストラクチャは決して固定されたものではない。サーバーはパッチを当てられ、スケールイン、スケールアウトされ、交換される。セッション・マイグレーションがなければ、サーバーが入れ替わるたびに参加者全員が切断と再接続を余儀なくされ、セッションが8時間を超えると混乱が生じます。セッションマイグレーションが有効な場合（SDK v2.30.0+）、移行は不可視です。ストリームは継続され、再接続イベントは発生せず、既存のオーディオ/ビデオは中断されません。

それでも再スタートが必要なもの 録画（アーカイブ）、ライブ ストリーミング放送、およびエクスペリエンス コンポーザー インスタンスは、セッションが移行すると終了するため、セッション通知コールバックを介して再起動する必要があります。 自動アーカイブ 自動的に再起動する。

それを可能にする方法： パス sessionMigration: true を各クライアントのセッション初期化オプションに追加します。デフォルトでは、これは false.を参照のこと。 サーバーローテーションとセッション移行ガイド SDK固有の完全な構文、手動でのトリガー、セッション通知コールバックの処理の詳細については、こちらを参照してください。

自動再接続

何をするのか？ クライアントが予期せずセッションへの接続を失った場合、SDKはアプリケーションコードを必要とせずに自動的に再接続を試みます。

なぜそれが重要なのか： 自動再接続がなければ、短時間のネットワーク障害により、ユーザーは手動でセッションに再参加しなければならない。自動再接続では、SDKは透過的に回復を処理します。サブスクライブしていたストリームは一時停止し、接続が回復すると自動的に再開します。

どのように機能するのか： 設定は必要ない。接続が切断され、クライアントが再接続を試みる場合：

• Session オブジェクトは sessionReconnecting イベントを開催する。
• 接続が回復すると、Sessionオブジェクトは sessionReconnected イベントを開催する。
• 接続が回復できない場合、クライアントはセッションを切断し、次のようになる。 sessionDisconnected イベントが発生する。

アプリケーションはオプションでこれらのイベントをリッスンし、ユーザーにステータス・インジケータを表示することができる：

session.on({
  sessionReconnecting: function() {
    // Display a "reconnecting..." indicator
  },
  sessionReconnected: function() {
    // Hide the indicator
  },
  sessionDisconnected: function() {
    // Handle permanent disconnection
  }
});

一時的に接続が切断されている間に送信されたシグナルはキューに入れられ、接続が回復すると配信される。次の セッションガイドに参加する を参照してください。

ピア・コネクション・レベルの戦略

ピア・コネクション・レベルの機能は、クライアントのメディア・ルータへの WebRTC 接続がどのように構成され、どのコーデックをネゴシエートするかを管理します。これらの設定は、クライアントごとに一度だけ適用され（ストリームごとには適用されない）、リソースの消費と互換性に広く影響します。

シングルピア接続（SPC）

何をするのか？ クライアントのすべてのサブスクライバー・ストリームを、ストリームごとに1つの接続ではなく、メディア・ルーターへの1つのWebRTCピア接続にバンドルします。

なぜそれが重要なのか： ピア接続が1つ増えるごとに、ICE候補の分離、DTLSハンドシェイク、OSレベルのソケット状態などのオーバーヘッドが追加される。10個のストリームをサブスクライブするモバイル・デバイスでは、10個のピア接続がデバイスにストレスを与え、大きな電力を消費します。SPCはこれを1つの接続に減らし、リソース消費を削減し、ネイティブ・モバイル・クライアントでより大きなセッションを可能にします。

さらなるメリット - レートコントロール： 単一の接続で、WebRTC輻輳コントローラは以下を見ます。 すべて 入ってくるストリームを1つのバンドルとして扱うことで、より適切な情報に基 づいてレート適応を決定することができる。マルチ接続モデルでは、各接続が独立してプローブと適応を行うため、発振が発生し たり、帯域幅共有が最適でなくなったりする可能性がある。

それを可能にする方法： SPCはデフォルトでオフ。設定 singlePeerConnection: true を指定します。ウェブSDKの場合は、このプロパティを OT.initSession() オプションオブジェクトを使用します。他のSDKの場合：

• アンドロイドだ： Session.Builder.setSinglePeerConnection(true)
• iOS： OTSessionSettings.singlePeerConnection = YES
• ウィンドウズ SinglePeerConnection プロパティ Session.Builder
• Linux/macOS： otc_session_settings_set_single_peer_connection()
• リアクト・ネイティブ enableSinglePeerConnection OTSessionで options プロップ

参照 セッションガイドの作成 をご覧ください。

いつ使うか： 特にモバイル・プラットフォームでは、ルーティングされたセッションに一握りの加入者しかいない場合は、常にSPCを有効にしてください。ストリーム数が増えれば増えるほど、そのメリットは大きくなります。

コーデック選択

何をするのか？ 各パブリッシャーとサブスクライバーのペア間で使用されるビデオコーデックを選択する。

なぜそれが重要なのか： コーデックの選択は、与えられたビットレートでの品質、CPU使用率、ハードウェアアクセラレーションの可用性、スケーラブルビデオとの互換性に影響する。VP8は最も安全なデフォルトであり、普遍的にサポートされ、ほとんどのプラットフォームでハードウェアアクセラレーションが可能で、スケーラブルビデオとの互換性がある。VP9は、同じビットレートでより良い品質を提供するが、CPUコストが高くなる。H.264は、iOSと一部のAndroidデバイスでハードウェア・エンコーダの恩恵を受け、バッテリーの消耗を抑えることができるが、スケーラブル・ビデオには対応していない。

自動的に機能する仕組み Vonageプラットフォームは、パブリッシャーとサブスクライバーのペアごとにコーデックをネゴシエートし、プロジェクトレベルの優先順位を尊重する一方、優先コーデックが両方のエンドポイントでサポートされていない場合はVP8にフォールバックします。

いつ介入すべきか： 参照 ビデオコーデックガイド 完全な決定基準については VP9スケーラブルビデオガイド VP9固有の挙動については SDKコーデック環境設定API をオーバーライドする。

エンドツーエンド暗号化（E2EE）

何をするのか？ クライアントでメディアペイロードを暗号化し、メディアルーター全体で暗号化 されたままにして、同じセッションの他の参加者のみが復号化できるようにす る。これは、標準のDTLS-SRTPトランスポート暗号化の上に、追加の暗号化レイヤーを提供する。

なぜそれが重要なのか： 標準的なルーティングセッションにおいて、メディアルータは暗号化されていないメディアにアクセスすることができます（アーカイブ、トランスコーディング、スケーラブルなビデオレイヤの選択などの機能に必要です）。E2EEは、メディア・ルーターがメディア・コンテンツにアクセスすることを防ぎます。これは、厳格なデータ・プライバシーをエンドツーエンドで維持する必要があるユースケースに必要です。

重要な制約： E2EE を有効にすると、メディア ルーターでのメディア デコードを必要とする機能（アーカイブ、ライブ ストリーミング放送、エクスペリエンス コンポーザー、オーディオ コネクター、および SIP 相互接続）は使用できなくなります。E2EE を有効にする前に、これらの制限を考慮してください。

それを可能にする方法： E2EEはアドオン機能で、Vonage Videoアカウントを有効にする必要があります。有効にしたら e2ee: true を使用し、クライアントでセッションを初期化する際に暗号化シークレットを設定します：

vonage.video.createSession({ mediaMode: "routed", e2ee: true });

セッションの参加者全員が同じ暗号化シークレットを使わなければ、理解しやすいメディアを受信することはできない。シークレットは、セッションが接続されると、その場で変更することができます。暗号化シークレットは エンド・ツー・エンド暗号化ガイド をご覧ください。

河川レベルの品質管理

ストリームレベルの機能は、最もきめ細かいノブである。各パブリッシャーとサブスクライバーに独立して設定でき、多くはコールの途中で動的に変更できる。これは、アプリケーションが品質管理に積極的に参加するレイヤーである。

スケーラブルなビデオ

何をするのか？ パブリッシャーは、同じストリームの複数の空間レイヤーと時間レイヤーをエンコードする。各サブスクライバーは、利用可能な帯域幅と表示要件に合ったレイヤーを受信する。パブリッシャーが重複したフル解像度ストリームを送信することはない。

なぜそれが重要なのか： 10人の加入者がいるセッションにおいて、パブリッシャーから10個の独立したフルHDストリームを送信することは無駄であり、一方、最も制約の多い加入者に単一のストリームを適応させることは最適とは程遠い。スケーラブル・ビデオは、複数の品質レイヤーを持つ1つのストリームを送信する。メディア・ルーターは適切なレイヤーを選択し、各加入者に転送する。加入者のネットワークが劣化すると、メディア・ルーターはそのレイヤーをリアルタイムでダウングレードします。一方、パブリッシャーは影響を受けず、メディア・ルーターが決定を下すためにすべてのレイヤーをストリーミングし続けます。

自動的に機能する仕組み 2人以上の参加者がいるルーティング・セッションでは、メディア・ルーターはスケーラブル・ビデオを自動的に有効にします。 オート プロジェクトの設定)。各パブリッシャーのSDKはスケーラビリティ構造をネゴシエートする（VP8サイマルキャストはL1T1/L2T1/L3T1レイヤーを使用、VP9 SVCは空間レイヤーも使用可能）。

いつ介入すべきか： 画面共有ストリームの場合、メディアルーターが低帯域幅の加入者向けにダウンスケールしたい場合は、スケーラブルビデオを明示的に有効にします。詳細は スケーラブルなビデオガイド.

ビットレート・プリセットとパブリッシャーの最大ビットレート

何をするのか？ パブリッシャーがカメラ映像に使用する最大ビットレートを設定できます。DEFAULT, BW_SAVER, EXTRA_BW_SAVER)または生の値。

なぜそれが重要なのか： 従量制または混雑した接続では、制限のないパブリッシャは、デバイス内の他のすべてのアプリケーションと帯域幅を争うことになります。プリセットを低く設定すると、ビデオのフットプリントが減少し、同じデバイス内の他のアプリケーションに多くのヘッドルームが残ります。スケーラブル・ビデオを有効にしてVP8を使用する場合、プリセットはどのエンコーディング・レイヤーをアクティブにするかも制御します。 BW_SAVER 事実上、ストリームは2つの空間レイヤー（低と中）に制限される。 EXTRA_BW_SAVER を1つ（低）に制限する。

レートコントロールとの相互作用： Google Congestion Control (GCC)は、あらかじめ設定された上限を下回っても動的に適応します。設定 BW_SAVER は天井であって、床ではない。

画面共有にビットレート・プリセットを使用しないでください。 画面共有エンコーダの動作は異なります。画面共有にビットレートの上限を適用すると、帯域幅の節約を期待できないまま、不鮮明で低フレームレートの出力が生成されることがあります。以下を参照してください。 パブリッシャー最大ビットレートガイド.

パブリッシャーの解像度とフレームレートのコントロール

ビットレートのプリセット以外にも、パブリッシャーが動画をエンコードする際の解像度とフレームレートを直接制御することができます。パブリッシュ時に設定する方法と、パブリッシュ開始後に動的に調整する方法があります。

パブリッシュ時に解像度とフレームレートを設定（Web SDK）：

const publisher = OT.initPublisher(targetElement, {
  resolution: '1280x720', // '1920x1080', '1280x720', '640x480', '320x240'
  frameRate: 15,          // 30, 15, 7, or 1
});

パブリッシャーは常に 最大 解像度とフレームレートは、あなたが必要とする可能性があります（SDKは、初期値から減らすことができるだけで、それ以上増やすことはできません）。

動的な解像度とフレームレートの調整（Web SDK）：

パブリッシング開始後、ストリームを再起動することなく、パブリッシャーが希望する解像度とフレームレートを変更できます：

// Reduce resolution
await publisher.setPreferredResolution({ width: 320, height: 180 });

// Reduce frame rate
await publisher.setPreferredFrameRate(7);

ダイナミックアジャストメントが役立つ一般的なシナリオ：

• 対応 qualityLimitationReason: "cpu" パブリッシャーの統計より：CPUの負担を軽減するためにフレームレートを下げる。
• オーディオのフォールバックがトリガーされる前に、帯域幅が突然低下した場合の対応。

ビデオコンテンツのヒント（Web SDK）： 画面共有ストリームの場合、ブラウザのエンコーディング戦略をガイドするコンテンツ・ヒントを設定する：

publisher.setVideoContentHint("text");    // Prioritises sharp text/static content
publisher.setVideoContentHint("motion");  // Prioritises smooth motion (default camera behaviour)
publisher.setVideoContentHint("detail");  // Prioritises fine detail at lower frame rates

参照 パブリッシャー動画制約ガイド そして ストリームの公開 - ウェブガイド.

パブリッシャーのビデオ劣化の好み

何をするのか？ 帯域幅やCPUリソースが制限されている場合に、ビデオエンジンが解像度を下げるかフレームレートを下げるかの優先順位を制御します。

なぜそれが重要なのか： ネットワークやデバイスが現在のビデオ品質を維持できない場合、エンコーダーは何かを劣化させなければならない。デフォルトでは、ビデオエンジンは自律的に決定します。たとえば、画面共有セッションでは解像度を維持した方が有利であり（滑らかな動きよりもシャープなテキストの方が重要）、カメラフィードではフレームレートを維持した方が有利です（滑らかな動きの方がブロック状の静止画よりも自然です）。

コンテンツとの関係 ヒント ビデオコンテンツのヒント と劣化プリファレンスは、異なるが関連した目的を果たす。コンテンツ・ヒント（Content Hint）とは、伝送されるコンテンツの種類を示すものである、 "text" 一方、Degradation Preference はエンコーディング戦略を明示的に制御します。コンテンツヒントを設定すると、ビデオエンジンは自動的に適切な劣化プリファレンスを選択します、 "text" は解像度を維持するように自動的に選択します。明示的に設定された劣化プリファレンスは、コンテンツヒントからの自動選択を上書きします。

スケーラブルなビデオとの関係： スケーラブルビデオがアクティブな場合、ビデオエンジンは、残りのストリームの解像度を劣化させるのではなく、時間的または空間的なレイヤーを削除することを決定することができる。劣化の優先順位は、アクティブなレイヤー内のガイドとして適用されます。

SDK固有のAPI：

完全な例については、プラットフォーム別のパブリッシュガイドを参照してください： アンドロイド, iOS, iOS (Swift), リナックス, ウィンドウズ.

加入者が希望する解像度とフレームレート

スケーラブル・ビデオ・ストリームに加入する際、メディア・ルーターに対して、各加入者にどの品質レイヤーを配信するかを指示することができる。これは、アダプティブ・レイアウトを構築するための主要なツールです。例えば、大規模な会議グリッドでは、サムネイルは低解像度レイヤーを受信し、アクティブなスピーカーはフル解像度を受信する必要があります。

サブスクライブ時に優先解像度を設定する（Web SDK）：

session.subscribe(stream, targetElement, {
  preferredResolution: 'auto', // Recommended: SDK picks the layer based on element size
  // Or specify explicitly:
  // preferredResolution: { width: 320, height: 240 },
  // preferredFrameRate: 7,
});

について "auto" ほとんどの場合、この設定を推奨します。 は自動的に レンダーサイズ 加入者の ビデオ・エレメントを選択し、最も適切なスケーラブル・ビデオ・レイヤーを要求する。注意 その "auto" はレイアウトに敏感です。アプリケーションが頻繁に変更される場合 アプリケーションで加入者タイルのサイズが頻繁に変更される場合（たとえば、アクティブスピーカーの切り替え、ピン/アンピン フロー、レスポンシブグリッドリレーアウト、またはアニメーション遷移)、SDK は優先解像度を繰り返し更新する場合があります。 は優先解像度を繰り返し更新します。そのため メディア・ルーターでは、レイヤーの切り替えや帯域幅の「ランプアップ/ランプダウン」サイクルが頻繁に発生します、 これは、ネットワークの解約を増やし、ビジュアルの安定性を低下させる可能性があります。非常に 動的なレイアウトでは、明示的に preferredResolution (または UIが落ち着いたときだけ更新する）、あるいは急激な振動を避けるために解像度の変更を制限する。 急激な振動を避けるために解像度の変更を制限する。

加入後のダイナミックな調整：

// Downgrade a tile when moving it to a thumbnail position
subscriber.setPreferredResolution({ width: 320, height: 240 });
subscriber.setPreferredFrameRate(7);

// Upgrade when the subscriber becomes the active speaker
subscriber.setPreferredResolution({ width: 1280, height: 720 });
subscriber.setPreferredFrameRate(30);

フレームレートの制限（Web SDK）： subscriber.restrictFrameRate(true) は、サブスクライバーを1秒あたり1フレーム以下に制限する。これは、「プレゼンス」タイルを表示しながらCPUと帯域幅を節約するために、大規模なセッションの非アクティブな参加者にとって有用である。コール restrictFrameRate(false) 通常のフレームレートに戻す。

クロスSDK APIについては スケーラブルなビデオガイド そして 品質ガイドを購読する.

オーディオ・フォールバック

何をするのか？ パブリッシャーまたはサブスクライバーのネットワークがビデオを維持できなくなると、SDKは自動的にそのストリームのビデオを無効にし、オーディオを維持します。

なぜそれが重要なのか： フリーズしたビデオフレームは耳障りです。オーディオストリームが途切れると、会話は完全に途切れてしまいます。オーディオのフォールバックは、帯域幅がなくなっても、参加者がお互いの声を聞くことができるようにします。Opus FECおよびDTXと組み合わせることで、非常に低いビットレートでも、音声は明瞭なままです。

補完的な2つのモード：

• パブリッシャー・オーディオのフォールバック:パブリッシング・クライアント自身のネットワーク評価によってトリガーされます。パブリッシャーの輻輳（ふくそう）メトリクスがビデオを維持できないことを示すと、パブリッシャーはビデオトラックを無効にします。リレーセッションとルーティングセッションの両方で利用可能。
• 加入者音声フォールバック:特定の加入者に代わってメディアルーターがトリガー。影響を受けた加入者のみがビデオを失い、他の加入者はビデオを受信し続ける。ルーティングされたセッションでのみ利用可能。

どちらの機能も自動的に作動する。詳しくは 音声フォールバックガイド.

モニタリングと観測可能性

モニタリング・レイヤーは、3つのスタック・レイヤーすべてにまたがっており、インフラ・トポロジーから個々のストリーム・メトリクスまで、あらゆるレベルで品質を可視化する。

品質モニタリングと顧客の観察可能性

何をするのか？ クライアント観測APIは、パブリッシャーとサブスクライバーの両方に対して、パケットロス、ビットレート、フレームレート、デコード解像度、フリーズカウントなど、ストリームごとの統計情報を継続的に提供します。ウェブSDKはさらに、オーディオのMOSスコア・スケールをシミュレートした品質スコアであるビデオのMOS（Mean Opinion Score）、およびCPUパフォーマンス・モニタリングを提供します。

なぜそれが重要なのか： 各エンドポイントで何が起きているかを可視化しなければ、「ユーザーのネットワークが悪い」のか「ユーザーのデバイスが過負荷」なのかを区別できません。統計情報により、アプリケーションは、品質がさらに低下する前にユーザーに警告を発したり、レイアウトを調整したり、ポリシーベースのアクションをトリガーするなど、スマートな意思決定を行うことができます。

主な能力

• ハイレベル統計API:ピア・コネクションの遷移に渡って正規化された、パブリッシャーまたはサブスクライバーごとのメトリクスの集計。プロダクション・モニタリングやアダプティブUXに使用します。
• ビデオ画質が変更されたイベント:品質が理由コード（帯域幅、CPU、コーデックの変更、解像度の変更）を伴って変更されたときに発行されます。ポーリングなしでUIの状態を駆動するためにこれらを使用します。
• 平均意見スコア（MOS）:業界標準の1～5の品質スコア（ウェブのみ）。お客様の観測スタックと統合することで、通話品質の長期的な傾向を追跡できます。
• CPUパフォーマンス・モニタリング:デバイス側の CPU ストレスを、コマ落ちの原因になる前に検出します（ウェブのみ）。背景ぼかしのようなCPU負荷の高い機能を無効にすることで対応。
• プレコールテスト:を使用する。 Vonageビデオ・ネットワーク・テスト・ライブラリ ユーザがセッションに参加する前に、MOSを推定し、オーディオ/ビデオの公開可能性をチェックする。

参照 顧客観察可能性ガイド 完全な統計リファレンスとSDK固有のコード例については、こちらをご覧ください。

さらに読む

• ビデオコーデックガイド
• スケーラブルなビデオガイド
• 音声フォールバックガイド
• セッションの作成（メディアモード、SPC、アダプティブ・メディア・ルーティング、メディアメッシュを含む）
• パブリッシャー動画制約ガイド
• ストリームの公開 - 設定ガイド
• 品質ガイドを購読する
• 顧客観察可能性ガイド
• パブリッシャーの最大ビットレートガイド
• サーバーローテーションとセッション移行ガイド
• セッションへの参加 - 自動再接続
• 地域メディアゾーンガイド
• 制限付きネットワークガイド
• エンド・ツー・エンド暗号化ガイド
• パブリッシャーのビデオ劣化の好み
• インサイトAPIガイド