赤：冗長性を備えた音質の向上

2020年4月に、Citizenlabは、Zoomの暗号化がかなり弱いことを報告し、ZoomがSILKオーディオコーデックを使用していると述べました。残念ながら、この記事にはこれを確認し、将来参照する機会を与えるための初期データが含まれていませんでした。しかし、おかげナタリーSilvanovichからGoogleのProject ZeroのそしてFridaトレースツールに、いくつかの生のSILKフレームのダンプを取得することができました。彼らの分析から、WebRTCがオーディオを処理する方法を調べるようになりました。一般的に知覚される通話品質に関しては、小さなグリッチでさえ気付く傾向があるため、最も影響を与えるのはオーディオ品質です。WebRTCが提供する音質を改善するためのオプションを探すという、実際の冒険に着手するには、わずか10秒の分析で十分でした。



2017年に（DataChannelの投稿の前に）ネイティブのZoomクライアントを扱ったところ、そのオーディオパッケージがWebRTCベースのソリューションパッケージと比較して非常に大きい場合があることに気付きました。



上のグラフは、特定のUDPペイロード長を持つパケットの数を示しています。150〜300バイトのパケットは、通常のWebRTC呼び出しと比較すると異常です。それらは、通常Opusから取得するパケットよりもはるかに長くなります。フォワードエラーコントロール（FEC）または冗長性があると思われましたが、暗号化されていないフレームにアクセスできなければ、さらに結論を導き出したり、何かをしたりすることは困難でした。



新しいダンプの暗号化されていないSILKフレームは、非常によく似た分布を示しました。フレームをファイルに変換してから短いメッセージを再生した後（非常に役立つブログ投稿をしてくれたGiacomo Vaccaに感謝します）必要な手順を説明します）Wiresharkに戻り、パッケージを確認しました。これは私が特に興味深いと思った3つのパッケージの例です：

packet 7:
e9e4ab17ad8b9b5176b1659995972ac9b63737f8aa4d83ffc3073d3037b452fe6e1ee
5e6e68e6bcd73adbd59d3d31ea5fdda955cbb7f

packet 8: 
e790ba4908639115e02b457676ea75bfe50727bb1c44144d37f74756f90e1ab926ef
930a3ffc36c6a8e773a780202af790acfbd6a4dff79698ea2d96365271c3dff86ce6396
203453951f00065ec7d26a03420496f

packet 9:
e93997d503c0601e918d1445e5e985d2f57736614e7f1201711760e4772b020212dc
854000ac6a80fb9a5538741ddd2b5159070ebbf79d5d83363be59f10ef
e790ba4908639115e02b457676ea75bfe50727bb1c44144d37f74756f90e1ab926ef
930a3ffc36c6a8e773a780202af790acfbd6a4dff79698ea2d96365271c3dff86ce6396
203453951f00065ec7d26a03420496f
e9e4ab17ad8b9b5176b1659995972ac9b63737f8aa4d83ffc3073d3037b452fe6e1ee
5e6e68e6bcd73adbd59d3d31ea5fdda955cbaef

パッケージ9には、2つの以前のパッケージ、パッケージ8-1つの以前のパッケージが含まれています。この冗長性は、SILKデコーダーの詳細な調査によって示されたLBRR-低ビットレート冗長性フォーマットの使用によって引き起こされます（Skypeチームが提供するインターネットプロジェクト、またはGitHubのリポジトリにあります）。





ZoomはSKP_SILK_LBRR_VER1を使用しますが、2つのフォールバックパッケージがあります。各UDPパケットに現在のオーディオフレームだけでなく、前の2つのオーディオフレームも含まれている場合、3つのパケットのうち2つを失っても、堅牢になります。では、ズームの音質の鍵はおばあちゃんのSkypeシークレットレシピかもしれません。

Opus FEC

WebRTCで同じことをどのように達成できますか？次の明らかなステップは、OpusFECを検討することでした。



SILKのLBRR（低レート予約）はOpusにもあります（Opusはビットレート範囲の下限にSILKを使用するハイブリッドコーデックであることを忘れないでください）。ただし、Opus SILKは、エラー制御モードで使用されるLBRRの一部であるように、ソースコードがかつてSkypeによって検出された元のSILKとは大きく異なります。



Opusは、元のオーディオフレームの後にエラー制御を追加するだけでなく、その前にあり、ビットストリームにエンコードされます。Insertable Streams APIを使用して独自のエラー制御を追加してみましたが、実際のパケットの前に情報をビットストリームに挿入するには、完全なトランスコーディングが必要でした。





取り組みは成功しませんでしたが、LBRRの影響に関するいくつかの統計が生成されました。これを上の図に示します。 LBRRは、パケット損失を大きくするために最大10 kbps（またはデータレートの3分の2）のビットレートを使用します。リポジトリはここから入手できます。これらの統計はのWebRTCを呼び出したときに表示されていないgetStats() APIを、その結果は非常に興味深いものでした。



OpusFECの問題はトランスコーディングだけではありません。結局のところ、WebRTCでの設定はやや役に立たない。

• , , - . Slack 2016 . , .
• 25%. .
• FEC (. ).

ターゲットの最大ビットレートからFECビットレートを差し引くことはまったく意味がありません-FECはメインストリームのビットレートを積極的に削減しています。通常、ビットレートストリームが低いと、品質が低下します。 FECで修正できるパケット損失がない場合、FECは品質を低下させるだけで、品質を向上させることはありません。なぜそれが起こるのですか？主な理論は、輻輳がパケット損失の理由の1つであるということです。輻輳が発生している場合は、問題を悪化させるだけなので、これ以上データを送信したくないでしょう。しかし、EmilIvovが2017年の素晴らしいKrankyGeekの講演で説明しているように輻輳が必ずしもパケット損失の原因であるとは限りません。さらに、このアプローチでは、付随するビデオストリームも無視されます。比較的小さな50kbpsのOpusストリームとともに数百キロビットのビデオを送信する場合、Opusオーディオの輻輳ベースのFEC戦略はあまり意味がありません。おそらく将来的にはlibopusにいくつかの変更が加えられるでしょうが、現在WebRTCでデフォルトで有効になっているため、今のところ無効にしようと思います。



これは私たちには適さないと結論付けます...

赤

真の冗長性が必要な場合、RTPには冗長オーディオデータのRTPペイロード（RED）と呼ばれるソリューションがあります。それはかなり古いです、RFC2198は1997年に書かれました。このソリューションでは、タイムスタンプが異なる複数のRTPペイロードを、比較的低コストで同じRTPパケットに入れることができます。



REDを使用して各パケットに1つまたは2つの冗長オーディオフレームを配置すると、OpusFECよりもパケット損失に対してはるかに堅牢になります。ただし、これは、オーディオビットレートを30kbpsから60または90kbpsに2倍または3倍にすることによってのみ可能です（ヘッダー用に10 kbpsを追加）。ただし、1秒あたり1メガビットを超えるビデオデータと比較すると、それほど悪くはありません。



WebRTCライブラリには、RED用の2番目のエンコーダとデコーダが含まれていました。未使用のオーディオREDコードを削除しようとしたにもかかわらず、このエンコーダーを比較的少ない労力で適用することができました。ソリューションの完全な履歴は、 WebRTCバグ追跡システムで入手できます。



また、Chromeが次のフラグで始まるときに含まれる試用版として利用できます。

--force-fieldtrials=WebRTC-Audio-Red-For-Opus/Enabled/

次に、SDPネゴシエーションを介してREDを有効にできます。次のように表示されます。

a=rtpmap:someid red/48000/2

追加の帯域幅を使用することはお勧めできない環境があるため、デフォルトでは有効になっていません。 REDを使用するには、Opusコーデックの前に来るようにコーデックの順序を変更します。これは、ここにRTCRtpTransceiver.setCodecPreferences示すようにAPIを使用して実行できます。明らかに別の方法は、SDPを手動で変更することです。 SDP形式でも最大予約レベルを設定する方法を提供できますが、RFC 2198のオファーと応答のセマンティクスが完全に明確ではなかったため、これをしばらく延期することにしました。オーディオの例



で実行することで、これがすべてどのように機能するかを示すことができます。これは、1つのバックアップパッケージを使用した初期バージョンの外観です。





デフォルトでは、ペイロードのビットレート（赤い線）は、冗長性がない場合のほぼ2倍で、ほぼ60kbpsです。DTX（Discontinuous Transfer）は、音声が検出されたときにのみパケットを送信する帯域幅節約メカニズムです。予想どおり、DTXを使用すると、通話の最後に表示されるように、ビットレートの影響が多少緩和されます。







パケット長をチェックすると、期待される結果が示されます。パケットは、以下に示すペイロード長の通常の分布と比較して、平均して2倍の長さ（背が高い）です。



これは、部分的な予約が見られたZoomの機能とはまだ少し異なります。比較を確認するために、前に示したズームパケット長グラフをもう一度見てみましょう。

音声アクティビティ検出（VAD）サポートの追加

Opus FECは、パケットに音声アクティビティがある場合にのみバックアップデータを送信します。同じことがREDの実装にも当てはまります。このため、SILKレベルで定義されている正しいVAD情報を表示するようにOpusエンコーダーを変更する必要があります。この設定では、ビットレートは音声が存在する場合にのみ60 kbpsに達します（一定の60+ kbpsと比較して）。





そして、「スペクトル」は、ズームで見たもののようになります。





これを達成するための変更はまだ現れていません。

適切な距離を見つける

距離は、バックアップパケットの数、つまり、現在のパケットの前のパケットの数です。適切な距離を見つける作業をしていると、距離1のREDが涼しい場合、距離2のREDはさらに涼しいことがわかりました。私たちの研究所の見積もりでは、60％のランダムなパケット損失をシミュレートしました。この環境では、Opus + REDのパフォーマンスは優れていましたが、REDのないOpusのパフォーマンスははるかに劣っていました。 WebRTC getstatsを（）APIは、分割して得られた隠された試料の割合と比較することによって、これを測定するための非常に有用な機能を提供concealedSamplesをすることによってtotalSamplesReceivedを。



オーディオサンプルページでは、コンソールに貼り付けた次のJavaScriptスニペットを使用して、このデータを簡単に取得できます。

(await pc2.getReceivers()[0].getStats()).forEach(report => {
  if(report.type === "track") console.log(report.concealmentEvents, report.concealedSamples, report.totalSamplesReceived, report.concealedSamples / report.totalSamplesReceived)})

あまり知られていないが非常に便利なフラグを使用して、いくつかのパケット損失テストを実行しましたWebRTCFakeNetworkReceiveLossPercent。

--force-fieldtrials=WebRTC-Audio-Red-For-Opus/Enabled/WebRTCFakeNetworkReceiveLossPercent/20/

20％のパケット損失とデフォルトで有効になっているFECでは、オーディオ品質に大きな違いはありませんでしたが、メトリックにはわずかな違いがありました。



REDまたはFECがない場合、メトリックは要求されたパケット損失とほぼ一致します。FECの効果はありますが、小さいです。



REDがないと、60％の損失で音質がかなり悪くなり、少しメタリックになり、言葉が理解しにくくなりました。



REDでは距離= 1の可聴アーティファクトがいくつかありましたが、距離2（現在使用されている冗長性の量）ではほぼ完全なサウンドでした。

人間の脳は不規則に起こるある程度の沈黙に耐えることができるという感覚があります。（そして、Google Duoは沈黙を埋めるために機械学習アルゴリズムを使用しているようです。）

実世界でのパフォーマンスの測定

OpusにREDを含めることで音質が向上することを願っていますが、場合によっては悪化することもあります。 Emil Ivovは、POLQA-MOSメソッドを使用していくつかのリスニングテストを実施することを志願しました。これはすでにOpusに対して行われているため、比較のためのベースラインがあります。

最初のテストで有望な結果が示された場合は、上記で使用した損失率の指標を適用して、JitsiMeetのメインスキャンで大規模な実験を行います。



メディアサーバーとSFUの場合、すべてのクライアントがRED会議をサポートしているわけではないかのように、サーバーが選択したクライアントへのREDリレーを管理する必要がある場合があるため、REDの有効化は少し難しいことに注意してください。また、一部のクライアントは、REDが不要な限られた帯域幅のチャネル上にある場合があります。エンドポイントがREDをサポートしていない場合、SFUは不要なエンコーディングを削除し、ラッパーなしでOpusを送信できます。同様に、RED自体を実装し、Opusを送信するエンドポイントからREDをサポートするエンドポイントにパケットを再送信するときに使用できます。



このエキサイティングな冒険を後援してくれたJitsi / 8×8Incと、必要な変更について分析してフィードバックを提供してくれたGoogleの人々に感謝します。



そして、ナタリー・シルバノビッチがい​​なかったら、私は暗号化されたバイトを見て座っていただろう！