記事一覧

映像コラムでちょっとプラグを使ってみた


まぁ、今日は宣伝と言うことで勘弁していただきたい。5月21日に市民交流センターで常陸太田市文化団体連合会 の総会が開かれた。その模様を撮影させていただいたのを編集したのが上記のコラム映像。具体的にプラグを使うとはどういうことか解り易く書いたと思いたい(笑

まず音楽はフリーのMP3のクラッシックをダウンロードしクイックタイムでAIFFに変換してシーケンスに貼付けた(そのまま使うと音がシャクル)

最初のシーンはSuper+と8点表示機を使っている。
Super+
http://audience.studio-web.net/FxScript/Fx.cgi?mode=dir&dir=11
8点表示機
http://audience.studio-web.net/FxScript/Fx.cgi?mode=dir&dir=72

Super+はマルチ色が8色まで可能なのでここでは2色使い立体効果をかけている。また中縁を若干太くしナビを使ってフェードインしている。機能が多過ぎて難解さは比類がないが(笑)使い込めばひと味違った表現が可能となる。難はレンダリングに時間がかかることで短いカットには有用だが現業で使う場合はマルチCPUのMacが必要となるだろう。

左下は8点表示機の表示だがもっぱらマップ(地図)系を意識して開発した物だが最近多用している。理由は楽だしブログ用の映像に、割り切って使える簡易性があるからだ。次の団体数のスーパーでも使っている。(スーパーの下には座布団を引いている(笑))

受け付けシーン2カット目の上方1/3はMask on Mosaic2で肖像権の問題が発生するとややこしいのでボカしてしまった。
Mask on Mosaic2
http://audience.studio-web.net/FxScript/Fx.cgi?mode=dir&dir=3

次は同録シーンとなるが家庭用のカメラは収音特性が悪いので話の内容についてはセリフ挿入機をフルに使っている。
セリフ挿入機
http://audience.studio-web.net/FxScript/Fx.cgi?mode=dir&dir=85

これと冒頭ではスーパー+、途中の挿入映像ではBSドキュメンタを使用している。同録映像は時間的にもたれる事が多いので映像をインサートすることが多いが、使用する映像は過去に収録した物が多いためBSの表現にヒントを得て開発した物だ(笑
BSドキュメンタ
http://audience.studio-web.net/FxScript/Fx.cgi?mode=dir&dir=87

大体以上のプラグで構成したが最後に出てくる円グラフは先だって試作した物と8点表示機を併用した物だ。
グラフ・プラグイン孝5  試作0号の完成
http://audience.studio-web.net/diarypro/diary.cgi?no=328

円形グラフは、もう一つの四角形グラフと抱き合わせでデリバリーしようと考えているが肝心の四角形グラフの開発が完成していない(爆)

もう一つ別ブログになるがDV(SD)→ハイビジョンサイズのプラグを使ったのが以下。常陸太田市のビデオ研究会会員から提供をいただいたものだ。

DV(SD)→HDV
http://audience.studio-web.net/FxScript/Fx.cgi?mode=dir&dir=47

元々は地デジ時代の移行で4:3サイズのSDやDV等の素材をハイビジョンサイズに使用するためのプラグだが現行NTSCサイズの640*480を1920*1080のハイビジョンサイズにはめ込んでも小さくなるために90%近く大きくし輪郭等で補正したが、まぁYouTubeでは大丈夫だろうと踏んで実験してみた。拙的には問題無しと見た(爆

ちょっとブログの更新が遅れたが徐々に快復(笑)したい。映像ブログや仕事のせいもあるが先月から今月にかけて世界経済が崩壊するのではないかとウォッチングに時間をかけていたせいもあった。現在も問題は解決していないがニュースには現れてきていないので持ち前のデバガメ根性が出て来てしまっている(笑

推論にあやまりがあるかもしれないのでブログに書く事が難しいが機会があれば上程しようと思う。

Panasonic HDC-SD100 1920/24P Trial


以前コラムでは1080/60Pの実験を行ってみたが、そういえば愛機のSD100にも24Pのモードがあったはずと思い出して実験を行ってみた。といっても作業環境はMacであるので中途の作業環境は人によってはワケワカメ状態になるのをお許し頂きたい。

24Pは重宝しているiAモードが使えない。ほぼコントラストの効いた普通のビデオカメラのような画面になってしまう。これはこれでいいのだが現場の撮影をiAを解除したオート撮影すると、流動する輝度の高い対象の影響をもろ受ける撮影仕様になってしまう。二世代近く前の撮影特性になってしまうのだ。

まぁ贅沢もいっていられないので取りあえず庭と近所の桜を24Pで撮って見た。結果は大画面を見ていただけばおわかりと思うが家庭用のカメラとしては ほぼ良好だとおもう(腐ってもプログレッシブなのだ(笑))てか、家庭用のカメラでFLVにした時にこの程度までいければWeb上で映像を使ったコンテンツ提供のモチベーションになる。拙的には感動ものなのである(多分にコスト対効果比があるが(笑))ちなみにどうしても周波数特性が高い絵を選んでしまう人の悪さはさておいて(笑

実験手順は(FCP6が編集環境である)
・SD100の24P仕様で撮影する
・FCP6の切り込みと転送で取り込む(自動的にApple Intermediate Codec)
・シーケンスにならべる(Apple Intermediate Codec設定されている)
・QuickTime (Apple Intermediate Codec)のフル画面で吐き出す
・On2 Flix Proでflv変換(1080P Hi-Definition(VP6-S FLV))フル画面で吐き出す
・YouTubeにアップロードする。

まえのコラムでも述べたが
秘伝 MacでYouTubeアップのコツ(実はWinも(笑))
http://audience.studio-web.net/diarypro/diary.cgi?no=346

秘伝 MacでYouTubeアップのコツ(実はWinも(笑))2
http://audience.studio-web.net/diarypro/diary.cgi?no=347


取り込みから吐き出しまでのプロセスは同一コーディックが基本である。これはDVDを作る時も基本的には同じ考え方で作業をすることを お勧めしたい(経験上ではあるが)この実験の趣旨は24Pで上記のプロセスでYouTubeが認知するかどうかという実験だ。というのも上記の流れでもQuickTime のコンテナにはApple Intermediate Codec以外のコーディックの中には まれにエラーになるものもあるからだ。

最初からこのコツがわかっていればブログサイトの設計をYouTubeを基軸とした作り方をしていたのにという軽い後悔をしている(笑)ただこれだけのことだが使い込んでみないと理解出来ないのである。

次回はTouTubeを使ってみて感じたことを書いてみたい。

秘伝 MacでYouTubeアップのコツ(実はWinも(笑))2


このコラムは秘伝 MacでYouTubeアップのコツ(実はWinも(笑))の続きである。
http://audience.studio-web.net/diarypro/diary.cgi?no=346

さて前回はApple Intermediate Codecでなくても良いと吹いたが(笑)たまたまHDVのデーターがどこかに残っているはずなので探したら出て来た(単純にテープからアップするのがメンドかっただけだ。しかもHC-3で収録したもの)

こんどはHDVコーディックでQuickTimeを吐き出し変換をかけた。HDVの難しい所は原データーが1440*1080なので何もしないと1920*1440のFLVデーターが出来上がってしまう(並に痛い目に逢っているのだ(笑)) そこでレシオを入力ソースに固定しないで1920*1080と強制的にOn2 Flix Proで設定した。変換コーディックは1080P Hi-Definition(VP6-S FLV)である。出来上がったのが下の番地(デモ小画面は上)

札幌の風景の大型YouTube画面
http://www.youtube.com/watch?v=n5BHPJH6eJI&ftm=35

うまくHD画質に変換出来るかと危惧したが問題はないようである。拙は以前のコラムで家庭用カメラは静止フレームを好むと書いた。

家庭用カメラで手ブレ補正競争が熱くなる理由
http://audience.studio-web.net/diarypro/diary.cgi?no=343

実は静止映像はそのコーディックが、どの帯域を重視し、どの帯域を捨ててるか逆に推測しやすくなっている。今回久しぶりにHDVの動画を見たがAVCHDと同じように高い周波数はまずいようだ。メーカーからみれば値段を考えろ、値段を! といわれそうだが(笑

今回感じたのは、拙のようにWebで動画を見せることを指向している人種にとってはもはや最近売られている60〜70Kクラスのカメラで十分でないかという思いだ。むしろ問題は2つある。ひとつは2GDualの非力さと、ナレーションの問題だ。

CPUについては現在4コアのiMacで出て来ているので2年後に更新するならばムーアの法則に従い8コアの時代に突入しているだろうから現在の6倍は早くなる見当なのであせることはない(笑)その予兆として考えられるのは今回ITU-Tで規格もれした1080/60Pを中心とした3D用の家庭用のカメラだ。つまり8コアでは時代遅れなのだ。だから8コアは下にさがってくる(笑)

やはり問題はナレーションだろう。これを書きながら机の上に置いてある巡音ルカのパッケージを恨めしそうに見ている(笑

そろそろボーカロイドの挑戦をはじめるか、どうか、悩む。

秘伝 MacでYouTubeアップのコツ(実はWinも(笑))

グーグル傘下であるYouTube(ユーチューブ)は動画配信サイトとして世界最大手として君臨しているといっても過言ではないだろう。

残念なことに拙とは相性が悪く、いままで何回もアップしては画質等に納得いかず放置していた経緯がある。ところが色々な課題があり徐々に無視するわけにはいかない流れになって来た。時代なのだ(笑

今回は納得するまで張り付いて試行錯誤を行う事にした。カメラはAVCHD、編集のインフラはFCPというのが前提である。

結論を先に言うと信号の流れに逆らってはいけないと言う哲学的な答えで達観した(プロトコルを合わせろということだ)YouTubeの仕様としてアップサイズは 2 GB ということと作品時間の長さは 10 分以下であることが最初の縛りとして存在する。

なんだかんだで最終的に出来上がったのが以下である。

陶芸の里をめざして
http://www.youtube.com/watch?v=YlIA15HNRg4&fmt=35

水戸コミケと全国痛凧連合
http://www.youtube.com/watch?v=DLEWutzcnDc&fmt=35

板谷稲荷神社(常陸太田市東二町)← 結構いい(笑
http://www.youtube.com/watch?v=JJ8baPC1RP8&fmt=35

家庭用のカメラでこの程度はストリーミング再生して欲しかったのが長年の思いだったが、この2年間ことごとく挫折した。そこで考え方を変えてアプローチして出来上がったのが上記である。

以下はYouTubeのアナウンスである。

推奨: 動画の元の解像度 - HD では 1920x1080(1080 p)または1280x720
コーディクはH.264 または MPEG-2 を推奨
推奨コンテナはFLV、MPEG-2、MPEG-4
ビット レートはコーデックに大きく依存するため、推奨値や最小値はありません。動画は、ビット レートではなく、解像度、アスペクト比、フレーム レートで最適化してください。フレーム レートはリサンプリングは行わず、元の動画のフレーム レートを維持するようにしてください。プルダウンなど、フレーム レートをリサンプリングする手法は一切使用しないようにしてください。更に画のフレーム レートはできる限り元の動画と同じにします。現時点で最も高い品質で動画を再生するには、動画を HD の形式でアップロードすることをおすすめします。こうしておくと、YouTube に新しい形式が追加された場合も、それに合わせて動画をアップグレードできます。

などとある。なるほど上記の情報だけでもYouTube のサーバー仕様が見えてくる。昨年100億円でグーグルに買収されたOn2 Technologies社のOn2 VP6方式技術がHDで対応されつつあるなと拙は感じている(ほぼ憶測だが(笑))

H264圧縮フォーマットは現在の動画や動画配信技術の根幹をなすものである。AVCHDのカメラ、ブルーレイ、YouTubeなど裏にはH264が潜んでいる(笑)FCPはAVCHDの家庭用のカメラを取り込む時には自動的に謎のコーデックであるApple Intermediate Codecに変換される。これはWin上では走らない規格でコーディックも公開されていない。どのへんのものかは以前容量比較をしたので参考にして欲しい。

Macで簡単に作るブルーレイ2
http://audience.studio-web.net/diarypro/diary.cgi?no=297

実質的にはProRessと変わらない圧縮量だというのがわかる。そこで編集後にApple Intermediate CodecのままQuickTimeで吐き出した。取り込まれたコーディックそのままで吐き出したのである。陶芸の里をめざしてはこの段階で2.53Gの容量になっていた(3分11秒)そこでOn2 Technologies社のFLV変換ソフトOn2 Flix Proを立ち上げた。これにApple Intermediate CodecのQuickTimeが読めた時は、さすがに興奮した(笑)つまりこれをFLVにすれば元がH264であるのでYouTubeとの親和性が抜群であることが想像されたからだ。(実験はこのように原信号に逆らわずに行うよう心掛けた)

On2 Flix Pro
http://www.flix-j.com/flix/pro/index.html

On2 Flix Proの機能
http://www.flix-j.com/flix/compa/index.html

ここで力技を使った。On2 Flix Proの変換メニューから1080P Hi-Definition(VP6-S FLV)を選び変換をかけた。93.3Mになっている。これをYouTube にあげたのが上記の大型映像だ。動画を HD の形式でアップロードしたわけだ。

アップ後の動画をモニターするとDVの腐ったような画質になり落ち込んだが(笑)変換処理中とアナウンスが出ており数十分で現在の映像まで収斂したという感じを受けた。動画がアップグレードされたわけである(On2 VP6方式と思いたい(笑))

On2 Flix ProはWinの規格もデリバリーされている。Win上の編集でもコーディクを合わせて吐き出せば同じような結果が期待出来ると思う。コーディックは上記のHPで確認して欲しい。ただしカメラはH264系のAVCHDがお薦めと言うことになるが...

2pass変換なので時間がかかった、まぁ寝る前にセットして寝たが4〜5時間はFLV変換に時間がかかったと思う。反面YouTubeに上げる時間は短い。拙の作業環境は以下で
http://audience.studio-web.net/diarypro/diary.cgi?no=345

願わくば映像ブログ等で頑張っている方に このコラムが参考になって欲しい。ただし例によって実験は自己責任で行っており効果を保証するものではないが(笑)今回見えて来たのは上記の過程でも10分物で300M程度の容量でクリアー出来るという事だ。さらにサーバー内で動画質改善のアップロードが作動している事を確認できた。

とどのつまり、このアプローチでは2Gの容量はオーバースペックと言う事になる。多分、作品時間10分が30分になるのも上記のアップ条件なら可能だろう。

まぁネットで5分以上の物を作ってどうするのという思いはあるが(爆
ちなみに今のグーグルの考え方ではOn2 Flix Proはタダになる可能性がある。と拙は読んでいるのだが どうなることやらw

大型画面になる事で不利もある。安い中国製のワイドレンズは周辺のディストーション(歪み)がキツくなって使えないとか、マメに関係者以外の顔をマスク(ぼかし)しなければならないとかである(マスクは全面的にMask onMosaic2に頼っている)ただ大型画面は迫力はやはりある。悩みどころなのだ(笑

ただし、ここまでいければ貼付けコードを使うサイトの構想が色々浮かぶ、動画サーバーとしてYouTubeを利用すると言う柔軟性が生きてくる訳だ。この画質だったらこれは美味しい、美味しすぎると思うのは拙だけか(爆

56Kの接続スピード時代から動画配信の実験をやって来た拙にとっては 現在はあたりまえというには程遠い。そうまるで魔法のような時代に感じる時がある。

秘伝 MacでYouTubeアップのコツ(実はWinも(笑))2←HDVに挑戦
http://audience.studio-web.net/diarypro/diary.cgi?no=347

TM700の1080/60PをMacで編集してみた



最近発売されたパナソニックの家庭用カメラTM700の評判は思ったよりいいようである。ビデオサロンの4月号発売前に静止画の比較をアップしているようだが編集部も驚いたと記述されている。(100万円以下のカメラで水面がここまで再現されているカメラは初めてかもしれない等と書いてある)
http://www.genkosha.com/vs/report/entry/tm700108060p.html

2チャンネルでも板が立ち上がっており、ぼちぼち撮影データーが公開されはじめたので処理してみた。最初に結論を述べると解像度は確かにいい。いわゆる「できる」という言葉がふさわしい、家庭用のカメラもついにここまで来たかという感慨がある。だが「使える」というインフラはまだまだ乏しい。できると使えるとは違うのだ(笑

拙的な表現を許してもらえるならば、現状は鰻屋の店先で鰻(うなぎ)の匂いを嗅いでいる切ない状況なのだ(爆)そこでこの実験ではPをiのQuickTimeに変換し編集するアプローチしかしていない。

さてデーターは2ちゃんで公開された善光寺の8秒弱のデーターを使用させていただいた。(使用のプロセスが著作権上問題があるかもしれないので、もし抗議をうけたら即、動画は削除します)
http://gimpo.2ch.net/test/read.cgi/vcamera/1265951401/

データーはm2ts方式でFCPで直接読み込もうにも受け付けない
作業環境はiMac
OS 10.5.8
2GHz Intel Core 2 Duo メモリーは2G
FCPは6.0.6である。
(現在FCPは1080/60Pのコーデックは存在しない)

これではしかたがないのでMacでWindowXPを立ち上げた(拙の環境はVMware)Win上でTMPGEnc 4.0 XPRESS(4.5.2.255)を立ち上げ読み込んだら1920*1080 59.94fpsと認識する。(ちなみに1080/60Pの圧縮方式は独自と言うのみでPanaは公開していない)

そこでQuickTimeは2つのコーデックで出力してみた、フォトJPGとH264である(というかTMPGEncには現実的にこの2つしか選択肢はない、まぁ非圧縮と圧縮の比較ができるだろう的な実験しかできない)

そして2つのデーターをFCPに取り込みFLV(接続スピード700K)にしたのが上記の映像である。FCPのシーケンスはコーデックが混在しても受け付けるが最初に選んだクリップのコーディクが優先される。ただ、拙の場合はAVCHDの素材を編集する時は、これも仕様が定かではないApple Intermediate Codecを使用しているのでレンダリングし直した(おまじないみたいなものである、というか何故使うかという理由は相当長くなるので省略(笑))

データー容量と変換時間

元データー(8秒弱) 21.8M
H264への変換時間 5分40秒前後 容量 304.2M
フォトJPGへの変換時間 6分30秒前後 容量 859.9M
(読み込みも書き込みも同一HDを使用しているのでHDが別だったら変換時間は1/2の時間になる可能性がある)
ちなみにFLV(384*215)の大きさは1.7M(笑

2つのデーターを並べた(16秒弱)FCPのApple Intermediate Codecの変換時間は2〜3分程度でシーケンスは1920*1080i HDTVと認識している(厳密に言うとこのiが問題なのかもしれないが(笑)最初に記述したようにこのようなアプローチしかできなかった)

シーケンス上の映像を見る限りはフォトJPGの色に深みがあるように感じられたが、データー量が違うと再現性が異なるということだろう。

FCPを使用されている方は上記の容量と変換時間で作業環境を推察することが可能だと思う。本格的に使うには4coreとメモリーがもっと必要であるということだ。用途的にWebでの発表を384*215サイズで行っている拙にはこれだけの革命的な変化もさほど影響をうけないが(笑)、もっと大きなサイズで勝負している方には影響が甚大だと思われる。

特にブルーレイなどの納品をAVCHDの業務用機で作成されている方は足元をすくわれかねないポテンシャルがあると見ている(インフラが整えばの話だが)俺の画像の方がイイゼェ等と言われたら疲れるかも(爆

現段階は鰻の匂い程度で話をすましているが何と言うか凄いことになってきたなぁと思う(笑)なにかしら4coreのiMacを意識し出した(爆

SD100(νmaicoviconの挑戦は終わったのか?) 1
http://audience.studio-web.net/diarypro/diary.cgi?no=336

SD100(フォーカスや手ブレ補正の仕様) 2
http://audience.studio-web.net/diarypro/diary.cgi?no=337

SD100(TM700の発表) 3
http://audience.studio-web.net/diarypro/diary.cgi?no=338

SD100(TM700にみる現在のカメラシステム・デザイン) 4
http://audience.studio-web.net/diarypro/diary.cgi?no=339

家庭用カメラで手ブレ補正競争が熱くなる理由
http://audience.studio-web.net/diarypro/diary.cgi?no=343

3D再生装置の跳梁
http://audience.studio-web.net/diarypro/diary.cgi?no=341

秘伝 MacでYouTubeアップのコツ(実はWinも(笑))
http://audience.studio-web.net/diarypro/diary.cgi?no=346

秘伝 MacでYouTubeアップのコツ(実はWinも(笑))2
http://audience.studio-web.net/diarypro/diary.cgi?no=347