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
また、デジッタバッファ以外でも、そもそもの配信遅延の話に関わるような話も書いてあるため、興味があればそれ以外の項目も見てみると良いだろう。

第一半減期は7/16の17時半の前後に来るだろう。お楽しみに。

尚、ハン・ゲンキ氏という人物がいるという話は、この半減期をもじったものである。
ネタなので楽しむべし。そういう楽しいところがモナーコインの良いところなのであるから。

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

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

1.まずOBSを入れる

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

2.配信の設定をする

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


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


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

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


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

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

動画コーデック

動画コーデックの種類

H.264

DivX,Xvid

H.265

VP9

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

この章のまとめ

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

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

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

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

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

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

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

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

AVI

MOV

MP4

Ogg

Matroska

WebM

この章のまとめ

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

コンテナフォーマットは箱！コーデックは中身！箱によって入れられる中身が決まってる！

最近、モナーコイン界隈で生放送をすることが流行っているようである。 Twitchでは、生放送した動画をダウンロードして編集することが可能である。また、そうでなくともそもそも生放送時にコーデックやコンテナフォーマットの知識があっても損は無いと思い、ここに記事を投稿する。

そもそも動画の形式とは何か？

動画の形式と言われて何を思い浮べるだろうか。

MP4？AVI？それともWebM？

たまにある質問で、AVIとMP4のどちらの方が画質が良いですか？という質問があるが、これは全くの見当違いの質問である。

なぜなら、そもそも、AVIとかMP4とかWebMと言ったものはコンテナフォーマットというものだからである。

コンテナフォーマットとは、その動画の中身を入れる箱のようなもので、箱自体で中身の良し悪しが決まるわけではない。

では中身とは何か？
コーデックという言葉を聞いたことがあるだろうか？
コーデックとは、Coder/Decoderの略語で、今使われている意味としては、動画・音声を符号化したものである。
VP9やH.264等の言葉を聞いたことのある人もいるかと思うが、これらは動画コーデックである。
また、動画そのものだけではなく音声も無いと動画は楽しめないので、音声コーデックもある。MP3やAACやVorbisやOpusが音声コーデックである。
ただ、動画コーデックと音声コーデックだけあれば良いというわけでなく、コンテナフォーマットは、これら動画や音声を纏めて、時間等を合わせたり、字幕やタイトルや作者名等のその他の情報を入れるために存在している。

この章のまとめ

1.そもそもビットコインを使わない

最も確実で、安く済む。取引所間での送金をモナーコインやリップルなどにすれば、ビットコインを使わずに送金が可能である。この選択肢が可能であれば使いたい。

2.送金手数料を引き上げる

送金手数料を引き上げればその分早く承認されやすくなる。また、取引所等が未承認のトランザクションをInputとして使ってきた場合でも、送金手数料が大きければ、その送金の元となるトランザクションを含めて一緒にブロックに取り込んでくれる可能性が出てくる。

3.ViaBTCのTransaction Acceleratorを使う

ViaBTCというマイニングプールが、無料で、ViaBTCが掘ったブロックに限り優先的にブロックにトランザクションを取り込んでくれるTransaction Acceleratorを公開している。
こちらより飛べるので、止まってしまったら是非使おう。しかし、1時間に100個のトランザクションしかこのツールは使えないので、他人に先を越されることも多い。
尚、ViaBTCのサービスを利用している場合はそれとは別に特別枠を使用することができる。


4. 送金回数を少なくする、トランザクションのサイズを減らす(必要最小限のinput , outputを使うようにする)

そもそも送金回数を皆で減らせばトランザクションであふれかえることも減る。
サイズを削減すれば他のトランザクションが入るだけでなく、実質的に手数料を上げたのと同じ効果が得られる。(基本的にサイズ毎の手数料が高い順から承認されるので)
Bitcoin CoreやElectrumを利用している場合、コインコントロール機能を用いて必要最小限のinput , outputを使うと良い。また、お釣りのないトランザクションは1つ受取を減らせるので、サイズ削減に役立つ。
(たとえば、未使用の0.1BTCの受取が3個、0.01BTCの受取が11個あったとして、0.21BTCを送る時、0.1BTCの受取2個と0.01BTCの受取1個を使うとinputの数が少なくなるし、逆に0.01BTCの送金をしたいのであれば、0.1BTCの受取1つから0.01BTCと0.09BTCのお釣りのトランザクションを作るよりは0.01BTCの受取1個を使ったほうが無駄が無い。)




（5.あえて二重支払いを行なう）


この手法は、あまり使うべきでないので、出来ればこれは最終手段として使用してほしい。
送金してしまったが手数料が低すぎてなかなか承認されない場合、もう一度同じトランザクションを、今度は手数料を引き上げて発行する。
他のノードはMempool(その時に一時的に記録されてあるトランザクションの置き場所)にあるトランザクションと比較して、二重支払いが認められる場合これを承認しないが、
かなり時間がたってMempoolから消されたトランザクションに関しては、二重支払いとして判定されないので、通ることがある。
また、Bitcoin CoreのユーザーはAbandontransactionコマンドや、”取引の中止”でも似たようなことができるので、上手く活用したい。

そもそもなぜ送金の遅延が発生するのか？

スケーラビリティ問題の歴史と現状

Bitcoin Core派

Bitcoin Unlimited派

しかし、現在、どちらの解決策もとられず、問題はさらに深刻化している。

また、問題解決は遅々として進まず、8月1日よりUASFといって、Segwit支持者はSegwit支持者の独自のブロックチェーンを作るなどという強引な方法で推し進めようとする者もおり、(Core派の一部の過激派)

ますます対立の溝は深まる気配を見せている。