2014年03月03日

10bit4:2:2の素材を編集してVimeoに投稿する方法(win) その1

最初にコーデックの勉強と最近のムービーカメラの記録コーデックのトレンドなどについて。

映像ファイルにおける画質の高低を表すパラメータとして一番わかりやすいのは、解像度、ビットレートだろう。
解像度は映像の荒さと関係するので高ければ高いほど良いのはわかりやすい。(ただし視聴画面と距離において限度(Retina)があるけど)
ビットレートももちろん高ければ高いほどきれい。圧縮ノイズも減っていく。
ただし、低ビットレートでも何の破綻もなくきれいに表現できている絵もあれば、高ビットレートでも埋められない領域もある。
ビットレートだけでは測れない画質を決めるパラメータのうちのいくつかについて説明しておく。

位置情報色深度
ある色相(例えば「赤」)の明度・彩度の高低を表すのに、どれだけ間を刻むかというグラデーションのなめらかさに関するパラメータ
今のカメラで撮影できる素材では、8bit〜14bit程度まである。bit数が高いほどグラデーションがなめらかである。
よく空や子供の肌などなめらかなグラデーションの部分にうっすらと等高線のような色差がみられる現象があるが、あれはバンディングといって、この色深度と密接なかかわりがある。

位置情報色情報の間引き方法
RGB→YUVの4:4:4→4:2:2(YUY2)→4:2:0(YV12)とか。
めちゃくちゃ簡単に言うと、前者が一番画像を構成する色の粒が細かい。つまり、エッジがなめらかになる。
後者は複数の粒を使って塊で色を表現するその塊の単位が大きくなっていくため、エッジがあらくなっていく。
→ただし、これは4K、2KHD、SD等の解像度とも密接な関係がある。解像度が高ければ、適切な視聴距離では実質の粒が小さくなっていき、エッジの荒さは目立たなくなる。

参考文献はこちらの記事
http://daigouji-gai.tripod.com/documents/document07.html
http://www.boktv.x0.com/bokblog/2007/03/post_6.html

位置情報フレーム間圧縮の有無と程度(GOPサイズ)
ALL-I(イントラフレーム):全て独立して切り出せる1枚絵。
P、Bを使用したIPB方式:前(後)の絵(参照元=I)からの差分記録(または予測生成)方式。複数のフレームからの合成としてデコードされる
ALL-Iの方が動きが激しい場合でも1枚1枚はきれいな絵で撮れ、結果的には動的な場面でも精細な画質となる。P、Bは合成により実際にはない情報を「補間」したり、あるいは予測から外れた情報をとらえきれなかったりするため、動きが激しい場合には不利となる。
※ただし、これもビットレートとのバランスが大きく、ALL-Iはビットレートを大きく取れないと、1枚1枚のIフレームの絵の圧縮率が上がってしまい、結果的にブロックノイズが発生したりして破たんする。この点、IPBでビットレートに余裕をもって割り振れるため、参照元のIフレームの画質は相対的にはALL-Iより高く、これに基づいてPBを生成するため、特に動きが少ない場合にはきれいに見える。
※ちなみに私がお世話になっているGH2ハッカーのbkmcwdさんが得意とするのは3GOP(IBBIBBIBB…)などのショートGOPだ。Iのファイルサイズとビットレートのバランスがよく、私はGH2のALL-Iよりもずっときれいだと思う。

一方世の中の話をしよう。
私たちが目にする視聴媒体における配信ファイルのコーデックを最終形態とすると、今の主流は8bit4:2:0だ。
TVの電波にのってきているのは、大半がMPEGかH264.
MPEGやH264は規格では8bit420までと定められている。
インターネットでもYoutube、Vimeo等の動画サイトで広く配信されているデータはH264が主流で、圧縮に8bit420を用いている。

では、その映像を作る過程でのカメラからの映像キャプチャの段階ではどうか。
カメラの歴史はフィルムから始まった。フィルムは色深度、粒の大きさともに非常によく、なめらかで豊かな階調表現ができた。(らしい)
これをデジタル化する際に、まったく圧縮をしないのがRGBであるが、これではファイルサイズが大きくなりすぎて実質扱えないことから
いかにこれを圧縮するか、というのがデジタルカメラの記録コーデックの進化の命題となってきた。
画質とファイルサイズとそれを記録するメディアとのバランスで、そのカメラの商品の価格帯、顧客層が決まる。
映像の制作側としては、最終形態で大きく色情報を削って圧縮することになるので、それまではなるべく豊富な情報を残したファイル形式で編集することが望ましいことは言うまでもない。
かといって、何かするたびにつどストレージを入れ替えたりしなければいけないような非現実なファイルサイズでも困るわけだ。

いわゆるエントリーレベル、アマチュア機のビデオ記録だと、Cameraからの出力=最終視聴形態で、これは今の主流はH264の8bit420だ。
少し前はビットレートが低いMotionJPEGなどで記録するDSLRもあったが、今はほとんどH264ではないだろうか。
ビデオカメラやPanasonic、SonyなどはAVCHDのm2ts、他動画対応DSRLだとMP4、QuicktimeのMOVなど。

そして、プロ向けの最たるものがRAW記録。圧縮なし(またはロスレス圧縮)で記録する。
ただしこれにはCamera内収録は無理でいろいろ線やSSD等の機器をつないで外部記録をしなければいけなかったり、それがプロ機たるゆえんだ。

今面白いのは、いわゆるプロシューマ−(プロの中でも低コストな小規模なところ、あるいはアマチュアだがより高性能な機材を求める層)向けの製品であり、ファイルコーデック一つとってもさまざまなレンジがある。
その中で今注目なのが、アマチュア〜プロシューマ機の価格帯で購入できるBlackMagic社のレンズ交換式ムービーカメラ製品だ。
4K、2K、HDというラインナップがあり、特徴はProres422HQ及びRAW記録が可能なことだ。(しかも驚くべきことに、一番安い10万円のBlackMagic Pocket Cinema Cameraでは、内部のSD記録で、である。手のひらに乗る小さな箱体一つに、膨大な情報を記録できるの!)

Prores422HQとは、10bit4:2:2のALL-Iで記録できるAppleのFinalCut専用のコーデックであり、MACの世界(=画像処理・映像制作の本場)では広く流通している。
もともと中間ファイル用として開発されておりそれ自体が再編集も可能なほどの画質を備えているので、プロの世界での最終納品形態としてこれを指定される場合も多い。
TVでの視聴はできないが、最近の高スペックPCなら十分再生できる。

ここから本題。
わたくしごとだが、めでたくBMPCCを購入し、長らくお世話になったGH2の8bit420の世界からProres422HQの10bit422収録へとグレードアップした。
これにより何が変わるか?
Vimeoへのアップロード方式を変えることができるのだ。
現状は8bit420の素材を8bit420のH264で出力して出すことしかできなかったけれど、10bit422の素材は10bit422のまま編集して出したい
VimeoならProres422のMOVをアップロードでき、しかもwinでもMACでもダウンロードして10bit422の元素材を見てもらうことができるようになる。
(もちろんネット上での再生データは今まで通り8bit420だけどね)

ただし・・・アマチュアシネマトグラファーの端くれを目指すものとして、撮って出しの素材のみ投稿、というシチュエーションはほとんどない。機材フェチじゃないし、編集して作品として世に出したいという思いがある。
これに対し、Prores422HQというのは、基本FinalCut用のコーデックのため、ライセンスの問題があり、Windowsでのほとんどのソフト(Adobe製含む)はこの形態での書き出しができない。がーん。
しかしネット情報によるとwinではffmpeg等でファイル変換のみは可能なようだ。
まず中間コーデックで出してからさらにffmpegにかける必要があるのか〜うーん・・・。

ちなみに、映像制作に携わるプロ(やアマチュア)の間でWin使いの人はおそらく大歓迎で受け止めて使っているであろうデコードエンコード無料配布のファイルコーデックが、国産メーカーCanopusによるHQX-AVIだ。
10bit4:2:2のALL-I記録でありながら、ファイルサイズはProres422Proxy(一番下位の高圧縮タイプ)よりも小さく、かつ画質はむしろ勝っているように感じる。
さて、このHQX-AVIは中間コーデックとして10bit4:2:0のままもっていくことができるのだ。その受け渡し先は先述したffmpegであったり、x264(H264高画質変換用フリープログラム)であったり、またはwinの別のNLEソフトであったり、さまざまだ。
これが広く流通してくれればいいんだけど、DavinciやSpeedgrade等のグレーディングソフト、あるいはAnotherGUIなんかではこの形式の読み込み、書き出しができないようで。
VimeoやYoutubeでも直接これをUploadしようとしてもはねられる。
このHQXのファイルサイズと画質を考えると、中間コーデックとしてだけでなくむしろHQXを最終納品形態としてもいいくらいだ。ファイルサイズ小さいし。
しかし、MACで扱えないためマカーにおけるProres422神話に比べるとまだまだインパクトが弱く、、なかなかメジャーにならないのだろう。

さて、では、win使いにとっては、10bit420でVimeoに上げる方法は、NLE→HQX→Proress422と、無駄に1回エンコードを増やさなくてはいけないのか?
というときに、ある裏技を思いついた。
Avisynthを使えばAnotherGUIにHQXを読み込んで変換することができるのだ。
では、このavsスクリプトでもってffmpegの-vcodec copyオプションを聞かせて、MOVコンテナに再エンコなしで入れて、このMOV入りのHQXをVimeoに読ませることができるんじゃないの?と。

結果から言うと、一応できたっぽい
次のエントリーに続く。

→うーんたらーっ(汗)あせあせ(飛び散る汗)
できたと思ったんだけど、厳密に言うと再エンコなしでっていうんじゃなくて、「変換」自体はされてそう。
詳細は次のエントリーで。
posted by そよはっは at 22:36| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント:

×

この広告は1年以上新しい記事の投稿がないブログに表示されております。