新しいバージョンのWebSDK-v4があります。 これはパブリックベータ版にすぎませんが、ほとんどの日常的なケースでは既に安定しています。 新しいバージョンの下位互換性を維持しようとしました。
また、更新されたプラットフォーム-v3。 新しくて面白いものがたくさんあります。 すべてがより速く、より楽しく機能します。 以下の詳細について。
ご覧のとおり、ダブルストライクがあります！ カットの下で-クロスデバッグ、継続的な改善と痛みの6ヶ月で何が起こったのか。 ネタバレ：もう古代のフラッシュはありません。 純粋なWebRTC + ORTCのみ。
SDKの新機能
TypeScriptのすべてを書き直しました。 文字通り、すべての行とSDKはゼロから機能します。 主な理由はサポートでした。 Typescriptは、Vanilla JSよりも保守がはるかに簡単です。 危険なステップを踏むと、より頻繁にアップデートを提供できます。 さらに、すぐにお気に入りの言語の新しいtsdファイルを紹介します。
SDKの重量は12 KBだけ増加しました。 それがTypeScriptを導入する価格でした。 音声通話とビデオ通話を行う場合、これは小さな問題です。 111 KBのボリュームで混乱している場合は、非同期ブートモードを使用することをお勧めします。 一般に、スクリプトをダウンロードするには常に非同期を使用することをお勧めします。 ユーザーを待つ余分な瞬間も私たちを混乱させます。
すべてをWebpackで組み合わせます。 SDKの以前のバージョンは、Gulp、sh、および神のヘルプの助けを借りて構築されました。 安定した自動枯渇と構成の容易さ、ドキュメントの自動アセンブリ、npmモジュールのアセンブリ、tsd、自動バージョン管理が必要でした...私は永遠に続けることができ、誰でもこのリストに個人的なDevOpsの望みからいくつかのポイントを追加できます。 そして、たまたまWebpackが私たちが望むことを何でもできるようになりました。 また、高速に動作します。
Microsoft Edgeとの音声通話を利用可能にします。 WebRTCの代わりにORTC、StackOverflowのソリューションの欠如（Ctrl + C-> Ctrl + Vは私たちを救うことができませんでした）、地獄のMSサポートの7つの円、文書化されていないエラー。 私の前の記事で、1人のハリネズミと1人の別々のプログラマーの痛みと苦しみについて読むことができます。 SDKのミトンを作成し、便利なAPIにするために、開発サイクルのかなりの部分を占めました。 その結果、Edgeユーザーと話すことができ、彼らはあなたと話すことができます。 間もなくVP9がEdgeに表示されます-お互いを見ることができます。
h 264コーデックに優先順位を付けるか、他のコーデックに優先順位を設定できます。 通常、モバイルデバイスには、h264ハードウェアエンコーディング/デコーディングとVP8ソフトウェアエンコーディング/デコーディングがあります。 デフォルトの優先度でChromeを使用してモバイルを呼び出す場合、VP8が選択されます。 ソフトウェアレンダリング。 彼と一緒にゲームをした人は、これが痛みであることをすぐに知っています。 残念ながら、ブラウザの場合、ほとんどの場合はその逆です。 これにより、WebSDKを使用してモバイルアプリケーションにエネルギー効率の高い呼び出しを行ったり、特殊な鉄やケースのコーデックに優先順位を付けたりすることができます。
通話中にビデオのオン/オフを切り替えることができます。 これは再交渉です！ 再ネゴシエーションとは、動画をオン/オフした瞬間にブラウザの機能を再交換することです。 ポールで説明します。 Paul A.がPaul B.を声で呼んだとします。 2人のポールは、ブラウザで喜んでコミュニケーションを取ります。 ここで、Pavel B.はPavel Aに新しい両頭の亀を見せたいと思っています。再交渉がなければ、音声通話を終了してビデオを開始する必要があります。 そして今、ポールは中断することはできません。 確かに、彼らは再交渉について決して知ることはありません。 Pavel B.がボタンを押すと、SDKの力で彼はPaul A.！ さらに、パブロフの1人は自分のビデオを表示できますが、2人目はそうではありません。 スカイプのように。
保留/保留解除はWebRTCによって行われ、ピアツーピアモードで動作するようになりました。 保留-これは、通話を保留にし、魔法のように音とビデオが出ない場合です。 保留解除とは、コールを保留から解除し、魔法のようにすべてが再びオンになることです。 SDKの古いバージョンにもこのような機能がありましたが、サーバーはサウンドストリーム間の障壁になりました。 トラフィックはオンでした。 今、トラフィックは行きません。 ブラウザーは、サーバーまたは他のクライアントに、交換を一時的に中断し、誰もが満足していることを通知します。 少ないトラフィックと長いバッテリー寿命。
アイデアを実現するためのフィルターとマスク。 着信オーディオストリームを受け取り、シマリス音声を作成できます。 発信してダースの声を送ってください。 同時に圧縮とミトールを追加します！ ビデオストリームを取得し、キャンバスとニューラルネットワークで実行し、ピカソスタイルの口ひげを追加できます。 あなたが決める！ ブラウザでMSQRDを提供してください！
サーバー側の新しいもの
オーディオとビデオの遅延が減少しました。 呼び出しパターンを変更しました。 RTPトラフィックは1つのサーバーを通過し、3つのサーバーのチェーンを通過する前になりました。 テストでは、両方向で180m / sの遅延の減少が示されました。
Chromeの不良ネットワークでの作業を改善しました。 REMBテクノロジーのサポートが追加されました。 このテクノロジーを使用すると、弱いチャンネルの画像と音質を制御できます。 弱いネットワークでのon音や音の損失を防ぎます。 この技術はスマートであり、良好な接続で信号品質を低下させることはありません。 また、接続の品質が急上昇した場合は、微調整されます。
これで、サーバー側のシナリオでのみ、P2P / ViaServer呼び出しの方法を選択できます。 プラットフォームは、PeerToPeerとメディアサーバーの2つのモードで動作します。 ピアツーピアでの作業の場合、メディアトラフィックはサブスクライバーからサブスクライバーに直接送られます。 私たちもあなたもそれを見ることができず、例えば、それを記録したり電話網に送ったりすることはできません。 サーバーシナリオでは、すべての利点を備えたすべてがサーバーを通過します。 以前は、これら2つのシナリオのクライアントアプリケーションは異なっていました-呼び出しの開始時にX-DirectCallフラグを渡す必要があり、VoxEngineスクリプトでもすべてが正しく処理されました。 これですべてが簡単になりました。 決定はVoxEngineスクリプトで行われます。 コールの開始時に、サーバーコールが必要か、ピアツーピアだけが必要かを判断して、サブスクライバを正しく接続できます。
FirefoxとChromeでオーディオ/ビデオトラックが同期されるようになりました。 クラウド側では、同期コンテキストのインテリジェントな選択、RTCP統計に基づく遅延の計算があります。 ブラウザは、同期コンテキストに従って、オーディオとビデオのペアを正しく収集します。 些細なことですが、すてきです-過去を見る必要はありませんが、現在を聞いてください。
戦闘損失
古いメッセージングAPIを削除しました。 ネタバレはほとんどありません-私たちはそれをより良く、より新鮮で、より速く、よりセクシーにします。 まもなく、チームリーダーが解決すると、パブリックベータ版に移行します。 それまでの間、その場所には一時的に何もありません。
Flashをアンインストールしました。 Googleがこれに積極的に関与しているのとは異なり、SDKからのみ、Webからでもこれを行うことはできません。 私たちの喜びに制限はありませんが、これには少し悲しみもあります。 忠実なSafariおよびIEユーザーは、WebRTCをシミュレートするためにTemasysプラグインを使用する必要があります。 ユーザーがRunetの4.9％とまったく同じ場合は、更新されるまで少し待つか、古いバージョンのSDKを使用することをお勧めします。
結論として、 ドキュメンテーションを更新し、新しいバージョンのSDKのテクニカルサポートをすばやく得ることができるgitterチャンネルを開いたすべてを言いたいと思います。 それをテストします。
