ageha was here

2007/11/15を以て当ブログは更新を停止しました。記事は全てこのままですが、基本的に内容はOut of dateとお考え下さい。

ホーム > XXとは

MPlayer/MEncoderとは

　linux由来の動画再生/エンコードツール。オープンソース・フリー、コマンドライン。Macではターミナル（BSD互換サービス）、Winでは linux互換環境下（Cygwinなど）で動作。ffmpeg、VLCとともにlinuxにおけるマルチメディアの基盤となっている。 Firefox/Mozilla系のプラグインとしても動作するようだ。

　ライセンス形態はGPL。やや古いがGPL非互換のソースコードを含んでいるとの指摘もあり、公式にビルド済みバイナリを提供しているパッケージ管理システムは多く無い模様。また、エンコード関連の常として特許リスクがつきまとう。
　公式サイトはソースコードのみの配布に留まり、推奨入手方法は『コマンドライン版を最新のソースコードからビルドして使う』だ。GCCではビルド時に CPU毎に最適化オプションを指定できるが、それもconfigureスクリプトに任せて弄るなとしている。

　ビルドに関しては依存関係にあるライブラリが多岐に渡るため、気軽には手を出しにくい。linux/win向けには各CPUに最適化した『野良ビルド（非公式ビルド）』が短い間隔で配布されている。Mac OSX向けとしては、ffmpegXやD-Vision 3などのGUIラッパーから抽出して使う方法があるが、これらは常にやや古い。

　MEncoderは基本的にavi作成に特化した作りになっている。xvid+mp3.avi作成に於いては無敵とも言えるが、.mp4の作成は事実上使い物にならず（2006夏現在）、一旦rawvideo.264に吐き出してmp4boxで固定fpsの.mp4に変換する必要がある。この場合 MEncoderが備えるA/V Sync 機能は働かないようだ。Playerとしても、一般的な視聴目的ならGUI付きのビルド済みバイナリを配布している VLCの方が向いている。

　これらを圧してMac OSX上でMEncoderをビルドするメリットは以下の通り。

充実したフィルタ（インターレース解除、デノイズ、その他）

24fps素材で無敵のpullupや微調整の効くhqdn3dを筆頭に多彩なフィルタが揃っている。WinのAviSynthには及ばないと思われるが、mcdeint（動き補償デインターレース）など、新しいフィルタも控えている。

最新のコデック（x264、SNOW、その他）

MPlayer/MEncoderは、映像・音声ライブラリの開発に軸足を置くffmpegと共存関係にあり、MPlayer/MEncoder のソースコードを落とすと最新版のlibavcodec, libavformatが付いて来る（サーバーも同居）。またx264はリビジョンが頻繁に更新されるが、MEncoderはその全てに同時に追随している。x264の『リリース』はMEncoder同梱の形を取る公算も高い。winではAviSynth 経由でx264cliを使うのが一般的だが、オープンソースでは単一のCPUやOSに縛られる事を嫌う文化があるからだ。

man、ドキュメントの充実

ffmpegやx264cliに比べると、MPlayer/MEncoderのmanやドキュメント類は異常に充実している。決して優しくはないが、初心者向けのまとまった文書として存在している事が重要。得るものは大きい。

　Mac OSXで動作するエンコード環境としては、質・量ともに望み得る最善に近い。

外部リンク

MPlayer - The Movie Player：公式サイト（英文）
MPlayer/MEncoder：公式マニュアル（英文）
MPlayer/MEncoder：公式ドキュメント（英文）
www.itdp.de：メーリングリスト・アーカイブ（英文）
MPlayer and MEncoder on MacOSX：（和文、マニュアルとドキュメント、試訳途上）

スポンサーサイト

[ 2006/08/24 00:00 ] MEncoder　メモ | TB(0) | CM(0)

SVNとは

公式サイト：http://subversion.tigris.org/
日本語の解説：SubversionBook
配布所（.dmg形式）：http://subversion.tigris.org/project_packages.html

※他にFinkでも可

　CVS代替を目指して開発中のバージョン・コントロール・システム。ライセンス形態は Apache/BSD-スタイル、オープンソース。
　最新リリースはSubversion 1.4.0。Mac OSX 10.4.xには入っていない。
　ffmpeg, MPlayer, x264などが使う。

　CVSと大きく違うのは、ディレクトリ、コピー、リネーム、実行権限の変化も管理対象とするので、僅かな変化でもリビジョン（rev）が変化する事。

[ 2006/09/17 00:00 ] Macと*nix | TB(0) | CM(0)

時間軸fps混在と空間軸fps混在

※勝手な造語

fps混在

　24fpsで製作された部分と30fpsで製作された部分が混じっている映像(*1)。
　TV放送は30fpsだからTVカメラはもちろん30fps、インターレースド。映画カメラは24fps(*2)のノンインターレースド。だから、映画カメラで撮影された映像は、TV放送の際には30fpsに変換して放送される。このフレーム水増しをテレシネ変換と言う。映画、古いTVドラマ、アニメなど。
　こういう素材は逆テレシネで24fps化すれば奇麗にインタレ縞が取れる。元々のフィルムにインタレ縞は無いから。しかし、TV放送そのものが 30fpsなので、それを前提に製作された要素がTV番組の中に混じる事がある。

*1）24fps：厳密には 1001/24000fps。23.976fpsとも。30fps：同じく1001/30000fps。29.97fpsとも。
*2）『駅馬車』（Stagecoach、1939）で使われた新技術。それ以前は15fps。

時間軸fps混在

　時間軸上に24fpsで製作された部分と30fpsで製作された部分が混じっているもの。可変フレームレート（VFR）と言った方が通りが良い。
　歴史的に映画カメラによるコマ撮りで始まったアニメは基本24fps。古いディズニーなどは絵描きががっつり24枚描く。国産はごく一部を除いて8～ 15fps(*3)だが、CGなど部分的に30fpsが使われるケースが増えている(*4)。
　時間軸fps混在はアニメだけではなく、映画カメラ撮影シーンとTVカメラ撮影シーンを繋ぎ合わせたものは全て該当する。『BSアニメ夜話』ではスタジオでゲストがダベるシーンと、アニメの名場面が交互に出て来るが、『なつかし映画名場面全集』みたいな番組でも同じだ。TVドラマでも古いものは映画カメラ撮影だし、最近でも予算が許せばフィルム撮りはある。

*3）2コマ撮りとか3コマ撮りとかリミテッド・アニメとか言う。手塚治虫が『鉄腕アトム』（1963）で始めた。これに対して24枚がっつり描くものをフルアニメと言う。
　国産では戦前のウルトラ気合いの入ったものから、東映動画の初期作品あたりまで。
*4）Winでは古くからココにこだわって120fps.AVIなどの手法がある。アニメのフレームレートまとめwikiというものもある。MEncoder で出来ない事も無い。

空間軸fps混在

　空間軸上に24fpsで製作された部分と30fpsで製作された部分が混じっているもの。例えば、映画の字幕、アニメオープニングの歌詞やスタッフロール、TV局のロゴ、など。あと地震情報とか津波警報とかニュース速報とか…^^;
　こういうものは、一場面の中で映画カメラ撮影成分(24fps)とTVカメラ撮影成分(30fps)が混在している。字幕やTV局のロゴなどは、最初から毎秒 60000/1001フィールドを想定して作られている。

　どちらであるにせよ、逆テレシネフィルタではfps混在はウマく扱えない。

[ 2006/11/25 00:00 ] 動画　動画全般 | TB(0) | CM(0)

I/IDRフレームとは

Iフレーム：デカイ・キレイ・画質の素

　Iフレームとは普通の一枚絵の事。PやBフレームはIフレームとの差分なので、Iは全ての空間軸画質（一時停止したときの奇麗さ）の土台になる。あるフレームを別フレームとの差分で済ませる事を時間軸圧縮と言うのだけれど、要するにアニメの口パクだ。

　差分で済ませるとは、元になるフレームが無ければちゃんとした絵にならないと言う事だ。こうしたフレーム間の依存関係を「参照、reference」と呼び、Iフレームと、それに依存するフレームの軍団をGOP（Group of Pictures）と呼ぶ。
　下図は最も単純な時間軸圧縮の例。ここでは各Pは直前フレームのみを参照してると思って欲しい。

　時間軸圧縮を使った動画は、だいたいこのGOPの連続でできている。
　Iフレームの特徴は、ますP/Bに比べるとデータサイズが大きい事。これはもう圧倒的だから、Iは場面転換の先頭にあるのがいちばん効率がいい。次に、シーク（早送り・巻き戻し・スキップ・頭出しなどの総称）は基本的にIフレームが基準となる。上図のPフレームだけ頭出ししてもまともな絵にはならないよね。最後は少しややこしいのだけど、依存関係にあるフレームの処理（エンコード・デコード）が完了するまで、参照元のフレームはデコーダ・バッファ・メモリに置いておく必要がある。
　ようするに、Iはデカイ・キレイ・画質の素。

IDRフレーム：Iとシークとマルチレフ

　H.264/AVC規格で新しく追加されたフレーム。Iフレームとしても機能する。おそらくはIフレームに特定のフラグを付けたもの。
　特定のフラグとは次のようなものだ。
　H.264は時間軸圧縮にMultiple reference pictures（＊マルチプル・レファレンス、複数参照、自分的には不等距離参照＊）を使う。例えば、旧規格のPフレームは直前のフレームしか参照できなかったが、 H.264ではもっと前のフレームを参照できる。具体的な効果は、通過する車が建物の向こうに一旦隠れて反対側に出る、といった場面に現れる。こういう場面で車の前半分くらいを自分より前のフレームからの"引用"で済ませる事を動き補償と言うのだけれど、当然、直前よりはもっと前からパクってきた方が効率が良い。
　しかしいくら効率が良いと言っても無限に参照関係を作るとキリがないし（映画のエンドロールが冒頭のフレームを参照するとなると、映画一本まるまるバッファに置いておく必要がある）、間違って全然関係無いシーンを参照してしまうと画質が悪い上に"差分"のデータ量も膨大になる。
　従って、マルチプル・レファレンスにはなんらかの参照関係の区切り、ストッパー役が必要になる。シーンチェンジ検出機構をこの参照関係の区切り役に使うのがkeyint関連。常識的な立場（デコーダに積める程度のバッファ）から参照関係に区切りを付けるのがframeref（-r,--ref）だ。
　なお、規格上の参照関係は前後を問わないがx264ではPは前、Bは前後各１を使うようだ。

■参考記事

[ 2006/11/30 00:00 ] 動画　動画全般 | TB(0) | CM(0)

SSIMとPSNRとは

PSNR：

長所

シーンカットの無いシークエンスを、設定を変えてエンコードした場合、ほとんど必ず、PSNRの高いほうが画質が良い。
グローバルPSNRで0.2dB違えば通常は充分に目で見て解る違いがあるとされる。
したがってPSNRは、エンコードの過程で変化するコデックのパラメータ（RDOやレートコントロール）を最適化する上ではまずまず役に立つ。

短所

PSNRの値そのものは無意味。PSNRが同じでも、素材同等になるケースもあれば汚いアーティファクトが出る事もある。これは素材の長さとアルゴリズムのタイプに依存する。従って、違いの大きなアルゴリズムを比べる際には、PSNRは使えない。また、PSNRを元にしてシーンカットをまたがるbit配分を行うのは無意味。
大して見える事の無いアーティファクトの中に、PSNRに大きく影響するものがある（例えば、Y軸の均等スケーリングや、各ピクセルに少量のガウシアンノイズを加えた場合など）。その一方、非常に目に留まり易いにも関わらず、PSNRにほとんど影響しないアーティファクトというものもある（例えばブロックノイズ）。

SSIM：

長所

PSNRの問題を相当程度に緩和する。動画/静止画の画質指標としては*ベストではない*が、高速に算出できるものとしてはベスト。
SSIMの絶対値比較は妥当と言える。

Loren Merritt氏の見解を表にしてみた。

SSIM値	qp設定値（※）
0.98 以上	20	オリジナルと区別がつかない。
0.95	30	見るに耐えない。（＊または辛うじて、そこそこ見られる＊）
0.9	40	非常に醜い。
0.8	51	これ以上は圧縮できない
0.7以下	-	素材に大量のノイズを加え、さらにそのノイズを量子化工程で消し去るほどqpを高くしない限り、達成困難。

※おそらく、qpを使った1パスABRと思はれる。

短所

　詳細不詳。
　x264のSSIMは概算。開発者は多くの場合（普通の長さの動画）では、"ほんとうのSSIM"の数パーセント程度の精度になるとしている。
　厳密に計算すると時間が100倍くらいかかるのだとか。

agehaにオリジナル無し
■原文：[x264-devel] Defining video quality

▼Axel Gunter：06/12/1

x264 と JM (10.2) の画質を比較する際に、自分は PSNR を使っていた。
 自分の理解では、JM は実際の動きやテクスチャのディテイルの再現よりは、PSNRの向上を追求したものに思える。
 x264も同じ方向性だろうか？
 また、画質の定義として、他に産業界で一般的な数値指標はないだろうか？というのは、PSNRはミスリードを起こす事があるからだ。なにかヒントか、コメントが欲しい。

While comparing x264 with JM (10.2) I had been using PSNR for comparing the qualities of the two encoders. I understand JM is an encoder designed to achieve better PSNR rather than track true motion, or increase texture detail. I was wondering if x264 was based on a similar theory? 
 Also, what other metrics are usually being used in the industry to define video quality, since PSNR can be misleading at times. Any pointers/comments? 
       
 Thanks 
 Axel

▼Guillaume POIRIER：06/12/1

x264 はエンコードの SSIM を表示できる。これはより正確とされている：
       http://en.wikipedia.org/wiki/SSIM       
       SSIM（From Wikipedia, the free encyclopedia）
 ※部分試訳         Structural SIMilarity (SSIM) index（＊構造的類似性指標＊）は、二つの画像の類似性を計測する方法です。SSIMは全てを参照する測定基準（＊full reference metric＊）です。別の言い方をすると、画質を元の非圧縮、または歪みの無い画像に基づいて計測するということです。
 SSIMは過去の汎用画質指標よりも改善されています。PSNR や MSE などの広く用いられている方法は、人間の視覚認識とは矛盾している事が証明されています。       
 Guillaume 
       -- 
 喧嘩することの無い人々の協調関係というものは、最大の国家連合からタウンミーティングや教区会に至るまで、これまでに存在した事が無い。
 -- トマス・ジェファーソン
 （MPlayer ML におけるフレーミングについてインタビューを受けた際に）
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html

x264 can give the SSIM of the encode, which is supposed to be less 
 missleading: http://en.wikipedia.org/wiki/SSIM       
       
 Guillaume 
       -- 
       An association of men who will not quarrel with one another is a thing 
 which has never yet existed, from the greatest confederacy of nations 
 down to a town meeting or a vestry. 
 -- Thomas Jefferson 
 (when interviewed about MPlayer ML flamewars) 
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html

▼Alex Izvorski：06/12/1

こんにちは Axel。

Guilliame が書いた通り、x264は SSIM と PSNRを算出できる。
ほとんどの場合、私はSSIMを使う事を奨める。SSIM は非常に良い指標だ。
そしておそらく、PSNRよりも早く、かつ正確なものとしては唯一だ。

単に非常に良い指標では満足できず、天下無双の指標を求めているならば、そしてまた各種指標の比較を知りたいならば、VQEG FR-TV Phase I および Phase II リポートが役立つかも知れない：

http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseI/COM-80E_final_report.pdf
http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseII/downloads/VQEGII_Final_Report.pdf

上記のテストでは、最強の画質指標は NTIA (ANSI T1.801.03-2003, ITU BT.1683)だ。SSIM はほぼこれに対等。面白い事に、おおくの有名な指標、例えば JND (Tektronix/Sarnoff)や、DVQ (Watson/NASA) 、そして PDM(EPFL) などは、どれもY-PSNRだけを使った場合とほぼ同等か、より悪い（！）。

PSNRについて：
シーンカットの無いシークエンスを、同じアルゴリズム（＊この場合ほぼコデックと同義か＊）で、設定を変えてエンコードした場合、視覚的にはPSNRの~~低いものほど~~高いものほど良い。ほとんど必ず。したがってPSNRはエンコードの過程で変化するコデックのパラメータ（RDOやレートコントロール）を最適化する上ではまぁまぁ役に立つ。

しかしながら、PSNRにはいくつか欠点がある。
１）PSNRの値そのものにはなんの意味も無い。例えば、PSNRが40のエンコード結果とオリジナル素材が二組あった場合、片方が素材同等に見える一方で、もう片方は汚いアーティファクトが出ている、といった事があり得る。これは素材の長さとアルゴリズムのタイプに依存する。これは、大きな違いのあるアルゴリズムを比べる際には、PSNRは使えないという事だ。また、PSNRを元にシーンカットを跨がるbit配分を行うのは無意味という事でもある。
２）本質的には目に見える事の無いアーティファクトの中に、PSNRに大きく影響するものがある（例えば、Y軸を均等にスケーリングしたり、各ピクセルに少量のガウシアンノイズを加えてみて欲しい）。その一方で、PSNRに非常に低い影響しか持たないが、非常に目に留まり易いアーティファクトというものもある（例えばブロッキング）。

SSIMはこれらの問題を、相当程度に緩和する。SSIMは動画/静止画の画質指標としては*ベストではない*が、高速に算出できるものとしてはベストだ。SSIMの絶対値比較は妥当と言える。非常におおまかなガイドとしては、0.7以下は見るに耐えない。（＊または辛うじて、そこそこ見られる＊）。0.8-0.85は多少の目に見える映像の歪みが出るが、大方の人にとってはOK。0.9以上はオリジナルと区別がつかない。

注意して欲しいのは、x264のSSIMは"ほんとうの"SSIMアルゴリズムのあるべき姿とは別の方式で算出されている事だ。windowingも、 luma maskingも、motion maskingも無い。算出しているのは、sample of all possible positionsだけだ。しかしながら、多くの場合、"ほんとうのSSIM"の数パーセントは表している。そして概ね100倍くらいは早く算出できる。ここで"多くの場合"とは、普通の長さ（＊natural footage＊）という意味だ。

可能性としては(＊不詳＊) があり得る。
しかしそうしたケースに遭遇する事は極めて稀だろう。もし本当のSSIMが欲しければ、私にそういうコードを書くように五月蝿く騒ぎ立ててくれ。;)

Hello Axel,

As Guilliame wrote, x264 can calculate SSIM as well as PSNR. I
recommend using that for most work. SSIM is a very good metric, and
probably the only one that is both fast and better than PSNR.

If you are looking for the absolute best metric as opposed to a merely
very good metric, and also for how to compare metrics, you may wish to
read the VQEG FR-TV Phase I and Phase II reports:

http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseI/COM-80E_final_report.pdf
http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseII/downloads/VQEGII_Final_Report.pdf

In those tests, the best metric is NTIA (ANSI T1.801.03-2003, ITU
BT.1683). SSIM also does quite well. Interestingly, many well-known
metrics such as JND (Tektronix/Sarnoff), DVQ (Watson/NASA) and PDM
(EPFL) are either about the same, or worse than, using just Y-PSNR (!).

About PSNR: if you encode the same continuous (no scenecuts) sequence
with the same algorithm with several different settings, the version
with the lower PSNR is almost always visually better. Thus PSNR does a
reasonably good job of allowing you to optimise codec parameters that
you can vary during an encode (like RDO or rate control).

However, PSNR fails on several counts:
1) The absolute value of PSNR means nothing. In other words, looking at
two pairs of original/encoded images both with PSNR of 40 (for example),
one pair may look identical and the other may have gross artifacts. It
all depends on the source footage and on the type of algorithm. This
means that PSNR is useless for comparing significantly different
algorithms. It also means that using PSNR to allocate bits accross
scenecuts will result in bad decisions.
2) Some artifacts which are essentially invisible have a huge PSNR
impact (try scaling Y uniformly or adding a small amount of gaussian
noise to each pixel for example). Other things which are extremely
visible have an unreasonably low PSNR impact (like blocking).

SSIM fixes these problems to a significant degree. It is not *the best*
video/image quality metric, but it is the best that can be computed
quickly. SSIM absolute values can be reasonably compared: as a very
rough guide, below 0.7 is barely watchable, 0.8-0.85 has some visible
distortion but ok for most people, and 0.9 and higher are
indistinguishable from the original.

Please note that SSIM in x264 is not calculated the way that the "real"
SSIM algorithm (and papers) say it should be. There is no windowing, no
luma masking, no motion masking, and only a sample of all possible
positions are calculated. However, it is within few percent of the
"real" SSIM in most cases, while being about a hundred times faster to
calculate. "Most cases" here pretty much means any natural footage; it
may be possible to construct synthetic footage so as to defeat the
approximations used, but you are extremely unlikely to ever encounter
such. If you want real SSIM, bug me to release my code for that ;)

Regards,
--Alex

▼Loren Merritt：06/12/1

       PSNRについて：
 シーンカットの無いシークエンスを、同じアルゴリズム（＊この場合ほぼコデックと同義か＊）で、設定を変えてエンコードした場合、視覚的にはPSNRの低 いものほど良い。ほとんど必ず。したがってPSNRは            ^^^^^ 高い程、
       PSNRはエンコードの過程で変化するコデックのパラメータ（RDOやレートコントロール）を最適化す る上では まぁまぁ役に立つ。
         
 しかしながら、PSNRにはいくつか欠点がある。
 １）PSNRの値そのものにはなんの意味も無い。例えば、PSNRが40のエンコード結果とオリジナル素材が二組あった場合、片方が素材同等に見える一方 で、もう片方は汚いアーティファクトが出ている、といった事があり得る。これは素材の長さとアルゴリズムのタイプに依存する。これは、大きな違いのあるア ルゴリズムを比べる際には、PSNRは使えないという事だ。また、PSNRを元にシーンカットを跨がるbit配分を行うのは無意味という事でもある。
 ２） 本質的には目に見える事の無いアーティファクトの中に、PSNRに大きく影響するものがある（例えば、Y軸を均等にスケーリングしたり、各ピクセルに少量 のガウシアンノイズを加えてみて欲しい）。その一方で、PSNRに非常に低い影響しか持たないが、非常に目に留まり易いアーティファクトというものもある （例えばブロッキング）。
         
 SSIMはこれらの問題を、相当程度に緩和する。SSIMは動画/静止画の画質指標としては*ベストではない*が、 高 速に算出できるものとしてはベストだ。SSIMの絶対値比較は妥当と言える。非常におおまかなガイドとしては、0.7以下は見るに耐えない。（＊または辛 うじて、そこそこ見られる＊）。0.8-0.85は多少の目に見える映像の歪みが出るが、大方の人にとってはOK。0.9以上はオリジナルと区別がつかな い。 　本当に？自分の意見では、
 SSIM=0.98+ (qp=20) はオリジナルと区別がつかない。
 SSIM=0.95 (qp=30) は見るに耐えない。（＊または辛うじて、そこそこ見られる＊）
 SSIM=0.9 (qp=40) は非常に醜い。
 そしてこれ以上は圧縮できないレベル (qp=51) ですら SSIM=0.8となる。
 手許では、素材に大量のノイズを付け加え、そのノイズを量子化工程で消し去るほどqpを高くしない限り、SSIMが0.7 以下となる映像は生成出来ていない。
       
 PSNRでもSSIMでも、指標の絶対値は、圧縮後のストリームにどれだけのqualityが残っているかを示すというよりは、素材にあるノイズの量を示 すものだ。
       
 しかしながらおそらく、同じノイズを持っていると想定される場合、映画の中の異なった場面を比較する上ではSSIMの方が上だろう。
       
 --Loren Merritt 

On Thu, 30 Nov 2006, Alex Izvorski wrote: 
       About PSNR: if you encode the same continuous (no scenecuts) sequence 
 with the same algorithm with several different settings, the version 
 with the lower PSNR is almost always visually better.  Thus PSNR does a 
                   ^^^^^ higher 
       reasonably good job of allowing you to optimise codec parameters that 
 you can vary during an encode (like RDO or rate control). 
         
 However, PSNR fails on several counts: 
 1) The absolute value of PSNR means nothing.  In other words, looking at 
 two pairs of original/encoded images both with PSNR of 40 (for example), 
 one pair may look identical and the other may have gross artifacts.  It 
 all depends on the source footage and on the type of algorithm.  This 
 means that PSNR is useless for comparing significantly different 
 algorithms.  It also means that using PSNR to allocate bits accross 
 scenecuts will result in bad decisions. 
 2) Some artifacts which are essentially invisible have a huge PSNR 
 impact (try scaling Y uniformly or adding a small amount of gaussian 
 noise to each pixel for example).  Other things which are extremely 
 visible have an unreasonably low PSNR impact (like blocking). 
         
 SSIM fixes these problems to a significant degree.  It is not *the best* 
 video/image quality metric, but it is the best that can be computed 
 quickly.  SSIM absolute values can be reasonably compared: as a very 
 rough guide, below 0.7 is barely watchable, 0.8-0.85 has some visible 
 distortion but ok for most people, and 0.9 and higher are 
 indistinguishable from the original. 
              
 Really? imo, SSIM=0.98+ (qp=20) is indistinguishable from the original, SSIM=0.95 (qp=30) is barely watchable, SSIM=0.9 (qp=40) is really ugly, and there could be nothing left of the content (qp=51) and still produce SSIM=0.8. I failed to generate any videos with SSIM<0.7 except by adding tons of noise to the source and then setting qp high enough that all the noise is quantized away. 
 With both PSNR and SSIM, the absolute value of the metric is more a measure of how much noise was in the source than it is of how much quality is left in the compressed stream. Though perhaps SSIM does better at comparing difference scenes within one movie, when they can be assumed to have the same noise. 
       
 --Loren Merritt

▼jtwen：06/12/1

x264 のモード決定や動き予測の過程でSSIMを使う方法はある？
       

Is there a way of using SSIM in the mode decision and ME process of x264?
       
 Thanks,
 Gene

▼Guillaume POIRIER：06/12/1

x264 の土台部分には無い。しかし、
       http://akuvian.org/src/x264/x264_ssim_map.00.diff
 このパッチの名前からすると、smthがなんかしてるんぢゃないかと思う。
       
 Guillaume 
       -- 
 喧嘩することの無い人々の協調関係というものは、最大の国家連合からタウンミーティングや教区会に至るまで、これまでに存在した事が無い。
 -- トマス・ジェファーソン
 （MPlayer ML におけるフレーミングについてインタビューを受けた際に）
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html
       

Not natively with vanilla x264, but the name of this patch 
       http://akuvian.org/src/x264/x264_ssim_map.00.diff makes me think that 
 smth is in the works. 
       
 Guillaume 
       -- 
       An association of men who will not quarrel with one another is a thing 
 which has never yet existed, from the greatest confederacy of nations 
 down to a town meeting or a vestry. 
 -- Thomas Jefferson 
 (when interviewed about MPlayer ML flamewars) 
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html

[ 2007/01/19 00:00 ] 動画　動画全般 | TB(0) | CM(0)

MeGUIガイド_コンピュータの動画ファイル

原文：Computer movie files

コンピュータの動画ファイル

コンピュータの動画ファイルとは、オーディオとビデオを含んだファイルです。動画ファイルは複数のコンポーネントからなっており、各コンポーネントは大抵はモジュール構造になっています。モジュール構造とは、他の部分に影響を与えずに、簡単に取り換えられるという意味です。このページでは、様々なタイプのモジュールを説明し、一般的な例を挙げてゆきます。

重要: 　このページ（とサブページ）には主観的な品質比較が書いてある事があります。しかし、最終的な判断は自分の目（または耳）で行うものですから、そのへんは話半分に読んで下さい。

コンテナ

　コンテナは全てのものを統合するパートです。映像（実際の画像）、オーディオ、その他に必要なものは全てコンテナの中に入れておく必要があります。複数のファイルをZipアーカイブの中に入れるような感じです。

コンテナが必要な理由は次のようなものです：

再生ソフト・ハードが各コンポーネントの取り扱いを便利にできるようにする。
付加的な機能をファイルに加えられるようにする。例えば：
- ストリームのインデックス付け
- メタデータ（内部のストリームに関する情報）
- エラー・リカバリー能力
- チャプタなどのメタ・ナビゲーション
- ストリーミング

　サブページ「コンテナ（英文試訳）」に様々なコンテナの情報があります。

ビデオストリーム

　ビデオストリームには実際に表示される映像データが入っています（ここで"動画ファイル"と言う場合はオーディオとビデオが入ったものを指します。"ビデオストリーム"は映像のみの場合に使います）。ひらたく言うと、圧縮された映像です。

ひらたくない説明（でも完璧ではない）：

ビデオコデックは一般にI、P、Bの三種類のフレームを使います。

I-フレーム（イントラフレーム、内部的なという意味）はキーフレームです。特定のフレームをjpgにしたようなものと考えて下さい（と言っても似ているのはどちらも静止画を圧縮したもの、といった程度です）。キーフレームは映像を短い範囲に区切り、他のフレームはこれを参照します。他のフレームに依存しなくてもデコードできるので、'イントラ'と呼ぶわけです。
P-フレームは予測フレーム（predicted frame）です。これは二つの部分からできている事を意味します。最初の部分はI-フレーム同様ですが、フレームの一部分を（全体ではありません）jpgに似た方式で保存します。残りの部分が '予測'の由来となります。前のフレームから拝借してくるのです。これは少し説明が必要でしょう。例えば、フレームの中央に顔のアップがあって、左に流れていくとします（パン）。最初のフレームが I-フレームであれば、2番目はP-フレームにできますから、「フレーム#01から情報を拝借してきて、左に4ピクセルずらせ、そしてその右側を新しいデータで埋めろ」みたいな事ができます。これが P-フレームです。マジでそんなカンジ。
B-フレームはこの理屈をさらに延長したものです。Bは双方向（Bi-directional）という意味です。これだけでもなんとなくわかるでしょ？B-フレームは前と後ろの両方のフレームから予測されます。それに加えてオリジナルの情報を書くこともできます。画像の作り方も前と同じで、違いは未来（＊後方＊）のフレームも参照できることだけです。詳しい事を知るまでは、単に使い物になるとだけ覚えておいて下さい。なぜ使い物になるのか考えると夜も眠れなくなってしまいますから。
　※訳注：実際問題、これでなぜ圧縮効率が向上するのかは完全には明らかになっていない（教科書p48）。
　※訳注：H.264/AVC規格のBは双予測（Bi-predictive、前後問わず２枚、教科書p22）、x264のBは双方向（man MEncoderの記述はBi-directionalで統一）。

規格とコデックの違いについて：

規格とは、ビデオフォーマット（に限りませんが）の仕組みを解説した仕様書の束です。
　※例：http://akuvian.org/src/x264/ITU-T_H264.pdf.gz
エンコーダ（別名コデック）とは、規格を実装、具現化したものです。
違いわかります？例えばMPEG-4 ASPという規格が出来上がると、様々な人たちが独自のエンコーダを作るという事です。DivX とかXviDとか。はいつまりDivXでエンコードしたファイルはXviDの再生に使うのと同じデコーダで再生できると言う事です。もちろん、現実はそんなに甘くなくて、それぞれのエンコーダは規格のなかから思い思いの機能を実装し、さらに独自の機能を加えたりもします。現実が甘く無い例としては：

Quicktime h264 はMPEG-4AVC規格のうち基本的な機能しか使っていません。x264のようなエンコ−ダが使うのは、実用上、規格上の機能のほとんど全てです。これは、QT上でファイルを作る限り、x264同等の画質を達成するのは困難な事を意味します。
　※訳注：「画質」だけならApple-h264でx264同等のものを作るのは特に困難とは思いません。問題は圧倒的な遅さです。優秀なインタレ解除やデノイズがフリーでは見当たらない事、Appleは一般ユーザーをiTMSでのデータ購入に誘導すべくQuickTimeインフラに様々な障壁を設けている（ように見える）事、などと合わせるとQuickTimeベースのエンコードを習得するのは非効率だと思います。

サブページ「 Video（英文試訳）」に様々なビデオフォーマットの情報があります。

オーディオストリーム

オーディオストリームには音声に関するデータが入っています。「オーディオフォーマット」という用語は前項の規格とコデックの関係に似ていますのでそちらを読んで下さい。

　サブページ「audio（英文試訳）」に様々なオーディオフォーマットの情報があります。

字幕（Subtitle）

ここでは、'the subtitles'とはソフトサブを意味します。ソフトサブは動画ファイルの再生中にオーバーレイ表示するものです。逆に映像の中に直接エンコードしてしまうものをハードサブと言います。ソフトサブのメリットはかなりたくさんありますので、ここでは主なものをいくつか挙げておきます：

複数の字幕ストリームを保存できる（他言語や、様々なスタイルなど）
字幕のオンオフができる（オーディオストリームが母国語の場合など）
映像と分離しているので、映像の圧縮効率が若干良い。

　サブページ「字幕（英文試訳）」に様々なサブタイトルフォーマットの情報があります。

そのほかの要素

その他の要素を詰め込める先端的なコンテナもあります。チャプタとか埋め込みフォントとか。以下に若干の例を挙げます。

アタッチメント

Matroskaは無駄の少ない小さなコンテナですが、如何なる種類のファイルでもアタッチ（＊添付＊）する事が出来ます。公開年度の情報を書いたテキスト？オリジナルサウンドとラックのZipファイル？DVDのジャケット？なんでもおっけー！。今の所そうしたものを展開できるソフトはmkvextractというCLIのものだけなのですが、GUIがたくさんあります。添付ファイルは巨大なこともありますから、ディスクスペースに注意して下さい。

エンベッデッド（埋め込み）・フォント

　これも Matroska のみの機能。 SSA/ASS字幕をmuxする時に、小洒落たフォントを使いたいがそれが再生されるコンピュータにあるとは限らない、といった事があります。Matroskaファイルのそのフォントをアタッチしてしまえば、vsfilter（デファクトのdirectshow用字幕レンダラ）がそのフォントを使って字幕を再生してくれます。

チャプタ

　これが何なのかは説明する必要はないでしょう。フォーマットによりチャプタのスタイルは異なります。以下はMatroskaの例です。

<Chapters>
 <EditionEntry>
   <EditionUID>1</EditionUID>
   <EditionFlagHidden>1</EditionFlagHidden>
   <EditionFlagDefault>0</EditionFlagDefault>
   <ChapterAtom>
     <ChapterUID>1</ChapterUID>
     <ChapterFlagHidden>0</ChapterFlagHidden>
     <ChapterFlagEnabled>1</ChapterFlagEnabled>
     <ChapterDisplay>
       <ChapterString>Part A</ChapterString>
       <ChapterLanguage>eng</ChapterLanguage>
     </ChapterDisplay>
     <ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
   </ChapterAtom>
   <ChapterAtom>
     <ChapterUID>2</ChapterUID>
     <ChapterFlagHidden>0</ChapterFlagHidden>
     <ChapterFlagEnabled>1</ChapterFlagEnabled>
     <ChapterDisplay>
       <ChapterString>Part B</ChapterString>
       <ChapterLanguage>eng</ChapterLanguage>
     </ChapterDisplay>
     <ChapterTimeStart>00:09:48.000000000</ChapterTimeStart>
   </ChapterAtom>
 </EditionEntry>

　やっかいですね。次はOGG フォーマットのチャプタです：

CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 1

　非常に簡単です。もちろん、Matroskaのほうが機能が豊富です。ここでは深入りしませんが、オーダード・チャプタについてだけ少し解説しておきます。

Ordered Chapters

　再生時に、動画ファイルの一部分として、他のmatroskaファイルを参照するチャプタ。例えば、TVシリーズをエンコードしたとしましょう。まず、全エピソードのオープニングとエンディングをカットしてそれぞれ独立したファイルを２個作ります。次に、本編ファイルにオーダード・チャプタを使えば、再生時にオープニングとエンディングを自動的に再生してくれます。

アナモルフィック・フラグ

　MKV と MP4コンテナに埋め込める機能。再生時に使うアスペクト（＊縦横＊）比の値、 anamorphic再生とも言います。例えば、16:9の映画を4:3のアスペクト比でエンコードした場合、MKVにmuxする際に再生時のアスペクトを 16/9と指定してやれば、再生ソフトは自動的にそのアスペクト比にリサイズして再生してくれます。

[ 2007/01/24 00:00 ] ごみ箱　未分類 | TB(0) | CM(0)

MeGUIガイド_コンピュータの動画ファイル/コンテナ

原文：Computer movie files/Container

一般的なコンテナ

AVI

　フルネーム：Audio Video Interleave
　おそらく、現存するコンテナの中で最も一般的なもの。ほとんど全てのメディアプレイヤ、OS/プラットフォームで再生できる。1992年にMicrosoftが開発。

　AVIは動画コンテナの基本線とされる場合が多い。最低限の機能を備えており、最も古く、最も一般的だからだ。今もって他のコンテナよりAVIを好む人もおり、たとえばこの人はAVIはMKVやMP4など、新しいコンテナがもつ機能の多くをサポートしていると指摘している。しかしながら、通常、そうした機能は規格化されていないか、性能が悪い。ただし、先進的なコデックの機能が不要なら、AVIは充分なものだ。

結論：必要な要素がxvid+mp3だけで、先進的なコデックの機能が不要なら最善（それでもMatroskaのほうが良いと言う人もあるだろう）。

FLV

　フルネーム：Flash Video
　このコンテナはFlashがビデオのストリーミングに使う。youtubeなどにあるフラッシュプレイヤーストリームがそれだ。またKeepVidのようなサイトを使った際にダウンロードするのもこれだ。ほとんどの場合、音声はMP3で映像はh263/h263+またはVP6。おそらく他のフォーマットも詰め込めるとは思うが、あまり意味が無い。従って、フラッシュビデオが必要でない限り、このコンテナをエンコードに使うメリットは無い。使い勝手に関する結論もありません。

OGM

　フルネーム：Ogg Media
　Tobias Waldvogelが当時としては驚異的だったVorbis オーディオコデックを、一般的なMPEG-4 ASPビデオフォーマットと一緒に使う為に開発した。OggコンテナとASPを摺り合わせる為にたくさんの "hack"を使っている。チャプタ、複数オーディオストリーム、コンテナ内へのソフトサブ埋め込みといった機能が揃っていたので、短期間のうちに非常に普及した。しかし最終的に、Tobiasが発表したOGM "規格"により開発は停滞、Xiph Projectが引き継ぐに至ったが、彼らはOGM"規格"をあまり尊重していないように見える。OGMと同等以上の機能を備え、オーバーヘッドも少ないMatroskaコンテナの登場により使う人は途絶えた。

結論：Matroskaに比べると、将来性が少なく、オーバーヘッドも大きい。ogmしか再生できないようなブッ飛んだデバイスでも持っていない限り、使うべきではないだろう。

※補足：OGMの顛末は妖精現実さんに詳しい。

MKV

　フルネーム：Matroska
　コンピュータ上で再生するにはおそらく最善のコンテナ。ほぼ全ての機能が使える。あらゆるビデオフォーマットが簡単に扱え、いかなる音声・字幕フォーマットも扱え、VFR、チャプタ、ソフトサブなどの先進的な機能も備えている。一般的なAVIよりもデコード負荷が高いとされているがそれは誤解と言って良い。負荷が増えるのは事実だが極めて僅かで、実用上の差はない。オーバーヘッドが少ないので映像やオーディオにその分のbitrateを振り向ける事もできる。
　ホームページはmatroska.orgだが、初心者に役に立つ情報はない。

結論：最も用途が広いコンテナ。すばらしい！

MP4

　フルネーム：MPEG-4 File Format
　第一版は1998年。規格化は1999年初頭。これがMPEGが策定した最初のMP4ファイルフォーマットで、基本的にwebビデオや携帯機器（携帯電話など）向けだった。1999年終盤には完全な後方互換性を備えたVersion 2が登場（規格化は2000年）。その後もMP4の拡張と開発が続いている。執筆時点での最新は2005年終盤に登場したMPEG-4 ALS (lossless audio coding)。

MP4は最新の MPEG 規格だけでなく、過去規格との後方互換性を持つ。MP4コンテナには以下のものを入れる事ができる：

ビデオ

MPEG-1
MPEG-2
h263(およびその拡張規格) (MPEG-4 V1を単純化した3gp経由で)（＊h263の拡張はh263+,h263++＊）
MPEG-4 ASP
MPEG-4 AVC (H.264)

オーディオ

MPEG-1 Layer 1
MPEG-1 Layer 2（＊MPEG-2 TVキャプチャがよく使う＊）
MPEG-1 Layer 3（＊通称MP3。デコーダはlayer 1,2と後方互換＊）
MPEG-2 (added support for lower frequencies and multichannel over MPEG-1)
AAC (MPEG-2も同様。しかし他の MPEG-2 audioとは異なり、MPEG-1との後方互換性は無い)
AMR (3gp経由)
CELP & TwinVQ (低ビットレート/スピーチ用)
SAOL (MIDI)
ALAC (Apple Lossless)
ALS (lossless)
SLS （これはAACのscalable lossless拡張）

ソフトサブ

3GP timed text
JPG/PNG image format

　MP4にはこの他にuser data atomというものがあり、その中にストリームに関するメタ情報やアルバムアートなどを埋め込める。プライベート・ストリームを使ってVorbisやAC3、またはDVDサブピクチャなどを埋め込む事も可能だが、これらは規格には無いので再生機器/ソフト類はサポートしなくても良い。そうした機能が必要ならMKVの出番だ。またMP4はメニューもサポートしている（それが動作するプレイヤやテスト用の素材も存在する）。

結論：MKVほどたくさんではないが、一般的なフォーマットは全てサポートしており、ISO規格により相互運用性も高い。MKVよりも「そのまま使える」ようにできている。これは商用ソフトやハードウェアプレイヤに反映されている。しかし明らかに、audio/videoデコーダのサポートはこれとは別の問題だ。MPEG-4 ASP/H.264映像とMP3/AAC音声をくっ付けたり、単に.ts や .mpg ファイルのコンテナだけを変更したいなら、MP4が最適だろう。ソフトサブやvorbisが使いたいならMKVを推奨する。
　MP4はMKVの補助として使える。エレメンタリ・ストリームをMP4にmuxすると通常はmkvmergeでは扱えない。当面の回避策としては単にMP4をインポートしよう。

※補足：

　原文はMKV全面推奨なので一応、難点を挙げておきます。
　第一は、ハードウェアプレイヤが期待しにくい事です。ogg Vorbisが登場時点では優れた性能を持ちながら現在の立場に落ち着いたのもソレ。一部の北米/韓国製MP３プレイヤはサポートしましたが、それだけでは充分ではなかったのだと思います。
　第二に、これは大多数には無関係ですが、Macではmkvtoolnixを始めとしたツールが常に古い事です。
　

※参考：槻ノ木隆のBBっとWORDS

[ 2007/01/25 00:00 ] ごみ箱　未分類 | TB(0) | CM(0)

MeGUIガイド_コンピュータの動画ファイル/Video

原文：Computer movie files/Video

Common Video Formats
1. MPEG
  1. MPEG-1
  2. MPEG-2
  3. MPEG-4 SP
  4. MPEG-4 ASP
  5. MPEG-4 AVC
2. h26_
  1. h263
  2. h263+
  3. h264
3. Snow
4. Theora
5. On2
  1. VP3
  2. VP6
  3. VP7
6. WMV
  1. VC-1
7. Real

Common Video Formats

MPEG

　MPEG（Motion Pictures Experts Group）が定める規格は、現在、最も一般的なビデオフォーマットの規格。

MPEG-1

　今でも使われているビデオフォーマット規格としては、おそらくもっとも古いもの。CDなどに動画を保存するために制定された。最も一般的なのは 352x240 @ 1.5mbits/secで、"VHS 画質"とされる。

MPEG-2

　MPEG-1よりも高ビットレート、高画質を目指して制定された規格。言い換えると1.5mbits以下ではMPEG-1とあまり画質に差がない。2mbits以上では顕著な差が出る。 DVDもこのフォーマットを使っている。DVDの映像は全てMPEG-2であり、平均的なビットレートは5mbit以下、解像度はPAL（＊EUなどの TV方式＊）で720x576、NTSC（＊日米などのTV方式＊）で720x480だ。少数ではあるが、YV12以外のカラースペースを使ったビデオフォーマットがある事に注意。YUY2フォーマットのMPEG2もある。

MPEG-4 SP

　SPは Simple Profile の略。
　後述するMPEG-4 ASPの簡略版。有益な機能が大量に省かれており、現在ではほとんど意味が無い。Sorenson（ QuickTimeが使用）と3ivxが有名。MicrosoftもMicrosoft Video V1/V2という名称でサポートしようとしたが、彼らのコデックは規格に準拠しておらず、ほぼ無視された。

MPEG-4 ASP

　ASPは Advanced Simple Profileの略。
　現時点でアニメ、アメリカのTV・映画のエンコードで一般的なフォーマット。DivX と XviDが有名。現在一般的なパソコンではCPU負荷は問題とするほどでは無く、画質も今もって十分と言える。

一般的なコデック：

XviD：フリーコデックとしてはベスト。恐らく、大半の商用コデックよりも良い。ASP規格のうちで実用になるものは全てサポートしている。ASPとしては間違いなく推奨できる。
DivX：初心者がよく使うが一般的には XviD のほうが結果は良い。なお、同梱のデコーダは酷いものなので決して使うべきではない。
LMP4：Libavcodec MP4の短縮形式。XviD同様のエンコーダだが、画質はやや劣る。mencoderなどに実装されている。

MPEG-4 AVC

　AVCはAdvanced Video Codingの略
　Wikipedia に詳しい解説（＊英文＊）がある。別名h264、単に AVCとも言う。MPEG4-ASPに続くMPEGの次世代動画圧縮方式。圧縮効率は目覚ましく（あるオプションだけで20%効率化（＊CABACと思われ＊））、エンコード・デコード負荷が高い。

一般的なコデック：

x264：XviD 同様のオープンソースエンコーダ。AVC準拠としては唯一で、全ての商用コデックを凌ぐ性能を持つ。high profile オプションの大半をサポート（前述のwikipediaに機能と profile level対応表がある）。パーソナル・ユースの高画質H264コデックとしてはデファクト。CLI で公開されている。ホームページは x264.nl。
Nero AVC：一般に入手可能なものとしては第二位。x264 と比べると、触れるオプションは半分程度だが、GUIで使える。最終的な画質はx264に及ばないが、GUIは初心者には魅力的だ。Nero Suiteに同梱。ホームページは nero.com
Apple h264：最下位はApple！。いや、実際には Xvidよりはずっと良いので最下位では無いが、古く、基本的なbaseline profileだ。ただし b-frameが1枚使える。詳細情報はここに。ホームページは apple.com/quicktime

h26_

　ITU-Tが策定する映像規格の総称。

h263

　基本的にはMPEG4-ASPのサブセット。携帯電話用の 3gp コンテナに入っている事が多い。

h263+

　h263の追加改訂版。追加部分に MPEG4-ASP と互換性のない要素がある。その結果 h263+ は h263 よりも稀。プロプライエタリなビデオ会議ソフトや一部の携帯電話に使われている。これも携帯電話用の 3gp コンテナに入っている事が多い。

h264

　MPEG4-AVCの別名。（＊ITU-Tサイドの呼称＊）

Snow

　既存のコデックとは全く異なる手法で映像データを保存する実験的なコデック。特に、マクロブロック情報の保存にDCT（Discrete Cosine Transformations、離散コサイン変換）を使う代わりにDWT（Discrete Wavelete Transformations、離散ウェーブレット変換）を使う。どう違うのかはよく解らないが、数学の話らしい。画質は概ね xvid相当だ。ただし、この新らしい圧縮方式のポテンシャルは極めて大きい。開発者の筆頭格であるpengvado（彼はx264の開発でも活躍している）はかつて、「この２年、x264ではなくsnowに集中していたら、間違いなくh264を超えていただろう」と言った事がある。要注目だ。
　面白い事に、データの保存方式が異なるので、圧縮で出るノイズも一般的なDCTコデックとは異なる。一回試してみてほしい。

　Doom9のSnowに関するスレッド（やや古く非活発）

Theora

　ソースコードを公開したOn2 VP3ベースのフリーコデック。開発ペースは比較的遅い方。このフォーマット最大の利点は、完全に、如何なる目的でもフリーに使える事。オープンソースソフトウェアの熱狂的信者向けという事だ。
　欠点は最新のコデックより画質が悪く、Windows上ではffdshow / VLC / mplayer しかサポートしていない。画質はほぼVP3レベルで MPEG-1 よりは若干良いが MPEG-4 AVC や VC-1よりはかなり落ちる。

On2

　On2は独自の動画規格とコデックを推進する企業。私企業なので彼らの動画規格はプロプライエタリで、閉じている。コデックを３つ出している。

　ホームページ

VP3

　古く、稀少。事実上使われていない。Theoraのベース。画質は MPEG-1クラス。

VP6

　現在ポピュラーになりつつあるフォーマット。flash ファイルで使える動画コデックは２個あるが、そのうちのひとつ。なのでyoutubeなどで使える。大半はもうひとつのほう、h263を使う。恐らくそのほうが安いから。画質はXvidの半分よりは上くらい。CPU 負荷は比較的低い。On2 websiteでフリーの個人向けエンコーダが入手できる。

　ホームページ

VP7

　非常にパワフルなビデオコデック。MPEG-4 AVC や VC-1と同等レベル。しかしながら次世代DVD規格（HD-DVD と Blu-Ray）には入っておらず、無用の長物になりつつある印象。On2 websiteでフリーの個人向けエンコーダ・デコーダが入手できる。

　ホームページ

WMV

　Microsoftが開発したWindows Media Videoに分類されるコデック。詳細はWikipedia（＊英文＊）参照。

VC-1

　WMV9の拡張版。放送向け機能を加えたもの。例えばインターレースド・エンコード（WMV9 のインターレースは4:1:1 colour フォーマットのみ）。画質は MPEG-4 AVC同等で、どちらが上かは結論が出ていない。

Real

　（＊原文に記載なし＊）

※Snowについて
　DWTの他に、H.263+由来のオーバーラップド・マクロブロックというマクロブロックの切り分け方式を使ってブロックノイズをほぼ根絶できるらしい。
　libavcodecシリーズの一つとしてffmpeg、MEncoderで試用出来る。winではMeGUI snow版が存在するようだ。
　コマンドが良く解らないが、手許のMEncoderで作ったsnow.avi/snow.mkvは非常に再生が重い（PowerPC G5 2Ghzx2）。
※訳文の精度
　このページ、原文の書き手は高校生くらいだと思う。
　各コデックの評価については、やや視野が狭い印象を受けました。
　ひらたく言うとドザ主観の過剰な形容詞や長ったらしいところは思いっきり丸めました。
　ただし初心者向けに解り易くまとまっており、今北産業級なのでそのままです。

[ 2007/01/27 00:00 ] ごみ箱　未分類 | TB(0) | CM(0)

MeGUIガイド_コンピュータの動画ファイル/Audio

原文：Computer movie files/Audio

一般的なオーディオ・フォーマット
1. MPEG-1 Layer 2 & 3
2. AAC
3. Vorbis
4. AC3
5. DTS

一般的なオーディオ・フォーマット

MPEG-1 Layer 2 & 3

Layer 2: 別名MP2。かなり稀少。その名称からMP3の方が良いと思う人が多いのだろう。Wikipedia（英文）によると、256kbits以上では MP3 よりも音が良い。

TooLAME (toolame.sourceforge.net) か ffmpegでエンコードできる。

Layer 3: MP3と呼ぶほうが有名。これはオーディオ・フォーマットの .avi であり、最も互換性が高い。音質は'平均的'。すなわち、全てのフォーマットのうちでいちばん悪い。しかしファイルはとても小さくなるので、単にビットレートを上げればしあわせになれる。エンコードは LAME (LAME Ain't an MP3 Encoder ～これは頭文字からつくった名称だから無視していい。LAME は MP3 エンコーダだ）。

Homepage: lame.sourceforge.net.

Download: rarewares.org/mp3 （アルファ版）

AAC

　AAC、別名Advanced Audio Coding、別名MPEG-4 Part 3、別名MPEG-2 Part 7（まぁ、AACでいいだろう）詳細はwikipedia（英文）。音質はMP3よりも良い。恐らく他のどのコデックより良いだろう。

　AACには三種類の 'プロファイル' がある。LC (Low Complexity)、HE (high efficiency)、そして HEv2 (High Effiency version 2)。LC は"ノーマルな"プロファイル。一般的なAACファイルはLCだ。もしも概ね64kbits以下でエンコードするなら（大体の目安。Neroは75- 80kbit程度を使う）、HEにしても良いだろう。このレベルのビットレートではその方が音が良い。同様に、さらに40kbits程度まで下げるなら HEv2を。

　ただし、これは理想の話。現実には、作成できるプロファイルに制限のあるAACエンコーダもある。また、256kbitのAAC-HEv2ファイルを作る理由も無い。そうしたものは256kbitのAAC-LCより音が良いわけでは無く、再生互換性の問題も生じるからだ。再生できるプロファイルに制限のあるデコーダもある（現時点では、まさにiTunes/iPodsだけがHE および HEv2プロファイルをサポートしていない。おそらく将来は対応するだろう。たぶん）。

　AACが定義するその他のプロファイルとしては、Main profileとLong Term Prediction (LTP)がある。これらはどちらも非常に面白いのだがツールはほとんど無い。ほぼFAACのみだ。

　主なAACエンコーダは三つある（他にもあるがこれらが一般的だ）。

Nero Digital Audio：リリースは2006年5月、フリー、素晴らしい音質、CLI。これ以上なにを望む？ nero.com/nerodigital/eng/Nero_Digital_Audio.htm
Coding Technology AAC Encoder：通称 'CT AAC' 、とか、あと似たような名前でも。音質的にNeroよりこちらを好む人が多いようだ。しかし、徹底的なテストはまだ存在しない。Winampなど少数のプログラムで使える。.dll用のCLIラッパーがオンラインで入手できる（ただし法的正当性は疑わしい）。
Quicktime：2004年初頭の時点では、Quicktime は最良のAAC encoderだった。その後の進化はおそらく非常に僅かなものだ。AAC-LCしか作成できず、HE や HEv2 のサポートは無い。
FAAC： Free AAC Codec。上の二つほど音は良く無いが、オープンソースで有名なAACエンコーダとしては唯一のものだ。かつては広く使われていたが、現在はそうでもない。main profiles と LTPをサポートしているダウンロードは： rarewares.org/aac.htm

Vorbis

　完全にパテントフリーのオーディオコデックで、音質はAACに肉薄する。各所のテストで一等と評価される事もある。'ふつうの'ビットレートでは違いはぎりぎり首の差だ。一般的に Ogg Vorbisと呼ばれるが、ここではオーディオコデックのみを指す Vorbisと呼ぶ。というのは他のコンテナで使う事もあるからだ。Oggはコンテナの名前で、一般的にはVorbisはこれに入っている事が多い（.ogg）。Vorbis は、Xiph organizationが他の変なコデックと一緒に開発している。一般的なコデックは一つも無い。

AC3

　DolbyスタジオによるATSC A/52 規格に準拠したもの。Dolby Digital AC3 は、Dolbyの、基本的にはロシー（＊ロスレスの逆＊）なオーディオコデックだ。彼らが長年開発している包括的なコデック群のひとつ。DVDと、大半の Digital TV放送でスタンダードに使われている。もしも音声がAC3 audio のファイルがあったら、通常は音声は素材のままと思って良いだろう。それが望み得る最善の音質だ。しかしながら、ほかのロシーコデックと比べると、非常に非効率的でディスクスペースを喰う。

DTS

　DTS (Digital Theater Systems) は極めて高ビットレートのオーディオコデックで、エンコードにおいては先ず使われない。DVD規格の公式コデックだが、対応は必須では無いのでDTSをデコードできないDVDプレイヤもある。巨大なもの (768 kbps) とむちゃむちゃ巨大なもの (1,536 kbps)の二通りがある。448kbitの 5.1 AC3 の方が768kbitの 5.1 DTSよりも音が良い事に注意。ひらたく云うと、ディスクスペースの無駄でしか無く、これファイルに突っ込むヤツは切腹すベシ。

参考
Xiph organization
パテントフリーとオープンソースを推進する団体。

[ 2007/02/03 00:00 ] ごみ箱　未分類 | TB(0) | CM(0)

MeGUIガイド_コンピュータの動画ファイル/字幕

原文：Computer movie files/Subtitles

コンピュータの動画ファイル/字幕

一般的な字幕フォーマット
1. SRT
2. SSA
3. ASS
4. VobSub
5. TTXT

一般的な字幕フォーマット

SRT

　SubRipText。しばらく前にフランス人が作った。非常に基本的なテキストベースの字幕フォーマット。シンプルな16進法の色付けとボールド、イタリックのフラグがある。再生側で別のフォントカラーやアウトラインを使うこともできる。字幕再生はVSFilterが前提となる。
　コードサンプル（thank you wikipedia）

1
00:00:20,000 --> 00:00:24,400
In connection with a dramatic increase
in crime in certain neighbourhoods,

SSA

　SubStationAlpha。パワフルなデジタル字幕フォーマットの必要性から開発された、かなり古いフォーマット。ファンサブで広く使われている。開発者がいなくなったため、開発は何年も前にSSAv4で停止しており、ASS（SSAv4+）が後を継いでいる。以下のように機能は豊富だ。

テキストにボールド、イタリック、フォントタイプ、サイズ、色、エンコード形式、アラインメント（非常に基本的なポジショニング）を指定出来る。
行単位の"style"指定。上記に加えてアウトラインの幅、影の深さ、アウトラインと影それぞれの色、そしてマージンを指定出来る。
基本的なカラオケエフェクト。
各行に個別にタイムスタンプと表示ポジションを指定できるため、スクリーンに複数の行を表示できる。

スタイルとコードのサンプル

Style: Default,Arial,40,16777215,16777215,16777215,-2147483640,-1,0,1,1,1,2,30,30,25,0,0
Dialogue: Marked=0,0:25:50.40,0:25:53.06,*Default,Comment,0000,0000,0000,,Kakarrot-o!!

ASS

　AdvancedSubStationAlpha。字幕フォーマットの形式としては SSAv4+とも。+は改良版を意味する。ほとんどの人はSSAとASSの違いを意識することは無い。と言うのはこのフォーマットのレンダラはフィルタもTextSub/VSFilterも同じだからだ。したがって、ASS固有のコードの入ったSSAscriptはTextSub/VSFilterで描画できる。結果的に、フォーマットの違いは解りにくい。SSA とASSのドキュメントはここにある。このフォーマットはanimeのファンサブによく使われる。SSAの開発者がいなくなった後も多くのファンサバーは開発の継続を望んだので、SSAv4+ が提案され、現在ではASSとなった。SSAに加えて以下の機能が使える。

テキストにアンダーライン、打ち消し線、枠線の幅と影の深さ（前述のスタイル指定限定）、エッジのぼかし、XY軸のフォントスケーリング、文字間隔の指定、テキストの回転、アウトラインと影の色（前述のスタイル指定限定）、透過、が指定出来る。
進行とともにスタイルが変化するフォント、コードのオーバーライド、動くテキスト、ピクセル精度の位置指定、テキストの起点指定、フェード、など実現する大量の機能。
カラオケはどういうわけか rebuffed（＊改善が無い？＊）。
新しい機能の為の、スタイルのアップデート。

　SSA/ASSドキュメントにはそのほかに、VobSub/VSFilterに実装されていない機能もいくつかある。例えばピクチャの埋め込み。実現すればテキスト字幕と画像字幕を同じフォーマットで扱えるようになるだろうが、実現はちょっと無理だろう。
スタイルとコードのサンプル

Style: Batou,Century Gothic,28,&H00C0C0C0,&H00000000,&H00000000,&H7F000000,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,0
Dialogue: 0,0:13:00.11,0:13:03.77,Batou,,0000,0000,0000,,Both our faces aren't meant for mirrors.

VobSub

　この名前はやって来た場所に由来するのだろう。VobSubとはDVDのVOB, Video Object fileから抽出したビットマップ字幕フォーマットの事だ。Gabestが作った字幕抽出に使うアプリケーションもVobSub（またはVSRip）と呼ぶ。VobSubは.idx file（開始点のタイムスタンプや色などの基本的な情報）と.sub file（字幕本体のビットマップデータ）からなる。テキストベースのSRT、SSA、ASS、TTXTとは異なり、VobSubsは画像なので通常はサイズが大きい。
インデックスコードとビットマップのサンプル

timestamp: 00:18:40:752, filepos: 0000aa000

TTXT

　MPEG-4 Timed Text。3GPP規格の字幕フォーマットがベースで非常に良く似ている。見た感じXMLキチガイ。面白いのは全ての時刻に行を定義しなければならないように見える事だ。つまり表示すべき字幕が無いところでもブランク行を入れておく必要がある。サンプルは以下の通り。

<TextSample sampleTime="00:03:35.980" xml:space="preserve">Please excuse me.</TextSample>

[ 2007/02/04 20:24 ] ごみ箱　未分類 | TB(0) | CM(0)

x264とは（MEncoder ドキュメント）

原文：http://www.mplayerhq.hu/DOCS/HTML/en/video-codecs.html#codec-x264）

7.1.3. x264

7.1.3.1. x264とは

　x264はH.264 映像ストリームを作成する為のライブラリです。100%完成してはいませんが、少なくともH.264の機能のうち品質に影響する機能はほとんど、なんらかの形でサポートしています。H.264規格には、先進的ではあっても、本質的に映像の品質とは全く無関係な機能が数多く定義されています。そうしたものの大半はまだx264には実装されていません。

エンコーダの機能

CAVLC/CABAC　→　(no)cabac
複数参照フレーム　→　frameref
Intra: フレーム内部では全てのマクロブロックタイプを利用可能(16x16、8x8、4x4、並びに全ての予測方式)。　→　partitions, (no)8x8dct
Inter P: Pフレームでは全てのパーティションが使える(最大 16x16 から最小 4x4まで)　→　partitions
Inter B: Bフレームでは16x16～8x8のマクロブロックが使える。スキップやダイレクトを含む。　→　partitions
レートコントロール:固定量子化（qp）、固定ビットレート、シングルパス・複数パスでのABR（平均ビットレート(crf, bitrate, pass)）、オプションでVBV( vbv_maxrate, vbv_bufsize, vbv_init)
シーンカット検出　→　scenecut
適応的Bフレーム配置　→　 (no)b_adapt
B フレームの参照フレーム化/任意のフレーム並べ替え　→　(no)b_pyramid, / 不詳
8x8 と 4x4サイズの適応空間軸変換　→　partitions
ロスレス・モード　→　qp=0
カスタム量子化マトリクス　→　cqm
スライス単位の平行エンコード　→　threads
インターレース保持　→　(no)interlaced

※補足

x264：アプリケーションが呼び出すライブラリ。x264.a（静的ライブラリ）など。複合化（デコード）能力を持たず、符号化（エンコード/コーディング）能力のみなので、コデックと言わすにコーダーと呼ぶ事もある。以下のアプリケーションはx264のAPIを呼び出す。
x264cli：x264専用のテスト用コマンドライン・アプリケーション。単にx264と言う事も多い。
ffmpeg：libavcodecのテスト用コマンドライン・アプリケーション。x264を呼び出せる。 H.264のデコーダはlibavcodecシリーズの中にある。
MEncoder：統合動画エンコード用コマンドライン・アプリケーション。x264, libavcodecを呼び出せる。
ffmpegX/MeGUI：統合動画エンコード用コマンドライン・アプリケーションのGUIラッパー。内部的にx264cliやMEncoderを呼び出して使う。

7.1.3.2. H.264とは

　H.264はITU と MPEGが共同で開発した新しいデジタルビデオコデックの名称です。正式名称は、～大変ややこしいのですが～、"ISO/IEC 14496-10" または "MPEG-4 Part 10"です。より一般的には"MPEG-4 AVC" とか、単に"AVC"とも呼ばれます。

　ま、なんと呼ぼうとH.264 は試す価値アリです。というのは、MPEG-4 ASPの品質を、5%～30%低いビットレートで実現できるからです。実際の結果は素材映像の内容とエンコーダの性能によります。しかしH.264はメリットだけではありません。: H.264のデコードは非常に高速なCPUと大量のメモリを要求するようです。実例を挙げると、1733 MHz Athlonで、DVD解像度の1500kbps H.264 ビデオの再生はCPUの約35% を使います。これに対し、DVD-解像度の1500kbps MPEG-4 ASP ビデオはCPUの10%です。これは、大半のユーザーにとってHD解像度の再生はほとんど問題外だという事です。また同時に、そこそこのDVD ripですら、2.0 GHz程度以下のプロセッサではぎくしゃくし得ると言う事です。

　少なくとも x264では、エンコードに必要な性能はMPEG-4 ASPと比べてそこまで酷くありません。例えば、1733 MHz Athlonでは一般的な DVD エンコードは 5-15fps程度で走ります。

　この文書ではH.264の詳細は説明しませんが、おおまかな概略はこちらのpdfにあります：The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions（pdf直リン。当ブログ内で一部試訳中、Doom9 -AVC情報の試訳も参照）。

7.1.3.3. H.264 videoをMPlayerで再生するには?

　MPlayer は libavcodecのH.264デコーダを使います。2004年7月以降、libavcodec は少なくとも最小限の H.264 デコードはできるようになっていて、それ以後も、サポートする機能と、CPU利用効率の両面で大きく進歩しています。常に最近のSVN checkoutを使うよう心がけて下さい。

　libavcodecの H.264デコード機能が最近進化したかどうかを手っ取り早く確かめるには、FFmpeg Subversion repository's web interface. をまめに見ておくと良いでしょう。

7.1.3.4. MEncoderとx264でvideoをエンコードするには?

　subversion クライアント（＊SVN＊）をインストールしてあれば、以下のコマンドで最新の x264 ソースコードがダウンロードできます。:

 svn co svn://svn.videolan.org/x264/trunk x264

　x264 のAPIに変更があれば、MPlayerのソースコードも変更されます。ですからMPlayerも常にSVN版を使うのが良いでしょう。おそらくこの状況は x264が「リリース」されたら変わると思います。それまでの間、x264は極めて「unstable」と考えるべきでしょう。というのは、プログラミング・インタフェイスが変更の対象になっているからです（＊参考記事：MEncoderの-x264encopts、大規模改訂＊）。

　x264のビルドとインストールはスタンダードな方法で出来ます。:

 ./configure && make && sudo make install

　これで libx264.a が /usr/local/lib に、そして x264.h が /usr/local/includeにインストールされます。
　（＊マルチスレッド・エンコードをするには./configure --enable-pthread。事前に./configure --helpでオプションを確認する事＊）
　x264 のライブラリとヘッダがスタンダードな場所にあれば、x264 サポート付きMPlayerのビルドは簡単です。通常通りに、

./configure && make && sudo make install

　これでMEncoderのconfigure スクリプトがx264を自動検出するハズです。

[ 2007/02/18 00:00 ] ごみ箱　MEncoder-Doc | TB(0) | CM(0)

bppとは

　BPPは1ピクセルあたりのbit数です。
　bpp = vbitrate * 1000 / (width * height * fps)

　基本的に静止画の色深度（表中の1.00～32.00）をそのまま持って来たもので、libavcodec mpeg-4やXvidの初期には画質指標として使われていた時期がありますが（表中のASPの経験則）、静止画と異なり、時間軸圧縮などで素材の動き成分が大きく影響する動画エンコードでは必ずしも「いくつなら良い」と言うものではありません。ですから数値的画質指標に使うのは無理があります。
　Xvidでは0.2あればだいたい大丈夫という感じでしたが、より性能の高いH.264/AVCは画質の幅が広く、電波ノイズやフィルムグレインを保持したいかどうかで評価はかなり違って来ると思います。

　しかしながら、BPPを揃えてエンコードしてやると、様々なH.264コデックやフロントエンド、また解像度やfpsの違いを超えて、画質を比較できる可能性があります。
　例えば、640x272@24fps, 1024kbpsと720x480@24fps, 2048kbpsは、SSIMを同列に比較できるという事になるハズです（あくまでもおおざっぱに、です）。
　また、H.264/AVCのプロトタイプであるH.26Lは720x480@1Mbpsで、"素材と見分けがつかない"という評価を出しています。これはBPP=0.10～0.13に相当しますから、そこを目指してみるのも面白いと思います。
　なお、Apple TVがやけにBPPが高いのは、再生できるビットレート上限をそのまま入れている為です。QuickTime系フロントエンドはシークの追従性を重視して、大量のI/IDRを挿入する傾向（最小GOP間隔が1～5秒）がありますから、厳密な画質比較の際はこれも考慮する必要がありそうです。

x264の手許常用値（一律1024kbps）

x264で良く見かける高画質値 (約2000kbps)

Apple TV

H.26Lの"素材と見分けがつかない"レベル

　※単位：kbps

		640x272 (シネスコ)		640x352 (16:9)		640x480 (4:3)		704x480 (無効領域抜き)		720x480 (D1)		960x540 (16:9)		1280x720 (16:9)		1920x1080 (16:9)
BPP	ASPの経験則	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps
32.00	(TrueColor)	133,560	166,950	172,842	216,053	235,694	294,617	259,263	324,079	265,156	331,445	397,733	497,167	707,082	883,852	1,590,934	1,988,667
24.00	(FullColor)	100,170	125,212	129,632	162,040	176,770	220,963	194,447	243,059	198,867	248,583	298,300	372,875	530,311	662,889	1,193,200	1,491,500
16.00	(HighColor)	66,780	83,475	86,421	108,026	117,847	147,309	129,632	162,040	132,578	165,722	198,867	248,583	353,541	441,926	795,467	994,334
8.00	(256Color)	33,390	41,737	43,211	54,013	58,923	73,654	64,816	81,020	66,289	82,861	99,433	124,292	176,770	220,963	397,733	497,167
1.00	(白黒二値)	4,174	5,217	5,401	6,752	7,365	9,207	8,102	10,127	8,286	10,358	12,429	15,536	22,096	27,620	49,717	62,146

0.50		2,087	2,609	2,701	3,376	3,683	4,603	4,051	5,064	4,143	5,179	6,215	7,768	11,048	13,810	24,858	31,073
0.40		1,669	2,087	2,161	2,701	2,946	3,683	3,241	4,051	3,314	4,143	4,972	6,215	8,839	11,048	19,887	24,858
0.39		1,628	2,035	2,107	2,633	2,873	3,591	3,160	3,950	3,232	4,039	4,847	6,059	8,618	10,772	19,390	24,237
0.38		1,586	1,983	2,053	2,566	2,799	3,499	3,079	3,848	3,149	3,936	4,723	5,904	8,397	10,496	18,892	23,615
0.37		1,544	1,930	1,998	2,498	2,725	3,407	2,998	3,747	3,066	3,832	4,599	5,748	8,176	10,220	18,395	22,994
0.36		1,503	1,878	1,944	2,431	2,652	3,314	2,917	3,646	2,983	3,729	4,475	5,593	7,955	9,943	17,898	22,373
0.35		1,461	1,826	1,890	2,363	2,578	3,222	2,836	3,545	2,900	3,625	4,350	5,438	7,734	9,667	17,401	21,751
0.34		1,419	1,774	1,836	2,296	2,504	3,130	2,755	3,443	2,817	3,522	4,226	5,282	7,513	9,391	16,904	21,130
0.33		1,377	1,722	1,782	2,228	2,431	3,038	2,674	3,342	2,734	3,418	4,102	5,127	7,292	9,115	16,407	20,508
0.32		1,336	1,669	1,728	2,161	2,357	2,946	2,593	3,241	2,652	3,314	3,977	4,972	7,071	8,839	15,909	19,887
0.31		1,294	1,617	1,674	2,093	2,283	2,854	2,512	3,140	2,569	3,211	3,853	4,816	6,850	8,562	15,412	19,265
0.30	無意味	1,252	1,565	1,620	2,025	2,210	2,762	2,431	3,038	2,486	3,107	3,729	4,661	6,629	8,286	14,915	18,644
0.29		1,210	1,513	1,566	1,958	2,136	2,670	2,350	2,937	2,403	3,004	3,604	4,506	6,408	8,010	14,418	18,022
0.28		1,169	1,461	1,512	1,890	2,062	2,578	2,269	2,836	2,320	2,900	3,480	4,350	6,187	7,734	13,921	17,401
0.27		1,127	1,409	1,458	1,823	1,989	2,486	2,188	2,734	2,237	2,797	3,356	4,195	5,966	7,458	13,424	16,779
0.26		1,085	1,356	1,404	1,755	1,915	2,394	2,107	2,633	2,154	2,693	3,232	4,039	5,745	7,181	12,926	16,158
0.25	非常に良い	1,043	1,304	1,350	1,688	1,841	2,302	2,025	2,532	2,072	2,589	3,107	3,884	5,524	6,905	12,429	15,536
0.24		1,002	1,252	1,296	1,620	1,768	2,210	1,944	2,431	1,989	2,486	2,983	3,729	5,303	6,629	11,932	14,915
0.23		960	1,200	1,242	1,553	1,694	2,118	1,863	2,329	1,906	2,382	2,859	3,573	5,082	6,353	11,435	14,294
0.22		918	1,148	1,188	1,485	1,620	2,025	1,782	2,228	1,823	2,279	2,734	3,418	4,861	6,076	10,938	13,672
0.21		876	1,096	1,134	1,418	1,547	1,933	1,701	2,127	1,740	2,175	2,610	3,263	4,640	5,800	10,441	13,051
0.20	充分	835	1,043	1,080	1,350	1,473	1,841	1,620	2,025	1,657	2,072	2,486	3,107	4,419	5,524	9,943	12,429
0.19		793	991	1,026	1,283	1,399	1,749	1,539	1,924	1,574	1,968	2,362	2,952	4,198	5,248	9,446	11,808
0.18		751	939	972	1,215	1,326	1,657	1,458	1,823	1,492	1,864	2,237	2,797	3,977	4,972	8,949	11,186
0.17		710	887	918	1,148	1,252	1,565	1,377	1,722	1,409	1,761	2,113	2,641	3,756	4,695	8,452	10,565
0.16		668	835	864	1,080	1,178	1,473	1,296	1,620	1,326	1,657	1,989	2,486	3,535	4,419	7,955	9,943
0.15	低画質	626	783	810	1,013	1,105	1,381	1,215	1,519	1,243	1,554	1,864	2,330	3,314	4,143	7,458	9,322
0.14		584	730	756	945	1,031	1,289	1,134	1,418	1,160	1,450	1,740	2,175	3,093	3,867	6,960	8,700
0.13		543	678	702	878	958	1,197	1,053	1,317	1,077	1,346	1,616	2,020	2,873	3,591	6,463	8,079
0.12		501	626	648	810	884	1,105	972	1,215	994	1,243	1,492	1,864	2,652	3,314	5,966	7,458
0.11		459	574	594	743	810	1,013	891	1,114	911	1,139	1,367	1,709	2,431	3,038	5,469	6,836
0.10	ヤメとけ	417	522	540	675	737	921	810	1,013	829	1,036	1,243	1,554	2,210	2,762	4,972	6,215
0.09		376	470	486	608	663	829	729	911	746	932	1,119	1,398	1,989	2,486	4,475	5,593
0.08		334	417	432	540	589	737	648	810	663	829	994	1,243	1,768	2,210	3,977	4,972
0.07		292	365	378	473	516	644	567	709	580	725	870	1,088	1,547	1,933	3,480	4,350
0.06		250	313	324	405	442	552	486	608	497	621	746	932	1,326	1,657	2,983	3,729
0.05		209	261	270	338	368	460	405	506	414	518	621	777	1,105	1,381	2,486	3,107
0.04		167	209	216	270	295	368	324	405	331	414	497	621	884	1,105	1,989	2,486
0.03		125	157	162	203	221	276	243	304	249	311	373	466	663	829	1,492	1,864
0.02		83	104	108	135	147	184	162	203	166	207	249	311	442	552	994	1,243
0.01		42	52	54	68	74	92	81	101	83	104	124	155	221	276	497	621
0.00		0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

参考リンク

改訂履歴

2006/12/07：初出
2007/04/04：全面書き換え。HD解像度・Apple TV・H24Lを追加。

[ 2007/04/04 00:00 ] 動画　動画全般 | TB(0) | CM(0)

mp4box(gpac)とは

原文：(GPAC) About GPAC

　GPACは、MPEG-4 Systems standard (ISO/IEC 14496-1)に基づくマルチメディア・フレームワークです(*1)。ANSI Cでスクラッチで書き起こされています。

　開発主旨は、MPEG-4 Systems レファレンス・ソフトウェア（IM1の名前でISO/IEC 14496-5で配布されています）の代わりに使える、クリーンで（できるだけ多くの人が読めるという意味です）、小さく、フレキシブルなソフトの提供です。MPEG-4レファレンス・ソフトウェアは、実際非常に巨大なソフトで、実用性よりは規格そのものの検証に主眼があります。

　この主旨に基づき開発作業は、最新のマルチメディア規格～SVG/SMIL, VRML, X3D, SWF, 3GPP(2) tools, など～を単一のフレームワークに実装する方向で調査してきました。VRML97と、X3D規格の相当部分は既にGPACに実装済みです。また、SVG (SVG Tiny 1.2)の一部をサポートし、Macromedia Flashのサポートも試験的実装の段階です。

　GPACはC（ほぼ100%ANSI）で書かれています。これは（組み込み機器やDSPへの）ポータビリティ（＊移植性・可搬性＊）の為で、メモリーへのフットプリント（＊メモリ使用量というほどの意味らしい＊）ができるだけ小さくなるように心がけています。

　Version 0.4.0以降のGPACは、GNU Lesser General Public Licenseでライセンスされています。それ以前のバージョンはGNU General Public Licenseです。

　現在にリリース版（GPAC 0.4.2）は、既にMPEG-4 standardを非常に広くカヴァーしています。また、以下に関してはまずまずサポートしています。VRML/X3D、W3C SVG Tiny 1.2、3GPP、大半の2D MPEG-4 Player（先進的で勢いがあり、広く一般に入手できるもの）、勃興しつつある3D player。サポート済みツールの詳細は、features のページを見て下さい。

　他にもGPACはMPEG-4 Systemの encoder/multiplexerの機能を持っています(*2)。MP4と3GPP(2)ファイルの、パブリッシングとコンテンツ・ディストビューション用ツール、そしてscene description（MPEG4/VRML/X3D コンバータ、SWF/MPEG-4、などなど）。

　GPACは現在、以下のプラットフォームで動きます。

Windows
Linux platforms
WindowsCE (SmartPhone/PocketPC 2002/2003) (OpenGL-ES経由の3Dレンダリング)
組み込みlinux (familiar 8 + GPE)

【所感】

(*1)MPEG-4 Systems standard (ISO/IEC 14496-1)に基づくマルチメディア・フレームワークです。

　これがGPACの本分。フレームワークと言うのは良く解らないが、なんでもイチからCでゴリゴリ書くより、必要に応じて呼び出せるもん作っておいたほうがいいでしょというようなもんらしい。ライブラリとどう違うのか良く解らないが「集合」かな？KTC眼鏡レンチセット、みてーな。プログラマではないので深入りしない。

　MPEG-4 Systemsとはなんぞやということになると、鬼のように幅広く、イメージしにくい。　
　放送・通信のみならず、インタラクティビティという点ではゲーム（的なもの）も包含しうる。
　ってもオイラにイメージが湧くのはそのくらいで、ぜってーその先がある。

　その他GPACプロジェクトのドキュメントを読んでも読んでも「なんだかスゴそうだ」という印象以上のもんが持てないのは、ベースがQuickTime（時間軸を基軸にデジタルデータを管理する考え方、テクノロジーというよりプリンシパル）である事と無縁ではないだろう。

　MPEG-4規格自体が、純粋に「デジタルで動画を扱う事」を目指したMPEG-1/2とは根本的に性質が異なる。

(*2)他にもGPACはMPEG-4 Systemの encoder/multiplexerの機能を持っています。

　だから、この項は２番目に来る。
　mp4boxは動画成分である映像、音声、字幕などのmultiplexer（多重化（してMP4コンテナに突っ込む））を担当する。
　encoderとは主に、VRMLなどの「シーン記述言語」で書かれたテキストファイルをMP4形式に「エンコード」するものだと思う。

【ソースコード内のmanがD&Dで開けた】

$ man /Users/USERNAME/gpac/doc/man/gpac.1

NAME
       GPAC - MPEG-4 Systems Framework and Software Development Kit

DESCRIPTION
       GPAC  stands (does it ?) for GPAC Project on Advanced Content. It is an
       implementation of the MPEG-4 Systems standard written in ANSI  C.  GPAC
       provides  tools  for  media playback, vector graphics and 3D rendering,
       MPEG-4 authoring and distribution.  This man page is  about  configura-
       tion of the GPAC framework version 0.4.3.

INTRODUCTION
       Some applications in the GPAC framework use a configuration file shared
       among modules and reloadable at run time. This file is located  in  the
       user home directory and called ".gpacrc".

       The  configuration  file is based on the win32 .ini file model, ordered
       by sections and keys.

       A section is declared as [SectionName] , a  key  is  declared  as  key-
       Name=value  ,  the  key  value is not interpreted and always handled as
       ASCII text. Plugins may use the configuration file as  well  (to  avoid
       multiple files).

       Note  on  plugin names: Plugin names as given in the configuration file
       are names exported by each interface  and  not  name  of  the  physical
       library  file  (.dll/.so  ...).   The physical file name can however be
       used to identify a plugin, it will be replaced by the interface name if
       the plugin was successfully loaded.

【~/gpac/applicationsの内容】

そうすっとgpacアプリケーションの一覧がそれなりに埋まる。　

名前	種類	メモ
CVS	folder
GPAX	folder	GPAC ActiveX control, IE only
Makefile	file
generators	folder
mp42avi	folder	NAME MP42AVI - MPEG-4 BIFS to Video converter SYNOPSIS MP42AVI [options] file DESCRIPTION MP42AVI is a tool to convert a pure MPEG-4 BIFS presentation (no audio, no image, no video) to an uncompressed sequence of images or an uncom- pressed RGB avi file. Pages du manuel Linux
mp4box	folder	MPEG-4, 3GP, 3GP2コンテントの作成と配布に必要な機能を一つにまとめたツール。 NAME MP4Box - MPEG-4 Systems Toolbox SYNOPSIS MP4Box [options] file [options] DESCRIPTION MP4Box is a multi-purpose command line tool to create and edit MPEG-4 Systems presentations and manipulate ISO-media files (MP4, 3GP, MOV). MP4Box supports file conversion from various raw formats and IsoMe- dia/AVI/MPEG-PS/OGG containers, file hinting for RTP streaming for QuickTime compatible streaming servers, file interleaving, file frag- mentation and track extraction. MP4Box also provides dump tools used to inspect file layout, RTP hint tracks, SDP information, scene composition. It may also be used to con- vert to and from BT/XMT-A/VRML/X3D. MP4Box also features MPEG-4 Systems encoders and decoders for BIFS and OD tools. MP4Box doesn't expect any particular order in options at prompt.
mp4client	folder	NAME MP4Client - GPAC MPEG-4 command-line Player SYNOPSIS MP4Client [options] [file] DESCRIPTION MP4Client is GPAC command-line player. It supports all GPAC playback features (2D and 3D support, local playback, RTP streaming, HTTP fast- start, many audio and video codecs ...). MP4Client also supports visual extraction to BMP, RAW or AVI (no compression, no audio).
osmo4_sym	folder	GPAC Players
osmo4_w32	folder	GPAC Players
osmo4_wce	folder	GPAC Players
osmo4_wx	folder	GPAC Players
osmophone	folder	GPAC Players
osmozilla	folder	GPAC plugin for mozilla-based browsers
standalone2drender	folder
testapps	folder
v4studio	folder

[ 2007/04/29 23:26 ] 他ツール　mp4box(gpac) | TB(0) | CM(0)

7.1.3.1. x264ってなんですか？

　x264 はH.264 映像ストリームを作成する為のライブラリです。100%完成してはいませんが、少なくともH.264の機能のなかで品質に影響の大きな機能はほとんど、なんらかの形でサポートしています。H.264規格の先進的な機能の中には、本質的に映像の品質とは全く無関係なものたくさん定義されています。そうしたものの多くは、まだx264には実装されていません。

　エンコーダの機能

CAVLC/CABAC
複数参照フレーム
イントラ：全マクロブロックタイプが利用可能（16x16、8x8、4x4に全ての予測方式が可能）。
インターP：全パーティションが利用可能（16x16 から4x4まで）
インターB：16x16～8x8のパーティションが利用可能（スキップ / ダイレクトを含む）。
レートコントロール：固定量子化（qp）、固定ビットレート、シングルまたはマルチパスABR、オプションでVBV。
シーンカット検出
適応的Bフレーム
Bフレームの参照フレーム化 / 任意のフレーム並べ替え
8x8 と 4x4 サイズの適応空間軸変換
ロスレスモード
カスタム量子化マトリクス
複数スライスの平行エンコード
インターレース保持

原文

http://www.mplayerhq.hu/DOCS/HTML/en/video-codecs.html#codec-x264

7.1.3.1. What is x264?

x264 is a library for creating H.264 video streams. It is not 100% complete, but currently it has at least some kind of support for most of the H.264 features which impact quality. There are also many advanced features in the H.264 specification which have nothing to do with video quality per se; many of these are not yet implemented in x264.

Encoder features

CAVLC/CABAC
Multi-references
Intra: all macroblock types (16x16, 8x8, and 4x4 with all predictions)
Inter P: all partitions (from 16x16 down to 4x4)
Inter B: partitions from 16x16 down to 8x8 (including SKIP/DIRECT)
Ratecontrol: constant quantizer, constant bitrate, single or multipass ABR, optional VBV
Scene cut detection
Adaptive B-frame placement
B-frames as references / arbitrary frame order
8x8 and 4x4 adaptive spatial transform
Lossless mode
Custom quantization matrices
Parallel encoding of multiple slices
Interlacing

[ 2007/08/04 07:13 ] MEncoder　Doc | TB(0) | CM(0)

7.1.3.2. H.264ってなんですか?

　H.264 は ITU と MPEG が共同で開発した新しいデジタルビデオコデックの名称です。大変ややこしい事に、“ISO/IEC 14496-10“ とか “MPEG-4 Part 10“ などとも言います。一般的には “MPEG-4 AVC“ とか、単に “AVC“ とも呼ばれます。

　なんと呼ぼうと H.264 は一般的にMPEG-4 ASPの品質を 5%～30%低いビットレートで実現できますから、試す価値はあります。実際の結果は素材映像の内容とエンコーダの性能によります。しかしH.264はメリットだけではありません。デコードには極めて高速なCPUと大量のメモリが必要なようです。実例を挙げると、1733 MHzのAthlonで、DVD解像度の1500kbps H.264 ビデオの再生はCPUの約35% を使います。これに対してDVD-解像度の1500kbps MPEG-4 ASP ビデオはCPUの10%しか使いません。これは大半のユーザーにとってHD解像度の再生はほとんど問題外だという事です。また同時に、そこそこのDVD ripですら2.0 GHz程度以下のプロセッサではぎくしゃくする事があると言う事でもあります。

　エンコードに必要な性能は、少なくとも x264ではそこまで酷くありません。例えば、1733 MHzの Athlon では一般的な DVD エンコードは 5-15fps程度で走ります。

　この文書ではH.264の詳細は説明しませんが、おおまかな概略はこちらのpdfにあります： The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions.

　＊当ブログ内に一部試訳あり、Doom9-AVC情報試訳も参照。

原文

http://www.mplayerhq.hu/DOCS/HTML/en/video-codecs.html#codec-h264-whatis

H.264 is one name for a new digital video codec jointly developed by the ITU and MPEG. It can also be correctly referred to by the cumbersome names of “ISO/IEC 14496-10“ or “MPEG-4 Part 10“. More frequently, it is referred to as “MPEG-4 AVC“ or just “AVC“.

Whatever you call it, H.264 may be worth trying because it can typically match the quality of MPEG-4 ASP with 5%-30% less bitrate. Actual results will depend on both the source material and the encoder. The gains from using H.264 do not come for free: Decoding H.264 streams seems to have steep CPU and memory requirements. For instance, on a 1733 MHz Athlon, a DVD-resolution 1500kbps H.264 video requires around 35% CPU to decode. By comparison, decoding a DVD-resolution 1500kbps MPEG-4 ASP stream requires around 10% CPU. This means that decoding high-definition streams is almost out of the question for most users. It also means that even a decent DVD rip may sometimes stutter on processors slower than 2.0 GHz or so.

At least with x264, encoding requirements are not much worse than what you are used to with MPEG-4 ASP. For instance, on a 1733 MHz Athlon a typical DVD encode would run at 5-15fps.

This document is not intended to explain the details of H.264, but if you are interested in a brief overview, you may want to read The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions.

[ 2007/08/04 07:13 ] MEncoder　Doc | TB(0) | CM(0)

| ホーム |
Page Top↑

Index

・表紙
・全記事一覧
・ここについて
・人気記事
・x264関連
・ageha更新終了の辞

　2007/11/15を以て当ブログは更新を停止しました。
　記事は全てこのままですが、基本的に内容はOut of dateとお考え下さい。
　→Next。

-G-

-A-

タグ検索

カテゴリー