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

音声コーデック

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

音声コーデックは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にしとくと良い

動画の形式について 第一章 (基礎知識編)

動画の形式について

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

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

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

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

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

MP4？AVI？それともWebM？

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

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

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

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

この章のまとめ

コンテナフォーマットが箱と名札みたいなもの(MP4,AVI,WebMなど)
箱がないと動画コーデックと音声コーデックやその他を一緒に纏められない。
音声コーデックや動画コーデックはその箱に入った中身
MP3,AAC,Vorbis,Opusが音声コーデック
H.264やVP9が動画コーデック

ビットコインの送金遅延問題(スケーラビリティ問題)について 後編(個人での防衛策)

歴史的背景等は前編をお読みください。

個人で送金遅延による被害を最小限に抑える方法は何があるだろうか？

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の送金遅延が問題となっている。

ここでは、その送金遅延がなぜ発生するのかと対策法について考える。

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

そもそも前提として、ビットコインは、10分に1回ブロックが生成されるように調整されている。
そして、1ブロックあたり1MBまでしか取引を入れられない。

単純に考えると、10分に1MBまでしか取引をさばけないということである。
昔はこれで十分さばけたが(そもそもブロックサイズが750kBだった時代もあるし、もっと昔はさらに小さかった)
今はビットコインが20万以上になるなど、注目を浴びた分、送金の需要が大きく増え、送金がさばききれないという事態が発生してしまった。
この問題を、スケーラビリティ問題と言うこともある。
ある程度知ってる人はこの言葉のほうが聞いたことがあるかもしれない。
この問題、トランザクションが大きくあふれると分裂するとかいう騒ぎになるが、あふれかえらなくなると今度は騒ぎが沈静化するという特徴がある。

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

実はこの問題、1年ほど前にも言われていて、当時はBitcoin Classic VS Bitcoin Coreの構図になった。
その時は結局、分裂せずにBitcoin Core派が勝利(?)したのだが、ここに来て再びスケーラビリティ問題が騒がれるようになった。


さて、それでは、今回の構図について見ていこう。
今回の構図は、Bitcoin Core派 VS Bitcoin Unlimited派 である。(実際には、それ以外の方法で問題解決をしようとしている人もいるのだが、割愛)

Bitcoin Core派

Bitcoin Core派は元々Bitcoinの開発をしている開発者等が主体となっている。
Segwitを導入することで問題の解決を図ろうとしている。Segwitとは、Segregate Witnessの略で、日本語にすると、署名分離という意味である。
このSegwitでは、ブロックサイズは1MBとしつつ、どの部分をカウントして1MBとするかが変わるのである。
現バージョンは、1MBの中に、トランザクションの電子署名の情報を含めて1MBとするのだが、
このSegwitでは、1MBの中に、トランザクションの電子署名の情報を除いて1MBとするのである。
そして、署名を置く領域を別に作り、この1MBのトランザクションの領域＋その他の領域が合計4MBになるようにするのが今回の提案。
これにより、従来に比べ1ブロックに2倍程度のトランザクションを含めることができるようになるという話である。
また、トランザクション展性問題も、Segwitにより解決する。そして、Lightning NetworkやAtomic Swapが使えるようになることで、さらに使いやすくなる。

Bitcoin Unlimited派

Bitcoin Unlimited派は、中国のASIC開発・マイニングプール運営を行なうBitmain等が主体となっている。
ブロックサイズを大幅に引き上げることで問題の解決を図ろうとしている。
具体的には、まず、採掘者・プールは採掘サイズ、最大許容ブロックサイズ、最大許容ブロックサイズを超過したブロックを承認するのに必要な承認回数の3つをセットする。
自分がブロックを発見したら採掘サイズでセットした値まででブロックを生成する。
また、他人が掘ったブロックが最大許容サイズまでのブロックであれば、その続きから自分は採掘する。
ただし、他のもっと長いブロックチェーンがあり、その承認回数が超過ブロックを承認するのに必要な承認回数を越えていればそのブロックチェーンを採用し、そこから採掘を始めると、こういう仕組みである。
ブロックサイズはマイナー達に決定権があり、最初はブロックサイズがバラバラでもしばらくすると段々ブロックサイズがマイナー達の合意により収束していくというシステムである。
このシステムは、今までと大きく違ってマイナーに決定権があるというかなり革新的なシステムであり、マイニングプールが作ったソフトウェアだということを感じさせる。
しかしこちらは、ソフトウェアのバグにより、何度かネットワークが落ちたりするなど前途多難なようである。
また、BitmainがSegwit導入に否定的なのは、ASICBoostという、一種不正を突いてマイニングを早く行なっているからだという噂も立っている。実際、どういうわけかAntpoolの採掘したブロックにはほとんどトランザクションを取り込まないブロックがあり、疑わしいところがある。

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

そのため、個人では特にほとんどできることもなく、ブロック遅延によりトランザクションがなかなか承認されない、取引手数料を引き上げざるを得ない、最悪の場合数日たっても承認されないということが発生している。

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

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