Edited at
SchooDay 6

Schooの生放送配信のカメラから見切れた側

More than 1 year has passed since last update.


はじめに

本投稿は、Schooの2016年末特別企画「Schoo advent calendar 2016」の6日目の記事になります。

エンジニアはエンジニアでも、放送技術的な意味でのエンジニアをやっています。なので、この記事もQiitaの皆さんのようなシステム開発的お仕事の領域ではなく、ライブストリーミングやスタジオの運用的お仕事についてのお話となることをあらかじめご了承ください。


配信機材構成図

まずは弊社で使用している機材構成についてご紹介します。


配信システム.png

右から登壇者に近く、一番左からエンコードされた映像がエントリーポイントに流れていくイメージです。


細かいところにはいろいろな仕掛けがあるのですが、映像・音声周りの機材を簡略化するとご覧のような構成を使っています。


自由な入力ソースを一つ

登壇者に一番近いところからご説明すると、まず生放送で授業を実施してくださる先生のお持ち込みになったPCをとにかくCerevoさんのLivewedgeに入力するようにしています。

これにはいくつかのメリットがあり、


  • 先生が複数台のPCを持ち込んでも適宜切り替え可能になる

  • 進行役(弊社では学生代表と呼称しています)のPCも適宜切り替えて使用できる

  • Livewedgeが内部でスケーラも持っているため、次のコンバータに入力する信号が統一できる

というように、入力側では接続するデバイスを自由に、出力側では出力される信号を揃えて吐き出せるようになります。


1080iに統一された映像信号を4系統設ける

次に紹介するのはTriCasterに直接映像信号を送りこむための機器です。

HPX175は放送用、特に弊社のような小さなスタジオに向いた機材なので直接接続してもいいのですが、LivewedgeはHDMIの出力しかないためSDIにコンバートしなければなりません。これをGrass ValleyのG1で解像度と信号を1080iに整えて送り込んています。

もう少し解像度の選択肢はありますが、720やSD解像度にするメリットはあまりないため、だいたいこのあたりの設定で皆さんお使いかと思います。


音声は混信リスクの高いワイヤレスマイクは使わない

弊社が渋谷のにぎやかなところにあるので、いつどこで誰が無線を利用するかはわかりません。

他にもいろいろと事情はあるのですがATWシリーズの2.4GHz帯を使用するタイプは送信機と受信機がペアリングするタイプのマイクなので、他のマイクから音が紛れ込む、という事故が防げるというメリットがあります。(もちろん、Wifiと混信してノイズとなってしまうリスクはあるのですが、他所から音がまぎれるよりは、だいぶだいぶマシです)


最終的にはFMLEで3種類のエンコード

Schooの録画配信の裏側にあるように、基本として用意されている三つのビットレートは生放送でも同様にTriCaster460でエンコードしております。

このTriCasterはWindows7がOSとして入ったパソコンでして、一般的な放送機器でいうところのスイッチャーとは多少異なる作られ方をしています。

イメージとしてはWirecastやXsplitのような配信用アプリをインストールし、それに見合ったハードウェアを積んだスゴイオモイPC、という感じのやつです。配信する際はスイッチングに使用するTriCasterアプリがFMLEの仮想ビデオソースになり、かつTriCasterアプリがFMLEを立ち上げつつスイッチング用アプリケーションの裏でFMLEを動かすことで配信を行っています。

なお、内部に記録したmp4ファイルを動画として再生したリ、透過のpngファイルをテロップにするというようなことも可能です。

※バージョンや機種によってはTriCasterは独自のエンコーダーを用意しているので、今回の説明と異なる場合があります。ご注意ください。

エンコードの設定は動きに弱い代わりにある程度はっきり解像度をとれるような向きで調整しています。


まとめ

スタジオ側の機材構成にあたっては、


  • 3つのエンコード設定を設定ごとにストリーム設定しなくていい

  • 機器全体の構成はなるべくシンプルにして、なるべくトラブルシュートやメンテナンスを容易に

ということが求められていました。

Wirecastなどの導入も検討した時期があったのですが、配信設定ごとにrtmpURL/streamなどを都度設定することになるため、一つの設定を3ストリームまで使い倒せるFMLEが最終的に便利だったのですね。

とはいえTriCaster内でのFMLEはなかなかトラブル時の現象を把握できない不安があるため、途中までの機器数を減らし、放送までの経路は可能な範囲でコンパクトに、また、柔軟性を要求する箇所にはスケーラを持った機器を優先的に投入し、多少厳しい環境でも安全に動きそうな構成にしておきました。

中々独自の配信システムに配信する例はそう多くないので、多少苦労もありますが楽しく配信しております。

開発でも配信でも、ご興味がございましたらばWantedlyの採用ページより、ぜひご応募くださいませ。