システム奮闘記:その96

コーデック入門



Tweet

(2012年2月9日に掲載)
はじめに

 コーデックとは何なのか。
 簡単にいえば次の事なのだ。

コーデックとは何か?
動画や音声などのアナログのデータをデジタル化するための
ソフトや装置の事なのだ。
今はソフトが主流な上、データの圧縮なども兼ねている。

 コーデックの話を知らないと、動画再生などで混乱を招きます。
 そこで今回は、コーデックの話を書く事にしました。

動画再生とコーデックの問題

 パソコン上で動画再生。  結構厄介だったりする。  うちの会社の商品の扱い方やデモ動画がある。  営業所に配るのだが、隣の部署の部長から  CDに焼いて配ってね!  と言われる。  でも、その動画を再生しようとすると・・・  エラーが出たりするのだ (--;;
WindowsMediaPlayerでのエラー
コーデックを探す様子
そしてエラーが出る
コーデックがないとエラー
開けない動画がある場合、コーデックを探すみたいだが
見つからないようなのでエラー表示が出る。

 動画には色々な形式がある。

 mpeg、avi、WMV、VOBなどなど

 そして拡張子が「mpg」で、mpeg形式の動画データでも

 mpeg1、mpeg2、mpeg4があるのだ!

 動画データの拡張子は同じなので、見た目では判断できないのだ。


 だが、そんな状況でも動画を再生しなければならない。
 そこで無料の動画再生ソフトを探す事にした。
 するとGOMPLAYERというソフトを発見した。

 GOM PLAYER(ゴムプレイヤー)

 それでも・・・

 閲覧できへん動画がある・・・ (--;;

 その後も、色々、探してみるのだが、万能なソフトが見つからない。


 それだけではない。
 仕入先から商品案内のCDが届いたのだ。
 早速、それを開いてみるが・・・

 動画が再生できへん (--;;

 拡張子を見れば、mpeg形式なのだが、どうやらmpeg2みたい。
 仕入先に対して「見れる動画を送ってよ」言いたくなったのだが
実は、仕入先もボヤいていた。

 どのパソコンでも見れるようにして欲しいと外注先に言ったが・・・

 動画の品質にこだわる!!

 という事で、外注先が自己満足の動画を作成したというのだ。


 だが、社内にとどまる範囲なので、まだ良いのだが、
こんな依頼が来ると頭を悩ませる。
 営業マンから・・・

 お客さんの所で動画をCDに焼いてくれ!

 お客さんのパソコン環境がわからない。
 社内にある動画が見れるとは限らない・・・。


 そこで発想の転換を行なった。

 動画変換ソフトを使えばエエかも!


 そこで無償の動画変換ソフトを探す事になった。
 色々試したら、良い物が見つかった。

 Any Video Converterのフリー版だ!

 Any Vide Converterのサイト

 これでWMV形式に変換したら、Windowsのパソコン上なら動画が見れる。

WMVのバージョンについて
WMVにも色々なバージョンがある。
あまり高いバージョンだとWindowsXPパソコンの
WindowsMediaPlayerに対応していないため
閲覧できない物もあるので、WMV9にしておくのが無難なのだ。

 これだと少なくとも、お客さんのパソコンがWindowsであれば
WindowsMediaPlayerで使えば閲覧できる。

 でも・・・

 変換できへん動画がある・・・ (--;;

 だった。

 動画との格闘が続く日々だったのだ。

コーデックを勉強する動機

 2011年、営業所に配布するCD作成が面倒なので youtubeみたいな動画配信サイトのソフトを探していた。  すると・・・  PHPmotionを発見!  そこでPHPmotionのインストールを行なう事にした。  詳細については「システム奮闘記:その95」をご覧下さい。  (オープンソース動画配信ソフト PHPmotion)  PHPmotionのインストールの際に出てきた事は・・・  各種コーデックのインストール  だった。  PHPmotionの導入の際にインストールしたコーデックの一覧。
各種コーデックなどのインストール作業一覧
(1) FAAD2
(2) FAAC
(3) opencore-amr
(4) vo-amrwbenc
(5) GMS
(6) LAME
(7) OpenJPEG
(8) Theora
(9) x264
(10) Xvid
(11) WebM

 さすがに、コーデックから逃げられない。
 まさかコーデックを全く知らないでPHPmotionのインストールネタを
書くわけにいかない。

 まずは、PHPmotionのインストールの際に導入する
コーデックを調べていく事にした。

FAAD2コーデック

 FAAD2コーデックとは何か?  FAAD2のサイトを見てみる事にした。  AudioCoding.com FAAD2/FAAC  すると、こんな説明があった。
サイトの中のFAAD2の説明の一部抜粋
FAAD2 is an open source MPEG-4 and MPEG-2 AAC decoder
オープンソース版のMPEG4とMPEG-2のAACのデーコーダーだというのだ。

 ところで・・・

 AACデコーダーとは何やねん?

 そもそも・・・

 デコーダーとは何やねん?

 最初から、つまづく私。でも、いつもの事なので気にしない。

 AACを調べてみる事にしたら、以下のサイトを発見した。
 AAC:MPEGオーディオ

 MPEG2、MPEG4で使われる音声コーデックの一種のようだが
いまいち、モヤモヤ感が残る。

 そこで次のサイトを見てみる事にした。
 音声ファイルの主な形式と特徴|コーデック・MP3・AAC・Ogg

 MPEG1の音声コーデックは、MP3が使われているというのだ。
 AACは「Advanced Audio Coding」の略で、アップル社の製品の
iTunesやipod、携帯の着うたなどに使われたため、広く認知されたという。

 MP3とAACの違い。

MP3とAACの違いの1つ
MP3 不正コピー防止の対策がない
AAC 不正コピー防止の対策あり

 FAAD2のサイトにも、DRM(Digital Rights Management:デジタル著作権管理)が
ついていると書いてあった。
 DRMについては「システム奮闘記:その94」(著作権入門)をご覧ください。


 さて、FDDA2に話を戻す。
 FDDA2のサイトに書いている特徴を並べてみた。

FDDA2のサイトに書いている特徴
(1) 携帯用
(2) それなりに処理が速い
(3) LC,MAIN,LTP, SBR, PSをサポート
(4) DreaMでDRMをサポート(不正コピー防止)
(5) DBA+をサポート

 (3)について調べてみる事にした。
 槻ノ木隆の「BBっとWORDS」 AACって何
 パイオニア MPEG技術解説

 AACの品質に関する度合を表す用語だという。
 番号ではなく、名称になっているのだ。

AACの品質と圧縮度を表す用語
LC 一番簡単な物
オーディオデータに使われている
MAIN LCにBackward predictionを追加した物
でも、Backward predictionが何かわからない (^^;;
MPEG2、MPEG4の動画に使われている
LTP データ量を増やさずにより品質を上げる物みたい。
SBR MAINにForward predictionを追加した物
でも、Forward predictionが何か、わからない (^^;;
PS 他のサイトを探しても記述がみつからず (--;;

 私には・・・

 難しくて、わからへん・・・(--;;

 なのだ。
 データ圧縮の事を学んでいる人なら当たり前の話なのだが
何せ、かじり始めた私。ましてや事務員の私が・・・

 わからなくて当然なのらー!!

 と、開きなおる (^^)

「事務員なのだ」がネタでなくなってきた
システム奮闘記の連載を重ねていくにつれ
「事務員なのだ」が本音からネタになっていった。
だが、最近、システムを触る機会が減ってきた上
他の分野の勉強が増えたため、技術まで回らなくなってきている。
そのため、本音に戻りつつあるのだ。原点回帰(?)
総務部員なので「事務員」は、ウソではないのだ (^^)

 どうやらAACの中にも種類があるという事がわかったのだ。


 次に、(5)のDBA+について調べてみた。
 DBA+とは「Digital Audio Broadcasting」の略で
デジタルラジオの規格なのだ。
 ふと思った。

 なんでFMラジオやねん?

 デジタルといえばFMラジオが頭に浮かんでしまった。

実際はFMラジオはアナログ放送です
FMラジオはAMラジオと違って音質が良い。
中学の時に「FMはデジタルだから音質が良い」と聞いて
そのまま四半世紀の間、疑う事なく過ごしていました。

でも、今回の事で、FMはデジタルだと書こうとして調べてみたら
実際にはアナログである事がわかりました。大恥かく所だった (^^;;

AMの場合、搬送波に音声波を乗せるため、電波の波の強弱で
音声を判断する。そのため、ノイズの影響を受けやすい。

FMの場合、搬送波の密度を変える(周波数を変化)で
電波の波の強弱(振幅)は一定なので、ノイズの影響を受けても
密度の変化だけを拾い上げたら良いので、ノイズを除去しやすい。
あたかもデジタルみたいに綺麗な音声で放送できるのだ。

 FMラジオがアナログ放送である事がわかって良かった。
 そうでないと、もう少しでデタラメを書く所だった。

 おまけとして、AMとFMの違いを、もう1つ。
 偉そうに「AMはアナログで、FMはデジタル」と知ったかぶりで
書く予定だった話を、修正した物です。

AMとFMの違いについて
AMラジオは中波と呼ばれる周波数帯を使っている。
それなりに広い範囲に電波が飛ぶが、夜になると
中波を反射する電離層が表れるため、より遠くへ電波が飛ぶ。
そのため、海外の中波が入る事がある。
モスクワ放送の日本語版は、ウラジオストクから
720KHzで放送しているのだが、見事に電波が届いているのだ。

ちなみに、1985年、阪神が優勝する試合の実況で
大阪の朝日放送の電波(1008KHz)が北京まで届いていて
北京にいた阪神ファンが「奇跡だ。植草貞夫の実況だ」と喜んで
聞いていた話があるぐらいだ。


ところで、FMは超短波と呼ばれる周波数帯を使っているだけでなく
音質が良く、音楽放送に向いているのだ。
でも、遠くまで電波が届かない難点があり地域限定になってしまう。

 ところでDBA+のデジタルラジオに戻します。
 調べてみると、日本とアメリカ以外の多くの国で採用されている
比較的、新しいデジタルラジオだというのがわかった。
 Wekipedia DBA
 WikiPedia デジタルラジオ

 そして、DBA+が日本に馴染みがないのも納得。

 でも、DBA+で検索していくと、日立など日本のメーカが
欧州でDBA対応のラジオを販売するなど、日本企業は頑張っているのだ。

 インターネットラジオでもDBA+の規格で放送しているかもしれない。


 ここまででわかったのは

 FAAD2が音声デコーダー

 という事だ。

FAACコーデック

 FAACコーデックとは何か?  FAACのサイトを見てみる事にした。  AudioCoding.com FAAD2/FAAC  音声エンコーダー  なのだ。  FAACのサイトに書いている特徴を並べてみた。
FAACのサイトに書いている特徴
(1) 携帯用
(2) それなりに処理が速い
(3) LC,MAIN,LTPをサポート
(4) DreaMでDRMをサポート(不正コピー防止)

 ところで、デコーダーとエンコーダー。
 なんとなく意味はわかるが、頭の整理のため調べてみた。

エンコーダーとは? デコーダーとは?
エンコーダー 「encoder」(符号化)の事だ。
ある情報を一定の規則に基づいて変換する事だ。
音声や動画を作成・圧縮・暗号化するためのソフトなのだ
デコーダー 「decoder」(復元化)なのだ。
符号化(エンコード)したデータを復元する事だ。
音声や動画再生するソフトなのだ

 これを図式化すると、こういう事なのだ。

エンコーダー(符号化)
エンコーダー(encoder)の概略
動画・音声データをコーデックを使って
データ変換(圧縮・暗号化など)を行なう事なのだ。
デコーダー(復元化)
デコーダー(decoder)の概略
圧縮や暗号化されたデータをコーデックを使って
復元して元の動画や音声データにする事。

 これでスッキリした。

 FAAD2で音声データを符号化して、FAACで復元化する。
 その違いである事がわかった。

H.264とMPEG4の関連性

 FAAD2を調べている際に、mpegの規格の話に出くわした。 MPEG-1、MPEG-2、MPEG-4とは、それぞれ異なる規格である事がわかった。  そして、互換性がないため、MPEG-1を再生できる動画ソフトでも MPEG2では再生できないのも納得。  でも、拡張子は「mpg」なので、非常に紛らわしいのだ。    ところで、調べてみると、MPEG-4の説明の所で、 H.264の規格が出てくる。何か関連性がありそうな感じがしてきた。  そこで、一体、どういう関連性なのか見てみた。  富士通研究所 画像圧縮技術 画像圧縮技術  上のサイトを読んでいると、H.264とMPEG-4との関連なのだが、 H.26*系とMPEGは、元々は・・・  別々の標準化団体が策定した規格を  共同で策定する事になった規格  なのだ。  図式化すると以下のようになる。
MPEG-4/H.264 AVCに至るまでの流れ
mpegとH.26*との関連と標準化団体での策定の流れ
別々の標準化団体が合同で策定する流れなのだ。
一度、MPEG-2の時に合体したのだが、分離して
また合体して、今の「MPEG-4/H.264 AVC」という規格に至る。

 MPEG-4/H.264 AVCの凄いのは・・・

 画質が良い上、MPEG-2の2倍以上の圧縮が可能!!

 これだけ見ると、すげー技術と思うのだ。

 でも、すぐに導入というわけにはいかないようだ。
 というのも・・・

 アルゴリズムが複雑!

 なのだ。
 そのため圧縮・復元するには、馬力が必要になる。
 どんなチップを搭載するのかが問題になるというのだ。

 ところで名称を見ると「MPEG-4/H.264 AVC」になっている。

 AVCって、何の略やねん!

 という事で調べてみると「Advanced Video Coding」で
直訳すると「高度な映像符号化」なのだ。

 MPEG-2に比べて2倍以上の圧縮なので、いかに凄いのかを
示したいのかもしれない。


 ふと富士通のサイトを見て、ふと思った。

 ビットレートって何やねん?

 調べてみると以下の表現に使われる。

ビットレート(bit rate)とは
(1) その回線で、1秒間に送信できるデータ量
(2) 1秒間辺りの映像のデータ量
1秒間の映像にどれくらいのデータ量があるのかの値で
映像ビットレートとも言う。

 確かに「bit rate」なので、直訳すると「ビットの割合」や
「ビット速度」になる。
 
 ここでは動画の話なので(2)の「1秒辺りのビットの割合」が当てはまる。
 とすれば、こういう見方ができる。

 高画質だとビットレートの値は高い!

 そして、圧縮率が良い場合は、同じ動画であっても

 ビットレートの値は低くなる!

 のだ。


 ところで圧縮率を高めた時の利点は色々ある。
 特にマラソンなどの中継で、テレビ局まで映像を電波で送信する場合
電波で送信できるデータ量が限られている。
 そこで圧縮率の高い圧縮方式が活躍するのだ。

テレビ中継で高圧縮動画が良い理由
高圧縮動画で送信すると電波の節約や回線占有を防げる
マラソンなど屋外で中継する場合、映像を電波でテレビ局まで送っている。
生放送なので、途切れない映像が求められる上、高品質の動画であれば良いのだが
電波で送信できるデータ量は限られている。

もし、圧縮率の低いMPEG-2の規格で動画を送信すると、
2波に分割して送る事態が発生しても不思議ではない。

だが、圧縮率の高いMPEG-4/H.264 AVCのような規格で送信すると
1波の電波で送信可能になれば、電波帯域の確保のための費用の節約や
電波帯域の資源配分も行なえる。

箱根駅伝の中継の裏には、こういった技術が満載なのだ。
もちろん、富士通研究所のサイトの受け売りです (^^)

 昨年(2010年)、地上デジタルに移行したので技術革新は感じるが、
そうでない限り、テレビの技術が進歩しているとは見た目では感じない。
 でも、実際には、どんどん変化しているのだ。

GSM規格

 GSMとは何なのか?  Global System for Mobile Communication  なのだ。  直訳だと「国際的な携帯の通信システム」となる。  そこで調べてみる事にした。  TDD-TDMA方式で実現されている第二世代携帯電話  なのだ。  でも、「TDD-TDMA」や「第二世代携帯電話」と言われても・・・  全くわからへんのらー!!  調べてみると、欧州で策定されたデジタル携帯の規格で その後、アジアでも広く使われるようになったりして ついには世界規格になったというのだ。  GSMの略は、欧州で策定された時は「Group Special Mobile」だったが 世界的に広がったため、今の略になったのだ。  日本では採用されていない規格のため、「GSM」という言葉や 文字を見る機会は、ほとんどないのだ。  GSMは進歩していて、拡張した規格もあるのだ。
GSM規格の発展
GSM-FR 「GSM Full Rate」(GSM 06.10)なのだ。
GSMデジタル携帯として最初に使われた符号化方式なのだ。
音質は劣るが、符号化のための演算量は少ないため
性能が低い携帯でも搭載可能なのだ。
GSM-EFR 「GSM Enhanced Full Rate」(GSM 06.60)の略だ。
GSM-FRの音質を改善すために開発されたのだ。

 海外の携帯を持つ機会はなさそうなので、これぐらいにします。

opencore-amrコーデック

 早速、どんなコーデックなのかサイトを見てみる。opencore-amr  音声コーデックだという。ここで疑問が出てきた。  PHPmotionで動画サイト構築なのに・・・  なんで音声コーデックのインストールやねん!  と思った。  実は、この時、2つの事を誤解していたのだ。
この時、以下の2つの誤解をしていました
(1) MPEGやAVIの動画ファイルは以下の図のように
動画データ、音声データ、文字データを個々に
1つの箱(コンテナ)に入れている構造になっている。


だが、そんな事を知らず、動画ファイルは、動画部分も
映像部分も文字データ部分も以下の図のように
ごっちゃ混ぜになっていると思っていた。



そのため動画ファイルと、音声ファイル全く別物だと思っていた。
そのため、音声コーデックが必要なのがわからなかった。

コンテナの話は後述しています。
(2) PHPmotionは動画配信サイトなのだが
音声や画像の配信も行なえる。
それが、すっかり抜けていたため、動画配信サイトで
音声コーデックなのかという疑問をもってしまった

 でも、世の中、どう転ぶか、わからない。
 (1)と(2)の誤解のおかげで、動画データの事を調べるキッカケになったのだ。
 (2)が頭の中に入っていたら、音声の再生のためのコーデックだと思って
単なるコーデックの紹介で終わっていたと思う (^^)


 さて、opencore-amrについて調べてみる事にした。

 オープンソース版のAMRのコーデックだというのがわかった。

 Adaptive Multi Rate (適応多重レート)

 の略なのだ。

 と言われても・・・

 だから何やねん。わからへん!

 なのだ。

 そこで踏み込んで調べていく事にした。すると

 第三世代携帯通信(3G)の規格

 だという。


 ARMコーデックにもいくつかの種類がある事を知る。
 通常、「ARM」というと「ARM-NB」の事を指す。

ARMの規格の種類
ARM
(ARM-NB)
音声に特化した圧縮形式だ。
圧縮率は高いのだが、音質は劣る。

サンプリング周波数は8KHz
ARM-WB ARM-NBの音質を改善した規格だ。
「ARM-Wide band」で、広域帯域音声符号方式だ。

サンプリング周波数は16KHzだ。
ARM-WB+ ARM-WBをより発展させた物だ。
音声だけでなく、オーディオといった音楽などの
音声圧縮に使われる規格なのだ。

サンプリング周波数は16/24/32/48KHz (選択可能)なのだ。

 ところで

 サンプリング周波数って何やねん?

 知ったかぶりして、説明を端折りたい所なのだが
メッキが剥がれる方が、格好悪いので、最初から自分で剥すのだ (^^)

 わかりやすい説明があった。
 日経トレンディ サンプリングとビットレート、どう違うの?

 サンプリング周波数とは、音声波形を1秒間に、細切れにする数を意味する。
 サンプリング周波数600Hzといえば、1秒間に600回、細切れにして
個々の時点での音声情報を採取してデジタル情報にしているのだ。


 数値が大きければ、大きいほど、滑らかな曲線に復元しやすく
高周波数帯域の音質が良くなるというのだ。


 一般的に、送信したい音声の周波数の倍の値で、細切れするのだ。
 300Hzの音声なら、1秒間に600回、細切れにするのだ。

 ところで周波数が大きくなればなるほど、細切れにする必要があるのか。
 具体的に図で示してみる事にした。

低い周波数の場合
細切れにしてみる 細切れにした点をつなげあわせた後
細切れにしてみた 各点を結んでみた
左図が音声データを細切れにした物と考える。

そして右図は、細切れにした点を線で結んでみた物だ。
簡易的なのだが復元と同じと見ても問題ない。

ゆるやかな波(低周波数)の場合、大雑把な細切れであっても
かなり正確に復元できるのだ。

 しかし、高い周波数の音で、同じような細切れにしてしまうと
以下のような感じになり復元ができなくなる。

高い周波数の場合
細切れにしてみる 細切れにした点をつなげあわせた後
細切れにしてみる 細切れにした点をつなげてみた場合
左図が音声データを細切れにした物と考える。

そして右図は、細切れにした点を線で結んでみた物だ。
簡易的なのだが復元と同じと見ても問題ない。

激しい波(高周波数)の場合、大雑把な細切れの場合だと
とんでもない形に復元してしまうのだ。
そのため、もっと狭い間隔で細切れが必要になるのだ。

 という事で、音声周波数の帯域が高くなればなるほど
サンプリング周波数(細切れの数)を増やさないといけないのがわかる。

個々サンプリング周波数について
ARM
(ARM-NB)
サンプリング周波数は8KHzだ。
1秒間に8000回、細切れにして、その時点での音声情報を
デジタル情報にしているのだ。
送信する音声の周波数帯域が4000Hzまでというのがわかる。
ARM-WB サンプリング周波数は16KHzだ。
1秒間に16000回、細切れにして、その時点での音声情報を
デジタル情報にしているのだ。
送信する音声の周波数帯域が8000Hzまでというのがわかる。
それにより品質の高い音声で送れるというわけだ。
ARM-WB+ サンプリング周波数は16/24/32/48KHz (選択可能)なのだ。
最大24000Hz帯域という高い周波数帯域の音を送信できるのだ。
そのため音声だけでなく、高い周波数帯域の音が含まれている
クラッシック音楽なども送信できるのだ。

 ところで、ARM(ARM-NB)は電話での音声帯域と、ほぼ同じだ。
 電話の場合、送信できる音声周波数帯域が300〜3400HZだという。

音声周波数帯域の比較
音声周波数帯域の比較
人間が音として拾える範囲は20Hzから20000Hzと言われる。
しかし、電話の場合、300Hzから3400Hzという限定された範囲の
音声しか送信できないのだ。

当時の技術では圧縮技術も何も発達していなかったため
電話での会話で意志疎通できる範囲を選んで
この周波数帯域にしたようだ。
ARM-NBも、それにならっているようだ。
そのため音楽などを流すのには、高い周波数帯域の音が遅れないため
音楽データ送信には不向きなのだ。

ところで音楽CDの音声は様々な楽器の音があったりするため
人間が拾える範囲の音を収録するため、20000Hzを少し越えた範囲まで
音楽データを保管しているのだ。

 音声周波数の話。
 聴覚の話になるのだが、普段、人と話していて相手の人の声が
聞き取れていて会話ができるので、普段は聴覚の話が問題になる事はない。

 だが、我々は他人事にできない聴覚の問題があるのだ。

高齢者は警報器の音が聞き取れない
高齢者が火災警報の音が聞き取れない理由
若年層の人は、広い帯域の音を「音」として認知できる。
だが、年を取るにつれ高い周波数帯域の音を「音」として
認識できなくなるのだ。要するに聞こえなくなるのだ。

老人ホームで火災警報器が鳴ったが逃げ遅れた老人の話がある。
それは若者にとっては「うるさい音」であっても
高齢者にとっては火災報知器の音が聞こえないため
火災が起こっている事が認識できずに逃げ遅れてしまうのだ。

そう考えると、年齢と共に好みの音楽が変わったりするのも
聞き取れる音域が変化し、心地よい音の範囲が変化も考えられるのだ。

 音声周波数の話を語学に応用したのが、フランス人の耳鼻科の
トマティス博士が提唱するトマティス・メソッドだ。
 トマティス英語

言語による周波数帯域の違い
言語による周波数帯域の違い
日本人は英語が苦手な民族と言われたり、英会話学校に何年通っても
なかなか上達しないと嘆く人も多い。

その原因は音声帯域の違いから来るのだ。
日本語の場合、母音主体の低周波数帯域の音声で
英語は子音主体の高周波数帯域の音声だ。

幼児期に子音主体の音声帯域を「音声」として認識する訓練を
受けない日本人の場合、この帯域の「音声」を「雑音」として
脳が無意識のうちに排除してしまうのだ。
そのため、英会話学校に真面目に通っても、外国人の音が
「音声」として拾う事ができないため、英語が聞き取れず、
会話に入っていけず、会話の練習ができないという悲劇を生むのだ。

英語の上達が早い人は、どういうわけか「音声」として拾えるため
慣れれば聞き取りができるため、会話にも参加できるし
使えば使うほど、メキメキ上達するのだ。

私自身、英語の発音がカタカナ発音になっている。
その理由は、英米人の発音を真似しても、子音主体の音が
正確に拾えないため、自分では真似しているつもりでも
カタカナになってしまうのだ。それは人に指摘されて初めてわかる。
完全に高い周波数帯域の音が拾えていない証拠なのだ。


(電話と語学の音声の関連)

トマティスメソッドを使えば、語学と音声の話が見事に説明できる。
だが、だいぶ昔に英語教育の権威の竹蓋幸生先生(当時・千葉大学教授)に
トマティス・メソッドの話を尋ねたら、電話で送信できる音声が
限られているため、高周波数帯域の音声主体の言語では
電話での会話が困難になるのではないかと指摘された。
その後、電話の音声と外国語について踏み込んで調べていないため
いまだ私にはわからないのだ。

 音声周波数帯域で横道にそれてしまったので本題に戻ります。


 同じ規格でも種類によって、送信・復元できる音声帯域が異なるため
音声だけを送信なのか、音楽まで含めるのかで、コーデックの選択が
異なってくるのがわかるし、それにより品質の差が生まれるのだ。

 サンプリング周波数。勉強になった。


 この辺りから、動画ファイルの中身は、単体で存在するではなく
動画データと、音楽データとを合体させた形になっているのではないかと
思い始めた。


LAMEエンコーダー

 LAMEのサイトを見てみる。  LAME Ain't an MP3 Encoder  なのだ。  調べてみると、LGPLのライセンス形態でMP3の音楽データに 変換するためのエンコーダーなのだ。  動画AVIファイルを作成時に、音声部分をMP3にすることが多いみたいだ。  ところで・・・  MP3って何やねん?  調べてみると、次の略だという。  MPEG Audio Layer-3  なのだ。  階層は3段階あって、圧縮率の高さを表すのだ。  MP3は、一番、圧縮率の良い形式だという。  非可逆なので完璧な復元はできないのだが。  MPEG形式の動画データに使うための音声データの形式だという。  だが、問題は、不正複製防止機能が付いていないため 複製し放題なのだという。

JPEG2000

 JPEG2000とは何なのかを調べてみる事にした。 「Joint Photographic Experts Group」の後継版  だという。  要するにJPEG規格の後継版がJPEG2000なのだ。  だが、後継版といっても・・・  jpegとは互換性があらへん!  のだ。  そこで次のサイトを見てみる事にした。JPEGとJPEG2000  画像の圧縮方法から違う!  のだ。
圧縮方法の違い
JPG 離散コサイン変換
8×8ピクセルに分割して圧縮する方法。
そのため格子状のノイズが出てしまう。

不可逆圧縮
JPEG2000 離散ウェーブレット変換
画像全体で圧縮を行なうため
格子状のノイズは出ないのだ。

可逆圧縮不可逆圧縮の選択可能

 画質を向上させたようだ。
 そしてJPEG2000の場合、可逆圧縮が選択できるため
元の画像に復元する事ができるのだ。


 でも、2012年1月現在、あまり普及していないようだ。

 圧縮時間がかかる上、その割には圧縮率が高くないようだ。
 そのため、各ソフト会社やデバイス関連の会社が、JPEG2000の実装を
やりたがらないようだ。

Theoraコーデック

 オープンソース版(修正BSDライセンス)の動画コーデックなのだ。  そして、あまり使われていない上に、VP8がオープンソース化すれば 廃れてしまうという話を見て、あまり重要ではないと思って、 軽く飛ばそうと思った。  だが、後で調べてみると、色々、業界の覇権争いが垣間見えるのだ。  HTML5の標準動画コーデックを巡る議論なのだ。  それについては後述しています。

x264エンコーダー

 x264はMPEG-4/H.264 AVC用のオープンソース版のエンコーダーなのだ。  要するに、動画圧縮するためのソフトなのだ。  それだけだと・・・  へぇ〜。そうなんだ  と軽くうなづいて、終わってしまいそうなのだが 調べてみると、業界の話が見えてくる。  これは後で気づいたのだが、以下の語句が、業界を知る上での 重要語句になる。
業界を知るための重要語句
(1) なぜ、コーデックではなく
エンコーダー(圧縮ソフト)なのか?
(2) なぜ、デコーダー(再生ソフト)でないのか?

 X264について調べていくと、こんな事がわかった。
 MPEG-4/H.264 AVC規格の動画を再生するのに

 特許料が必要なのらー!!

 動画再生のソフトや装置に特許料が必要な事なんて
今まで考えた事すらなかった (^^;;


 ところで、MPEG-4/H.264 AVC関連には、様々な技術が使われており
複数の会社が特許を所有しているのだ。

 MPEG-4/H.264 AVCについては、MPEG-LAという米国の団体が
特許の管理を行なっているのだ。
 H264の特許所有者の一覧(MPEG-LA)


 考えてみれば、圧縮技術を開発するのに膨大な開発費用がかかっている。
 それを回収しないと、企業は成り立たないはずなのだ。

 そのため、他社や他の団体が営利目的で、その技術を利用する時は
特許料を払うのは当然の事になる。


 ふと気づいた。
 色々な動画形式を網羅した無料の動画再生ソフトが
なかなか見つけられない理由なのだ。

 特許料を払いながら無料ソフトを配布する人はいない!

 というわけだ。納得したのだった (^^)

Xdiv コーデック

 オープンソース版のコーデックだ。  MPEG-4(MPEG-4/H.264 AVC)の再生ができるのだ。  元々は、DivXというソフトだったとい。  DivXNetworks社が始めたOpenDivXなのだが 商用に方向展開したため、それに反発したDivXのプログラマーが  DとVを引っ繰り返した「Xdiv」で  オープンソースとして開発を続けているというのだ。  ところで「MPEG-4/H.264 AVC」といえば、MPEG-LAが 特許管理をしている上、特許料がかかるはず。  特許料を払いながら、無償で公開しているという 太っ腹な事をしているのだろうか?  調べてみると、Xdviは特許のライセンスを受けていないというのだ。  これって・・・  特許侵害やん!!  と思った。  でも、法的問題の回避は行なっているという。  アメリカでは問題回避のため、ソースコードの配布のみにしている。  実際にXvid.orgのサイトを見ても、バイナリーでは配布されていない。
アメリカではソースコード公開は
特許侵害に当たらないようだ
最初、Xvidの説明で、wikipediaなどを見ると、特許侵害の回避のため
ソースコードの配布だけにしているという文章を見て
腑に落ちない所があった。

でも、DebianのFAQを見て「なるほど」と思った。
コミュニティディストリビューション特許ポリシー FAQ

米国の場合、ソースコードは言論というと捉え方があるというのだ。
特許の侵害ではなく、言論活動の一環で、言論の自由という論理だ。

1990年代、暗号技術で米国が輸出規制を行なっていた。
公開鍵暗号のPGPを合法的に海外に持ち出す方法として、
暗号ソフトのソースコードを紙に印刷して「出版」という形で
国外に送ったという実話がある。

 日本の特許法68条で「業として特許発明を実施する権利を専有する」なので
私的使用だと何ら問題は発生しない。

 でも、パッケージソフトに、Xvidを使って販売すると
特許侵害になる。もちろん、GPLで公開しているため
商用ソフトとして販売する企業はないと思うが・・・。

 もし、企業が自社で動画閲覧用にXvidを使う場合は
どうなるのだろうか?
 そしてアメリカや他国のサイトで、特許侵害のバイナリ配布を
ダウンロードした場合、法的にはどうなるのだろうか?

 そんな事を考えると・・・

 安易なフリーソフトのインストールはマズいかも (--;;

 以前から、ウイルス混入の問題や、著作権違法のソフトの問題は
認識していたのだが、今回、特許侵害の問題がある事に気づいた。


 企業で無料ソフトやフリーソフトを禁じている所があるが
ウイルス問題だけでなく、法的問題の回避もあるのだなぁと
改めて実感した。

動画ファイルの仕組み コンテナフォーマット

 WebMの話に入る前に、動画や音声コーデックなどを 見ていく中で、ある事に気づいた事を書く事にします。  今まで動画ファイルといえば、こんな形式だと思っていた。
今まで私が思っていた動画ファイルの構造
動画ファイルの内部構造はこうだと思っていた。
ひとつの動画ファイルの中に、動画も音声も文字も
一緒になっていると思っていた。

 だが、もしかして以下のように、個々に独立した物が
ひとつのパッケージとして存在しているのではないかと思い始めた。

実は、こういう形ではないかと思い始めた
動画ファイルの構造は、個々のデータが独立した形で存在している
もしかしたら個々のデータは独立していて
パッケージでひとまとめになっていると思い始めた。

 そこで調べてみる事にしたら、案の定、そうだった。

動画ファイルの構造
動画ファイルの構造
動画ファイルはコンテナという箱になっていて
その箱の中に、動画データ、音声データ、文字データを
搭載する形になっている。

 そして・・・

 動画ファイルの拡張子はコンテナを表す!

 事を初めて知った。

 ところで・・・

 どうしてコンテナにするの?

 そんな疑問が残ったままだ。
 コンテナの役目を調べてみる事にした。

コンテナの役目
(1) 個々のデータを同じコンテナに格納する事で
再生時に同期をとりやすくして、音ズレなどをなくす
(2) 個々のデータのままコンテナに格納する事で
取り出しを簡単にしたり、動画だけ、音声だけの格納でも
使えるようにする。

 (1)がどうもピンとこない。
 特に、コンテナ自体が圧縮するなどはないのだ。

 そしてコンテナの中に入れられる動画データの種類は
複数の場合が多い。音声のデータも複数の種類が入れられる。
 そのため、同じコンテナでも組み合わせによって
何種類ものコーデックが必要になったりする。

 AVIコンテナを取り上げてみる。

AVIに搭載可能なデータ形式
動画
MPEG-1
MPEG-2
MPEG-4
MS-MPEG4
WMV7/WMV8/WMV9
DV
Flash Video
Motion JPEG
Lossless JPEG
H.264
H.263/H.263+
H.26
FFV1
Theora
On2 VP3
On2 VP4
On2 VP5
On2 VP6
On2 VP7
VP8
VC-1

(その他、色々)
音声
リニアPCM
ADPCM
MP3 (0x0055)
AC-3 (0x0092)
AAC
HE-AAC
FLAC
Windows Media Audio

(その他、色々)

 こんなに多種類の動画データと音声データを
AVIコンテナは格納できるのだ。
 なので下図のような多種多様な組み合わせが可能になるのだ。

同じコンテナでも動画や音声データは
多種多様な組み合わせが可能
(AVIを例にしてみる)
同じコンテナでも動画や音声データは多種多様な組み合わせが可能
AVI動画ファイル。拡張子では「avi」なので同じように見えるが
コンテナの中に格納されている動画データ、音声データは多種多様で
上図のような組み合わせが可能になる。

 拡張子は同じでも、中身が異なる事態が発生する。
 そのため同じ動画再生ソフトを使っても以下の事態が発生する。

同じ動画再生ソフトを使っても
再生可能な場合と不可能な場合が発生する
コンテナは同じでも動画や音声の中身は異なるため、同じ動画再生ソフトを使っても再生可能な場合と不可能な場合が発生する
動画再生ソフトで、動画データ、音声データに対して
コーデックの対応の有無で、再生可能かどうかが決まる。

 これで以前からの謎が解けた。

 以前、同じAVIファイルでも再生可能な動画と再生不可能な動画に
直面した際、何が違うのか、わからないため、AVIにバージョンの違いや
規格の違いがあると思っていた。
 だが、今回の事で・・・

 AVIファイルでも動画や音声のデータ形式が異なる

 を知ったので、動画再生ソフトがコーデックの対応の有無で
再生できるAVIファイルと、再生できないAVIファイルがある事がわかった。

 動画ファイルの拡張子は、あくまでもコンテナの種類なので
ファイルの拡張子だけ、再生可能かどうかは判断できないのだ。


 そして、どんなコンテナがあるのか調べてみる。
 すると、色々なコンテナがある事を知った。

コンテナの種類
AVI Audio Video Interleaveの略
Windows3.1の時、動画コンテナとして
マイクロソフトが開発したのだ
FLV AdobeFlashで使われる。
H.263、H264などが格納可能だ。
Youtube、ニコニコ動画で使われているし
PHPmotionで動画サイト構築でも使われる。
Matroska WebMで使われるコンテナだ
Ogg Theora動画データに使われる
WMV WindowsMediaPlayerで再生できる
3GPP W-CDMAの携帯で使われている
MOV Apple社のQuickTimeで使われている

 ところで、動画コーデックの話を調べている際、
コンテナの種類と動画データの種類とを混同してしまう事が
何度もあった。なぜ、混同してしまうのか。

 それが起こる理由が以下のサイトを見てわかった。
 図書館員のコンピュータ基礎講座:動画データ

 つまり、こういう事なのだ。

コンテナ名と動画形式の種類
動画ファイルを見る場合、コンテナ名と動画形式の名前が一致する場合と一致しない場合がある
コンテナ名と動画形式名が一致する場合がある。WMVが良い例だ。
そのためコンテナの話を知らない時に、動画の話を見ると
WMVで動画ファイルの形式と思い込んでしまう。

そしてAVIも動画ファイル形式と思い込んでしまうため
同じ動画再生ソフトでも再生できる場合と、できない場合が発生すると
バージョンの違いなどではないかと混乱をしていまう。

そして、AVIコンテナに格納できる動画データの形式が
色々ある事を知ると混乱してしまう。

 これで動画ファイルの仕組みがわかったのだ (^^)

フレームレート

 フレームレート。カタカナだと・・・  意味がわからへん!!  迷惑な話だ。  そして、どういう綴りか想像するのだが、カタカナだと 「R」と「L」の区別がわからないだけに「フレーム」を  Flameで調べると混乱したのらー!! (--;;  日本人に「R」と「L」の区別なんてわかるかい!!  私は「右」(right)も「光」(light)も「書く」(write)も  「ライト」と発音するぞ!!  なのだ。  聞き取りで区別できないのだから、練習しろと言われても 違いがわからないから、発音なんてできるわけないのだ (^^)  カタカナをやめて訳して欲しいと思う。  なんとか「Frame rate」だというのがわかった。  1秒間のコマ送りの数  という意味だ。拍子抜けだった。  カタカナにすると、意味がわからなくなる。  テレビの場合、コマ送りは1秒間に24枚なのだ。  アニメのセル画で、パラパラめくると、いかにも動いて見える。  動画でも、コマ送りの回数の設定ができるのだ。
「R」と「L」の違いの余談
多くの日本人は区別ができない。
でも、大抵は通じるので、あまり問題にする事はないのだが
厄介なのでスペインやイタリアのラテン系だ。
彼らは、相当、気にする。

以前、イタリア人と話していて「R」と「L」の違いで
「発音がおかしい、練習だ」と言われて、練習させられた。
英語圏でないイタリア人に指摘された事に対して
「イタリア人に、とやかく言われる筋合はない!」
と思ったのだが、後で知った話、彼らは鮮明に違いがわかるため
目くじらを立てる事があるのだ。

反対に、オーストラリア人は英語圏なのだが
明確に区別ができないらしく、気にしない。
そのため「R」と「L」の発音ができなくても
目くじらを立てないのだ。


WebM規格

 WebMとは、オープンソース版のWeb向けのメディアデータの規格で googleが推進しているのだ。  そして核になるのが次の3つのコーデックとコンテナだ。
WebMの3つの核
VP8 動画データのコーデック
元々は、On2が開発した物でGoogleが買収
そしてBSDライセンスにした物だ。
Vorbis 音声・音楽データのコーデック
非営利団体のXiph.orgが開発した物なのだ。
もちろん、オープンソースなのだ。
Matroska WebMで使われるコンテナ。
名前がマトリョーシカなので連想しやすいのだ

 全てソースコードを公開している上、誰でも自由に使えるのだ。
 

真空波動研:コーデックを調べる方法

 ところで動画ファイルの拡張子を見ただけでは コンテナの種類しかわからない。  そのため、何の動画データや音声データがが格納されているのか 拡張子からでは判断できないのだ。  コンテナの中には、何の形式の動画データや 音声データが格納されているのか調べたいと思った時、 便利なソフトを発見したのだった。  黒羽製作所が頒布している真空波動研というソフトだ。  早速、ダウンロードしてみる。
真空波動研を起動
真空波動研を起動の様子
WindowsMediaPlayerと連動している動画再生ソフトだ。
コーデック検出でも使える優れ物だ。

 コーデックを知るには、まずは該当の動画ファイルを開く。

動画ファイルを開く作業
真空波動研で動画ファイルを開く様子
「ファイル」→「開く」で動画ファイルを開く。

 もし、該当のファイルがWindowsMediaPlayerで
再生できない形式の場合、以下のようなエラーが出る。

エラー画面
エラー画面
このエラーが出ても気にしない。
目的はコーデックの検出であって動画再生でないからだ。

 そして動画コンテナに格納されている動画データと
音声データのコーデックの検出を行なう。

コーデックの検出方法
コーデックの検出方法
「表示」→「詳細のコピー」を行なう。

 これでコーデックの検出が完了。
 検出した内容のデータがクリップボードに移動するので
検出した中身を見るには、メモ帳が便利なのだ。

メモ帳を開いて貼り付け
メモ帳を開いて貼り付け

 すると、以下のように検出したコーデックが見れるのだ。

検出したコーデックの内容
[movie.mpg]
352x288 MPEG1 4:3 625line CCIR601 25.00fps 1130.80kb/s CBR
MPEG1-LayerII 44.10kHz 224.00kb/s CBR Stereo
[RIFF(VideoCD)] 00:19:56.093 (1196.093sec) / 208,025,036Bytes

movie.mpg / DLL 120101 Unicode
MPEG1形式で音声はMP3というのがわかる。
桃色の「RIFF(VideoCD)」となっているが
CD形式のファイルという。

他にも、コマ送りが25枚などの情報もわかる。


 ところでPHPmotionに掲載する際、動画ファイルは
FLV形式に変換される。
 PHPmotionの話については「システム奮闘記:その95」
(PHPmotionで動画サイトを構築)をご覧ください。

 でも、FLVコンテナの中身は、色々な組み合せが可能だ。

 そこで、PHPmotionでFLV形式に変換した場合
どんな動画データ、音声データになっているのか
真空波動研を使って見てみる事にした。

PHPmorionで変換された動画ファイルの中身
[KoOW3kCowyARpUzyQeqq.flv]
560x420 Sorenson H.263 30.00fps 559.80kb/s
MPEG1-LayerIII 44.10kHz 64.00kb/s CBR JointStereo/MS
[FlashVideo] 00:00:30.030 (30.030sec) / 2,372,466Bytes

KoOW3kCowyARpUzyQeqq.flv / DLL 120101 Unicode
動画データはH263だとわかる。
音声データはMP3を使っている。
コンテナは「FLASH Video」なのがわかる。

 このソフトがあれば、コーデックの検出が行なえるので
AVIコンテナのように、何種類の動画や音声データを格納できる場合
どの動画再生ソフトが使えるのか、どの動画変換ソフトが使えるのかを
知るためには、便利なソフトだと思った。


動画変換ソフトで動画ファイルの仕組みを見る

 動画ファイルは、コンテナという箱の中に、動画データと 音声データが格納されている事を知った。  そこで何気なく動画変換ソフトのAny Video Converterを使うと コンテナの中の動画と音声データの組み合せが選択できると思った。  Any Vide Converterのサイト  そこでソフトを動かしてみる事にした。
Any Video Converterの画面
Any Video Converterの画面
上図の囲んだ部分の拡大図
AVIファイルに変換する時のパラメーター操作部分
AVIファイルへ変換する時の、値の選択画面だ
動画ファイルの事を知る前は、ここを無視していたのだが
勉強後に見ると、実は重要な選択箇所だというのがわかる。

 実際に、AVIに変換する場合、動画データは何にするのか
選択肢を見てみた。

AVIファイルに変換する場合の動画データの選択肢
Any video converter:AVIファイルに変換する場合の動画データの選択肢
13種類の動画データを選択できるのだ。
そのため、ここの選択を誤ると、ある再生ソフトでは再生可能で
あるソフトではコーデックがないため再生不可能になったりする。

それ以外にも縦・横の大きさ、フレームレート(1秒辺りのコマ送り)を
選択できるのだ。

 次に音声データの選択肢を見てみる。

AVIファイルに変換する場合の音声データの選択肢
Any video converter:AVIファイルに変換する場合の音声データの選択肢
6種類の動画データを選択できるのだ。
そのため、ここの選択を誤ると、ある再生ソフトでは再生可能で
あるソフトではコーデックがないため再生不可能になったりする。

それ以外にもビットレートやサンプルレート
(音声周波数の範囲)を選択する事ができる。

 動画ファイルの仕組みを知ると、色々、設定ができる。
 今後は、最適な動画変換ができると思った。


HTML5策定を巡っての動画規格戦争

 動画や音声などの規格だが、どれを標準にするかで 激しい戦争が起こるのだ。  技術開発した企業としては、多額の投資をして開発し 特許まで獲得した物を採用してもらわないと 利益にならない上、投資が回収できなかったりするのだ。

TheoraとH264の動画戦争

 HTML5以前は、ブラウザで動画を閲覧する際には プラグインが必要だった。  だが、HTML5からはプラグインなしで<video>タグを使って 動画を設定できるようにする話が出ていた。  その標準動画コーデックの候補に「Ogg Theora」が挙がっていた。  無償な上、自由に使えて、しかも特許の問題も少ないから これが最適ではないかと言われていた。  だが・・・  Apple社、ノキア社、Adobe社が  TheoraをHTML5の動画標準コーデックに反対した  のだ。  Apple社、Nokia社はMPEG-4/H.264の特許を持っているのだ。  なので、彼らは自分達の特許が生かせる動画を標準にしたかったのだ。  Adobeは、ブラウザで動画を動かす際のプラグインを提供している。  FLASH不要になるのは、具合が悪い。  それに対抗したのがMozillaやOperaなどのブラウザ陣営だった。  彼らはH264を反対し、Thoeraにするよう求めた。  図式化するとこんな感じになった。
HTML5での標準動画を巡る争いの構図
H264とTheoraの対決
HTML5での標準動画を巡る争いの構図
それぞれ表向きの理由はある。そして、本音がある。
この争いの場合、本音が見えやすい。

己の利益のためなら呉越同舟、合従連衡が当たり前の世界だけに
この構図は永遠の物ではない。

ここでは仲良くTheoraに反対しているApple社とAdobe社が
その後、FLASHを巡って、利害の対立のため争ったりする。

そして、この時、NokiaはDRMが未サポートで著作権保護が
できないため、反対しているのだが、その後、中国向けの音楽配信で
DRMを外した音楽データで配信しているのだ。
日経ITpro Nokia、中国向け「Comes With Music」を開始、DRMフリーで提供

それぞれの行動や主張は二転三転しているのだが
己の利益のためなら矛盾は気にしない。本能丸出しのようだが
これが本来の企業活動の姿だと思う。
多くの日本人は、国家や企業に「友情」や「信念」を求めたがるが
それは幻想である事に気づく必要がある。

 そして結果は痛み分けで、どちらも標準動画にならなかった。

サブマリン特許(潜水艦特許)とは
Apple社がTheora導入に反対していた理由の1つがサブマリン特許問題だ。

アメリカの特許制度の問題点を悪用した物だ。
1995年以前は、特許審査期間関係なく、特許成立後17年間
特許権が有効という制度だった。

そのため、その技術が特許出願中かどうかわからないまま
色々な企業が、その技術を使って色々製品化していく。
出願した人は、技術が普及するまでの間は、特許出願しながらも
修正や追加と称して、できるかぎり審査を遅らせて、
技術が普及した後で特許を成立させて、特許権の侵害を訴えて
莫大な利益を得るやり方だ。

そして先発明主義なので、たとえ、出願が早くても
先に発明した事が証明されると、先に発明した方に権利が与えられる。
先発明主義で、日本企業が悩まされていたようだ。
日本企業がアメリカで特許出願して、技術を普及させた後
別の企業が「俺が先に発明した」と言いがかりをつけて
アメリカのお得意の陪審員を丸め込んだ裁判に持ち込み
日本企業は裁判で負けて泣き寝入りする事態が起こっていた。

さすがに各国から文句を言われて1995年に改正し
特許権は特許出願から20年有効という事になった。

そしてオバマ政権が2011年、特許制度の改正を行なった。
先発明主義から先願主義への大改正になった。

 この動画戦争は、これで終わりではなかったのだ。

 この時、Theoraに、あまり乗り気ではなかったGoogleが
再燃させたのだった。
 それについては後述しています。

YoutubeはTheora導入に難色を示していた
Googleの傘下にあるYoutubeはTheora導入に対して
難色を示していた。動画の圧縮が良くないという理由だった。
そのため商用のH264をサポートを続けていたのだ。
オープンな環境を呼びかけながら、クローズな物を使う。
己の利益のためから、形式に、こだわらないのがアメリカらしい。

だが、Theoraが圧縮が良くないというのに疑問の声もある。
そのため、Youtubeが採用しなかった本音の部分は
別の所にあると思われるのだが、探してみたのだが
全く見当がつかない。

 HTML5での標準動画形式が決まらないまま、2012年2月4日現在
Firefox、Opera、ChromeではThoeraの動画の再生が
可能になっています。

VP8とH264の動画戦争

 Googleが発表したWebM規格。  無償で動画規格のVP8を公開するのだから、太っ腹だ。  しかも、かなりの支持があるというのだ。  グーグルによるVP8のオープンソース化、アドビがFlashでサポート表明! モジラ、オペラもサポートへ  だが、これがHTML5策定での  標準動画を巡る争いの再燃!  をもたらすのだった。  そうなると、MPEG-4/H.264 AVCの特許を持っている企業は 黙ってはいられない。  多額の投資をして開発した物が無償の規格の登場で追いやられては たまったものではないのは想像できる。  Googleはケンカを売るやり方が始まった。  2011年1月12日のITmediaニュースの記事。  Google、ChromeブラウザでのH.264サポート終了へ  googleが商用のH.264をサポートしないぞという宣言なのだ。  こんな意図があるのが、すぐに読み取れる。
Googleの意図
(1) 競合する物をサポートする気はない。
(2) H.264の再生をChromeに組み込むのに特許料がかかる。
しかも競合なので、余計に払いたくない。

 そしてGoogleの傘下にあるYoutubeでも、こんな発表があった。

 2011年4月11日のITmediaエンタープライズの記事。
 YouTube、全動画をWebM形式に変換すると発表

 膨大な利用者を抱えるyoutubeで、WebMを導入すれば
WebMが広がる事が考えられるからだ。

Theoraの時とは異なるGoogleの態度
YoutubeはTheoraの採用について消極的だった。
圧縮面で問題があるという事で採用していなかった。
GoogleがOn2社を買収してVP8をオープンソース化したため
独自の技術の採用をしたのだった。

youtubeがTheoraに対して難色を示していた理由は
建前上、圧縮が良くないだった。
本音の部分を調べてみたのだが、推測すら見つけられなかった。


 だが、H.264側は黙っているわけではない。

 ITmediaニュース 2010年5月24日
 Googleの「WebM」に特許問題か MPEG LAが特許料要求の可能性


 この記事を見たら、Googleは間抜けだなぁと思いがちなのだが
精鋭を抱えるgoogleが、そんな稚拙な事はしない。

 次の記事を見たら、googleのやり方の巧妙さに驚く。

 日経エレクトロニクスの記事  (2011/2/18)
 Googleの前に立ちはだかる特許の壁

 この中でGoogleがVP8に以下のようなライセンス条項を
設けているというのだ。

VP8のライセンス条項
VP8が特許を侵害しているという訴訟を起こしたら
VP8の利用に必要な特許の使用権を剥奪する

 要するに・・・

 特許侵害を訴えるのであれば

 WebMを視聴できる装置の販売はできんぞ!

 なのだ。

 もし、MPEG-4/H.264の特許の大半を欧米企業が
持っているのであれば、どんどんケンカをやってくれと思う。

 だが、MPEG-4/H.264の特許の多くは、日本と韓国のメーカが持っている。
 日本企業が不利益を被るだけに、日本人としてはgoogleが
無償でWebMを公開する事を手放しで喜べないのだ。


 ところで、Theoraの時と違う動きが色々見られる。
 構図としたら、以下のようになっている。

HTML5を巡るVP8とH264の争いの構図
HTML5を巡るVP8とH264の争いの構図
Apple社はVP8に反対の立場だ。H264の特許を持っているからだ。

だが、Thoeraに反対していたAdobe社がVP8をサポートしている上
積極的に支援している。Googleに付いた方が賢いと考えたのだろう。

そしてMicrosoftは、Theoraには反対だったのだが
IE9はVP8をサポートすると静かに表明。
あまり積極的な様子でない事から、静観しながら
どっちに転んでも大丈夫なように保険をかけている。

 合従連衡、呉越同舟。
 利害関係が絡むと、昨日の友は今日の敵。逆もあり。

 Webなどの記事を参考にしているため、深い部分での本音や
思惑まではわからないが、業界の利害関係を垣間見た気がした。


 現在の所、HTML5での標準動画は決まっていないのだが
各ブラウザが独自で動画をサポートしているのだ。

ブラウザと動画のサポートについて
Theora H.264 WebM
Chrome ×
FireFox ×
Safari × ×
IE9 ×

 それぞれの思惑などがあるのだが・・・

 一番困るのは、一般の利用者!

 だという事を認識して欲しいと思う。


最後に  今回の動画ファイルの仕組みやコーデックの勉強で知った事を まとめてみました。
動画ファイルのまとめ
(1) 拡張子はコンテナを表す
(2) コンテナの中に動画データ、音声データを格納可能
個々に独立しているので、取り出しが可能だ
(3) コーデックは圧縮・復元方法の装置(ソフト)
(4) 特許がからんだコーデックもあるため無料ソフトに注意。
特許料を払いながら無料で再生ソフトを配る太っ腹な人はいない。
そのため、いかなる動画でも再生可能な無償ソフトはない。
特許法の勉強が必要になってくるかもしれない。
(5) 標準動画を巡る覇権争いが絶えない

 動画技術よりも覇権争いに興味を持ってしまった。
 各社の思惑、腹の中が見たくて仕方なくなったのらー (^^)

 もっと時間をかけて調べたら、面白い事がわかったかもしれませんが
そこまで踏み込んで調べるだけの知識や情報収集能力がなかったので
今回は、この辺りでとどめておきます。


次章:「IT担当者のための経営戦略入門」を読む
前章:「PHPmotionで動画配信サイト構築」を読む
目次:システム奮闘記に戻る

Tweet