配信画面を作り直しています — 7つに分かれた操作を1画面へ

配信の管理画面を作り直しています。まだ実装していません。 この記事は、何が問題で、どう変えるつもりで、なぜそう決めたのかを書いたものです。掲載している画面はすべて検討用に作ったモックで、実際の画面ではありません。

作り直す理由は、送出の方式が増えたからです。RTMPS、SRT、ブラウザ送出、そして質疑応答のSkyWayと待機室。それぞれに別の画面があり、どれが何の役目なのかが画面名から読み取れなくなっていました。

目的は、オペレーターが監視しやすい環境をつくること

先に、今回いちばん大事にした考えを書きます。

この刷新の目的は、配信前のプレビューを足すことではありません。配信を管理するオペレーターが、監視しやすい環境を整えることです。

これまでページごとに分かれていた配信操作を、オペレーターの目線でダッシュボードにまとめ、一元管理できるようにします。 本番中に見たいものが1画面に揃っていることが、そのまま監視のしやすさになります。

配信は、始まってしまえば止められません。異変に気づくのが遅れれば、その分だけ視聴者に届いてしまいます。オペレーターが何かに気づけるかどうかは、画面の作り方で決まります。 タブを切り替えないと分からない情報は、見られないのと同じです。

以降に書くことは、すべてこの目的から出ています。7つの画面を1つにするのも、映像と音声を並べるのも、状態を常に文字で出すのも、そのためです。

1イベントに7つのボタンが並んでいました

いまのイベント一覧には、1行につき7つのボタンがあります。編集、送信・受信情報、配信コンソール、質疑応答、待機室、挙手モニター、レポート。

本番中はこれらを行き来します。どの画面が何をするのかは、名前を見ても分かりません。 「配信コンソール」と「送信・受信情報」の違いを、初めて触る人が言い当てられるでしょうか。

そこで、イベントをクリックしたら1画面に入り、そこで完結する形にします。右に設定のタブ、中央に監視のコンソール。設定を切り替えても中央の映像は出したままにします。本番中に設定を確認する場面で、映像から目を離さずに済ませるためです。

レポートだけは一覧に残します。配信が終わってから見返す画面なので、本番用の画面と混ぜないほうが安全だと考えました。

設定を変えると、画面のほうが変わります

「どのUIが何の役目か分からない」への直接の答えは、いまの選択と関係のないUIを出さないことだと考えました。

• 送出方式をブラウザ送出に切り替えると、RTMPSのモニターは消えます。両方が同時に出ることはありません
• 配信モードを追いかけ再生にすると、表記が RTMPS / SRT に変わります。超低遅延モードのStageはRTMPSのみでSRTに対応していないため、そこに出しても意味がないからです
• 待機室を使わない設定なら、待機室のタブごと消えます

見えているものが、いまの設定そのものになります。

配信前に絵を確認してから、開始できるようにします

監視の環境を整えるうえで、外せなかったのがこれです。インジェストした映像を確認してから、配信を開始したい。

調べてみると、新しい仕組みを作らなくても成立することが分かりました。 既存の実装が、すでにこの運用を想定していたからです。

配信開始のAPIは、イベントが「準備中」の状態でも送出用のトークンを出します。一方で視聴ページ側は、「配信中」でなければ視聴用のトークンを発行しません。

つまり「送出は届いているが、まだ誰も見ていない」という状態が、設計上すでに用意されていました。

そこで操作を3段に分けます。

段	何が起きるか	視聴者
プレビュー	手元でカメラと合成を確認するだけ。どこにも送りません	見えません
送出	配信基盤へ送ります。イベントは「準備中」のまま	見えません
配信	イベントを「配信中」へ進めます	見えます

ボタンの活性も、この順序どおりにします。絵を確認してからでないと送出できず、送出していなければ配信も開始できません。

映像が来ていない画面は、グレーの無地にします

小さな話ですが、これは意識して決めました。カラーバーを流している配信と、何も届いていない状態が見分けられないからです。

映像が来ていないときは、色のついた絵を出しません。無地のグレーに破線の枠だけを出します。「何かが映っている」と「何も来ていない」を、一目で分けるためです。

音声は、どれか1つだけを聞きます

本線、質問者向け送り、待機室。この3つのうち1つだけを聞ける形にします。同時に鳴らすと、返しの確認になりません。

質問者向け送りを並べているのは、マイナスワンが効いているかを耳で確かめるためです。質問者に自分の声が戻っていないかは、その音を実際に聞かないと分かりません。

質問者の声を、会場へ出す

質疑応答では、質問者の声を会場のスピーカーからも出す必要があります。ここで決めたことが2つあります。

モニターと会場出力は、必ず別のデバイスにします。 オペレーターがヘッドホンで聞く音と、会場PAへ送る音は別系統です。同じにすると、モニターで切り替えた音がそのまま会場に出ます。

この構造は、BGM再生アプリを自作したときの結論と同じです。1つの出力を分岐させるのではなく、デバイス1台につき独立した系統を1つ持たせます。分岐させると再生速度が不安定になる、という実測がありました。

両方にレベルメーターを付けます。ピークホールドを入れたのは、会場出力で特に効くと考えたためです。 質問者の声は音量が読めません。バーだけだと一瞬の突っ込みを見逃すので、直前に何dBまで来たかが残っているほうが安全です。

映像のほうは、UIを含まない別ウィンドウを会場側のディスプレイに出して全画面にします。発言許可と会場出力を1対1にする予定です。別々に選べると「許可したのに会場に出ていない」という事故が起きるからです。

挙手した人を、1枚のカードにまとめます

いまは質疑応答コンソール、待機室、挙手モニターの3画面に分かれています。これを1つにまとめ、1人分を1枚のカードにします。

カードには、小さなプレビューとその人だけのレベルメーター、そして「質問を許可」「拡大表示」を置きます。声が出ているかどうかは、許可する前に確認したい情報です。

できないことも書いておきます

設計の途中で、できないと分かったことが2つあります。

RTMPS送出のときは、音声レベルが取れません。 いま取れている通信品質の数値は、管理画面自身が送出しているとき、つまりブラウザ送出のときにしか手に入らないためです。OBSなどから送っている場合、管理画面は映像経路の外側にいます。ここは実現方法から検討し直しになります。

会場への出力はChromeが必要です。 出力デバイスを指定する仕組みも、ウィンドウを別ディスプレイへ配置する仕組みも、Safariでは動きません。画面全体をChrome限定にするつもりはなく、会場出力の欄だけを無効にして理由を出す形を考えています。

いまはまだ、設計だけです

繰り返しになりますが、この画面はまだ存在しません。 掲載した画像はすべて検討用のモックです。

実装は、まず画面の器を作って既存の機能を移すところから始めます。監視を1画面に集める、という目的の大部分はそこで果たせます。次にブラウザ送出の3段を通す。この2つで要望の大半が満たせ、しかも配信基盤側の新規実装がほとんど要りません。RTMPS送出時のプレビューや視聴者数の表示は、その後になります。

出来上がったら、実際の画面で使い方を書きます。

ブラウザから直接送出する仕組みそのものは、エンコーダを持ち込まないに書きました。今回の画面は、その上に乗る操作系の話です。