- オンラインストア向けのオンラインコンサルティングシステムを構築して、ウェブサイトの訪問者が通常のメッセンジャーに座っているコンサルタントとビデオ会話を行えるようにします。
- ブラウザ以外に何も持っていない参加者を接続する機能を備えたPolycomベースの電話会議システムを補完したいと考えています。
技術
前の記事のすべての計算を完全に繰り返すのではなく、結論に直行します。 したい場合：
- サポートされているすべてのデスクトップブラウザー
- 追加のソフトウェアをインストールする必要はありません
- システムはネットワーク干渉に耐性がありました
- 遅延は最小限でした
Adobe Flash Playerのビデオサポート
Flashは現在、いくつかのコーデックで圧縮されたストリームを再生できます。
- H264
- ソレンソンスパークH263
- On2 vp6
- フラッシュ画面ビデオ
カメラからのビデオのキャプチャとエンコードにより、すべてがさらに悪化します。 H264コーディングのサポートは、最近リリースされたFP11でのみ登場し、それ以前は、唯一のオプションはSorenson Sparkでした。 残念ながら、11番目のバージョンは大多数のユーザーによってまだインストールされていないため、FP10のみを使用しているユーザーを考慮する必要があります。
また、私たちは誰を扱っているかを忘れてはなりません。 Adobeは、Flash Playerバージョン11.0-11.2で特定のタイプのH264ストリームの再生を「中断」することができました。 問題は、packetization-mode：0でパケット化されたストリームを再生することです。つまり、このモードはほとんどのソフトフォンで使用されます。 バグの詳細は、同社のバグトラッカーで見つけることができます。
結果は次の図です。 H264を介してSIPクライアントに正常に接続するには、次のものが必要です。
- ユーザーが11より前のFPバージョンを使用している場合、Sorenson-> H264を一方向にトランスコードします
- ユーザーが前述のバグでFP 11を使用している場合、 H264-> H264 （パケット化を変更するため）を一方向にトランスコードします
- その他の場合はすべて、トラフィックをそのまま許可します。
ビデオは音声ではありません
一見すると、ビデオと音声の伝送の唯一の違いは、使用するチャネルの幅にあるように思えるかもしれません。 これは確かに真実ですが、いくつかの重要な違いがあります。
オーディオストリームは通常10〜20ミリ秒のフレームに分割され、各フレームは他のフレームとは別にエンコードおよびデコードされます。 ビデオの場合、これは無駄が多すぎるため、ほとんどのフレームでは、画像自体がエンコードされるのではなく、前のフレームとの違いがあります。 さらに優れた圧縮のために、オブジェクトの動きを補正するために、わずかに「シフトされた」前のフレームで差が取られます。 一般に、ビデオ圧縮に関する一連の記事を個別に作成できますが、これについては詳しく説明しません。
別のことが重要です。 オーディオストリームの1つのフレームが失われた場合、たとえば、前のフレームを再び失うなど、単純にそれを隠すことができ、ほとんど気付かないでしょう。 ただし、このようなトリックはビデオでは機能しません。これは、失われたフレームに後続のフレームを重ねる必要があるためです。 ここから、リモート側に独立して圧縮されたキーフレームを送信するように依頼しない限り、アーティファクト自体は消えないように見えます。 SIPでは、これは2つの方法で実行できます。SIPINFOを介したシグナリングレベルと、RTCPを介したメディアレベルです。
次に、会話の参加者間のチャネルのMTUの制限を考慮する必要があります。これは通常、約1500バイトです（NATの場合、IPフラグメンテーションに依存することはできません）。 オーディオフレームはこのような制限に適合しますが、ビデオフレームはほとんどの場合適合しません。 したがって、フレームを断片に分割する必要性は、パケット化と呼ばれ、Flash Playerの一部のバージョンのバグに関連付けられています。
結果
その結果、すべてのレーキを注意深く調べ、必要な量の干し草をどこにでも散布すれば、完全に機能するソリューションを得ることができます。 ブラウザからのビデオコールのサポートをクラウドベースのRTCKitプラットフォームに統合することができました。これにより、この機能を数時間で任意のWebサービスに統合し、多くの時間を節約できます。
テストページに登録せずにこれらすべてをテストできます 。 そこのビデオの解像度は352x288に制限されています。 JitsiおよびLinPhoneソフトフォンをテストしましたが 、H264をサポートしている他のクライアントに関するレビューを聞くのは興味深いでしょう。 habr効果による負荷に耐えようとします！ 重要な注意：ブラウザーからブラウザーへRTCKitを介して呼び出し、同時に非常に友好的なNATを使用する場合、説明されているすべての代わりに、RTMFP Peer-2-Peerテクノロジーが使用されます。
今後の記事では、音声およびビデオ会議、通話ルーティング、モバイルデバイスとの対話のトピックを取り上げます。 お楽しみに。