目次
VC++ の共通機能開発の概要 (コラム記事のリスト、購読歓迎、継続的な更新...) 
https://blog.csdn.net/chenlycly/article/details/124272585 C++ ソフトウェア異常トラブルシューティング チュートリアル シリーズ入門から習熟まで（コラム記事一覧）、ぜひ購読して更新を続けてください...）https://blog.csdn.net/chenlycly/article/details/125529931入門から習熟までのC++ソフトウェア解析ツール事例集（コラム）記事は更新中...) https://blog.csdn.net/chenlycly/article/details/131405795 C/C++ の基礎と応用 (コラム記事、継続的に更新中...) https://blog.csdn.net /chenlycly/category_11931267.htmlオープンソース コンポーネントとデータベース テクノロジ (コラム記事、継続的に更新...) https://blog.csdn.net/chenlycly/category_12458859.html オーディオおよびビデオ ソフトウェア アプリケーション シナリオや使用環境の変化に伴い、オーディオ品質も変化します要件はますます高くなっており、高品質のオーディオ効果を実現するには、オーディオおよびビデオ分野の成熟したソリューションから学ぶことができます。WebRTC は現在、音声品質の問題を解決する最も先進的な音声エンジンの 1 つであり、その中でも NetEQ ネットワーク イコライザー モジュールは、低帯域幅下での音声データの遅延、ジッター、パケット損失の問題をうまく解決します。この記事では、WebRTC における NetEQ ネットワーク イコライザーの実装原理、処理フロー、パケット損失補償処理メカニズムを詳細に分析します。
1 はじめに
IPネットワークは主にデータ伝送サービスに使用されるため、独立した論理回線または物理回線を占有する従来の電話機とは異なり、サービス品質（Qos）保証がなく、パケットの到着順序の乱れ、遅延、パケット損失、パケット損失などの問題が発生します。そしてジッター。パケット損失に対しては、ビジネスで再送信または複数の送信メカニズムを使用できますが、オーディオおよびビデオ ソフトウェアはリアルタイム サービスであり、帯域幅、遅延、ジッターに関する厳しい要件があるため、特定の QoS 保証を提供する必要があります。
オーディオおよびビデオ ソフトウェアの音質に影響を与える主な要因は、遅延ジッターとパケット損失処理の 2 つです。一般に、ネットワーク伝送による悪影響を排除するためにジッタ バッファが使用されますが、ジッタ バッファ技術はパケット損失処理に直接影響します。受信バッファは遅延ジッターを除去するために使用できますが、パケット損失が発生するとフリーズしたり、沈黙や補間補償が埋められます。ただし、遅延、ジッターが大きく、パケット損失が激しいネットワークでは、その効果は理想的ではありません。 。
WebRTC で NetEQ ネットワーク イコライザー テクノロジを借用してソフトウェアの音質を向上させる方法。まず、NetEQ の原理と処理手順を分析して分解する必要があります。次に、パケット ロスの原理と使用シナリオを理解する必要があります。補償アルゴリズムを作成し、それをソフトウェア製品の設計に効果的に適用します。
2. WebRTC の概要
WebRTC の NetEQ ネットワーク イコライザーを詳しく紹介する前に、まず WebRTC について一般的に理解しましょう。
WebRTC (Web Real-Time Communication) は、Google が開始したリアルタイム オーディオおよびビデオ通信 C++ オープン ソース ライブラリであり、オーディオおよびビデオの収集、エンコード、ネットワーク送信、デコード、表示などのオーディオおよびビデオ ソリューションの完全なセットを提供します。このオープンソース ライブラリを使用すると、オーディオおよびビデオ通信アプリケーションを迅速に構築できます。
リアルタイム オーディオおよびビデオ アプリケーション ソフトウェアには通常、次のリンクが含まれています: オーディオおよびビデオのコレクション、オーディオおよびビデオのエンコード (圧縮)、前処理および後処理 (美化、フィルタ、エコー キャンセル、ノイズ抑制など)、ネットワーク送信、デコード、レンダリング (オーディオとビデオの再生) など。これらの細分化されたリンクのそれぞれには、さらに細分化された技術モジュールもあります。
WebRTC と呼ばれていますが、実際には Web 間の音声とビデオの通信だけでなく、Windows、Android、iOS などのモバイル プラットフォームもサポートしています。WebRTC の最下層は C/C++ で開発されており、優れたクロスプラットフォーム パフォーマンスを備えています。
- WebRTC は主に C++ で開発および実装されています。コードでは C++11 以降の新機能が多数使用されています。ソース コードを読む前に、C++ のこれらの新機能について一般的に理解しておく必要があります。
- C++11の新機能はC++のオープンソースコードで頻繁に使われるだけでなく、転職時の筆記面接でもよく聞かれるので学習する必要があります。
- 新しい、無料で公開されている「Google オープンソース プロジェクト スタイル ガイド (zh-google-styleguide)」をよく読むことをお勧めします。これは Google のコーディング標準であるだけでなく、コーディング時に何をすべきかを説明するだけでなく、なぜそれをしなければならないのかを説明します。C++11 以降の新機能を学ぶのにも非常に有益です。私たちのプロジェクト チームは、昨年このプロジェクト スタイル ガイドを体系的に研究し、そこから多くのことを学びました。
WebRTC は、優れたオーディオおよびビデオ効果と優れたネットワーク適応性により、ビデオ会議、リアルタイムのオーディオおよびビデオのライブ ブロードキャストなどの分野で広く使用されています。ビデオ会議の分野では、Tencent Conference、Huawei WeLink、Byte Feishu、Alibaba DingTalk、Xiaoyu Yilian、Xiamen Yilian などの国内メーカーがいずれも WebRTC ソリューションをベースにしたビデオ会議を提供しています。
プロのオーディオおよびビデオ サービス プロバイダとしてよく知られている Agora は、オープンソース WebRTC ライブラリをベースとしており、ソーシャル ライブ ブロードキャスト、教育、ゲームおよび e スポーツ、IoT、AR/VR、金融、保険、医療、企業コラボレーション、およびサービスを提供しています。他の業界、オーディオおよびビデオのインタラクティブ ソリューション。Shengwang のサービスを利用している企業には、Xiaomi、Momo、Douyu、Bilibili、New Oriental、Xiaohongshu、HTC VIVE、The Meet Group、Bunch、Yalla、その他の世界的な大手企業、ユニコーン、スタートアップ企業が含まれます。大手企業の Shengwang に加えて、多くの企業がオープンソース WebRTC に基づいて複数のオーディオおよびビデオ アプリケーションを開発し、複数の分野でオーディオおよびビデオ通信ソリューションを提供しています。
3. NetEQ とは何ですか?
NetEQ は本質的にオーディオ JitterBuffer (ジッター バッファー) であり、正式名は Network Equalizer (ネットワーク イコライザー) です。
GIPS 音声エンジンの 2 つのコア テクノロジーのうちの 1 つは、NetEQ と呼ばれるパケット損失隠蔽アルゴリズムを含む高度な適応型ジッター バッファー テクノロジーです。2010 年に Google は、このテクノロジーを Global IP Solutions から 6,820 万米ドルで買収しました もう 1 つのコア テクノロジーは 3A アルゴリズムです。その後、Google はこれを WebRTC に統合し、2011 年にオープンソースとしてリリースしました。
NetEQ は適応ジッター制御アルゴリズムと音声パケット損失隠蔽アルゴリズムを統合し、デコーダと統合されているため、NetEQ は高パケット損失環境でも常に良好な音声品質を維持できます。
4. NetEQテクノロジーの詳細説明
4.1. NetEQの概要
NetEQ 処理には、適応型ジッター制御アルゴリズムと音声パケット損失補償アルゴリズムが含まれます。適応型ジッター アルゴリズムは、変化するネットワーク環境に迅速に適応でき、音声パケット損失補償アルゴリズムは、最小限のバッファリング遅延で一定の音質と明瞭さを確保できます。さらに、NetEQ アルゴリズムのシミュレーション テストは、音質効果と既存のソフトウェア設計との比較。 ソフトウェア設計の有機的な組み合わせ。
NetEQ 処理には、適応型ジッター制御アルゴリズムと音声パケット損失補償アルゴリズムが含まれます。適応型ジッター アルゴリズムは、変化するネットワーク環境に迅速に適応でき、音声パケット損失補償アルゴリズムは、最小限のバッファリング遅延で一定の音質と明瞭さを確保できます。さらに、NetEQ アルゴリズムのシミュレーション テストは、音質効果と既存のソフトウェア設計との比較。 ソフトウェア設計の有機的な組み合わせ。
NetEQのモジュール概要図は以下のとおりです。
上の図からわかるように、NetEQ は、適応パケット バッファ、音声デコーダ、ジッタ制御とエラー隠蔽、および再生の 4 つの部分に分かれています。ジッター制御およびパケット損失補償モジュールは NetEQ のコア アルゴリズムであり、適応バッファリングを制御するだけでなく、デコーダとパケット損失補償アルゴリズムも制御し、最終的な計算結果を再生のためにサウンド カードに渡します。
まず、NetEQ は現在最も完全なジッター除去テクノロジーです。固定ジッター バッファリングや従来の適応型ジッター バッファリングと比較して、NetEQ は変化するネットワーク環境に迅速に適応できるため、遅延とパケット損失が少なくなります。NetEQ 適応ディザリング アルゴリズムのパフォーマンス比較を次の図に示します。
次に、ジッター制御およびパケット損失補償モジュールは、拡張、通常、加速という 3 つの主要な操作で構成されます。
Expansion : 拡張操作、つまり、拡張モードと preemptive_expand モードを含む、音声の継続時間を延長します。前者はNetEQのパケットロス補償処理で、遅延したパケットを待ってパケットロスを補償する機能、後者は元のデータに基づいて音声時間を伸ばす優先拡張で、再生速度を遅くする機能です。
通常: 通常の再生動作、つまりネットワーク環境が正常で比較的安定している場合の動作です。
Accelerate : 動作を加速します。つまり、高速再生を実現します。
要約すると、この記事では主に NetEQ のジッター除去およびパケット損失補償テクノロジーについて説明し、シミュレーション テストと製品設計分析を組み合わせて、ビデオ会議製品の通話音質をさらに向上させます。NetEQ のパフォーマンス リストは次のようになります。
4.2. ジッター除去技術
ジッターには 2 つの定義があります。
ジッターの定義 1: さまざまな遅延による、ネットワーク内のデータ パケットの到着レートの変化を指します。具体的には、ジッターは、送信側のデータ ストリームの送信間隔と受信側の受信間隔の差として定義でき、可変コード レートのシナリオに適しています。
ジッター定義 2: 受信側での特定のデータ パケットの到着間隔と平均データ パケット到着間隔の差がデータ パケットの遅延ジッターとして定義され、一定のコード レートのシナリオで使用されます。
ジッターは、キューに入れられた IP パケットの遅延差から構成されるゼロ平均ランダム シーケンスです。データ パケットが蓄積されると、データ パケットが早く到着することを意味し、音声の完全性は確保されますが、受信側でバッファ オーバーフローが発生しやすくなり、エンドツーエンドの遅延が増加する可能性があります。データ パケットがタイムアウトすると、データ パケットがネットワークを介して送信されてから一定時間が経過しても受信側に到着しないことを意味し、データ パケットの到着が遅れたり、失われたりする可能性があることを示します。オーバーフローとタイムアウトはどちらもパケット損失を引き起こす可能性があるため、エンドツーエンドのパケット損失の可能性が高くなります。したがって、ジッターによって引き起こされるパケット損失を減らすには、ジッターを効果的に制御する必要があります。
ジッターは、通常、ジッター バッファリング技術を使用して除去されます。つまり、受信機でバッファが確立されます。音声パケットが受信機に到着すると、まずバッファに入り、一時的に保存されます。その後、システムは、次の時点でバッファから音声パケットを抽出します。一定のレートで解凍し、オーディオ ポートから再生します。ジッター除去の理想的な状態は次のとおりです。ネットワーク送信における各パケットの遅延は、バッファー内のすべてのバッファリングされたデータの遅延と等しく、バッファーのサイズは、早期に到着した各パケットのジッターとバッファリングされたデータの合計に等しい必要があります。データ遅延の合計は等しい。
ジッタ バッファ制御アルゴリズムには、静的ジッタ バッファおよび適応バッファ ジッタ制御アルゴリズムが含まれます。
静的ジッタ制御アルゴリズム：音声通話確立後、通話終了までの遅延とバッファサイズは固定値であり、タイムアウトやジッタがバッファサイズを超えたデータは破棄されます。アルゴリズム モデルはシンプルで実装が簡単ですが、ネットワーク遅延とジッターが大きい場合はパケット損失率が高くなり、ネットワーク遅延とジッターが小さい場合は音声遅延が大きくなり、遅延とサイズが大きくなります。ネットワーク状況に応じてバッファを動的に変更することはできず、初期値は適用可能なネットワーク状況を制限します。
適応型ジッター制御アルゴリズム: 実際のネットワークのジッターに応じてバッファーの遅延とサイズが変化します。受信側は、現在受信しているデータ パケットの遅延をアルゴリズムに保存されている遅延情報と比較して、現在のネットワークの最大ジッターを取得し、適切なバッファ遅延とサイズを選択します。このアルゴリズムの利点は、ネットワークジッターが大きい場合にはパケットロス率が小さく、ネットワークジッターが小さい場合には遅延が小さいことですが、欠点はアルゴリズムが多様で比較的複雑であることです。
現在のネットワークの複雑さと変更可能性を考慮して、適応型ジッター アルゴリズムが一般的に使用されており、NetEQ のジッター除去もこのタイプのアルゴリズムに属します。
4.3. パケットロス補償技術
パケット損失補償は、パケット損失隠蔽 (略して PLC) とも呼ばれ、送信者ベースの補償と受信者ベースの補償の 2 つのカテゴリに分類できます。パケットロス補償技術は以下から構成されます。
送信者に応じた補償をパケットロスリカバリ、つまりPacket Loss Recoveryとも言います。一般に、送信機に基づく補償は受信機に基づく補償よりも優れていますが、ネットワーク帯域幅と遅延が増加します。
FEC (Forward Error Correction) は、音声データ伝送の信頼性の向上を目的として、VoIP の音声品質を向上させるための現在最も有望な冗長符号化技術です。このため、FEC は元のデータを送信するだけでなく、相関関係に基づいて冗長データも送信し、デコーダがデータ間の相関関係に基づいて失われたデータ パケットを再構築できるようにする必要があります。VoIP で最も単純なのはパリティ コードです。この方法は、n-1 個のデータ パケットごとに、前の n 個のデータ パケットの XOR 演算を含むチェック コードを送信します。ネットワークが n データ パケットごとに 1 パケットだけ損失した場合、他の n-1 データ パケットからチェック コードを取得できます。パケット。失われたパケットを再構築するためのパケット。パリティ パケットに基づく FEC は次のようになります。
連続的なパケット損失が発生すると、FEC などのさまざまな補償技術は効果がありません。突然の連続的な音声損失の大部分に耐えるために、インターリーブ技術を使用できます。インターリーブ技術は失われたデータ パケットを回復できないため、真のパケット損失回復技術ではありませんが、この技術によりパケット損失によって引き起こされる損失を軽減できます。インターリーブ技術は、元のデータを IP パケットよりも小さいいくつかの単位に分割し、送信前にこれらの単位の順序を並べ替えて、各 IP パケットのデータが異なる音声フレームからのものになるようにします。フレーム内のデータは失われますが、フレーム内のすべてのデータは失われません。これらのユニットは受信側で並べ替えられます。インターリーブ技術は、聴覚を利用して失われたデータの一部を自動的に回復する人間の脳の能力を利用します。フレームごとに失われるデータが少量であれば、人間の聴覚への影響が少なくなり、音質が向上します。付加情報が出力されないため帯域は増加しませんが、受信側で並べ替えが必要となるため遅延が増加し、ある程度は耐えられません。GSM システムはインターリーブ技術を使用します。
インターリーブ技術は次のとおりです。
低レート冗長コーディング (低レート冗長コーディング) は冗長技術です。各データ パケットには、独自のデータに加えて、前のフレーム データの圧縮コピーも含まれています。このコピーは品質が低く、ビットを占有します。小さいです。受信側でパケットが失われた場合、このコピーを使用して、後続のデータ パケットから失われたパケットを迅速に再構築できます。FEC とは異なり、追加されるビット数は前後のフレームに相関があり、後続のパケットにコピーされるだけなので、帯域幅と遅延も増加しますが、FEC のように、ネットワークが切断された場合の連続的なパケット損失には適用できません。輻輳しています。これにより、さらに深刻なパケット損失が発生します。G.729A は冗長コーディング技術を使用します。冗長コーディング回復パケット損失の概略図は次のとおりです。
パケット損失補償技術の基本原理は、受信側で失われた音声パケットに類似した代替音声を生成することであり、この技術の実現可能性は、音声の短期的な類似性と人間の耳のマスキング効果に基づいています。 、小さなパケット損失率 (<15%) と小さな音声パケット (4 ～ 40 ミリ秒) を処理できます。失われたデータは正確に復元できないため、受信側のパケット損失補償は送信側の補償に代わることはできません。したがって、ネットワークのパケット損失率が大きい場合は、送信者補償テクノロジーに依存する必要がありますが、パケット損失率が大きすぎる場合は、ネットワークを最適化することしかできません。
挿入ベースの方法とは、パケット損失箇所に、通常、無音、ホワイトノイズ、コピーなどの損失波形と無相関の単純な波形を挿入することによってパケット損失を隠す方法を指します。
サイレント置換の使用範囲は非常に限られており、パケット損失率が 2% 未満で、音声フレームが 4ms 未満の場合に効果的に機能します。ホワイト ノイズまたはコンフォート ノイズは、失われた波形を正しい音声で修復する人間の脳の潜在意識の能力を利用しており、沈黙よりも優れています。
コピーとはGSM方式で採用されている方式で、パケットロスが連続して発生した場合、前のフレームのデータを徐々に減衰させて補償波形を生成しますが、音声の前後フレーム間の相関は考慮されていないため、その効果は次のとおりです。あまり理想的ではありません。補間技術とは、パケット損失を補うために類似の波形を使用することを指します。この技術は比較的複雑です。パケット損失の前後のデータを使用して損失データを推定し、失われた波形を最も類似した波形に置き換えます。つまり、その効果は次のとおりです。挿入技術よりも優れています。
フレーム間補間技術は、従来のエラー隠蔽技術です。変換符号化または線形予測符号化を使用する音声エンコーダの場合、デコーダは音声信号の短期定常性と隣接するフレーム間のパラメータの相関に基づいて前のフレームのパラメータを補間することで補償できます。G.723.1 はパラメータ補間技術を使用して、LSP 係数と励起信号に対してそれぞれフレーム間補間を実行し、失われたフレームを補償します。G.729 はまた、以前のフレームの直線性を使用して、エラー フレームを隠すために補間のために前のフレームのパラメータを使用します。失われたフレームを補償するためのフレーム予測係数 (LPC) とゲイン低減係数。
再構成による補償技術は、パケット損失前後の復号情報を再構成して補償パケットを生成する技術であり、最も計算量が多く効果が大きい。これは受信側で完了し、送信側の参加や追加のビット ストリームを必要としないため、リアルタイム伝送の要件を満たすことができ、現代のネットワーク伝送においてより効果的かつ実用的です。
ピッチ検出による波形置換技術は、ピッチ周期を計算し、ピッチ周期に基づいてフレームの無声音と有声音を判定し、無声音の場合はパケットロス前の最新の波形を使用し、それ以外の場合はセグメントを使用します。パケット損失前のピッチ期間の長さを使用して、それを適切な波形に置き換え、短期エネルギーとゼロクロス レートを組み合わせて失われた音声を復元します。効果は挿入技術によるものですが、比較的複雑です。
デジタル音声信号処理の基本単位は基音であり、物体が振動するときに発せられる最も低い周波数の音を基音とし、残りが倍音となります。つまり、音声のエネルギーの大部分は発音体が振動する際に伝わるのですが、この声帯の振動の周波数を基本周波数といい、その周期が基本周波数です。ピッチ周期の推定はピッチ検出と呼ばれ、その目的は声帯の振動周波数と正確に一致するピッチ周期の長さを取得することです。
波形符号化を使用する G.711 エンコーダではパケット ロス補償技術は使用されていませんが、音声品質を向上させるために、G.711 プロトコルの付録にピッチ検出に基づくフレーム ロスを補償する波形置換技術が追加されています。デコードされた前のフレームを使用し、そのデータは現在の音声信号のピッチ周期を推定するために使用され、最新のピッチ周期とその前の 1/4 ピッチ周期のデータは欠落データを補うために使用されます。最初の 1/4 ピッチ期間のデータは、フレーム損失の前に音声信号とオーバーラップして加算するために使用され、元の信号と補償信号の間のスムーズな移行を保証します。次のフレームのデータが失われていない場合、スムーズな遷移を保証するために、1/4 ピッチ周期のデータが伸長されて重ね合わされ、通常の復号データと加算されます。次のフレームがまだ失われている場合は、さらに 1 ピッチ周期のデータを抽出して補正します (最大 3 ピッチ周期まで抽出できます)。失われるフレームが増えるほど、補償された音声と実際の音声の差が大きくなります。したがって、最初のフレームを除いて、連続フレーム損失補償はフレームごとに 20% の割合で減衰する必要があります。音声信号、特に有声信号は一定の周期性を持つ準定常時系列であるため、フレーム損失データを再構築するにはフレーム損失前の音声データを使用する方がよい。
タイムドメイン補正技術では、ギャップの両側の波形をギャップの方向に伸ばしてギャップを埋め、ギャップの両側で重複するピッチ周期のベクトルを見つけ、それらをオフセットしてギャップをカバーします。重なっている部分を平均化します。この方法は、ギャップ境界での位相の不連続現象を回避し、パケットロスの接合点での破裂音が聞こえないため、ピッチ検出による波形置換よりも主観的な効果が優れています。
WebRTCにおけるNetEQのパケットロス補償技術は、iLBCアルゴリズムを組み込んだパケットロス補償技術を採用しています。iLBC の正式名は Internet Low Bit rate Codec です。GIPS によって開発された、パケット交換ネットワーク通信用に特別に設計されたコーディングおよびデコーディング アルゴリズムです。サンプリング レートは 8khz。エンコーディング時間は 20ms と 30ms の 2 つあります。コード レートは次のとおりです。それぞれ 15.2kbps と 13.3kbps で、パケット損失に対して非常に堅牢です。iLBC のパケット損失補償はデコード側でのみ処理され、モデルベースの回復方法を使用して補償パケットが生成されます。
1) 線形予測係数 (LPC) を再構成します。つまり、最後のフレームの LPC システムを使用して再構成します。最後のフレームは空間的にも時間的にも現在の失われたフレームの LPC との相関が最も高いためですが、この単純なコピーでは、連続した失われたフレームを処理するときに明らかに大きな歪みが発生します。
2) 残差信号を再構成します。残留信号は通常、準周期成分とノイズ状成分の 2 つの部分に分けることができます。準周期成分は前フレームのピッチ周期に基づいて近似でき、ノイズ様成分はランダムノイズを発生させることで得られ、両者のエネルギー比も前フレームの比例関係から求めることができます。 。したがって、最初に前のフレームのピッチを検出し、次に失われたフレームの音声信号をピッチ同期した方法で再構築し、次に相関を使用してノイズのようなゲインを取得し、最後にミキシングを実行して全体を再構築する必要があります。残留信号。
3) 連続的なフレーム損失の場合、PLC によって補償された各音声フレームは同じスペクトル特性 (同じ LPC) とピッチ周波数を持ち、各補償フレーム間の相関を減らすために、フレームごとにエネルギーが減少します。
OPUS のパケット損失補償は、CELT と SILK の 2 つのモードに分かれています。OPUS コーデックは、インターネット上でのインタラクティブな音声およびオーディオ出力のために Internet Engineering Task Force (IETF) によって設計され、Skype の SILK (Skype の既存の SILK アルゴリズムと互換性なし) と Xiph.Org の CELT テクノロジを統合しました。CELT モードでのパケット損失補償は、iLBC のパケット損失補償と同様です。
SILK エンコーダ モジュールのフレームワークは次のとおりです。
4.4. NetEQ の概要設計
NetEQ モジュールには、主に MCU と DSP という 2 つの主要な処理ユニットが含まれています。MCU (マイクロ コントロール ユニット) モジュールはジッタ バッファの制御ユニットです。ジッタ バッファは受信データを一時的に保存するために使用されるため、MCU の主な機能はデータパケットと制御パケット出力。ジッターキャンセル技術はMCU制御モジュールに組み込まれています。
NetEQの概略設計は以下のとおりです。
ジッター バッファーには 240 のスロットがあり、ネットワークから送信された各元のデータ パケットは、主にデータ パケットのタイムスタンプ、シーケンス番号、データ タイプなどを保存するジッター バッファーの適切なスロットに配置されます。実際のデータキャリアはメモリバッファに保存されます。新しいデータ パケットが到着すると、そのキャリアを保存するためのスペースがメモリ バッファに割り当てられ、それによってジッターの除去が実現されます。
DSP モジュールは主に、デコード、信号処理、データ出力など、MCU から読み取られたデータ パケットのアルゴリズム処理を担当します。DSP モジュールにはパケット損失補償技術が含まれています。
音声バッファには、デコードおよび信号処理された再生データが格納され、565 サンプルを格納できます。curPosition は再生データの開始点、sampleLefe は再生サンプル数を表します。
共有メモリ、デコード バッファ、アルゴリズム バッファはすべて一時的なデータ バッファです。共有メモリは、ジッタ バッファから読み取られたデコード対象のデータを一時的に保存し、サンプル損失数と MCU 制御コマンドを保存するために使用されます。デコード バッファは一時的に保存されます。デコードされたデータ、NetEQ アルゴリズム バッファは DSP アルゴリズムによって処理されたデータを一時的に保存し、音声バッファ内の新しいデータを補足するために使用されます、再生バッファは再生ドライバのデータ バッファであり、音声からデータを読み取るために使用されますバッファして再生します。
4.5. NetEQ コマンドのメカニズム
NetEQ の処理フローはさまざまなコマンドによって制御され、使用されるコマンドは受信したデータ パケットのステータスに基づいて決定されます。
1) 前のフレームと現在のフレームの両方が正常に受信されます。この時点で、データ パケットは通常の処理フローに入り、デコードされたデータはジッター除去の必要性に応じて、通常、加速、またはプリエンプティブ拡張として選択されます。
2) 現在のフレームのみがパケットを失うかタイムアウトする: 現在のフレームがパケットを失うかタイムアウトする場合、PLC 処理に入り、LPC 信号と残留信号を再構築します。つまり、Expand 操作です。NetEQ はタイムアウトおよびパケット損失フレームを最大 100ms 待機しますが、この時間を超えると、次のフレームを直接抽出して再生します。
3) 連続した複数フレームのタイムアウトまたはパケット損失: 複数の連続フレームが損失した場合、複数の PLC 操作が必要になりますが、このとき、データが遡るほど、補償パケットを正確に再構築することが困難になるため、補償エネルギーが減少します。継続的なパケット損失に対するゲインが採用され、大きな歪みの発生を避けるためにフレームごとに削減されます。
4) 前のフレームが失われ、現在のフレームは正常です。前のフレームが失われ、再生された前のフレームのデータが PLC によって補正されます。PLC補正されたフレームと正常に復号されたフレームとの間で音声の連続性を保つためには、前後のフレームの相関関係に基づいて平滑化する必要があり、この場合は「Normal」または「Merge」を選択します。
さらに、NetEQ が初めてパケットを受信したとき、または NetEQ 全体がリセットされた後に、デコーダがリセットされます。一方、NetEQ が 3.75 秒を超える遅延を持つパケットを受信した場合、そのパケットはタイムアウト パケットとして破棄されず、ジッタ バッファに挿入され、バッファのステータスがリセットされます。
4.6. NetEQ 再生メカニズム
WebRTC の音声エンジンは実行時に 2 つのスレッドを開始します。1 つのスレッドはデータ パケットを受信してジッター バッファに挿入し、もう 1 つのスレッドは再生のために 10 ミリ秒ごとに音声バッファから 10 ミリ秒のデータを読み取ります。
NetEQ は、音声バッファ内のデータ ストレージとジッタ バッファ内のデータ ストレージを組み合わせて、ジッタ バッファからデータを読み取るかどうかを決定します。
1) 制御コマンドが Normal、Expand、デコーダ リセット、またはパケット バッファ ステータス リセットで、SampleLeft が 10ms 以上の場合、データはジッタ バッファから読み取られず、DSP は通常動作を実行します。
2) 制御コマンドが Normal、デコーダ リセット、またはパケット バッファ ステータス リセットで、SampleLeft が 10ms 未満の場合、ジッタ バッファからデータを読み出した後、DSP は通常動作を実行します。
3) 制御コマンドが Expand で、SampleLeft が 10ms 未満の場合、データはジッタ バッファから読み取られず、DSP は Expand 動作を実行します。
4) 制御コマンドが Merge の場合、DSP はジッタ バッファからデータを読み出した後、Merge 動作を実行します。
5) 制御コマンドが Accelerate の場合、SampleLeft が 30ms 以上の場合、データはジッタ バッファから読み出されず、DSP は Accelerate 動作を実行します。SampleLeft が 10ms 以上 30ms 未満の場合;SampleLeft が 10ms 未満の場合、データは別のジッター バッファーから読み取られ、DSP はノーマル動作を実行します。;SampleLeft が 10ms 未満の場合、ジッター バッファーからデータを読み取った後、DSP はアクセラレート動作を実行します。
6) 制御コマンドが Preemptive Expand の場合、SampleLeft が 10ms 以上の場合、DSP はジッタ バッファからデータを読み取らず、DSP は Preemptive Expand 動作を実行します。SampleLeft が 10ms 未満の場合は、読み出し後、ジッター バッファーからのデータを受信すると、DSP はプリエンプティブ拡張操作を実行します。
上記コマンド処理では、音声バッファでのさらなる通話遅延を防ぐための配慮から、SampleLeftが10ms以上の場合はジッタバッファからデータを読み出す必要はなく、それ以下の場合のみデータを読み出します。音声バッファ内に適切な量のデータを維持します。制御コマンドがマージの場合、前後のデータの連続性を確保するために、いつでもジッタ バッファからデータを読み取る必要があります。制御コマンドの場合、 Expand の場合、パケットロス補償が発生します。 ある程度のデータ量があるため、ジッタバッファからデータを読み出す必要はありませんが、SampleLeft が 10ms 以上の場合、データが十分にあるため、Expand 操作は実行されません。音声バッファを再生用に確保し、通常動作のみを行います。
4.7. MCU制御機構
NetEQ のジッタ アルゴリズムでは、忘却係数アルゴリズムに基づいて予測ネットワークのジッタを計算するために Blo (optBufferLevel) が使用され、適応平均アルゴリズムに基づいて予測ジッタ バッファのジッタを計算するために BLc (bufferLevelFit) が使用されます。MCU の制御メカニズムは、再生されたデータのタイムスタンプ (playedOutTS、TSplay として記録)、読み取られるデータ パケットのタイムスタンプ (availableTS、TSavail として記録)、Blo と Blc の関係に基づいて動作コマンドを選択します。TSplay と TSavail の関係は、ネットワーク データが正常かどうかを判断するために使用されます。
Blo と Blc の比較を以下に示します。
上図の Blo と Blc の関係により、Accelerate、Preemptive Expand、Expand、および Merge 操作の選択が決まります。
つまり、NetEQ でのジッター除去は主に、ネットワーク遅延とジッター バッファー遅延の関係に基づいて対応する操作を実行するように DSP に通知するさまざまなコマンドを送信することによって実現されます。
4.8. DSPアルゴリズム処理
DSP モジュールは NetEQ の音声信号処理モジュールであり、その動作コマンドは MCU によって制御されます。WebRTCでは自己相関関数方式が用いられており、音声信号は非定常信号であるため、信号処理には短期自己相関関数が用いられます。短期自己相関関数法を用いた遺伝子検出は、主に信号周期で最大となる短期自己相関関数の特性を利用し、元の信号とそのシフトされた信号の類似性を比較することでピッチ周期を決定します。距離がピッチ周期に等しい場合、2 つの信号の類似性は最も大きくなります。古典的な短期自己相関関数がピッチ検出に使用される場合、ウィンドウ関数が使用されますが、ウィンドウは移動せず、音声信号は移動します。窓長はピッチ周期の2倍以上必要であり、窓長が長いほどピッチ周期の精度は高くなりますが、その分計算量も増加します。
WebRTC の加速および減速操作は、WSOLA アルゴリズムに基づいて音声の長さを調整します。これは、音声のピッチを変更せずにタイムライン上の音声を圧縮または引き伸ばし、良好な音質を確保することです。これは、一般に可変速度として知られています。 . 曲はありません。音声長調整アルゴリズムは、時間領域と周波数の 2 つのカテゴリに分類されます。時間領域は、重複領域における波形類似性 (WSOLA) アルゴリズムに代表されます。音声信号の場合は、より高い音声品質が得られ、周波数の計算量は高くなります。アルゴリズムが小さくなります。音楽信号のように周波数の変化が激しい音声の場合、時間領域アルゴリズムではより高い音声品質を得ることが難しく、サブバンドWSOLAアルゴリズムなどの計算量の多い周波数アルゴリズムが一般的に使用されます。GIPS は VoIP サービス用に NetEQ を設計したため、データは主に音声信号であり、周波数領域の変化が小さいため、時間領域アルゴリズム WSOLA が使用されます。
再生音声のジッター除去やパケットロス補償、低遅延・高音質を実現する鍵となるDSP処理について、以下にDSPのさまざまな動作を紹介します。
1) 加速度: 音声パケット内のサンプル数を削減し、削減されたデータは音声サンプルの相関に基づいて得られるピッチ周期です。２サンプル周期の音声データは平滑化されて１ピッチ周期のデータに変換される。加速処理は 1 フレームとして 30ms かかり、相関が非常に強い (>0.9) か信号エネルギーが非常に低い場合にのみ加速されます。アルゴリズムは減速処理と同様です。以下に示すように:
2) 速度を遅くする: 音声パケットのサンプル数を増やす 追加されるデータは、音声サンプルの相関に基づいて得られるピッチ周期です。2 つのサンプル期間の音声データが平滑化され、2 つのサンプル期間の間に挿入されます。減速操作は 1 フレームとして 30ms かかり、再生されるデータは少なくとも 0.625ms であり、それ以外の場合は前のフレームが繰り返し再生され、デコードされたデータ キャッシュが 30ms 未満の場合は、再生キャッシュに直接コピーされます。ピッチ周期は 2.5ms ～ 15ms の範囲なので、最大 15ms まで延長できます。以下に示すように:
3) フレーム挿入: iLBC のパケット損失補償アルゴリズムが使用されます。つまり、線形予測システムが再構築され、残差信号が再構築され、補償フレーム エネルギーがフレームごとに削減されます。フレーム挿入操作中、再生されるバッファは再生読み取り時間 (10ms) より小さくなければなりません。以下に示すように:
4) 融合: 前のフレームのパケット損失後、フレーム挿入操作が実行され、新しいデータがデコードされるときに、音声データの一貫性を向上させるために、新しいデコードされたデータとフレーム挿入データが平滑化されます。そしてエネルギーは徐々に増加します。融合操作によって生成される中間データは大きいため、最大限のスペースを確保する必要があります。以下に示すように:
5) 通常: この時点では、新しいデコードされたデータが出力され、通常どおり再生されますが、前のフレーム データが補間フレーム データである場合は、最初にフレームを補間してから平滑化する必要があります。
4.9. DSPアルゴリズムのシミュレーションテスト
上記の DSP アルゴリズムの動作を考慮して、この記事では、さまざまなパケット損失率の下で断続音声信号 (Test1)、連続音声信号 (Test2)、音楽信号 (Test3) のシミュレーション テストを実施し、客観的な測定規格 ITU-T P563 を採用しました。 MOS 値の推定では、パケット損失時に無音を埋めるために LostData が使用され、パケット損失時にフレームを挿入するために Expand が使用され、パケット損失時に融合の前にフレームを挿入するために Expand+Merge が使用されます。
| テスト 順序 |
出力フレーム 間隔 |
パケットロス率 |
MOS(P563) |
||
| 失われたデータ |
拡大する |
展開+結合 |
|||
| テスト1 |
10ミリ秒 |
10.00% |
2.131 |
2.163 |
2.377 |
| 11.11% |
2.237 |
3.085 |
3.073 |
||
| 12.50% |
1.717 |
2.930 |
3.231 |
||
| 14.29% |
2.159 |
3.138 |
3.348 |
||
| 16.67% |
1.656 |
2.650 |
3.275 |
||
| 20.00% |
2.364 |
2.161 |
2.333 |
||
| 25.00% |
1.838 |
3.001 |
3.033 |
||
断続的な音声信号は、パケット損失率の変化の影響をあまり受けません。パケット損失中に音声があまり失われない場合に MOS 値が向上するためです。パケット損失中に発生する破裂音は、パケット損失補償後に大幅に改善されます。主観的な経験は良好です。 。
| テスト 順序 |
出力フレーム 間隔 |
パケットロス率 |
MOS(P563) |
||
| 失われたデータ |
拡大する |
展開+結合 |
|||
| テスト2 |
10ミリ秒 |
10.00% |
2.656 |
2.872 |
3.598 |
| 11.11% |
2.568 |
2.997 |
2.926 |
||
| 12.50% |
2.634 |
3.162 |
3.038 |
||
| 14.29% |
2.530 |
3.169 |
3.007 |
||
| 16.67% |
2.290 |
2.903 |
2.980 |
||
| 20.00% |
2.522 |
3.206 |
3.108 |
||
| 25.00% |
1.952 |
2.943 |
2.952 |
||
連続音声信号はパケットロス率に従って緩やかな下降傾向を示しており、パケットロス補正の効果はTest1と同様で、破裂音は大幅に改善されており、主観的な体感は良好です。
| テスト 順序 |
出力フレーム 間隔 |
パケットロス率 |
MOS(P563) |
||
| 失われたデータ |
拡大する |
展開+結合 |
|||
| テスト3 |
10ミリ秒 |
10.00% |
2.428 |
2.658 |
2.855 |
| 11.11% |
2.577 |
2.708 |
2.663 |
||
| 12.50% |
3.420 |
2.478 |
2.739 |
||
| 14.29% |
3.552 |
2.444 |
2.863 |
||
| 16.67% |
3.251 |
2.421 |
2.792 |
||
| 20.00% |
1.000 |
2.208 |
2.527 |
||
| 25.00% |
1.099 |
1.993 |
2.474 |
||
音楽信号は久石譲の「天空の城ラピュタ」です。スペクトル全体が大きく変化します。パケットロス率が小さい場合は補正効果が高く、パケットロス率が大きくなるほど補正の主観的効果は悪くなります。
加速、減速、通常動作を逐一比較するのではなく、パケットロスがない場合、加速動作と減速動作はジッターを除去し、音声信号の完全性を維持するのに非常に効果的です。
上図のダイナミック シミュレーションの初期値は 37 サンプルです。つまり、最初に再生されるサンプルは 37 個です。Expand後のMergeで得られるMOS値が低下する原因としては、1.Expand前に再生するバイト数が少なく、挿入されたフレームデータの音質が低下する、2.Expand前のExpandで補正されるデータ量が多くなる、の2つが考えられます。 Merge は Merge 後の MOS 値に影響を与えるため、音質の観点からは Expand と Merge が 1 対 1 に対応することが理想的です。
上図の固定シミュレーションの固定値は 500 サンプルです。つまり、再生されるサンプル数は 500 のままです。この時点で、Expand で得られる MOS 値が大幅に向上しましたが、その後は毎回 Merge 操作を実行して MOS 値を向上させることができます。
上図のダイナミック シミュレーションの初期値は 0 です。つまり、最初に再生されるサンプルは 0 です。この時、Expand前に再生するサンプル数が減り、Expandで挿入されるフレームデータのMOS値が減少し、その後ExpandとMergeが一対一に対応していないにも関わらず、データ量が減少します。各マージの前に再生されるため、スムージングが必要なデータが少なくなります。MOS 値を増やすのに役立ちます。
P563 標準のいくつかの重要なパラメータは、信号対雑音比 (SNR)、沈黙間隔、平均ピッチ周期などです。基準となる位相変化はありませんが、位相変化は位相の不連続性など、聴覚に大きな主観的な影響を与えます。フレームデータ挿入後の波形ではパチパチ音が発生し、音質に影響を与える場合があるため、P563のMOS値はフレーム補間とフュージョンでほぼ同等と推定される場合もありますが、主観的にはフュージョンの方がはるかに優れています。フレーム補間の様子。
5. NetEQ ソースファイルの説明
mcu_dsp_common.h: NetEQ インスタンス。
neteq_error_codes.h: NetEQ エラー コード。
neteq_statistics.h: NetEQ PLC 統計。
dsp.h: dsp上でPLCを動作させるためのヘッダファイルです。
加速.c: 操作を高速化してレイテンシを短縮します。信号の相関が強く、信号のエネルギーが弱い場合に処理が行われます。
Expand.c: オーディオ信号を生成し、バックグラウンド ノイズを生成します。
preemptive_expand.c: 速度を落として遅延を増やします。
Normal.c: 通常の再生。
merge.c: 新しいデータ フレームと拡張された前のデータ フレームを平滑化します。
bgn_update.c: 背景ノイズの推定と更新。
cng_internal.c: 快適なバックグラウンドノイズを生成します。
dsp.c: dsp動作の初期化関数と定数テーブル定義。
recin.c: RTP パケットを追加します。
reout.c: PCMをデコードして出力します。
dsp_helpfunctions.h
dsp_helpfunctions.c: 2 つの dsp 関数、周波数は 8k の倍数、ダウンサンプリングは 4k です。
min_distortion.c: 最小歪みの計算。
correlator.c: 信号の相関を計算します。
Peak_detection.c: 相関ピークの検出と位置決め。
mix_voice_unvoice.c: ミックス
mute_signal.c: ミュート(弱める)
unmute_signal.c: ミュートをオフにする (クレッシェンド)
random_vector.c: ランダムなベクトル。
codec_db_defines.h
codec_db.c: アルゴリズムライブラリのデータベースを管理します。
dtmf_buffer.h
dtmf_buffer.c: DTMF メッセージとデコード。
dtmf_tonegen.h
dtmf_tonegen.c: DTMF 信号を生成します。
mcu.h: MCU側の動作。
mcu_address_init.c: MCU アドレスの初期化。
mcu_dsp_common.c: MCU と DSP 間の通信。
mcu_reset.c：MCU側のデータをリセットします。
set_fs.c: DTMF サンプリング レート。
signal_mcu.c: データが利用可能であることを MCU に通知し、PLC コマンドを要求します。
split_and_insert.c: RTP ヘッダーを分割し、パケット バッファーに追加します。
rtcp.h
rtcp.c: RTCP 統計。
rtp.h
rtp.c：RTP機能。
automode.h
automode.c: 動的キャッシュ戦略。
パケットバッファ.h
packet_buffer.c: パケット キャッシュ管理。
バッファー統計.h
bufstats_decion.c: バッファー ジッターに基づいて PLC コマンドを与えます。
webrtc_neteq.h
webrtc_neteq_help_macros.h: NetEQ マクロ定義
webrtc_neteq.c：NetEQ API。
webrtc_neteq_internal.h: NetEQ 内部関数
webrtc_neteq_unittest.cc: NetEQ 単体テスト。
6. 参考資料
《GIPS NetEQ》、グローバルIPソリューション
「WebRTC 音声エンジンにおける NetEQ テクノロジーの研究」、Wu Jiangrui
「WebRTC 音声エンジンにおけるパケット キャッシング技術の研究」、Xiao Hongliang
「VoIPパケットロス処理技術の研究開発」、Li Ruwei、Bao Changchun
《ITU-T P.563 狭帯域電話アプリケーションにおける客観的な音声品質評価のためのシングルエンド方式》、国际電联ITU（国際電気通信連合）