月刊マリシーユ・ビゼン(笑)

  なんと今月の月刊マガジンの表紙はマリシーユ・ビゼン様だ！とりあえずここの表紙絵は保存しておこう。

東京タワーで、３Ｄバッティング。
  STEREOeYeさんとこのステレオ写真掲示板から勝手に転載。東京タワーのホームページを見ても、これに関する情報が無い。あんまりなので全文引用。

■場所：東京タワー５Ｆ（屋上）
■日程：８月８日～２４日（１１時～１６時）
■内容：
アニメ投手（メジャー、タッチなど）の立体映像をスクリーンに投影。
偏光メガネをかけたプレーヤー（バッター）が、飛んでくるボール（映像）
を打ち、そのタイミングによってアウト・ヒット・ホームランなどの映像
が流れるもの。
■主催：講談社/小学館

  私も行けたら行ってみよう。東京タワーって15年ぐらい前に一回行ったきりだ。その時はサンガリアコーヒーの販売機があったのに感動した。

  さらに転載。
ステレオフォトメーカーがバージョンアップ
  Duboisアナグリフなる新しいアナグリフ方式を搭載したそうです。
サンプル画像
  アナグリフ奥が深いです。Duboisアナグリフに関するリンク先を読んでみましたが、私にはさっぱり分かんないです。

DepthQ HD 3D Stereoscopic Video Projector by Lightspeed Design
  一体型3Dプロジェクターの新型です。液晶シャッター方式かな？6000ドル。もう一息ですね。

はじさい　せんがんみこし
  これは…

Googleマップの「ストリートビュー」機能について、画像URLの確認
  うわぁ、目茶苦茶おもしろい。
  panoid(ぱのあいでー、ですよ)の値は、ストリートビューの写真の上でドラッグ操作してストリートビュー窓の余白部分で右クリック->選択した部分のソースを表示で見られた。ああなんだ、「リンク」のURLに書いてあるじゃん。
惣菜山口前
そのアップ

Googleストリートビューについて
  Googleストリートビューが気持ち悪いという人の意見。まったくそのとおりなんだけど、私としてはこの新しい気持ち良さの感触がそのへんの気持ち悪さに勝ってしまっている。でもこれを利用した犯罪は絶対起こると思う。

火事で燃えている真っ最中の家を「Google マップ ストリートビュー」で発見
  こちらをどうぞ。

YouTubeダウンロードテスト

  まだやってるよ。でも今度はアップロードじゃなくて、ダウンロードです。

YouTubeMP4
  ここを利用すると、YouTubeの高画質動画を(多分)そのままH264なmp4でダウンロードできる。でも対応しているのは「&fmt=18」形式のみみたい。
  例えば、この動画。アップロードした元動画は480x360のビットレート1000kだったんだけど、ビットレートは500kぐらいに再変換されて、ファイルサイズも半分ぐらいになっている。他の動画も数本試してみたけれど、傾向は同じ。なるほどなるほど。それでも画質的には元ファイルと比べて見劣りしないレベルです。まあ元ファイルは320x240を480x360に引き伸ばした程度のもので、そんなに綺麗な動画じゃないんだけど。

  という訳でYouTubeのステレオ動画を鑑賞する方法がまたひとつ増えました。
  mp4なのでそのままではステレオムービープレイヤーやStereoscopic Playerで見られないけど、動画のフォーマットを変換してやれば見られるようになります。ffmpegなら、
> ffmpeg -i source.mp4 -sameq dest.avi
これだけ。

  ちなみにこのサイトは私がYouTubeにハマりだした3ヶ月ぐらい前にも一度試した事があったのですが、その時は上手くダウンロードできませんでした。YouTubeの仕様変更に合わせてバージョンアップしているみたいです。今後も頑張ってほしいものです。

YouTubeアップロードテスト：もういいかげんいやんなってきたぞ

  H264についてぐぐってみたら、x264 詰め合わせなるものを発見しました。
  こちらからどうぞ。
seraphyのプログラム公開所
  トップから2. プログラム -> 改造したソフトでダウンロードできます。ぱっと見じゃ使い方も良く分からない詰め合わせですが、AviUtlのプラグインが入っています。これなら簡単に使えるかも。

  はい、簡単に使えました。x264.928.release01.rar(最新版ね)をダウンロードして、「auo」、「cli」フォルダの中に入っている
x264gui.auo
x264gui.ini
x264.exe
x264afs.exe
をAviUtlのフォルダにコピーするだけで使えます。後は普通にAviUtlを使って、保存する時に
ファイル -> プラグイン出力
とするだけ。「ビデオ圧縮」をクリックすると、x264の設定画面が出てきます。ビットレート指定も可能です。音声エンコーダを指定しないと先に進めません。ffmpegを選んでおきました。

  これは指定どおりのビットレートでエンコードできています。480x360の1000kだと、ファイルサイズはたったの3.86MBです。おおお。これならアップロードもあっという間です。
x264 1000k, use x264.exe
x264 2000k, use x264.exe, VGA
  あーん、やっぱり「&fmt=6」だよー。もう画質の比較をする気力も有りません。さよーならー。


  動画について突っ込んだ事をやるならば、やはりそれなりの基礎知識は必要ですね。勉強して出直します。結局実りの無い実験となってしまいました。今回の実験におけるいちばんの収穫は、

アマレココとFastCodecの組合せはスゲーぞ

という事でしょうか。

  さあ、他の事やろーっと。

YouTubeアップロードテスト：まだやってる

  いーかげんにしないと、しつこいのは嫌われるよ。ギクリ。

  サンプル動画の作り方を変えてみた。
  アマレココの独自コーデックを使わないで、FastCodecを使ってみた。いやこれが凄いのなんの。コマ落ち？なにそれってかんじ。それでもH264への変換具合は前記事と同様。上手くいかない。独自コーデックのせいではなかったようだ。

  Debut+FastCodecでやってみる。これもかなりいいかんじでキャプチャーできる。でもやっぱりH264への変換は上手くいかない。

  AmCap+VHScrCap+FastCodecでやったみたら、変換できた！でもこの組み合わせはとんでもなく遅いのよ。でも録画ソフトによって結果が変わる事が判明した。

  ちなみに、以前に上手くいっているステレオ撮影動画は、ふぬああ+FastCodecでやっている。これをAviUtlでHuffyuvに変換して、ffmpegでH264に変換。ふぬああは設定が面倒なので、今回はまだ試していない。


  ちょっと気分を変えてAviUtlからffdshow Video Codecを使ってH264にしてみた。「avarage bitrate」を500kにしてエンコード。いちおうファイルサイズは縮むけど、ffmpegでチェックしてみるとビットレートは4565kと出る。ファイルサイズは17.7MB。
H264 500k, use ffdshow
  ね、凄いでしょ。再生スピードいじったりしてないんですよ。キャプチャーした動画そのまんまですよ。
  それでも高画質のフォーマットは「&fmt=6」。なんか根が深そうだ。あーん、アマレココのキャプチャーを「&fmt=18」で出したいよー。

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」で判断してました。そりゃあ以前の動画と比べて見劣りするわ。どうも今回の実験はサンプル動画の作り方にミスが有ったようです。(おかげでいろいろと新しい世界を知る事ができましたが。)これはサンプル作成からやり直しか？できれば私はもう遠慮したいのだけど。

[ 続くのか？ ]