ageha was here

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

ホーム > アーカイブ－ 2007年01月

threads=<1-16>

　x264 rev 607でマルチスレッドの方式が変更され、速度が改善した。手許（PowerPC G5 2Ghzx2）では、2パスで概ね3時間強かかっていた24分アニメが2時間半程度になった。こうかはばつぐんだ。

■VGA （1024kbps, 640x480）

タイトル	FPS1	FPS2	FPS	Avg QP (P)	PSNR (Grobal)
threads=2平均（57件）	14.42	5.26	3.85	20.68	45.25
threads=4平均（12件）	18.69	6.42	4.75	19.02	46.83

　概ね誰にでもお奨めできそう。
　以前のrevでは threads=4は「まぁ、数秒くらい速く終わるかな？」程度だったので大進化。表のデータは実写もアニメも映画もテレビ番組もいっしょくたなので個別に見れば、24fpsで吐いた映画とアニメはもっと早い。
　Zero1氏（Turion 64 x2 TL-60 (2x2.0GHz)）のコメントでも、マルチスレッドが高速化し画質劣化が非常に少なくなった、お奨め。との事。もともと早いx86ではどこまでいくんだろう？

Changeset 607（06/12/16）
新しいスレッド方式：

各フレームをスライスに分割していたのを、複数参照フレームの併行処理に変更。
速度改善、スレッディングのビットレート・ペナルティ緩和。
副次効果：

フレームの再エンコードはもうできないので、スレッデッド・シーンカット検出はpre-me pass（＊動き予測の前のパス？＊）でやらなければならない。これは高速だが、精度は落ちる。
CPU数より多くのthread数を使っても良い。--threads=autoはcpus*1.5を使うようにアップデートされた。
他にレートコントロールのマイナーチェンジ。

　rev 607以前の推奨はthreads=CPUコア数だったが、これで4コア以上のCPU（2007後半以降？）が出て来ても対応できるだろう。Cell向け最適化もなんとかならんか。

なお、CPU利用効率も大きく向上した。-vfチェインにmcdeintのようなボトルネックを使わなければ、概ねCPUメータが振り切れる。以前は振り切れる瞬間が無かった。スレッド数は最大5になる事が多い。この点、x264はApple-H.264に劣っていたが、だいぶ差が詰まった。2 パスでの画質はもとより勝負にならない。

070105追記： threadsは最大16

PowerPC G5 (2GHzx2)の場合

akupenguin氏は「16 threadsでは画質劣化が最大1%になるが、まぁ常用してもいいんじゃないの」と言っている。ように読めた^^;。
そこで常用設定でthreadsだけ変更して計測してみた。プロセスの優先順位指定とかは解ってないので誤差が出る筈です。てゆうか出てます。
素材は約１分半のアニメのオープニング（例に拠ってケロロ軍曹）、1stはturbo=1。

■CPU:PowerPC G5 (2Ghzx2)

threads	Frames	Sec_1	Sec_2	Fps_1	Fps_2	PSNR	SSIM	Fps_1_diff	Fps_2_diff	PSNR_diff	SSIM_diff
1	3157	360	1124	8.77	2.81	40.244	0.9775031	-	-	-	-
2	3157	228	759	13.85	4.16	40.246	0.9775451	5.08	1.35	0.002	0.0000420
4	3157	240	649	13.15	4.86	40.240	0.9775352	4.38	2.06	-0.004	0.0000321
16	3157	236	633	13.38	4.99	40.213	0.9774428	4.61	2.18	-0.031	-0.0000603

※結論：
　少なくともPowerPCx2で1stにturbo=1を使う場合は、1stはthreads= 2、2ndはthreads=16が最速になる。

threads	Frames	Sec_1	Sec_2	Fps_1	Fps_2	PSNR	SSIM	Fps_1_diff	Fps_2_diff	PSNR_diff	SSIM_diff
2/16	3157	231	652	13.67	4.84	40.223	0.9774683	4.90	2.03	-0.021	-0.0000348

　ただし、凄い勢いでメニイコア最適化が進む事は確実だから、1stと2ndでthreadsを変えるのは後々ちょいと根性が要るだろう。最終的な客観画質の低下も緩和しているがもとから無視しても問題ない範囲の話だ。threads=2/16かthreads=16/16かの選択はちょっと悩ましい。2ndの速度がやや落ちているのは誤差なのか、それとも statsの内容がthreads=2に最適化してたりすんのだろうか。
　

※画質劣化：PSNRは0.2dB違えば通常は充分に目で見て解る違いが出ると言う。もちろんPSNRは万能では無く、高くても画質に不満を感じるケースはある。しかしながら、主観画質は電気いっこつけるだけで随分と変わるものだ。モニタを変えればがっつり調整しない限りまず別モノになる（手許ではしてないから左右のモニタで色味がかなり違う）。数値的画質指標では少なくとも視聴環境と感性の影響を排除できるから、ネットの向こう側で通用する公算は「手許では」より高い。

　
※1st passでthreads =2が最高速となる理由は良く解らない。
　2ndがリニアに高速化しているのに比べて非常に目立つ。
　scenecutアルゴリズムはthreads=2で勝手に--pre-scenecut、すなわち「各フレームをスライスに分割していたのを、複数参照フレームの併行処理に変更」に切り替わる筈なので、少なくともオプション上はthreads=2だけが早い理由は無い。
　turbo =1をベタなオプションで書くとこうなる。

subq=2:frameref=1:partitions=p8x8,i8x8,i4x4:

　しかしながら、turbo=1に変えて上記を使い、1st, 2ndともthreads=2でエンコードしたところ、両パスとも低速化した上に、さらに最終的なPSNR、SSIMも悪化した。下手に弄らないほうが良さそうだ。
　この結果から、1stと2ndでは上記以外にも実際の処理内容が異なると思われる。例えば2ndはある程度の処理を 1stのstatsを信用して省いているとか。

4 core Xeon 5160の場合

　akupenguin 氏によると4 core Xeon 5160では上記のような不連続は無く、threadsを増やせばほぼリニアに高速化する。turboオプションの無いx264cliではオールラウンドに threads=16で良さそうだ。

x264 revision 610 - sliceless threading - what's new#3（Doom9）
（スレッドを増やすと若干の画質低下になるというのはどうなったのか？に対して）
今でもそう。だが以前ほどではない。したがって"reduces the bitrate penalty"（ビットレートペナルティの低減）。
Code:
cpu: 4 core Xeon 5160

threads speed psnr loss 
 r606 r611 r606 r611
 1: 1.000x 1.000x 0.000 0.000
 2: 1.540x 1.739x -0.036 -0.004
 3: 1.838x 2.384x -0.065 -0.002
 4: 2.043x 3.224x -0.077 -0.005
 5: 2.028x 3.512x -0.110 -0.009
 6: 2.034x 3.629x -0.132 -0.009
 7: 1.988x 3.680x -0.151 -0.015
 8: 1.953x 3.702x -0.188 -0.017
 9: 2.016x 3.729x -0.210 -0.020
10: 1.995x 3.742x -0.233 -0.031
11: 1.954x 3.749x -0.255 -0.030
12: 1.909x 3.765x -0.268 -0.040
13: 1.895x 3.770x -0.286 -0.045
14: 1.936x 3.759x -0.313 -0.046
15: 1.897x 3.781x -0.335 -0.045
16: 1.845x 3.765x -0.349 -0.046

scaling efficiency (speed / #cores):
r606: 51%
r611: 94%
上記はLinuxでの計測。Windowsでは効果的なスレッド同期を実現するのにたくさんの問題があった。そして現在に至るもパフォーマンスはここまでは良く無いかも知れない。

　なんか16だけちょいと落ちてるけんども、これこそメニイコア最適化であっちゅーまだべな。

Windows固有の問題？

　なお、Windowsでの効果的なスレッド同期（ってなんだかわかりませんが）の問題だが、引用元のスレにはwin32threadsとかpthreadsの単語が散見される。linux系とWin系ではスレッドに必要なナニカの挙動が異なるらしい。x264cliにwin固有のスレッド方式を組み込んでしまえばよさそうなものだが、それやるとmencoderで受け付けないとかで、akupenguin氏はx264ライブラリでそこまでwinに特化できないと言っている、あたりまで読んだ。ということで、実は引用元のスレはあらかたがx264.exeでの動作検証と、MeGUIへの実装方法の話で埋まっている。Sharktooth氏を筆頭に奮闘が続いている様子なので、winでx264cli、特にMeGUIな方は是非ご一読されたい（そしてどうなってんのかどっかに書いて下さい（⇒MasaHeroの日記：スレッド処理、スレッドに関するメモ））。

070117追記：MEncoderマニュアル改訂

MEncoderマニュアルの改訂に気が付きました。

threads=<0−16>：平行処理でエンコード

default=1
複数CPUでパラレル・エンコードをするためにスレッドを分散。
圧縮品質に僅かな悪影響がある。
0 または ’auto’でx264はCPU数を検出し、適切なthread数を自動選択する。

MEncoder dev-SVN-r21948-4.0.1 (C) 2000-2006 MPlayer Team
x264 core:54 svn-618M

Man/CODEC固有オプション/-x264encopts/threadsは改訂済みです。

スポンサーサイト

[ 2007/01/05 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(2)

エンコード十戒

きれいな絵を得ようとするより、うまい設定を組もうとするべきである。
その絵の前の絵、その絵の次に来る絵の動きやポーズをしっかり捉えるまでは、GOP関連設定を終わってはならない。
1bitも無駄にしないこと。どのbitも姿勢、雰囲気、動作、あるいは性格を表現できるのだ。
これが最高だと確信出来るまで、他にどんなイメージも持たないこと。あなたの使命はスクリーン上にもっとも作り手の意思に忠実なイメージを展開することだ。
オプション過剰にならないこと。
各ピクセルは常に、空間を動く、モーションベクトルに作用されたかたまりとして考えられなければならない。
あなたに欠けているものを与えてくれる人々に頼るべきである。
知識を具体化するために物事を学ぶのではなく、独創的に応用するために、原理から学ぶべきである。
常に量という概念を念頭に置くこと。
注意深く！しかし臆病になってはならない。

参考
■[アニメ]大塚康生の「クリーンアップ十戒」（愛・蔵太の少し調べて書く日記：2007年1月10日）

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

あたらしいテレビのはなし

　もしも2011年になってもIP放送から収益を上げるしくみが出来上がっていなければ、この国の映像産業はジリ貧になってしまうのです。
　なぜならば！
　日本のコンテントの中核をなすテレビ業界の喫緊の課題は産業構造のリストラクチャなのだからです。

前世紀

　この「放送局が"情報の関所"となって収入を得るしくみ」は在京キー局を頂点とする寡占体制であるのです、放送免許制で保護されているのです。つまり競争が無いのです。TV以上の宣伝媒体が無ければTV局は強気に出れるので、金を払う側（CMを出すスポンサー）がエラいとは限らないのです。視聴者は「関所の人が選んだ情報」に「関所の人が選んだ時間」にしか接する機会が無いのです。人間は取得した情報に基づいて思想を形成し、行動を決定するので、情報の結節点に位置するTV局が社会に占める比重は高かったのです。ここでは深入りしませんが、情報寡占の弊害は報道において最も顕著に出るのです。

2005年まで

　PCとNetの能力は、視聴者同士が映像を直にやりとりできるまでになったのです。価値のある情報（番組）を視聴者が決め、視聴者同士でやりとりできるのです。ひらたく言うと、情報の民主化なのです。

　著作権だ海賊行為だと言ったところで、それが楽しければ人間はやるものだし、一度普及してしまえば倫理のほうが変化するのです。その証拠にWinnyによる情報流出はいまだに後を絶たないのです。より自由な情報流通への需要が確立した以上、それを育て、そこからテラ銭を取るしくみを制したものが次世代の情報結節点を握るのです。
　CM に関しては、企業が自前のwebサイトやweb広告で消費者にダイレクトにアピールするようになり、相対的にTVCMの重みが低下したのです。これはネット慣れした層を相手にする業種、コアな客筋への依存度が高い業種ほど顕著だったと思われるのです。余談ながら、この時期にはゲーム脳が盛んに報道されたのです。
　この段階では番組製作社におかねがまわるしくみが無いのですが、彼らがTV局を迂回して視聴者に番組を電送し、収益に繋げ、次回作の制作資金を回収する手段を持てば、制作者サイドの著作権概念も変化する筈なのです。

　ようするに、新しい情報流通回路が、新しい映像消費形態を生み出したと言う事なのです。そしてこの時点では、既存の流通経路はまだ新しいビジネスチャンスを活かせていないのです。
　この時点でTV事業者が為すべきだったのは、CMのCMや、TVCMにURL表示制限をかけるなどの「ジリ貧感倍増政策」では無く、「好きな場所で、好きな時に、好きな番組を、見る」というみんなが味わってしまった楽しさにどう適応するかを考える事だったのです。なぜならば！視聴者がタダで見てるのは既存のTV放送だって同じことなのだから。

2006年

　ジャパネットたかたの番組からそのまま購入画面へ進む。ニュースの画面からそのまま企業のニュースリリースへ飛ぶ。好きな映画を好きな時に好きな場所から呼び出す。そんなの10年以上前のAT&TのCMにも及びませんが、国内でそれに向けて具体的な一歩を踏み出したのは彼らが最初だったのです。

　そこを目指して一歩でも進まなければ、TV局は情報革命を生き残る事はできないのです。自分の理解では情報革命とは情報再配分構造のリストラクチャなのです。守りたい使命感も感情的な反発も、実のある行動がなければ支持されないのです。

　ホリエモンや村上ファンドがあのような形で退場を余儀なくされた以上、もはや後に続くチャレンジャーが出る事は期待し難いのです。

　まじめな話、放送業界のスタンスは既に2000年の時点でボロクソに言われていたのです。

世界情報通信サミット2000：セッション1 -「モバイルとデジタル家電が拓く新ビジネス」
※ 太字オレ。勝手に縮めてあります。発言者のみなさんすいません。
池田信夫
このインターネットから孤立した方式でデジタル放送が始まると、日本は世界から取り残されるでしょう。
古川　享
「古川君、インターネットのような邪悪なものを放送の世界に持ち込まないでくれたまえ」とまで発言された方もおりました。
池田　信夫
日本の放送業界の既得権益にしがみつく排他的な態度は、かつての金融業界を思わせます。
鈴木　寛
放送と通信の融合に遅れたら、折角、携帯でかなり、盛り返した日本の情報化がまた、１０年遅れてしまうと思います。
中村　伊知哉
鈴木さんは10年と控え目におっしゃったけど、テレビとインターネットの結合に失敗したら、日本の情報化は死ぬと思います。

日本のコンテントの中核をなすテレビ番組をインターネットで流れるようにすること。使いやすい電波帯をテレビ携帯PCなどあらゆる端末で使える太いデジタル回線にすること。

こういう筋を形づくるのは「政治」の役割だと思うんですが。「行政」が利害調整をしているうちはスカッと打開できない。どっちもダメなら「ネット」の力、かな？

　たぶん、現在に至るまでずっとそのままなのでしょう。
　政治的なイニシアティブでもあればまた違ったのでしょうが、日本にはアル・ゴアもニュート・ギングリッヂも居ないのです（何年前の政治家だよ）。いやそもそも居ればホリエモンは逮捕されていたでしょうか。

まとめ

情報の結節点の上に築かれた既存のTV体制は、情報の民主化を妨げ、社会全体に非効率を押し付けている。

続く

[ 2007/01/10 00:00 ] INBOX　未分類 | TB(0) | CM(0)

続・あたらしいテレビのはなし

～おねがい～
このエントリを書くに当たってYouTubeとか見まくったので、
言い回しなどに一部不適切な影響が残っている可能性があります。
心を強く持って離れて読んで下さい精神的に。

あとagehaにオリジナル無し。

ぜんかいのあらすじ

　情報の結節点上に築かれた既存のTV体制は、社会全体に非効率を押し付けています。
　テレビとインターネットの結合に失敗したら、日本の情報化は死んでしまいます。
　「政治」のイニシアティブは期待できず、「行政」の利害調整ではスカッと打開できない。
　どっちもダメなら「ネット」の力。なのです。

どうがきょうゆうサービスについて

　2006にブレイクしたのはようつべとステ６ですが、2000～2005にかけて始まった動画共有サービスは他にもあります。いくつかは潰れるでしょうが、続々と出て来る事は確実でしょう。補助アプリもスタンドアローンからFirefox機能拡張まで、いろいろ有るようです。
　画質に関しては、Stage6やdailymotionクラスであっても「立ち読み」級だと思いました。地デジや感動度250%はもちろん、地アナと比べても雲泥の差です。しかし、iPod/PSP/携帯電話などに多様化した視聴デバイスや「ながら視聴」、それからブログへの引用では現状でも充分でしょう。てゆうかむしろベストではないかと。
　新しくて楽しい事があれば誰でもそれは試してみたいものです。横からアレはダメこれはダメと言うだけの人は、煙たいものです。ですから、コピーライトやDVD売り上げへの影響の問題は、ここではいったん脇に置く事にします。

　なぜならば、大切なのはそこに巨大な需要がある事だからです。

どうがきょうゆうサービスのポイント

A. 動画共有サービスから視聴者が受ける利便性は以下の通りです。

事実上のIPサイマル放送
事実上のビデオ・オン・デマンド（最近見つけた例）
事実上の放送と通信の融合（ブログへの引用、URLリンク）
視聴者によるレーティング（タグ、コメント、ブログによる言及、ソーシャルブックマーク、、、）

B. 可能性としては次のものが挙げられます。

ピンポイント広告（個人の視聴履歴や検索キーワードに基づく広告表示）

C.欠点としては次のものが挙げられます（2007初頭現在）。

画質
作り手の収益保全手段

つかってみたかんそう

　放送の場合、見逃したら・録り損ねたら終わりですが、動画共有サービスで見る事ができるならそこで視聴機会が持てます。実際、自分は絵柄の好みで避けていた涼宮ハルヒを今回初めて見ました。世間の話題になってから、もう見逃しちゃったから・録画し損ねたからまぁいっか、よりは、画質は落ちても見られた方が視聴者にとってはしあわせなわけです。それは作者や個々の作品にとっても同じなのではないでしょうか。残念ながら、個人的には、そんなに面白いかなぁ？って感じでしたけども。
　TV事業者は最大の番組配達人かもしれませんが、全ての需要を拾えるほど小回りが利くわけではありません。でしょでしょ？（アレ？）

　そもそも、ユーザーが自分の手間を割いてアップロードするのはほとんどの場合その作品が大好きだからで、要するにファンがタダで宣伝をしてくれているという面があります。例えば、自分が見たハルヒにはでら丁寧な英語字幕が付いてました。台詞がうざいくらい大量な作品なのでアレ読むだけでも面白いですし、その気ならアップロードした人にここの字幕はなんでこうしたのとコメントで聞く事も出来ます。もちろんそれは作品の本質ではありませんし、海外での収益機会を奪ってると言われればそこまでです。でも超愛してなきゃできねぇだろ～あれわ。敵視一辺倒では、コミケはコピーライト侵害だから全面禁止にしてしまえというマンガ出版社と違いがありません。
　TV事業者は番組のコピーライト保有者かもしれませんが、それが全てに優先するとは限りません。何事もほどほどが肝要。でしょでしょ？

　もちろん、「利用者の節度」と「作り手の権利」に適度な折り合いがつくまでには、何件かの「訴訟」が必要かもしれません。しかし一定の範囲であれば（例えばいくつかの「事件」を通して形成された"暗黙の了解"）、動画共有サービスをコンテントの露出機会（リヴィール・ウィンドウ）にカウントするほうが、トータルではそれを愛する全ての人にとってプラスになると思うのです。
　TV放送は最大のウィンドウかもしれませんが、それが唯一無二である必要はありません。でしょでしょ？

　さらに、可能性としては、ピンポイント広告で、製作社が直接に収益（次回作投資資金）を得る途もあります。YouTubeでは、映像を見終わると関連ビデオへのリンクが出て来ますが、そこにDVDや関連商品のアフィリエイトを出すとか、映像とは無関係のCMが出るようにして、視聴回数が多いほど、ダウンロード回数が多い程、製作社に広告料金が入るしくみを作るのは、不可能な事ではないと思うのです。これであれば自分のようにちょろっと見ただけのアクセスも収益機会となります。
　放送局は最大の資金提供者かもしれませんが、それが唯一無二である必要はありません。でしょでしょ？

　あとテレビと関係ないですけど、いまどきWinny使ってる人ってかなりヤバい印象です。ウィルス対処能力が。いまだに情報流出事件が後を絶たないというのは、暴露ウィルス？なにそれウマい？ってノードが沢山ある証拠だと思います。コピーライトだけで切ればどっちも悪でしょうが、情報セキュリティ的にはWinnyへのコンテント供給を減退させるものにはメリットがあります。ひらたく言うと安保/公安マター。
　悪とよりマシな悪しか選択肢がないなら躊躇なくよりマシな方を選べ。それが理想的な世界に近づく唯一の道だと思うぞ？（ここだけ芝村）

けつろん

　もちろん、現在の国内法ではアップロードは明白な違法行為（公衆送信化可能権の侵害）ですから、コピーライト保有者の意向があれば、YouTubeは動画を削除します。また、2008年通常国会に提出予定の著作権法改正案にて"海賊版のダウンロード"が違法となる見込みでもあります。現在の動画共有サービスが100%完璧無問題と言うつもりもありません。

　しかしながら、問題視すべきは学級会じみたコピーライト論よりも、
　それらの問題を改善した、より洗練されたサービスが、
　国内から出てこない事のほうだと思うのです。

　というかTV局が自前でVODやりゃYouTube対策にお金かけなくてもいいと思うんですよ。いやいろいろ有るのは解るけど、解決して見せなきゃTV局の社会的有用性は減る一方だし、そうなるとTV局が番組のコピーライトを保持する社会的妥当性に疑問符がついてしまふ。
　コピーライトさえクリアになれば、動画共有サービスの方が、現在のTV局よりも公共性が高い。と思いました。情報伝送経路として。

　頭書の通り、このエントリでは法的問題は捨象しています。
　自分はなによりもまず需要の存在に目を向けるべきと考えているからです。
　消費者や視聴者は、サラリーマンに正義や倫理の代弁者である事を期待していません。常に更なる便益の提供を期待しています。法的な問題を抱えつつも普及した存在があるならば、それはネギと鍋とカセットコンロ背負った鴨の群生池（だし汁入り）も同然です。タダでリスク背負って新規事業の実験してくれてるわけですし。

　既にCBSの最高経営責任者は"コンテンツ所有企業はインターネットでコンテンツを入手したいというユーザーニーズの取り込みに失敗した音楽業界の前例に留意すべきだ"として、実のある動きを見せています。
　映像需要を喚起するなら、なによりもまず視聴者を映像漬けにする必要があります。「光学ディスクを買うほど能動的では無いが、テレビを放送で見るほど受動的でもない層」により広く映像を届けた方が、もっとたくさんのひとをしあわせにすることができるのじゃないでしょうか。

ブルーレイは大好きだがコピーワンスは大嫌い（ITmedia ライフスタイル：2004/10/06）
※太字原文ママ
「私はディスクを踏んで割ってしまうということがよくあるので、大切なコンテンツのバックアップを取れないのは辛い。画質が向上するとユーザーが不便になるというのは絶対におかしい」
　麻倉氏がこのような話をある会合で語った時に、とある在京キー局の人がこう語ったという。

　「放送は生で見るものです。アサクラさん」

「コピーワンスは、もしかしてエアチェックする気をなくさせるのが目的ですか？との質問に対して、在京キー局の人は『まさしくその通り』と答えて非常に驚いた。こういうことをいっているのだから、ハイビジョン時代になっても放送局の体質は全然変わっていない」

放送・通信の在り方に関する、私見その９（古川亨ブログ：2006年6月16日）
それに対して、1080i擁護派は、「1080iが優れた方式で、議論の余地は無い、プログレッシブの話をするなら帰れ!!」（実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん（E並氏）はとても紳士ですので、私は尊敬しております。決して誤解のないように）郵政省の会合でも何度となく放送のプロ達に諭（さと）されたものです。｢君はPC業界に都合の良い方向へ持っていこうとしてるんでしょ｣「崇高な放送の世界を邪悪な世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。
将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。

　そもそも著作権は経済的私権保護の為に設けられた表現の自由に対する例外的制限事項、より直裁的には、利権です。
　YouTubeをめぐるコピーライト紛争の正体は、社会と放送事業者の価格交渉に過ぎません。
　商品は、情報。この場合は番組です。
　そして、既に視聴者/消費者の手には、有効なカードがあります。
　コピーライトの主張は常に部分最適解であってそれが全体最適解と一致するとは限りません。
　生き残るのは、より全体最適解に近い部分最適解を実現したもの。
　すなわち、最も善く公共の使命を果たすもの。

　すなわち、「あたらしいテレビ」です。

（コマネチ）

　公共性や報道の使命が既存の放送システムと一体不可分であるかの如き主張は、この価格交渉ゲームに於いてはむしろ重荷、自縄自縛になりかねません。
　
　テレビ局がもはや時代や視聴者のニーズより既得権益の保全を優先するならば、彼らの社会的有用性（=公共性）は差し引きでマイナスとなります。彼らの事業はバランシング・ポイントまで縮小を余儀なくされるでしょう。それも極めて近い将来にです。

　なぜならば、インフラごと鎖国可能な携帯電話事業とは異なり、IP網の遮断はほぼ不可能だからです。たとえ今この瞬間に地アナ停波を実行し、DVDの所持販売を非合法化しても、映像はIP網を通してやってきます。

　動画共有サービスが出揃ったのは2005年。ブレイクしたのが2006年。まだ始まったばかりです。そして、地アナの停波まではまだあと1654日、236週間と2日、18四半期+１個月、ドッグイヤー換算で31.5年「も」あります。

　てゆうかそのへんの感覚を肚に落としてないからネットで嫌われたり買収されかかったり受信料貰えなかったりすんですってば！

　停波を早めてコピワンに篭城するか、損害覚悟で撃って出るか。
　前者は全滅までの時間稼ぎに過ぎません。後者なら再建の基礎は残せます。
　対案抜きで相手の非を鳴らすだけというのは当事者能力を欠いています。

　公共性とか報道の使命とか学級会みたいのはいーからさー、もっと自分のコトバで語ってくんなきゃテレビツマンナイ！そうした人々の社会的有用性（=公共性）は高くありません。彼らには情報流通のサイクルからはご退場いただき、代替事業者の登場を促すべきです。

　情報革命を肚に落とせない者や、パニクってコトバのチカラに縋る者に興味はありません。
　作り手に正当な報酬を届けられる者、作り手と製作資金を直結できる者、VOD視聴と広告を繋げられる者、ほんとうの放送と通信の融合を実現できる者、あたらしい著作権を形にできる者、あたらしいテレビを形にできる者がいたらあたしんとこに来なさい。

　なぜならば！テレビとインターネットの結合に失敗したら、日本の情報化は死んでしまうのですから。

　Godspeed YouTube.

続く

参考

1. 国内TV事業者と競合する存在
　※主観的相対評価。イニシャルコストは含めない。

名称	画質	視聴コスト	情報選択の自由	情報蓄積の自由	情報電送の自由
地上波アナログ放送	◎	◎	X	X	X
地上波デジタル放送	◎◎◎	◎	X	XXX	XXX
動画共有サービス	X	◎	◎	◎	◎
HDレコーダ	◎	◎	◎	◎	X
Mac or Win + iTMS/iTunes/iPod/Apple TV	X	X	△	◎	△
HDレコーダ + ロケーションフリー	△	◎	◎	◎	◎
Win + Slingbox	△	◎	◎	◎	◎

2. 主要な動画共有サービス

3.ちなみに鶴屋さん派

[ 2007/01/13 00:00 ] INBOX　未分類 | TB(0) | CM(0)

あたらしい著作権のはなし

このエントリは旧ブログの焼き直しです。

◆ 印刷機の発明後、著者の知らないところで勝手に本を印刷して売ったり、他社の売れスジを勝手に印刷して売ったりが「ふつう」な時代が長くあった。

　よく考えると、写本の時代には著作権もへったくれもあったもんじゃないもんな。その流れらしいです。写本を作るのはすげぇ手間ですし、それ以外に複製を作る手段もなかったわけですから、むしろ複製を作ってくれてありがとうってな感じだったのでしょう。
　太古の昔からDRMやコピワンがあったら三国志も史記も古事記も魏志倭人伝も聖書も死海文書も残ってはいません。価値のあるものは勝手にコピーされて残り、そうでもないものは残らない。価値があるものとはなんぞや、を誰かが決めたわけではありません。それを手にした一人一人が自分で考え、自分で決めてきた結果です。

◆印刷機は巨大な装置産業だったので、莫大な投資が必要だった。

　16世紀頃に成立した印刷業は急激に成長した。高価だった「本」の価格は大幅に下がり、庶民の知識欲や情報欲を満たした。フォントも写本のねだんにふさわしい重々しいものではなく、軽い印象のある、読み易いものが工夫された（イタリック）。装丁も写本のねだんにふさわしく専用の書見台を必要とするような巨大なものではなく、安く、持ち歩きすらできるようなものが工夫された。情報の大衆化である。
　宗教改革に伴う教会の影響力低下もあって（原因は印刷聖書そのものだ）、コンテントの内容も幅広かった。有り体に言えばエロかった。心ある人々は「印刷本はからっぽの洞窟」と嘆いた事だろう。少なくとも自分には"デカメロン"と"週刊実話"の区別が付かない。エロエロっす。

　さて、本が売れるのはイイが写本時代の感覚で他社に同じ内容をバンバン刷られたら持たない。印刷機の月賦が払えない。という事に気付いた印刷会社の面々は多いに悩んだが、あるとき、賢い人がヒラメいた（参考）。「複製を作る権利」ってのがある事にしたらどうか？出版社が本を書いた人から「複製を作る権利」を買って、それを持ってない会社は印刷しちゃイケナイ事にしたらどうだ！？。でも世の中の意識は写本時代のままだから反対も大きかった。知識は独占するものじゃ無い！そんなのは悪い事だ！。でも出版社がみんな共倒れになったら誰がみんなの知識欲や情報欲を満たしてくれるの？無いでしょ他に？もう印刷本の無い世界には戻れないよ？と、いうような論争の果てに、あいだを取って「複製を作る権利」はある！でも一定期間で消滅する！って事になった。

　これがコピーライト（著作権）のはじまりです。
　当時の人たちは、それが世の中の大多数の知識欲や情報欲を満たす為の望み得る最善と考えたわけです。

　おかげで、すぐれた文章を書ける人は、大勢の人を喜ばせる文章や、大勢の人の役に立つ文章を書いて、沢山のひとから少しずつお金を貰って暮らしてゆけるようになった。それ以前の時代、すぐれた文章を書ける人は、自分の書くものを気に入ってくれるお金持ちを見つけて、その人の結婚式を祝う詩を書いたり、その人の子供の家庭教師になったりして暮らしてゆくものだった。「作家」とか「作品」というコトバのイメージは、この時代の前と後ではかなりの違いがあります。

　このように、あたらしい技術というものは、人間の社会を大きく変えてしまう事があります。

◆ 「著作権」は別に絶対正義でも天賦人権でも無い。社会的必要に応じて変わるもの。

　「著作権」と漢字で書くとなにか人を平伏させる効果があるが、もとを辿ればなんのことはない「印刷業者が複製を作る権利」。ドライでビジネスライクなものだ。「作家にとっては著作とは血を分けた子供のようなもの」というキモチは解らないでもないが、そのキモチ自体が、数百年も続いたパラダイムが作った脳内ファンタジーかもしれない。自分も同じ脳内ファンタジーは持っているのでそのキモチは尊重したく思うのだけど、100年後には形が代わっている可能性が大きいと思う。

　なぜならば。

　もし誰かが「お前のブログはオレの著作権を侵害してるから削除しる！」って言って来ても、自分は名前変えてどっかよそにバックアップ書き戻すだけだと思う。まぁ、そん時になってみなきゃ解らないですが。少なくとも自分にはそれが出来る。その手段がある。そういうあたらしい技術が今は誰にでも、使えるから。

　逆にここに書いてある文章（大したもんじゃないです、はい。大したもん書ける人はブログなんか書きません）を誰がどんなふうに使おうが、おいらにはソレを止める事など不可能です。「コピーを作る能力」はここを見る人の全員が持っている。少なくともあなたにはそれが出来る。その手段がある。そういうあたらしい技術が今は誰にでも、使えるから。

　あたらしい「世の中の大多数の知識欲や情報欲を満たす為の望み得る最善」を、頑張って考えないといけないような気がします。

◆「聖書は写本で読むものです。印刷などという邪悪な世界に引き込まないでくれたまえ」

　と、言った人が居たかどうかは知らないが、印刷技術の前までは、写本を生業とする修道院が結構あった事はほんとう。
　彼らの作る本は事務机のように巨大で、表紙は貴金属の透かし彫りで覆われ、中を開けば一字一字丁寧に、華麗な装飾フォントで、書かれるというよりも、むしろ描かれているものだった。教会のステンドグラスの明かりの下でページをめくったりなんかした日にゃあ、まさに感動度250%だっただろう。

　写本職人（修道僧）さんたちが特に強欲だったりなにかの腐敗の温床だった、という事は無いと思う。ほとんどの人たちは真面目に、より美しい写本を作る事に精を出していたはず。たんに彼らの職業生活を守る事が「社会全体にとってベスト」ではなくなってしまっただけだ。印刷機の発明によって。
　今でもその手の修道院は写本の技術とともに残っている。文化としてなのか、堅実な産業としてなのかは深入りしてない。

　ついでながら、歴史の教科書では腐敗の代名詞という事になっているローマ法王庁は、反動宗教改革という自己改革を断行して生き残りました。改革派が主導権掌握に当たって選んだ戦術は神学論争では無く、未開社会での信者大量獲得。エースの名をフランシスコ・ザビエルと言います。

[ 2007/01/15 00:00 ] INBOX　未分類 | TB(1) | CM(0)

続・あたらしい著作権のはなし

1. 「著作権」という漢字には人を平伏させる効果があります。

著作権のぶんるい（参考）

「著作者人格権」：

公表権、氏名表示権、同一性保持権など。
放棄できないので、必ず「著作者」が持っている。
カネにならない。

「著作財産権」

著作物の財産面に関する権利。コピーライト、公衆送信化可能権、など。
契約によって譲渡できるので、「著作権者」イコール「著作者」とは限らない。
カネになる。

　人を平伏させる効果があるのは、A.です。B.はそうでもありません。でも、フツーの人々にとってはどちらも「著作権」ですから、「著作権者団体」はわざとこれを混同させるように喋ります。「著作者」の中にも、混ぜこぜに喋る人が居ます。人間の習性を応用した営業トークです。
　これは「著作財産権の強化に反対する人々」にとっては厄介です。なにしろ、「著作権」というコトバを使った瞬間に、フツーの人々はA.だと思って平伏してしまいますから（参考）。

　ここでは法律上の正確さは脇に置いて、「原著作者の権利」と「コピーライト」と言い換えてみます。

「原著作者の権利」：カネにならない。
「コピーライト」：カネになる。

　ミもフタもありませんが、実は著作権をめぐるあらそいというのは、タダの価格交渉です。著作権というとすぐに文化だ芸術だと言う感じで平伏してしまいますが、ほんとうは関係ありません。そういうものの価値はですね。キミのココロの中にあるのさっ。

ここから先は余談です。

2. 日本の著作権法は欧米のコピーライト概念を明治時代にそのまま翻訳したものが元になっている。

　「著作権」というコトバが厄介で解りにくいのは、日本の歴史と断絶しているからです。歴史というのはたくさんの人の経験値のつみかさねの事です。「自由」「権利」「義務」「契約」などの概念をテメーらの経験でイチから造り上げた欧米の連中と比べると、日本ではこれらのコトバは「接ぎ木」です。

　C とか読めないのにMEncoderやx264にハマってしまったので、いきがかり上、GPLやオープンソースについて書いた英文を読む事があるのですが、なにかこう、書いてる人の、コトバのハラゴナレが英文と和文では違うような印象が、します。日本から目立ったオープンソースが出てこないという話を見かける事もあるのですが、これは、パソコンの浸透具合とかプログラマーの数とか英語とかだけではなくて、自由とか権利とか義務とか契約とかいうコトバのハラゴナレも関係あるのじゃないかって気もします。

　国内で原著作者自身が、「原著作者の権利」と「コピーライト」の違いを混同していながら、著作「権」者団体の代表として「著作権」を守ろう！と語っていたりするのは、実はその人だけの責任ではなくて、社会全体が「接ぎ木」を肚に落とせてないせいもデカイのじゃないかとも思うのです。曖昧な口約束で権利をやりとりしてしまうのが悪いと切るのはカンタンですが、それではほんとうの仕事（創作）が進まない現実もあるわけですし。
　日本の原形質には、欧米流の「自由」「権利」「義務」「契約」などの概念とは折り合いのよくない部分があるんじゃないでしょうか。江戸時代には、浮世絵や草双紙などの印刷権である「座」という概念があったようなのですが。

　このままアメリカ流の分厚い契約書と訴訟社会に進むほうがラクではあるのですが、オモムキがありません。趣味的に。ちょいと根性見せて経験値を積み上げるほうが、たぶん、味が出てくると思います。マニアックな歴史のヨミモノとして。そーささやくのよ。あたしのゴーストが。

　明治維新以来、西洋文明の大波の上を、涙を呑んで上っ滑りに滑って来たこの国の大枠には、世間に根付いては居ないがカタチとしては存在する法律やしくみがまだたくさん残っています。使われていない電気回路みたようなものです。
　情報革命は、そうしたカラッポの法律やしくみに、テメエ等の経験で電流を通す貴重なチャンスです。これを逃したら、次の機会にはオレ等は「アメリカ人のエイリアス」みたようなものになってるかもしれません。趣味的に面白くありません。
　たとえばこんなのはどうでしょうか。

３. 拝啓天皇陛下様

　このブログは「臣民のライセンス」にて公開致します。

このブログの「原著作者の権利」は自分が留保します。
このブログの「コピーライト」は天皇陛下に献上します。
畏れながら陛下におかれましては広く臣民にコピーライトをご下賜くださりますようお願い申し上げます。臣民各位におかれましては皇室への尊崇と八紘一宇（人類みな兄弟）の精神でお取り扱い下さい。控えい控えいっ。この紋所をなんと心得る。

　クリエイティブ御紋っす。（大丈夫かいろんな意味で）

　少なくともクリエイティブ・コモンズよりは、ハラゴナレは良いと思う。コモンズなんて日本の歴史にねぇもん。ゼネラル・コモンズとかコモン・センスってちょー根っこの権威だもん。あいつらの歴史的に。やつらはコモンズという単語を目にした瞬間に、深く読まなくても脳内データベースで意味を補完して、行動に反映できるのだ。歴史の授業なんか覚えてなくても「常識」とか「世間の空気」の中にご先祖様の痕跡が残っているから、補完材料はどこにでもある。だって六法全書が「十七条憲法」とか「墾田永年私財の法」とか「生類哀れみの令」の精製物でできてるようなもんなんだぜ？。おいらの脳内データベースにはそんなもん、ゼロだ。

　天皇陛下の前では全員平等。八紘一宇（人類みな兄弟）。こっちのほうが効率が良い。「みんな平等」だけだと、ギスギスしたしちめんどうな論争だらけになる。曖昧でどこにでもくっつく権威は、そういうものに対する抑止力になる。別に献上する相手は水戸の御老公でもイワシのアタマでもポロロッカ星人でもエルバフの高き心でもなんでもいいんだけど、潰しの効くもんが良い。法的には無意味なもんが良い。カタチや象徴性があれば尚可。

　出る杭は打たれるとか、水飴にまとわりつかれるような見えない気持ち悪さが厭っていう人は、クリエイティブ・コモンズなりGPLなりを使えばいいと思いますです。

　自立した市民精神に反するとか、そういう人はちょっとマテ。♪オっレっのハナシを聞け。大切なのは何を使うかぢゃなくてどう使うかです。たかだか100年やそこらでそんなもんが根付くと思ってるなら、ちょいと歴史をナメテるぜ。いきなり入会地（いりあいち）とか結（ゆい）とか前近代まで飛ばれてもおいらの脳内検索結果は0件だ。もっとあるでしょご先祖様が死ぬ程脳みそ絞り倒して考案した近代化マッスィィィンが。人間はアタマだけで生きてるわけぢゃ無い。根無し草になるなジョミー！

　国外では御稜威が一切通用しないってのが問題ですけどね。ぢゃ世界征服。カッコイイから。

　、、、いや本気にしないよーに。

参考

著作権保護期間延長はクリエイターのためになるか (2/3)（小寺信良氏：2006年11月27日）
著作権保護期間の延長を行わないよう求める請願署名（青空文庫：2007年1月1日）
クリエイティブ・コモンズ（フリー百科事典『ウィキペディア（Wikipedia））
地球へ…：竹宮恵子の名作SFがテレビアニメ化（まんたんウェブ 2007年01月10日）

[ 2007/01/15 00:00 ] INBOX　未分類 | TB(2) | CM(2)

続々・あたらしいテレビのはなし

1. イントロダクション
- 1.1. クール・ジャパンはカネになってない
- 1.2. 日米における放送事業者のスタンス
2. 実際の製作者よりインフラ保有者のほうが圧倒的に強い日本
3. アニメの作り手に適切な報酬は渡っているか？
4. 流通経路が「作品の権利」を持つとどうなるか
5. むすび

1. イントロダクション

1.1. クール・ジャパンはカネになってない

2006 年にこういうニュースがありました（グレーの所をクリック）。

仏２少女、マンガの国あこがれ日本向け家出　警察に保護 - 国際（asahi.com： 2006年7月頃） ※元記事消滅

日本の漫画やロックに魅せられたパリ郊外に住む１６歳の少女２人があこがれの日本を目指して家出。鉄道を乗り継ぎポーランドにたどり着いたところで警察に保護された。
陸路ロシアを横断し、船で日本に渡る計画を立てていたが、経由国でビザ（査証）が必要だとは知らなかったという。仏紙リベラシオンが報じた。

同じ学校に通う２人は日本の忍者マンガ「ＮＡＲＵＴＯ」や少女マンガ「ピーチガール」、日本のビジュアル系ロックの大ファン。「文化から生活スタイルまで何もかもがあこがれ」の日本に行こうと思い立った。

朝鮮半島までの陸路は鉄道を乗り継ぎ、「海は船で渡ろう」と計画。６月２２日にわずかな現金と携帯電話、携帯オーディオプレーヤー、漫画本を持って出発。ベルギー、ドイツを経由し、２５日にポーランドからビザ無しでベラルーシに出国しようとしたところで国境警察に拘束されたという。

フランスでは日本のアニメやコスプレ、Ｊポップが若者に絶大な人気で「オタク」「カワイイ」は仏語として定着。７月７～９日にパリ郊外で開かれる日本の漫画やアニメなど日本文化の紹介イベント「ジャパン・エキスポ」には６万人の人出が予想されている。

　わたしはこのニュースをこの人に教えてあげたひ。

旅上（萩原朔太郎純情小曲集：1924）※青空文庫

ふらんすへ行きたしと思へども
ふらんすはあまりに遠し
せめては新しき背廣をきて
きままなる旅にいでてみん。
汽車が山道をゆくとき
みづいろの窓によりかかりて
われひとりうれしきことをおもはむ
五月の朝のしののめ
うら若草のもえいづる心まかせに。

　ところでシベリア鉄道は1904年9月に全線開通してました。従って、行動力の源泉となる「脳内あこがれ密度」はこうなります。

　パリ郊外に住む１６歳の少女２人　＞＞＞　超えられないカベ　＞　朔太郎

　てなヨタはともかく「脳内あこがれ密度」はカネになります。朔太郎も"新しき背廣"を買う時は、できればフランス製がいーなー、と探した筈。さぞや日本のコンテンツ産業も、、、

コンテンツ産業のGDPに対する割合

米国	世界平均	日本
4.70%	3.15%	2.66%

（※数値は2004年。首相官邸知的財産戦略本部/知的財産推進計画２００６・別冊参考資料（H18.6.8）P30より）

　、、、なんだかショボイです。
　百歩譲って、ハリウッドに比べりゃ月とスッポンなのは、解ります。
　でも世界平均より下というのはヘンです。だって私たちは「文化から生活スタイルまで何もかもがあこがれの国」なのですよ？
　グロス・ナショナル・クール・ジャパン・アズ・ナンバーワンはどこにあるの？

それはね。キミの心の中さ！(^~^)b

　数字に出てこない以上、他に答えようがありません。虚像。
　しかも、経済産業省の調べではゲームを除く全てのコンテンツ産業の国際収支が赤字です。
　海賊行為に苦しんでいるのはどこも同じです。どこかに、日本固有のボトルネックがある。

1.2. 日米における放送事業者のスタンス

アメリカのTV局はインターネットの活用方法を探り始めています（事例1,2,3,4）。
　とくにCBSの最高経営責任者は、インターネットでコンテンツを入手したいというユーザーニーズの取り込みに失敗した音楽業界の前例に留意すべきだと公言し、Slingboxのような小さな（しかし独創的な）会社と協調しています。

　一方、日本のTV局は、コピワンで視聴者の利便性を下げ、YouTubeを監視する部署を作り、録画NetやまねきTVのような小さな（しかし独創的な）会社を訴えるなど、敵対的な動きを強める一方です。

　このスタンスの違いはどこから来るのでしょうか？

　アメリカのコンテント産業の王様は、ハリウッドです。映画の業界人に比べれば、テレビの業界人は、はっきりと格下です。コンテントの流通ルートを「ウィンドウ」と言うのですが、これはテレビや VHSの普及に合わせて、映画の人が考え方やビジネスを変化させていく中で編み出したコトバです。すこし抽象的なので例を挙げると「ポケモン」というコンテントにとっては、TV局も映画館もDVDもゲームも玩具も「ウィンドウ」の一つです。それぞれの「ウィンドウ」の相乗効果が出るように、常に全体最適解を考えろ。それが儲けが一番でかいし株価も上がる。という考え方です。
　アメリカのテレビマンは「我々は映画の人から見ればウィンドウの一つ」という考えに慣れています。従って「我々が権利を保有するテレビ番組にとって、インターネットは新しいウィンドウの一つ」というアタマの切り替えも、やりやすいのでしょう。

　対するに、日本のコンテントの中核をなすのはテレビ番組です。映像業界全体に君臨する頂点です。そして彼らの流通経路は、放送事業の始まった最初から寡占であり、国内に限っては無敵です。
　自分はゲーマーなのでゲームの例を出します。
　日本のテレビマンの中に、任天堂のように頂上を明け渡した経験を持つ者は居ません(1997頃)。SCEのようにゼロから実力で頂上を奪い取った経験を持つ者は居ません(1997頃)。セガのようにインフラ基盤を失った経験を持つ者は居ません(2000頃)。マイクロソフトのようなチャレンジャーを迎え撃った経験を持つ者は居ません(2002頃)。んでもって任天堂が再び玉座を奪還しつつあるのですが、こりゃまた別のオハナシ。
　 TV放送事業にはこのような競争がありません。無風状態のカースト制度の頂点に長く居ると、外部要因から来る変化に適応できなくなるものです。「放送は生で見るものです。アサクラさん」、とか、「崇高な放送の世界を邪悪な世界に引き込もうとしている」とか、ヒキコモリくさいマニアックな倫理観を仕事に持ち込むようになります。そのうち誰か「地デジが無ければワンセグをご覧になればいいじゃない」とか言いだすのじゃないかと。
　ひらたく言うと、腐敗です。そして腐敗とは無自覚なものです。

2. 実際の製作者よりインフラ保有者のほうが圧倒的に強い日本

経産省は2005年にコンテンツ産業全般に渡る分析を公開しています。経済産業省/コンテンツ産業政策のページから入手できます。その中から適当に拾うと、、、

平成17年２月、コンテンツ産業の現状と課題（pdf直接リン）

映画配給会社、テレビ放送局などのコンテンツ流通部門が寡占的傾向にある中で、コンテンツの制作事業者は、制作資金調達、マーケティング等において流通事業者に大きく依存せざるを得ない状況にある。このため、コンテンツ産業では付加価値の多くを流通事業者が取得する構造にあり、コンテンツ自体の価値を創造する生産部門が必ずしも成果に応じたリターンを得られていない状況にある（P17）

我が国番組のほとんどは資金提供者が権利を確保することが多く、製作会社による二次利用の機会が有効に活用されていない状況。一部少数の二次利用展開の成功モデルのほとんどは、製作会社が権利を管理するパターン(例「ドラえもん」「ポケットモンスター」)（P19）

　要するに、テレビ局の支配力がでかすぎると言っています。それが日本のコンテンツ産業の収益性を阻んでいると。そしてコンテンツ自体の価値を創造する人々に版権を持たせろと。

　では、具体的に番組製作の過程で動く金額はどうなのでしょうか。

3. アニメの作り手に適切な報酬は渡っているか？

　図は『アニメーション産業の現状と課題』という経済産業省が平成15（2003）年3月に作成したpdfを模写したものです。原文は経産省の検索ページから入手できます。
　スポンサー ⇔広告代理店⇔キー局までの上流はなかなか良さそうな取引なのですが、キー局⇔元請けプロダクションの段階で、一気に零細感溢れる数字になっています。しかも最初から赤字前提を匂わせる但し書き付き。
　代理店とキー局がコストカットをすれば、ちょいとムダを省くだけでも元請けに渡る資金が激増しそうなものですが、寡占で、圧倒的に立場の強い彼らにはその動機がありません。むしろ最近では、トリコロールな信玄餅や、メロンのようなキャベツを珍重する人もいるくらいですから、逆に制作費を締め付けたほうがおいしいケースすらありそうです。「視聴率がすべて」なら、そうするのが優秀な人材となります。

　キー局の手許に残るのは1,200万に過ぎませんから、そこから放送設備の更新費用や人件費を出すとなると、必ずしもおいしい商売ではありません。まして地デジの投資負担がかかりますし。
　しかしながら、放送局の真の存在価値は、番組とCMの送出インフラです。これは、かなりの部分を、インターネットで、より安く、代替可能です。より低いコストで、番組を送信する手段があるのに、それをしないのは、社会全体としては非効率です。社会から「得べかりし利益」を奪っています。ひらたく言うと、公益に反します。

　スポンサーにとっては、僅か15秒程で、しかも視聴率しか目安が無く、さらにHDレコーダなどで飛ばされてしまうTVCMなどより、自社サイトを見てもらう方が、宣伝効率が良くなっています。その場で商品を売る事だってできるわけですから。IP放送や、動画共有サービスなら、番組に企業サイトへのリンクを埋め込む事も可能です。もしも元請けプロダクションが企業を回って広告を集める事ができたなら、広告代理店の取り分1,000万円を製作資金に上乗せできる可能性があります。さらに、番組の作り手に、視聴回数に応じた広告収入を届ける事も可能です。
　ひらたく言うと「PVがすべて」。この場合「より多くの人に、繰り返し見てもらえる番組」を作り出すのが、優秀な人材となります。

図の中に「権利管理窓口」と言うものがありますが、これが「我が国番組のほとんどは資金提供者が、権利を確保することが多い(2. 引用2.)」です。TV局が制作資金を出さなければアニメが作れないと言う事ですね。スポンサー、代理店、キー局などからなる「XX製作委員会」というヤツです。

※ ここで「ゼーレの老人たちな？」と軽口を叩こうとして自分で自分の妄想にハマってしまった。

　スポンサーはグッズの売り上げを求める。代理店は広告効果を求める。キー局は視聴率を求める。
　肩書きが喋っているかのような組織の利益代表者。人格の見えない「SOUNDONLY 02」。そんな「委員会の呼び出し」。
　誰も作品の質とか、いまこれを世に出す意味とかには関心が無い。
　ほんとうは自分は面白い作品を作る事にしか関心が無いのだけれど、
　制作資金が無くなるからキリキリとした空気のこの場所から逃げちゃダメだx3。僕はここにいてもいいですか。
　・・・みたいな。

◆◇◆

まぁ、どんな解釈でもくっつくのがエヴァではありますし、
　そこを切り回せないで何が仕事かとも思うのですが、
　感受性の強さで生きてるクリエイタという人種はもうちょっと作品に集中できる環境に置いた方が良い気もします。
　トミノさんが一度壊れたのもたぶんコレだし。
　こういう場所には野球の契約交渉みたように代理人を、ってそれを買って出たのがジブリの鈴木敏夫さん。なのか？

◆◇◆

ともかくオレ脳内では「XX製作委員会」の実際の雰囲気は「ゼーレ」。まる。
　なにエヴァ見た事ない？うん。一応見といた方がいいかもよ。
　音楽で言うとビートルズとかビリー・ジョエルとかレイ・チャールズとかあのへんのクラスだから。

さぁそうなると、いくらDVDやグッズが売れても「下請け」に回る配分比は、～数値が見当たりませんが～、構造的にかなり渋そうです。もうちょっと出してくれよと交渉しようにも、他に資金調達先の無い彼らには切れるカードが有りません。
　これが「コンテンツ自体の価値を創造する生産部門が必ずしも成果に応じたリターンを得られていない状況(2.引用1)」です。
　、、、しかたがないから声優でもアイドル化してみる？主題歌タイアップしてみる？

　なお模写の過程で、図の赤や黄色の文字・彩色は手許で追加しましたが、グレイの彩色、配置、文字強調はできるだけ原本に忠実におこないました。ちまちまと矢印の大きさなどをなぞっていると、このpdfの作り手さんはこの産業構造は適切なものではないと考えているのだろうなぁ、、、という気がしました。
　pdf末尾には経産省の今後の施策が挙げられています。抜粋してみると、、、

「アニメーション産業の現状と課題（経産省の検索ページへ）」
※ 太字＆下線は原文ママ。
7. 経済産業省のアニメーション産業に関する施策

独占禁止法体系の厳格な運用による放送局のプロダクションに対する優越的地位の濫用の防止

金融機関からの資金調達環境の整備 (コンテンツファイナンス研究会の開催等)によるプロダクションの自立支援

海外の配給会社やブロードバンド等、キー局以外の流通出口を活用したビジネスモデルの促進

　意訳すると「阿漕な商売しとったら承知せんぞゴルァ！」といったところでしょうか。

4. 流通経路が「作品の権利」を持つとどうなるか

　前述の通り、コンテントの流通経路を「ウィンドウ」と言いますが、その「ウィンドウ」のどれか一つが強すぎると、他のウィンドウとの相乗効果よりも自己の利益を優先し、「作品」の総合的なポテンシャルを損ねてしまいます。例えば、TV局は海外への放送ができないので、海外でどれほどアニメ人気があってもそこから収益を挙げる仕事に熱心にはなれません（実際、番組輸出は出世コースではないと思います）。逆に、どれほど愛されている「作品」であっても、彼らが持つ唯一のモノサシである「視聴率」に最適化するのが、最も合理的な行動です。

　これが、アニメ業界の基本構造です。一週間あたり80本も放送されていながら制作会社は軒並み赤字決算という利益なき繁忙。
　もちろん、放送事業者や代理店がやっている事は、所与の条件の中でもっとも合理的な行動を取っているだけです。
　しかしながら、ここで見て来たような取引を「正当」と感じる人は稀でしょう。
　私たちが「作品」にお金を払うとき、そのお金はやっぱクリエイターに届いて欲しいですからね。運送業者の取り分が一番でかかったら、やっぱ不可解ですし、まして梱包の都合で「作品」を弄ったりしたら、ねぇ？

　その結果がこの数値です。

コンテンツ産業のGDPに対する割合

米国	世界平均	日本
4.70%	3.15%	2.66%

（※首相官邸知的財産戦略本部/知的財産推進計画２００６・別冊参考資料（H18.6.8）P30より）

　クリエイターたちは人間をシベリア鉄道に密航させるほどの「脳内あこがれ密度」を生んでいながら、非効率な事です。

5. むすび

情報の結節点の上に築かれた既存のTV体制は、情報の民主化を妨げ、社会全体に非効率を押し付けています。
　放送事業者が、圧倒的な地位の下に作品の権利を支配しながら、海外視聴者のニーズに応えず、国家的な逸失利益を放置し、あまつさえ己ひとりの視聴率のために「作品」を弄ぶ事すら厭わないならば、情報流通のサイクルからはご退場いただき、代替事業者の登場を促すべきです。

　なぜならば。
　テレビとインターネットの結合に失敗したら、日本の情報化は死んでしまうのですから。

ageha にオリジナル無し。

"You Will"（AT&T 1993）
「モバイルとデジタル家電が拓く新ビジネス」デジタル放送・デジタル家電１（世界情報通信サミット2000）
中古ソフト問題雑感（だ☆めーず - ゲーム雑感：2002年4月29日）
アニメーション産業の現状と課題（経済産業省の検索エンジン：2003頃）
ブルーレイは大好きだがコピーワンスは大嫌い（IT Media +D：2004 年10月6日）
コンテンツ産業の現状と課題（pdf直接リン）（経済産業省のコンテンツ産業政策のページ：2005年）
■テレビがネットを嫌う本当の理由■（世の中不思議で面白い：2005年4 月25日）
放送・通信の在り方に関する、私見その９（古川亨ブログ：2006年6月 16日）
詐欺師の告白（Meine Sache ～マイネ・ザッヘ～：2006年08月02日）
テレビ業界を震撼させた新たな司法判断「まねきＴＶ」仮処分却下（日経IT プラス：2006年8月17日）
ダウンロード、海賊版は禁止　政府、著作権法改正を検討（asahi.com： 2006年11月24日）

　政府の知的財産戦略本部（本部長・安倍首相）は、音楽や映像を違法コピーした「海賊版」をインターネット上からダウンロードすることを全面的に禁止する著作権法改正に着手する。２７日に開く知財本部コンテンツ専門調査会に事務局案を提案。罰則も設け、０８年通常国会に提出をめざしている改正案に盛り込む。海外でも人気が高い日本のマンガやアニメなどの権利保護を強め、コンテンツ産業の育成を促す狙いがある。

　現行の著作権法では、著作権者の承諾なしに複製したコンテンツをネット上に流すことは違法だが、違法コピーをダウンロードしても、個人で利用する限りは著作権の侵害とはならない。このため、ネット上で違法コピーを入手する行為が横行しても、規制するのは極めて困難だ。

　政府は「世界トップクラスのコンテンツ大国を実現する」との方針を掲げ、アニメや映画、ゲーム、音楽、出版などのコンテンツ産業の市場規模を、２０１０年までに１５兆円にしたいとの目標を０４年に設定している。

　知財本部は、現状を放置すれば正規のコンテンツの買い手が減り、正当な利益を得られない制作者が創作意欲を失いかねないと判断。海賊版のダウンロードが違法であることを明確にすることでその流通を減らし、コンテンツ産業を成長分野に育てたい考えだ。
著作権むずい（あずまきよひこ.com：2006年12月10日）
クリエイターに必要なのは著作権の強化ではない（池田信夫 blog：2006年12月20日）
2006年のテレビ包囲網——ゲーム・HDDレコーダー・YouTube【コラム】（日経ITプラス：2006年12月21日）
信玄餅（MUSASHI -GUN道-まとめwiki）
最近のドラえもん（Melog：2007年01月07日）
テレビ業界のカースト制（ハコフグマン：2007年1月10日）

[ 2007/01/17 00:00 ] INBOX　未分類 | TB(1) | CM(0)

2006年で最も印象に残ったアニメ

1.無敵看板娘

タイトル	I枚数	I比率	Avg QP (P)
VGAアニメ平均値（無敵看板娘を除く33件）	401	0.92%	20.10
『無敵看板娘』平均（02-12話）	439	0.98%	22.16

　毎週地味にAvg QP(p)が高くて気になった。
　カメラワークを駆使した演出は他のアニメではあまり見られない。　
　文字で書きにくいのだが、コマ送りで見ると「アニメーターなら一挙一動に意味を込めろ」とでも言いたげなコマも目立った。
　どちらも凄まじく地味で見過ごしがちなのだが、巧い。
　フィルム時代はコレが普通だったのかも知れない。古典的な動画職人のココロイキってやつだと思う。
　きちんとエンコするには、どんな映像がどんな符号化ツールに向いてるか、引き出しをもっと増やさなければと思った。
　その後、『愛・蔵太の少し調べて書く日記』で大塚康生の「クリーンアップ十戒」を読んでさらに平伏しました。

2. ゼーガペイン

タイトル	I枚数	I比率	Avg QP(p)
ゼーガペイン_15	494	1.16%	21.91
ゼーガペイン_16	541	1.27%	20.70
ゼーガペイン_17	492	1.16%	20.03
ゼーガペイン_18	436	1.02%	19.93
ゼーガペイン_20	490	1.15%	19.37
ゼーガペイン_21	441	1.04%	18.74
ゼーガペイン_23	580	1.36%	21.73
ゼーガペイン_25	581	1.37%	21.58

　GOP関連をおろそかにしたx264はXvidにも劣るはこの作品で思い知った。
　毎週毎週、I枚数がとんでもない事になっている。『無敵看板娘』に比べると動き自体に面白みは無く、古典的な職人芸の印象は薄い。
　にも関わらず、カット切り替えでやたらとブロックノイズが目に付く。
　短いカットをぽんぽん繋いでリズム感を出すという、編集職人の芸。
　これはscenecutだけではなく、最小GOP間隔を切り詰める必要があると気が付いたのは終盤近くになってからだ。
　録画失敗だらけだったのが残念。

　このI比率で無敵看板娘並みに動かれたらどーしよー。

[ 2007/01/17 01:00 ] 動画　圧縮日記264 | TB(0) | CM(0)

070115-結果＆設定篇

エンコードの概要

PowerMac G5 (2Ghz x 2), mem1GB。
MEncoder/x264 のビルド日は2006/12/20。
映像ビットレート1024kbps, 2パス, アニメは24000/1001fps, 実写は30000/1001fps, lanczos 3
HighProfile の為、再生はVLC、MPlayer（OSX）、QuickTime Player + avc1Decoder。

VGA(640x480)

タイトル	fps1	fps2	fps_total	I枚数	I比率	AVG QP(P)	PSNR	SSIM	I16x16	I8x8	I4x4	1st時間	2nd時間
ヴィーナス・ヴァーサス_01_070112	22.02	6.96	5.29	412	0.93%	17.09	48.28	0.9934247	5.7%	74.0%	20.3%	0:33.28	1:45.54
ケロロ軍曹_070105	19.15	6.20	4.68	391	0.88%	18.98	46.05	0.9915265	8.4%	71.1%	20.6%	0:38.37	1:59.17
ケロロ軍曹_070112	20.54	6.06	4.68	449	1.01%	19.44	45.92	0.9908702	8.9%	73.6%	17.5%	0:35.59	2:01.55
ひだまりスケッチ_01_070112	20.26	7.02	5.22	393	0.89%	16.75	47.90	0.9950168	7.2%	62.6%	30.1%	0:36.14	1:44.30
メジャー3rd_01_070106	22.28	7.44	5.58	420	0.93%	17.54	47.59	0.9922558	8.7%	64.4%	26.9%	0:33.38	1:40.44
メジャー3rd_02_070113	19.80	6.55	4.92	383	0.85%	19.02	45.94	0.9905024	9.4%	65.6%	24.9%	0:37.52	1:54.29
機動戦士ガンダム0080～ポケットの中の戦争～_02_070111	18.22	6.08	4.56	440	0.91%	20.09	46.02	0.9875355	6.1%	77.6%	16.3%	0:44.22	2:13.01

※エンコ以外の作業も同時にやる事が多いので速度はばらついている。

060831-結果篇や、060915-結果篇と比べると速度は大幅に向上している。
I8x8 の比率は巨大。High Profileの圧縮効率は、SDに於いても大。
数知的な画質はガンダムが最も悪い（AVG QP, SSIM）。この時代のアニメはセル画をフィルムカメラで撮影している筈だが、その際のカメラのブレと思しき場面が散見された。無敵看板娘の経験から言っても、カメラワークは動き補償にかかる負荷が巨大と思われる。

VISTA(640x352)

タイトル	fps1	fps2	fps_total	I枚数	I比率	AVG QP(P)	PSNR	SSIM	I16x16	I8x8	I4x4	1st時間	2nd時間
ProjectBlue_01_070110	27.16	8.49	6.47	421	0.97%	16.83	47.62	0.9907793	6.3%	76.2%	17.5%	0:26.45	1:25.32
ゴーストハント_070110	28.16	8.46	6.51	375	0.86%	13.40	50.86	0.9952298	5.4%	64.4%	30.3%	0:25.48	1:25.52
ひまわり_01_070108	26.81	8.23	6.30	454	1.01%	18.57	46.35	0.9893814	5.0%	79.1%	15.9%	0:27.57	1:31.03
月面兎兵器ミーナ_01	27.28	8.32	6.38	475	1.15%	17.01	47.63	0.9912010	6.0%	73.9%	20.0%	0:25.16	1:22.49

※寝てる間に終わったので速度のばらつきが無い。

1st はほぼ実時間。
数値的な画質はゴーストハントが最も良い。

設定概要

　基本方針は、1stはフレームタイプの決定と大まかなレート配分統計が取れれば良いとの考えから、重そうなオプションを 2ndにまわす方針をさらに徹底し、threadsと合わせて全体的な高速化を得る。です。

$ mencoder ケロロ軍曹_070105.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:turbo=1 -passlogfile ケロロ軍曹_070105.264.log -vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::3,hqdn3d=4:3:6,harddup -sws 9 -ofps 24000/1001 -of rawvideo -o /dev/null

$ mencoder ケロロ軍曹_070105.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=all:trellis=2:brdo:bime -passlogfile ケロロ軍曹_070105.264.log -vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::3,hqdn3d=4:3:6,harddup -sws 9 -ofps 24000/1001 -of rawvideo -o ケロロ軍曹_070105.264

threadsを、実験結果に基づき、1stは2、2ndは16にした。
qp_stepを、なるP氏の設定例に倣って、8にした（アニメのみ、実写はデフォルト値で行くつもり）。
me_rangeを、なるP氏ほかの知見に倣って、2ndのみ32にした。
partitionsを、MEncoder Documentsに倣って、2ndのみallとした。（1stはturboのプリセット値）
8x8dctを、1stはGOP設定のみとの考えから、2ndのみとした。
cqm=jvtはレート配分に与える影響が大きいと考え、1stにも残した。

課題

　I8x8の多さから考えて1stにも8x8dctを使うべきかも知れない。
　turbo=1の内容は以下の通りと思われる。

subq=2:frameref=1:partitions=p8x8,i8x8,i4x4:

　turbo =1はpartitions=i8x8を含むので、8x8dctはturbo=1と併用する意味がある。要実験。

[ 2007/01/17 02:00 ] 動画　圧縮日記264 | TB(0) | CM(0)

iPhoneと携帯電話のGPS対応義務化について

ええとiPhoneなんだけど、3G対応に一年かかるって以前にコレ。

来年4月、すべての携帯電話にGPS（日経パソコンオンライン：2006年 10月11日）
※太字オレ
GPSモジュールを内蔵した携帯電話が、来春以降一挙に広がりを見せそうだ。きっかけは、第3世代（3G）携帯電話へのGPS搭載の義務付けだ。

　総務省は事業用電気通信設備規則を2006 年1月に改正・公布し、2007年4月に施行する。改正の大きな柱の一つが、携帯電話からの緊急通報機能を充実させる、通称「日本版e911」だ。施行後に発売される3G端末は、原則としてGPSモジュールの内蔵が義務付けられる。対応端末から110番／118 番／119番へ緊急通報した際に、通報者の位置情報をGPSで測位し、警察・消防・海上保安本部に自動通知する仕組みを構築する。

　根拠は総務省の報道資料っぽい。

事業用電気通信設備規則の一部を改正する省令案等に係る情報通信審議会答申及び意見募集の結果（2005 年12月20日）
※太字オレ
(1)     情報通信審議会に諮問した省令案
　○事業用電気通信設備規則（昭和60年郵政省令第30号）の一部を改正する省令案（PDF）
　　　電気通信事業者の電気通信設備のうち音声伝送役務を提供するものについて、緊急通報を扱う場合には、次の機能を有することを規定します。

1)     緊急通報の発信場所を管轄する警察機関、海上保安機関又は消防機関へ接続する機能
2)     緊急通報を発信した端末の電気通信番号及び位置情報を通知する機能
3)     通話中の回線を保留する機能
（中略）
　情報通信審議会の答申及び皆様から寄せられた御意見を踏まえ、速やかに省令等の改正を行うこととします。（施行日は、平成１９年４月１日を予定しております。）

　これより新しいのは見当たらなかったので、その後速やかに省令等は改正されたっぽい。

　iPhone の国内販売に当たっては、3G対応+GPSモジュール+対応ソフト（警察、消防、海保直電機能）が要るような気がする。
　国内大手でその改修に手を出しそうな会社あるかなぁ。

◆◇◆

　iPhone が搭載するOS XはMac OSXとは違ってサードパーティのソフトはインストールできない仕様だ。
　セキュリティの為とされているが、これは要するにiTMS以外の音楽や動画データはシンクロも閲覧もできませんよという事でもある。
　一方、国内販売の担い手と期待されているソフトバンクのケータイには「着うたフル」がある。

　それはそれとして、iPhoneはものすんごく欲しい。
　いーかげんClieの液晶がヘタッて来たので。テキストメモくらいはあるのでしょう？
　グラフィティを手放すのはやむを得ないとしても、Palmに慣れた身にはリナザウもWZero3も携帯電話もレスポンスのトロさがガマンできないし、あれらではシンクロもままならぬ。iPhone はものすんごく欲しい。

ところで総務省報道資料の右肩にあるロゴがちょっと可愛かった。

agehaにオリジナル無し

2007 年以降、3G携帯は原則GPS機能搭載へ（ITmedia+D：2004年05月18日）
携帯電話・IP電話からの110番に位置情報通知機能義務化へ（スラド： 2005年10月26日）
GPSの義務化に向け、「3Dナビ」で優位に立つ──KDDI（ITmedia +D：2006年03月27日）
来年4月、すべての携帯電話にGPS（日経パソコンオンライン：2006年 10月11日）

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

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ガイド_x264の設定

2007/11/01追記：x264cli svn-680に準拠した本記事のアップデートがこちらにあります。

原文：Video configurationdialog/X264 Configuration

大きい脂肪質の警告。

原文、『MEWIKI』は整備途上のMeGUIドキュメントです。
原文の解説は初心者むけに非常に簡便です。
試訳した本人はマカーです。
MEncoder, x264cliとも、対応オプションは推測です。
x264cli/MeGUIな方はタグ：x264(r600)コマンド対応も参照願います。

MeGUI概要

　MeGUI（MEncoder GUI）はWindows上で動画エンコードに関わる多数のフリーウェアを統合的に扱う為のGUIフロントエンド。また動画エンコードに役立つ独自の機能も搭載している。インストーラは x264.nlにて配布されており、インストール後、アップデータを起動して動作に必要なファイルを取得する。
　x264cli、MEncoder、mp4boxの他に、音声や字幕などに関連するコマンドラインツールを取得すると思われる。

　事前にインストールしておくべきものは以下。

Microsoft .NET framework 2.0: Windows updateまたは Microsoft websiteから取得。
Avisynth: スクリプトを使って動画編集（インタレ解除やデノイズ、リサイズなど）を行うもの。取得先は avisynth.org。MeGUIのアップデータはavisynth用のプラグインも取得するので、特にMeGUIを動作させるだけなら別途プラグインをダウンロードする必要は無い。

x264の設定項目

Page 1 - General options

MeGUI	x264cli	MEncoder	常用値（MEncoder）
Deblocking: デコード中のインループ・デブロッキング・フィルタを使用。指定範囲は二つとも -6 から 6の範囲。Deblocking strength はデブロック強度、 Deblocking Threshold はデブロックをかける映像の量を指定する。	--no-deblock -f, --deblock <alpha:beta>	(no)deblock deblock=<-6-6>,<-6-6>	deblock(使用) 0,0
Enable PSNR calculation: このボックスをチェックすると、x264 はログに PSNR情報をジョブの終了後に書き出す。若干遅くなる。	--no-psnr	(no)psnr	psnr(使用)
Number of threads: マルチコア・システムを持っている場合に、この値を増やしてそのメリットを活かす。複数のフレームを同時に処理できる。マルチスレッド化に伴う画質劣化は取るに足りない。推奨値は 0。これで x264 はCPUのコア数を検知して最適なスレッド数を使う。このオプションを使うには、MeGUI settingsの Automatically set number of threads をdisableにすること。	--threads <integer>	threads=<1-16>	1st,2 2nd,16 参考
fourCC: AVI などのコンテナがコデック判定に使う4CCの指定。	対応なし	対応なし	非使用
AVC profiles: この設定は、AVCの特定プロファイルに沿った設定をする際の助けとなる。選択されたプロファイルを超えるオプションが指定できなくなる。	対応なし	対応なし	参考
AVC Level: 特定のAVCレベルに沿ったエンコードをしたい場合に使う。選択されたレベルでは使えないオプションを指定出来なくするようにはしないので、ツールメニューの "Validate AVC level" でチェックする事。	--level <string>	level_idc=<10-51>	参考

Page 2 - Zones and custom commands

	MeGUI	x264cli	MEncoder	常用値（MEncoder）
	Zones: Zoneの使い方はこのドキュメントの目的を超えるが、ここでzoneの定義と適用する Quantizer または重み付けを指定する。	--zones	zones	非使用
	Custom Commandline Options: x264(cli)の追加コマンドを使いたい場合はここに入力する。x264(cli)に新しい機能が追加されたが、MeGUI のアップデートがまだの際などに使う。

Page 3 - Rate control, motion estimation and GOP

MeGUI	x264cli	MEncoder	常用値（MEncoder）
VBV Buffer Size: VBV Bufferの最大サイズ	--vbv-bufsize <integer>	vbv_bufsize=<value> (ABR or two pass)	未指定(default)
VBV Maximum Bitrate: Video Buffer Verifierの最大ローカルビットレート	--vbv-maxrate <integer>	vbv_maxrate=<value> (ABR or two pass)	未指定(default)
VBV Initial Size: VBV bufferのイニシャル占有率。 1.0 = full, 0.0 = empty。	--vbv-init <float>	vbv_init=<0.0-1.0> (ABR or two pass)	未指定(default)
Bitrate Variance: ビットレートの変動範囲。 1.0 = pure VBR, 0.0 = pure CBR	--ratetol <float>	ratetol=<0.1-100.0> (ABR or two pass)	4。番組ごとに地味にサイズが変わる。
Quantizer Compression: quantizerの変動範囲。 1.0 = pure CQ, 0.0 = maximum change	--qcomp <float>か？	qcomp=<0-1> か？ (ABR or two pass)	未指定(default)
Temp. Blur of est. Frame complexity: curve compression（＊不詳＊）の前にquantizer curveに適用する時間軸ブラーのレベル。時間軸ブラーは量子化程度の一貫性をもたらす。この値を増やすと、映像は真のCQに近づく。（＊適用量子化値の急激な変動を多少滑らかにするものか＊）	--cplxblur <float>	cplx_blur=<0-999> (two pass only)	未指定(default)
Temp. Blur of Quant after CC: curve compression（＊不詳＊）の後でquantizer curveに適用する時間軸ブラーのレベル。この値を増やすと、映像はCQに近づく。	--qblur <float>	qblur=<0-99> (two pass only)	未指定(default)
Chroma ME: 動き予測の際に、彩度情報も動きの検出に使う	--no-chroma-me	(no)chroma_me	chroma_me(使用) 要、subq>=5
ME Range: 動き予測機構が使う最大捜索範囲（マクロブロックの中で）	--merange <integer>	me_range=<4-64>	1st,16 2nd,32 実用範囲16-32程度
Scene Change Sensitivity: シーンチェンジと看做すフレーム間の変更をパーセンテージで指定。範囲0-100。-1はシーンチェンジ検出なし。	--scenecut <integer>	scenecut=<-1-100>	実写40(default) アニメ65
ME Algorithm: 動き予測に使うサーチアルゴリズムの選択。Exhaustiveはピクセル単位となり、凄まじく遅い。	--me <string>	me=<name>	1st,(turbo) 2nd,umh
Subpixel refinement: サブピクセル予測に使うアルゴリズムとパーティション決定に使う方式の選択。RDO (Rate Distortion Optimisation) を選ぶとBフレームにRDOを使う。	-m, --subme <integer>	subq=<1-7>	1st,(turbo) 2nd,7
Keyframe Interval: I-frames間の最大間隔	I, --keyint <integer>	keyint=<value>	240または300
Min GOP size: I-frames 間の最小間隔	-i, --min-keyint <integer>	keyint_min=<1-keyint/2>	実写,24または30 アニメ1
Noise reduction: プリプロセス・ノイズリダクション。0 = disabled。	--nr <integer>	nr=<0-100000>	非使用

Page 4 - Advanced settings

MeGUI	x264cli	MEncoder	常用値（MEncoder）
Quantizers
Minimum Quantizer: x264が使う最大量子化値	--qpmin <integer>	qp_min=<1-51> (ABR or two pass)	10
Maximum Quantizer: x264が使う最小量子化値	--qpmax <integer>	qp_max=<1-51> (ABR or two pass)	51
Maximum Quantizer Delta: 連続フレーム間における量子化値の最大変動幅	--qpstep <integer>	qp_step=<1-50> (ABR or two pass)	実写4 アニメ8
Credits Quantizer: For use if you set the credit starting point in the preview window.	不詳	不詳	不詳
Factor Between I and P frame Quants: IフレームとPフレームの量子化値換算係数。Iに適用された平均量子化値にここの値を掛けたものがPに適用される。	--ipratio <float>	ip_factor=<value>	未指定(default)
Factor between P and B frame Quants: P フレームとBフレームの量子化値換算係数。Pに適用された平均量子化値にここの値を掛けたものがBに適用される。	--pbratio <float>	pb_factor=<value>	未指定(default)
Chroma QP Offset: 輝度に適用する量子化値と彩度に適用する量子化値のオフセット。	--chroma-qp-offset <integer>	chroma_qp_offset=<-12-12>	未指定(default)
Quant Options
Trellis: Trellis RDO の適用。最終マクロブロックのみか、常時かを選択。要CABAC	-t, --trellis <integer>	trellis=<0-2>	2 要CABAC
Number of Reference Frames: 複数参照フレームの最大数。	-r, --ref <integer>	frameref=<1-16>	1st,(turbo) 2nd,4
Mixed: マクロブロック・パーティション単位で参照フレームを個別に選べるようにする。	--mixed-refs	(no)mixed_refs	mixed_refs (使用)
CABAC: 圧縮効率の高い encoding stream syntaxを使う。	--no-cabac	(no)cabac	cabac(使用)
No DCT Decimation:	--no-dct-decimate	(no)dct_decimate	nodct_decimate (非使用)
No Fast P-Skip: スキップ検出の非使用。画質向上	--no-fast-pskip	(no)fast_pskip	nofast_pskip (非使用)

Quantization matrix: 使用するカスタム量子化マトリクスを指定。You must specify the custom matrix. （＊mustの意味不明＊）	--cqm <string> --cqmfile <string>	cqm=<flat\|jvt\|<filename>>	JVT
Macroblock Options: 各マクロブロックパーティションの使用可否	-A, --partitions <string>	partitions=<list>	1st,(turbo) 2nd,all
B-Frames:
Number of B-Frames: B-Frames (B-VOPs)の最大連続数	-b, --bframes <integer>	bframes=<0-16>	3
Adaptive B-Frames: B-Frames の連続枚数を映像内容に応じて自動調節。	--no-b-adapt	(no)b_adapt	b_adapt (使用)
B-Pyramid: B-Frames も参照フレームに使う	--b-pyramid	(no)b_pyramid	b_pyramid (使用)
RDO for B-Frames: B-Frames にRDOアルゴリズムを使う	--b-rdo	(no)brdo	brdo(使用) 要subq=6以上
Weighted Bi-Prediction: B-frames を参照フレームに使うかどうかの精度が高まる	-w, --weightb	(no)weight_b	weight_b (使用)
Bidirection ME: 動き予測の精度最適化に前後両方向の時間軸を使う。	--bime	bime	bime (使用)
B-Frame Mode: B-Framesのモーションベクトル予測方式。Autoでフレーム毎に最適な方式を選ぶ。	--direct <string>	direct_pred=<name>	auto
B-Frame bias: B-Framesの挿入傾向を調整。高い程Bを使う傾向が増える。低い程減る。	--b-bias <integer>	b_bias=<-100-100>	未指定(default)

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

「H.264/AVCにおいても縦横は16の倍数でなければならない」について

1. 『H.264/AVCは縦横とも16画素の倍数でないと符号化できない』

改訂版H.264/AVC教科書、p183
※太字オレ
例えばHDTVの場合、走査線の数は1080本です。これに対してH.264/AVCでは垂直、水平方向とも16画素の倍数でないと符号化できません （1080本は16の倍数ではない）。例えば、1088本（16の倍数）を符号化した場合、8ラインを捨てて表示する必要がありますが、この場合、クロッピング処理によって、ビットストリーム中でどの上下8ラインを捨てるのかを明示的に指定する事ができます。

　※この「明示的な指定」は、x264cli、VUI設定の--overscanで行う（参考1, 2）。

2. 8x8や4x4は16x16マクロブロックのサブ区分と思われる

Introduction paper to H.264/MPEG-4 AVC includingthe Fidelity RangeExtension. （PDF）
2. 符号化ツール（試訳）
各ピクチャは一個以上のスライスに分割することで圧縮される。各スライスはマクロブロックからなる。さらにこれは16x16ピクセルの輝度サンプルと、それに対応する輝度サンプルからなる。しかしながら（＊これまでとは異なり＊）各マクロブロックは、動き補償予測の為に、さらにサブ・マクロブロック・パーティションに分割される。予測パーティションのサイズは７種類となる。 – 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 そして4x4だ。これまでの規格では、動き補償はマクロブロックを丸ごと使うか、新しめの規格では16x16 か8x8パーティションを使った。従って、パーティションの形にバリエーションが増えたという事は、予測精度の向上をもたらす。次に、残ったデータは 8x8（FRExtでしか使えない）か4x4で空間軸変換される。過去の主要規格ではこの変換ブロックサイズは8x8のみだった。4x4ブロックサイズの採用で残りの差分信号の精度が向上する事になる。空間軸変換のブロックサイズは常に予測に使われるブロックサイズと同じか、より小さい。ビデオシークエンスのシークエンスからサンプル（*原注：ここでは特にサンプルとピクセルを区別しないが、厳密にはサンプルが正しい。）に至る階層構造は以下のようになる。

シークエンス（ピクチャ（スライス（マクロブロック（マクロブロック・パーティション（サブ-マクロブロック・パーティション（ブロック（サンプル））））））

ニコンシステム(株)H.264 解析ツールNH264H1のpdf
http://www.nikon-sys.co.jp/products/index_1_1.htm

　※これらから、4x4や8x8は16x16に対するサブ区分と思われる。一番右下、田の字型に分割されてるのが8x8だと思う。

3. cropやscaleで縦横を8や4の倍数にするとMEncoderはエラーメッセージを出す。
　ただしエンコードは進行する。

4. Xvidやlibavcodec mpeg-4では、縦横16倍数は鉄のオキテ

MEncoder Document/ DVD映像を高画質なMPEG-4 ("DivX")にする方法/効果的にエンコードするための制限事項（試訳）
最高画質を追求する場合、MPEG系圧縮の特徴からくるいくつかの制限事項を守る必要があります。MPEGは映像をマクロブロックと呼ばれる16x16の正方形に分割します。各マクロブロックは、輝度（強度）情報を表す4個の8x8ブロックと、2個のハーフ・レゾリューション8x8ブロック（red- cyan 軸とblue-yellow軸）で構成されます。手許の動画の横幅と高さが16の倍数でない場合でも、エンコーダは映像全体をカバーできるだけの 16x16マクロブロックを使うので、余聞な無駄が出ます。
ですので、目標ファイルサイズの範囲で最高画質を求める場合は、16の倍数以外の縦横は使わないようにしよう。

　※Xvidやlibavcodec mpeg-4では、入力映像の縦横が16の倍数でなかった場合、勝手に16の倍数まで映像領域が「あるものとして」エンコードする。
　　自分はこれを訳す過程で、16倍数はMPEG-1/2/4 に跨がる鉄のオキテと認識した。AVC | H.264においても三つ子の魂で。テストはしていない。

5. 少なくともx264では、画質への影響は軽微らしい。

2ch/DTV/x264 rev7（2006年11月下旬～12月上旬）

やっぱり16の倍数じゃないとダメっぽいとあったのですが、みなさんは16:9の映像の場合どのような解像度にしていますか?

704x480(DVD左右クロップ) --sar 40:33

自動的に無効領域が追加されて16の倍数になるから問題なし

俺も気にしてないな。画質は全然落ちないし

俺は気にしてる。16の整数倍にしないとなんとなく暗部とか薄いグラデーションとかでブロックノイズ増える気がする。ただの気のせいかもしれないけど。

画質に関しては関係ないと思うけど、16の倍数だと動画の圧縮率や精度が向上するのは確かだと思うよ

　※画質的な問題を感じている人はほとんど無いようだ。
　※ただし、上記1.2.3.補足的に4.までは16倍数制限の存在を明示、または示唆している。
　　2ch/Doom9ともに、アニメ派が中心な事も一応さっぴいて考えるべきかと思う。手許でもアニメのほうが多いっつうのはともかく。

6. さしあたっての結論
　H.264/AVCは、縦横が16の倍数でなかった場合でも、バリエーションが増えたマクロブロック・パーティション（x4 .. x8 .. x16）を駆使して、画質への影響をある程度封じ込める事ができると思われる。
　実用上の画質劣化は、少なくともx264では、無視できる範囲と思われるが、程度は素材に依り異なるだろう。

余談
　アニメの情報量は非常に少ない。基本だけど。
　人間の脳が受ける「印象」のハナシではなく、必要bit量とでも言うか、ともかくCPUから見てのハナシ。
　アニメの場合、なにがどうだろうと、単色のっぺりの「アニメ塗り」が映像に占める割合が多い（実写に比べてディテイルが圧倒的に少ない）。
　背景やテクスチャの精細さが際立って見える作品も多いが、その印象は前景のキャラが「アニメ塗り」だからだ。
　キャラクタの顔に皺や毛穴やニキビは無いし（この点、役者がドーラン塗りまくってる初期のカラー映画は結構圧縮しやすい）。
　着物の質感というのもまず無い（例外）。

[ 2007/01/21 00:00 ] 動画　MPEG-4全般 | TB(0) | CM(0)

「象の鼻は長い」

　英語を試訳しようってときには主語がうざい。
　主語と述語の関係に気をつけないと誤解の幅が広がるし、さりとて略さなければ日本語として読みづらい。自分の文章力は棚にあげるとしても。

『主語を抹殺した男　評伝　三上章』金谷武洋著（朝日新聞朝刊　書評欄：2007年1月21日）
※太字オレ
　昔、私は、日本語には主語と述語があり、時に主語は略せると習った記憶が有る。略すと言うのは元より在るのが前提だが、三上文法はそうではない。日本語にはそもそも主語なんてないというのである。半世紀近く前に刊行された著書『象の鼻は長い』はロングセラーとなった一冊。
「は」という助詞が、主語でなく主題を示すものであり、句点を超えて次々と文にかかっていく重要な係助詞であることが強調されるなど、
（＊中略＊）
　著者（＊モントリオール大学日本語科長・金谷武洋＊）は三十数年前に、留学先のカナダで現地の学生に日本語を教えることになったとき、この三上文法に出会い、（＊中略＊）外国語として日本語を教えるとき、もっとも役立つのが三上文法だったという。

　太字のところ、３０回くらい読んだ。略そうなどと考えるからアウト？先頭に主題を明示して、あとは主語なんて忘れろ？
　そもそも著書とか著者とか「誰」を指すのか書いてない。とくに著者のほうは、この記事が書評であるという前提で、記事タイトルの「金谷武洋著」に目をやらないとわけわかんねぇ。「主題」が示してあるというよりは、文脈から読み取らせろってカンジ？。主題の明示にはレイアウトも駆使しろ？

　「象の鼻は長い」はそのスジでは有名な例文のようだ。

「～は～が～」構文について（最終更新日：2003年12月15日）
スタイルシートに
h1{color:red}
こう記すと、一番大きい見出しの文字の色が赤になる。この記述は「h1は色が赤い」と読めるではないか。
（＊中略＊）
コンピュータ言語のスタイルシート風に表せば、
Zoo{Hana:Nagai}
となろう。

h1 { margin:30px; font-size:30px; text-align:center; color:red; font-family:Osaka;  }

　「h1は、マージンが30px、フォントサイズが30px、テキスト揃えが中央、色が赤、フォントファミリーがOsaka」。
　「は」という助詞が、主語でなく主題を示すものであり、句点を超えて次々と文にかかって、る。
　selector（セレクタ）とかdeclaration（宣言）とかproperty（属性）とかvalue（値）とか、言うより、肚に落ちる。

　Selector H1 have property P1 whose value is V1, property P2 whose value is V2, and property P3 whose value is V3.

　いや、文法的には絶対間違ってるけど、このくらい冗長には、なる。
　実はすっげえ符号化効率良くねぇ？。日本語。今北産業とか。

　ところで韓国人がやたらと英語が巧かったり、プログラミングがシュアで早かったりするのはなんでだ。構造は、ほぼ世界で唯一の兄弟言語なんだが。
　なんか独特の英語習得法でもあんのか。

参考

■[その他]『主語を抹殺した男』（小田中直樹［本業以外］ネタ帳： 2006年12月23日）
■ 『主語を抹殺した男評伝三上章』象は鼻が長い（本と音楽のクロスオーバー情報サイトＳＭＡＲＴ：2007.1.6）
[PDF]三上章の主語・主題論

[ 2007/01/21 00:00 ] INBOX　未分類 | TB(0) | CM(0)

070118-ふたつのスピカ

エンコードの概要

PowerMac G5 (2Ghz x 2), mem1GB。
MEncoder/x264のビルド日は2007/01/20（x264 core:54 svn-618M）。
映像ビットレート1024kbps, 2パス, アニメは24000/1001fps, 実写は30000/1001fps, lanczos 3
HighProfileの為、再生はVLC、MPlayer（OSX）、QuickTime Player + avc1Decoder。（iPhone/AppleTV不可）

VGA(640x480)

タイトル	FPS1	FPS2	FPS	I枚数	I比率	Avg_QP_(P)	PSNR_(Grobal)	Ssim	I16x16	I8x8	I4x4
ふたつのスピカ_01_打ち上げ花火	21.37	7.01	5.28	284	0.63%	16.90	47.49	0.991	6.5%	67.7%	25.8%
ふたつのスピカ_02_アスミの夢	21.15	6.83	5.16	301	0.67%	16.72	48.19	0.993	7.5%	63.5%	29.0%
ふたつのスピカ_03_星への一歩	22.45	6.78	5.21	301	0.67%	16.52	48.70	0.994	8.6%	62.2%	29.2%
ふたつのスピカ_04_遠い日の記憶	17.25	6.06	4.49	297	0.66%	15.91	49.05	0.994	8.0%	61.9%	30.0%
ふたつのスピカ_05_おかあさんの顔	22.78	7.40	5.58	284	0.63%	16.43	48.27	0.993	5.0%	70.2%	24.8%
ふたつのスピカ_06_テスト終了	20.99	6.61	5.03	298	0.66%	16.38	48.82	0.994	7.6%	65.4%	27.1%
ふたつのスピカ_07_宇宙学校入学式	20.65	6.07	4.69	326	0.73%	17.25	47.77	0.993	6.6%	67.7%	25.7%
ふたつのスピカ_08_ひとりの夢みんなの夢	21.02	5.51	4.36	316	0.70%	17.93	47.31	0.992	6.6%	67.7%	25.6%
ふたつのスピカ_09_カムパネルラの森	15.47	5.93	4.29	281	0.63%	16.72	48.23	0.993	4.2%	71.1%	24.7%
ふたつのスピカ_10_水の中にも宇宙	22.35	7.31	5.51	290	0.64%	17.16	48.18	0.993	7.8%	66.0%	26.2%
ふたつのスピカ_11_傷ついた翼	20.69	6.83	5.14	293	0.65%	17.09	47.49	0.992	7.0%	66.2%	26.8%
ふたつのスピカ_12_ふたりの星はっぱ星	22.49	7.33	5.53	305	0.68%	17.61	47.27	0.992	5.1%	72.7%	22.2%
ふたつのスピカ_13_約束の５人	20.62	6.46	4.92	307	0.68%	17.35	47.40	0.992	7.5%	66.3%	26.2%
ふたつのスピカ_14_悲しい笑顔	22.37	7.43	5.58	321	0.71%	18.28	46.71	0.991	6.7%	67.1%	26.2%
ふたつのスピカ_15_ひとりぼっち	19.20	6.35	4.77	308	0.69%	17.04	48.15	0.993	7.6%	67.9%	24.5%
ふたつのスピカ_16_アスミの桜	22.20	7.02	5.33	290	0.65%	16.80	48.38	0.993	7.7%	69.3%	23.0%
ふたつのスピカ_17_サバイバル訓練	21.26	6.94	5.23	310	0.69%	16.76	48.07	0.993	6.3%	66.5%	27.3%
ふたつのスピカ_18_マリカとまりか	20.59	6.23	4.78	301	0.67%	16.85	47.97	0.992	4.3%	70.4%	25.2%
ふたつのスピカ_19_いま君にできること	20.12	6.20	4.74	295	0.66%	17.06	47.70	0.992	5.1%	68.7%	26.1%
ふたつのスピカ_20_明日を見つめて	21.70	7.12	5.36	296	0.66%	17.43	47.42	0.992	4.6%	72.6%	22.8%
平均	20.84	6.67	5.05	300	0.67%	17.01	47.93	0.992	6.5%	67.6%	25.9%

　※平均時間は１st：0:36.15。2nd：1:53.03、合計：2:29.19。

060831-結果篇や、060915-結果篇と比べると速度は大幅に向上している。

SSIMは全て0.98以上、数値的には「オリジナルと区別がつかない」レベルだが、実際にはそんな事は無い。

　石段や茂みの質感を素材と比べると結構違う。
　アニメの部分はpullupで24fps化してしまえば良いものの、時報や局ロゴはNTSC(29.97fps)だからpullupだけではジャギが目に五月蝿い。この素材ではそんな事は無いようだったが、CGの花火もNTSC(29.97fps)合成のケースもある。自分的には空間軸fps混在と呼んでいる。

　これらに対処するため、手許ではpp=l5を重ねている。単独でも性能を発揮するインタレ解除フィルタなので厳密にはやや強すぎるだろう。

　素直にインタレ保持エンコすりゃいいのだが、それでは面白みが足りない。いずれにしても五月蝿い事を言えば、というレベルのハナシ。

　なお、フレーム単位でぱたぱたと動く暗階調のブロックノイズは主観的にはほぼ気にならないレベルに抑え込めている（無くはない）。

設定概要

基本方針は、1stはフレームタイプの決定と大まかなレート配分統計が取れれば良いとの考えから、重そうなオプションを2ndにまわす方針をさらに徹底し、threadsと合わせて全体的な高速化を得る。です。

$ mencoder ふたつのスピカ_20_明日を見つめて.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:turbo=1 -passlogfile ふたつのスピカ_20_明日を見つめて.264.log -vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::3,hqdn3d=4:3:6,harddup -sws 9 -ofps 24000/1001 -of rawvideo -o /dev/null

$ mencoder ふたつのスピカ_20_明日を見つめて.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=all:trellis=2:brdo:bime -passlogfile ふたつのスピカ_20_明日を見つめて.264.log -vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::3,hqdn3d=4:3:6,harddup -sws 9 -ofps 24000/1001 -of rawvideo -o ふたつのスピカ_20_明日を見つめて.264

threadsを、実験結果に基づき、1stは2、2ndは16にした。
qp_stepを、なるP氏の設定例に倣って、8にした（アニメのみ、実写はデフォルト値で行くつもり）。
me_rangeを、なるP氏ほかの知見に倣って、2ndのみ32にした。
partitionsを、MEncoder Documentsに倣って、2ndのみallとした（1stはturboのプリセット値）。
8x8dctを、1stはGOP設定のみとの考えから、2ndのみとした。
cqm=jvtはレート配分に与える影響が大きいと考え、1stにも残した。

課題

I8x8の多さから考えて1stにも8x8dctを使うべきかも知れない。
　turbo=1の内容は以下の通りと思われる。

subq=2:frameref=1:partitions=p8x8,i8x8,i4x4:

turbo=1はpartitions=i8x8を含むので、8x8dctはturbo=1と併用する意味がある。要実験。

特記事項

faacはあんま性能が良く無いそうなので、音声を192kbpsにしてみた。

===FFMPEG_AUDIO===
$ ffmpeg -i ふたつのスピカ_01_打ち上げ花火.264 -i ふたつのスピカ_01_打ち上げ花火.mpeg -y -vn -f mp4 -acodec aac -ar 48000 -ac 2 -ab 96 -map 1.1:0.0 ふたつのスピカ_01_打ち上げ花火.aac.mp4

確かに128kbpsでは目を閉じて素材と聞き比べるとあれれなカンジがあった。上を見ればキリが無いが、これの歌が結構好きなので。
　究極的には素材のMPEG1 audio layer 2を、そのまま.mp4にコピーできる筈ではある。

[ 2007/01/21 00:00 ] 動画　圧縮日記264 | 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)

EvalVid - MP4Box - GPAC version 0.4.3-DEV

http://www.tkn.tu-berlin.de/research/evalvid/

　中程より下、Pre-compiled binariesのところにPPC版がある。学術的なコデック比較の為のサイトっぽいので直リンは控えます。そうした性質上、頻繁にアップデートされるというものでも無さそうです。

GPAC library static (Mac OS X / PPC) - CVS 21.10.2006
MP4Box - statically linked (Mac OS X / PPC) - CVS 21.10.2006
ffmpeg - statically linked (Mac OS X / PPC) - SVN 21.10.2006

※何れもffmpegX0.0.9x同梱版より新しい。

mp4box

バージョンは0.4.3-DEV

$ /Users/USERNAME/Desktop/EvalVid/MP4Box -version
MP4Box - GPAC version 0.4.3-DEV
GPAC Copyright: (c) Jean Le Feuvre 2000-2005
 (c) ENST 2005-200X

General Optionsだけ見てみたが、ほぼ、MP4Box Documentationと内容が揃っているようだ。注目は-par。

$ /Users/USERNAME/Desktop/EvalVid/MP4Box -h general
General Options:
//
 -par tkID=PAR: sets visual track pixel aspect ratio (PAR=N:D or "none")

MEncoder -x264encoptsに無い--sarをmux時に後付けできそう。いや、実は720x480のままでスケーリングしなけりゃMEncoderが自動でx264 [info]: using SAR=8/9ってしてくれるんだけども。

ともかく、手許で使っていたmp4boxのコマンドはそのまま通るので、720x480で作り、PAR指定だけ追加してみた。

===MENCODER_PASS1===
/usr/local/bin/mencoder CM_pan720x480.mpeg -nosound -ovc x264 -x264encopts てきとう -vf yadif=2,pp=l5,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o /dev/null
 
===MENCODER_PASS2===
/usr/local/bin/mencoder CM_pan720x480.mpeg -nosound -ovc x264 -x264encopts てきとう -vf yadif=2,pp=l5,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o CM_pan720x480.264
 
===FFMPEG_AUDIO===
/usr/local/bin/ffmpeg -i CM_pan720x480.264 -i CM_pan720x480.mpeg -y -vn -f mp4 -acodec aac -ar 48000 -ac 2 -ab 64 -map 1.1:0.0 CM_pan720x480.aac.mp4

===MP4BOX_--mux===
/Users/USERNAME/Desktop/EvalVid/mp4box -fps 29.970030 -par 1=8:9 -add CM_pan720x480.264 -add CM_pan720x480.aac.mp4 -new CM_pan720x480.mp4

===MP4BOX_--info=== 
/Users/USERNAME/Desktop/EvalVid/mp4box -info CM_pan720x480.mp4
* Movie Info *
 Timescale 600 - Duration 00:00:29.795
 Fragmented File no - 2 track(s)
 File Brand isom - version 1
 Created: GMT Sun Jan 28 04:53:28 2007

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD

Track # 1 Info - TrackID 1 - TimeScale 30000 - Duration 00:00:29.796
Media Info: Language "Undetermined" - Type "vide" - Sub Type "avc1" - 893 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 720 x 480 - Profile High @ Level 5.1
NAL Unit length bits: 32
Pixel Aspect Ratio 8:9 - Indicated track size 640 x 480
Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:00:29.653
Media Info: Language "Undetermined" - Type "soun" - Sub Type "mp4a" - 1390 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

スクリーンショット50%縮小

１	２	３

VLC 0.8.6a 720x540で表示。横幅に合わせて縦を拡大している。 720x576のPALに合わせた挙動なのだと思う。素材のMPEG-2もこうなる。	QuickTime Player Pro 7.1.3 + avc1 Decorder 0.6.0 720x480そのままで表示。これは「国際標準規格」準拠の動作では無い。素材のMPEG -2は640x480で表示する。	Lanczos4使用、640x480で作成したもの。 640x480で表示。

　QTの林檎+Jで"ビジュアル設定"を見ると、"表示サイズ"は720x480のまま。なんだか良く解らない。これSARと違うのか。とりあえずおいといて、、、

　主観的な「画質」は640x480（上記３のファイル）のほうが良かった。

　bitrateはどちらも同じなのでその分の差はあるが、インタレ解除とデノイズは同一。
　VLCで比べた感想としては、迫力は表示面積の大きい720x480の方が上なものの、奇麗さでは640x480の方が良いと感じた。720x480 は地味に文字がボケる。ボケはコマによって変動し、時に目にうざい。文字以外の部分でも同様の現象がおきているようで、それで全体的になんとなく画質が悪いと感じたのだと思う。全画面表示では38,400画素の差がある720x480の方が有利かと思ったが、面白い事にさらに差が目立った。

　720x480維持のほうが素材に"忠実"なのだが、実感としてはハテナな感じ。そういえばDoom9氏も640x480を推奨していたような記憶が、、、。

　VUIを使うと言う事は、再生時にリアルタイム拡縮が入ると言う事だ。
　もちろん家電プレイヤはハードウェアでリアルタイム拡縮をやるわけだし、Winでも正しくグラボを設定すればできるようだ。これが--sar指定付き 720(or 704)x480の人が多い理由だと思う。その方が素材に"忠実"だし、たぶんそれで問題の無い画質になるのだろう。インタレ保持で作るにも便利だし。

　だがMacで同じ事ができるとは期待し難い。モデルに拠ってはWinに遜色の無いグラボが付いてはいるものの（おいらのはショボイ）、Apple の垂直統合ビジネスモデルでは、ドライバもファームウェアも基本的には門外不出だ。最悪の場合、TerraSoftがYDLの開発でやってたように、モデル毎に搭載ハードウェアにリバースエンジニアリングかける事になりかねん。
　もちろん、グラボの差を吸収してくれるCoreVideo APIをVLCやQuickTime Player Proがバリバリにを使い倒すのを待つという道もあるが、何年もかかる。

　エンコ時に手間かけて、スクエア・ピクセルで4:3や16:9に直してしまう方が良いように思った。

ところで、なんでオレはハウステンボスの宣伝してるんだ？

[ 2007/01/28 00:00 ] 他ツール　mp4box(gpac) | TB(0) | CM(0)

プラットホーム

種類	比率
Win	84.21%
Mac	11.53%
Linux	3.75%
その他	0.52%

　Mac比、下がったまま。MeGUI Guide_x264の設定とか書いてるから当然だが、tag: x264(r600)コマンド対応の威力もいまだに大きい。
　Macではそのまま役に立たず、*nix使いから見ればレベルが低いという事だろう。

Mac

種類	比率
PPC	68.78%
Intel	31.22%

Win

種類	比率
XP	85.64%
2000	11.47%
98	0.97%
Server 2003	0.95%
Vista	0.79%
ME	0.10%
NT	0.08%

[ 2007/01/31 00:00 ] ABOUT　人気記事 | TB(0) | CM(0)

| ホーム |
Page Top↑

Index

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

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

-G-

-A-

タグ検索

カテゴリー

Script by 絵板のマナー講座
and 毒吐きネットマナーPlus

Archive R

2013 09 (1)
2008 02 (1)
2007 11 (11)
2007 10 (12)
2007 09 (6)
2007 08 (212)
2007 07 (2)
2007 06 (8)
2007 05 (16)
2007 04 (22)
2007 03 (23)
2007 02 (17)
2007 01 (20)
2006 12 (24)
2006 11 (41)
2006 10 (39)
2006 09 (22)
2006 08 (17)
2006 07 (4)
2000 02 (1)

管理/なかのひと

StyleKeeper

StyleChanger

タイトル	メモ
ageha
カテゴリ：-x264encopts	MEncoderのx264オプション関連
tag:H.264/AVC	H.264/AVC 規格関連
Lanczos 3、 Lanczos 4とはなんぞや
tag: x264(r600)コマンド対応	MEncoderと x264cliのx264オプション対応 MEncoder向けに作り直さねば自分の役に立たない。コメントも途絶えたようだし、そろそろ整理。
カテゴリ：mencoder
カテゴリ：動画全般
MeGUI Guide_x264の設定	包括的なMeGUIガイドの需要は結構ありそうだ。 C#, .NETで開発されているため、mono経由でMac OSXに移植される可能性がある。 AviSynth も3.0でLinux対応の見込み（手許でもconfigureスクリプトまでは動く）。 DGIndex、BeSweet不詳。
MPEG -4の基礎5 - ISO 14496-10 (ビデオ) -AVC
縦横（アスペクト）比

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

070105追記： threadsは最大16

PowerPC G5 (2GHzx2)の場合

4 core Xeon 5160の場合

Windows固有の問題？

070117追記：MEncoderマニュアル改訂

エンコード十戒

前 世紀

2005年まで

2006年

ま とめ

ぜんかいのあらすじ

どうがきょうゆうサービスについて

どうがきょうゆうサービスのポイント

つかってみたかんそう

けつろん

1. 「著作権」という漢字には人を平伏させる効果があります。

2. 日本の著作権法は欧米のコピーライト概念を明治時代にそのまま翻訳したものが元になっている。

３. 拝啓天皇陛下様

1. イントロダクション

1.1. クール・ジャパンはカネになってない

1.2. 日米における放送事業者のスタンス

2. 実際の製作者よりインフラ保有者 のほうが圧倒的に強い日本

3. アニメの作り手に適切な報酬は渡っているか？

4. 流通経路が「作品の権利」を持つとどうなるか

5. むすび

1.無敵看板娘

2. ゼーガペイン

エンコードの概要

VGA(640x480)

VISTA(640x352)

設 定概要

課題

PSNR：

SSIM：

大きい脂肪質の警告。

MeGUI概要

x264の設定項目

Page 1 - General options

Page 2 - Zones and custom commands

Page 3 - Rate control, motion estimation and GOP

Page 4 - Advanced settings

エンコードの概要

VGA(640x480)

設定概要

課題

特記事項

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

コンテナ

ビデオストリーム

オーディオストリーム

字幕（Subtitle）

そのほかの要素

アタッチメント

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

チャプタ

Ordered Chapters

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

一般的なコンテナ

AVI

FLV

OGM

MKV

MP4

Common Video Formats

MPEG

MPEG-1

MPEG-2

MPEG-4 SP

MPEG-4 ASP

MPEG-4 AVC

h26_

h263

h263+

h264

Snow

Theora

On2

VP3

VP6

前世紀

まとめ

2. 実際の製作者よりインフラ保有者のほうが圧倒的に強い日本

設定概要