ブラウザ送出をリリースしました — エンコーダなしで双方向配信を回す

配信コンソールにブラウザ送出を追加しました。超低遅延モードのイベントで、ブラウザから直接映像を送れます。

これまで双方向の配信を1拠点で回すには、配信元に2系統の送出を並べる必要がありました。OBSなどのエンコーダでカメラ映像をRTMPで送り、それとは別にブラウザで質疑応答コンソールを開いて質問者とやり取りする。音声も、配信基盤へ送る全体ミックスと質問者へ返すn-1を、卓で作り分けていました。この構成が、ブラウザ1枚に畳まれます。

今回のリリースで変わるのは次の点です。

• 配信元のソフトがブラウザ1枚になります（エンコーダが要りません）
• 音声はn-1を送るだけで済みます（全体ミックスはブラウザ側で合成します）
• 質問者の映像は発言と同時に自動でPiPに乗ります（ウインドウキャプチャが要りません）
• カメラから視聴ページまでの遅延が約1秒から190ミリ秒になりました（自社実測）
• 従来のRTMP送出もイベントごとに選べます

以下、それぞれ何がどう変わったのかを書きます。

配信元の構成が、ブラウザ1枚になりました

構成を並べると差がはっきりします。

	これまで	配信コンソール
配信元のソフト	エンコーダ（OBS等）＋ 質疑応答コンソール	ブラウザ1枚
送出	RTMPで送出	ブラウザから直接送出
質問者の映像	クリーンフィード窓をウインドウキャプチャ	自動でPiPに乗る
音声	全体ミックスとn-1を卓で作り分ける	n-1を送るだけ。全体ミックスはブラウザ側で合成する
ミキサー	2系統を出せるバス数が必要	出力1系統で足りる
司会の操作	質疑応答コンソールを別に開く	同じ画面で兼ねる

音声の行が、実務では一番効きます。質問者の声はブラウザの中に届いているので、配信基盤へ送る全体ミックスはブラウザ側で作れます。卓から出すのは質問者の声が入っていない音、つまりn-1だけでよく、これは卓のメイン出力そのものです。返しのバスを立てる作業も、ブラウザの音を卓へ戻す配線も無くなります。

減ったのは機材と設定項目だけではありません。キャプチャ元のウインドウを取り違える、キャプチャ範囲がずれる、バスの送り先を間違えて質問者にハウリングを返すといった、本番中に起きうる事故の経路がまとめて消えます。設定が減るというより、事故の起点が減るという言い方のほうが実感に近いはずです。

質問者は、発言と同時に自動でPiPに乗ります

質問者の映像は、発言が許可された時点で自動的にPiPとして合成されます。発言が終われば外れます。発言できるのは常に1名という制御がサーバー側にあるので、誰を映すかで迷う場面が構造的に生まれません。

配置は5つのプリセットから選べます。

プリセット	絵
右下（既定）	配信者を全画面、質問者を右下に小さく
左下	同じく、質問者を左下に
大きめ	質問者を右下に大きく（表情まで見せたいとき）
並べる	左右に同じ大きさで（対談）
入れ替え	質問者を全画面、配信者を右下に小さく

プリセットを選んだあと、プレビュー上でそのままドラッグやリサイズができます。内部的にはプリセットも自由配置も同じ「矩形」として持っているので、プリセットから少し動かす、という操作が破綻しません。ドラッグした瞬間に表示は「自由配置」へ変わり、実態と食い違わないようにしてあります。

プレビューは、視聴者に届く絵そのものです

画面に出しているプレビューは、合成後のキャンバスをそのまま映したものです。別に作った確認用の絵ではありません。

配信で怖いのは、手元で見ている絵と視聴者に届く絵が食い違うことです。ウインドウキャプチャを挟む構成では、キャプチャ範囲や重なり順の設定を誤ると、この食い違いが起きます。合成そのものを画面に出していれば、原理的に食い違いません。

もうひとつ、従来の質疑応答コンソールを併用する運用も残してあるため、両方から司会者の映像を送ると質問者に二重に届きます。この状況は検知して警告を出すようにしました。

遅延は、約1秒から190ミリ秒になりました

構成の簡素化を狙った改良でしたが、遅延にも効きました。カメラから視聴ページまでの実測値です（いずれも自社実測）。

送出方式	実測遅延
エンコーダからRTMPで送出	約1秒
ブラウザから直接送出	190ミリ秒

RTMPで送る経路では、エンコードとRTMPでの伝送、そこから配信基盤内での変換が積み上がります。ブラウザ送出はその段を踏まないぶん、素直に短くなります。

そのため質疑応答をしない配信でも、単に遅延を詰めたい場面で使えます。会場の音や画といっしょに見せる用途、拍手や反応が返ってくることに意味がある用途では、1秒と0.2秒の差はそのまま体験の差になります。質疑応答機能を使う予定がなくても、超低遅延モードのイベントであれば送出方式としてブラウザ送出を選べます。

合成のフレームレートは、Chrome・Safari・Firefoxのいずれでも30fps前後でした（自社実測）。ブラウザによる差はほとんどありません。

RTMPでの送出も、イベントごとに選べます

すべてをブラウザに寄せたわけではありません。送出方式はイベントごとの設定です。

ブラウザ送出は超低遅延モードのイベントで選べます。一方で、放送用のカメラやスイッチャーを持ち込む現場、複数カメラをスイッチングする現場では、これまでどおりエンコーダからRTMPで送るほうが確実です。機材を作り込む必要がある配信まで、ブラウザに置き換えるつもりはありません。

簡素にできる現場を簡素にするための選択肢であって、置き換えではない、という位置づけです。

回線側の話はボンディングルーターの記事にも書きました。ブラウザ送出を前提にすると、現場に必要な機材が「安定したインターネット回線を作るもの」だけになります。

手こずったのは、機能そのものより周辺でした

余談ですが、開発で時間を取られたのは合成や送出の本体ではなく、その周りの細部でした。発言者が交代したときにPiPをきれいに入れ替えること、司会者が二重になっている状態を検知すること、タブを裏に回してもフレームレートを落とさないこと、長時間のイベントのあいだ、配信と質疑応答それぞれの認証トークンを切らさずに保つこと。どれも地味ですが、本番で効くのはこの層です。それぞれの詰め方はいずれ別の記事で書きます。

まとめ

• 配信コンソールにブラウザ送出を追加しました。超低遅延モードのイベントで選べます
• 配信元の構成がエンコーダ＋質疑応答コンソールの2系統から、ブラウザ1枚になりました
• 音声はn-1を送るだけでよくなり、全体ミックスはブラウザ側で合成します。卓は出力1系統で足ります
• 質問者は発言と同時に自動でPiPに乗ります。配置はプリセット5種から選び、そのままドラッグで調整できます
• 遅延は約1秒から190ミリ秒になりました（自社実測）。質疑応答をしない配信でも、遅延を詰めたい場面で使えます
• 従来のRTMP送出もイベントごとに選べます。機材を作り込む現場まで置き換えるものではありません

音声のn-1そのものの考え方は配信のマイナスワン（n-1）とはで書いています。送出をブラウザに寄せても、質問者に自分の声を返さないという原則は変わりません。