【エンコードレシピ】夕澄の720ｐ（AVC）

↓4)改稿.2019/05/17...20190516...

＞　‥夕澄（せきちょう）とは
＞　とくにデジタルアニメの再エンコードにおいて、唯一悩ましいのが
＞　夕日射すド派手な色の再現性である


※　LW48の扱いについて見直しました →（没）


　‥立派にエンコードをしたはずなのにどうしてか色が出ていない
　BD-ts（マスターデータからのエンコード）と差ほど変わらないだろう数値設定のはずなのに
　なぜか、BD-tsの方が圧倒的に色艶が好かったりする
　再エンコードとはそういうものかなと思い込まざるを得ない


　動画エンコードの試行錯誤とは、そのようなところから始まるわけだが


　‥よくよく考えてみるに
　アニメのマスターデータとは、量子化されていない状態を指している
　それに比べるとBD-tsの中身とは、すでにぎっちぎちに量子化された状態だ

　量子化された状態を、さらに同じ程度の動きサーチで
　且つ少ないビットレート量で再量子化しようとすれば
　そこからさらに色が削がれる結果になる


＞　しかし、マスターデータからBD-tsへの置き換えは、そんなにもトーンダウンするものなのか？
＞　その程度の技術なのだろうか？


　‥その程度だとしたら、BD-tsにしたって、その範疇にあると言わざるを得ない
　でも、そこまでの酷評は存在しないのだ（BD化スタート当時は不慣れから多少あったらしい）

　ならば、BD-tsからだって差ほど変わらない程度にはなるはずだ
　例えば、同じ程度のビットレート量を宛がって、そうならない（できない）のでは矛盾すぎる

　そりゃまぁ、ソースとするデータの状態が違うのだから同じ設定のままに上手く行くはずもない
　それなりに差を考慮して、再エンコードをする必要はある


　‥その基準として
　放送映像のサイズ変更をしているテレビの画面サイズの違い程度の範囲に留まれば納得だろう
　しかし、なぜかそれがなかなかどうして‥難しいと来たもんだった

（コピー防止云々のマインドもちらつくことから、不可能とすら思い込まれて来た）


＞　しかし、それで技術と言えるのだろうか？
＞　それで、技術としてその先が拓くと思っているのだろうか？


　‥とにかくその中でも、ド派手な夕日射す光の表現はどうにもトーンダウンしてしまうのだ
　そりゃまぁ他が同程度にぼかされていれば、バランスまでが崩れてしまうほどではない
　しかし、BD-tsに見られるド派手な色艶は失われてしまうのだ

　同程度にぼかすことは成り立っているのに、どうして色のトーンを維持できないのか？？
（720ｐでそれができないのなら、1080ｐのそれだってその程度だろう）

　‥息巻いてデジタル放送を始めたんだからな
　そりゃ１ｋテレビだからって綺麗に映ってなんぼだし
　大画面との質が大きく異なることを真顔で通す程度の技術力でもない


（でもなぜか、テレビ自体の設定の差が曖昧にあることからして、見られたもんじゃなかったりする）
（そもそも、テレビ設定から具体的に突き詰めないなら、再エンコードの意味からして大幅減である）
（当方の推奨設定はこちらとこちらになってます）


　‥ならば、道はあって当然だ
　‥その道に辿り着いたのが今回のレシピと言うことになってま〜す

　（ただし、誠に残念ながら、AviUtlからの設定です）
　（XMedia Recodeしか扱えない方には、ハードルが高くなってます）
　（とくにAviUtlの課題として、16ビット音声までしか扱えないローカル制限付きっす）
　（映像は出せたとしても、そこからの調整が、もどかしく一手間だったりします）

1-4)1

＞　‥先ずは、AviUtlからの設定です
＞　ツールウィンドウで触るのは、ここではほぼ画面サイズだけです




　‥16：9と4：3の変更や、1080ｐへの変更をします
　‥あとはいじらなくても良いと思いますが
　インターレス映像には注意が必要です

　インターレスの中でも、とくに動きの速い格子の情報だけに対してインターレス処理を施す
　なんて技術も有るようでして、AviUtlがそれに対応しているかなどまるで分かりません


＞　次にシステムの設定項目です




　‥ここでのオススメは、キャッシュフレーム数（80）です
　実写（60），アニメ（80）
　動きサーチに絡んだ先を読ませる枚数をAviUtlの方でも先にやっちまおう作戦です
　そちらの方が効率が良いように思うところですが
　AviUtlの扱えるメモリー量に制限が絡むので、自分のメモリーと相談してください

　AviUtlの使用するメモリー量を2GBから4GBに増やすには
　「LargeAddressAwareを有効にする」にチェックが必要です


　‥出力時のファイル書き込み単位が4MBになっていますが、デフォルトです

　書き込み用のドライブが断片化してようと空きのある先から、情報を書き込む傾向です
　それを中途計算用の一時フォルダとドライブを同じにしてある場合
　書き込みが間に合わないタイミングでも、書き込み終了を待たずに処理を進めちまうようでして
　有り得ないとは思うのですが、最近、断片化が進んだ状態で余裕こいて
　ドライブ同じままでエンコードしていたら
　格子欠けが部分的に発生するようになりまして、訝しげ状態になってます

　‥こげな事案が発生するなら
　ハード丸投げ依存しないガッツリエミュレーションタイミングであるメモリーディスクこそが
　最強だろうと思うようになりました

　‥それでもまぁメモリーディスクでも何が起きるかはわからないので

　書き込みドライブ　＞　一時フォルダのドライブ　＞　読み込みドライブ

　の順に使用するドライブのスピード感を推し量って宛がっておくのが対策かなと‥
（まぁそこまでしないとダメなんて、それはプログラムにバグが有るとしか思えない）


※　「フレーム番号の表示を1からにする」にチェックを入れると
　　キーフレーム指定位置受け渡し時に
　　ｘ246が対応せずにそのまま全部一つずれてしまいます

　　バグと思うか‥対応仕様と思うかは、AviUtlの敷居の高さになると思います

　　‥ちなみに、キーフレーム指定は
　　テキストに上から順に半角数値を一つずつ改行して書きだしておけば
　　あとは、インポートするだけです
　　編集画面上からは、位置出し×一つずつしか指定できないちまちま機能なので
　　テキストにリスト出しした方が、やり直しするときにイライラしません

1-4)2

＞　では、読み込ませるファイルサイズの確認です




　‥プラグインの「WaveFileReader」にサイズの指定を渡すわけですが
　この指定をど忘れしていても、正確さ云々抜きにさしたるエラーを発生させません

　又、指定し直した場合には、AviUtlの作りからもAviUtlを再起動しておくのが無難です

　‥とはいえ
　あまりにも、ど忘れしがちの危うさが伴うことから
　AviUtlを読み込ませたい画面サイズ別の種類分の起動フォルダー振り分けを用意して
　起動させるAviUtlを使い分けるのが無難です

　（まぁその分、プラグインの更新をそれぞれにしないと成らないわけですが）
　（ど忘れしていた場合の精神的な負荷よりは、手間は小さいでしょう）

1-4)3

＞　L-SWASH Works File Reder settingsの項目です




　‥デフォルトから注目するのは
　「Video scaler」と「Dummy colorspace」と「AVS bit-depth」です


※　LW48についてすっかり見落としていたのですが
　　ググってもまったく以て情報が出て来ないどころか、あっても上手く行かず
　　それどころか、自分の稚拙な過去記事がヒットしていたりで、こっぱずかしいわけですが‥

　　‥改めて出して確認したところ

　　無難にＲＧＢ８ビット指定の方が、動きに無理がでないということになりました
　　各種データ数値は同じなんですが、例によって、エンコード出し時の平均fpsみたいな奴だけが変化します


　「Dummy resolution」は、フォルダー分けするときに一緒に整えておきます

　「Dummy framaerate」は、以前は反応していたのですが、今は反応がありません
　なので、AviUtlの読み込みデフォルトは「23.976」ですが、それ以外の場合には
　ファイルを読み込ませる際に、フレームレートの指定が欠かせない状態です

1-4)4

＞　ということで、ようやくL-SWASHのｘ246の項目です
＞　たまにはバージョンの確認をしましょう




　最初のｘ246で区切られた項目ですが
　ここで触るとしたら、「CRF」と「LEVEL」ぐらいでしょう
（基本的に、L-SWASHでの10ビット出しはオススメしないのがお約束にあるようです）


　‥ここでの品質：crf（11）は、デジタルアニメのBD-tsに合わせた数値になっています
　実写の場合は、あれこれ関係なく増量が半端ないので、概ねcrf（15）が想定です
　グレードの高いソースであればあるほど、色の鮮やかさをそのままに「夕澄」します

　（無論、４ｋソース動画までを対象にして語ってはおりません）


　‥当方のここでの方針は、720ｐの可能性の追求です
　なのでＤＶＤからの使い勝手を狙ったアップコンバート
　ＦＨＤサイズからのダウンコンバートが主体です

　アニメのＤＶＤは、年代別でその中身の造りが異なっています

　撮影の絡んでいた時代のモノは、実写と同じ要素が絡むのでcrf（15）が想定です
　ただし、HDリマスター化されてBD映像に至っているソースの場合
　crf（11）でも対応するようですが、再圧縮率はことのほか及ばないケースが多いでしょう

　一方、撮影の絡まないデジタル制作の段階作品の場合には、crf（13）が想定です
　DVDということで、BDよりは品質が下がるということです


　‥BDからリップしたソースの再エンコードの場合は
　（11）から0.5刻みで品質を下げて具合を確認することになります
　その場合でも、ソースの縦横サイズの違いよりは、ソース自体の品質の勘案の方が大きいです


＞　レート・QP制御の項目です




　‥ここで触るとしたら、「レート制御先行探査フレーム数」です
　実写（60）、アニメ（80）が当方の見解です
　（ただしHEVCでは効果が見られません、アルゴリズムが根本的に違うようです）


＞　フレームの項目です




　‥ここでは参照距離（2），Ｂフレーム（1）になっていますが
　三コマアニメの場合には、参照距離（4），Ｂフレーム（2）が適当でしょう

　‥実写とアニメの差としては
　シーンカット閾値：実写（67），アニメ（89）
　キーフレームの閾値の上限：実写（60），アニメ（80）
　が当方の見解です。
　（ただしHEVCでは効果が見られません、アルゴリズムが根本的に違うようです）


　※　参照距離と最大連続Ｂフレーム数をいじって、どこまで「夕澄」を維持できるかは不明です

　‥「夕澄」を維持する鍵は
　動き予測アルゴリズムのLEVELと、レート・QP制御にある
　「I-Pフレーム間係数（％）」と「P-Bフレーム間係数（％）」が大きく左右します
　しかしここの値の変動は、Ｂフレームを連続させた圧縮効率に影響を与えます
　他には、Ｉフレームの平均ＱＰ値がＰフレームの平均ＱＰ値を下回ったりの変化をもたらします

　（エンコード技術者からしても、あまり触りたくない部分だったということでしょう）


　‥先に、同じ内容を示してありますが
　基準値では「夕澄」たる鮮やかさには、ほど遠いのが再エンコード時の悩ましさになっています

　（裏を返せば、BD規格に収めるためのギチギチが1.40と1.30だったと言うことかも知れません）


＞　拡張の項目です




※　ということで、LW48を外しております
　　一部には、エンコード時間が微差で減ると書かれていたりしますが‥外すと
　　Exhaustive Searchを使用する影響は拭えないのか‥2000コマ程度で20〜30秒程度の手間が増える傾向です

　　‥その点、誤差が減るとした表記は、なんとも言えません
　　16ビット深度などと欲張ったことをしていたので、無理が減った感じはしますが
　　16ビット深度分の複雑さが正しくあったなら、時間は減ると思うのですが不明です

　　そもそも制作者自身が詳細に語っていないという時点で、次点の空気なのでしょう　
　

1-4)4

＞　で、再圧縮率は如何ほどになるのかというのが気になると思いますが
＞　それは、再エンコードするソース次第です
＞　期待外れも起きるし、ラッキーも起きるというまばらです


　ただし、DVDファイル並の倍速表示が可能になるので、とりあえず出してみての損はありません
　でも、Exhaustive Searchを使用するので、掛かる時間は大きいです