金曜ロードショーとか土曜プレミアムと裏番組の組合せ、あるいはスポーツ中継の放送延長でずれた深夜番組と裏番組の両方を録画したい、という人にお薦めの逸品。
関連記事
外部リンク
aviutl用のインタレース維持リサイズ フィルタ @ がらくたハウスのがらくた置き場 の、アプコン動画から元の縦解像度に変換する能力は非常に高い。
がらくた置き場のサンプルよりもさらにはっきりと再現性の高さが分かるサンプルを作ってみた。画像はマクロスフロンティア第6話「バイバイ・シェリル」より引用。
今回のエンコのターゲットは、アニメ「ルパン三世 sweet lost night~魔法のランプは悪夢の予感~」(2008-07-25 AX系で放送)。
あちこちに出てくる回想シーンが、砂嵐状ノイズ(しかも色付き)によるエフェクトなのでいつもの品質指定では潰れてしまう。 CRF (Constant Rate Factor)のパラメータを小さくすれば潰れを抑えられるが、回想シーン以外で過剰なビットレートになってしまうので、必要なカットの範囲だけパラメータを変更したい。 こんなときはzoneオプションを使うようだ。 zoneの範囲はフレーム番号で指定することになっている。
--crf=21 --zones 935,1138,q=10/5542,5589,q=10
のように書けば、フレーム番号(0開始)で935〜1138の範囲と、5542〜5589の範囲のCRFを10に、その他の範囲のCRFを21にできる。
今回、Aviutlで24fps化(テレシネ解除)したが、Aviutlでは24fps化後の正確なフレーム番号を知る術が無いので、Aviutlの作業ファイル(aup)を読み込むAvisynth script(avs)を作って、VirtualDubModでこのavsファイルを読んで回想シーンのフレーム番号を確認した。
以下、ノイズを効果として含む映像の場合のCRFと画質、ビットレートの関係についての考察。
ソニーPCLに聞く「国内向けBDオーサリング」の現状 @ 西田宗千佳のRandomTrackingの画面写真によると、BD(Blu-lay)のH.264(MPEG4 AVC)エンコは2pass VBRのようだ。
Quad core×5台でおおよそリアルタイムでエンコード
とのこと。シングルスレッドだったら実時間の20倍くらいかかる計算になる。30分のアニメだと10時間(実際には30分より短いのでもう少し少ない)。個人でやるのに比べて10倍も違わないのが意外。ただ、
エンコードした映像をモニターでチェックして、圧縮ノイズなどで破綻している部分をみつけ、前後の状態を勘案しながらビットレートを調整、再びエンコードを行なって、出来る限り美しい映像に仕上げる
そうなので、ここの手間は売れ筋の作品とそうでないものとで差がついていそう。
伝統的に、キャラクターの顔や特定のポーズなど、絶対にノイズを出してはならないとされる部分も多いので、気を遣いますね
テレビ局で流すやつは、完全自動のリアルタイムエンコだから「重要なカット」を人が認識して匙加減をするDVD/BDとは大違いの画になることがある。アナログキャプチャ&エンコは自分で重要なカットの調整ができるけど、デジタル放送のストリームキャプチャだと、最初から酷いブロックノイズが乗ってたりして哀しかったりしそう。
あと、暗部のもやもやに関して参考になる情報も。
液晶テレビは、バックライトを立てることで、黒が黒ではなく、浮いた黒に見えます。それに従い、ブラウン管では黒に沈んで見えなくなるはずのノイズが、液晶テレビでは見えてしまいます。
「黒浮き」ってやつですね。確かに、時間方向のノイズ低減をしてなかった頃のファイルを始めて液晶モニタで見た時に、恐ろしくザワザワしていて驚いたものだ。プロの世界でのチューニングのセオリーを知りたい!
あに瓶さんの「縞縞アプコンをきれいにして観よう」でアプコンの原理(?)に基づいて縞を解除するAviSynth用スクリプトが公開されていた。
さっそく試してみる。
……う~ん、おかしいな……
aviutlのインタレ保持リサイズと同じで縞が消えてくれない……。
YC分離の残像の方でなく、確かにアプコン由来の縞なんだけど。
自作aviutl用フィルタはアプコン縞のできる過程なんて無視してるので、 輪郭線にジャギーが残ってしまうことがある。 あに瓶さんのResizeIntrを参考にして作り直そうと期待していたのだが、 残念な結果に。さて困った。 もしかして手持ちの動画がおかしいのか?
24pの動画をきちんとテレシネ解除しても残像のように横線が残る現象。 例えば、あに瓶さんで模擬画像が掲載されている、こんな感じ。
AVIUTLにインタレ保持したまま縦方向にリサイズできるプラグインがあるのだけれど、これが結構調整が難しいようで、なかなか上から下まで縞の無い状態を作り出すことができなかった。また、アプコン動画にはコンポジットで納品されたものを放送局でYC分離しているものが相当数あるようで、YC分離の際に盛大にクロスカラーが乗ったり、前のシーンの残像が生じたりする。この点に関しては、まっとうなYC分離機能を持ったアナログ機器を通した画の方がデジタル放送データの画よりも高品質に見える(解像度やS/Nでは劣るが)。
クロスカラー除去は既存のプラグインがあるとして、
不可逆的に失敗したYC分離の残像とアプコン縞の低減をしたいけれども
良い方法が無い。
仕方がないので、自分で適当なプラグインを作ったところ、
結構それらしい画を作れたので置いておく。
アプコン解除プラグイン Lv.1 Exp.1 for Aviutl
無保証。配布自由。
関連記事
以下、やっていることの解説。
H.264動画では、暗部や青色部分のブロック感(もやもやざわざわ動いている感じ)が気になるというのは、昔から知られていて、
x264 HAQ (Haali Adaptive Quantization parameter)のような対策が打ち出されているわけですが、そもそもどうしてざわざわしてしまうのでしょう。実はQPを変えるだけでは対策になってないかもしれない、そう思っていろいろ調べてみました。
そのものずばりの情報は得られなかったので、とりあえず推測を幾つか挙げてみます。
VAQ (Variance-based Adaptive QP) の趣旨は「のっぺりしたところからビットレートを取り上げてファイルサイズを減らしましょう」で、 HAQ (Haali Adaptive QP)は「(x264の尺度で)同じ平坦に見えても、暗い部分はブロックが目立つので、逆にビットレートを割きましょう」と、実は 目的がかなり違う。
VAQでもHAQでも問題になっているのは、
QPを調整する対象ブロックを選ぶ尺度が、まだ人間の感覚と一致していないこと。暗部のブロック感を抑えようとするとQP調整の対象を広げることになって、全体を低いQPでエンコするのと変わらなくなったりする。
⇒ seraphy氏による詳しい解説
そこでseraphy氏は、QPの調整対象を自己流の尺度で選ぶようにした「OreAQ」を開発。
⇒ ここの「x264OreAQ.***.release**.rar」がコンパイル済の実行ファイル。
Charlieも早速使ってみた。
x264 Core56 Sharktooth版でエンコードした結果のファイルとCore58 Dark Shikari版のファイルとをmkvmergeで結合したところ、後ろに結合したDark Shikari版の部分の表示がおかしくなった (MPC + CoreAVC or ffdshow)。
パンする部分で16x16ブロックくらいの大きさでところどころ位置が数ドットずれる。 結合前のファイルでは症状が再現しないので、再生に必要なパラメータに互換性がなかったのだろう。結合するなら、エンコーダのビルドは一つに固定しておくのが無難だろう。
関連記事