WebRTC最新情報 #4 ~M92リリース、Slack Huddlesローンチなど~

こんにちは、SkyWay TechSol（テクニカルソリューション）チームのmonmeeです。

いつの間にか夏も終わりが近づいて来ていますが、皆さまいかがお過ごしでしょうか。
私は今月、人生5回目のお引越しを済ませて、新居での生活を送っています。広いリビングに大きめのテレビとソファが置けるようになって控えめに言って最高ですね。

さて、今回は久しぶりの投稿となりますが、WebRTC最新情報シリーズの第4回目になります。

WebRTC最新情報では、WebRTC業界の最新情報やブラウザのWebRTC実装状況について定期的に皆様にお届けします。主な調査元サイトは以下です。

・WebRTC Discuss: WebRTC全般についての議論が行われるGoogle Groupです。
・Chromium bugs: Chromiumブラウザに関する不具合情報が集約するサイトです。
・Bugzilla: Firefoxブラウザに関する不具合情報が集約するサイトです。
・Safari Webkit Bugs: Safariブラウザに関する不具合情報が集約するサイトです。
・BlogGeek.me: testRTCの創業者Tsahi氏が運営するWebRTC情報サイトです。
・WebRTC Weekly: Tsahi氏が運営するWebRTC関連ニュースをまとめたサイトです。
・webrtcHacks: WebRTC愛好家が運営するWebRTC開発者向けブログです。
・rtcsec: リアルタイム通信（特にSIP、VoIP、WebRTC）のセキュリティに特化して言及するブログです。

【免責事項】 
本調査は素早く幅広い調査を目的としており、本記事にて提供する情報の正確性・妥当性につきましてはその保証をするものではありません。ご意見があれば以下までお問い合わせください。
☞ https://support.skyway.io/hc/ja/requests/new

------------

[libwebrtc] M92リリース

PSA: WebRTC M92 Release Notes

7/8にM92がリリースされました。主な変更点は以下です。

1. AndroidでもPerfect Negotiationができる様に改良

12609 - webrtc - Web-based real-time communication - Monorail

Perfect Negotiationとは、WebRTCの複雑なネゴシエーションをキレイに行うためのクライアント側処理のことです。
これまでPerfect NegotiationはChromiumブラウザ(PC/iOS/Android)とFirefox(PCのみ)、そしてiOSで利用可能でしたが、今回Androidも対応となりました。
※Safariは現在、Perfect Negotiationに対応していません。

2. Unified Plan SDPでChromeが複数のBUNDLEをサポートできていないバグを修正

10208 - webrtc - Web-based real-time communication - Monorail

これまで、mセクションのバンドルがChromeでは1つしかサポートされておらず、2つ目以降は個別にSDPが生成される様になっていました。

これはdraftで定義された仕様とは違ったため、M92から修正となりました。

[Safari] iPadOS 15でVP9がハードウェアアクセラレーション対応

Apple Developer Documentation

Safari 15のβ版リリースノートによると、iPadOSのバージョンが15である全てのiPadで、VP9とWebMのハードウェアアクセラレーションが可能になるようです。

Added hardware accelerated VP9 and WebM in MSE on all iPads that support iPadOS 15.

Safari 15のリリースは今秋を予定しています。

[Release] Slack Huddlesがローンチ

Slack ハドルミーティングで話して問題を解決する

6/30に、SlackがHuddlesという音声チャット機能を追加しました。

Huddlesの通話プロトコルにはWebRTCが利用されており、WebRTCプラットフォームにはAmazon chimeが採用されています。

[Chromium] 一画面で利用できる映像・音声メディア数の制限が入った

1232649 - chromium - An open-source project to help move the web forward. - Monorail

Dealing with HTMLMediaElements and srcObjects in WebRTC applications - webrtcHacks

Chrome M92より、一画面で利用可能なWebMediaPlayersのインスタンス数、つまり映像・音声メディアの数に制限が入りました。
しかし、その後の議論で制限は緩和されました。

変更から修正までの背景を簡単にお伝えします。

WebMediaPlayersは、通話終了後もインスタンスが破壊されずメモリリークを引き起こすという問題を元々持っていました。

この問題を助長しないために、WebMediaPlayersインスタンスの生成上限数の制限がM92より実装されました。当初は、デスクトップブラウザは75、モバイルブラウザでは40がWebMediaPlayersの生成上限数として設定されました。
それ以上のWebMediaPlayersインスタンスを作成しようとすると、以下エラーが発生します。

[Intervention] Blocked attempt to create a WebMediaPlayer as there are too many WebMediaPlayers already in existence. See [crbug.com/1144736#c27](http://crbug.com/1144736#c27)

しかし、この変更に対し即座に変更を元に戻す要望が多くあがりました。

なぜなら、WebRTCを用いた多人数通話ユースケースにおいてこの変更は致命的だからです。

例えば、最小38人の双方向ビデオ通話時に上記エラーが発生して通話出来なくなる可能性があります。これは、videoタグとaudioタグを別々に利用していた場合、1人あたり2つのWebMediaPlayersが必要になるためです。

議論の結果、2021/8/3にWebMediaPlayersの生成上限数を1000まで拡張する修正が入りました。

最新版のChromeでは38人以上で双方向ビデオ通話をしてもエラーは発生しなくなるはずです。

[Chromium] Capture HandleがM92からオリジントライアル中

Capture handle - Chrome Platform Status

Identifying Shared Tabs using Capture Handle (Elad Alon) - webrtcHacks

M92よりCapture Handleがオリジントライアル提供されました。

現在の画面共有機能には以下のような課題があると言及されています。

・画面共有するWebRTCアプリケーションはgetDisplayMediaによって画面共有しているアプリケーションが何か認識できない
・キャプチャされるアプリケーションはキャプチャされていることを認識できない

上記を可能にし、両アプリケーション間でコラボレーションを生み出そうという動機のもと生まれたのがCapture Handleです。

Capture Handleの使用用途は以下の4つになります。

1. 別タブを操作するAPIの提供

例えば別タブの資料を画面共有して、別タブに移らずとも次のページに移動させたりすることが可能になります。
デモはこちら。

2. 合わせ鏡にならないようにエラーを吐く機能

WebRTCアプリケーションと同じタブを画面共有しようとした時にエラーを吐くようになります。
共有した画面の映像が合わせ鏡のようになるのを防ぐことができます。
デモはこちら。

3. 間違ったタブを画面共有しないように警告を出す機能

PermittedOriginsに設定されていないタブを共有しようとした場合、ダイアログを表示して警告します。
機密情報を誤って画面共有しないようにするためのセキュリティ施策として有効です。

4. 画面共有先の分析

どのアプリケーションを画面共有しようとしているかを取得、分析できるようになります。

------------

最後までお読みいただきありがとうございました。
今後もWebRTCに関する最新情報をお届けしていくので、お楽しみに！

▼SkyWayサービスサイトはこちら▼
https://webrtc.ecl.ntt.com/