【エンコード日記】ＨＥＶＣはインタレース操作非対応らしい件

記稿.2019/12/06

＞　XMedia RecodeのHEVCでインターレース解除を試みた
＞　エラー吐いて止まった、何度やっても同じである


＞　しょうがないので、解除したソースをプログレッシブでエンコードしてみた
＞　プログレッシブ表記になっておりません


　つまり、非対応くさっ
　まぁHEVCの対象が、４ｋ８ｋだから
　４ｋ８ｋはインタレース非対応でーす（もはやそういう規格っす）

　まぁそういう事のようです


＞　で、XMedia RecodeのHEVCなんですが


　設定記録ファイルを読み込んで再エンコードした結果と
　手動で直々に数値変更した再エンコードの結果が異なります

　項目が多いので全部は目を通していませんが
　GOPのＮとＭとブロッキング軽減が全然ちげえー

　知らないと全然違う結果のままっすから（どうしてこうなったん？）

【エンコード日記】HEVCとAVCにおけるGOPの差

↓2)改稿.2019/11/06...20191105...

＞　まず先に結果からざっくりと申し上げます


　‥以前のマシンスペックでは踏み込めずにいたサーチ距離について変更になりました

　キーフレーム間隔：６０（実写），８０（アニメ）
　先読み：６０（実写），８０（アニメ）
　Syne Lockahead：６０（実写），８０（アニメ）
　シーン変更感度：６７（実写），８９（アニメ）

　↓

　キーフレーム間隔：...１２０...画像が荒れるようなので見直し中
　先読み：...１２０...画像が荒れるようなので見直し中
　Syne Lockahead：...１２０...画像が荒れるようなので見直し中
　シーン変更感度：８９

　（今更の所、実に申し訳ない‥m(_ _)m‥すまん）

　‥見直し中になりました（度々‥m(_ _)m‥すまん）‥

　↓

　フレームレート：２３.976　／　２９.97
　キーフレーム間隔：７２　／　９０（フレームレートに対して３秒値）
　先読み：７２　／　９０（フレームレートに対して３秒値）
　Syne Lockahead：７２　／　９０（フレームレートに対して３秒値）
　シーン変更感度：８９

　フレームレートに対して３秒値に、一本化され変更となりました　＼(^o^)／


＞　では、うんちくに入ります
↓/続きを読む/↓

【AviUtl】ソースのキーフレーム全抽出プラグインが欲しい

記稿.2019/05/28

＞　エンコードレシピ「夕澄の夢」で
＞　用いているキーフレームの選択設定が絶対的にベストとは思っていません
＞　でも、標準よりは人の側の編集要求を満たすにベターであると言えるでしょう


　‥それでも決定的な弱点があります
　それは、標準との差でもあります‥（使い分けのポイント）

　ＰとＢを避けて、Ｉフレームをわざわざ増量させる特定値による割り出しのため
　それだけ、よりＢフレームを選択しない（割り出しにくい）ルール化でもあるわけです

　つまり、Ｂフレームを多くして圧縮したい場合の要求を満たしません

（Ｉフレーム数の間引きがされにくい‥品質設定と絡んでＢよりＰを割り出してしまう）


　これは、あくまで色彩の劣化を避ける為の
　Ｉフレームに軸を据えた‥場面の変化に即したＧＯＰ構造を要求した結果です


＞　ところがこれをＨＥＶＣで同じようにやっても上手く行きません


　‥そこで思いついたのが
　まずはＡＶＣで再エンコードしたファイルを元に
　Ｉフレーム位置を全抽出してしまい
　今度はそれを、インポートしてＨＥＶＣでの再エンコードに利用しちまおうとのアイデアです

　ＨＥＶＣエンコード時におけるその辺の設定値をどうするのかという課題が残りますが

　取りあえずそれでＩフレーム位置を同じにして当ててみて
　圧縮率が向上するかどうかです
　劇的に圧縮されるようなら、ＡＶ１を無用の長物にしちゃうかも（なんてな）

【エンコード日記】デブロックフィルタのそこんところ

↓3)記稿.2019/05/04

＞　デブロックフィルタ（deblock）とは


　‥量子化された格子の境という奴ほど連続めくりして見る場合の最適化が欠かせない
　綺麗に見える連続にするにも、まずは格子の境目の最適化である
　ブロック状にて処理される以上、つなぎ目の具合ほど慎重さが求められる

　‥如何なる作業にも言えることだが
　「カッチ」と蓋のされる日本製とそうでない中華製とのキャップ等での差は大きい
　境目の質とはそういうものだ

　‥裏を返せば
　境目の処理が伴う性質上、条件が違えば、似せることはできても
　まったく同じになるわけが無い‥との理解に至らざるを得ない


＞　ところが
＞　AVCにおいてその機能性はどうにも大ざっぱである
＞　HEVCにおいては、処理に対するアプローチは増えているが注目度は低い


　AVCの頃の感覚で十分だと思っていると
　折角のHEVCの追加要素を見逃したままだ（それこそ過剰装備にしか見えていないだろう）

　‥しかし、つなぎ目をどうするかほど、重大な要素も無い
　ぶっちゃけたことを言えば
　動画エンコードとは、つなぎ目だらけの寄せ集め映像である（軽視して良いわけがない）


＞　さて話を進めよう


　AVCにあるdeblock項目にはまず
　機能をオンにするかオフにするかのスイッチがある

　十分すぎるビットレートさえ与えれば
　「ブロッキングなんて発生するわけねぇ」なんて考えもあるようだが
　そんな考えはまず捨てよう

　‥何が起こるかわからない‥それほどの情報量を処理していただこうというのに
　境目の補正を欠いてやらかそうなんてのは、ブラック企業の手抜きっぷりとさほど変わらない
　どう考えたってその程度の発想から抜け出せないままになる
　（品質の良さなんて奴は、ガタガタしないように如何にして事前対策してあるかだッ）


＞　それにしても、次の項目の二つの数値の意味がよくわからない


「AviUtl」や「XMedia Recode」には

　ブロッキング軽減 - 強度：０
　ブロッキング軽減 - 閾値：０
　とある

　‥ググってみると

　--deblock （alpha,beta）
　alphaはFilterを掛ける閾値（いきち）
　betaはFilterを掛けない閾値（いきち）
　と書かれてあったりする

　（だからなんだよわかんねぇよ）


＞　‥そこで日本語を置き換えてみた
＞　フィルターに掛かったときの閾値、掛からなかったときの閾値


　‥そもそもがデブロックの処理なんだから
　まずはブロッキングになりそうな程度で分けることになる
　常時一定の閾値で処理をする必要は無いのだ
　だからこれは、必要時と不要時の閾値が異なっていると考えて良いだろう（そうとしか思えない）


　‥あとは限界値の組み合わせから見比べてみれば良い
　±6までの整数値しか用意されていないので、それだけ大ざっぱということでもあるわけだけど
　必要時と不要時の閾値が異なっていると考えるなら、そういうものかなと思わなくもない
↓/続きを読む/↓

【エンコード日記】ＡＱ強度（0.6）と（1.0）の差のそこんところ

記稿.2019/03/19

＞　‥ＡＱ強度とは
＞　ビットレートの割り振りがされた後の
＞　最終的な一つの格子の中での内訳における
＞　微細に表現するべきところと、平たく解釈しても良いところとの割合の度合いを指す


　‥で、一般に
　ＡＱ強度（1.0）は、カメラの水準ということらしい
　カメラの水準と言うことは、一枚単位における輪郭の度合いを優先したい内訳という事でもある

　輪郭さえしっかりしていれば、後から幾らでも「味付け」のしようがある
　カメラでは輪郭こそが命と言えるだろう‥（よう知らんけど）


＞　‥ところが、動画ではそうでは無かった
＞　動画の場合に重視すべきは
＞　「ぼかし表現」とした自然現象としての最たる風光の度合いこそを基準にすべきだった


　‥それの差が、ＡＱ強度（0.6）ということらしい
（黄金比差にあるようでもあるが、ＱＰ値との兼ね合いでもあるような‥）


　‥例えば、月明かりである
　‥「闇の中の動きで、輪郭は重要だろうか？」
　いいや、鮮やかさの方が印象に残るだろう
　だからこその「月影」とした言葉での表現がされるのである

　そこを輪郭優先でやらかしては
　月明かりに適った「ぼかし」現象は、端折られて処理されるばかりだろう

　ギンギラ映像ばかりを見ていると、やたらとシャープに整えたくなるわけだが
　そこに合わせてしまうと、ぼかし現象本来の味わいが失われてしまうのだ


　‥静止画は一枚がゆえにいくら弄ったところで他のコマに影響を及ぼさないが
　動画はそうでは無い、輪郭ばかりに目をやると、風光の度合いで色が細ってしまうのだ

（HEVCだと、33方向に動きをチェックできるので、それなりにマシになると思われるが）
（AVCの場合は、そこまでの性能には無いので、ビットレートを割り振るだけでは対処しきれない）


＞　それはとくに、画面を暗めにした場合にはっきりするだろう


　暗くしても尚、輪郭だけがはっきりとしているなんてのは不自然すぎるのだ
　ビットレートの割り振りをケチるかケチらないかの差がそこに現れる

　ＡＱ強度（0.6）にするとビットレートの割り振りが減るので
　その分、品質を調整してビットレートを多目にする必要が伴う


（このような解釈こそが、本来的にビットレートを正しく割り振るという事でもあると思う）
（単に圧縮効率が上がったと喜ぶのではなく、細かい所の変化にまで気を配るべきである）
（‥さすれば、パソコン編集の映像はせいぜい27型サイズなので）
（如何にFHDサイズで調整していようと、TVでのHDサイズ調整とさして変わらない内容になるっぽ）


　‥まぁそのように対処して‥輪郭がシャープになるかというと
　そうでもなく、ＡＱ強度（1.0）と比べれば、ふわっとした印象のままということらしい

（ダウンコンバートとの差というのもありそうだが、FHDで出すのはめんどいしFHD画面が無い）


＞　‥動画エンコードの側で
＞　ぼかし現象と思わしき変化を繊細に仕分けて処理できるようにならないと
＞　如何なる現象にも適切に美麗、且つ、効率の良い圧縮率を得るには至らないだろうう


　（何でもかんでもなだらかになるように、平均化で演算させればイイってものでもない）
　（HEVCよりAVCの方が良いと思ったら、微にそういう見方に成ると思う）

　‥HEVCの場合は、格子の間の処理が細かい且つ格子もサイズの大きいのを使えるので
　AVCより強力に平均化されやすい傾向はあると思う

　（ゆえに、33方向を端折ったりしては、無残な結果にしかならないものと予想する）

【エンコード日記】心理的エンハンスのそこんところ

記稿.2019/03/10

＞　動画エンコードにおいて、心理的エンハンスには謎が多い
＞　そもそも何をしているのかを誰も説明し得ていない


　なのに、規定値のままに使うとそれこそ、1.2〜1.5倍も増量してしまうと云う厄介者である


　‥ところが
　「Psy-Trellis強度」と「Psy-RD強度」の値を揃えて使用することで
　思っていたほどに色みが後退しないことを発見っ！


　‥さらに
　規定値にしてしぶしぶ使うと（どちらも1.00‥ｘ264の場合）
　テレビの各映像メニューにおいて、適度な色合いで表示されるようになる

　テレビの各映像メニューなんてそもそもいじらないパソコンモニターオンリーの場合には
　殊更にどうでもいい話にも思えるが、放送を前提にしているがゆえの作りという事らしい


　‥そもそも、パソコンオンリーだというのなら
　制限モードではなく完全モードにこだわるべきだろう
　でも誰もそこまでしようとはしない（自慢貸ししずらくなるし、区別管理からして面倒くさいからな）


＞　ハードの方だけでは調整できないところを、ソフトにツケを回したと言うことだろうか‥



　‥しかしそれにしても
　昔のフィルム映像前提のテレビは、そんな器用な事ができる作りにはなっていない
　そこは、デジタル撮影された映像だからこその露光の良さ由縁みたいなもので、そこを勘違いしていると悩ましいことになる

　‥逆から妄想すれば
　日本のテレビメーカーが、自分たちのブラウン管時代の色づくりを残したくて
　それぞれを発展させたのが「映像メニュー」のエトセトラという事かも知れない

　そうだとすると

　デジタル映像の方を如何にして、アナログ映像寄りに味付けできるのか‥という事だったかも知れない
　（ならば、テレビだけでなく、カメラのノウハウも入り交ざって来たことだろう）


　‥結果、おいてきぼりを食らったのが
　元々の残したい願望の牽引役だったフィルム映像のリマスター出しだったことになる

　同じようにやるととんでもないことになるのは、予想に反しない
　（ニュースの昭和映像を見れば一目瞭然）



＞　ちなみに、心理的エンハンスを規定値で使った上で、期待する色みを得るには


　「参照フレーム数」と「M.E. 範囲」からの値の違いによる影響が大きいように思われる
　どちらかというと、Ｂフレームをやたらと多くしても、赤さが増すだけなので
　そこを規定値でどれほどにカバーしているのかにもなる

　‥場合によっては
　「彩度QPオフセット」が勝手に作動して、数値を放り込んでいたりする（驚いたし）

　（勿論、この作動が‥バグなのかどうかについても調べようがない）



＞　「Psy-Trellis強度」と「Psy-RD強度」の値を双方ゼロにしてエンコードすると
＞　手頃な映像メニューは、ダイナミックにみられる明るい系だけだったりする


　‥デジタルアニメ映像の場合
　制作側がすべての映像メニューに対応できるように色の選択をしているとは思えない
　‥その点、多くのデジタル実写映像の場合
　色を選んで造り込むとした所作が無いので、逆にモード選択を求めるのだろう


　‥そこの違いを考えると
　必ずしもすべてのジャンル映像が、映像メニューを前提にしているわけではない

　（万人万色向けに色みを気にしている人口比率はそれ程に多くない）
　（綺麗に見られりゃ、それ一択で良いとさえ思っているはずだ）

【XMedia Recode】3.4.5.2よりHEVCの「min-keyint」指定が正しく反映するようになりました

記稿.2019/02/24

＞　しかも、６４ビット対応まで登場しております
＞　「ありがとうございまーす♪」


　さっそくHEVCのキーフレームがどのぐらい入るものなのか試してみたところ
　AVCテクニックは、あっさりと敗北しました
　あの程度ではちっとも‥Ｉフレームの増量が見られませんでした
　これはもう地獄を見るしか無さそうです


＞　‥話が変わります


　ＡＶＣの品質レートは、ソースの状態により、その適正値はかなり変動するようです
　薄々感じてはいましたが、ＦＨＤとＨＤの基本差は2.25倍です
　それよりも効率よく圧縮ができてしまっているようですと、ビットレートの割り当てが不足の傾向になるようです

　具体的には

　ＡＶＣで、fast_pskip（1）っぽいソースの場合
　ダウンサイズすると、特定域の色の輪郭が不足しているので

　ＦＨＤサイズでは、CRF（15）での再エンコードがなかなかの見映えにあろうとも
　ＨＤでのCRF（15）のままHi10で出して、ご機嫌に圧縮率が良かろうと
　部分的にピンボケ傾向が発生していたりと不可解に見まわれます
　そんな時は、むしろ普通に‥８ビット出しで攻めた方が無難だったりします
　その上で、ＣＲＦを上げるなり下げるなりの検討が必要になる感じです


＞　それから


　‥今更ながら、テレビ×ＵＳＢの対応を確認したところ
　プロファイル highL4.2でも可能でした（やばっ）
　ということで、気分16：9映像の場合に、積極的に使って行こうかななんて思うところです

　でも、どことなく
　「16ｘ16」の格子を使うと「8ｘ8」止まりの時とは違う「癖」を感じるというか‥
　19型の場合にとくにそれを感じます

　‥で、じっくりと見比べてみたところ
　格子サイズ「8ｘ8」止まりの場合の方は、どうにものっぺりとしており
　それに見慣れていたせいで、妙に色の表情に立体感のでる「16ｘ16」の格子に違和感を感じたらしい‥
　画によっては、変なラインがもやもやと目に焼きつくような印象だったりもしました


　ちなみに

　ＨＤサイズで出す場合、規格としてはL3.2程度が妥当ではありますが
　格子分割が多い場合、コマ一枚当たりのあれこれな制限に引っ掛かって、色剥がれが発生する場合も有り得ます
　なので、気分L4.1ないしL4.2とした構えの方が無難でしょう（高画質前提）

　（逆から言えば、始めから制限を考慮してエンコードされるので、より小ぶりになる傾向はあると思います）

　‥主旨にも依りますが、そもそもテレビ×ＵＳＢ視聴の場合
　USB2.0の帯域が引っ掛かって、ＦＨＤサイズ映像の再生の際にコマ落ちの可能性が否めません

　（そんなことからか‥テレビ番組用の映像は16：9にも関わらず、はじめから1440×1080に縮めてあるらしいとか）
　（つまりｋｋ対応放送の狙いとは‥USB3.0の活用案？？‥でも録画ダメ方向だし‥さっぱりわからん）


＞　で今回さらに
＞　1280x720サイズでＡＶＣＨｉ１０_CRF（13）で洗逸したmp4を
＞　テレビにUSB挿しして再生を確認してみたところ
＞　再生はできましたが、（HDサイズだし、Bフレームカットなのでさすがにコマ落ちはしないのですが）
＞　どうにも演算処理能力が乏しいのか、ところどころで格子パーツの色落ちが激しく視聴に耐えられない状況でした


　全く対応していないと言うよりは
　ハードパフォーマンスが低くて再生が止まることが大きい‥と判断できそうです
　（ぶっちゃけ、入ってるプログラムはオープンソースのまんまでしょうし、そういうことだったんだなぁと思われます）

【エンコード日記】BT709と画面の大きさと色温度差の怪

改稿.2019/02/01...20190128...

　AviUtlの時もそうだったのですが、BT709で「ウルトラマン」をエンコードすると
　モニター側の色合い調整で戸惑います

　今回の設定（洗逸GOP（Ver.Bフレームカット-AVC））でも、その辺の悩ましさに戸惑いました


＞　結果を先に述べますと


　19型では、好逸スタンダード‥色温度（中-高）
　26型では、好逸ダイナミック‥色温度（低-中）〜（中）

　‥が適当にあるようです。
　ぶっちゃけ、（768x576）のPALサイズで出すよりは、（960ｘ720）のHDサイズで出した方が
　赤さがより適正になるような気がしました
　（サイズが1.5倍、エンコード時間増なので後まわしっす）

　‥などの気になるところはあるのですが、まぁ概ね美麗です

　少なくとも、前回設定でのHDサイズ出しと見比べて、一つ上の画質を得ています
　やはり、Ｂフレームカットの効果が効いているのでしょう
　ＣＲＦ（１５）ということもあり、以前に見られた微にピンボケとも皆無です


＞　でも、こんな風に差が現れるとは予想外でした


　19型はＰＣモニターとしてのテレビにもあるので
　ギラギラしていると目が疲れて受け付けません
　なので、好逸スタンダードでも間に合うのですが

（明るさオート（オン）の時間帯によっては、好逸ダイナミック（19型）でもそれほど目にギラつきません）
（暗い場合には（オフ）にします。オフにしない場合、好逸スタンダードとの差を感じない程度に明るさが落ちています）
（慣れてくると、概ね好逸ダイナミック色温度（中-高）でもイイかなと思うことの方が多いかと）


　居間にある26型になると、好逸スタンダードでは、色味に不足が生じてしまいます
　そこで好逸ダイナミックということです（ここの違いがＨＤサイズで改善するかどうかです）


　さらに、テレビサイズでの色温度での違いが、予想していた理屈通りにはっきりと出ています

　この二つの好逸設定を得ていない場合だったら
　Ｂフレームカットでのエンコード挑戦は、敗北だったように思います


＞　19型での色温度（中-高）での視聴は、始めのうちは青さが強い気がしますが
＞　意外にも目が慣れてしまいました‥（あれ？）ってな感じです


　‥なんだかんだと、ウルトラマンでは丁度よさげに見えても、セブンだと始めは青さが気になりました
　それは、26型での（低-中）〜（中）の間ぐらいが適当に思う微差でもあります

　（参考までに、ウルトラセブン第４５話には、緑とオレンジの国鉄車両が走ってます‥たぶん多摩川）


＞　３２型のテレビで見るなら、ＨＤサイズでのエンコードが適当に思います（色温度は見ないとなんとも云えません）
＞　２４型辺りなら、（768x576）は十分に想定内でしょう‥（色温度（中））

【HEVCと洗逸と受難】イントラとインターのそこんところ

記稿.2019/01/20

＞　ＡＶＣに比べると、ＨＥＶＣでは、圧倒的に「イントラ」と「インター」を用いた説明が入る


　‥早い話が
　キーフレームとそのあとに続くフレームとの違いを意味しているのだが
　HEVCの場合は、特にイントラとインターにおいて四分木の扱いが異なっている事によるのだろう

　例えば、レベル5.1以上を選ぶ場合
　イントラ深度は、強制的にCU（64）とCU（32）の二段階に制限されるという
　すると、四分木としてイントラ深度（4）までを扱えるのは、レベル4.2までで、最適解像度で云えばFHDサイズだ

（どうしてこんな事になっているのかというと、思うに、デコードまでが大変になるから）
（もともと送信量を減らすことを考慮して造られたのがHEVCでもあるわけだし、そのように思われる）
（これが５Ｇ時代に突入すると、事情は異なってくるかも知れない）


　‥イントラは、オープンGOPやオールイントラにでもなければ、他の画像からの格子を参照しない‥
　（※IDRフレームという区分がキーフレームになる）

　つまり参照される側だから、圧縮においてのそれは、単に参照されやすいようにマス目を引くだけになる
　この段階でわざわざ矩形の形までを採用すると非常に複雑な計算をせざるを得ない
　なので、ザックリと　CU（64）（32）（16）（8）という正方形要素だけでマス目を引く扱いらしい

　ただし、CU（64）からのイントラ深度（4）を用いたとて、必ずしも望む効果を得られるかは不明だ

　そこで最大CUを下げると、下げた分だけイントラ深度の値も下げることになる
　最小CUを上げても、上げた分だけイントラ深度の値を下げることになる

　…このことから
　イントラ深度（1）を選択する場合には、最大CUと最小CUの値を揃えることを意味するのだろう
　果たして最大と最小のどちらを用いるのだろうか？
　最大CU（64）、最小CU（8）に選択していたなら、自動で一番に効率の良いところを選ぶのだろうか？

（まぁその辺の細かい解説は今のところ目にした例しがない）
（気になるようなら、始めから最大CUと最小CUの値を揃えて指定してしまうのが時間的効率かも知れない‥）　
（HEVCの場合、小サイズでのエンコードなら、最大CU（16），最小CU（8），イントラ深度（2）だろう）


＞　ではインターの場合はどうだろうか？


　‥文献でも細かい解説が見られないので、あくまで想像の域を超えないが
　再帰的というぐらいだから、インターとて
　イントラの定義に則って、基本的な正方形格子を用いて区切るのだろう

　そうで有るならば、イントラがキーフレームとして適切に値しない場合は
　インター自身の分解に任せる仕様に思われる（そうとしか思えない）


　‥イントラが、キーフレームとして適切である場合
　インターは、イントラの格子をそのままに活用して、インターとしての四分木を切ることができる
　で、その時の最大TUというのが、最大CUサイズからの矩形を意味しており
　矩形をさらに分解するという事では無いらしい

　矩形に分解されれば、それより先の分解を進めず、基本は正方形格子による入れ子式に折りたたまれる
　ということで、4ｘ4の分解マス目は、CU（4）としての扱いをせずに矩形の一つに区分されている（へぇ〜）


　では、最大CU最小CU最大TUともに（16）で且つイントラ深度インター深度ともに（1）なら
　そのマス目の分解能は16×16と16ｘｎサイズのTUだけという事になるのだろうか？

（誰もそんなのを想定していないとばかりに説明不足はどうにも不可解である）


＞　‥イントラのマス目が、インターのマス目たり得るなら、品質も圧縮効率も向上する
＞　‥インターのマス目たり得ないなら、Ｐフレームに制限されるようなビットレートでやり繰りしなければならない
＞　その時の品質と圧縮効率の兼ね合いは決して満足できる状況には無い
＞　ただし、オールイントラの場合には、容量が嵩むだけで、品質に差は見られないだろう


　‥ＨＥＶＣのスライス能力は、優秀にあることから、増量を気に留めないなら
　それの差の見分けが付かないことから、キーフレームがどこだろうと気にする必要はほとんど無い

　しかしそれで良いのだろうか？

　見分けが付かないほどに優秀なスライス能力を手に入れたなら
　次は編集のしやすさとしてのキーフレームの的確さということになるはずだが
　未だに「一に縮小、二に縮小、兎に角まだまだ縮小せよ」としか頭に無いらしい

　キーフレームが適切にあればあるほど、圧縮率が上がる以上に
　編集がしやすくなる、倍速がより美麗且つ適正に見えるとしたメリットを得るのだが
　どうにもそこまでの意図を持って取り組んでいる様子は伺えない


＞　多分、本気で取り込もうとすると、ＡＩを活用せざるを得ないのだろう
＞　すると、オープンソースとしてのスタイルを維持することが難しくなる
＞　その時の打開策としては、特定ハードに対応させることでオープンソース化は維持できるにせよ
＞　コスト次第では、エンコード上のネックになりかねない（プロ向けのオプションの類に陥る）

【エンコード日記】フルBT.709指定 VS. psy_rd=(0.2)

改稿.2019/01/19...20190118...

　‥ＡＶＣにて、Ｂフレーム無しでウルトラマンをエンコードすると
　クリアーさだけが剥き出しになった趣に陥り、我慢できず
　psy_rd=(0.2)という方向をやってみたものの
　是がまた大きめのモニターだとそれもありだろうけど、19型の画面では何かと満足感が無い

　そこで

　同じに画をいじって容量増すぐらいなら、フルBT.709指定もありだろうと思った
　やってみたら、すんなりと納得できる画を得た‥（psy_rd=(0.2)は没になりました）


＞　どうにもBT.601のままというのが、品質にムラを起こす要因だったらしい
＞　それは、とくに色温度（低）に下げるほど顕著に現れる


　今どきのテレビの前提は、ダイナミックモードのド明るめだ
　且つ、Ｂフレーム前提の映像にあるわけだから、尚更にBT.601の課題点が見えていなかったように思われる

　（昭和映像をエンコードしようとすると誰もが問わざるを得ない登竜門だ）


　‥正解は
　Ｂフレーム有り程度だと気にならなくも、無しでのエンコードもしくはより高品質を目指すなら
　色領域が不足しだして、フルBT.709指定が欠かせない‥ということらしい

　（それの事情が、そもそものデジタル放送化の都合だったのだろう）


＞　余談だが


　‥AVC CRF15（768ｘ576）でエンコードすると、狭い領域にぎっちぎちなのか
　ウルトラマン第一話に登場の潜水艇S16の灰色系反射に、そこだけ余裕が無いのか、エッジ立ちまくりに見え始める
　思えば、どう見たって色領域を広げた方が良さげ‥だった
　つまりBT.601のままは、色々と品質の向上を得ようとし出すと、気が付かない部分での色不足が露わになる
　という事だったらしい

　‥ということは
　4ｋ8ｋサイズともなるとBT.2020，BT.2100への切り替えは、セットになるのだろう
　（むしろセットにしないと用を成し得ない予想になる）


＞　それにしても、psy_rdの性格の現れがよく解らない
＞　BT.601時代映像とBT.709時代映像とでは、異なっているように思う


　はっきりしたのは、昭和映像において、psy_rdの値を上げても、望ましい状況を招かない事だ

　しかし、デジタル映像になると‥そうでもなく‥HEVCになるとさらによく判らない
　唯はっきりしていることは、ぼかされるし、容量も時間も嵩むし、利が不明という事である

　（やはり、大型化の流れにおける間に合わせ感は否めないと思う）
　（だからといって、心理的エンハンスなしにするのもよろしくない）
　（ブロッキング軽減と似たような機能性に思うまでだが‥説の曖昧すぎが不満だ）