7 - 06 OGG, OGM, MCF, Matroska

← (P)もくじ(I)(N) →

Ogg, OGM, MCF, Matroska

2003年 2月20日

4種類の新しい動画形式――Ogg(Ogg Container), OGM(Ogg Media), MCF([Multi]Media Container Format), MKV(Matroska Media)――について、 それぞれの背景、良いところや問題点を考えてみる。(注: このメモでいう Ogg は拡張子 .ogg で広く用いられている Ogg Vorbis 圧縮オーディオのことではなく、来るべきマルチメディア・コンテナ「Ogg動画」のことです。) ここで、動画というのは「チャプター、字幕、メニュー」のような映像と音声以外の成分も含めていう。 マトリョーシカの拡張子は正式には決まっていないが、MKA(オーディオ), MKV(ビデオ), MKM(マルチメディア)などが提案されている。 ここでは仮にMKMMKVとしておく。

拡張子 MKA, MKV が第一候補になってますが、 第二候補の XMA, XMV のほうがカッコイイような……。

Ogg動画

公式サイト
http://www.xiph.org/ogg/
ひとことで言えば
高音質の音声コーデック Ogg Vorbis の功績は大きい。Vorbis の過去の栄光だけでは勝負にならないが、現実的に最有力、期待のプロジェクト。
マスコット
おさかな。
開発者
Montyとゆかいな仲間たち(xiph.org

オーディオ圧縮技術 Ogg Vorbis で知られるOgg(オッグ: 「特攻する」という意味のネットゲーム用語より。語原は Orion ship G)シリーズだが、 ゆくゆくはマルチメディア全般でのフリーなオープン規格を確立することを目指している。 ビデオの圧縮形式 Ogg Theora が現在開発中で、これがリリースされると、映像、音声の両方ともパテントフリーな動画を作れるようになる。 音声の可逆圧縮コーデック FLAC(→ 別記事「日本語タグつきFLACリッピング」)も正式に Ogg シリーズに加わった。

Ogg Vorbis が現在のような大ブレイクをとげたのは、もちろん高圧縮で高音質というすぐれた性質のためということが基本にあるけれど、 MP3(MPEG-1レイヤー3)の音声圧縮について開発元のフラウンホーファー社(FhG、研究所の名でIISとも呼ばれる)が特許権を主張した事件と関係が深い(→ mp3というフォーマットと特許・著作権)。 CDを入れ替えることなくCDの内容をHDにまとめておいて好きな順序で手軽にPCで音楽を楽しむ……ということを可能にしたMP3、 このことが特許のからみで気軽にできなくなる可能性がでてきた。 実際、日本でも当時有名だったMP3エンコーダー「午後のこーだ」が公開中止されたりした。 MP3に代わるフリーでオープンなフォーマットを確立しようという機運は、このことで高まった。 (その一方では実験研究名目での「フリーでオープンなMP3」LAME の発展もあった。) ちょうどユニシス社がGIF画像について特許権を主張したせいで、かえってすぐれたフリーの別形式PNGが普及したのとよく似ている (→ PNG普及プロジェクト JAPAN)。

Ogg Theora というビデオ圧縮フォーマットも、DivX5 や XviD のような特許でしばられたMPEG-4ビデオに対するフリーな代替ということが基本にある。 (このうち DivX5 は、ブラウザの Opera 同様、広告が入ることをがまんすれば、ユーザーからみるぶんには「無料」で使える。)

Oggの特徴は、なんといっても「フリー」ということ、そして Ogg Vorbis が「低ビットレートで高音質」ということだろう。 企業が特許を主張している(主張しかねない)ような技術をさけて、すべて基本的に一から自分たちで作っている。 Ogg Vorbis が愛好されるのにも、心理的、思想的な意味での「自由の響き」が好まれている面がある。 (圧縮形式を秘密にしたまま聴き比べを行うブラインド・テストでも、Ogg Vorbis は MP3 より同じサイズで高音質という評価を得ているので、 音の良さは単なる心理的な気分の問題だけではない。→ Discussion of Audio Compression) 128Kbps未満、およそ64Kbps前後までの、比較的低いビットレート(高い圧縮率)のオーディオで、Ogg Vorbis は MP3 より良い結果を出している。 動画の場合、音より映像に重点が置かれることが多く、ビットレート64~128Kbps程度(ステレオ2チャンネルの場合)では、 明らかに音声を Ogg Vorbis にするメリットがある。 (160Kbpsや192Kbpsだと、LAME MP3とあまり差は感じられない。)

Ogg動画の問題点
フリーでないコーデックをどこまでサポートできるか

Ogg Theora のリリースとほぼ同時にスタートすると思われる「Ogg動画」だが、 音声成分に Ogg Vorbis が使えるようになり、映像成分に Ogg Theora を使えるようになるのは当然として、 そのほかの音声圧縮、映像圧縮がどこまでサポートされるのか、というのが第一の関心事項だ。 ビデオ圧縮の XviD はオープンソース開発とはいえ、MPEG-4なので、パテントフリーではない。 MP3音声(MPEG-1レイヤー3)は、もとよりフリーでない。 フリーであることを最重視してきた Ogg の人々が、こうしたフリーでないコーデックをクロスプラットフォームで広くサポートすることについて、 どういう立場をとるのかは微妙だ。ユーザーサイドにはベータ公開されるであろう不安定な Ogg Theora より、 とりあえずビデオ成分には XviD や DivX を使いたいという要望がある。 また、AC3音声をそのまま動画に使いたいという要求も大きいが(現在のOGMでは可能)、AC3もドルビー社の技術で、あまり堂々とサポートできるものとも思えない。 もしOggが、AVIやOGMにかわる汎用性の高い柔軟なマルチメディア・コンテナを目指すとすれば、 こうした理想と現実のギャップがある。

実際に動画を作らず先に枠組みを決めてしまった

例えば30分のクリップで、20MBの音声と200MBの映像を合体させると、 条件にもよるが、現在のAVI動画やOGM動画では、どちらも単純に足し算した20+200=220より1.5MB程度サイズが増える。 映像と音声を合体させる「のりしろ」(構造データ)に1%程度のファイルサイズが消費される。 できることなら少ないほうがいい「のりしろ」だが、OGMではAVIとあまり変わらないか、かえって逆にムダがふえている。 (シークの軽さ、的確さといったパフォーマンスの内容まで考えればAVIとほぼ同じサイズで効果が上なので、単純比較はできないが。) Oggでも、ほぼ同じ量の構造データが消費されると見られる。 MCFやMKVでは構造データが約半分ですむという話が事実とすれば、Oggメディアは設計にムダがあるのではないか、という疑いが生じる (→ MCF specification, introduction)。 仮にそうだとしても、音声圧縮 Ogg Vorbis と同じしくみを使う限りにおいて、 したくても設計の全面変更はできない。実際に音声と映像を合体させてOgg動画を作るテストを行うことなく、 規格の枠組みだけおおまかに決めてしまった。 Oggコンテナの規格は、実際にそれで動画を作ってみての試行錯誤をへて慎重に決定されたものではなく、こなれていない面があるようだ。

Ogg動画の良いところ
主流と考えられ、将来性が高そう

すでに Ogg Vorbis の実績があり、FLAC のチームも加わったため、 将来のフリーな動画形式の「主流」として最も有望だ。 特に権威に弱い日本人は、個人が開発した「わけの分からない」OGMなどより「本家」「標準」「正式」フォーマットと言われるだけで、 こころが動くかもしれない。

MKVや、とくにMCFは、計画倒れに終わる可能性があるが、 Oggはすでに機能しているOGMと統合される見通しで、新フォーマットのなかでは最も現実的なものと考えられる。 新しいものを試したいとは思いつつも「長い物には巻かれよ」「寄らば大樹の陰」といった堅実、安定志向のユーザにとって、 いちばんぶなんな選択だろう。

OGM動画

公式サイト
http://tobias.everwicked.com/oggds.htm
http://tobias.everwicked.com/subtit.htm
http://oggmux.sourceforge.net/
ひとことで言えば
4形式のなかで今実際に使えるのはコレだけ。動画コンテナ新時代を真っ先に実現した最先端の実験的フォーマット。 そのぶん不具合も多い。
マスコット
とくになし。OggDSのアイコンはフィルムの絵。
バージョン情報画面にある「雷神(トール)とへび」は、OggのマスコットでOGM独自ではない。
開発者
核心部は Tobias、GUIはKoepi。VobSub、VitrualDubModを初め開発者の層は広い

OGM動画(Ogg Media; Ogg Movie ともいう)は、すぐれた音声圧縮 Ogg Vorbis を動画のオーディオ部分に使えるように、 Tobiasという個人が私的に開発した。 Oggメディアの枠組みを利用しており、名前も Ogg Media だが正式な Ogg シリーズではなかった。

字幕をソフト的に合成して再生時にオンオフできたり、チャプターをつけたり、複数の音声を切り替えたり……と、 DVDのようなことができるが、こうした字幕やチャプターの具体的仕様も Ogg とは無関係だ。 さらに今では、音声成分に Ogg Vorbis でなく AC3 も使えて、 Oggとは直接的には何の関係もない「Ogg Media」(OGMファイル)さえ作れるようになった。

OGM動画の問題点
規格がハッキリしない

OGMはあくまで個人が趣味で作ったもので、ユニコード対応なども必要にせまられてから後追いで実装しており、 現時点では不備や混乱も少なくない。VobSub で再生する限りにおいて、字幕の国際化はまだまだ遠い。 ロケールが日本になっていると、スペイン語、フランス語、ドイツ語のような比較的メジャーな言語でさえ不具合があり、 日中韓のような多バイト文字のサポートは現状かなり無理がある。 VobSub 自体の不具合もあるが、 規格があいまいだったため、字幕データを格納するSRTが UTF-8でなく Windows CPで広まってしまった。

すでに開発終了?

開発者の Tobias がOggのチームに加わったことで、 現在のOGMは一種、宙ぶらりんの状態にある。 (もちろん Tobias のコードがオープンソースになれば、多かれ少なかれほかの人が開発を続ける可能性が高いが。)

Oggに縛られている

OGMは個人が開発したといっても、まったく自由に作ったわけでなく、予定されていたOgg動画フォーマットの枠内で開発された。 ところが、フォーマット(つまりコンテナ)としてのOggは、実績があったわけでなく、漠然とした予定図があったにすぎない。 実際にやってみて初めて分かる問題点というものもある。 この点が、MCFへのモチベーションとなった。

OGM動画の良いところ
現実に機能してる唯一の形式

Ogg、MCF、MKV(仮)は、現時点では、まだ計画にすぎない。 このメモで取り上げる4形式のなかで、OGM動画だけがきょうからでもすぐ簡単に使えて、 シークの軽さや Ogg Vorbis の音質、ソフト字幕といったメリットを利用することができる。 動画作成でも再生でも、環境は整っており、Windows でも Linux でも使える。

この4つのなかで試してみるとしたらどれがいいですか、と尋ねられれば、2003年2月現在、「OGM」と即答できる。 ほかの3形式は、試したくてもまだリリースされてないからだ。

新しい可能性を示した

音声や字幕の多重化や動画に「メニュー」(チャプター)を埋め込むこと……といった新しい実験的な試みを最初に実装した。 使ってみてあとから不満を言うのは簡単だが、やはり最初に誰かがやってみないことには始まらないのであって、 その功績、存在意義は大きい。

MCF動画

公式サイト
http://mcf.sourceforge.net/
ひとことで言えば
もうだめぽ。
マスコット
MCFのワッペン
MiChiFuちゃん
開発者
Tronic, mf

MCF(Multimedia Container Formats、旧称TMF [The Media Format] )は、Oggコンテナの枠組みに縛られることなく、OGMでの反省もふまえ、 最初から規格をきちんと決めて、オープンソースで開発しようというものだった。 2002年末に分裂するまでは、最も有望な未来の形式だった(2003年はMCFブレイクの年になると予想されていた)。 当時、OGMは画期的であったけれども不満も見え始め、しかもOGMの開発はOggの規格に縛られたうえ個人のクローズド、 本家Ogg動画の開発も先が見えない状態だったからだ。 しかし中心になっていた Tronic があまり開発に時間をさけなくなったうえ、 現実にアクティブにコードを書いている ChristianHJW らと仕様をめぐって意見のおりあいがつかず、 ChristianHJW らはプロジェクトを離脱、独立して別のプロジェクトを始めた。 このため、MCFは事実上、開発中断状態になっている。

MCF動画の問題点
リリースの見込みが立っていない

これは問題点以前の問題だろう。 開発が中止されたわけではないので依然2003年内に何らかのリリースが行われる可能性はあるが、 残念ながら、現状、存在意義があいまいになってしまった。 MKVに対するMCFのメリットは処理が軽いということだが、MKVでも充分に軽いことがハッキリすると、 MCFの存在意義がいっそう希薄になる。逆に万一MKVが重すぎてしょうがないとでもなれば、MCFが見直されるかもしれない。

MKVより拡張性が低い

「バイナリー版XML」EBMLの採用をやめたことで、 ヘッダに含められる情報の種類や量が前もって制限されており、 将来の拡張性は低い。

MCF動画の良いところ
AVI、Oggよりコンパクト

AVIやOggより構造データ量が少ない(半分程度)、とされる。 このほか、MKV形式の長所短所は、EBML関係をのぞいて、すべてそのままMCFにあてはまる。

MKVより軽い

MKVと違い、複雑な処理を必要とするEBMLを使わないので、比較的低い性能の環境でも処理できるはずだ。

マトリョーシカ(マトロスカ)動画(MKV)

公式サイト
http://matroska.org/
http://matroska.sourceforge.net/
ひとことで言えば
血気盛ん。目指すは「なんでも合体」スーパーコンテナ。
マスコット
ロシアの民芸品
開発者
ChristianHJW、robux4 こと Steve Lhomme、ほか多数

マトリョーシカ(Матрёшка)は、MCFプロジェクトから独立したもので、MCFに「バイナリー版XML」であるEBMLのデータ構造を追加したものだ (→ Matroska Sematic)。 MCF同様、汎用コンテナであって、特定の圧縮フォーマットではない。 マトリョーシカはロシアの民芸品の名前で、XML風の入れ子構造を象徴している。 ロシア語の発音をローマ字で書くと Matryoshka/Matrioshka だが、規格の名称はわざと綴りを簡単化して Matroska になっている。 本来の綴りだと英語圏などの一般の人にとって発音しにくく覚えにくいなど、愛称として不適切だからだ。

マトリョーシカの名前の由来でもある「いれこ構造」EBMLは可変データ構造を可能にする柔軟で拡張性の高い方式だが、処理コストも高い。 従来のヘッダでは、決まったオフセットの場所に決まったデータがあって、決まったバイトが一定のフラグになっていた。 そのほうが明らかに処理が単純明快になるが、ヘッダに新しいものを追加する場所がないとか、 例えばあるフィールドが256文字まで、というふうに、いろいろな制約を受けやすい。 制約が少なくなるように余裕をみてぜんぶ1024文字まで入れられるようにしたとすると、今度はムダにヘッダが肥大化したりする。 固定長の害をなくすのに終端文字を決めてポインタを使うという方法があるが、 ポインタでポイントされるデータそのものは基本的にどのフィールドがなに、というように固定される。 そうではなくて、ちょうどHTMLのタグで「知らないタグは無視する」という簡単な規則で後方互換と拡張性を両立できるように、 EBMLでは各フィールドにタグをつけることで、将来いろいろ拡張しても、古いアプリケーションで問題が起きないようにしている。 各アプリケーションは自分が知っている自分が処理したいフィールドだけを処理すればいい。 言い換えるなら、バイナリのデータのなかに、データそのものと、そのデータを識別するメタデータの区別をもうける。 これに反して、在来型のヘッダはいわば「3行目が題名で4行目が作者名です」といった約束事で成り立っていて、 あとから題名のなかにサブタイトルというフィールドを追加したくても、なかなか大変だ。――EBMLの採用は画期的とも言えるが、 あまりに革新的すぎて現実のマシンの処理能力が追いつかなかったり、いろいろな実装が複雑になる可能性は否定できない。

マトリョーシカ(MKV)の良いところ
Ogg/OGMでの反省をふまえている

何事もやってみないと分からない面があるものだが、OGM動画やOgg規格について、実際に使ってみると「こうしたほうが良かったのでないか」 といった感想もでてくる。後発の強みで、MCF/MKVは、OGMで問題になった部分について最初から注意深く対処することができる。 構造データをコンパクトにすること、またそもそも広める前に厳密で詳細な仕様を決めること(Oggでは、この点にぬかりがあったというか、 これから仕様を決めようというその前の段階で、Tobias個人が自分なりの方法でOGMを作ってしまった)。 例えば、OGMの字幕規格SRTはエフェクトにも乏しく使用すべき文字エンコーディングもあいまいだが、 MKVのデフォルト字幕形式USFはSSA/ASS並のエフェクトをソフトサブで実現し、文字もUTF-8と決まっている。

きわめて多くのコーデックをサポート

MPEG系の音声やビデオ(DivX, XviD)のサポートが明言されている。 フリーであることを至上命題とするOggと違い、実用本位、現実主義的に、現に使われているものは、それ自身にパテントがあろうがなかろうがサポートする方針だ。 (Oggもある程度はそうすると思われるが。) 音声としては、MPEGレイヤー3、レイヤー2、PCM, MPC(MusePac), AC3, Vorbis などが使える予定。 映像成分としては、DivX3/4/5, XviD はもとより、MPEG2 をサポートする計画すらある(最近、MPEG2はVirtualDubなどで直接扱えるようになっているので、 この計画は現実味がある)。UCIという中間インターフェイスを使うことで、原理的にあらゆるコーデックによるエンコードデータをマトリョシカで透過的に利用できる状態を目指しているらしい……。実現すればまさに「汎用スーパーコンテナ」だ。 しまいには WMV/WMA のサポートまでするのではないかとさえ思われる。 特許問題に敏感なOggでは二の足を踏みかねないようなことだ。純粋にユーザサイドからみれば、もちろん合体させられるサポート形式が多いほどべんりだが。 以下のような形式が、順次サポートされてゆく予定だ。

強力で徹底的な字幕サポート

ただ文字を出せるだけでなく、文字色、影色、輪郭色、フォントの種類、サイズ、位置……はもとより、カラオケ字幕やスクロールのような特殊効果まであらゆるサポートを考慮したUSF(Universal Subtitle Format)をくみこむことができる。USFは、将来の新しい画面効果用の拡張を自由にできることと後方互換が失われないことを両立するため(字幕に詳しいかたは、SSA形式とASS形式の差を連想してほしい)、XML風の書式になっている。

構造体の未来?EBML

ファイルフォーマット自体、EBMLというXMLのバイナリー版を使っている。 これにより位置合わせのためのパディングがいっさいなくなり、オーバーヘッドの贅肉はぎりぎりまでそぎおたされる。XMLライクなタギングなので、ぎりぎりまで詰めておいても、あとからいくらでも拡張できる。 柔軟性の高い構造、将来の拡張が容易でしかも後方互換に影響しない、サイズの制限がない、 構造データが少なくコンパクトとされるMCFより、さらにコンパクト、といったメリットが予想される。

MKVの問題点
EBMLは現実的に機能するのか

OGM/Oggへの反省をふまえた後発の形式なので、OGMやOggで見つかった問題点はほぼすべて対応済みだが、 MCF/MKVはまったく新しい形式であるだけに、実際に使ってみる段階になるといろいろそれ特有の問題が見えてくると思われる。 とくにEBMLは、 Tronic がプロジェクトの分裂をかけてまで反対した仕様だ(逆に言えば、 ChristianHJW はプロジェクト分裂の代償を支払ってまで、 この仕様にいれこんだ、のだが……)。

具体的に、XML風のつねとして、どこかをちょっと書き換えるだけで、かなり広い範囲をパースしなければならない、という問題がある (「開始タグ」と「閉じるタグ」を入れる場所を見つけるのに、基本的には全体をパースしないといけないので)。 MKVはストリーマブル(途中で切れても切れた前までは再生できる。中間でデータが損傷しても、そこ以降はふたたび正常に再生できる)ということだが、 XML風の複雑なデータ構造のなかでストリーマブルを実現するのは、大変そうだ。すでにテストは成功しているそうだが、 かなりの処理能力を必要とするはずだ。 (もっとも数年後には、そんなこと問題にならないほどマシンの能力も上がるかもしれない。)

まとめ

やはり本命はOGM(Ogg)である。すでに使われている実績がある、というのは大きい。 よほど理不尽なことでもない限り、OGMとOggは平和的に統合される予定なので、現在のOGMと将来の「公式」Oggのどちらが良いか?というのは無意味な問だ。

Oggには「パテントフリーな技術だけを使ってすべてをすすめたい」という基本方針があるはずだから、 それが制約になるかもしれない。

まったく新しいものとして一から作られているMCF/MKVも重要な対抗勢力といえる。 競争は相互にとってプラスになりうる。 MKVはただのチャプターだけでなく、ツリー表示できるような「メニュー」を動画にくっつけられるようにする予定だ。 こうした「新しい良い工夫」は、必ず他方にも良い意味での刺激と影響を与えるだろう。 Ogg側とマトリョーシカ側とに感情的なもつれがあるのも確かだが、 コンテナという同じものを開発していれば、当然どっちがいいかという話はでるし(少なくともユーザサイドから)、 開発者としてもナーバスにならざるを得ない部分があるだろう。 APEとFLACのように、ユーザが自由に選択できる2形式として、OggとMKVが共存する形が実現すれば理想的だ。

いずれにせよ、 AVIは、長期的にはすたれていくだろう。 シークが遅かったりそうでなくてもメニューから好きな場所に直接ジャンプできない、多チャンネルや字幕切り替えが使えない、VBRの音声が正式サポートされていない、ダウンロードが切れて末尾1%が足りないだけで全体が再生できなくなってしまう、 といった多くの不満点は、現在のそしてこれからのユーザの要求を満たさないだろう。 理由はともあれ現在のOGMが広まりつつあるのは事実だし、ということは、AVIよりOGMを使うほうがいいと考えるユーザが増えているのだろうと思う。 といっても、MP3 CBR の音声1チャンネルと映像1チャンネルの2チャンネルを合体させるだけならAVIでも充分であって、 限界をわきまえてその限度内で使うぶんには、AVIにもサポートソフトが多いなどのメリット(消極的な利点だが)がある。

追記

2003年2月24日: [速報] Matroska (.MKV) をサポートした VdubMod、アルファ版限定公開――マトリョーシカの作成は意外に軽快!

OGM系ツールの作者として知られMatroskaチームのメンバーでもある Cyrius は、 最初の MatroskaDub を完成させた。VirtualDubMoD の発展形だ。 仕様書に従った valid な Matroska ファイルを生成すること、読み込むことができる。 現在、Matroska アルファテスト・ティームによってテストが進行中。 詳しくは下のリンク参照。

関連記事

Ogg vs. MK*
OGM関係

更新履歴

2003年2月24日: Matroska形式ファイルの読み込みと出力ができる VirtualDubMod についての速報を追記した。このソフトでは Matroska動画の拡張子を MKV としている。Linux用のソフトも MKVtoolnix という名だ。これにあわせて「MKM(仮)」と書いていたマトリョーシカの拡張子を MKV になおした。

2003年3月21日: MCF動画の問題点「リリースの見込みが立っていない」の項目に、 開発が中止されたわけではないことを付け加えた。 開発チームの mf が、なかばあきらめ気味の調子ながら、I'm more hoping for survival of MCF than for Matroska語ったため。

2003年3月25日: 現在のOGMの問題点のうち、SRTの文字エンコーディング問題をより具体的に記述、詳細説明を含む別記事へのリンクを追加した。 そのほか数か所加筆。

テキスト版省パケ版XML版


Xiph.org vs. Matroska.org ほか、メモ

2003年 2月19日

動画関係のメモ。「最新版」などの言葉はそのメモの日付の時点で。 OGG(xiph)vs. Matroska ネタに興味あるかたは、 OGG, OGM, MCF, Matroskaのほうがもう少しまとまってます。

MCFのマスコット MiChiFu

2003年2月12日

Matroska との分裂以降、影が薄くなってしまったMCFですが、 「MCFのマスコット Michifu」なる絵が掲載されてました。
http://mf.onthanet.com/mcf/michifu_fullsize-wip.png
胸にMCFのロゴをつけてます。

OGMの上を目指すものとして一時期かなり期待を集めた mcf ですが、 開発は中断状態。一方、mcf から独立した matroska(マトリョーシカ)は、かなり勢いがある。

事実関係を簡単にまとめておくと、とりあえずmp3パテント問題にまでさかのぼることができるでしょう。 「特許特許、カネカネうざい。 もっといいものをフリーで自作してやるわい」ということで、Ogg Vorbis が登場。 この Ogg Vorbis という圧縮形式(コーデック)は本当にすばらしいもので、mp3 より小さくて高音質、 しかもフリー、もはや後方互換性以外に mp3 を使う理由はほとんどなくなったのでした。 まさに gif と png の関係。

ogg vorbis の開発集団 xiph.org には、さらなる遠大な計画があって、 「この調子で、マルチメディアの全分野でフリーの総合フォーマットを確立しよう」と。 ビデオ圧縮では、パテントでがちがちに縛られている mp4系(XviD, DivX)に代わるものとして、 on2 が商用に開発してあとから打算あってフリーにした vp3 という Wavelet系コーデックを改良した Ogg Theora というものを作っています。 作っていますが、まだ仕上がりはまったく未知数で、すごいものかもしれないし、だめかもしれない。

ところで ogg はフリー、オープンソースなので個人が拡張してよりべんりなものを作るのも自由。 こうして、本家 xiph.org と無関係に、Tobias というスペイン在住の鬼才が Ogg Vorbis と Windows の動画コーデック(XviD、DivXなど)を合体させる拡張規格を考え、 それを Windows 用の一般のプレーヤーで自在に再生できるようにする DirectShowフィルターを公開。 Ogg の枠組みを基本にしつつ、ソフト字幕やチャプターまで入れられる素晴らしいコンテナを作りました。 音声部分は Ogg Vorbis だけでなく、ドルビーの ac3 も使えます。 通称 Ogg Media、OGM として現在のブレイク。

Xiph の開発者は「勝手に Ogg Media という名称を使われた」ことで文句を言っていた。 フリーのくせに「勝手にOggの名称を使うな」と怒るのは変なようだが、 「Ogg Mediaのファイル(OGM)が再生できない、どうすればいいの」みたいな問い合わせが xiph.org に行ってもサポートのしようがない、 何しろ自分たちが作ったものでないうえソースも非公開なのでサポートしたくてもできない、 しかしOGMがこれだけ広まればOggシリーズと勘違いされて本家に問い合わせが殺到するのはありうべきことで、 「OGMのことは知りません、わたしたちはOGMはサポートしていません」と苦々しく繰り返さざるを得なかった。

この段階で、公式OggともOGMとも別に新しいメディアフォーマットを作ろうという動きがありました。 今で言うMCFなのですが、理由は二点あって、第一にOGMがオープンでなかったため自由に大規模開発ができなかったこと、 第二にOGMは本家OGGの作った「拡張予定図」の範囲内で実装しているのですが、この予定図、実際にやってみるとあれこれ問題があることが判明。 シークが速い、2トラック以上を合体させられるなど従来のAVIよりいいことは確実なのだが、工夫すればもっとよくできる、 特に同じ内容でファイルサイズをもっとコンパクトにできる、OGG規格にはムダ、改良の余地あり。 OGMも個人的に試行錯誤で拡張しているので、あとから振り返ると「こうすれば良かった」みたいなのが出てくる。 例えば字幕のフォーマットを最も原始的なSRT形式と決めてから、あとから字幕の文字をイタリックにしたりが可能なように無理やり拡張したり、 そもそもSRTのテキストをどんな文字コードで書くかもあいまいだったので、日本語だったらSJISなのかUTF-8なのか、どっちにせよ文字化けがある。 ヨーロッパの言語だと問題がないのかというと例えばチェコ語の文字のようにISO-8859-1と異なり Windows Code Page で「勝手に」挿入されているものを使えて、 その結果UTF-8とも互換がとれなくなってしまった。OGMでの実践経験と反省をふまえ、いちからきちんと作り直したほうがいい、 という考えがあった。しかし、このMCFも当時としてはまだ計画予定図にすぎず、例えばカラオケ字幕をメディアフォーマットの規格に含める、 など意欲的ではあるが、今思えば地に足がついていない部分もあった。

当初のMCF規格のうち、字幕の部分はUSFという別規格に分離。XML風に、将来どうにでも拡張できるようにした。 MCF自身も同じXML風の記述法EBMLベースにという動きが主流になっていた。でもXML風だとパースの手間がバカにならず、 あまり複雑にしないほうが良いのでは、という反対意見もあって、おりあいがつかなかった。 そしてマトリョーシカと現MCFとに分裂。マトリョーシカは人形のなかに人形が入っていて……と何重にもなったロシアの民芸品ですが、 この愛称はいかにもXML風へのこだわりを表してます。すでにほぼ完成していた当時のlibmcfをXMLパーサ的な発想で書き直したのがlibmatroskaなので、 matroskaは「MCF++」です。.mc2 という拡張子が提案されたりしたのも、.mcf からの発展だったから。 E=MC^2 にひっかけて芸術は爆発だ、的なパワフルな拡張子。

この分裂の直後、今度はOGMを開発したTobiasが本家OGGのチームに加わり、「これからはOGMはOGGだ」という盛り上がりがあった。 (それまで「OggプロジェクトはOGMとは無関係です!」という摩擦があったので。) これが大ニュースだったこと自体、裏を返せば本家OGGも開発者不足で総合メディアフォーマットの完成があやぶまれていたことがある(実際、 リリースが予定に比べ何度も延期されてきた)。 「できれば個人の独走で拡張した現OGMは白紙に戻しxiph.orgの公式規格として再設計したい」という本音はあるだろう。 けれど、これだけOGMが広まっていると、現実問題、後方互換に配慮せざるをえない。 勝手に拡張するな標準はこっちです、とあとから言っても、コードを書いたハッカーのほうが偉いに決まっているし、 自分たちでは実装できない仕様書だけあとから出してきても分が悪い。OggMuxer にせよ、VirtualDubMod にせよ、 Tobiasのデファクトスタンダードを前提に設計されている、 XviDのビルダーKoepiのような実力者も、xiphがTobiasの実装を後追いするのが当然、 というようなスタンスに見える。 OGMのTobiasが本家Oggに参加せずMCF側についていたら、oggの未来はかなりやばかったし、 現在もTobiasはoggに加わったというニュースはあったものの、 具体的には結果は出ていない。

ogg側は、後方互換をとりつつ拡張性を高めることは可能だろう。 matroska側も、DirectShowフィルターが公開されてしまえば、「新OGM用DSフィルター」のインストールと手間は同じ。 「再生にはこれをインストールしてください」とリンク一本かいて、拡張子.mkvのマトリョーシカ形式動画を配布。 思っているより敷居は低いかもしれない。 「Ogg Vorbis と同じ開発元が作ったファイル形式です」というだけでは、勝負にならない。 動画作成者は何しろ趣味の世界なので、 かなりマイナーでも、かなり手間がかかっても、そっちのほうが良ければすぐ乗り換えるので……。 現時点でのogg側の優位は、(自分たちの作品ではない)OGMがすでに広まっているのでそれに乗っかれる、というだけだ。

XviD XviD (uManiac Stable) 2003年2月13日版

2003年2月14日

配布元:
http://umaniac.leffe.dnsalias.com/stable/stable.html
本家がやたら重いことがあるので日本のvectorにもミラーしときました。本家が落ちてるときとかどうぞ。
http://hp.vector.co.jp/authors/VA022257/ogm/
ちなみに uManiac さんはアイスランドのかたです……

XviD のバイナリーファイルには Koepi、Nic、uManiac などのバージョンがあります。
Koepi のビルドは動作速度や先進性などで人気が高く、本家のソースコードに独自の拡張もついています(Quantization Type の 「新Modulated」が有名)。 この「Koepi独自のオマケ」の部分にもけっこうファンが多いよう……。 OGM関連の最新マルチメディアフォーマットの仕事でも知られます。
Nic のビルドも Koepi と並んで有名で、安定性が高いと言われています(比較的古い環境でもそこそこぶなんに動作するらしい。XviDの再生に使うDirectShowフィルターの作者として有名)。
uManiac は Alpha と Stable の2本だて。もちろん Koepi と Nic のコーデックにも安定系(stable)と開発系(beta)の概念はありますが、 uManiac は以前からこの2種類を別ページで独立に更新してきました。 「このマニアめ」(ユー・マニアック!)というおちゃめなニックからも察しがつくように、 最も先端を突っ走るビルダーで、多いときは一日に4度も5度もアルファ版を更新してきます。 uManiac のアルファ版は最先端志向で、安定性や速度での最適化ではありません。 一方、同じ uManiac の stable 版は、開発系のコードをいっさい使わず、安定系の「ルート」のコードで固めた最も堅実なビルド、 そのかわり Bフレーム、サブピクセル、GMC といった最新オプションは利用できません。 uManiac Stable は、だいたい月一度だけ更新される保守的なもので、2002年11月から更新がなく、そろそろ更新されるだろうという感じでした。 今回更新されたのが、これ。uManiac Stable は過去のものからチェンジログつきでアーカイブ公開されており、 マイルストーン・ビルドといった感じです。

XviD.Root.13.02.2003.1810.exe
CRC [ 89BC0A29 ]

どのビルドを使うかはお好みしだい、相性しだい。 ひとつだけ注意点があるとしたら、グーグルで検索すると上のほうに出てくる DivX Digest のミラーは本家の更新をきちんと反映しないので、 避けたほうが良いです。

2003年2月16日

uManiac の「 stable 」が更新され、マイナーバグフィックスかと思っていたら、 設定ダイアログを開いてびっくり! Bフレームはもちろん、 「グローバル・モーション有効」、「超精密動き検出(1/4ピクセル単位)」、 「動き検出に色情報も使う」、などの開発系オプションがマージされたばかりか、 うわさのVHQまで入ってます。 「 stable 」と言いつつ先端オプションは自己責任で使うべきですが、それにしてもすごい。 BフレームがXviD安定系にマージされたら、5.0.3に上がったDivXをふたたび確実に追い越してしまう予感。 なんで stable のページにあるのか問いつめたい気もするが、要するにdevツリーのソースがルートツリーに入れられるだけ安定したと認められた、 ということなのだと。

uManiac Stable の最近の更新について

注: 上記以降、uManiac Stable は毎日のように更新がつづき、 毎日変更されるようなものをユーザサイドからみて Stable(安定版)と呼べるのか?という当然の疑問が生じた。 これに関するやりとりが上記スレで、要するにユーザからみて以前のような意味での安定版とは言えない。

2003年2月27日

XviD - uManiac 「新・安定版」

uManiac の stable のページは、ふたたび実質的な安定バージョンの置き場となり、 開発最前線のものをビルドしたインスタント・ビルドのコーナーとふたたび通常の感覚通りの二本立てに。 「新・安定版」というのはちょっと大げさな言い方かもしれませんが、xvid.org が公式リリースしたパブリックリリース0.9.1にもとづくビルドでおすすめ。(正式リリース版となる予定の 1.0 よりは、まだ前の開発段階のものです。)
http://umaniac.leffe.dnsalias.com/stable/XviD.Root.24.02.2003.1100.exe

OggMux 0.9.4.2

2003年2月15日

.ogg と合成するとき、 オフセット(ディレイ)を指定できるようになりました。「なんたら T01 2_0ch 448Kbps DELAY -172ms.ac3」のような ac3 からディレイつきで直接にOGGにしたとき、 実用上すぐにべんり。(音声 mp3の場合、OggMuxer では未実装。) プリセットタグでは、音声に「中国語(北京)」、字幕に「中国語簡体字」「中国語繁体字」が補完されました。 もっとも言語タグはプリセットになくても、GraphEdit でダイレクトにタイプもできますが……
何といっても、こっちはこっちで行くもんねというスタンスに感じ入りますね。 Tobias が xiph に入ったというニュースの続報がないままに、 Koepi がこっちを更新したのは、ちょっと波紋を呼びそうな。 Koepi はもともと xiph 側が(Koepiたちの育ててきた)OGMに合わせるのが当たり前、というようなニュアンスがあって、 xiph寄りのメンバーから「そうとも限らない」と反論されたりしてきたのですが、 これは「意思表示」ととっていいのでしょうか。それとも、単なる定期的なメンテ更新なのか。 Tobias自身のDSが止まってるだけに……XviDのソースもCVSからとったものに「勝手に」自分のオマケ機能をつける Koepi のこと、 TobiasのDSFがオープンソース公開されたときにどう動くか想像してみると楽しい。
中国語簡体字と繁体字、いやーユニコードでやる気充分。対する「本家」OGGですが、 アンチ mp3 から始まった形式が mp3 との mux をどこまでサポートするんでしょう。 OGM側はパテントなんてお構いなしにAC3でもAACでも「自己責任」でmuxできますが。 MCFマトリョーシカとなるとWMVやWMAまで使えるコンテナになるようで、MP+(最近は正式名称MPCで、MediaPlayerClassicと紛らわしい)もサポートに入ってるし。 xiph.org が自家製の Ogg Vorbis + Ogg Theora しか合体させれないmuxerを出してきたらその「独占欲」についてMSなみに笑えますね。 (もちろん、そんなことはあるまい、というお話ですが。) そのことはみんな思っているし、xiph のジレンマなんでしょうけど。 だって、xiph のチェンジログに「mp3 VBR のサポートを改善」とか書いてあったら、それもまた楽しいような……。 「xiph は mp3サポートを強化しました」……ってすごいジレンマでは。 OGM、MCF、MKV は音声 .ogg に限らず MP3 VBR をどうどうと使いたい人にとっても良いかも。

VirtualDub 1.5.0

2003年2月17日

バージョン番号的には大きな桁上がりですが、内部的なアーキテクチャが全面変更されたためだそうです。 表面的な変化は少ないです。 音声のフィルタが追加されましたが、これはまだ開発段階。 ついでながら、今回のリリースノート末尾に Onegai Teacher がおもしろかったうんぬんのアニメバナシが書いてあります。 同じ声優が違うシリーズで違う役をやってるのはおもしろいよね、なんて無邪気なことが……。

そのほか

2003-02-16 Net Transport Official Site MMS/RTSPな総合ストリーミングダウンローダーらしい

テキスト版省パケ版XML版



faireal.net このウェブサイトは、まもなく終了します。 このページに書いてあった情報は、特に断り書きがない限り、自由に使ってください(コピー、改変を含む)。

Public Domain Dedication クリエイティブコモン「パブリックドメイン」ライセンスを選択してもかまいません(自由)。

「著作」に対するこのような考え方は、20世紀頃の人間法に合致しない可能性があります。

花の魔法使い マリーベル

このページの情報に関するフィードバックは、掲示板または下記メールアドレスへ(PGP)。

webmaster@faireal.net
SEO [PR] !uO z[y[WJ Cu