2019年05月28日

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

記稿.2019/05/28

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


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

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

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

(Iフレーム数の間引きがされにくい‥品質設定と絡んでBよりPを割り出してしまう)


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


> ところがこれをHEVCで同じようにやっても上手く行きません


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

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

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



posted by 木田舎滝ゆる里 at 10:19 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年05月04日

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

↓3)記稿.2019/05/04

> デブロックフィルタ(deblock)とは


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

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

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


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


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

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


> さて話を進めよう


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

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

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


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


「AviUtl」や「XMedia Recode」には

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

 ‥ググってみると

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

 (だからなんだよわかんねぇよ)


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


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


 ‥あとは限界値の組み合わせから見比べてみれば良い
 ±6までの整数値しか用意されていないので、それだけ大ざっぱということでもあるわけだけど
 必要時と不要時の閾値が異なっていると考えるなら、そういうものかなと思わなくもない
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 11:58 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年03月19日

【エンコード日記】AQ強度(0.6)と(1.0)の差のそこんところ

記稿.2019/03/19

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


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

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


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


 ‥それの差が、AQ強度(0.6)ということらしい
(黄金比差にあるようでもあるが、QP値との兼ね合いでもあるような‥)


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

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

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


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

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


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


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

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


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


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

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


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


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

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

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



posted by 木田舎滝ゆる里 at 01:56 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年03月10日

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

記稿.2019/03/10

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


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


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


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

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


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


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



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

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

 そうだとすると

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


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

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



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


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

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

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



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


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


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

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



posted by 木田舎滝ゆる里 at 23:11 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年02月24日

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

記稿.2019/02/24

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


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


> ‥話が変わります


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

 具体的には

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

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


> それから


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

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

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


 ちなみに

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

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

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

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


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


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



posted by 木田舎滝ゆる里 at 02:22 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年01月28日

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

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

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

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


> 結果を先に述べますと


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

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

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

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


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


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

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


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


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

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


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


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

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


> 32型のテレビで見るなら、HDサイズでのエンコードが適当に思います(色温度は見ないとなんとも云えません)
> 24型辺りなら、(768x576)は十分に想定内でしょう‥(色温度(中))



posted by 木田舎滝ゆる里 at 13:44 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年01月20日

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

記稿.2019/01/20

> AVCに比べると、HEVCでは、圧倒的に「イントラ」と「インター」を用いた説明が入る


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

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

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


 ‥イントラは、オープン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サイズからの矩形を意味しており
 矩形をさらに分解するという事では無いらしい

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


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

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


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


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

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

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

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


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



posted by 木田舎滝ゆる里 at 21:52 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年01月18日

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

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

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

 そこで

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


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


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

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


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

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


> 余談だが


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

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


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


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

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

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



posted by 木田舎滝ゆる里 at 17:41 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年01月17日

【エンコード日記】シーン変更感度(先読み、GOPとのコンビネーションが必須だった)

記稿.2019/01/17

> シーンの検知には、100%選択されるケースとそうでないケースとがある
> 最大指定値とて、すべてを検出できているとは限らない
> さらに、先読み量にも、GOPの調整値にも影響を受ける
> アニメと実写とで二分化する
> (Iフレームの増量は気になるけど)秒間コマ数の違いは、シーンの検知にはさほど関係が無いらしい


 ‥100%選択されるとは限らないケースの場合
 先読み量が多ければ多いほど‥最適になる‥と思ってきたが、実は間違っていた
 先読みが多すぎると却って、ビットレートの効率化の調整が先に働いてしまうらしく
 シーンの検知の方が後まわしにされる傾向を確認した

 (シーン検知の方にまずは優先度を与えないと、この先の革新は見込めないだろう)

 先読み量を上げることで、むしろ省かれるケースが多くなる(基本値以下は論外)
 基本的に{GOPの最大距離}={先読み}に扱うべきにあることから、先読みの値の方がより重要になる

 (この先読みの適正値がアニメと実写で異なっている)


>  シーン変更感度(89),先読み(80)‥アニメ
>  シーン変更感度(67),先読み(60)‥実写


 ‥例えば、振り向くシーンの場合
 マンガなら必ず2コマ必要になる

 ところがエンコードの場合、「後ろ向き」一枚を優先すべきがIフレームとしての適正だ

 なぜなら、振り返った顔にIフレームが入ってもすぐさま別のシーンに切り替わるだろう
 そのようなとき、Iフレームの次の画がBフーレムになることで画質の差に違和感が付きまとう場合がある
 (頭から高画質前提なら問題ない話だが、DVDからのアップコンバートともなるとその手のケースも増えるだろう)
 (その様な場合、そのままPフレームが当てられる方向に任せた方がスッキリするようだ)

 これの基本が押さえられているかいないかでさえ、指定した数値の違いで差が出る


 先読みの最適値は、フレームレートの基本値に影響を受けるので
 あまりにも基本のフレームレートに対して違和感の募る値を選ぶなんてのは有り得ない

 そうなると、先読みの値に合わせて、シーン変更感度の値を選ばざるを得なくなる

 ところが、2で割り切れる値では、シーンの抽出にスルーむらが、どちらからずでどうしても発生してしまう
 さらに、3で割り切れる値ともなると、お話にならない奇妙な検知が発生する

 ‥ということで素数値に活路を見出したところ、上に挙げた数値になりましたとさ


> ちなみに、HEVCの場合、最大CU値の違いでも差が出るかも知れないので
> ここでの話は、今のところAVC止まりです


 Bフレームの指定枚数でも検知差が出ると思いますが
 ウルトラマンなど、Bフレームカットすると、Iフレームがより増量される傾向になります
 (半イントラ状態におったまげました‥ただし値には偏りがあり拾われないケースでは依然として拾いません)



posted by 木田舎滝ゆる里 at 12:38 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする

2019年01月16日

【エンコード日記】CRF(15.15)は没になりました

記稿.2019/01/16

 ‥例のCRF(15.15)ですが

 パン動作には良かったのですが
 バストアップ,どアップをはじめとした中核シーンにおいて
 無駄なピンボケ感にイライラが募りまして没になりました

 結局、品質の設定値に端数値を噛ませると宜しくない傾向になるようです


> 結果、CRF(15)になりました


 ‥まぁ解ったことは、複雑な動きの場合
 多少ボケた方が、見やすい印象になるらしい‥
 複雑なほど、より正確に有るべきに思っていましたが、そうでも無かった事になります

 つまり、静止した画像系の印象の方を重視して、ビットレートを割り切っても差し支えないということに


> ‥となると、あとはシーン変更感度なんだなぁ
> 複雑な動きがよくなるもならないも、こちらでなんとかするしかないでしょう



posted by 木田舎滝ゆる里 at 16:02 | Comment(0) | HEVCと洗逸と受難 | 更新情報をチェックする