序文
2020年の流行の突然の発生により、デジタル通信は人々の間の重要な通信手段になりました。また、リアルタイムのオーディオおよびビデオ通信（RTC）の安定性と通信効果の優れたテストも提供します。取引量の急増により、RTCサービスは、通話品質の確保、フリーズの最小化、エンドツーエンドの遅延、帯域幅のコストなど、ユーザーエクスペリエンスの確保に関して多くの困難に直面しています。ネットワーク伝送のプロセスでは、RTCソリューションはユーザーエクスペリエンスと運用コストの二重の制約に直面する必要があり、これは大きな課題となります。このホワイトペーパーでは、RTCサービスのネットワーク抵抗の下でのエクスペリエンス保証の提案について説明します。この記事では、最初に関連技術の特徴について説明します。次に、この記事では、TencentTeanaが立ち上げたオーディオジョイントソースチャネルコーディングスキームに焦点を当てます。このソリューションは、Tencent ConferenceやTRTCなどの製品で宣伝および展開されています。ユーザーエクスペリエンスを確保しながら、帯域幅と待ち時間を大幅に削減します。
1.背景紹介
図1.エンドツーエンドの観点からの音声通話体験に影響を与える要因
VoIPは複雑な連鎖システムです。送信者から受信者への一方的な通信を例にとると、収集、前処理、エンコード、送信、デコード、拡張、再生などの複数の段階を経る必要があります。各段階は最終的な経験に影響を与えます。エンドツーエンドからパースペクティブまで、通話体験に影響を与える要因は、ソースとチャネル（リンク）の2つの部分に分けることができます。信号源部分では、主な干渉要因は音響側のノイズやエコーなどの物理的特性ですが、一般的に品質保証は音声信号処理方式の最適化（深層学習技術の組み合わせなど）により行われます。ソースが最終エクスペリエンスの上限を決定すると言われている場合、チャネルは「割引」エクスペリエンスの上限を決定します。
図2.音声パケットの損失
RTCビジネスでは、重要な課題は送信中のパケット損失です。パケット損失は、受信側でのデコードサウンドの不連続性またはフリーズを引き起こし、エクスペリエンスに影響を与えます（図2）。したがって、ネットワーク抵抗の改善は、RTCサービスが避けられないトピックです。ただし、抵抗を改善する方法では、帯域幅の冗長性とCPU消費の増加を回避することはできません。同時に、どの単一の方法でも上記の問題を完全に解決することはできません。したがって、優れたRTC通話エクスペリエンスを作成するには、ソースとチャネルを組み合わせて、システムを上から下に設計する必要があります。この記事では、RTCシステムのネットワーク抵抗を改善する方法に焦点を当てます。
2.関連技術の概要
1）WebRTC
図3.WebRTCエンジン
RTCの主流の商用ソリューションはオープンソースから始まります。現在のオープンソースシステムの中で、WebRTCが最も広く使用されています[1]。WebRTCは、WebベースのRTCビデオ会議機能を実装します。コアテクノロジーには、オーディオとビデオのキャプチャ、エンコードとデコード、ネットワーク送信、表示、その他の機能が含まれ、クロスプラットフォーム（Windows、Linux、Mac、Android）もサポートします。比較的包括的なプラットフォーム機能により、RTCは独自のブランドのSDKを構築するための開発プラットフォームとしてそれを選択しました。
したがって、かなりの数のRTCメーカーが採用している戦略は、基盤となるレイヤーを変更せずに完全にWebRTCに基づいています。アプリケーションのシナリオでは、使いやすさなどの側面を改善するための努力が払われています。
しかし、流行の特別な背景の下で、ユーザーは、リアルタイムのオーディオおよびビデオ通信の安定性と通信効果に対するより高い要件を提唱しています。オープンソースプラットフォームに基づいて変更を加えるだけでは、通話エクスペリエンスを根本的に高いレベルに向上させることはできません。したがって、より多くのコア機能と基盤となるテクノロジーを備えたソリューションは、市場でより競争力があります。
2）組み込みコーディング技術（レイヤードコーディング）
埋め込みコーディングは、レイヤードコーディングとも呼ばれ、ネットワーク抵抗の要件を満たすために、ソース内のさまざまなコンポーネントのレイヤード処理に使用されます（図4）。原則は次のように要約できます。
バンドパスフィルターにより、入力音声信号は狭帯域部分と広帯域部分に分けられます。
より多くのビットレートを使用して狭帯域部分を圧縮し、歪みを減らします。帯域幅リソースがある場合は、最初に小さなビットレートを使用して、高周波数で効率的なパラメーターエンコーディングを実行し、許容可能な品質で高周波数を復元します。さらに、帯域幅リソースが多い場合は、高周波数をより細かくコーディングして、高品質の高周波数を回復できます。
上記のコード化されたストリームは、異なる優先度の送信保証戦略を使用して受信側に送信されます。特に、ネットワークが非常に貧弱な場合、コードストリームの狭帯域部分のみが送信されます。
受信側が少なくとも低周波部分を受信すれば、狭帯域音声を復元でき、基本的な品質を保証できます。符号化精度の異なる受信高周波に応じて、品質レベルの異なる広帯域音声が出力されます。
図4.埋め込みコーディングの基本アーキテクチャ
埋め込みコーディングは、ビデオコーディングシステムで広く採用されています。音声コーディングの分野では、2000年から2010年にかけて、ITU-T G729.1やG.718などの人気があり、関連する標準の超広帯域が進化しました。 [23]。
ただし、埋め込みコーディングには、音声サービスの効率が低いという問題があります。その理由は、音声サービスの基本ビットレートが20kbpsなどと低いためです。組み込みコーディングが導入された場合、システムは2kbpsのレイヤードコーディングに対して複雑なレイヤードロジックを実行する必要があります。これは、QoEの包括的な品質の観点から必ずしも最適な戦略ではありません。したがって、IETF OPUS [4]などの2010年以降の主流の標準では、埋め込みコーディングは使用されていませんでした。一般に、埋め込みコーディングが採用されていない場合でも、関連するコーディング標準はマルチレートコーディングテクノロジーを採用します。つまり、複数のコーディングビットレートをサポートし、ユーザーはビジネス特性に応じて合理的な構成を行うことができます。
3）複数記述コーディングテクノロジー（MDC）
マルチディスクリプションコーディング（MDC）はストリーム分離テクノロジーであり、具体的には、オーディオ信号のセグメントを異なるサブパート（「記述」と呼ばれる）に分離します。各パートは別々にパッケージ化され、異なる伝送パスを使用します。乗り換え。受信側が説明の一部を受信すると、低品質のオーディオを復元できます。すべての説明を受信すると、高品質のオーディオを復元できます[5]。
MDCの最も単純な実装の1つは、オーディオ信号のセグメントでパリティサンプリングを実行することです。奇数サンプルと偶数サンプルはグループ化され、別々に送信されます。受信側が奇数サンプルまたは偶数サンプルに関連するデータパケットのみを受信する場合でも、デコードと補間によって復元できます。低品質のオーディオを生成します。より複雑なMDCには、奇数フレームと偶数フレームの繰り返しの残差分析が含まれ、歪みが最小の変数の組み合わせがエンコードと送信のために決定されます。一般に、MDCエンコーダーには、複数の記述されたエンコーダーと残差関係を記述したエンコーダーが含まれており、エンコーダーの複雑さは非常に高くなります。
MDCの設計コンセプトは、ネットワークステータスが不良である必要があることを前提としています。MDCの価格は、（同じビットレートの）上限品質を犠牲にすることです。一般に、理想的なチャネルでは、MDCを完了するために追加の20〜30％の帯域幅を消費する必要があります。したがって、MDCは帯域幅の使用量を削減しません。さらに、MDCは主に狭帯域部分に使用され、広帯域部分は依然として埋め込みコーディングや帯域拡張などのテクノロジーを組み合わせて帯域幅の使用率を向上させます。そうしないと、帯域幅の使用量が増加します。
4）REDメカニズム
REDメカニズム、つまり冗長オーディオデータのIETFRTPペイロード[6]。提案されたメカニズムは、上記の低いオーディオビットレートに関連しています。たとえば、パケット化操作は20msの音声フレームごとに実行され、パケットヘッダーは10kbps、ペイロードは20kbpsと想定されます。このような割り当ては、深刻なビットレートの浪費を引き起こします。したがって、REDの提案は、2つの隣接する20msペイロードを1つのデータパケットに結合することです。このようにして、データパケットのペイロード比率は80％に達する可能性があります。OPUSは引き続きREDメカニズムを使用し、隣接する60ミリ秒のデータを1つのパケットにマージして、パケットヘッダーを共有します。ただし、REDメカニズムにはパケット内の抵抗はありません。他の抵抗保証がない場合、パケットが失われると、40〜60ミリ秒の連続データに影響します。
5）帯域外FEC
図5.帯域外FECの概略図
帯域外FECは、クラッド層でのデータ冗長性操作のためのテクノロジーです[7]。たとえば、パケットが4の場合、ネットワーク送信中にいずれか1つが失われ、このパケットに属する4つのデータパケットが受信側で任意の順序で受信された場合、失われたパケットを回復できます。具体的には、送信者：パラメータに従ってデータパケットを送信し、データパケットをブロックし、パケットデータに冗長性を追加します。受信終了：すべてのパケットを受信した後、データを回復できます（損失は冗長パケットの数を超えません）。これは、パケットがすべてになるのを待つためにFEC回復アルゴリズムに遅延があるため、FecDelay =ブロック*フレーム長です。
6）ARQ再送信
いわゆるARQ再送信とは、パケットが失われ、回復できないと判断された場合、遅延を増やしてネットワーク抵抗を改善するために再送信が要求されることを意味します[8]。高速オーディオ再送信ARQは、基本的な要求戦略としての「再送信の選択」アルゴリズムです。このアルゴリズムの重要な機能は、再送信要求とジッタバッファ間の緊密な連携です。いくつかの基本的なガイドラインは次のとおりです。
要求再送信モジュールは、再送信されたすべてのデータパケットの再送信が成功するまでに消費された時間を記録およびバッファリングし、JitterBufferモジュールに再送信遅延ArqDelayを通知します。これにより、データバッファ待機時間の高度な制御性が向上します。
受信側はARQ要求を使用します。データバッファキューのデータフレームが再生される前に、正常に再送信されなかったデータフレームが再生時間に達すると、受信側はACK通知を使用して再送信の要求をキャンセルし、無駄な要求を減らします。
3.共同ソースチャネルコーディングアーキテクチャ
1）スキームの設計コンセプト
前述のように、ネットワーク抵抗の問題を考慮すると、主流のRTCソリューションは依然としてチャネル側の方法に集中しています。特に、ネットワークの冗長性を追加することにより、高レベルの抵抗が維持されます。ただし、チャネル側の方法に完全に依存している場合、実際のアプリケーションでは他の問題に直面します。
ネットワークの抵抗が完全に帯域外に起因する場合、帯域幅のコストは急上昇します。
再送信などの操作は、パケットの組み合わせや解析などの反復操作をもたらし、待ち時間が長くなります。
したがって、Tencent Teanaのソリューションは、最初にソースから開始して、帯域内FECを最適化します。いわゆるインバンドFECの最も直感的な説明は、ヘッダーとT番目のフレームに加えて、T番目のパケットにはT-1番目のフレームの情報も含まれているということです。実際、OPUSはすでに上記の帯域内FEC機能をサポートしています。計算後、OPUSインバンドFECフレームのペイロードは通常のフレームの約70〜80％ですが、20％のパケット損失率に対する抵抗しか提供できず、入出力比は低くなっています。
上記の考慮事項に基づいて、TencentTeanaは次の共同ソースチャネルコーディング戦略を提案します。
まず、ソース側メソッドの機能の上限を改善します。標準の帯域内FECと比較して、新しいソース側FECは、より強力な個別抵抗を必要とします。たとえば、40％のパケット損失率をサポートします。
第二に、帯域外および帯域内抵抗の柔軟な使用。抵抗の安定性と帯域幅の消費の間でより柔軟な妥協点を持たせるため。関連する制御パラメーターは、反復アップグレードを実行するためにテストプラットフォームによって提供される経験的データに依存します。
第三に、前方互換性の問題については、古いプロトコルと新しいプロトコルの間に相互運用性がないことを確認する必要があります。
2）スキームフレームワーク
図6.共同ソースチャネルコーディングの基本フレームワーク
TencentTeana共同ソースチャネルコーディングの基本フレームワークが導入されました。
システムは、送信側、ネットワーク側、および受信側に分解できます。
送信者は、新しいスキームのコードストリームをアップストリームメディアエージェントに送信します。その中で、cFECは、ソース側の抵抗、帯域外、およびフロー制御を提供します。実際のネットワークステータスに応じて、最小帯域幅と遅延コストでQoEを保証するために、特定の構成が発行されます。
上流のメディアエージェンシーは、新しい計画に対応するプロトコルを標準プロトコルに変換します。
ダウンストリームメディアエージェンシーは、標準プロトコルを新しいスキームのプロトコルに変換し、それを受信側に送信します。
受信側は新しいスキームのプロトコルを受信し、ソースチャネルを組み合わせる機能を備えています。帯域幅と遅延が少ないため、安定した信頼性の高いネットワーク抵抗を得ることができます。さらに、受信側はcPLCパケット損失補償モジュールも統合して、突然のパケット損失状態を処理します。帯域外およびフロー制御モジュールによって制御されるリアルタイム戦略。ネットワーク損失の場合、帯域外FECまたはARQ再送信により、データパケットを受信側に最大限に完全に送信できます。それでもパケット損失が発生する場合は、まずcFECの帯域内抵抗に基づいて品質保証を実行します。さらに連続するデータパケットが失われる場合は、パケット損失補償のためにcPLCを開始します。
3）コアモジュール
a。ソース側FEC（cFEC）
Tencent TeanaのcFECソリューションは、音声信号の時間相関モデリングを完全に借用して、帯域幅の使用率を向上させます。したがって、帯域幅が制限されている場合、抵抗が大幅に向上します。
図7は、cFECとOPUSネイティブFECの効果の比較です。純粋なネットワークに加えて、cFECはOPUSネイティブFECと比較して0.1〜1.1MOSを改善できます。特に、40％の比較的大きなパケット損失率の下で、cFECテクノロジーの使用は依然としてMOSスコアを3.0以上に保ちます。ソース側の独立した抵抗が改善され、共同ソースチャネルコーディングの実装に十分な保証が提供されます。
図7.cFECテクノロジーとOPUSネイティブFECの耐性機能の比較
例として40％のパケット損失率を取り上げ、既存のテクノロジーと比較して耐性を向上させる自己開発のcFECテクノロジーの能力を示します。各ファイルの最初の段落はOPUSネイティブテクノロジー処理の結果であり、後の段落はcFEC処理の結果です。主観的な経験から、cFEC処理後の音声品質と継続性は非常に重要です。
40％未満のパケット損失率、OPUSとcFECのネイティブテクノロジーの効果の比較（上の女の子、下の男の子）
b。適応型帯域外制御戦略
最初のコンセプトは「フロー制御」です。「フロー制御」は、3つの異なる次元から説明できます。第一に、それは構成システムであり、2人以上が話していても、システムに必要な基本的な構成パラメーターはクラウドによって制御できます。次に、「フロー制御」は、送信元から宛先への機能の動的な交換です。第三に、ネットワーク輻輳制御（輻輳制御）、適応制御に基づいています。このように、パケット損失時のパケット損失に抵抗する方法、ジッタ時のジッタに抵抗する方法、およびすべてのプロセスが動的に制御されます。輻輳制御は、エンドツーエンドの遅延変化（Jitter）をリアルタイムで監視することにより、現在のネットワークがネットワークの輻輳に達する傾向があるかどうかを判断し、妥当な現在の帯域幅予測値を提供します。帯域幅予測値に基づいて、システムは帯域外FECおよびARQ戦略を動的に構成して、適応型帯域外制御戦略を実現します。
c。メディアエージェンシーとフォワード互換性の問題解決
共同ソースチャネルコーディングのアプリケーションの課題は、古いバージョンのオンラインプロトコルとの互換性、または新しいクライアントと古いクライアント間の相互接続です。包括的に考慮しないと、クライアントは互換性のないコードストリームを受信し、デコードエラーによってノイズやその他の問題が発生します。図6に示すように、関連するプロトコルトランスクリプターをメディアエージェンシーを通じて展開して、さまざまな標準プロトコルまたは非標準プロトコル間で変換し、対応するプロトコルデータパケットを特定のクライアントに送受信します。
d。コンテキストベースの連続パケット損失補償（cPLC）
パケット損失補償技術は、デコード側に展開されます。帯域外と帯域内の両方のFECに障害が発生した場合に、復元された音声フレームに基づいて失われたフレームを予測することです。このテクノロジーは追加の帯域幅を必要とせず、互換性があります。主流のPLCは、失われたコンテンツを約20ミリ秒しか回復できず、その影響は非常に限られています。深層学習の発展に伴い、産業界と学界の両方が、継続的なパケット損失補償の問題を解決するために深層学習を導入しようとしています[9]。これらのソリューションには、スペクトル回帰に基づいて関連するスペクトルまたは信号を予測したり、モデルを生成したりすることが含まれます。一般に、上記のスキームは、最大120msの連続パケット損失データを補正できます。しかし、モデルは大きくて複雑です。
Tencent Teanaによって提案されたcPLCソリューションは、アルゴリズムモデリングプロセスでの信号処理の重みを増やし、パラメータモデリングのコンテキスト関係を抽出し、深層学習ネットワークを呼び出して失われた音声を再構築します。cPLCソリューションは、複雑さが低いだけでなく、遅延がゼロで、展開の難易度が低く、互換性が高いという利点もあります。
図8は、ディスクリートパケット損失およびバーストパケット損失のシナリオにおけるcPLCおよびOPUSネイティブPLCの補正効果を示しています。実験結果は、すべてのテスト条件下で、cPLCがOPUSネイティブPLCテクノロジーよりも品質が優れていることを示しています。特に、cPLCの利点は、突然のパケット損失シナリオでより明白になります。
図8.cPLCテクノロジーとOPUSネイティブPLCの機能比較
4.実験結果
現在、TencentTeanaの共同ソースチャネルコーディングスキームがTencentカンファレンスで開始されました。テスト後、帯域幅を30％削減できます。同時に、遅延がさらに40〜60ミリ秒短縮され、ユーザーエクスペリエンスがさらに向上します。
5。結論
RTCシナリオでは、抵抗の改善はユーザーエクスペリエンスを決定する重要な要素です。この記事では、いくつかの典型的なメカニズムを分析し、各メカニズムの特性について説明します。しかし、流行の中で、RTC製品の安定性とコミュニケーション効果はより多くの課題に直面しており、新しいソリューションに対する強い需要があります。Tencent Teanaのソースとチャネルの共同コーディングスキームは、ソースとチャネルの抵抗戦略を効果的に組み合わせて、帯域幅と遅延コストを効果的に削減しながら、ユーザーエクスペリエンスを確保します。効果の観点からは、信号ソースとチャネルの共同最適化戦略を、従来の信号処理と詳細な学習と組み合わせた新しいテクノロジーが、将来のRTCソリューションの焦点になります。
参照
[2] ITU-T G.729.1：G.729ベースの組み込み可変ビットレートコーダー：G.729と相互運用可能な8〜32 kbit / sのスケーラブルな広帯域コーダービットストリーム
[3] ITU-T G.718：8〜32 kbit / sの音声および音声のフレームエラーロバストな狭帯域および広帯域埋め込み可変ビットレートコーディング
[5] VK Goyal、「Multiple Description Coding：Compression Meets the Network」、IEEE Signal Processing Magazine、vol。18、いいえ。5、pp。74–94、2001年9月。
[6] IETF RFC6354：冗長オーディオデータのRTPペイロード。
[7] J.Bolotなど。インターネットにおけるパケットオーディオのFECベースのエラー制御の事例。1997年。
[8] H。Seferogluなど。リアルタイムワイヤレスマルチメディア用のレート歪み最適化ジョイントARQ-FECスキーム。ICC2005で。
[9] https://ai.googleblog.com/2020/04/improving-audio-quality-in-duo-with.html