Clever Geek Handbook

ビデオ会議でのパケット損失と戦う

はじめに





ネットワークを介したビデオ伝送について話すとき、それは主にビデオコーデックと解像度についてです。 実際、ビデオ送信についてはあまり耳にしません。 ここでは、ビデオ会議モードでビデオを送信する際のネットワーク損失と闘う問題についていくつかの光を当てたいと思います。 損失がなぜそれほど重要なのですか？ はい、少なくとも1つのビデオパッケージ（オーディオとは異なります）を取り、スキップすることはできません。 適切なビデオコーデックは、連続するフレームはそれほど変わらないという事実に基づいており、フレーム間の違いのみをエンコードして送信するだけで十分です。 （ほとんど）すべてのフレームが前のフレームに依存していることがわかります。 そして、損失のある画像はバラバラになります（ 一部はそれを好むものもありますが ）。 ビデオ会議を選ぶ理由 サークル（往復）ごとに500ミリ秒の遅延が既にユーザーを悩ませているため、リアルタイムには非常に厳しい制限があるためです。

ビデオパッケージの損失に対処する方法は何ですか？

ここでは、UDPを介した最も一般的なオプションであるRTPを介したメディア転送について検討します。



RTPおよびUDP

リアルタイムメディアは通常、RTPプロトコル（ RFC 3550 ）で送信されます。 ここでは、彼について3つのことを知ることが重要です。
  1. パッケージには順番に番号が付けられます。 したがって、シーケンス番号のギャップは損失を意味します（パケット遅延を意味する場合もありますが、その差は非常に微妙な場合があります）。
  2. RTPパケットに加えて、この規格では、何でもできるサービスRTCPパケットも提供しています（以下を参照）。
  3. 通常、RTPはUDPを介して実装されます。 これにより、個々のパッケージが迅速に配達されます。 TCPについてもう少し説明します。


ここで、IPなどのパケットネットワークについて説明していることにすぐに気付きます。 そして、そのようなネットワークでは、データはすぐに大きな部分（パケット）で破損（損失）します。 信号の単一/少数のエラー（DVBなどで人気）を回復する多くの方法は、ここでは機能しません。

歴史的な観点から損失との戦いを検討します（ビデオ会議の技術の利点は非常に新しく、単一の方法がまだ完全に期限切れになっていないわけではありません）。



受動的方法



ビデオストリームを独立した部分に分割する

ネットワーク上の会議で最初に成功したビデオコーデックはH.263です。 損失を処理する基本的な受動的な方法は、その中で十分に開発されました。 最も簡単な方法は、ビデオを互いに独立した断片に分割することです。 したがって、1つの部分からのパケットの損失は、残りの部分のデコードには影響しません。

少なくとも時間内だけでなく、空間内でも破片にする必要があります。 タイムラグは、キーフレームの定期的な（通常は2秒ごと）生成に含まれます。 これは、以前の履歴全体に依存しないフレームです。つまり、通常のフレームよりも大幅に（約5〜10倍）エンコードされます。 いくつかの損失を伴うキーフレームを生成しないと、遅かれ早かれ画像はバラバラになります。

空間では、フレームを分割することもできます。 H.263はこれにGOBを使用し、H.264のスライスを使用します。 実際、これはまったく同じものです-エンコードが互いに独立しているフレームの断片。 ただし、適切な操作のためには、スライスごとに、前のフレームの他のスライスから独立していることも確認する必要があります。 いくつかのビデオシーケンスが並列にエンコードされているように見え、そこから最終的な画像が出力で幾何学的に組み立てられます。 もちろん、これはエンコード品質を大きく損ないます（またはビットレートを増加させますが、本質的には同じです）。



2つの連続した画像のスライス間の依存関係。 オレンジは、スライスの制限がない場合、前の画像から予測できる領域を示します（つまり、これらの領域は5〜10倍効率的に圧縮できることを意味します）

ここで重要なのは、キーフレームの生成が標準的な手順である場合（たとえば、最初のフレームが常にキーである場合）、スライスの真の独立性を確保することは非常に重要なタスクであり、エンコーダーの再作業が必要になる場合があります（ただし、エンコーダーはどこから来て誰を作り直すのが難しいか） ）

エラー回復



1つの失われたスライス（パケット）を回復する例

すでに損失が発生している場合、失われたデータを既存のものから可能な限り回復することを試みることができます（エラー回復力）。 H.263コーデックに固有の標準的な方法が1つあります。失われたGOBは、周囲のGOBの線形補間によって復元されます。 しかし、一般的な場合、画像はより複雑であり、新しいフレームごとにデコードエラーが伝播されます（新しいフレームには前のフレームの損傷領域へのリンクが含まれている可能性があるため）。 一般に、多くの作業があり、2秒後にキーフレームが表示されて全体像が更新されるため、このメソッドの適切な実装が開発者の想像でのみ存在するようです。

前方誤り訂正

損失に対処する別の良い方法は、冗長データを使用することです。 必要以上に送信します。 しかし、ここでの単純な複製は、すべての点で優れたメソッドがあるため、あまり良く見えません。 これはFEC（ RFC 5109 ）と呼ばれ、次のように配置されます。 特定のサイズ（たとえば5）のメディア（情報）パケットのグループが選択され、いくつかの（ほぼ同じまたはそれ以下の）FECパケットがそれらに基づいて認識されます。 FECパケットを取得して、情報グループからパケットを回復するのは簡単です（ RFC 6015などのパリティコード）。 やや難しいが、 N個の FECパケットがグループ損失のN個の情報を確実に回復することは可能である（たとえば、リードソロモンコード、 RFC 5510 ）。 一般に、この方法は効果的で、多くの場合簡単に実装できますが、通信チャネルの点では非常に高価です。



アクティブメソッド



点滅パケットとキーフレーム

ビデオ会議の開発により、受動的な方法ではあまり達成できないことがすぐに明らかになりました。 本質的に明らかなアクティブな方法を使用し始めました-失われたパケットを再送する必要があります。 3つの異なるリセットがあります。

  1. パケットを再要求します（NACK-否定応答）。 パケットを失いました-再度要求されました-受信-デコードされました。
  2. キーフレームリクエスト（FIR-完全なフレーム内リクエスト）。 デコーダーがすべてがうまくいかず、かなり前に起こったことを理解している場合、履歴全体を消去するキーフレームをすぐに要求でき、ゼロからデコードを開始できます。
  3. フレームの特定の領域を更新する要求。 デコーダは、一部のパケットが失われたことをエンコーダに通知できます。 この情報に基づいて、エンコーダはエラーがフレーム全体にどの程度広がっているかを計算し、何らかの方法で損傷した領域を更新します。 これを実現する方法は理論的にのみ理解可能であり、実用的な実装を見たことはありません。


私はメソッドにやや決心しました-しかし、これが実際にどのように実装されているか。 しかし実際には、RTCPパケットがあります-ここではそれらを使用できます。 そのような要求を送信するための少なくとも3つの標準があります。



アクティブなメソッドは、パッシブなメソッドよりも実装がはるかに難しいことは明らかです。 そして、リクエストを形成したり、パケットを再送信したりすることが難しいわけではありません（3つの標準のサポートが同時に問題を複雑にしますが）。 そして、再要求が早すぎる（「失われた」パケットがまだ届いていないとき）や遅すぎる（画像を表示する時間になったとき）ように、ここで何が起こっているかを制御する必要が既にあるためです。 ネットワークで一時的な大きな問題が発生した場合、受動的な方法は2秒以内に通信を復元します（キーフレームの到着）。 ）



再リクエストの素朴な実装による3秒の切断後にビデオがフリーズする例。

しかし、これらのメソッドは適切に実装されているため、はるかに優れています。 キーフレームの生成、スライス、またはFECパケットに場所を与えることによって品質を低下させる必要はありません。 一般に、非常に小さなビットレートのオーバーヘッドは、「高価な」受動的な方法と同じ結果で達成できます。

TCP

TCPが使用されない理由は多かれ少なかれ明らかになりました。 これは、パッケージを再要求する最も単純な方法であり、パッケージを制御する真剣な能力はありません。 さらに、パッケージの再要求のみを提供し、いずれの場合もキーフレームの再要求を最上部に実装する必要があります。



スマートメソッド



ここまでは、損失との戦いのみを懸念していました。 しかし、チャネル幅はどうですか？ はい-チャネル幅は重要であり、最終的には同じ損失（およびパケット配信時間の増加）で現れます。 ビデオコーデックが通信チャネルの幅を超えるビットレートに設定されている場合、この場合の損失に対処しようとするのは意味のない作業です。 この場合、コーデックのビットレートを下げる必要があります。 ここからすべてのトリックが始まります。 設定するビットレートを決定する方法は？

主なアイデアは次のとおりです。



一般に、ビデオ会議システムの品質を決定するのは、ネットワークパラメータを評価し、今日調整するためのインテリジェントな方法です。 真面目なメーカーはそれぞれ独自のソリューションを持っています。 そして、今日のビデオ会議システムの主な競争上の優位性は、この技術の開発です。

ところで、 3GPP TS 26.114標準 （産業用VoIPネットワークを構築するための主要な標準の1つ）には、オーディオ用の同様のアルゴリズムの記述が含まれていると記載されています。 記述されたアルゴリズムがどれほど適切かは明らかではありませんが、ビデオには適していません。



アーティストの視点でネットワーク条件に適応するためのアルゴリズムのステートマシン（3GPP TS 26.114より）


More articles:


All Articles