配信途切れについて

先に書いておくと、この内容は割と難しいです。

Mixer配信で、Low latencyをオンにするとたまに音声や映像の途切れが発生する。
これがなぜ発生するのか、どういう原理なのかについて説明していきたい。


まず、配信時には、音声と映像を33ms毎(30fpsの場合はおそらく33ms)に、
その音声と映像をエンコードし、パケット化する。
実はこの時、そもそもエンコードすることができずに、その部分のデータをロスしてしまうことがある。



これはそもそも配信に使うハードウェアの負荷によるものが大きい。
これにより配信途切れが発生する。
回避するためには、エンコーダの設定を変更し、
負荷の少ないものにするか、ハードウェアを更新するか、
ソフトウェアエンコードでなくハードウェアエンコードに変更したほうが良いだろう。



次に、データを33msごとにパケット化し、これを送る。
ここで、上り回線の帯域が足りないか、家からプロバイダーへの上り回線の帯域自体は足りていたとしても、そこから先でそのパケットが何らかの原因でロスした場合、そこで配信途切れが発生する。
もしくは、パケットの順番が入れ変わって届いたり、パケットの到着が遅くなってしまった場合、デジッタバッファ(*)が十分に無いと配信途切れが発生する。
MixerのLow latencyモードがオフになっている場合は、おそらくはMixerのサーバーで処理してこの配信途切れが目立たないようにごまかしているのと、受信者側のデジッタバッファを増やしているのだろうが、
Low latencyモードでは少しでも配信遅延を減らすためにこのデジッタバッファを最低限にしているため、
仮にこのデジッタバッファが0.1秒だった場合、パケットが0.1秒遅れただけで配信途切れが発生することになる。
また、デジッタバッファが少ない場合は、欠けたパケットを前後のパケットから推測して補うことが難しくなることがある。
ある程度多ければ推測して補うだけの時間があるが、少ないと少しでも早く届ける必要があるため、そうもいかないことが多い。これにより、余計配信途切れが目立つようになる。



また、これは受信側の問題であるのだが、受信側の下り回線が貧弱な場合等は配信途切れが発生する。
Low latencyモードの場合は、おそらくは配信データをそのまま視聴者に渡すため、受信側の帯域もある程度潤沢である必要がある。
元の解像度よりも低い解像度で見たい場合等は必然的にLow latencyモードをオフにする必要がある。



*:デジッタバッファとは、簡単に言えば、”受信側が用意する”データの途切れに備えるためのデータ。これが潤沢にあると遅延は大きくなるが配信途切れが発生しづらくなり、少なければ少ないほど遅延が少なくなるが、少しパケットをロスしただけでも配信途切れが発生しやすくなる。

デジッタバッファについて詳細に知りたい場合は以下のリンクを参照してほしい。
http://www.cisco.com/c/ja_jp/support/docs/voice/voice-quality/5125-delay-details.html#dejitterdelay
また、デジッタバッファ以外でも、そもそもの配信遅延の話に関わるような話も書いてあるため、興味があればそれ以外の項目も見てみると良いだろう。

Mixer配信について

最近MonappyでTwitch連携やMixer連携ができるようになったのでここに記す。

基本的なやり方自体は別のサイトでもわかるが、
Monappyの通知等を使いたい場合は、
それ特有のことをしなければいけないのでここに記す。

ここでは、OBS Studioという配信ソフトで配信する方法を解説する。

1.まずOBSを入れる

https://obsproject.com/download
より、Download Installerをクリックしてダウンロード。
インストールは各自で行なうようお願いしたい。

2.配信の設定をする

まず配信キーを入手する。これは配信用パスワードなので他人に漏れないように注意。

配信キーの入手方法はMixerの場合は、
Mixerの開き右上のアイコンのMANAGE CHANNELタブに行き、赤枠に囲まれたボタンをクリック。そうすると配信キーがコピーされる。
Regenerate Stream Keyを押すと配信キーがリセットされるので注意。



まず、自動構成ウィザードは使わない。
OBSを起動したら設定に入る。

次に、配信タブをクリックし、配信サービスおよび配信サーバー、配信キーを設定する。
Mixerを使う場合は以下のような設定にすれば良い。


次に、出力タブに行き、次のような設定にしておく。

Mixerはビットレートの制限は無いようなので、基本的にハードウェアエンコードを使い、ビットレートを高くすればそこそこ良い品質で配信できるだろう。(ハードウェアエンコードのほうがCPU負荷が少ない)。


もしエンコーダにハードウェア(NVENC)が表われない場合は、ソフトウェアエンコードを使うことになる。(AMD製GPUで使えるVCE等に関しては自分に環境が無いため、説明不可能。各自調べて頂きたい。)


ソフトウェアエンコードの場合は以下のようになる。

視聴者から配信途切れがあると言われる場合は、
CPU使用率が高い場合はエンコード方式を変えるか、エンコーダプリセットを変更する。
帯域が食われている場合はビットレートを下げることで上手く行くだろう。


知識のある方は出力モードを基本から詳細に変えて、詳細な設定が可能である。
ただし、書いてあることの意味が分かる場合のみこちらを利用することをお勧めする。
尚、詳細だと以下のような設定ができる。

3.配信する画面を決める

さて、これだけではまだ配信できない。配信するための画面を決定しなければいけない。
例えば、ゲームの場合はゲームキャプチャかウィンドウキャプチャを使って、その画面だけを写させることができる。
ただし、たまにそれに対応していないゲームがある。その場合は画面キャプチャで代用することができる。
また、BrowserSourceを使い、URLに以下のようなアドレスを入れると、Monappyで寄付された時に通知を表示させることができる。(また、このアドレスの最後に&mode=testと入れるとテストモードになる)
https://monappy.jp/transactions/stream_effect/(ユーザー名)?key=(キー)&volume=1.0


また、次のアドレスは寄付総額を配信中に表示させることができる。(この寄付総額は好きな時にリセットすることができる)
https://monappy.jp/transactions/total_donate/(ユーザー名)?key=(キー)


また、このような、画面や通知などのウィンドウ等の配信画面を構成する要素をソースと呼ぶ。
複数のソースがあると、どれが上でどれが下というのを調整したくなるかもしれない。
そのような時は、ソースを選択して、↑↓をクリックすることでどちらを上にするかを決められる。



これで配信の準備は整った。
あとは配信を開始する時は配信開始を押す。終了する時は配信終了を押せば良い。

楽しい配信ライフを！

動画の形式について 第四章 (動画コーデック編)

良くわからない人用の超簡単な解説

動画コーデックはVP9かH.265を使っとけ！だめならH.264だ！
ハードウェアエンコードは早くて画質が悪い！ソフトウェアエンコードは遅くて画質が良い！
NVencやQSVやVCEがハードウェアエンコードで、普通にCPUを使うのがソフトウェアエンコードだ！
ソフトウェアエンコードはCPUを使用するから特に配信時は処理落ちに注意！
配信先に制限があるか、回線が劣悪なら固定ビットレートを使え！そうでないなら可変ビットレートだ！

動画コーデック

第三章にも書いたとおり、動画もまた感覚的なものであるので、それ用の専用のコーデックがある。
動画の中のデータは、動画部分が占める割合が(普通は)最も多いので、このコーデックの選択により、同じ画質でも大きくデータ容量が変わる。よって、この動画コーデックの違いは踏まえておきたい。
また、当然対応するコンテナフォーマットも違う。対応しているコンテナでないと収容できないので、これらも覚えておきたい。
また、音声コーデックでも書いた通り、ビットレートの違いで動画を比較することは同じコーデックで無いかぎりできない。
コーデックの違いを比較する場合は基本的にビットレートを揃えてから比較する。

動画コーデックの種類

H.264

H.264は現在かなり主流のコーデックである。
しかし、後継のH.265よりも当然のことながら圧縮率で劣るので、これから段々使用されなくなってくる恐れがある。
ブルーレイディスクで使われることがある。

DivX,Xvid

一時期はDivX,Xvidがもてはやされた時代もあったが今やそうでもなくなってきた。
DivXとXvid、元は同じであるが、XvidはDivXの商用化に反対する一部が分裂して出来たものである。

H.265

H.265はH.264の後継である。H.264の半分のビットレートで同等の画質になるらしい。
まだ新しく、それ故に対応していないコンテナフォーマットもいくつかあるが、これからはこれが主流になる可能性がある。

VP9

VP9は、H.265に対抗するべくできたコーデックであり、フリーなコーデックである。
H.265に対抗すると言うだけあって、H.265と同じビットレートであれば同等レベルの画質になる。
Youtubeは再エンコードする際に動画部分にVP9コーデックを用いている。


もちろん、動画コーデックにも可逆圧縮コーデックはあるが、やはりファイルサイズが大きくなりがちなので省略する。
ただし、原本として持っておいたり、編集途中などで一旦出力し、さらに他の動画で使う場合等は可逆圧縮でも良いかもしれない。
尚、未圧縮もあるが、流石に未圧縮はデータが大きすぎ、いくらなんでも無茶なので書く気はない。

動画のエンコードについて

動画コーデックはファイルサイズの大きい動画を扱うので、符号化させるのにかなり時間がかかる。
そのため、コンテナフォーマットや音声コーデックでは扱わなかったが、ここではエンコードについての知識も書いておこう。


例えば動画を編集する時や、配信する時に、避けて通れないのがエンコードである。


エンコード方法については、ハードウェアエンコードとソフトウェアエンコードがある。
注：キャプチャーボードにおけるハードウェアエンコードとソフトウェアエンコードの違いはここでは取り扱わないので、注意。


ハードウェアエンコードはCPUやGPUの中にある専用回路を用いてエンコードする。
ソフトウェアエンコードはCPUの普通の計算機能を用いてエンコードする。

仮想通貨について勉強している人は、ASICというものを知っているかもしれないが、
ハードウェアエンコードはASICを使ってマイニングをするようなものである。


ではハードウェアエンコードのみを使えばいいのかと言えば、動画においてはそうではない。
ハードウェアエンコードは速度に優れるが、ソフトウェアエンコードよりもビットレートあたりの画質が悪くなる。
ただし、物によっては数十倍の速度でエンコードできるので、 ある程度容量を食ってもいいが高速にエンコードしたい場合はハードウェアエンコード、
容量や帯域幅(配信時)の制限が厳しかったり、そもそも対応していない場合や、画質あたりのビットレートを落としたい場合はソフトウェアエンコードを使うと良いだろう。
ただ、H.265のハードウェアエンコードからはハードウェアエンコードでもそこそこ画質が良くなってきており、もしかしたら今後ハードウェアエンコードにとってかわられる可能性はある。

また、NVencやQSVやVCEと言ったものはハードウェアエンコードのための機能である。


配信時に気をつけるべきことは、ソフトウェアエンコードの場合、CPUの使用率があまりに高くなると処理しきれなくなり、配信に支障をきたす場合がある。
ハードウェアエンコードの場合、リアルタイムエンコード時でも2passエンコードする余裕がある場合もあるい、これで同じビットレートでも画質を上げることもできるが(特に動きの多いものでは)、CPUでは基本的に処理が大きすぎてしまうので、配信時に2passエンコードするようなことは少ない。


また、第三章でも書いた通り、VBRとCBRとABRがあるが、
ニコニコ生放送のように制限が厳しい配信先や、通信速度が低く一秒間に多くのデータ量を送れない場合は確実にCBRにしなければいけないし、
保存目的や、自分の通信環境が良好で、多くのデータをどんどん送れるような回線を持っていて、かつ配信先の制限がゆるい場合はVBRを使うべきだろう。

この章のまとめ

VP9かH.265を使うべし。だめならH.264を使うべし。
処理の早さはソフトウェアエンコードよりもハードウェアエンコードのほうが圧倒的に早い。
ただし、画質あたりのビットレートはソフトウェアエンコードのほうが高い。
ただ、段々ハードウェアエンコードも進化してきており、今後ハードウェアエンコードにとってかわられる可能性はある。
また、配信先に応じてCBRにするかVBRにするかを決めると良い。

動画の形式について 第三章 (音声コーデック編)

音声コーデック

わからん人用の超簡単な説明

音声コーデックはOpusが最強、それが使えなかった場合はAAC
AACの中でもHE-AAC v2＞HE-AAC＞AAC-LCと、ちょっと違うぞ！
どれを使うべきかはコンテナフォーマットと相談だ！

音声コーデックとも音楽コーデックとも言う。

ここでは、動画で使われる音声コーデックとそのコーデックの特徴や機能について説明していく。

そもそも音声や音楽は波であるので、それに特化した圧縮方式を用いたほうが効率が良い。
また、音楽は元の全てのデータを保持しなくとも良い。(音楽とは感覚的なものなので、人間への伝わり方が同じであれば削れるだけ削ったほうが良い)
というのも、音楽は、その音楽の全てのデータを保持したのと、ある程度データが削られたものがあるが、
ある程度削ったとしても多くの人間の耳には違いがわからない故である。
テキストファイルのように、中の文章が一部違っては困るようなものはZip等で圧縮するが、
音楽や動画は一部が欠落しても問題無いのである。

全てのデータを保持して圧縮したものは可逆圧縮、全てのデータを保持しないで圧縮したものは非可逆圧縮と言われる。
可逆圧縮コーデックでなく、非可逆圧縮コーデックが世の中では主に用いられるが、非可逆圧縮のほうが、ほとんど同じデータをずっと軽く圧縮できるため、一般的な利用ではこちらのほうが良く使われる。

また、ビットレートが高いと音質が良いと聞いたこともいるのではないかと思うが、
これはコーデックによる。効率の良いコーデックであれば、低いビットレートでもまともに聴けるし、効率が悪いコーデックであれば、高いビットレートじゃないと音質が良くないといったことが発生する。
非可逆圧縮であまりにビットレートを高くしても、可逆圧縮にしたほうがサイズが低く、音質が良い場合もあるので、非可逆圧縮でビットレートを高くしすぎるのはよそう。

最近は、音声コーデックは、低ビットレートでも音質が良くなるように改良されていっている。
今はOpusが最もビットレート対音質が良いようである。少なくとも私は、160kbpsのMP3と64kbpsのOpusの区別は付かない。

それでは主流な音声コーデックを見ていこう。

MP3

名前が有名で、MP3以外を再生できてもMP3プレイヤーって言ったりするぐらい有名である。結構古い規格である。最近、開発終了がアナウンスされた。たまに勘違いされているが、MP3はフリーなコーデックではなく、個人の使用に限ってフリーである。法人等では使わないように。
古いだけあって、ほとんどのコンテナフォーマットが対応している。

AAC

MP3よりも高いサンプリング周波数に対応している。(とは言っても、96kHzも48kHzも私には違いがわからないが)
実はAACといっても何種類かある。一般的に使われるのは、AAC-LCやHE-AAC、HE-AAC v2。
新しく開発されたものほど低ビットレートでも良い音質になるように作られてきている。再生できる音楽プレイヤーはそこそこある。
MP4コンテナの動画では、AACとH.264が一緒に使われることが多い。
コンテナフォーマットはAVI,MP4,MOV,Matroska等が対応している。

Vorbis

Ogg vorbisと言われることもあるがOggはコンテナフォーマットである。
Xiph.orgが開発したコーデック。一時期もてはやされた時代があったが、
最近聞かなくなったのはHE-AACやHE-AAC v2が台頭してきたからかもしれない。
オープンソースのコーデック故、宗教上の理由で使う人もいるだろう。
後述のOpusに取って代わられ、既に開発が終了している。

Opus

現時点で最強のコーデックだと私は思う。50kbps前後でもまともに音楽が聴けるレベルである。
オープンソース。開発はXiph.orgである。Vorbis使っている人は是非乗り換えるべし。

コンテナフォーマットはOgg,MP4,Matroska,WebM等が対応している。Oggに入れられたOpusはOgg Opusと呼ばれる。
また、Opusは実はそもそもIP電話・VoIPを主眼に入れて開発しているため、今後VoIPでも主流になる可能性はある。


尚、余談だが、最近は、Youtubeは音楽はOpus 160kbpsで再エンコードされる。


上記は全て非可逆圧縮コーデックである。
可逆圧縮コーデックにはTAK,FLAC,Monkey'sAudio,LA等がある。ただ、ここは音楽についての説明ではなく、動画を作るための動画に使われるようなコーデックの説明なので、説明は省略する。
また、非圧縮のものはPCM,LPCM,リニアPCM等と呼ばれる。(厳密には、PCMとLPCMは少し違い、PCMにはG.711u-law/a-law等の対数PCMを含むがLPCMはそういったものは含まないがやはり省略。)

可変ビットレート(VBR)と固定ビットレート(CBR)、平均ビットレート(ABR)について

音楽や動画の中でのビットレートの割り振り方には、可変ビットレート、固定ビットレート、平均ビットレートの3種類がある。
それぞれここからはVBR,CBR,ABRと略す。V=Variable C=Constant A=Averageの略である。

VBRは、沢山データ量を割り振らなければその音を再現できないようなところではデータ量を多く割り振るし、逆にほとんどデータ量を割り振らなくともその音を再現できるようなところではデータ量を少なくしか割り振らない、これにより、必要なデータ量のみを常に割りふっていける(無駄が無い)ということである。
ただし、固定でないため、想定したビットレートになりづらいこと、リアルタイム通話などでは一定時間に通信可能なデータ量を越えてしまって、データが一部欠落したりするなどといった欠点もある。

CBRは、1秒あたりのデータ量を常に一定にして割り振っていく。
そのため、データ量を割り振らなくても良いところで割りふったり、圧縮効率が悪い(無駄が多い)といった欠点はあるが、常にデータ量が一定のため、データサイズが基本的に定まっているという利点がある。(ニコニコ生放送では、ビットレート制限があり、これを越えないためにはCBRを基本的に使う。Twitch等ではこの制限はないため、これを使う必要がない。)

ABRはVBRとCBRの中間で、平均して大体同じになるようにしていく。
ただ、当然特徴も、利点も欠点も両方の中間といったところである。

音楽を保存する目的の場合はVBR、通信をする場合で、通信環境が劣悪だったり、配信先に制限がある場合はCBRで良いだろう。

この章のまとめ

音声コーデックはOpus使うべし、新しすぎて対応してない等だったらAAC使うべし
ビットレートで音質が決まるのではなく、同じコーデックを使った時のビットレートで音質の違いがある。

動画の形式について 第二章 (コンテナフォーマット編)

コンテナフォーマット

良くわからん人用の超簡単な説明

コンテナフォーマットは箱だ！コンテナって言うぐらいだしな！
コンテナによって入れられる中身が違うから気をつけろ！
コンテナはMatroskaかMP4使っとけばとりあえず大丈夫だ！
対応してなかったり困ったら下の詳細な文章を読んでくれ！

コンテナフォーマットとは、第一章では、中身を入れる箱のようなものという説明をしたが、
そもそもコンテナという名前がついているので本当に箱みたいな機能をするのである。


さて、コンテナフォーマットの詳しい話をしよう。
コンテナフォーマット、実は入れられる中身がコンテナフォーマット毎に決まっているのである。
だから、例えばWAVはコンテナフォーマットであるが、これにVP9等の動画コーデックを入れることはできない。
そもそも、そのコーデックがどういう仕様か知らなければ、音声と動画の調整など無理な話である。


コンテナフォーマットの機能は、複数の動画や音声を入れるだけでなく、
動画と音声がずれることが無いように調整する機能や、字幕や著者名等、データに関するデータ(メタタグ)を入れる機能がある。

コンテナフォーマットの種類

コンテナフォーマットにはいくつか種類がある。それぞれ対応する中身も違う。

AVI

Windowsが標準で対応していたコンテナ。(元々Microsoft(MS)が作ったという歴史がある)
今では可変フレームレートに対応していない等で、古い仕様が問題になってきており、使われることはこれから少なくなるかもしれない。

MOV

Apple版AVIのようなもの。QuickTimeで使われるコンテナである。
Windowsへのサポートは終了しており、元々あまり使われていなかったのが更に使われなくなるかもしれない。

MP4

MPEG-4規格の”一部”である。最新の動画コーデックであるH.265や、良く使われる音声コーデックであるAACに対応しており、現在良く使われるコンテナフォーマットである。
拡張子は動画では、mp4が使われる。

Ogg

Oggはコンテナフォーマット。Ogg Vorbisという言葉を聞いたことがあるかもしれないが、Vorbisは音声コーデック名。Oggに入ったVorbisという意味である。
オープンなコンテナであるが、最近は別のにとって代わられ気味である。
拡張子は元々Oggだったが、今はOggを使うことは推奨されていない。(Ogg Vorbis用の互換のために使われるようにするとのことである)音楽はOga,動画はOgvにするように呼びかけられている。

Matroska

フリーなコンテナで、Oggより割合新しめ。古いコーデックからVP9やOpusといった最新のコーデックと幅広く対応している。こちらはMP4とは違い、オープンソースのコーデックに多く対応している印象がある。
Windows10以降、Windowsでは標準で対応している。
拡張子は動画では、mkvが使われる。

WebM

実はMatroskaから派生してできたコンテナである。Googleが開発している。
このコンテナフォーマットは、VP8,VP9,Vorbis,Opusのような、割合新しく、オープンソースなコーデックのみにしか基本的に対応していない。

この章のまとめ

最近ではMP4かMatroskaが基本的に使われる
オープンソースにこだわるならMatroskaにしとくと良い