【Microsoft Teams】帯域制限ポリシーの動作は謎
シレっと動作の変更が行われる事は常である。この記事は2022/11/05の環境で検証されました。
Teamsの帯域制限ポリシーとは、は以下
https://learn.microsoft.com/ja-jp/microsoftteams/meeting-policies-audio-and-video#media-bit-rate-kbs
会議ポリシーとか名前からアレな翻訳のポリシーに属しているメディアビットレートポリシー。会議ポリシーって会議毎に割り当てられるポリシーだと思うじゃん？残念、ユーザーに割り当てるポリシーである。ビデオ「会議」の際に適用されるので会議ポリシー。
それはさておき、ざっと説明文だけ読めば個人単位、またはグループ単位での、音声・動画の使用帯域を制限するポリシーなのだろう。重役は無制限、ヒラは200kbpsくらいが上限で。つまりはこんな感じか。
では何が謎なのか？
実際にやってみる
そもそも帯域と言っても、登りと下りの2種類ある。いわゆる「ギガが足りない」に沿って一般的に考えれば、少なくとも下りは制限されるだろう。だが何事も検証が大事。
3名会議の検証環境を用いる。内訳は1名だけ上限150kbps(18.5KB/s)、他2名は無制限だ。
150kbpsというのは、ビデオ会議の最小要件から採用した。
https://learn.microsoft.com/ja-jp/microsoftteams/prepare-network#bandwidth-requirements
制限アリをA、制限なしをB,Cと呼称。3つ全てのマイクをミュートし、以下４つの検証を行った。
- Aのカメラのみオン、B,Cはオフ
- Bのカメラのみオン、A,Cはオフ
- B,Cのカメラをオン、Aはオフ
- 全員のカメラをオン
まずは上記リストの１から。下の図1の最上部が上限設定アリのユーザーのプロセスである。
はい、登り無制限が確定しました。そしてB,C共に高画質のビデオを受信している。
次にリスト2番目の結果が下の図２である。
ファ？？？
なるほど、Aの受信速度は納得。設定した150kbps以下である。しかし帯域無制限のはずのCも影響を受けている。なぜなら、カメラをオンにしたBのアップロード速度が制限されているからだ。ここで一つの事実が浮上する。
帯域制限が適用されるのは、受信側ではなく送信側であるという事。
さらにリスト３番目の検証を行う。結果は以下の図３。
Aの帯域制限を守るように、BとCのアップロードがさらに制限される。動画はもうコマ送り状態。
そして最後に全員のカメラをオンにする。結果は以下の図４。
なんとも言えない結果になった。Aのアップロードは制限を受けていない。A以外の会議参加者が帯域無制限であるためだろう。逆にBとCのアップロードはAの帯域制限と合わせる為に低画質配信となった。よってB視点で見ると、帯域制限を受けているはずのAが高画質で見えており、無制限のCはコマ送りとなっている。
社長Cがコマ送りであるにも関わらず、ヒラのAがイキイキと動く姿。部長Bには思うところがあるかもしれない。
結論
以上の検証結果をまとめる。
受信側に一人でも帯域制限ポリシーを適用された人物が居る場合、送信側はその帯域制限に合わせた送信しか行わない。よって、全員に配信される画質が低下する。
「こいつが参加する時だけ回線の調子悪いな」
そんな人を作りたい時にだけ使うポリシーである。重役だけの会議は高画質で。そんな思惑で使えない事も無い。が、そこに1人のヒラが参上すると仮定する。画面内でコマ送りになる重役たちをしり目に、ヒラは無駄にモニターの中で躍動する事となるだろう。
”なんでこいつだけこんなに滑らかに動くの？”
そんな質問が上級職から飛び出そうな組織のSEは、ネットワーク状況を鑑みてグローバルで帯域制限してしまうほうが無難だと思う。
社外の相手にはこちらの映像が鮮明に見え、しかし社内間では常に低画質。または社外に繋ぐ人は制限からリストアウトしておく。
実用として思いつくのはこの程度だろうか。それ以外あるかな？トリッキーすぎて思いつかない。
考察
こういう挙動になってしまうのは、Teamsのアプリが送信元で映像のエンコードを行っているからだと思う。AWS上のTeamsサーバーはブロードキャスティング程度しか担っておらず、受信側の帯域状態を送信元に伝える挙動になっているのだろう。謎いと思ったが、少し考えれば分かる事だった。
YoutubeやTwitchといったライブ配信サーバーは、今やクラウド上でエンコードを行っている。マシンスペックや収益もろもろが増大し、サーバー群が増強されているからだ。5年ほど前までは、ライブ配信では配信者がエンコードを行う事が常だった。クラウド上の配信サーバーのマシンパワーが不足しており、配信者のＰＣスペックが大幅にそれを上回っていたからだ。よって配信者側がエンコードを行い、サーバーは中継を担うという方式を取っていた。現在のTeamsはこの環境と同意なのだろう。
ビデオミーティングの画質が現在においても安定しないのには理由がある。一つのライブ配信動画には～数万の接続があり、これらユーザー数に対しエンコードは画質の種類の分だけでよい。３～５程度だろうか。
しかしながらビデオミーティングでは、カメラの台数分だけエンコードが必要になる。10人居れば10プロセス、低画質と高画質を選べるだけでも最低20プロセスが必要だ。ユーザー数の比ではライブ配信の数倍～数千倍のエンコード処理が必要となる。まだまだ現実的じゃないね。
よって送信元でエンコードを行う事は致し方なく、しかしマシンスペックにバラつきがある送信元で複数のエンコードを走らせる事は現実的ではない。そもそも動画のエンコードとは処理が重い部類のプロセスであるのだ。よって回線帯域の最低値に合わせてエンコードを行うのはシステム上は合理的である。
ただしスマホアプリではアップロード品質を送信元が選べる仕様が存在する。Web版やデスクトップ版にも導入されそうな仕様ではある。ポリシーにこれらの諸設定が加われば、前述の重役は高画質で～、といった設定を管理者が行うのもより現実的になるだろう。
あれ？帯域制限ポリシーって下りではなく登りにこそ適用されるべきなのでは？