YouTubeアップロードテストはまだ続く

  とにかく気になる点は解決させないと気が済まないみたいです。この性格はいつか命取りになるぜ。

  まず気になるのは、以前にアップした
Rez 3D h264 test
が前記事のアップロードよりも綺麗に見える事。YouTubeの仕様変更の可能性を疑ってしまった私は同じファイルを再アップロードしてみる事にしました。画質に関わる仕様変更が有ったなら、これで判るはずです。
  ところがYouTubeって同じファイルのアップロードは拒否してくれるんです。ファイル名を変えてアップロードしても駄目。ちゃんとファイルの中身を見て判断しているようです。別にちょこっと画質チェックができればいいので、元ファイルの頭1000フレームだけ取ってアップロードしてみました。こんなふう。
> ffmpeg -i source.mp4 -vframes 1000 -sameq test.mp4
  こうなりました。
Rez 3D h264 test (again)
  画質に変化は見られません。たまたまこの動画がYouTube映えする画面だったみたいです。疑ってゴメン。

  この動画はアナグリフで見やすいように、事前に画質調整していた事を思い出しました。それじゃあと今回の動画サンプルもガンマをいじってみました。
MP42 1000k, gamma adjust
  おお、結構良くなりました。ワイヤーフレームがくっきりしましたね。

  そういえば上の「h264 test」の元動画は480x360でした。という訳で640x480から480x360にリサイズしてアップしてみました。
MP42 1000k, gamma adjust, resized
  おおっと、これはビックリです。明らかに違ってます。
比較画像
  左が480x360、右が640x480。640x480は細かいラインが潰れています。
  想像するに、YouTube側ではアップロードされた動画を480x360にスケーリングして再エンコードしているのではないでしょうか。でもそのスケーリング処理がショボいみたいです。どうやらこれは断言できそうです。480x360でアップロードしましょう。
   いやちょっと待て、ビットレートが同じなら画像が大きいほうが画質が落ちるのは当たり前だ。ごめん。

  同じ条件で高めのビットレートな動画もアップしてみました。元ファイルをそのまま「-sameq」で変換したので、これはH264です。
H264 2253k, gamma adjust, resized
  期せずして、MP42とH264の比較にもなってくれました。
比較画像
  左：MP42 1000k、右：H264 2253kです。なんだか大差は無いですね。
  これもまた想像ですが、過去の実験データから見るにYouTubeにアップロードされたファイルは500k以下のビットレートで再エンコードされている気配です。あまり高ビットレートでアップロードしても意味は無さそうです。「高画質で表示する」が出現する条件の境界が1000kアップロード近辺のようなので、そのへんを考慮する必要は有りそうですが、500kアップロードでも「&fmt=18」を付ければ1000kアップロードと大差の無い品質の高画質表示ができます。
  MP42とH264で結果に差が出ていない点も興味深いです。

  低ビットレートな動画は広い範囲のなめらかなグラデーションに特に弱いみたいです。このサンプルでは露骨にブロックノイズになっています。コントラストをいじって暗い部分のグラデーションを潰してみました。
MP42 1000k, contrast adjust, resized
  かなり見栄えが良くなったような。アップロード元動画の画質調整はかなり重要のようです。


  ああ！またここで不思議な現象が！記事をアップしてから気付きましたが、今回の実験に使ったサンプル動画は「&fmt=18」だと汚い表示になってしまいます。「&fmt=6」だと高解像度表示になります。どうなってんの。「&fmt=18」と「&fmt=6」の違いってなんだっけ。これは調査せねば。もううんざりです。

  おいちょっと待て、とこの記事の動画を見直してみたら、ここの動画も「&fmt=6」対応でした。今まで「&fmt=18」で判断してました。そりゃあ以前の動画と比べて見劣りするわ。どうも今回の実験はサンプル動画の作り方にミスが有ったようです。(おかげでいろいろと新しい世界を知る事ができましたが。)これはサンプル作成からやり直しか？できれば私はもう遠慮したいのだけど。

[ 続くのか？ ]

YouTubeアップロードテスト：以前の記事の補足

  前記事で「H264」と書いてあるファイルですが、一部H264になってない物が有るみたいです。Media Player Classicのプロパティで見ると、「MP42」と出る。
  H264ファイルを
> ffmpeg -i source.mp4 -b 500k dest.mp4
とかやるとMP42に変換されてしまうようです。かといって
> ffmpeg -i source.mp4  -f mp4 -vcodec libx264 -b 500k dest.mp4
とかやるとビットレート指定が無視されてしまいます。あー訳判んね。

  だけど、前々記事の場合は全部H264に変換できています。ビットレート指定も上手くいっています。これの元ファイルは確かffdshowのmsmpeg4v2を使用していたと思います。そのへんが関係しているのでしょうか。今はそこまで突っこんで調査する気力がありません。

  Huffyuvの設定をこんなふうにしてみたら、
> ffmpeg -i Huffyuv-file.avi -f mp4 -vcodec libx264 -sameq H264-file.mp4
の結果が変化しました。
  前記事では「-sameq」で変換後のH264ファイルのビットレートは3054kだったのが18000kぐらいになって、ブロックノイズも見えなくなりました。ファイルサイズは100Mぐらいになってしまいますが。

  動画関連はのめり込むときりがありません。皆さんご注意下さい。

さらに補足：
  以前のバーチャルリアリティー展のファイルを調べてみると、これは全部H264になってました。これもすべてHuffyuv->H264の手順で変換してます。こっちはビットレートの変換もちゃんと動作します。という事は、原因はアマレココのコーデックかもしれない。

結局突っ込んじゃいました：
  上のH264ファイルに関するトラブルは、アマレココでキャプチャーした動画でのみ発生しているみたいです。という訳で、いちおう問題解決。

YouTubeアップロードテストの続き

  前記事で「時間の無駄」とか書いておきながら、ムラムラきたのでやってしまいました。ほとんど病気です。

  補足：なんかいろいろ間違いがありました。この色の文字は後からの補足。詳しくは次の記事にて。

  サンプル動画はnullDCのRezのキャプチャ。1ドット幅フォントあり、グラデーションありで、画質チェックには最適サンプルだと思われます。

  デスクトップキャプチャーにはアマレココを使用しました。
  紹介が遅れてしまいましたが、このソフト最強です。nullDC動かしながらのキャプチャーなのに、フレーム落ちはほんのわずか、キャプチャー範囲指定のユーザーインターフェイスもうっとりするほどに完璧です。デスクトップキャプチャーマニアな方は是非どうぞ。

  アマレココは独自コーデックを使用しているので、ffmpegから直接変換できません。AviUtlを使ってffmpegから読めるHuffyuvに変換しました。Huffyuvは可逆圧縮コーデックなので、変換による画質の劣化は無いはずです。

  あとはいつものようにffmpegでH264に変換するだけ…と思ったのですが、なんか変だ。
> ffmpeg -i rez_test.avi -f mp4 -vcodec libx264 -b 500k uploadtest_500k.mp4
> ffmpeg -i rez_test.avi -f mp4 -vcodec libx264 -b 1000k uploadtest_1000k.mp4
とやっても、変換後のファイルが同じです。
> ffmpeg -i rez_test.avi -f mp4 -vcodec libx264 -sameq uploadtest.mp4
と同じ結果になってます。あら困った。

  試しに上のH264変換済みの「-sameq」なファイルを
> ffmpeg -i uploadtest.mp4 -b 500k uploadtest_500k.mp4
> ffmpeg -i uploadtest.mp4 -b 1000k uploadtest_1000k.mp4
としたら上手くいきました。Huffyuvからの直接なビットレート変換はできないみたいです。そういう事にしておきましょう。(間違い：実はこれではMP42に変換されてしまいます。)

> ffmpeg -i rez_test.avi -f mp4 -vcodec libx264 -sameq uploadtest.mp4
でHuffyuvからH264に変換したファイルがこれ。
3000k：H264元画像(これはH264になってます)
  H264ファイルのビットレートは3054k。ffmpeg様の「-sameq」を信用するならば、これがこの場合の最大ビットレートのようです。でもグラデーションの部分がちょっとブロック化してます。(Huffyuvの設定をいじると良い結果になるようです。)
  Huffyuvのファイルサイズは350Mバイトだったのに対して、H264ファイルは14.8Mバイト。かなり縮んでます。
  これをYouTubeにアップロードすると、こうなります。
3000k：YouTube標準
3000k：YouTube高画質
うーん、こんなもんかな。

  同様に、
1000k：H264元画像(これは実はMP42)
1000k：YouTube標準
1000k：YouTube高画質

500k：H264元画像(これもMP42)
500k：YouTube標準
500k：YouTube高画質

  むむ、アップロード元動画のビットレートに関わらず、結果はほとんど同じのような。皆さん、どう思われますか。(「&fmt=18」で比較してました。この動画は「&fmt=6」で高画質化するのが正解だったようです。500k動画は「&fmt=18」の効果は有りますが、「&fmt=6」では効果無しです。)
  あら、500kは「高画質で表示する」が出現しないわ。最初のH264テスト
これ
は500kアップロードで出現したのに。どういう事？

  いや待てよ、この時もHuffyuv->H264だったから、実は最大ビットレートでアップしていたのかもしれない。元ファイル残ってるかな。こっちのほうが綺麗に見えるのは、アナグリフで見やすいようにガンマ調整してからアップしたせいかもしれない。このへんはYouTubeの仕様変更の可能性も考えられます。あーん、訳わかんないです。もうやだよー。


  最初のテストの元ファイルが残ってました。ものぐさ万歳。500kのつもりでしたが、1677kになってました。私が過去にHuffyuv->H264でアップした動画は、全部最大ビットレートでアップしていた可能性大です。あわわ。
  「高画質で表示する」出現の境界線はビットレート1000kぐらいかな？もうちょと実験してみれば判るけど、めんどくさいよー。

YouTubeアップロードテスト

  何気にYouTubeのアップロードテスト実験をしてみました。
  aviファイルをそのままアップロードするのと、H264に変換してアップロードするので違いが有るのか確認したくなったのです。気候がいいといきなり変な事をやりたくなります。以前の実験も参考にどうぞ。

  元ファイルはこの記事のこの動画。コーデックはmsmpeg4v2、ファイルサイズは14,999KB。ちなみに
> ffmpeg -i circular-pol_01.avi
とやると動画ファイルに関する情報を見られます。

  元ファイルは8:3なので、4:3に変換します。ビットレート400kは、元ファイルが790だったのでじゃあ半分でいいやという事で。このへんてきとうです。
> ffmpeg -i circular-pol_01.avi -s 640x480 -vcodec msmpeg4v2 -b 400k circular-pol_01_400k.avi
  これが変換後のファイル。ファイルサイズは5265KB。

  H264はこんなふう。
> ffmpeg -i circular-pol_01.avi -s 640x480 -f mp4 -vcodec libx264 -b 400k circular-pol_01_400k.mp4
  こうなります。ファイルサイズは4993KB。
  H264のほうがブロック感が少ないです。ファイルサイズも少し小さくなってます。H264優秀です。でも変換には結構時間がかかります。


  YouTubeにそれぞれをアップロード。
msmpeg4v2
H264

  アップロードが完了しても、「高画質で表示する」の表示が出るまでしばらく待たなければならないはずなのですが、アップロードが完了直後でもURLに「&fmt=18」を付けると「標準画質で表示する」が出現します。あれれ？画質も上がっているようです。「高画質で表示する」の場合と違いは有るのでしょうか。いちおうキャプチャを取っておきました。
msmpeg4v2：標準
msmpeg4v2：&fmt=18
H264：標準
H264：&fmt=18

  H264のほうが綺麗ですが、元のファイルがそうなんだから当然ですね。後で考えるに、サンプル動画の選択をミスしてますね。小さい文字とかが出てる画像のほうが良かった。なにしろ思い付きで行動してるもんで。
  後は「高画質で表示する」の表示が出るまで待つとしましょう。出るのかな？


  待ってる間に、ビットレート1000kなH264もアップしてみました。
> ffmpeg -i circular-pol_01.avi -s 640x480 -f mp4 -vcodec libx264 -b 400k circular-pol_01_400k.mp4
こうなります。ファイルサイズは12,040KB。ちょっとデカくなります。
  YouTube版はこちら。
H264,1000k

  ちょっと異変が有りました。上の場合と同様に、アップロードが完了直後に「&fmt=18」を付けてみても「標準画質で表示する」が出現しません。
H264,1000k：標準
H264,1000k：&fmt=18その1
画質は同じですね。
  その後リロードしてみたら、「&fmt=18」が普通の反応になりました。こちらの画質は上がっています。
H264,1000k：&fmt=18その2
  ファイルサイズが大きめだったので、YouTube側のファイル変換に時間がかかっていたのかもしれません。この段階では「高画質で表示する」の表示は出現しません。


  んで、上の記事を書いてから再度リロードしてみたら、またもや異変が。
  後からアップしたH264,1000kは「高画質で表示する」が出ているのに、それ以前にアップの400k版はまだどちらも「高画質で表示する」が出ていない！
  一晩ぐらい寝かせてみないと結論致しかねますが、もしかすると400kアップロードでは「高画質で表示する」が出ないのかもしれません。以前の実験の時は、500kで「高画質で表示する」が出ていました。このへんが「高画質で表示する」の出現境界線なのかもしれません。(> 実はこれ、勘違いでした。次記事以降で解説)でも「&fmt=18」付ければ400kも高画質表示になるんですけどね。

  という訳で、「高画質で表示する」のリンクからの再生画面のキャプチャです。
H264,1000k：「高画質で表示する」
  上の「H264,1000k：&fmt=18その2」と同じみたいですね。という事は「高画質で表示する」用の動画はアップロード直後に出来上がっているということになります。なんで待たされるんだろ。

  比べてみると、H264ならば400kも1000kもそれほど大きな違いは無さそうな。動画の時間や用途によって使い分けるのが良さそうです。「高画質で表示する」が出ない(？)400kアップロードでも、「&fmt=18」を付けたリンクに誘導するようにすれば有効に使えると思います。
  この次の機会が有ったなら、もうちょっと細かい画像でやってみようと思います。っていうか誰かやって。

  とにかくYouTubeは時代の流れに合わせて仕様がコロコロ変わっているようです。私はYouTube歴まだ3ヶ月ぐらいなのですが、その間だけでもかなり変化が見られます。詳しい仕様を公開していないのもそのせいなのでしょう。今回のレポート内容もいつまで通用してくれるか。多分長くは通じないのでは。
  こんな物の解析に夢中になるのははっきり言って時間の無駄です。そこそこに切り上げて他の事に夢中になったほうがいいと思います。
  それでもYouTubeは国際標準な点が魅力です。日本国内だけでは立体視ヲタクの数が少なすぎなのです。

YouTube用の高画質動画を作る

  はあ、やっとできた。とりあえず比べてみてよ。

普通にアップロード(320x240,flv)

高画質(480x360,H264)

  全然違うでしょ。あ、赤青メガネは裏返して見てね。


  とりあえず方法だけ。詳しい説明はあとで。

  ここ の最新版ffmpegを使う。私はffmpeg-r13712-gpl-static-win32.tar.bz2を使いました。

  コマンドライン：
> ffmpeg -i source.avi -s 480x360 -f mp4 -acodec libfaac -ac 2 -ab 125k -ar 22050 -vcodec libx264 -b 500k dest.mp4
  「-ar 22050」は「-ar 44100」とかでもいいかもしれない。動画のビットレートは見本に合わせた結果なので、これが本当に適切かどうかはまだ不明。

  できあがった「dest.mp4」をそのままいつもどおりにYouTubeにアップすればオーケーです。
  再生すると「高画質で表示する」という表示が出現します。


  ただしこの表示が出るには、アップロード処理完了後にYouTubeで動画を表示できるようになってからさらに10分ぐらいかかるので注意。のんびり待とう。
  この「高画質で表示する」をクリックするか、動画のURLに「&fmt=18」を付けるかすると高画質再生になります。

  何故かこの動画を高画質モードで再生すると8:3表示になる。なんで？アップロードした動画は4:3なのに。ついでに比較動画。