みなさま、こんにちは。おさかなと申します。
今回は私が以前に業務で関わっていた音楽ライブの配信について紹介したいと思います。当時はシステム開発から現場での配信オペレーション対応まで行っていたので、そのときに得られた配信の技術的な知識や、現場のトラブルシューティングも含めてお伝えできればと思います。
そもそも配信とは？
最近、YouTubeやTikTokをはじめとした動画SNSで動画を自分で撮影して「配信」する人が増えていますが、そもそも配信とは何でしょうか？
配信とは、「サーバーやインターネットを経由し、映像や音声などのコンテンツを視聴者に届けること」を言います。なので、動画サイトに動画をアップロードして公開することはもちろん配信ですし、Spotifyのように楽曲を広くユーザーに届けるサービスも配信と言えます。
一方で、公共の電波を使用して動画を流すことは配信とは区別されて「放送」と呼ばれます。放送の種類としては地上波放送や衛星放送（BS放送、CS放送）などがあります。
また、一口に配信といってもさまざまな種類があります。大きく分けると下記の表の3種類に分けられます。
| 配信形式 | 特徴 | 視聴のタイミング |
|---|---|---|
| 生配信 | 撮影した映像をリアルタイムに配信 | 決まった時間に視聴 |
| 収録配信 | 事前に収録しておいた映像を編集・加工して配信 | 決まった時間に視聴 |
| オンデマンド配信 | 事前に制作した動画を配信プラットフォーム上にアップロードして配信 | 好きなタイミングに視聴 |
「生配信」はその名の通り、撮影した映像をリアルタイムに配信することです。対して「収録配信」や「オンデマンド配信」は事前に収録した映像に編集や加工を施して後日配信することを言います。
私は特に音楽ライブの生配信に携わっていたので、以降では生配信にフォーカスしたいと思います。
まずはざっくり「生配信の仕組み」を解説
さて、配信に関する前置きが長くなってしまいましたがここからはいわゆる音楽ライブの生配信で私が関わっていたシステム部分について紹介したいと思います。音楽配信のフローをざっくりと図に表すと下図のようになります。
図の左から説明すると、まず音楽ライブの配信現場では配信する映像と音声は別々のカメラとマイクで とります。そしてそれらの時間同期をとり、タイミングを合わせてから映像と音声の統合処理（エンベデッド（embedded））を行います。その後、音声がエンベデッドされた映像は、インターネット伝送に適した形式（パケット）に変換されて送信されます。
この変換処理は「エンコード」と呼ばれ、主に「符号化」「データ圧縮」などが行われています。エンコードはエンコーダを使用して行われます。私は現場ではまさにエンコード業務を行っていました。どんな作業を行っていたかは後ほど紹介するのでここでは割愛します。
そして、エンコーダで処理された映像は配信元となるサーバーに送られ、そこから視聴者に対して配信されます。配信元のサーバーには様々なサービスがあり、代表的なものとしてStagecrowd（ステージクラウド）、Streaming+、ZAIKOなどが挙げられます。配信映像は非常に通信量が大きく、それを滑らかに再生するためには視聴者側で安定した通信環境が必要となります。
ライブ配信では、視聴者に対して映像を届けるまでに「エンコーダと配信サーバーの間の伝送」と「ライブ配信サーバーと視聴者の間の伝送」の2種類の伝送があります。前者を「ファーストマイル」、後者を「ラストマイル」と呼びます。
ファーストマイルでは主に「RTMP」というプロトコルが使用されており、YouTubeなどの配信プラットフォームで配信経験のある方は馴染み深いかもしれません。一方でラストマイルでは「HLS」や「MPEG-DASH」というプロトコルが使用されています。ラストマイルで使用されているプロトコルは映像をあらかじめセグメントと呼ばれる10秒程度の単位に分割して伝送しています。そして、視聴者の端末で再生を開始する前にいくつかのセグメントを保持しておくことで安定した配信ができるようにしています。
このようにセグメントを保持することによって、視聴者が映像を再生するまでにおよそ10~30秒程度の遅延が生じます。配信映像が実際のライブ会場よりも少し遅延しているということを聞いたことがあるかもしれませんが、それはこのセグメントの仕組みによって生じています。セグメントの長さは調整が可能なので、時間を短くすることで遅延を減らすことはできますが、その分再生処理を頻繁に行う必要があるため再生の安定性が低下する場合もあります。一方で、これらの課題を解消するためにさまざまな技術が開発されており、遅延時間の改善が行われています。
少しの乱れも許されない生配信の難しさ、そしてよろこび
それでは私が実際に現場でどのような業務を行っていたか紹介したいと思います。先述しましたが、私は主に現場で「エンコード業務」を行っていました。エンコード業務はいわゆるカメラ撮影チームから映像を受け取り、それをエンコーダーに入力して配信先のプラットフォームまで打ち上げるという作業です。大まかに挙げると、ケーブルの引き回し、エンコーダーの操作、映像の調整、配信映像の確認などがあります。
エンコード業務の中でも私が最も注意していたのは映像の解像度やフレームレートなどです。配信先のプラットフォームには受信する映像の推奨フォーマットというものが存在します。そのため、エンコード側がそれに合わせた映像を伝送する必要があるのですが、プラットフォームによって推奨値が異なっています。
配信業務では、事前にプラットフォームごとに推奨値を把握して正しく伝送してやることが非常に重要です。これを誤ると配信プラットフォームで映像を受け取れなかったり、最悪の場合サーバーがダウンしてしまうなど大事故につながる可能性があります。そのため事前に撮影チーム・エンコード担当者・配信プラットフォームの担当者で打ち合わせを行い、映像の認識統一を行います。
これは実際に現場で起きたことなのですが、カメラチームとエンコード担当者、配信先プラットフォーム担当者との間で認識齟齬があり、映像をプログレッシブで伝送するはずがインターレースで伝送してしまい、映像にちらつきがあるとプラットフォーム担当者から報告を受けたことがあります。幸い、リハーサルの映像疎通確認で気づくことができたので、即座に原因を調査しギリギリではありましたが本番までに調整して無事配信を終えることができました 。
また、配信映像はカメラからの生の映像に対してエンコード処理（変換処理）を行っているため、照明演出が激しい映像や暗い映像を処理すると、一部が白飛びしたりブロックノイズが生じて映像品質を下げてしまうことがあります。そうならないように、エンコード手法を変更したり、ビットレートなどのパラメータを調整して極力視聴者の体験を損なわないようにも努めました。
映像の配信では少しでも映像や音声に乱れがあると事故になってしまうので限られた時間の中で適切にトラブルシューティングする必要があるのですが、実践的に原因を切り分けて対処する力を養うことができ非常に貴重な経験となりました。また、無事配信を終えたときにチャット欄で視聴者のみなさんから温かいコメントを頂けたときには非常に励みになりました。
まとめ
今回は私が業務で携わった配信の仕組みや現場の仕事について紹介しました。コロナの影響で2020年から配信需要は拡大し、落ち着きを取り戻したこれからも配信は続いていくと思います。withコロナになったこれからライブ配信エンタメがどう進化していくのか技術の進化とともに引き続きウォッチしていきたいと思います。
ちなみに本ブログでは、以前、音楽ライブを自動で撮影するシステムのカメラ制御についても紹介させていただきました。もし、そちらにご興味のある方がいらっしゃいましたら、ぜひご一読いただければ。よろしくお願いいたします。
