ライブ配信のキモである“エンコーダ”について考える【導入編】

この1年で一気に拡大したライブ配信。エンコーダの選択・設定ゆえの事故や、みていてもっと画質が向上できるのではと思う配信もまだまだあります。新規参入したライブ配信プラットフォームでは、推奨されるエンコーダの設定などの情報が不足していたり、そもそもプラットフォーム側の担当者、技術者もよく理解していないケースも存在します。

いろんな配信現場で、「エンコーダって何がいいんですか？」と訊かれることも多く、また技術的な裏付けなく“なんとなく”配信管理をしているケースも散見されるため、基本に立ち返って、ライブ配信におけるエンコーダについて、まとめてみたいと思います。

筆者もすべてのエンコーダを触ったことがあるわけでもないですし、たまにレンタルでいじるくらいの機材もあるので、ここでは「これを使って、こう設定すれば間違いない」というような話ではなく、あくまでエンコーダ選択や設定の背景となる基本的な知識や、トラブル時の原因切り分けに必要な基礎知識のようなお話をしたいと思います。

後日、筆者の手元に用意できるエンコーダについて、実際の動作を検証した結果も紹介していく予定です。

そもそも、ライブ配信のなかでのエンコーダの役割とは？

長年ライブ配信に関わってきた人には当たり前の話ではあるものの、ちょっと遠回りですが、まずは、ライブ配信におけるエンコーダの役割をお話ししたいと思います。

本来、「エンコーダ（en-coder）」とは、情報を特定のフォーマットに符号化（コード化）するためのソフトウェアだったり、専用のハードウェア全般を指す言葉です。対になる言葉は「デコーダ（de-coder）」です。

「エンコーダ(encoder, coder)」と「デコーダ(decoder)」を組みわせた「CODEC（コーデック）」という言葉もあり、エンコード・デコードの方式やそれを実施するソフトウェアやハードウェアを示します。

広い意味での「エンコード」は必ずしも圧縮を伴うわけではありません。たとえば「ライブ配信」とググったときに、検索結果のURLに含まれる「%E3%83%A9%E3%82%A4%E3%83%96%E9%85%8D%E4%BF%A1」は「ライブ配信」という文字列を「URLエンコード（パーセントエンコーディング）」という形式でエンコードしたものです。これをデコードすると「ライブ配信」という元の文字列になるわけです。「ライブ配信」という文字列がこうやって見えているのは……というもっと根本的な「エンコード」の話もあるのですが、それは置いておきます。

ライブ配信の世界での「エンコード」は、映像と音声を圧縮・符号化して送信するものを指しています。このnoteでは、以下、この圧縮〜送信を行う「狭義のエンコーダ」を前提にお話しします。

このエンコーダの役割を一言でいうなら、「ライブ配信する映像と音声を圧縮して、配信サーバに送り届ける」ということになります。

このサーバに送るという作業を、英語圏だと「ingest（インジェスト）」、日本の業界だと「打ち上げる」もしくは、単に「配信」などと言うことが多いのですが、このnoteでは「打ち上げる」「打ち上げ」などと書いていきます。

多くの場合、映像は「H.264（MPEG-4 AVC）」、音声は「AAC」の形式にエンコード（圧縮）したうえで、RTMP（Real-Time Messaging Protocol）ないしTLS/SSLによる暗号化を加えたRTMPSというプロトコルで配信サーバに送出します。ほかにも、徐々に普及が進みつつある「H.265（HEVC）」や「HLS（HTTP Live Streaming）」を含め、さまざまなプロトコルが使われることもありますが、現状は、まだまだH.264/AAC、RTMPの組み合わせが一般的です。

H.264やAACによる圧縮の特徴

データのサイズを小さくする「圧縮」、それを元に戻す「伸張」には、大きく2つの方式があり、元のデータを完全に再現できる「可逆圧縮（ロスレス圧縮）」と、元のデータは失われるけれど圧縮率は高く、まあまあいい感じのデータが再現できる「非可逆圧縮（不可逆圧縮）」があります。

H.264もAACも共に「非可逆圧縮」であり、圧縮率を高めていく（実際には、データの情報を間引いていく）と、どんどん画質や音質が悪くなっていきます。もともと持っている映像・音声の情報を間引いて、伝えるべき情報量を減らすことで、大きな圧縮を可能にしています。

（オープンソースのH.264のCODECである「x264」ではロスレスの出力も可能ですが、実際にはデータは巨大になります）



実際圧縮とその限界がどういうものかイメージするには、以下の動画がすばらしくわかりやすいので、まずはこちらをご覧ください。

一方の「可逆圧縮」の例としては「ZIPファイル」などがおなじみかと思います。元のデータが復元できる代わりに、データによっては大きな圧縮率は期待できません。なお、すでになんらかの方式で圧縮されたファイルをZIP形式で圧縮しても、ほとんど小さくならないのですが、これは、元のデータの持つ情報量より小さくすることができないからです。

映像配信、ストリーミングの進化の歴史のなかでは、モバイルを含むインターネット回線の高速化（バンド幅が広くなる）とともに、高い圧縮をかけても遜色のないCODECが開発されたこと、また、その圧縮・伸張をリアルタイムに実行できるコンピュータ（スマフォ含む）の処理能力の向上が大きく貢献しています。

H.264に比べて、H.265は同程度の画質を約半分の容量で済む代わりに、エンコード・デコードの負荷は大きくなっているように、コンピュータの処理能力の向上とともに、より高い圧縮が可能になっている一面があります。

また、同じエンコーダを使った場合でも、よりコンピュータのCPUやGPUのパワーを使う設定にしたほうが、一般的には画質がよくなります。それだけ、圧縮には多くの処理能力が必要ということです。以下は、Wirecastで「x264」のCODECを利用した場合の設定ですが、「超高速」〜「非常に低速」の各設定では、後者のほうが画質はよくなりますが、CPUへの負荷は大きくなります。

H.264やH.265も、現代の動画の圧縮は、映像の連続しているフレームが似ていることと、フレーム内での物体の動きやフレーム全体のカメラの動きがあるという特徴を利用して、各フレームの情報を削減したうえで、各フレームの個々の映像に関しては細かい情報を間引いていくこと（空間周波数の高い情報の粒度を下げる）で圧縮しています。

くわしく知りたい方は、「フレーム間予測」「動き保証」「離散コサイン変換 （DCT）」「量子化」「エントロピー符号化」などのキーワードを調べてみると、なぜ、元の映像の印象を大きく損なわずに圧縮できるのか、また、圧縮率を高めると、ブロック状のノイズ（ブロックノイズ）やアニメのような画では輪郭周辺にモスキートノイズが顕著に増えるのかがよくわかります。

なお、広く使われている「JPEG」も離散コサイン変換やエントロピー符号化（ハフマン符号化）を利用して圧縮が行われていて、これらは現代の画像や映像の圧縮の基礎となっています。


H.264やH.265でも、JPEGと同様に、同じ映像を圧縮する場合でも、どの程度情報を間引くか（量子化）で、圧縮率を制御することができ、エンコーダは、それによって目標とするビットレートでデータを送るようになっています。


エンコーダで送出したものが、そのままユーザーに届くわけではない

ほとんどのプラットフォームでは、エンコーダで送った映像と音声がそのままエンドユーザーのもとに届くわけではありません。というのも、ユーザーの回線状況に応じて、適切な解像度やビットレートの映像・音声に切り替える処理が必要だからです。回線状況ではなく“おさいふ”状況に応じて、“ギガ”を使わないように、解像度を下げて視聴したいユーザーもいるでしょう。

ユーザーの回線状況に応じて、適切なビットレートの映像・音声を取得できる仕組みは「アダプティブ・ビットレート(ABR)」などと呼ばれています（エンコーダの設定で出てくる「平均ビットレート(ABR)」とはまったく別の概念ですが、ややこしいですね）。

また、現在の多くの再生環境は、HTTPをベースとしたHLSやMPEG-DASHというプロトコルでデータを受信しており、再生環境に応じた方式で送る必要もあるため、フォーマットの変換も行われます。

そのため配信サーバでは、エンコーダから受信した映像と音声を、複数の解像度・ビットレートで再びH.264やH.265などでエンコード（トランスコード）します。そうして、用意した複数の解像度・ビットレートのデータから、ウェブブラウザやプレーヤーが回線状況に応じて適切なデータを選べるようにすることで、アダプティブ・ビットレートが実現できるというわけです。

実際、YouTubeやAmazon Prime Videoなどを視聴していて、急に画質が悪くなったり、逆に画質がよくなったりする経験をしたことがあるかと思いますが、YouTubeなどのサーバ側には複数のビットレートのデータが用意されていて、回線状況に応じて、再生するデータが自動で切り替わっているからです。

多くの配信プラットフォームでは、サーバ側でABRのためのトランスコードの処理が走っています。こうした処理は、ライブ配信はもちろん、ライブ配信のアーカイブ、アップロードしたファイルでも同様に行われます。

プラットフォームによっては、ライブ配信とアーカイブでは、トランスコードの処理は別々に行われていて、画質や音質がライブ配信時とアーカイブでは異なっている場合もあります（また、ライブ終了後、すぐにアーカイブが見られないサービスは、ライブ配信の終了後にアーカイブ用のトランスコードが実行されているからです）。

現在広く普及している、HLSやMPEG-DASHでの配信の場合、配信サーバは、エンコーダから受信したデータを順次トランスコードし、複数のビットレートのデータを作成します。その際、数秒〜10秒の一定時間ごとにデータを分割（セグメント化）し、配信で必要な形式（MPEG2 TSやfragmented MP4）にした小さな動画・音声ファイルとして、ライブ配信の進行に伴って、ユーザーがアクセスするサーバから取得できるように、順次展開していきます。

それだけでは、プレーヤーはどのファイルを取得すればいいのか判断できませんので、回線速度に合わせた最適なデータや、最新のデータのURLなどの判断などに必要な「プレイリストファイル（マニフェストファイル）」を作成し、これもまたライブ配信に進行に合わせて随時中身を更新して配信サーバに展開する処理が行われます。

プレーヤーは、まずプレイリストファイルを取得したうえで、回線状況に応じた動画・音声データのURLを判断し、分割された動画・音声データを取得し再生します。プレイリストファイル自身に書かれている更新頻度に応じて、プレイリストファイルも定期的に再取得することで、最新の映像・音声ファイルのありかもわかり、ライブ配信が実現されています。プレーヤーは回線状況やユーザーの設定に応じて、適切な解像度・ビットレートのデータをダウンロードして再生、もし途中で回線状況が悪化すれば、より低い解像度で低ビットレートのデータに随時切り替えることで、再生を停止しないようにしています。

HLSもMPEG-DASHも、通常のウェブサイトのデータ取得で使われるHTTPないしHTTPSを利用するたシンプルなしくみになっており、キャッシュも含め、CDNの利用もしやすく、多くのPCやスマートフォンのブラウザが標準で対応しているのも特徴です。

エンコーダから送られた映像・音声はトランスコードされるため、一番最良の解像度・ビットレートにトランスコードされても破綻しない画質・音質のデータを打ち上げる必要があります。基本的にはサーバが受入れ可能で、打ち上げに利用するネット回線の帯域的にも問題ない解像度・ビットレートを選ぶことになります。

なお、PIA LIVE STREAMで利用されている配信プラットフォームULIZAのように、「打ち上げ」の段階で、複数の解像度・ビットレートのデータをエンコードして送る必要のあるサービスも存在します（この場合、トランスコードはされないものの、配信に必要なフォーマット変換は行われます）。こうしたサービスは映像制作側が細かく画質や音質を制御することができる余地があるのは大きなメリットですが、現場に複数のエンコーダを用意するか、AWS Elemental MediaLiveなどのサービスを別途使って、必要な解像度・ビットレートのストリームを複数作成して配信サーバに送るなどする必要があります。また、送った映像と音声が基本的にはそのままユーザーに届くため、安定した視聴のためには、配信途中でのビットレートの極端な増大を抑えることも含めて適切なエンコードが必須となります。

また、ツイキャス（TwitCasting）のように、最高画質の映像は打ち上げたそのままで、低いビットレートの映像だけがトランスコードされるプラットフォームも存在します。こうしたプラットフォームの場合も、打ち上げるデータのエンコードの質（主にビットレートが安定しているか）が、ユーザーの安定視聴を左右することになります。

映像のビットレート

映像の単位時間あたりの情報量は、映像を構成する各フレームの複雑さ、フレーム間の動き、フレームの解像度（フルハイビジョンだと、1920×1080ピクセル）、色深度、1秒あたりのコマ数を表すフレームレートで変わってきます。

H.264の場合で、フルハイビジョン（1080p）、秒あたり30フレーム（30fps）の場合、映像の複雑さや動きの激しさにもよりますが、4〜6Mbpsくらいでの打ち上げが一般的です。YouTube Liveの推奨値は、1080p60（60fps）で4.5～9Mbps、1080p30（30fps）で3〜6Mbpsとなっています。

必要より低いビットレートですと画質が劣化し、最悪ブロックノイズがはげしくなりますし、高いビットレートにすれば画質は向上しますが、打ち上げの回線のバンド幅（回線速度）や安定性によっては配信に障害が発生します。

配信プラットフォームによっては、より高いビットレートを受け入れられる場合もありますが、配信プラットフォームが受けられるビットレートを超えないことは重要です。

打ち上げたデータがそのままユーザーに配信されるようなサービスの場合は、ここの設定が不適切で、必要以上に高いビットレートにしてしまうと、ユーザー環境での再生に問題が発生する場合もあるので注意が必要です。

YouTube Liveや多くのライブ配信サービスのように、サーバ側でのトランスコードが必ず行われる場合は、受入れ可能なビットレートを超えないように、なるべく高いビットレートにしたほうが、画質的には有利ということになります。

フレームレートについて

フレームレートとは、1秒間に何枚の静止画（フレーム）で映像が構成されれているかを示す数値です。ライブ配信の場合は秒あたり30フレーム（30fps＝frames per second、30p）か60フレーム（60fps、60p）のいずれかとなるプラットフォームがほとんどです。


ゲーム配信やeスポーツのように滑らかな動きの表現が重要なコンテンツでは60fpsが必須ですが、セミナーなどであれば30fpsで充分でしょう。音楽モノのライブ配信では、あえて映画で使われてきた24fps（23.98fps）で映像を制作することも多いです。実際、同じ映像を60fps、30fpsと24fpsで観てみるとまったく印象が違います。60fpsは動きはスムーズでリアルですが、生々しすぎる印象を与えることもあり、意図を持って24fpsが選ばれることもあります。最近のデジタルカメラは映画制作なども想定したものが多く、24fpsでの撮影も可能であるのも、そうした映像が作られている背景にはあると思います。

ほとんどのプラットフォームは、24fpsでのライブ配信には対応していないため、24fpsで制作している場合でも、教科書通りにするなら30fpsに変換しての打ち上げとなります。実際には24fpsで打ち上げれば、プラットフォーム側のトランスコーダで30fpsに変換して配信されるケースも多いので、利用するプラットフォームのふるまいや、変換の品質なども確認するとよいでしょう。

フレームレートが高ければ、その分、打ち上げや視聴に必要なビットレートも大きくなります。回線のバンド幅が極めて限られているケースでは、あえて打ち上げのフレームレートを下げることも考えられます。配信プラットフォーム側でフレームレートを変換してくれるのであれば、24fpsで制作しているならそのまま打ち上げるほうが、打ち上げに使う回線の利用効率的には有利になります。

フレームレートの変更は、演出意図だけではなく、打ち上げに利用する回線が極めて限定されているときに、あえて落とすことも考えられます。筆者が、北海道の更別村にある「十勝スピードウェイ」から配信を行なった際は、フレッツ光のサービスエリア外で、回線として利用できるのは、ADSLとLTE網だけという過酷な条件でした。ADSLは上りのバンド幅が配信には足りないため、LTE網だけが頼りではあったのですが、観客のみなさんがスマホを使うとLTE網も回線が混雑し配信が困難となりました。そのため、ビットレートを落としつつ、画質をある程度維持するために、フレームレートを下げて配信を行いました。複数の回線をまとめて（ボンディングといいます）打ち上げを行うことのできる「Live U Solo」を用意していたのですが、携帯電話の基地局の能力のギリギリの状況となってしまい役に立たず、有線LAN接続可能なLTEのモバイルルータとLiveShell Xを利用して、回線状況を見ながら、配信中にフレームレートを落としたり戻したりしながら配信を行いました。通常は不要ですが、こうした環境下では、配信途中にビットレートやフレームレートを調整できるエンコーダだと助かります。

プログレッシブとインターレース

映像信号は、歴史的な事情で「プログレッシブ」と「インターレース」という2つの方式があります。ライブ配信やインターネット上の動画配信では、基本的にプログレッシブで再生され、打ち上げの際にもプログレッシブで行われます。

そのため、ライブ配信を中心とした映像制作では、撮影・スイッチング・収録・打ち上げまで、すべてプログレッシブで行うほうがシンプルなのですが、日本の地上デジタル放送などでは59.94iが使われている関係で、ビデオカメラやスイッチャの組み合わせによっては、インターレースでの制作となることもまだまだあると思われます。

そうしたケースでは、エンコーダかその手前で、インターレース→プログレッシブ変換（I/P変換）が行われるのですが、その質が低いと、ノイジーな映像となってしまいます。I/P変換をエンコーダでやらなければならない場合は、その品質についても注意が必要です。


GOP、キーフレーム間隔

H.264などの現代の多くの映像圧縮技術では、「GOP（Group Of Picture）」という単位で処理を行います。映像は複数のフレーム（コマ）の連続で構成されているのですが、すべてのフレームを静止画として圧縮するとデータ量が大きくなりすぎるため、完全に元の静止画を含むフレーム（キーフレーム、Iフレーム）のほか、前後のフレームのデータを元に作られるフレーム（Pフレーム、Bフレーム）がたくさん含まれています。

これらフレームの1つのまとまりがGOPで、かならずIフレームを含みます。ライブ配信では、1つのGOPに含まれるデータをすべて受信すれば、そのGOP内のフレームがすべて再現できる「クローズドGOP」という方式が利用されています。一方、前後のGOPのデータも利用しないとすべてのフレームが再現できない方式は「オープンGOP」と呼ばれます。

「GOP長」が長いとデータ量は削減され、短いとデータ量は増えるのですが、ライブ配信ではGOP長を2秒に設定する場合がほとんどです。この設定値は「キーフレーム間隔」と呼ばれる場合もあります。

エンコーダにせよ、トランスコーダにせよ、プレーヤーにせよ、圧縮・伸長は「GOP」単位で処理を行うため、ここ長いと、配信〜再生にかかる遅延が大きくなってしまうばかりか、配信プラットフォームによっては適切に処理できない結果となりますので、かならずプラットフォーム側が推奨する値とします（推奨値が示されていない場合は「2秒」となるように設定しておけば多くの場合、問題ないでしょう）。

なお、GOP長、フレームレート間隔の設定は秒で行うエンコーダと、フレーム数で行うものがあります。後者で2秒に設定したい場合、30fpsであれば60フレーム、60fpsであれば120フレームとすることになります。

CBR or VBR

一部のエンコーダの設定には「CBR」や「VBR」という項目が存在しています。「CBR（Constant Bit-rate）」は「固定ビットレート」、「VBR（Variable Bit-rate）」は「可変ビットレート」と訳されることが多いです。

CBRは、入力された映像の複雑さに関係なく、設定したビットレートを厳密に保つようにエンコードする方式です。一方のVBRは入力された映像が複雑であればより高いビットレートになり、映像が単純だったり静止画であったりすると、ビットレートは下がる方式です。

H.264は「VBR」しかなく、完全なCBRは原理的には実現できないのですが、エンコーダによっては「CBR」の設定が存在します。はたして、どのようになっているのでしょうか？

純粋なVBRではあらかじめ設定した圧縮率（実際には「量子化」をどの程度行うかで設定する）で圧縮を行い、出力されるビットレートは完全になりゆきになる方式です。ファイルとして保管しておく分には、画質としても有利なので問題にはならないのですが、インターネットを経由し送信し、さらに配信サーバでのリアルタイムのトランスコードの処理も必要なライブ配信では不都合があります。

そこで、ライブ配信で使われるエンコーダの場合はVBRであっても、目標となるビットレートを設定して、それに近づくように圧縮率を常時変えながら圧縮を行います（ABR＝Average Bit-rateと呼ぶこともあります）。

この辺の処理はエンコーダによって異なるため、どれくらい目標として設定したビットレートを超えたりするかはエンコーダの実装に依存します。

多くのVBR（ABR）の実装では、入力されている映像に応じて圧縮率を調整して処理していくのですが、たとえば静止画から動画に移った直後などは、それまでの圧縮率のままで処理すると、瞬間的に目標ビットレートを大きく逸脱して、高いビットレートになってしまうこともあります。後述するように、想定されない高いビットレートでの打ち上げは、配信停止などの事故を招きます。以下は、Wirecastで同じ映像を入力してテストしたものですが、利用するCODECや設定によってまったく異なることがわかります（赤線がビットレートの変化です）。

そこで、受信側が安定しデータを処理するためには、ビットレートの上限をある程度制限する必要があるのですが、実用的なアプローチの1つとして「VBV＝Video Buffer Verifier」という仕組みを使って、一定時間の平均ビットレートを制限して、想定する受信側のバッファサイズを超えないようにする処理をするものがあります。この処理での問題は、上記のように「静止画から動画に移った直後」などでは、ビットレートの上限を超えないように、つまり、受信側のバッファを溢れさせないようにするために、圧縮率を著しく上げる必要が出てしまい、そのタイミングで一時的に画質が極めて悪化してしまうことです（静止画部分をもっと圧縮しておけば、動画部分を犠牲にしなくてもよいわけですが、時間を巻き戻せないため、時すでに遅しということになります）。



そこで、一度圧縮処理を行ってみたうえで複雑さを判断して、常に圧縮率を適切に調整して、最終的な圧縮処理をするものもあり、「2パスエンコード」と呼ばれます。そのような処理を行うと、求めるビットレートから大きく逸脱はしなくできるものの、映像が入力されてから出力されるまでの遅延時間は大きく、CPUやGPUの負荷も大きくなっていきます。

このように、VBRでも求めるビットレートから逸脱しないようにがんばれば、CBRに近づけていけることになります。

そんなわけで、実際にはCBRとはいっても、実態はVBRであって、設定したビットレートをどう維持するのかは、エンコーダの実装に依存していますので、利用するエンコーダの振る舞いをしっかり確認しておくのがよいでしょう。

H.264などの現代の圧縮技術は、原理的に圧縮後のデータ量は実際に圧縮しない限りわからないため、厳密に設定したビットレートを維持してエンコードすることは不可能です。そこで、完全なCBRとして振る舞っているようにみえるものは、指定されたビットレートを常に下回るようにエンコードして、足りない部分は、「フィラー」と呼ばれるダミーデータで埋めることで、設定したビットレートを維持するようにしています。

ライブ配信での打ち上げでは、完全なCBRは回線の無駄でしかないため、ビットレートの変動を配信プラットフォームが受け入れられる範囲に収めたVBRであれば問題ないということになります。


送信のビットレートが想定より大きくなるリスク

これまで説明したとおり、エンコーダの種類や設定にもよるのですが、入力される映像によって設定した値よりもビットレートが大きくなることは往々にして発生します。多くの場合は問題ないのですが、プラットフォーム側が受け入れられるビットレートの上限が、あまり余裕のないものだと事故につながることがあります。

より強固にCBR的に振る舞うことのできるエンコーダであれば問題はないのですが、そうでない場合、エンコーダによっては設定した映像のビットレートが5Mbpsだったとしても、映像の変化によっては一時的に9Mbps程度まで上昇するということも実際に起こります（先に紹介した、WirecastでのApple H.264を利用した例では、4.5Mbpsの設定なのに、静止画から動画に切り替わった直後には、11Mbpsを超えています）。

もちろん、そうした場合も徐々に圧縮率を高めてすぐに5Mbps近くに落ち着くわけですが、配信プラットフォームのサーバの受信バッファの設計に余裕がない場合、配信が停止する事故に繋がりかねません。また、モバイル回線での打ち上げなど、回線のバンド幅（回線速度）がギリギリの場合には、そもそもサーバへの送信が間に合わないことも起こりえます。

というのは、映像の処理は最低でもGOP単位で行われるため、配信サーバ側は少なくともGOP長（キーフレーム間隔）のデータをためておく受信バッファが必要になります。実際には、常に受信とトランスコーダの読み出しが並行して進行しているので、安定した処理のためには、より大きな容量のバッファが必要です。



もし、打ち上げのビットレートが、サーバの設計の限界を超えてしまうと、入力のバッファが溢れて新たなデータを受信できなくなってしまいます。受信できない場合は、サーバの実装にもよりますが、エンコーダが送ったデータの一部は破棄されるか、そもそもエンコーダがデータを送ることができない状態が発生します。

配信プラットフォームのトランスコーダは必要なだけのフレームのデータを常にバッファから読み出す必要があるのですが、こうした状況下では、トランスコーダが処理をしようとしても、必要なデータがバッファにはない結果となり、配信は停止してしまいます。

配信プラットフォーム側が、どこまで高いビットレートまでなら受信できるのかという限界値を示しているのであれば、それを超えないように、利用するエンコーダーの特性を考慮してビットレートを設定すればよいことになります。

しかし、プラットフォームによっては、限界値は示さず、エンコーダによるビットレートの変動を考慮せずに、推奨値を提示していたりする場合もあるので、推奨値だけを信じてエンコーダを設定してしまうと、入力映像によって大きくビットレートが上昇し、泣きをみる事故も起こり得るので注意が必要です。

使っているエンコーダの特性や入力される映像によって、どれくらいビットレートが上下するかは変わってきますし、プラットフォーム側の推奨値も信頼できるとは限らないので、事前に充分検証することが望ましいと思います。

音声のビットレートとカットオフ周波数

音声に関しても映像と同様に圧縮率が高まれば音質は下がっていくのですが、一番わかりやすい変化は、高域の信号（高音）がどこまで入っているかという点になります。



圧縮前の音声データに関していえば、映像の世界でよく使われる音声のサンプリング周波数は48kHzですが、その場合では24kHzの高音まで再現できますし、CDなどで使われているサンプリング周波数である44.1kHzでは、およそ22kHzまでは再現可能です。

ライブ配信でよく使われるAAC 128kbpsや192kbpsのビットレートの場合、エンコーダにもよりますが、15kHz〜19kHzより上の高音はバッサリ切られていることが多く、その周波数を「カットオフ周波数」と呼んでいます。

人の声が中心なトークイベントであれば、高域がカットされていても問題ないのですが、音楽モノの場合は注意が必要です。


最近では、高音質を謳うライブ配信プラットフォームも登場していますが、エンコーダによっては、ビットレートを256kbpsや320kbpsまで上げてもカットオフ周波数が変わらず17kHzあたりでカットされているものも存在していますので、エンコーダの選択の際は確認が必要です。後編では、その辺のチェックもしていきたいと思っています。

とはいえ、人は年齢ともに高域の音が聞こえなくなっていきますし、Bluetoothイヤフォンなどでは、圧縮して音声を伝送している関係で、高域がそもそもカットされているものも存在します。ユーザーの視聴環境もさまざまですから、ただ低域から高域まで通ればいいといいというものでもなく、収録やマスタリングでよいバランスの音をつくるほうが聴感上の「音のよさ」に貢献する部分もありますので、特に音楽モノでは、まずはそちらに注力するべきとも言えます。

このnoteを公開したあとで、Wirecast安いときに買っておけばよかった、というコメントを知人からいただいたのですが、実際問題、ほとんどのライブ配信プラットフォームは、トランスコード時点で17kHzより上はカットされていて、高い周波数帯域まで送る必要があるのは、高音質を謳うプラットフォームを使う場合くらいかなとは思います（2021年9月1日 19:50追記）。

CPU、GPUの負荷

H.264やH.265での映像や音声の圧縮には、多くの計算が必要で、エンコーダが使うCPUやGPUの処理能力の多くが利用されます。ハードウェアのエンコーダであれば、映像の取り込み（キャプチャ）からエンコード、送信までを1パッケージ化していて、適切なハードウェアとなっているので、考慮は必要ありませんが、PCやMacを利用したソフトウェアベースのエンコーダを利用する場合は、そこに対する考慮は極めて重要です。

PCやMacは、エンコーダとなるソフトウェアだけではなく、他のアプリケーションやさまざまなバックグランドプロセスが動いているため、それらを含めて、CPUやGPU、メモリ、内部のバスのバンド幅などのリソースが不足しないようにしておく必要があります。また、映像の取り込みに使うキャプチャ装置の選択によっては必要とするリソースの量も変わってきます。

安定したエンコードのためには、PCやWindows、macOSの知識も必要になってきます。特にPCの場合、使用するパーツや周辺機器の組み合わせで安定度も変わってくることになります。

現代のCPUは負荷や温度などによって、CPUの性能を常時調整していて、高温になったときに、性能を落としてCPUを保護するためのサーマルスロットリングの機能があり、不意なエンコード性能の不足を招いたりします。特にラップトップの場合、埃などが冷却ファンにたまることでの冷却性能の低下も起こりやすいため、作業環境の空調なども含めたケアが必要となります。


CODECの選択

WirecastやOBSなどのソフトウェアでは、同じH.264でエンコードする場合でも、CODEC（エンコーダ）が選べるものがあります。macOS版のWirecastでは、「Main Concept H.264」「x264」「Apple H.264」の3つから選択でき、同じくmacOS版のOBSでは「x264」「Apple VT H264 Hardware Encoder」「Apple VT H264 Software Encoder」から選択可能です。



先に説明したCBR、VBRの振る舞いは、これらCODECによって異なりますし、同じ映像を入力した場合の画質も異なってきます。また、PCやMac用のソフトウェアの場合、CPUやGPUをどれくらい使うかも、CODECによって異なります。

Wirecastの「Apple H.264」やOBSの「Apple VT H264 Hardware Encoder」は、GPUを利用することで、CPUの負荷を抑えることができるなど、特性が違います（以下は、Wirecast 14.1.0のエンコーダ設定）。

WirecastやOBSで利用できる「x264」の場合は、圧縮品質とCPUの利用とのバランスを決めるパラメータがあります。CPUリソースをより多く使えば画質はよくなりますが、不必要に上げてもあまり意味はありませんし、安定性に影響が出ます。また下げていくと、負荷は少なくてすむものの、画質は犠牲になります。

音声についても、AAC-LCやHE-AACの選択ができたりしますが、配信プラットフォームによって対応しているかどうかで違いがあります。

プロファイル

H.264には、利用できる色空間や圧縮の方法など、さまざまな機能があるのですが、エンコーダやデコーダ、トランスコーダや再生用のソフトウェアによって対応している機能が異なります。どの機能に対応しているのかをわかりやすくまとめたものが「プロファイル」で、「High」「Main」「Baseline」など多くのプロファイルが設定されています。

上記3つでは、「Baseline」が一番基本のもので、「Main」「High」の順で対応する機能が増えていきます。そして、後者のほうがより効率的な圧縮を行うことができます。通常はHighプロファイルで問題ありませんが、配信プラットフォームによっては、BaselineやMainでないと正常に処理できないものもあるので注意が必要です。

エンコーダの信頼性や回線のバックアップ

ソフトウェアベースのものでは、エンコーダやOSそのものの不安定さという問題もありえます。配信中にエンコーダのアプリが突然異常終了したりハングアップするなどの状況は恐怖でしかありません。ソフトウェアのバージョンや、PCやMacの環境、他に動作するソフトウェアや利用するキャプチャユニットなどの周辺機器によって、これらの安定性は変わってきますので、事前に充分テストする以上の対処方法はありません。



また、キャプチャユニットと接続するThunderboltケーブルが抜けてしまうなどの事故も起こりえます。接続端子にロック機構のないHDMIだと、HDMI端子が抜けてしまうという事故のリスクもあるでしょう。PCやMacだけでなく、ハードウェアベースのエンコーダであっても、当然故障や電源喪失などの事故の可能性は常にあります。

さまざまな事故につながる原因はありますが、一番起こりがちなのは、打ち上げに利用するインターネットの回線の切断やバンド幅（回線速度）の不足といっていいでしょう。

業務での配信の場合、そうしたさまざまな配信を止めてしまうリスクにどれくらい備えるかというのは、予算やお客様の要求によって変わってきます。

回線断への対策として、もっともシンプルなものでは、Blackmagic Designのエンコーダ製品であるWeb Presenter HDやWeb Presenter 4Kのように、メインの有線LAN回線のほかに、本体のType-C端子にLTEモデムやUSB-Ethernetアダプタ経由で他の有線LAN回線を接続することで、メイン回線が切断された場合にバックアップ回線に切り替える機能を持っているものがあったりします。

Live U SoloやTVU Router、Speedifyのように複数のネット回線を束ねて打ち上げができるソリューションなども存在します。

また、YouTube LiveやStreaming+、AWS Elemental MediaLiveのように、配信プラットフォーム側が複数のストリームの打ち上げを受けて、トラブルが発生したらバックアップに切り替える仕組みをもっているものも存在します。そうしたサービスであれば、エンコーダとネット回線も2重化して、同じ映像を別のエンコーダと回線で打ち上げることで、起こりがちなトラブルに対処することが可能です。

配信プラットフォームが複数ストリームの打ち上げに対応していない場合でも、複数ストリームの受信と、他のサービスへの再打ち上げに対応しているサービス（たとえばAWS Elemental MediaLiveなど）で一旦受けたあとに、そこから最終的な配信プラットフォームに送るなどすることで、打ち上げに使う“ファーストマイル”のネット回線という、ライブ配信で一番信頼性の低い部分の障害を回避する方法もあります。

まとめ

「導入編」といいながら、かなりの長編となってしまいましたが、いかがでしたでしょうか？　ライブ配信の「配信管理」って、とても地味ですし、トラブルが起きなければ、適当にやっててもなんとかなってしまうのですが、だからこそ、事故は起こりがちです。

事故があったときに原因を切り分け、適切な対処をしたり、事故を防止していくには、地道に原理を理解して、それをもとに分析するしかありません。また、自分たちの業務にあった適切なエンコーダを選択し、適切な設定をするにも、こうした知識をもって、根拠ある選択をすることが極めて重要です。

最初にも予告しましたが、具体的なエンコーダ製品を例に、それぞれの動作がどうなっているかを検証したnoteも今後公開していきたいと思います。