サブタイトル:「mer2のマイノリティ・レポート(笑)」 --- 最近忍者ブログの仕様が変わったようで、一部の画像が見えなくなってますが、画像のURLコピペで見られます。(どうしよう困ったな) --- ご用件など、ございましたらtwitterまでどうぞ。
前記事で「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ファイルに関するトラブルは、アマレココでキャプチャーした動画でのみ発生しているみたいです。という訳で、いちおう問題解決。
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ファイルに関するトラブルは、アマレココでキャプチャーした動画でのみ発生しているみたいです。という訳で、いちおう問題解決。
PR
前記事で「時間の無駄」とか書いておきながら、ムラムラきたのでやってしまいました。ほとんど病気です。
補足:なんかいろいろ間違いがありました。この色の文字は後からの補足。詳しくは次の記事にて。
サンプル動画は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ぐらいかな?もうちょと実験してみれば判るけど、めんどくさいよー。
補足:なんかいろいろ間違いがありました。この色の文字は後からの補足。詳しくは次の記事にて。
サンプル動画は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のアップロードテスト実験をしてみました。
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は国際標準な点が魅力です。日本国内だけでは立体視ヲタクの数が少なすぎなのです。
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アップロードでは「高画質で表示する」が出ないのかもしれません。
という訳で、「高画質で表示する」のリンクからの再生画面のキャプチャです。
H264,1000k:「高画質で表示する」
上の「H264,1000k:&fmt=18その2」と同じみたいですね。という事は「高画質で表示する」用の動画はアップロード直後に出来上がっているということになります。なんで待たされるんだろ。
比べてみると、H264ならば400kも1000kもそれほど大きな違いは無さそうな。動画の時間や用途によって使い分けるのが良さそうです。「高画質で表示する」が出ない(?)400kアップロードでも、「&fmt=18」を付けたリンクに誘導するようにすれば有効に使えると思います。
この次の機会が有ったなら、もうちょっと細かい画像でやってみようと思います。っていうか誰かやって。
とにかくYouTubeは時代の流れに合わせて仕様がコロコロ変わっているようです。私はYouTube歴まだ3ヶ月ぐらいなのですが、その間だけでもかなり変化が見られます。詳しい仕様を公開していないのもそのせいなのでしょう。今回のレポート内容もいつまで通用してくれるか。多分長くは通じないのでは。
こんな物の解析に夢中になるのははっきり言って時間の無駄です。そこそこに切り上げて他の事に夢中になったほうがいいと思います。
それでもYouTubeは国際標準な点が魅力です。日本国内だけでは立体視ヲタクの数が少なすぎなのです。
とにかくgooglemapストリートビューには驚いた。
「ストリートビュー」という名前だったかどうか忘れたけど、本国版で似たようなサービスが始まった時は「ふーん、おもしろいね」レベルの物でそれっきりだったので、その進化ぶりにどびっくりです。できれば定期的に更新して、ライブラリ化してほしいぞ。
googlemapストリートビュー収録車の目撃記事
使用カメラはLadybug2。いくらするんだろう。
こういうのを見ると立体視版を構想してしてしまうのは悪いクセだ。横方向のパノラマは問題無いだろうけど、チルトすると矛盾が出るな。うーん、どうしよう。
「ストリートビュー」のプライバシー問題、グーグルが方針説明
「公道に出ている物なら公開したって問題無いだろう」という方針みたい。どんどんやってくれ。
やばい写真
その1
その2
>前後の写真を見てみると、「その2」はただ道を歩いていただけっぽいです。よかったね。まあホテル街ではあるが。
秋葉原のキッチンジローが消火活動中なので、秋葉原近辺の収録は5月27日だったらしい。
関連:
Flash Panorama Player
こんな事をしている人もいる
2008/01/26あたり。
バーチャルドライブ関連:
小特集
立体視版
Creamy!
番外
あらこんなのも有ったのね。
映像地図 | LOCATION VIEW (360゜ハイブリッドマップ)
アカウント無くても、右上のランキングから入れます。
「ストリートビュー」という名前だったかどうか忘れたけど、本国版で似たようなサービスが始まった時は「ふーん、おもしろいね」レベルの物でそれっきりだったので、その進化ぶりにどびっくりです。できれば定期的に更新して、ライブラリ化してほしいぞ。
googlemapストリートビュー収録車の目撃記事
使用カメラはLadybug2。いくらするんだろう。
こういうのを見ると立体視版を構想してしてしまうのは悪いクセだ。横方向のパノラマは問題無いだろうけど、チルトすると矛盾が出るな。うーん、どうしよう。
「ストリートビュー」のプライバシー問題、グーグルが方針説明
「公道に出ている物なら公開したって問題無いだろう」という方針みたい。どんどんやってくれ。
やばい写真
その1
その2
>前後の写真を見てみると、「その2」はただ道を歩いていただけっぽいです。よかったね。まあホテル街ではあるが。
秋葉原のキッチンジローが消火活動中なので、秋葉原近辺の収録は5月27日だったらしい。
関連:
Flash Panorama Player
こんな事をしている人もいる
2008/01/26あたり。
バーチャルドライブ関連:
小特集
立体視版
Creamy!
番外
あらこんなのも有ったのね。
映像地図 | LOCATION VIEW (360゜ハイブリッドマップ)
アカウント無くても、右上のランキングから入れます。
最新記事
(04/20)
(11/21)
(01/01)
(06/12)
(06/12)
(05/29)
(05/22)
(05/21)
(12/25)
(12/20)
最新コメント
[08/27 BernardSr]
[08/27 BernardSr]
[08/27 BernardSr]
[12/29 GroverIcow]
[12/26 gayenKinesl]
[12/25 gayenKincfv]
[12/25 geRoesonokp]
[12/24 geRoesonmxu]
[06/30 LindsayDom]
[06/24 Ayukupim]
[06/22 francinerj2]
[06/21 Karsewis]
[06/17 Porsulik]
[06/16 Porsulik]
[06/16 Porsulik]
[06/16 Amimior]
[06/15 WilfordMof]
[06/11 lakeishatb1]
[06/04 Mathewlomi]
[05/31 tiopomWarriorvrp]
[05/31 Lasdumor]
[05/29 Aredorer]
[05/27 IMPUCKICT]
[05/26 Asosans]
[05/24 RaymondZice]
カテゴリー
リンク
アーカイブ
アクセス解析
カウンター
カレンダー
01 | 2025/02 | 03 |
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
プロフィール
HN:
mer2
性別:
男性
趣味:
野良猫の餌付け