PyCon mini Shizuoka 2020 オンライン開催しました　配信技術/運用編

目次

shizuokaLogo.png

この記事は2020/02/29に開催されたPyCon mini Shizuoka 2020 オンラインのイベント準備と当日の様子などを、スタッフとして関わった個人の感想です。

なお当日のSNSの反応はこちらで見れます。

今回のオンライン開催への切り替え時に、技術的な準備もやっていたので、その内容は別の配信技術/運用編と題して記事にします。

イベント自体の経緯が経緯なだけに、長くなるので分けて記事にしています。

PyCon mini Shizuokaは、先の記事でも扱ったようにGoogle Meet（当時はHangout Meet）で各地のスピーカーとつないで、Meetの画面をそのままYouTube Live配信に載せました。

ここでは方法や機材や当日のトラブルを紹介し、こうするべきだった反省点も載せようと思います。

当日のオープニングでこんな画像がありましたが、あれは概要図で

PyCon mini Shizuoka オンライン オープニング.png

実際はもう少し複雑になります。

※念のためにですが、準備と当日までには9日もなかったので、この記事を参考にするというよりは、後々こうあるべきだったの後学のために残しておきます。

下調べ

オンライン開催に切り替えてから、どういった方法で具体的に行うかを計画しました。まずは現状で知見がないかどうかを調べます。

ちょうどこの時期にオンライン勉強会、イベントの開催ノウハウがSNSでも出回ってて、記事をいくつかみました。

まずこの記事がとても参考になりました。PyCon mini Shizuokaの配信環境はほとんどこれに近いです。

オンラインイベント開催のガイドライン – granica Blog

そのほか参考

機材について

実行委員会のスタッフが利用しているPCがどういうものかを調べたり、メインの配信会場でも用意できるPCがあるようなので、そちらの確認もしていきました。

オンライン開催に切り替えて残り9日の状況でして、今から新規に何かを用意する時間もありません。あるもので対応する形にしました。

利用したソフトウェア

  • ビデオ会議サービス:Google Meet
  • 配信ソフトウェア: OBS Studio（以下、OBS）
  • OS: Windows系

ビデオ会議サービスはGoogle Meetを利用しました。これはPyCon mini Shizuokaのスタッフミーティングで毎回利用していたのでスタッフが慣れていたという点で決めていました。Zoomのほうが安定している話は聞いていましたが、時間の都合上うまく使いこなせるか不安だったので頭には入れていません。

YouTube Liveの配信ソフトウェアは推奨のOBSを利用しています。その当時の最新版をインストールしています。

OSですが、Windows系一択にしました。これには理由があって、OBSにはデスクトップの音声をキャプチャする機能が標準でありますが、Windowsでは何も設定せずにも利用でき、Macの場合は標準ではキャプチャする方法がありません。（仮想オーディオデバイスを追加する手段がありますが、うまく使いこなせずにあきらめてます）そのため、最低限OBSを動かすマシンはWindowsにしました。

デスクトップ音声のキャプチャを大事にした理由としては、Meetの音をそのまま拾うことができるからです。Meet側に映像も音声も画面共有も集約することで、それぞれのソースを考慮せずに済みました。（デメリットもあったので良い方法だったかは言えず悩ましい）

メイン会場

配信や司会を行うメイン会場は、会場（Biviキャン）のご厚意でノートPCを貸していただけました。大学のキャンパスでもあるので講義で利用するマシンが利用できます。

スペックとしては、うろ覚えですが以下のようなものです。

  • CPUは世代的には3~4世代ぐらい前のCore i5系
  • メモリは4~8GBぐらい
  • ディスプレイ解像度は1380*720あたり（720pレベル）

このスペックは配信を行うスペックとしてはぎりぎりかなと思います。ただこの世代のCPUはIntel Quick Sync Videoが利用できまして、OBS側でもエンコード設定で認識されていたので、配信マシンを専用のマシンとすればそれなりに利用できます。キャプチャする解像度もフルHD以下だったので、このマシンで行うことを決めました。

また回線も会場にあるテレビ会議で使う専用の系統を利用させていただきました。やはり回線が強くないとそもそもオンラインカンファレンス自体が成り立ちません。今回一番の重要なところがクリアーできたのは助かりました。

バックアップ会場

バックアップ会場は私の自室です。マシンはデスクトップが1台、事務所からもう1台マシンを持ってきて2台体制にしました。（用意も突貫だったので汚い。。）

IMG_20200229_190617.jpg

スペックとしてはこんな感じです。

  • CPU: Intel Core i5 6500
  • メモリ: 16GB
  • GPU: Radeon系（RX480, HD6580）:HD6580はOSB側でハードウェアエンコードに非対応

マシンとしては、数世代前ですがフルHDレベルでの配信には耐えられる物です。実際の配信は720pに落として余裕を持たせました。（そろそろRyzenに変えたい物ですが）

自前の回線も大事ですが、ちょうど数年前にIPoE+DS-Liteという、IPv6ベースの回線にしていたので速度としても問題なく利用できました。

当日までの準備でやったこと

機材のめどが立った（現地は開けてみないとわからなかったのですが）ので、配信の準備と想定できる方法を試してみました。箇条書きするとこうなります。

  • YouTube Liveの有効化: 1日かかることに注意
  • 想定を用意してのテスト:2トラックそれぞれ別マシンで配信できるか
  • OBSの設定をチェックする:
  • OBS画面キャプチャ+Meetで配信を試す
  • 前日に配信会場でセットアップしテスト

YouTube Liveの有効化は、モバイルでの配信は即日にできるそうですが、PCなど配信ソフト経由の場合は有効になるまで1日かかるそうです。まず決めたら最初に有効化しておくとよいです。

2トラックで配信する場合は、配信のURLを作りますが、その時に配信の情報をコピーして作成するとハマります。（ご丁寧にコピーしますかと出てくるので意味が分からずその通りにしてしまってハマりました）配信ソフトと連携するときに使うストリームキーが同じ物になるからです。 配信のURLの生成は必ず新規作成をするほうがわかりやすいです。

OBSの設定は基本的に自動構成ウィザードで設定されたものを使うでよさそうです。配信の設定を合わせる場合は設定のエクスポートが使えますが、インポートした後は想定した設定に変更されているかチェックする方が良いです。

image.png

自動構成ウィザードで設定した後は、配信と録画をセットで行えるような設定に切り替えます。

image.png

最後に統計情報を見れるようにします。この統計情報も見つつ、YouTube Liveの管理画面も見つつ状況をチェックすると、トラブルに対処しやすいです。

image.png

OBSでchromeなどのブラウザウィンドウをキャプチャ（ウィンドウキャプチャ）を行う場合、ブラウザ側のGPUハードウェアアクセラレーション設定を無効にしないとキャプチャできない場合があります。利用するブラウザで無効化すると良いです。ほかのビデオ会議サービスはまた事情が違うと思います。

参考: OBSブラウザをキャプチャする配信設定｜gotomaki｜note

実際の配信で利用したマシンの組み合わせ

利用したマシンはノートPCで能力としては少し弱い物ですが。ただIntelのハードウェアエンコードが使えたので、配信と録画は両方とも可能でした。

なので、以下のように準備をしてみました。もしCPU負荷で配信が手一杯な場合は、録画を別のPCで使う必要があったと思います。

  • 配信用マシン: MeetとOBSが動く、Meetの画面キャプチャをOBSが行う
  • Meetホスト用マシン: スピーカーがMeetの会議に参加するときの承諾を行う
  • 司会用マシン: 司会側が利用するマシン: Meetを動かしスピーカーとのやり取りを行う

pycon mini shizuoka 配信環境の様子.png

このマシン以外にも、YouTube Liveの配信チェック用も用意しています。

配信用は先ほどにも説明した通り、メイン会場、バックアップ会場に2台ずつ用意しています。バックアップも2台用意できたため、メイン会場の配信用マシンが利用できなくなってもバックアップ側ですべて配信を引き継げるようにしました。

司会やスタッフ担当を決める

司会やスタッフ担当は、オンライン開催前から、現地（オフライン）開催である程度決めていました。このあたりの混乱は少なかったと思います。といっても勝手が違うこともあったので当日に現地会場側の判断で再構成されています。

あらかじめ決めていたのは、オープニングとクロージングの担当、セッションごとの司会担当、タイムキーパーです。

当日は配信のトラブルで配信環境はバックアップ側に切り替えましたが、司会とタイムキーパーは現地会場スタッフで行われたので運用自体は変わっていません。どちらも独立して行えた点は良かったと考えています。

当日発生したトラブル

こうした準備の元、カンファレンスが行われました。できるだけの準備は行ったものの当日は本当にトラブルとの格闘でした。後学のために発生したトラブルをなるべく残しておきます。

想定できる対応方法の案も考えてみました。試したわけではないので見当違いなものもあるかもしれません。（こんな方法もあるよとアドバイスいただけると助かります）

スピーカーがどの画面を見ればいいか悩む

これは、YouTube Liveで配信を行うときによくあるトラブルだそうです。Live配信側はどれだけ良い環境でも30秒程度は遅れてしまう（当然といえば当然ですが）ので、スピーカー側はLive配信が正しく配信されているか（画面、音）チェックし終えたら、後は音をミュートにしてもらえると良いです。そのままでもコメント自体は見れるので反応を楽しんでもらうために閉じる必要はないと思います。

それと、スピーカー側の環境ではマルチディスプレイでの環境もありますが、Meet側がうまく対応できていないようで、できればディスプレイは1つでプレゼンされた方が良いと思います。この時にPowerPointのノート機能やプレゼンツールは利用できないため、あらかじめその説明はスピーカーに必要です。

（もしかしたらこちらがそう思いこんで気が付かなかっただけで、スピーカー側は問題なかったかもしれません。また現在のMeetのバージョンだと改善している可能性があります）

対応方法の案

  • スピーカー側の発表環境を収集する
  • 運営側は実際の環境を模倣してあらかじめテストする（全部は難しいのでスピーカー側とのリハーサルで確認する）

ビデオ会議サービスでスライドの表示がおかしい

Meetの問題があったのか、Keynoteがどうしてもきれいに表示できずに代替手段をお願いすることになりました。 現在だと改善されている可能性がありますが、リハーサル前にPDFかGoogleスライドのようなブラウザベースでできるような代替手段はあったほうが良いと感じます。

ただZoomだとそういった問題は聞かず、他のビデオ会議サービスでも同じように聞いたことがなかったので、Meet依存の問題だったかもしれません。

対応方法の案

スライドの画面共有で比率や解像度が合わない

スピーカーのPCなどの機材状況が変わったときに起こるようでした。できればスライドの比率はあらかじめ決めたほうが良いです。状況にもよりますがMeetの画面共有は16:9のほうが扱い易かったと思います。ただ理由はわかりません。。

対応方法の案

  • スライドの比率をルールにする
  • 機材が変わったときにはテストと練習を行う

マイクからポップノイズ発生

スピーカーによっては、セッション中にマイクの何らかの不良でノイズが発生してしまうことがあります。基本的にマイクは接続している（スピーカー）側の問題になってしまいます。

定量的なノイズはリハーサル時に解決できるかもしれませんが、突発的に乗ってしまうノイズについては物理的な問題もあり直ぐに解決が難しいこともあります。

対応方法の案

  • スピーカーのマイク状況を開始前に確認する。OBSのレベルメーターを見るとわかりやすいです
  • ノイズ発生はどうしても起きてしまうトラブルとして、ある程度は許容する（しかない。。）

マイクの音量が小さい

YouTube Liveのコメントで音量が小さいと連絡を受けまして、ある程度の調整をしていました（OBSのデスクトップ音声のレベル変更である程度は調整できます）

ただ最終的にはスピーカー側機材の問題になり、こちらでは完全に操作することは難しいです。

このトラブルはスピーカー側のマイクとレベル調整がポイントになるので、あらかじめスピーカーと協力してリハーサルや発表の事前にチェックが必要になります。

対応方法の案

  • あらかじめテストを行うときには必ず発音テストをして確認する（できればOBSで録画をしてレベルメーターや実際に聞いて音量チェックも）
  • スピーカー側マイクとレベル調整をしてもらいながらテストを行う
  • 仮にトラブルでマイク機材の変更がある場合は、余裕をもって連絡をもらう

音が消える

これは特殊な事例で、セッション中に機材を変更する場合に気を付けるべきトラブルです。

配信開始前にヘッドセットなどの音響機材を追加した場合に、OBS側の設定が追従できなかったのか音声が配信に乗らないことがありました。 （その時の状況から配信用と司会用マシンの2つが兼任になっていました。それぞれ独立の予定でしたが直前に配信用マシンの不具合があってそうせざる得ない状況でした。この辺も準備がしきれなかった点になります。）

このトラブルはスピーカー側やMeetのホスト、司会側で確認するのが難しくて、YouTube Live配信側で気が付きました。

対応方法の案

  • 機材追加時は、OBS側で録画をして想定した音声が収録されているかのテストを行う
  • OBS側で音声のレベルの状況を常に確認する

トラブルが発生したときの対処がない

リアルタイム配信中に起こるトラブルは、配信を止めない限りそのまま見えてしまいます。後に戻すことはできませんが、起きた時の対処法は挙げておくべきでした。

スケジュール変更をできるような余裕を持つべきだったと感じました。

  • 起きた時にいったん配信をストップする
  • 時間をずらせる、再演できるようにスケジュール変更をできる余裕を作る
  • トラブル時の取り決めはあらかじめマニュアル化しておいて練習するべき

まとめ

リアルタイムでオンライン配信の難易度はやはり高いものでした。ただリアルタイムでSNSやYouTube Liveコメントでの盛り上がりが見れたことは体験として感動しました。

SNSやアンケートで意見をいただきましたが、セッションは収録したものを流せばよかったのでは？という意見もあってその通りだったと思います。

ただその時に思いつけなかったわけです。。収録ならもっと良い条件のもと、テストをしながら収録しなおすこともできたと思います。ただその時に思いついても日数がなさ過ぎました。

配信オペレーションもすべてきれいにリハーサルしたわけではないのでぶっつけ本番でした。良かった点は、機材がある程度そろっていればLive配信自体はできる。悪かった点は機材や配信ソフトを熟知して、テストやトラブルシューティングできないとトラブルに対応できない。

結果そのまま流し続けるしかないのが生配信です。

ご迷惑おかけしたスピーカーにも申し訳ない思いしかありません。個人的にも経験としても、起こしたトラブルについてできるだけ共有しました。

この記事を公開するときでも、まだ人が集まってのイベント開催することはできない状況だと思います。

オンラインでのやり取りは一層増える中で、オンラインカンファレンスの事例と何で苦労していたかを知っていただけると嬉しいです。

カンファレンスの感想を頂いたときに、同時にオンライン配信もしてほしいと意見もありました。この経験を元にオフライン/オンライン両方とも行うのも1つのアイディアで、やってみたい気持ちもあります。

ただ現状は、スタッフのリソース的には厳しいです。静岡のPythonコミュニティに興味がある方、カンファレンスのスタッフに興味がある方にぜひともお手伝いお願いしたいです（いつでもスタッフは募集しております。また募集の動きがあったらお伝えします。）

PyCon mini Shizuokaのオフライン/現地開催はまだ未定です。でも落ち着いたら必ずやります。皆さんとお会いできる日を楽しみにしています。

今はただ一刻も早く新型コロナウイルス感染症の終息を願うばかりです。

About Me

買ったり作ったり考えたり試したの日々の記録です