画質の構成要素その１「視覚の個人差」

　エンコードに手を出す以上、画質の善し悪しはわりと重要だと思う。
　まぁ趣味の世界だから最終的には「感性の問題」「自分は満足」で充分なのだが、そればかりでもナニだ。
　そこで画質の構成要素を素人ながら一応分解してみようとおもいます。
　「視覚の個人差」を「感性の問題」に入れちゃマズいかなぁと思って。あんまり気にするのもいろいろとナニです。

1.視覚の個人差

視力
動体視力
色覚
脳の処理能力

　1～3は周囲の明るさや光源の色で変化する。

1.1. 視力

　自分の視力を数値で把握していない人は稀だと思う。眼鏡などで簡単に補正できるので、多くの人は1.0程度はキープしていると思う。
　弱視 - wikipediaには「成人の場合は矯正視力が運転免許取得の条件の一つである0.7未満の場合を弱視と判断する医師もいる」とあり、A.A.O. - 弱視にまつわるエトセトラ -（2004年1月30日）では「矯正視力が0.3未満」としている。どちらも裸眼視力は問題にしていない。

　ブロックノイズの有無やそれが気になる・ならないの問題に関わる。ただし、意識する必要はないと思う。

1.2. 動体視力

　自分の動体視力を数値で把握している人は稀だろう。というよりそもそもその手法があるのか自分は知らない。
　ウソかホントか知らないが一流の野球選手は飛んでるボールの縫い目が見えるというし（民明書房だったらどうしよう）、自分は通常のTV視聴（ブラウン管）でインタレ縞が見える事がある。エンコード始める前は気にした事もなかったのだが、いや見えるったら見えるんだい。
　幽霊の、正体見たり、枯れ尾花。と言うべきか、ブラウン管上に存在しているのだから見えてもおかしくはないと言うべきか。
　鍛えればわりと簡単に向上するのだと思う。

　動きのカクツきや、インタレ縞の問題に関わる。気になる・ならないの「感性」で片付ける前に一応留意した方がよいと思う。

1.3. 色覚

　色覚は特に周囲の明るさや光源色の影響を受けやすい。プロはモニタにフードを付けるようだし、電球にも気を使うらしい。

　その他にいわゆる色弱という指標があるが、これは数量的なものではなく単なるラベリング～弱視かそうでないか程度のもの～だ。日本人男性の約95%、女性の99％以上は正常と言うのであまり考慮しなくても良いかとは思う。

　いちおう、色覚の仕組みと色弱者の呼称によると、網膜には赤・青・緑の三種の『錐体』があり、それぞれが特定の光の波長を検出する（分光感度）。赤錐体が無いとか、青錐体の分光感度がズレてるとかで、人間の色覚はいわゆる正常を含めて5種類7タイプある。ただし、血液型に種類があるようなものでどれが正常でどれが異常というものでは無いとしている。

　と言う事は、正常とされる95%の中にも「赤錐体の分光感度がちょびっとズレテマス、あと少しで色弱でしたねぇ」みたいな人から三色とも基準原基みたいな人まで、いろんな色覚を持った人がグラデーションみたいに分布してんだと思う。視力が0.3～2.0まであるように。

　面倒なので手許では色調整は一切しない事にしている。

　余談ながら『色の秘密（野村順一、文春文庫）』に皮膚もある程度光の有無や色に反応するとあった。健康には白い下着が一番ナノダソウデスヨ？（いやそっちへいっちゃダメだオレ）。

　弄る場合は人間の肌色を軸にすると良いらしいです。

1.4. 脳の処理能力

NTT Communication Science Laboratoriesの錯覚の解説内、視覚領第1野によると。

網膜の解像度は1000×1000程度。
それを受け取る脳細胞は100×100ほど。
腕をのばして見つめている爪は、10か20の画素で構成されていることになる。

　CCDが100万画素で画像処理チップが1万画素のビデオカメラという事になる。
　ハードウェアとしてはなかなか粗末な、、、てゆうか信じ難い。マジですか？。
　ちなみに聴覚のほうも鼓膜の性能からはありえない音を聞き分ける事ができるそうだ。
　上記サイトでは脳内で多数の信号に基づく統計処理が行われているのではないかとしている。

　統計処理は視覚領第1野よりももっと奥深くで実行されるのだと思うが、統計というからにはパターン蓄積が豊富なほど性能があがる筈だ。このしくみを解明して応用すればものすごい圧縮技術ができるであろ～。頑張ってもらいたい（誰に？）。インタレ解除にこだわるうちに通常のTVでインタレ縞が見えるようになった経験とも符合する。逆に統計処理である以上、この動体視力は他ではまったく役に立たないと思われる。ちぇっ。

　余談ながら、経験を重ねればモザイク除去装置ぬきでも見える説には一定の科学的根拠があると言えよう（だからなんだよう）。

スポンサーサイト

[ 2006/07/31 00:00 ] 動画　動画全般 | TB(0) | CM(2)

SSIMとはなんぞや

最終更新 2005/07/12 -- TheSSIM Index for Image Quality Assessment

TheStructural SIMilarity (SSIM)index is a novel method for measuring the similarity between twoimages. TheSSIM index can be viewed as a quality measure of one of the imagesbeing compared, providedthe other image isregarded as of perfectquality. It is an improved version of the universalimage quality index proposed before. A brief description ofthemethod canbe found here.More details are given in the following paper:

　試訳：

　構造的類似性（Structural SIMilarity）指数は二つのイメージの類似性を計測する新しい指標です（＊原文初出は2003/02＊）。SSIMは片方の画像が完璧な画質と考えた場合、比較対象となる画像の品質を測るモノサシと言う事が出来ます。SSIMは以前に案出された汎用画像品質指標の改善版です。SSIMの簡単な説明はここにあります。ここでは、より詳細な説明をします。

◆◇◆

　で、もちろん簡単な説明すらわかりゃしない。PSNRとは別の指標という事だろう。一応PSNRとは、ピークシグナル toノイズレシオ。高いほど画質が良いとされるが、人間の印象とは必ずしも一致しない。
　x264cliではデフォでSSIMを計測する。

 --no-psnr Disable PSNR computation
 --no-ssim Disable SSIM computation

　MEncoder -x264encoptsではなにもしなくてもログに出る（PSNRは明示的に指定しないと出ない）。
　PSNR・SSIM・VQMによる全CODEC客観的比較（BAL BAL NET - 2004/01/12更新）を見ると、これも高いほど画質が良いっぽい。
　MasaHaseさんのうぇブログのこの記事では、アニメ素材なら、ソースの解像度が720x480のときSSIMにして99～98%が狙える。主観でいえばオリジナルとの差が見分けられない。と表現している。
　手許のログを漁るとほとんどが99%以上だった。設定は1024kbps,2pass,横幅640固定。MasaHaseさんの2000kbps,3pass, 720x480と大差ないワケがないので、SSIMで気にすべきなのは小数点以下3桁目以降かも知れない。
　一応、060915-結果篇に追記したものは以下（その他の設定はおおむね060831-設定篇に同じ）。

VGA(640x480)

種	タイトル	I枚数	I比率	Avg QP (P)	PSNR (Grobal)	SSIM
-	平均	526	0.89%	19.97	45.74	0.9903196
A	無敵看板娘_FW_07	463	0.99%	19.77	45.36	0.9901443
A	無敵看板娘_FW_08	439	0.98%	20.36	45.26	0.9892927
A	無敵看板娘_FW_09	464	1.03%	19.15	46.26	0.9909509
A	無敵看板娘_FW_10	455	1.02%	20.04	45.36	0.9899225
R	BSアニメ夜話_23_鋼の錬金術師	783	0.79%	20.48	45.97	0.9903982
R	BSアニメ夜話番外編「アニメの時間よ永遠に」	553	0.51%	20.02	46.24	0.9912088

VISTA(640x352)

種	タイトル	I枚数	I比率	Avg QP (P)	PSNR (Grobal)	SSIM
-	平均	386	0.87%	14.21	49.47	0.9936473
A	コヨーテラグタイムショー_FW_07	432	0.98%	15.14	48.71	0.9924971
A	コヨーテラグタイムショー_FW_08	347	0.79%	14.33	49.13	0.9929892
A	コヨーテラグタイムショー_FW_09	380	0.86%	14.32	49.37	0.9933534
A	コヨーテラグタイムショー_FW_10	403	0.91%	15.10	48.96	0.9926276
A	コヨーテラグタイムショー_FW_11	427	0.97%	14.12	49.75	0.9934556
A	ゼロの使い魔_FW_07	383	0.90%	15.62	48.28	0.9926050
A	ゼロの使い魔_FW_09	367	0.85%	14.63	48.86	0.9932632
A	ゼロの使い魔_FW_10	384	0.89%	14.65	49.08	0.9936109
A	僕等がいた_FW_07	416	0.89%	13.01	50.40	0.9952227
A	僕等がいた_FW_09	343	0.73%	12.11	51.29	0.9954948
A	僕等がいた_FW_10	362	0.77%	13.24	50.31	0.9950015

疑問

小数点以下7桁も出るので、重要なのは小数点以下３桁目以降と思われる。たぶん99%切ったら論外くらいのイキオイ。私大文系としてはそこを強調する表記方法が欲しいところではある。小数点計算で7桁目の精度は一応用心して切り捨て、VISTA平均99.3647%、VGA平均99.0319%。とか。
手許ではインタレ解除もデノイズもかけてる。MEncoderとx264の関係上、SSIMの比較対象は元画像ではなく、-vfチェインが吐き出した後のデータではないか。winは持ってないが、たぶんAviSynthの出力だろう。

MEncoderのログはY（輝度信号）の平均SSIMを出しているように見える。UVは出ないっぽい。

x264 [info]: SSIM Mean Y:0.9880310
x264 [info]: PSNR Mean Y:44.499 U:48.195 V:49.478 Avg:45.514 Global:45.450 kb/s:1024.56

　主観的な画質はあまりにもいろいろな要素に左右されるので下手に書くのは躊躇われるのだけれど。自分としてはAvg QP(p)が最も肚に落ちる。
　アニメで20以下はbitの無駄。実写の20はもうちょいなんとかなんないかな、といったところ。噺家さんの着物の質感とか、きっといーもの着てるんだろうに潰れちゃってるなって感じ。まぁ言い出すとキリないし、bitrate上げる気もないんだけど。さらにさらに主観的には-x264encoptsより-vf チェインのほうが影響デカイ。

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

■MPEG-4 SP/ASP時代（2000～2004）

総括

　MPEG-4 ASPビデオの隆盛は概ね2000年を境に始まった。
　DVDのプロテクトは1999年に破られた。その後イロイロあって（おいらDVD触らないから別にどーでもいい）、
　2004末の北米ではCDドライブの一つも買えばDivXと3ivxがオマケで付き、家電売り場ではDivX.avi対応のDVDプレイヤが主流という状態になっていた。
　この状況はMicrosoftのDNAがもたらした偶然の産物と考える。彼らが後方互換性を考慮せず、全てのユーザーにDirectShowへの移行を強制し、それを強力に保護し、vfw/AVIをシステムから取り去っていたら、ジェローム＝ロタ（gej）がMsMPEG4をクラックするような事は無かっただろう。ネットがあろうが無かろうが、それが普及する事も、オープンソースの開発が進む事も無かったと思う。
　事実上、全ての母体となったのはvfw/AVIインフラだ。放置されたvfw/AVIが、フリープログラマー達の、枯れて、安定した、自由な、遊び場となった。

年表

　※細部はかなり乱暴に端折ってあります。先人のみなさんは怒らないで下さい。

年	名称	主なコンテナ	インフラ	提供	備考
？	MsMPEG4	.asf	DirectShow	Microsoft 社	ISO-MPEG4 規格策定途上でMicrosoftが出したコデック。先制に出たのはいち早く.asfでデファクトを取る為だったと思われる。 .mp4コンテナにはQuickTime.movのパテントがあり、普及すれば同社はAppleにパテント料を払わざるを得ない。シェアから言って莫大な額となるだろう。 2006現在も同社は.mp4をサポートしないと明言しており、実際していない。同社は映像コデックのパテントを数多く保有しており、この点からもちんたら規格確定を待つより先行したほうが儲かる。性能は高かったようだ。.ASFは現在の.wmf。
？	divx;-) (aka divx3.11)	.avi	vfw	オープンソース？	MsMPEG4 の.avi非対応に怒ったおっさんがクラック。.avi用に公開。 Divx+MP3.aviの元祖にして、"リップしてエンコして放流"の端緒。出自と使われ方は黒い。
2000	MPlayer、開発開始（当時の名称はmpg12play）、2001にはOpenDivX のエンコードも可能になっている。
2000	3ivx	.mp4	DirectShow QuickTime	3ivx社	DivX代替を目指して設立された会社。『　Windowsでは、3ivxの強みは MPEG-4 Audio, Video, .mp4 ファイルフォーマットを扱ったり、DirectShow フレームワークの元で動くコンポーネントを幅広く取り揃えている。ソフトウェア開発者は3ivx フィルタを自分のアプリケーションに取り込み、完璧なMPEG-4サポートを備えたソフトを開発できる。　DirectShow 以外では、Mac OS と Windowsの QuickTimeアーキテクチャもサポート。Apple MPEG-4との互換性があり、3ivxコデックでMPEG-4 Videoのライブ配信ができる。』 http://htffmpegx.seesaa.net/article/3776508.html から孫引き　他にUnix/linux、BeOS、Amiga版まで取り揃え、最近だとソニーのロケフリの中の人だったりもする技術番長。真の国際標準規格伝道者。ザ・正統派。　マカーの間では最速のMPEG-4 ASPとして名高い。自分は"神速の"3ivxと枕詞をつけていますよ。
2000 ～ 2002	Divx 4 Divx 5	.avi	vfw QuickTime	DivX社	Divx３開発者の一部が会社設立。オープンソースではなくなる。成果を持ってっちゃったらしく、他のメンバーから反発をくらう。このへんちょっと錯綜。フルスクラッチでキレイなカラダになる。最初は拡張子.divxを使っていたフシがある。 DivX+MP3.aviの立役者の一人。
2002	mencoder誕生。デフォルトコンテナは2006秋現在もAVI。
？	Xvid	主に. avi	vfw QuickTime	オープンソース	Divx３残党によるオープンソース。 DivX社に対する対抗意識（明白な目標）と、需要あるところかならず誰かがパッチを書くオープンソースの特質がかみ合って着々と性能を上げ、 Doom9コデックコンテストでは僅差ながらDivXに勝ち続ける。2005にはマルチスレッドにも対応。MPEG-4 ASP 最強。
？	Apple-MPEG4	.mp4	QuickTime	Apple 社	ISO-MPEG4 規格策定を待ってApple社が出したMPEG-4 SPコデック。性能的に見るべきものは無く、「.MP4は始まる前から終わっている」とまで言われた。同社は映像圧縮に関するパテントを保有しておらず、登場時点でWin界では当たり前だったBフレーム（ASP）非対応など。 2005のQuickTime7でようやくB対応を果たしたが、既に安定して代役を果たしていた3ivxやXvidなどのASP QuickTime コンポーネントをミナゴロシにしてくれやがった上にエンコ性能もそれら以下という『バージョンアップの皮を被った優越的地位の濫用』。 Xvidだけならまだしもちゃんとパテント料払ってる3ivxさんになんてことを。
2004	私事。ふゆ：動画エンコなるもので遊ぼうとCaptyTVを買う。なつ：ffmpegXにおちつく。あき：高速化ソフトで怪しい文字列を見つける。ふゆ：ターミナルというものにそのまま打つと動く事に気付く。←ポイントオブノーリターン
2005	Divx 6	.divx	vfw？	DivX社	性能向上で XviDに遅れをとり始めたDivX社は他の分野に生き残りの道を探っているようだ。コンテナ形式の変更はその一貫。拡張子.divxはDVDメニュー的な要素や字幕・副音声などを付加するもので、コアの映像・音声はAVIを踏襲。従ってVLCではそのまま再生できる。ハードウェアXvid+MP3.AVI再生機の中にもそのまま再生可能なものがある筈だ。

■H.264/AVC 時代（2005～2010）

総括

　ASP時代とは動画エンコを取り巻く条件が結構ちがう。

【vfw/AVIの終焉】: 　vfw終焉の影響は広範囲に及ぶだろう。例えば、H.264/AVCコデックの数があんまり出揃わない。 vfw/AVIにとどまる人が比較的多い。など。いずれにせよ動画エンコの進化はちと鈍る。フリープログラマー達の、枯れて、安定した、自由な、遊び場はもう無い。プロプライエタリ企業の集金マシーン（DirectShowやQuickTime）の上で足掻くか、ゼロから整備する linuxに参加するかだ。; 　ただし、この事態が開発者の間で想定されてないわけも無く、既にwinでは移行の痛みを緩和する様々なエンコ環境の整備が進んでいるようだ。一例はMeGUI。
　内部的にはAviSynth（ビデオフィルタ）、MEncoder（統合エンコ環境）、x264cli、Besweet（音声全般）、mp4box （.mp4コンテナmuxer）などの詰め合わせで、方向としてはffmpegXに近い。Mac/linux/Winはオープンソースをベースに、ある程度共通の動画インフラを持つ事になるかもしれない。
【動画需要の変化】: 　YouTube.flv/PodCasting; 　少なくとも2010までのコンピューテングは「ブラウザがあればあとは要らない」が軸になる。コンテンツ側の軸がCGMであるならば、それは既に動画の内容にも波及している。鮮度と話題性が命。画質は問われない。SDならミドルクラスCPUでCDリッピング並の速度が欲しいところだが、それならMPEG-4 ASPで十分。軽薄短小。それがweb2.0。; 　H.264/AVCはこのトレンドに逆行する。
【知的財産権サイドの戦術高度化】: 知的財産権サイドはDVD/MPEG-4 ASPから戦訓を得た。総じて「自宅PCでのエンコード」はより高度化した『アメとムチ』に直面する。

年表

年	名称	主なコンテナ	インフラ	提供	備考
?	wmv3 (aka wmv9, VC-1)	.wmv	DirectShow	Microsoft 社	Microsoft ここでも先制。AVC規格策定途上なのも一緒。 H.264/AVCとは異なるが要素技術には共通点が多く、性能は悪くは無い。画質と速度のバランスを取ったコデックと独自コンテナで先行逃げ切り戦略。なお、H.264/AVCに於いても同社はパテントを保有している。
?	x264	.avi, .mp4, .mpeg, など	vfw cli ？	オープンソース	2005 中、米露２箇所のコンテストで最強のH.264/AVCと目されている。 2006年10月にvfwサポートを停止したが、これは更なる符号化効率を追求するためと推測。なお、符号化効率を追求する上で最大の障害となるパテント問題はソース配布のみと言う形で迂回。他にも工夫はあるらしいが、可能な範囲でソースからのビルドを検討して欲しい。
2005	Apple-H.264	.mp4, .mov, .m4v	QuickTime	Apple 社	Apple ここでも規格策定を待って後発。映像圧縮にかんするパテントを保有しておらず総合性能は低い。しかし前回の反省からか、速度を捨てて画質に振り切ったコデックになっている。これでハイエンドを掌握、ローエンドはiPodとiTMSでコンテンツ流通を独占するハイ・ロー挟撃。なお、国際標準規格とは言いながら、拡張子.m4v/.m4aは規格に無く、慣習的にrawvideo, rawaudioに使われて来たもの。デファクトだからかんけーねーですかそうですか。

　この他にXvid AVC、3ivx AVCなどが進行はしているようだがまだ。
　その先にDWT系のSNOWが控えてはいるが、 JPEGとJPEG2000、GIFとPNGなどの例もあり、判断が難しいところ。

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

IPDSサイクル

　※この記事は2005年10月09日に書いたものの改訂版です。

１）これを繰り返して向上を図る。「業務改善」とかのキホン。らしい。

　

２）サイクルってんだから、繰り返し～たぶん無限の～がミソ。

　

３）マテマテ。２パス目はこれで良いが、1stパスの"Plan"はどうやって立てるんだ？

　

　なんか素材が要るでしょ素材が。

情報は集めるだけじゃ意味が無い。消化しないと。; 消化というのは、優先順位をつける事。重要なものとそうでも無いもの、あと関係ないもの。; 脳内の秩序構築を怠るとすぐに「駅の名前を全部言える子供」になってしまう。まぁ、怠るんですけども。; 2パス目以降は"3. See"からのフィードバックが当然、材料になる。; 0. の部分は「情報収集」にした方が通りが良さそうだが、とりあえずIntelligence：知識とした。; モノの本では「情報分析」とかになっている。日本語には InformationとIntelligenceの違いが無いともある。

４）優先順位をつけるには、「目的」が必要だ。

　

５）目的は、可能な限りシンプルに。複数目的は御法度。でないと結果検証で混乱する。ド素人だからね。
　

　色彩劣化や他の悪影響が有るかも知れないが、そこでおたおたしない。インタレ縞を潰したければ、まずそこに目標を絞る。他の事は別に実験するべき。すっげえ時間喰う。でもそこでおたおたするともっと時間喰う。

◆◇◆

　「鉄人」とか「職人」とか呼ばれる人たちの頭のなかあるのは、こうしたデータベースなんであらふ。彼らの脳内にはこの他にもいろんなフォルダがあるに違いない。それが巷間「経験値」と呼ばれるものの正体だ。たぶん。

　知識だけじゃ足りないし、経験だけでも足りない。両方を脳内でどれだけ整頓してあるか。それが自分のエンコード能力を左右する。知識と経験が増えるにつれて分類項目は増え、必要に応じて全体が再構築され、整合性が高まり、応用範囲が広がってゆく。たぶん。

　さて、ど素人の自分が手持ちのリソース（お金と時間と能力）で、この脳内データベース構築を加速するには？書き留めればいい。外部記憶で充分。
　後でぐぐれる方が良い。どうせ頭わりーんだから。

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

動画エンコードのアプローチ

　面倒なので毎度は書いていませんが、自分はx264も MEncoderも万人向けと言うつもりはありません。JPEG2000やPNGのようにどマイナーな地位にとどまる可能性もあると思います。いずれにせよ、iTunesのCDリッピングくらいの手軽さがなければひとさまにお奨めできるものではないです。エンコードそのものが実時間の1/3を切るまでは、マニアの遊びでしょう。

◆◇◆

1. はじめに
2. 妥協の前には理想が要ること
3. 必要のないものに深入りしないこと
4. 検証のない経験は非効率なこと
5. おわりに

1. はじめに

　動画エンコードにおいて、画質、速度、ファイルサイズは相互に矛盾する要求です。
　画質「だけ」を追求するなら無限のファイルサイズが必要です。あまり大きくては圧縮の旨味が薄れます。
　MPEG-1/2/4はどれも、ある程度の画質を諦めてずっと小さなファイルサイズを実現するものです。劣化は必ずあります。
　画質劣化を食い止めるにはある程度複雑な処理が必要です。これは時間がかかります。
　最終的にどれを重視するかは人それぞれなので正解はありません。が。
　
　このエントリでは、何を重視するにせよ最初に必要となるのは「いかに高いレベルで妥協するか」という精神だ。と言い切ってみます。
　その上で、自分が心がけている基本的な事柄を書いてみます。かなり抽象的なものになると思いますが、よろしければお付合い下さい。

『国産ロケットはなぜ墜ちるのか』151p
　理工系とひとくくりにされがちだが、理と工の差は、通常想像されるよりもはるかに大きい。理学は自然を理解する事を目的とする学問で、その基本には「妥協なき真理の追究」という態度がある。それに対して工学は、理解した自然の力を応用する学問であり、基本にあるのは「いかに高いレベルで妥協するか」という精神だ。

　要するにこの本が面白かったんでなんか書いてみようと^^;。

2. 妥協の前には理想が要ること

　「妥協」の前には「理想」が必要です。理想の無い妥協は迷走ですから。

画　質：素材と同じ。
速　度：一瞬。
サイズ：限りなく小さく。

　100=100点だと思ってください。

　現実にはこれは有り得ません。しかし、要素分解がミソです。多くても大変なのでとりあえずここでは三つで。この青い三角ができるだけ大きくなるようにあれこれ工夫して「望み得る最善」に近づいていくわけです。
　大雑把でも理想がないと、自分の妥協が適切なものかどうかがわかりません。そもそも何を・どの程度差し出せば何を得られるのかが、いくらやっても見えてきません。漫然とエンコを繰り返してもストレスが溜まるばかりです。雑で充分です。まず理想。
　後は手数を重ねれば重ねる程、問題点が整理され、その姿がより明確になっていきます。決してそこに手が届く事はありません。が、習得効率は上がります。
　余談ですが「理想を要素分解して考える」ことは、様々なケースで使えると思います。QuickTimeかlinuxインフラか、3ivxか Apple-H.264か、ffmpegか MEncoderか、などなどなど。一番重要なエンコツールは、たぶん自分自身です。
　繰り返しますが、たかが動画エンコにわざわざこんな面倒を考えるのは万人向けではありません。あくまでそれ自体を楽しめる人向けの遊びだと思います。

3. 必要のないものに深入りしないこと

　ここから先はMPEG-2 PSのアナログTVキャプチャをMEncoderのx264で、2passを使って、rawvideo.264に吐き出す前提で書いて行きます。

　最初に書いたように、画質・速度・サイズは相互に矛盾する要求です。それでなくても動画エンコは面倒の連続です。
　なにか最初に「固定条件」を作ってしまうと、多少は他の要素の見通しが良くなります。ではもっとも固定しやすい条件は何か？
　画質や速度はやってみなければわからない部分が大きいですし、速度はCPUに、画質は様々な要素に左右されます。またこれらは目標を決めたところで確実に守れるものでもありません。最も固定しやすい（そして誰が見ても比べやすい）条件はファイルサイズでしょう。これは解像度とビットレートで決まります。

3.1. まずは解像度。手許では横幅640で固定しています。

解像度	横幅	高さ	画素数
4:3	640	480	約30万画素
16:9 （ビスタ）	640	352	約22万画素
シネスコ	640	272	約17万画素

　2006秋現在、世間的には720x480や704x480の人が多いようです。
　もともと720x480は普通の4:3や映画の16:9のどっちにも使えると言う事で決まった中間解像度なので、正直に720x480で表示すると人間がデブになったりノッポになったりします。もちろん通常は再生時にソフト/ハードが4:3なり16:9 なりに拡大・縮小してくれるので問題はありません。が、
　手許で縮小している理由は以下：

再生時に使う拡大・縮小アルゴリズムは当然リアルタイムでなければなりません。ですから性能もそれなりです。どのみち視聴時には720x480のサイズでは無い。と割り切って、MEncoderでもう少し優れた拡大・縮小アルゴリズムを使っています。
720x480と640x480では5万画素ほど違います。そのぶん速度も、圧縮効率も向上します。
TVキャプチャで入りがちな黒帯をなるたけcropしたいという理由もあります。そのぶん速度も、圧縮効率も向上します。

　なお、16:9以下では高さの数値が正確な比率になっていませんが、これは縦横とも16の倍数でなければならないというMPEG-1/2/4の基本原則に従っています。
　720x480や704x480でエンコして、拡大・縮小は再生時に行うと言う事は、映像データをできるだけ弄らない、という事です。できるだけ弄らないという事は、素材に対する忠実度が高い～画質が良い～事に繋がります。未来のプレイヤ（ハード・ソフト）に期待している、とも言えます。

3.2 次に、ビットレート。手許では一律に1024kbpsで揃えています。

bitrate	1024kbps

　1024kbpsのx264映像と128kbpsのaac音声を.mp4に突っ込んだ場合、30分番組が概ね250MB、 CMカットして24分なら200MBになります。
　これは出来上がりサイズのキリの良さで選んでいます。
　他に、Doom9 の投票でこのくらいのビットレートがもっとも多い事。北米ではいまだに映画の1CD化が主流なのかなんなのかは解りませんが、これはx264は1000kbpsあたりのビットレートで最も多くテストされており、従ってその付近で最も安定した性能を発揮するようチューニングされている筈だと考えています。特に、オプションからは弄れない部分が、です。
　また、最新のHDレコーダでは4MbpsのMPEG-2でもまぁまぁ見れる画質と言いますから、これよりはうんと縮めたいところでもあります。

3.3 最後に、2パスしか使わない理由
　これは、特定のビットレート制限の範囲で「望み得る最善の画質」を要求するなら最低でも2パスが必要だからです。

　この解像度とビットレートが万人向けかどうかは良く解りません。もともと画質を基準に決めたわけでは無い事に注意して下さい。単に見通しをよくする為です。
　特定の解像度とビットレートの範囲でビットを有効に使う＝1bitあたりの画質を追求するアプローチについてはMEncoderドキュメントの『DVD映像を高画質なMPEG-4 ("DivX")にする方法』を参考にしています。

4. 検証のない経験は非効率なこと

　理想の構成要素のうち、面倒なものや自分に必要のない部分を固定すると、それ以外の部分、～例えばx264のオプション～、に集中する事ができます。

　2005年10月から2006年10月現在まで、手許では地アナ録画のMPEG-2全てを2パス, 1024kbps、横幅640でx264+ aac.mp4にエンコードしています。
　その条件下での画質は概ね以下の通りです。

種類	Avg QP(p)	主観画質（通常視聴）
アニメ	4:3 （640x480）は18～23程度 16:9（640x352）は14～18程度	良好良好
実　写	落語：ノイズが酷くなければ20～23。ノイズが酷い場合は28程度。サッカー：ノイズが少なくても28付近。	不満・着物や顔のディテイル充分
映　画	内容やノイズにより様々。最悪で28程度。	素材により様々

　Avg QP(p)と言うのはPフレームに適用された量子化値です。低いほど画質が良いので「画質劣化度」くらいに思っても良いと思います。
　ビットレート制限がある場合は、MEncoderがひとこまひとこま「画質劣化度」を調節して指定サイズに収めてくれるわけです。
　ffmpegXの作者さんはAvg QP(p)=20以下を無駄に高画質としていますが、実写素材ではビットレートを上げるなどしてもう少し低めのQPを狙っても良いかもしれません。

　なお、手許ではエンコード設定と数値的な結果をテキストに書き出すシェルスクリプトを作り、毎回それを読んでいます。表計算に要点を書くのは結構サボりますが、記憶・経験・主観的な印象だけだとどうしてもあやふやになるので、できるだけ数値的な結果を読む。違和感のある数字が出たら、なぜこの番組はこうなるのか考える、、、これで意外な事に気が付くこともあります。
　ソースコードは読めませんし、理屈を読んでもろくに理解できないので、少しでも効率よく経験値を稼ごうと思って始めた筈だったんですが、もはや番組よりログ見るほうが楽しみなカラダに、、、。

5. おわりに

　しつこいですが、動画エンコなんてものは所詮、マニアの遊びです。

　ほんの少し、自分の服を自分で作るのに近いんじゃないかと言う気もします。そんで気が付いたらミシンの分解組立てにハマってやんの。うお、今度の新型はボタン付けができるぞスゲェ！みたいな。地アナのインタレ縞が見えるとか地デジのブロックノイズが見えるとか。あんま意味ないです。所詮、マニアの遊びです。

　ここに書いたのはホンの一例で、実際には全くもって自由です。それぞれの「望み得る最善」を探してみて下さい。
　遊びはマジにやらなきゃ面白くないです。

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

LINK：esperance

・ http://www3.atwiki.jp/esperance/
x264+aac.mp4エンコーダ。Win/Mac/Linux対応。

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

LINK：D-Vision3公式

・ http://www.objectifmac.com/
ObjectifMac。D-Vision3など

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

LINK：ffmpegX - 公式

・ http://www.ffmpegx.com/
DVD, SVCD, VCD, CVD, VOB, DivX, XviD, H.264, PSP, iPod, MP4, MOV, FLV encoder for Mac OSX

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

LINK：raw2qt264

・ http://www8.atwiki.jp/quicktimeprogramer/
raw movieをQuickTimeのH.264 codecを使って圧縮するMac用プログラム。
ffmpegをフロントエンドに使ったコマンドラインで、パス数指定できる。

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

LINK：VLC media player - 公式サイト

・ http://www.videolan.org/vlc/
Mac/linux/Winで動く動画再生ソフト。必携。

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

LINK：Audacity:

・ Audacity
・ Audacity wiki
フリーのサウンドエディタ・レコーディングソフトウェア。

妖精現実：Audacity 1.2.5 (stable) と 1.3.2 (beta)(2006年10月30日)
Audacity は（クラスプラットフォームにありがちだが）開発の進行が早くなく、インターフェイスもいまいちだし（メニューは多言語だが、新しい方の版は日本語がないようだ）、機能も高価なペイウェアに比べると限られている。よって、高機能のペイウェアを既に持っている人には必要ないだろう。
しかし、オーディオエディタを何も持ってない方にとっては優れ物と思う。サンプル単位やミリ秒単位でオーディオファイルを編集する機能はしばしば必要になる。Wikipedia でも、音声メディアの作成には Audacity を推奨しているし、妖精現実の字幕タイミング入門でも Sub Station Alpha を使う準備段階として Audacity を使っている（古い記事のため現状と合っていないが）。

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

LINK：参考（win）：LostTechnology

・ http://www.losttechnology.jp/
Winでの動画作成全般。

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

LINK：参考（win）：超初心者はひっそりとここ見てから質問しる！

・ http://page.freett.com/dtvshitsumon/
2ch映像制作板のデノイズフィルタ。

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

LINK：参考：スクリーンサイズの種類とアスペクト比（縦横比）

・ http://members5.tsukaeru.net/rionawide/p11.html

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

LINK：参考：easy dv:インターレース

・ http://www7.ocn.ne.jp/~yoshi000/sono9.html
インターレースの基礎知識

[ 2006/11/05 00:00 ] 動画　動画全般 | 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)

LINK：Linux用アニメ自動録画システム、 foltia

tracはあるわSVNはあるわインスコマニュアルはあるわでそらもースンゴイ事になっている。
linuxの方は是非お試し頂きたい。

ドライバが無いんでMacでは動かないのだとか。ま、それはともかく。
公開おめでとうございます。

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

Avidemux2.3

【知った場所】Doom9.org
【入　手　先】Avidemux

　Linuxの MPEGStreamclipのようなもの。GUIで動画編集、各種エンコード、各種コンテナ書き出し、音声変換同時。
　Mac OSXではX11（システムディスクに入ってる）がインストールしてあれば動く。とりあえずゴテゴテとオプションを付けてx264+mp2.mp4を作って見たところ、VLC/MPLayer(cli)ともクラッシュした。

　と、いう段階で書くのもアレだが。
　x264 のコマンドはほぼ網羅している。主要なところではdirect_pred（--direct）にautoが無いくらいだろうか。デフォルト設定はギンギンのHigh Profile。書き出し形式にmp4もあり、インタレ解除やデノイズ、色調整なども効果を確認しながらできるようで、プリセットとして保存できる。フィルタの数はMEncoderほど多くは無いが、MEncoderだって全部が全部有用なわけでなし。主要なものは移植されている。独自フィルタの中にはPAL専用ながらフィールドシフトインタレ解除もある。

　なによりGUI。
　

　Enlightenment 入れてるからちょっとアレだけどこれでもTiger。通常のx11との違いはウィンドウ枠だけのハズだ。

Doom9： 12/7のNews
Avidemux 2.3 - 代替コンテナ等が扱えるVirtualdub。MOV, MP4コンテナ内のDVコンテントをサポート。概ね最新版のx264をを内蔵しており、いくつかのバグが修正された。

以下太字オレ

Avidemuxのサイト：2006-12-02: 2.3 Final
2.3 Finalを公開しました。

修正済みバグリスト：
Fixed make install for po directory
Fixed Ffv1rec
Fix for multiple gthread_init call (aakef)
Better audio dithering (Mihail+Josh Green)
Support for DV in .mov/.mp4
Resample crash fix when upsampling (a nasty one).
PCM in .mov/.mp4 sample size fix
Fix for MP4/MOV files containing .url field
Added smartcopy from cli or from javascript
x264のmp4出力でBフレームの参照化を使うとバグがあったのを修正。
For non Linux users:
preview2/MacOsX の新しいスナップショットが出来た。Preview 2cだ。Kuisathaveratの修正によりより多くのMacOsX versionで動くようになった。ありがとうKuisathaverat！

For win32 users：
アップデートすべきなのはzipファイルだけだ。最初に2.3.0 zip fileをインストールして次にその中身をx264_update fileで上書きして欲しい。

svn版 x264にアップデートしても大丈夫。avidemuxのx264はコンパチだ。しかしwin32 versionではgtkに基づく制限があるから注意して欲しい。非ascii characterのdirectory/filenameを使うと問題が有る。

version2.3はまだ続く。2.4でも同じコアを使っているので、そこからのバグフィクスを使えるからだ。

2.4 は2.3と同じだが、ユーザーインタフェイスが３種類ある。GTK, 無し（x11不要のcliモード）、そしてQT4だ。cli版は既に使う事が出来る（＊useable、有用だ。かも＊）。GTKは2.3と変わらない。しかしQT4版は、まぁ、初期段階だ。
（＊以下不詳＊）I hope jakub will stand the way QT does layout compared to GTK, which is not brilliant at the moment (and yes, designer is less efficient than glade).

おそらくはこれが今年最後のバージョンになるだろう。

　コマンドラインでも使える筈なので、プリプロセスをこいつに任せてmkfifoでx264cliに繋ぐ、とかできっかもしんねぇ。去年もそんな事言ってたような気がするけども。

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

縦横（アスペクト）比

映画界の呼称
DARとPARとSAR
一般的な SAR:
なぜx264にDARが無いのか。
AVIとQuickTimeとMPEG規格

映画界の呼称

スクリーン・サイズの種類と縦横比（アスペクト比）：りおなのVIVA!WIDESCREENより作成。

名称	縦x横	備考
スタンダード	1×1.37	35mm写真フィルムとほぼ同じ。TVもこれに倣った。
不詳	1×1.2	ほぼ正方形。トーキーの音声をフィルム上に収録するため、ちょっと映像を削った。不評で消えた。
ヨーロッパ・ビスタ	1×1.66	フランス映画に多い。
アメリカン・ビスタ	1×1.85	シネマスコープを除くほとんどのアメリカ映画。日本、イギリス、イタリア映画にも多い。
マスキングビスタ	1×1.66～1×1.85	35mm（スタンダード・サイズ）フィルムでの撮影または上映時に上下にマスクをかける。純正のビスタビジョンと区別するため“ビスタサイズ”と言う。 1960年代のフィルムの品質向上で実用化。 1980年代のビデオ普及により、撮影はスタンダード、上映はマスキングビスタが主流となる。
シネマスコープ	1×2.35	基準は1×2.35だが、通常は 1×2以上のアスペクト比を「スコープ・サイズ」と呼ぶ。撮影は専用のアナモルフィック・レンズか、スーパー 35方式（マスキングビスタ的なもの）を使う。

　4: 3なら1.33だし、16:9は1.78だ。勘定が合わない。「なんですかこれわ？」という数字だらけ。恐るべし映画百年の歴史。
　これら多彩な縦横比をどうやってデジタルの世界に持って来るか。

　DVD（と言うかMPEG-2のMain Profile @ Main Level）の720x480はアスペクト比1.5。表の中のどれにも合わない。
　なぜこれを採用したかは知らないが、720x480の画素数は僅か34万5,600画素。恐らくは、規格制定当時、ご家庭で買える範囲のお値段で再生機を作るには35万画素を30fpsで動かす程度が限界と予想された、という事だろう。画素数とfpsがCPUパワーとバッファメモリ搭載量に直結するからだ（MPEG規格は半導体の価格動向予測も考慮して決める）。
　だから、まず画素数とfps。次に、どのアスペクト比の映画でも、720x480を有効に使いきる、仕組み。
　例えばデータ上の解像度（サンプル数）は720x480 で固定しておいて、表示上のアスペクトは別に指定してやる。など。これならどのアスペクト比の映画でも、720x480を無駄なく使いきれる。画質最優先ならどのアスペクトに対しても個別に最適な縦横のピクセル数を決めるべきだが、家庭用DVDプレイヤでそこまでカヴァーするのは無謀だったという事だろう。

DAR とPARとSAR

名称	種別	対応規格	根拠
DAR Display Aspect Ratio ディスプレイ・アスペクト・レシオ	画面表示のアスペクト比。	MPEG-1/2/4	MEncoder 　- mpegoptsのvaspect=<1 \| 4/3 \| 16/9 \| 221/100> 　-xvidencopts のaspect=<x/y \| f (float value)>
PAR Pixel Aspect Ratio ピクセル・アスペクト・レシオ	ピクセルのアスペクト比。	MPEG-4 ASP?	MEncoder 　-xvidencoptsのpar=<mode> 　DAR = PAR * (width/height)。
SAR Sample Aspect Ratio サンプル・アスペクト・レシオ	ピクセルのアスペクト比。	MPEG-4 AVC	x264cli 　Input/Output:の --sar ※ 規格上はVideo Usability Info (Annex E):だが、ここではcore:54 svn-611M --longhelpに従った。 MEncoder -x264encoptsには見当たらない。

　アスペクト比はスクリーン（画面全体）で指定するものと、ピクセル単位で指定するものの２種類がある。PARとSARは、規格上の呼び方が違うだけで同じものだろう。手許では実際に-xvidencoptsのpar=<mode>を使った事は無いが、modeには ntsc169 や pal43 などのプリセットを入れる。ここに ext と入れると、par_width=<1-255> や par_height=<1-255> で独自の縦横比を指定する事ができるようだ。恐らくは、これがSAR。

一般的な SAR:

x264cli のSARは「8:9」のような書式で指定するようだ。-xvidencoptsの書式で書くと、par_width:par_height に相当するだろう。
DAR= (par_width / par_height) * (width/height)

Encoding H.264 using the x264 Command Line Interface（Zero 1氏）の一般的な SAR表から作成。

素材解像度	DAR		SAR（PAR_W : PAR_H）
素材解像度	一般名（縦横比など）	少数表記（高さを1とした時の横幅）	PAR_W	PAR_H
720x480 (NTSC)	4:3	1.33	8	9
	16:9	1.77(*1)	32	27
	アメリカン・ビスタ(*2)	1.85	100	81
	シネスコ	2.35	69	44
704x480 (NTSC Crop)	4:3	1.33	10	11
	16:9	1.77(*1)	40	33
	アメリカン・ビスタ(*2)	1.85	125	99
	シネスコ	2.35	85	53
720x576 (PAL)	4:3	1.33	16	15
	16:9	1.77(*1)	64	45
	アメリカン・ビスタ(*2)	1.85	40	27
	シネスコ	2.35	32	17
704x576 (PAL Crop)	4:3	1.33	12	11
	16:9	1.77(*1)	16	11
	アメリカン・ビスタ(*2)	1.85	50	33
	シネスコ	2.35	102	53

*１） (PAR_W/PAR_H)*(width/height)で計算すると16:9は1.78になる。
*２）大半とは言いませんが、多くのワイドスクリーンDVDは、厳密には16：9ではなく、1.85:1 か 2.35:1 (シネスコープ)。これは、映像の中にクロップすべき黒帯が含まれていると言う事になります。MEncoder Documents/DVD映像を高画質なMPEG-4 ("DivX")にする方法より。従って16:9とは各種ビスタやシネスコを包含する汎用比と思われる。

　なお、『改訂版 H.264/AVC 教科書』を見ると、VUI（ビデオ表示パラメータ、309ページ）の項に、aspect_ratio_idc、sar_width、sar_height、というものがあった。aspect_ratio_idcはプリセット。0は定義無し、1は1:1、2は12:11、、、という具合。13まである。14～254 はreserved（将来の拡張用）。ここが255だったら、
sar_width、sar_heightの値からSARを計算する。とある。
　上の表の「一般的なSAR」は16通りある事から、x264cliの--sarオプションは、sar_width、 sar_heightを入力するものと思われる。

なぜx264にDARが無いのか。

DARがありゃ便利なのにと思うのだが、どうもH.264/AVC規格にも無いらしい。例えば、H.264/AVC規格概要：レベルにある以下の記述。

規格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt （maximum frame size * 8）以下でなければならない事を除けば規格には無い。

　もしもAVCのレベルにフレームの縦横は720x480といった規定が無く、制限は1フレームあたりのピクセル数だけで、かつ、ピクセルに縦横比情報を持たせる事ができるのなら、ヨーロッパ・ビスタだろうがアメリカン・ビスタだろうがマスキングビスタだろうがシネスコだろうがそれ以外の変形素材だろうが、オリジナルのフィルムから起こす場合に限っては、もうちょっとだけ、素材に忠実な解像度で作る事ができそうだ。それなら、MPEG-4 ASPの"PAR"の名称を変える必要性が納得できる。
　あと、4kシネマ（4,096×2,160ドット）とか2kシネマ（2,048×1,080ドット）とかも睨んでるのかもしれないなと思った。

AVIと QuickTimeとMPEG規格

MEncoderはAVIヘッダにアスペクトを書き込む事ができる。しかしそれをちゃんと解釈できるのはMPlayerくらいらしい。オプションにある通り、rawvideo.xvidにDARやPARを埋め込む事もできる。しかしこれも、AVIコンテナではちゃんと解釈できるのはMPlayerくらいらしい。DARやPARは.MP4コンテナが安全だろう。

　一方、QuickTimeはコンテナにはアスペクトヘッダを埋め込め、正しい解釈もできる筈だが、インフラ全般に渡って映像データと付加情報は分離すべし、という一貫した思想がある（オブジェクト指向）。これはかなり徹底したもので「アスペクト情報を持った映像ストリーム」に対応困難らしい。結果的に.MP4であっても、SAR指定の入ったH.264サポートをQuickTimeコンポーネントとして実装するのは難しいようだ（考察：SARとQT（My cometG3））。
　Appleが国際標準規格の推進をアピールするのは自由だが、Apple - h.264 だけが H.264/AVCであるかのような印象操作は不愉快だ。

　MPEG （Motion Pictures Expert Group）規格はその名の通り、動画に関する規格だ。.MP4はAppleの.movベース（Appleが唯一MPEGに提供しているパテント）とはいえ、発想は異なる。上位団体はISO（International Organization for Standardization、国際標準化機構）と仰々しいがなんのことは無い。JISだJIS。「2Bの鉛筆」とか「単３の乾電池」とか「M３のボルト」などと本質的な違いは無い。ISO-MPEGの仕事は「産業界における汎用的な実用性を持った規格を定める事」だ。ひらたく言えば妥協がお仕事。できるだけ高いレベルで。

　手許ではSARを使わずにスケーリングしてしまうが、過去に720x480のMPEG-2PS（TVキャプチャ）の黒帯を、16:9にするべくcropして、スケーリングを間違えて640x480でエンコードした事がある（ソルティレイ#01 オーロラの降る街）。

-vf pullup,softskip,crop=702:352:8:64,scale=640:480,hqdn3d=2:1:4,pp=l5,harddup

記録が残っていないがSARもPARも滅茶苦茶なハズだ。


QT Player + avcdecoder 0.5.1	VLC 0.8.6	MPlayer OSX 1.0 pre 8

　これを正しいアスペクトで表示できる方が狂っているのだが、なぜかこうなった。
　QT Playerは素直に640x480。VLCとMPlayer OSX 1.0は、縦480を軸に、横幅を852に拡大している。当時（2005/10月）はMain profileで作っていたので、素のQT7（Apple-H.264）でもこうだった。偶然に正しいSARにでもなったのだろうか。

　ところでこのファイルは「こんなこともあろうかと」取って置いたというわけでは無く、何気なくme=ext、me_range=64を試して122時間 34分49秒かかった後に、やり直す気力が残ってなかっただけです^^;。

余談：
　なにげなくISOのスペルを辞書でひいたらこういうものがあった。

ISO standard cup of tea : ISOで決められた「標準紅茶」。
ISO 0（砂糖を入れないミルク紅茶）。
ISO 2（砂糖を2スプーン入れたミルク紅茶）。

冗談かと思ったら、本物でした。ISOで規格書も売っている。紅茶好きの間では有名な話らしく「ISO 3103:1980」で検索するとちょっと大変な事になっている。イギリス人め！安倍政権はISO国際標準すし規格の策定に全力を注ぐべきだ。

[ 2006/12/20 01:00 ] 動画　動画全般 | TB(0) | CM(0)

LINK: Lair Of The Multimedia Guru

Lair Of The Multimedia Guru
知った場所：MEncoder Documents / How to deal with telecine and interlacing within NTSC DVDs

　タイトルは、マルチメディア導師の隠家？どうもここがMichael's Niedermayerさんのブログであるらしい。ffmpeg、MPlayer、なかんずくSNOWのキーマン。てゆうかlibavcodecのキーマン。プログラミングのできない自分には何が書いてあるやらまるで理解出来ない。

　歯が立ちそうなのはこの記事くらい、、、と思ったけどやっぱ歯が立ちませんでした。

2006/06/09

Deinterlacing filters

　ここでは様々なインターレース解除フィルタの比較をしてみます。インターレースド素材は有名な foreman video（*1）からmplayerの phase=t および tinterlace=1 フィルタを使って作成しました。
　実験結果の映像はすべてmplayer -vo pnm と ppmtojpg --optimize --quality 90 で出力したものです。-vo jpegを使わなかったのはコンパイルしてなかったから。あと、-vo jpegは RGB 入力しか受け付けないから。ここではとくに使うメリットが無いです。
　インターレース解除フィルタの多くは2フィールド毎に合成して1フレームを出力するだけです。実際、常に偶数フィールドを選ぶものもあれば、常に奇数フィールドを選ぶものもあり、さらに奇数偶数の区別なく、常に1stフィールドを選ぶものありといった具合です。おかげで、この比較テストは期待したほど面白くはありませんでした。この問題から、フィルタの中には垂直反転した映像を流し込んでやる必要があるものがありました (pp=ci and kerndeint IIRC) 。さらにtomsmocompは -vf phase=b を使わなければ正確なフィールドに基づくフレームを出力できませんでした。そしてもちろん、top / bottom field first flag の指定ができるフィルタは正しく設定してあります。

＊以後、図は原文を参照。ここではmplayerのyadif、mcdeintに限る。

mplayer -vf yadif=1:1

1フィールドを1フレームで出力：ボトムフィールド1st
唇の端に僅かなジャギ。また左上、ジーメンスの文字がボロボロ。

mplayer -vf yadif=3:1

1フィールドを1フレームで出力・但し空間軸インターレースチェック抜き：ボトムフィールド1st
左上、ジーメンスの文字はキレイだが、指先がジャギジャギ。

mplayer -vf yadif=1:1,mcdeint=2:1:10

低速, 反復動き予測：おそらくボトムフィールド1st：qp
mcdeintのフィールドオーダーは、manには0か1とあるのみでどっちがどっちか書いてない。また自動検出も無い。
唇の端のジャギ緩和。また左上、ジーメンスの文字がやや復元。

mplayer -vf yadif=3:1,mcdeint=2:1:10

最もオリジナルに近いが、ジーメンスの文字がyadif=3:1 より劣化。

＊手許常用はyadif=0。Output 1 frame for each frame、フィールドオーダーはオート。特に落語で唇やまぶたのジャギが地味に目立つ。ズームも地味にジャギる。TV放送のフィールドオーダーはランダムに切り替わるようだから、手許ではこのコマンドそのままとは行かないが、yadif単体よりyadif,mcdeintのコンボの方が優秀なのか。

Comments

名前	コメント試訳	メモ
1.RC 06/06/11@ 9:21	静止画での比較は適切ではない。デインターレーサは動かしてみて動き回るエッジのジャギを見なければ正しい評価はできない。
2. mean 06/06/18@ 18:27	mcdeint に関しては、avcodec_close/free missing in the uninit part（＊不詳＊）があるかも知れない。
3.Michael 06/06/19@ 10:17	それはもう無い、たった今avcodec_close()を追加した
4. Sigdrak 06/06/19@ 17:01	Interesting results for yadif. What litterature have you checked on edge-directed interpolation that led you to this? Speaking of the implementation, I notice that there are such statements as: 1) if((y ^ parity) & 1) 2) uint8_t prev2= (tff ^ parity) ? prev : cur ; 3) uint8_t next2= (tff ^ parity) ? cur : next; inside of the loops. While I believe that nowadays CPU’s branch prediction will optimize it, couldn't it be made “cleaner”? (”patch welcome” is the reply I expect from you)	エッジを重点的に補間する手法？
5.Sigdrak 06/06/19@ 17:03	最適化の問題は気にしないで。既にテストしたでしょうから。恐らく register pressure （＊不詳＊）のほうが重要です。
6. Michael 06/06/19@ 23:55	edge-directed interpolation related litrature（＊重点的エッジ補間に関する文献？＊）は1年ほど何も読んでいない。随分前に少し読んだ。正確には覚えていないし、現在のyadif がやっている事がとの類似がどの程度かも知らない。しかし、一般的な補間ではないデインターレーシングに関する文献は、オンラインでフリーのものは１、２個しかないので（この事は確信してる）。いつもは他の文献を読んでいない。もしかしたらciteseerがなにか見つけているかもしれない、、、。 tomsmocomp もなにかのdirectional interpolation code を使っているようだ。知ったのはyadifを書いた後だったが、、、。そして、時間軸と空間軸のpredictors（＊予測子？＊）を混ぜるのは完全に自分のアイデアだ。最適化については、yadif と mcdeint はまだまだなのでパッチ歓迎。例えば、mmxでかなりの向上がある事は確実だ。 filter() も inline functionに変更できる（＊以下不詳＊）。 about optimizations, yadif and mcdeint are not really optimized and patches are always welcome, for example iam sure they could benefit alot from mmx filter() could also be changed to a inline function and called with “constant” tff and parity so that the compiler can optimize the related checks away while the source code would stay clean …	＊TomsMoComp：動き補償デインターレーサ。transcode、 AviSynthで使える。
7. compn 06/06/20@ 4:36	mplayer -vf lavcdeint が無いのはどうして？比較する価値が無い？dscaler deinterlace filterの事は知ってる？ http://dscaler.org/ あなたが libavfilter か libavmunge (as LAVF is taken by libavformat)を作るのはいつ？そして全プロジェクト(vlc, xine, mplayer, transcode, etc)のフィルタを統合してしまえば、みんな車輪の再発明を止めて、もっとスゴいフィルタに集中できるのに！	それが成立すればMac OSXはCore Video/QuickTimeに競合する「もうひとつの動画インフラ」を持つ事になる。プロダクションレベルならPhotoshopが必須だが、カジュアルユースならGimpで間に合う。
8. Michael 06/06/20@ 9:08	-vf lavcdeint は -vf pp=fd と同じだ。 dscaler については、linuxで簡単に使う手はあるだろうか？（qemuとかそういうのじゃなくて）。もし無いなら関心が無い。あればテストする、、、今のところ、libavfilterに取りかかるには私は怠惰すぎる/やる気がおきない。パッチは歓迎 :)。しかしながら、（＊以下不詳＊） its highly nontrivial if you want to allow all the speed related tricks like direct rendering and slices together with arbitrary filter graphs, and no 1 in = 1 out design.	不詳部分：例えばダイレクトレンダリングや自由なフィルタグラフのスライス、そして"非 1 in = 1 out デザイン"などの速度向上手法は非常に重要だ。 // 非VfW モデルはLinuxにも存在しない？
9. compn 06/06/20@ 14:22	dscalerはwindows only だと思う。でも誇大宣伝（＊過大評価？＊）が多いよ。
10. MuldeR 06/06/21@ 13:08	だれかmcdeintのしくみを説明してくれないか？自分の理解では、mcdeintより先にyadif=3を通さなきゃいけない。でもyadif=3の段階でフレームレート２倍のインタレ解除済みになる。であれば、その後でmcdeintを使う理由は何？既にインタレ解除済みの映像に対して mcdeintは何をするの？この時点でどんな向上があるの？どんな事でもいいです。教えて下さい。 mcdeintの情報はレアなので、、、
11. Michael 06/06/21@ 19:16	mcdeint は “missing” line を埋める為に動き予測と動き補償をやる。うまく動き予測をするには、元になる映像が要る。単純に奇数/偶数ラインを使う手も試したがうまくいかなかった。単純にフレームレートを倍増させるデインターレーサですら、mcdeintの後では向上が見られた。 mcdeint はオーバーラップド・ブロック・ベース（＊マクロブロック分割の際に、端っこをオーバーラップする。ブロックノイズ根絶手法＊）の動き予測と動き補償を使う。このコードはsnow codec（＊離散ウェーブレット変換、DWTを使う次世代コデック、H.264/AVCより重い＊）から持って来た。だから、snowに進展があれば自動的にmcdeintも進化する。 mcdeint=0 ：オーバーラップド・ブロック予測/補償を使わない。16×16 blockの 1/4 精度。 mcdeint= 1：8×8 blockサポートを追加、予測ゾーンサーチのダイヤモンド・サイズを拡大。 mcdeint=2 ：反復的オーバーラップド・ブロック・ベースの動き予測と動き補償 mcdeint=3 ：複数参照（＊multiple reference frames＊）を追加	笑った。x264より遅いわけだ。
12. MuldeR 06/06/21@ 20:18	お返事ありがとう！ mcdeintが“missing”ラインを埋めるというのは解った。でもyadif=3 の時点で既にmissingラインの無いフルフレームになる。mcdeintはどこを埋めるの？それとも奇数/偶数ラインを上書きする？それから、yadif=3,mcdeintはフレーム枚数を倍にする。だから（＊コマンドオプションの＊）フレームレートを手で修正しなきゃいけなくて、で、最終的にできあがりは２倍のfpsになる。mcdeintを使ってもTomsMoCompみたいにオリジナルのfpsを維持出来ないのかな？なにかオプションが要るのだろうか。 yadif=3,mcdeint,framestep=2.は、MEncoderでウマく動くみたいだ。でもCPUパワーがスゴく無駄になると思う（mcdeintが計算したフレームの半数をskipするから）。しかしながら、結果は面白い！唯一の問題はMPlayer では全く動作しないことだ。framestep=2があると映像がいったりきたりジャンプする（＊前後関係が変わる？＊）。
13. Michael 06/06/21@ 21:55	はい。上書きします。 mcdeintは前のデインターレースドフレーム（達）を動き予測/補償の参照フレームに使う。だからその計算をスキップはできない。そうしないと前のデインターレースドフレームが存在できないから。 mplayer -vf yadif,…,framestep=2 は動くようになった。
14.MuldeR 06/06/21@ 23:23	了解ちょうど長いエンコードが終わった。 mencoder -vf yadif=3,mcdeint=1,framestep=2 良い結果だ。僕のマシンでは凄く遅いが、、、動くようになった。とは最近直したと言う事？
15.MuldeR 06/06/25@ 16:52	最新のMPlayer build (2006-06-25)を試したら直ってなかった :-(
16. Michael 06/06/25@ 20:27	mplayer-svn r18781を。それが上のコメント時点での最新版
17.MuldeR 06/06/25@ 22:36	僕が使ったビルドはr18812だ。r18781で直ったのならそのままの筈だが、残念ながら直っていない、、、
18. Rich 06/08/02@ 8:00	MuldeR、インターレースド素材のオリジナル・フレームレートは倍の数だ。50とか60とか60000/1001とか。単に各フレームのライン数が半分なだけだ。フィールドをペアにして、一つのピクチャ上に交互配置してフレームレートを半減させるのは、それがコンピュータに保存されたときのやりかたで、オリジナルビデオの性質というものを考えると語弊がある。
19.JR 06/09/05 @ 12:26	yadif と mcdeint のコンボはmencoderで逆テレシネと同時にフィルタチェインに書いても使えるものだろうか（例えばNTSCからfilmへ[23.976 fps]）。 -vf yadif=3:1,mcdeint=2:1:10,framestep=2,filmdint=dint_thres=256,… -fps 30000/1001 -ofps 24000/1001 を試したが、結果は常に動きの早いシーンでのフレーム複製だった（dint_thres=256の効果でfilmdintはインタレ解除をしない。逆テレシネだけだ）。そして、私はこうした素材のどの- fpsを指定すれば良いのかまったく手がかりを持っていない。pullup, divtcなどの他の逆テレシネはまだ試していない。しかし結果が変わるかどうかあまり自信が無い、、、たすけて。
20. Justin 06/12/14@ 15:45	私は yadif=3:1,mcdeint=2:1:10,framestep=2 を試したが、ぴょこぴょことした不審な動きが出る（時折フレームの順番がおかしい）。使っているのはmencoder rc1だ。 -vf pullup,softskip,pp=lb も試したがこれは10～15倍も早いだけでなく、自分の見るところyadif,mcdeintの奇妙なダンスより良い（でもyadif,mcdent, framestepの苛つく動きを止める方法が見つかればまだ試すけど）。誰かmencoderのTomsMoComp相当のフィルタを知りませんか？たすけて。
21. Michael 06/12/14@ 17:39	もしもpullupなどの逆テレシネで “interlacing”アーティファクトが除去できたのなら、そのビデオはインターレースドではなくテレシネされたものだ。だからデインターレースの使用は可能でも、賢明でもない。もし -vf yadif=3:1 がうまくインターレースド・ビデオでうまくいかなければ -vf yadif=3:0 または -vf yadif=3を試して。 […] & gt;誰かmencoderのTomsMoComp相当のフィルタを知りませんか？ mencoderに TomsMoCompは無いです。transcodeを使って。	＊TomsMoComp：動き補償デインターレーサ。transcode、 AviSynthで使える。＊transcode：Linux、BSD、MacOSXで動くエンコーダ。コマンドライン、使い方はものすんごく簡単に見える。
22.Justin 06/12/15@ 13:50	素早い返事をありがとう。自分はキャプチャーカードからdumpしたNTSC-M 29.97 fps素材を使っている。場面がテレシネかインターレースドかは50/50のようだ。似たような事のあるはいないかい？自分は今、短いクリップで以下のような逆テレシネを試している。 -vf,pullup,softskip, etc そしてもしそれがjittery（＊神経過敏の＊）に見えたら、以下を試す。 yadif=3:1,mcdeint=2:1:10,framestep=2,filmdint=dint_thres=256 こちらのほうがかなり良い。どちらの場合でも出力は24000/1001 fps。というのは少しでも縮めたいのと、ほとんどの素材が23.97fpsに見えるからだ。これはアプローチとして正しいだろうか？

*1）動画圧縮の学術的な比較で良く見る映像。元々は2001年にMPEGが『この画像を圧縮してみな、MPEG-4 ASPよりスゴかったら採用してやらんこともないぞ？』と出したお題の一つ。Container Ship, News, Foreman, Tempete, Bus, Mobile Calender, Flower Garden、と言えば、そのスジの方は絵が浮かぶらしい。この7つのお題の圧縮大会で優勝したH.26LがH.264/AVC規格のひな形。なお、この実験の最大解像度は720x480、主観テスト（といっても統計的な精度補正を考えたもので、おいらがの感性では、などと言うのとはレベルが違う）の結果は、1MbpsのH.26Lは元画像と区別できない。512kbpsのH.26Lは1MbpsのMPEG-4と同等。手許の1024kbps固定は偶然だけども。ちなみにパテントリストには日本の大手家電がずらりと並んでいるので、2chには結構な情報が埋まっているハズだ。ドレがそうなのかってのはおいらには見極められんが。

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

エンコード十戒

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

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

[ 2007/01/09 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)

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)

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

1.視覚の個人差

1.1. 視力

1.2. 動体視力

1.3. 色覚

1.4. 脳の処理能力

VGA(640x480)

VISTA(640x352)

疑問

■MPEG-4 SP/ASP時代（2000～2004）

総 括

年 表

■H.264/AVC 時代（2005～2010）

総 括

年 表

1. はじめに

2. 妥協の前には理想が要ること

3. 必要のないものに深入りしないこと

4. 検証のない経験は非効率なこと

5. おわりに

fps混在

時間軸fps混在

空間軸fps混在

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

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

■参考記事

映 画界の呼称

DAR とPARとSAR

一般的な SAR:

なぜx264にDARが無いの か。

AVIと QuickTimeとMPEG規格

Comments

エンコード十戒

PSNR：

SSIM：

総括

年表

総括

年表

映画界の呼称

なぜx264にDARが無いのか。