YouTubeに高画質でムービーをアップする(4) - gamme’s direction is as pleasing to the soul.

その(1)http://d.hatena.ne.jp/gamme/20070525/1180108893
その(2)http://d.hatena.ne.jp/gamme/20070826/1188155073
その(3)http://d.hatena.ne.jp/gamme/20071005/1191867474

引き続きDivXを試してみました。もうちょっと細かい設定をいじりつつ。

ソース画像は(2)の時と同じ。ただしiMovieで.movに吐き出したファイル設定をちょっと変えてみました：

test16.mov iMovieの標準ビデオ圧縮設定=>
圧縮の種類：H.264
フレームレート：現在のサイズfps
キーフレーム：等間隔に設定、24フレーム、フレーム並べ替え
データレート；自動
品質：最高
エンコーディング：最高品質（複数回実行）

test16.mov QuickTimePlayerのインスペクタ=>
フォーマット：H.264、320x240、約1670万色、AAC、モノラル、48.000kHz
FPS：29.97
データ容量：34.92MB
データレート：7553.09kbps

画像サイズを320x240にしたのは、実際YouTubeでは320x240の画像を450x340に引き延ばして表示しているので、なら450x340を作ってあげるよりも320x240を作ってあげてそれがどう表示されるか見た方がいいのかなあと思って。しかし、.movだと、40秒程度のもので34.92MBとかになってしまうのだから、画質が良いのはわかっているけど、4分とか5分のものだったら.movでアップするのは無理そうですね。

とりあえずやってみた【test16】:

test16.divx DivX Converterの詳細設定=>
【ビデオ】
入力時の解像度を保持
リサイズフィルタ：バイリニア法（非常に滑らかな画像）
ソースプリプロセス：最高
フレームレート：30
サイコビジュアル強化：オフ
インターレース：プログレッシブソース
【コーデック】
エンコードパフォーマンス：異常な高品質
エンコードモード：2pass
平均ビットレート：550kbps
キーフレームシーンしきい値：50%
最大キーフレーム間隔：300
MPEG4ツール、両方向：アダプティブ・シングルコンセキュティブ
クォンティゼーション：H.263
【オーディオ】
特にいじっていない

test16.divx QuickTimePlayerのインスペクタ=>
フォーマット：DivX 5.0、320x240、約1670万色、MPEG Layer 3、モノラル、44.100kHz
FPS：30
データ容量：2.96MB
データレート：641.41kbps

拡張子.divxのままで問題なくアップできました。で、見て見ると…うーむ、こんなにヒドくされてしまうのか残念だなあ、という品質(￣д￣)。YouTubeで.flvした結果どーなったのか見てみようと、おはYouTubeして見ると：

test16_oha.flv QuickTimePlayerのインスペクタ=>
フォーマット：Sorenson H.263(Perian)、320x240、不明、MPEG Layer 3、モノラル、22.050kHz
FPS：29.97
データ容量：1.43MB
データレート：309.46kbps

データ容量がほぼ半分になってる、っていうのはデータレートもほぼ半分になっているからだね…。ローカルでQuickTimePlayer(w/Perian)で320x240で見ている分には「これでいいんじゃないのー」っていうクオリティなんだけど、450x340に引き延ばして表示すると、うーん、とても「いいんじゃないの」とは言えないクオリティーに。っていうか、データレートもうちょっとくれよ〜。320kbsくらいまでOKだったんじゃないのかい？(T_T)

VisualHubで.flvしてみたのと比べてみました。特に設定はいじらず。あ、エンコモードは2passで。

test16_vh.flv QuickTimePlayerのインスペクタ=>
フォーマット：Sorenson H.263(Perian)、320x240、不明、MPEG Layer 3、モノラル、44.100kHz
FPS：30
データ容量：3.43MB
データレート：828.95kbps

え、test16.divxよりファイルサイズが大きくなってる…。これじゃ手元でわざわざ.flvする意味ないじゃん(^_^;)　データレートも増えてるし。再生してみると、test16_oha.flvよりはキレイだけど（データレートは倍以上だもんね）、相変わらずブロックノイズは出まくりだし、最初のパン＆ズームのところのにじみは見られるクオリティじゃあない感じ。

データレート上がった割にはtest16.divxよりクオリティ低くない？と思って、14秒目のところをキャプチャ撮って比べてみました。再生はQuckTimePlayer(w/Perian)。プレーヤーのフレームサイズを、YouTubeで見えるサイズの450x380に拡大して再生してみました。【test16_oha.png】【test16_vh.png】【test16_divx.png】。test16_ohaは、滲ませてデータレート削減！という感じかな。なので、光っているところ全体にもそれが適用されちゃって、光っている感が無くなってしまう。その割には動いているところ（手）にがっつりブロックノイズが乗ってしまっているし。test16_vhでは、ブロックノイズがだいぶ軽減されている。test16_divxは、ブロックノイズが出て着ることは認められるものの、これくらいなら許そうかな、というレベルにまでなっている。光っている物の質感がだいぶ保持されてて、これくらいは保ってほしいなあという感じ。こほ３つの中ではオリジナルの.divxがベストだった。

うーんでも、この「このままでいて欲しい」.divxをYouTubeにアップすると、データレートはどうやったって減らされてしまうのね、どうも。

test16と同じネタを、ビットレート2000kbsでエンコしてみた。データレートはtest16の3倍近く。ローカルで見ると、450x380にリサイズして見ても申し分のないクオリティ。

test17.divx QuickTimePlayerのインスペクタ=>
フォーマット：DivX 5.0、320x240、約1670万色、MPEG Layer 3、モノラル、44.100kHz
FPS：30
データ容量：9.60MB
データレート：2077.59kbps

これをYouTubeにアップしてみた【test17】。test16よりは滲み方がひどくはなくなったけど、もうちょっとよいクオリティにしたいなあ、という感じ。パンやズームがない画は、やっと見れるクオリティになったなあ、という印象を受けました。明暗差がはっきりとある（暗い中にスポットライトが落ちている画、とか）ものも、それがフレームが固定だったらまあ見れますが、パンやズームがあるととたんにブロックノイズがわさわさ〜とうるさい感じになります。

test17をおはYouTubeしてチェック。

test17.flv QuickTimePlayerのインスペクタ=>
フォーマット：Sorenson H.263(Perian)、320x240、不明、MPEG Layer 3、モノラル、22.050kHz
FPS：29.97
データ容量：1.43MB
データレート：308.46kbps

先ほどと同じ、14秒目のところをキャプチャして比較してみました【test17_divx.png】【test17_oha.png】。test17_divx.pngは、申し分のないクオリティ。ブロックノイズも、キャプチャーしてみて始めて「あ、ここにノイズ出てる！」とわかるレベル。ブロックの大きさもとても小さいです。それと比べてtest17_oha.pngは、まあ画質は悪いけど、test16_oha.png、test16_vh.pngと比べると全然いいやっていう感じ。ノイズは、20ピクセル四方と13ピクセル四方程度の大きさのブロックが混在しているような感じに見えます。滲みはだいぶ軽減されて、画面にシャープさが増してきました。もうちょっとなんとかしたいんだけどね…。

やっぱり、できるだけデータレートの高いデータを作って、YouTubeのエンコーダーに任すのがよい感じがしてきました。

で、データレートを上げる為に、画像サイズを上げてみました。YouTubeの表示サイズである450x380の.movファイルを作ってみました。

studio_test_450.mov QuickTimePlayerのインスペクタ =>
フォーマット：H.264、450x340、約1670万色、AAC、モノラル、48.000kHz
FPS：29.97
データ容量：40.66MB
データレート：8.80Mbps

うお、データレートがメガビットに！　これから、画像サイズは変えないでデータレート2000kbpsの.divx、6000kbpsの.divxを作りました。ちなみにDivX Converterのビットレートの最大設定値が6000kbpsでした【test18】【test19】。

test18.divx QuickTimePlayerのインスペクタ=>
フォーマット：DivX 5.0、448x340、約1670万色、MPEG Layer 3、モノラル、44.100kHz
FPS：30
データ容量：9.51MB
データレート：2077.59kbps

test19.divx QuickTimePlayerのインスペクタ=>
フォーマット：DivX 5.0、448x340、約1670万色、MPEG Layer 3、モノラル、44.100kHz
FPS：30
データ容量：28.09MB
データレート：6080.28kbps

test17.divxとtest18.divx、ファイルサイズがほとんど変わりません。そして、test18.divxとtest19.divx、QuickTimePlayer上では見た目はまったく変わりがありません。うーんしかし、40秒足らずで28MBになってしまうのはちょっと実現不可能だな…。

アップしてみて試聴。test18は、あーやっぱりブロックノイズはどうしても出てしまう。ブロックノイズだけならまだいいんだけど、滲んだ感じになってしまうのがイヤだなあ。おはYouTubeしてみると、画像サイズはやっぱり320x240にリサイズされていました。ブロックの大きさが全体的に細かい感じになったような…といっても10ピクセル四方くらいはあるのだけれど。

test19、うーんtest18とあんまり変わりないかも…。test17、test18、test19だったら、test17が一番いいかも…。つまり、YouTubeが、大きい画像を小さく圧縮する計算と、同等サイズを.flvに変換するだけの計算とでは、後者の方が得意、っていうことなんだなと思った。

他にも、DivX Converterの設定をいろいろ変えてみた。「ソースプリプロセス」は「最高」よりも「オフ」の方が滲みがよい感じだった。シャープすぎる画像の方で、シャープさが画面の中を移動していく画像の方がブロックノイズは出やすくなってしまうので。「インターレース」も「MPEG4ツール、両方向」も「クォンティゼーション」も、いじってみてもあんまり大差のない感じだった。むしろデフォルトの方がいいっていうか。

これまで結論：

100MBのリミット範囲内で、できるだけデータレートのデカいファイルを作ってアップするのがよいっぽい。でも、データレートの上限はどうも2000kbpsっぽい。2000kbpsから上は、どんなに上げても劇的には変わらないっぽい。むしろ滲んだ感じに.flv化されてしまうっぽい。
画像サイズは、320x240がいい感じにエンコしてくれるっぽい。
ファイル形式は、圧縮率がよいという点でDivXがよいっぽい。ファイルサイズのリミット（と作業時間）が許すのなら、.movか.mp4でH.264で圧縮したものがノイズの少なさでは一番よいっぽい。.flvへのエンコードはYouTubeに頼った方がクオリティーがいいみたい。

これでひとまず、YouTube実験は終了ーって感じです。これ以上のクオリティの向上は望めないだろう、と。またYouTubeがファイル制限を変えたりエンコ方法を変えたりしたら、実験してみるつもりです。