2020年06月05日

【エンコード日記】可変フレームレートはMAX可変マクロブロック状態でもあるのか?

記稿.2020/06/05

> 現在、インターレース・タイプでの‥qcomp(1.0)を用いたサーチキュルキュル化に悶絶中


 ‥avidemuxを用いたキーサーチ確認では問題ないのに、テレビUSB挿しでダメになる
 (ほとんどお手上げ状態)

 ‥気分転換に、プログレッシブソースをサーチキュルキュルに抽出したものを
 好みに切り刻んで並べる編集をやらかしてみたところ
 見事に可変フレームレート扱いになっているのに‥改めて疑問を抱いた


> 1秒あたりのマクロブロックの制限はどうなった?


 そりゃまぁレベル5.2ともなれば
 特にアニメなら使い切らないケースの方が多いのだろう
 その様な場合は、フレームレートを小さくした扱いで計算するのかも知れない
 逆に多かった場合は、フレームレートを大きくした扱いで計算するのかも知れない
 そう考えると、この件での可変フレームレートはMAX可変マクロブロックに等しい扱いなのだろう

 (これは、無劣化で編集した結果の規格外性をどう扱うか?‥とした意味合いなのだろう)


> ‥だがそれでは
> ただ単にコンテナ形式を変換しただけの時に見られる可変フレームレートはなにが違うのか?


 こちらの方も規定の状態から逸脱しているデータ構成になるから
 その分を可変として扱うという事だろうか??

 (それはそれで、再リップせずに弄ってある痕跡を残すとした意味合いかも知れない)

 では、その時に起こり得る音声遅延状態はなんだろうか?

 (その辺はまだよく解らないが、遅延も可変もしにくい音声タイプはありそうで有る)


> で、結果的に


 ‥DVDの可変フレームタイプでは
 その辺のなんらかの構造の差の違いで
 AVCに再エンコードする際に、条件が噛み合わずにカクつくと云うことになる

 ‥そこで、≒60フレームに変更すると、器用に緩和されて見えることが多い
 ということになりそうだが
 これは、条件の相殺に適っていないとそうでも無い結果にもなってしまうとした‥予想にもなる

 (すべてを一発で解決するバランス調整値が得られないとしたら)
 (タイトルによっては、テレビUSB挿しでの美麗キュルキュルを程度諦めるほかない‥)



posted by 木田舎滝ゆる里 at 13:55 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月31日

【エンコード日記】qpmin:crf=1:1.5/但しqpmin(6〜10)

記稿.2020/05/31

> qcomp(1.0)にすると品質が底上げされるので
> あとは‥qpmin:crfに関連性はあるのか否か
> ということだが‥qpmin(11)以上はどうしたって劣化するので、(10)までが適正
> &crf値については、解像度1080を端境にした話に思われる


 Sサイズ ‥ qpmin(6)、crf(9.0)
 Aサイズ ‥ qpmin(7)、crf(10.5)
 Bサイズ ‥ qpmin(8)、crf(12.0)
 Cサイズ ‥ qpmin(9)、crf(13.5)
 Dサイズ ‥ qpmin(10)、crf(15.0)


 ‥便宜上↑のように呼称しておこう
 BDアニメのプログレッシブtsを720pにて再エンコードする場合
 Sサイズ対処でやらざるを得ないのだが、中には倍増してくれちゃうタイトルもある
 そのような場合は、Dサイズでやらざるを得ない

 Dサイズで再エンコードすると、テクスチャー崩壊はまぬがれないのだが
 気にしなくてもいい程度に収まる傾向のタイトルだったりするらしい
(テクスチャー崩壊が想定外なら、USB2.0帯域にまとめるのを止めちまうしかない)


> とりあえずそれで25分ものなら3GBを超えない程度にまとまるらしい(Bフレーム1枚)
> ところが不思議なことに


 ノンテロップOP&EDにも同じようにSサイズでやると
 まるで圧縮されないパターンに填まり込む(720pキュルキュルだろうと増量は頂けない)
 仕方がないので、そのような場合には、Aサイズが候補になる

 (この差は一体何なのだ?)
 (ちなみに、アニメ映画の場合も、似たような増量傾向がみられる)

 ‥一体、なにが違うのだろうか?
 割り当てられてるビットレート量にしたって、配分にケチケチがあるようには見受けられない

(OP&EDで減量できないなんてことになると、本編の方での圧縮だって怪しくなる)
(大丈夫なのか?)


 ‥なので、まずはOP&EDで減量できるか否かだろう
 イケるようなら、Sサイズで3GBを超えることはまず無い‥想定内だろう

 (4GBを超えちまったら、まず、お手上げだ)
 (あとは、サイズを落として、テクスチャー崩壊してないかをその都度チェックするしかない)


 ‥その点、映画版は4GBにまとめることからして既に無理なので
 品質を落とさざるを得ない話に誘われるところだが、想像しただけでも残念すぎる
(同一フォルダー内にあるソースを順繰りで再生してくれる機能がありゃまだマシだが)
(DVDがどうして連続で再生できているかってと、内部で1GB単位に区切る仕様だからである)

(ソースを分割して管理するのは悶絶だし、テレビUSB挿しのフォルダーの管理の仕方がまた鬼門‥)
(タイトルを前から順にコピーしないととまず駄目で、再書き換えにしても同じにしないとダメ)
(タイトル名をやり直すだけでも同じように全部を書き換えないと順番がぐちゃぐちゃになる)

(こちら側のOS上でのフォルダー設定し直しで対処できるのかはまだ試していない)

(でもまぁフォルダー管理で対処する気があるなら、お気に入り場面で区切るのはありなのだろう)
(問答無用で頭からお気に入り場面を再生できるならそれにこしたことは無いのだから)


> ‥ただ、XMedia Recode の場合
> 分割エンコードする場合の分割位置選択を指定するのに手間なのがかゆい
> さらに最近は、終わりの指定位置にキーフレーム制限、Pフレームのみの制限が加わったのか
> 再エンコードだというのに、終点位置を自由に指定できない場合が見られる‥


(なのでそのような場合は、シーンの区切りをダブらせるとした判断もせざるを得ないだろう)
(若しくは、フレームレート崩れに目を瞑って、再エンコードしたファイル側をバラす方法だろう)
(‥キュルキュルの威力の発揮のしどころと思えばやはり後者だが‥USB価格が‥)



posted by 木田舎滝ゆる里 at 17:11 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

【エンコード日記】qcomp(1.0)は隠れたプロ仕様だと思う

↓3)記稿.2020/05/31

> qcomp(1.0)にすれば、容赦なく増量する
> だが、Bフレームが段違いで画質向上する
> なのでBD並のインパクトを得るのに720pでのCRF値を上げても良いケースが増えた
> 但し、テクスチャー崩壊しちまうパターンには然したる変化は無いのでそこは下げざるを得ない


 (確実に見誤ってた‥orz)
 (jpegノイズ云々より、もっと時間軸観察間引きの方を疑うべきだった)

 ‥劣化のスパイラルに誘いこむ‥最もが時間軸観察間引きだった
 (444と420との差なんて、時間軸での劣化に比べたら誤差の差だ‥それぐらい決定的に異なる‥)

 ‥次に解像度×ビットレート量の順だった


> ということで、qcomp(1.0)はプロ仕様に思われる
> 増量してもカネに釣り合う作り、完成度としての立ち位置として申し分ない


 ‥是を理解していないと、どんなに尖ってみようと決まらない
 qcomp(0.60)で十分だとかハナ糞でーす(永遠に趣味のレベルっすから)

 同じエンコーダーを使っても、使いこなせていないあら不思議のままに人生終わることになる
 まるでお高いCPUを詐欺で売りつけられてるに等しいやらかしをやっちまってるパターン
 おまけにオーバークロックまでして悦に浸っちまってるなんて世界観の持ち主だったりしたら
 それこそ残念リップの王様だよ

 そんな残念リップに絆されて一歩も動けないままのHDDの中身とか、無駄に痛恨の極みだ

 ‥時代はHDRなのだから
 qcomp(0.60)とqcomp(1.00)の差も分からない
 そんなダメダメで脆弱な視覚で、映像美を語ろうだなんて
 はじめから規格側に嘲り嗤われてるってだけのオチだから‥orz

 日用だからそんな勘違いもありでしたなんて、それこそ残念な言い訳だよ

 それっぽちの視覚しかないのに
 それの差の判断も付かないのに、勢い余って時代が8Kに悦を浮かべてみたって
 ただの物欲だ、美学にはほど遠い


> 時間軸観察間引きは、そういう罠でもある
> ‥HEVCでどうかまでは知らん‥だが、HDRしようってのにqcomp(0.60)はありえん


 ‥間引きすべき取捨の意図が一般に説明されている様子が無いのも不可解しい
 ‥時間軸で観察するとしたワード以外に説明が無く不明で秘匿すぎる

 ‥普通に重複気味の部分の間引きだけならIPBの差で良いはずだ
 (時間軸観察で間引くとまれに残像がダブって仕込まれてしまうケースもあるので好かん)
 (何してくれちゃってんの?まったくの謎っすから)


> 高画質を保持して保管すべきと思い抱くなら
> 基本的に押さえるべきビットレート量から削るべからず
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 00:00 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月22日

【エンコード日記】qcomp(1.00)×qpstep(4)に合点を得たものの‥

記稿.2020/05/22

> qcomp(1.00)×qpstep(4)による画質向上感には合点できたものの
> qcomp(1.00)によるmbtree自動オフの影響の方に驚いた


 ‥1536x864でのqpstep(4)とqpstep(5)を比較したところ
 容量の変化はほぼ皆無でありながら
 拡大静止画比較も玉葱の薄皮1枚分ぐらいの差を見分けろと言わんばかりの差でしかないのに
 動かすとなぜか、全くの別物になる

 ‥とはいえ

 qpstep(5)のボケ具合の差が
 バンディングのトレース具合に影響することがハッキリとした
 qpstep(5)を用いると、BDtsソース側に刻まれているバンディングが減ずる傾向にあるが
 うまく行かない場合は、逆により微に目立ってしまうとした差を生みだしていた
 qpstep(4)にするとソースに準ずる方向でエンコードされる

 ‥という具合にqpstep(5)もまんざらでは無いと思う部分はあるも
 qpstep(4)にした途端に得られる滑らかすべすべ感にはどうしたって魅了されるのだ
 (意外にも、ぼかすだけでは抜群の滑らか感は得られないらしい)


> qcomp(1.00)にすることで、それがよりハッキリとする
> ということは、BDtsの規格のそもそもはqcomp(1.00)にあるとしか言いようがない‥


 ‥ところが
 qcomp(1.00)にしたことで、Bフレームの入り方が変更していた
 それは、mbtreeによるpb比率の自動調整がオフになる影響だ
 つまり、pb(1.3)の固定値に沿ったBフレーム選択ということになり

 ‥その流れから、サーチキュルキュルなどと言うことをやっているので
 なぜかPフレームが増えるよりもIフレーム優先で増量してしまうというオチに悶絶中‥orz


 (ただでさえqcomp(1.00)で増量というか減量が難しいのに‥どうすんだよこれ‥)
 (とくに悩ましいのが、720pでの画質×減量感がまったく甲斐を得られない点である)



posted by 木田舎滝ゆる里 at 17:06 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月19日

【エンコード日記】USB2.0帯域を凌駕しちまってる例

記稿.2020/05/19

> キュルキュルサーチ状態に変換したCRF(9.6)×qcomp(1.0)‥の
> 「映画 この素晴らしい世界に祝福を!紅伝説」のビットレート構成です


KonoSuba_Legend of Crimson.png

 ‥ご覧の通り
 USB2.0帯域を大きく凌駕している場面がちらほらしています
 これを想定内にやり直すとなると、全体の品質をすごく下げないと無理でしょう

 ‥そこはともかく
 そのまんまで、どれほどにHDテレビで再現できるのかを場面抜きして試みたところ
 後半のような案配はまだまだ視聴可能でした
 選ぶUSBメモリーやらテレビの性能次第では、音声で乱れが発生するかも知れませんが
 このぐらいなら、視聴する上でどうにか問題は無さそうです


 ‥で、ぶっ飛んでる辺りはと言いますと
 双方共に、見苦しい格子乱れは発生しませんでした(さすが隣のIフレームで即復活)
 そのまんまコマ落ちとオト落ちが激しく発生しますが、途中での再生落ちは無いらしい‥
 ソースによっては、熱での再生落ちが気になる状況もあるように思われますが
 USB3.0対応メモリーなら問題無いように思われます(使用したのは東芝製)


 ‥ちなみに
 ぶっ飛んでいる辺りは、双方共に回想シーンです
 この回想シーンでは、回想ノイズ乱れ&パンの容赦なき表現どころになってまーす

 (いやはや、誰も予期していない現象でしょう)
 (後半の魔法終結シーンよりビットレート使い込んじゃいやんの、ありえねー)


> avidemux(Iフレーム位置キュルキュル具合確認用)
> Bitrate Viewer(ビットレートの内部確認用)


 ‥avidemuxでのキュルキュル確認は
 ファイルを放り込んだあと、▲ボタンをポチポチするなり押しっぱでOKです

 ‥Bitrate Viewerの場合
 対応していない音声を使用していると弾かれます
 (AACかAC3が無難です)



posted by 木田舎滝ゆる里 at 23:46 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月18日

【エンコード日記】容量を増量させる第三の刺客

記稿.2020/05/18

 ‥エンコードの難敵と言えば
 まず、規則性の見られない映像をはじめとした細かい系が挙げられる
 次にパン&ズーム
 で、その次が確認された

 p4x4の多様×キュルキュルサーチなどという無理やりなエンコードにて
 姿を現した‥実はむちゃ劣化しやすい演出があった


> それは、今時アニメで多用されている回想シーン表現の色使いだった


 前の二者は、漫然と容量がかさむ傾向を見せることで最悪になるケースだが
 今時アニメの回想シーンのそれは、ちょっと違う
 いきなり瞬間的にUSB2.0帯域を振り切るのだ

 そういうのを調べると回想シーンであるパターンが多い

 つまり回想シーンにおいて複雑な動きを加えてあると
 圧縮効率がそこだけ悪いか品質が落ちやすい
 無理に品質を上げようとすれば、複雑をやらかさざるを得ない

 (とくに回想シーンでのフェード絡みは要注意だ)


> 制作サイドが其を心得ずに色選びをやり続けるのは見過ごせない



posted by 木田舎滝ゆる里 at 23:52 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

【エンコード日記】もう悩むのは捨てて、qcomp(1.0)で行こう

記稿.2020/05/18

> 時間軸観察間引きは、どんなに弄っても碌な結果をもたらさない


 ‥時間軸観察間引きを許すと、テクスチャーは崩壊する
 ただでさえダウンコンバートをやると崩壊してしまうのに
 さらにグデグテにしてしまう意味など無い

 (とくにパンのカク付きはうんざりで、それの主犯に怪しいのが時間軸観察間引きらしい)
 (パン演出部分については、アルゴリズムを変えるべきにあると思う)


> qcomp(1.0)にすると、mbtreeは自動でオフになり
> その分の時間軸観察もリセットされるっぽ


 ‥だからといって、テクスチャー崩壊が防げるのかというと、これも怪しい
 そもそものエンコードの造りが、重要で無いと判断された部分から間引きされる造りだ
 なので、間引きする上での辻褄を遺憾なく発揮してくれる


 ‥サンプルのテクスチャー崩壊についての例(紅伝説)
 格子ガラスの格子に沿って、なぜそこの行と列だけテクスチャーが見事に剥がれるのか?
 そりゃ、絵心としてはありかもしれないが(イレギュラーすぎる)
 その格子ガラス戸は、庇の下にあって、その場面ではとくに日陰状態だから、剥がれるわけが無い

 などという要求をエンコーダーが知る由もない(これでqcomp(1.0)である)

 ‥どうにか回復させようとえっちらおっちら弄ること
 qcomp(0.999)が好いらしい、しかし、すべてに通用できるとは限らない
 なにはともあれ、イレギュラーの微差に神経を研ぎ澄ますのは労力の無駄そのものだ‥orz


> その後も色々と数値を変えてみて(0.96)辺りなどと思い込んだが
> crfとqpminの方の比率にこだわった方がずっと案配良さそうな向きらしい


 qpmin×1.066666666666=CFR(連続値端数999‥のみ切り上げ)

 5×1.066666666666‥≒5.3333333
 6×1.066666666666‥≒6.4
 7×1.066666666666‥≒7.46666666
 8×1.066666666666‥≒8.53333333
 9×1.066666666666‥≒9.6
 10×1.066666666666‥≒10.6666666
 11×1.066666666666‥≒11.73333333
 12×1.066666666666‥≒12.8
 13×1.066666666666‥≒13.86666666
 14×1.066666666666‥≒14.93333333
 15×1.066666666666‥≒16
 16×1.066666666666‥≒17.06666666
 17×1.066666666666‥≒18.13333333
 18×1.066666666666‥≒19.2


 ‥逆数は「0.9375」である


 ‥XMedia Recodeでは知らないうちに、CRFの端数距離が伸びていた
 しかも、一度打つと、ソースを越えない範囲で、項目を越えても、その状態を維持する

 ‥なので、もう一箇所、桁増量コンマ端数打ちを仕込むことができる
 ‥なので、qcomp(1.0)にした方が、ずっと自由度が上がるので
 解像度変更等での調整に振り分けた方が、より要求に応えやすい

 (1080pで日用エンコードなんざしてたら、やはり視聴時間が減る一方だったz)
 (どう考えたって人生の無駄っすッ)


> 悩んでいいのは、増えていくだろうHDDの数だけで十分だ
> 残念リップを肥やしたって後悔で一杯になりかねん



posted by 木田舎滝ゆる里 at 20:45 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月16日

【エンコードレシピ】特異点1080p(BDtsアニメ-プログレッシブ用)

↓11)記稿.2020/05/16

> FHDモニターを持たずに特異点1080pを割り出したという
> それは正解か否か‥(その確認をするか否かはあなた次第)


 ‥1536x864は1920x1080の各0.8倍である所から
 それと数値をすり合わせながら逆算比較しつつ、値を絞り込んだわけですが
 なんというのか、最終的に、エンコーダーの造りが鬼門になるので

 特異点の定義としては、どのタイトルでも安定した限界的高品質が得られる
 とした仕上がりを指しています。


 ‥最終的にエンコーダーは正確性を重視してエンコードを致しません
 なので、必ず高周波部分の取捨をやらかして、やらかした部分は剥離したようになりやすいです
 それのバランスがどの辺にあるのかとした回答になっていると思います。

 (つまり、なんだかなんだと、比率の法則を予測しないでやらかしては解を得られません)


> それにしても、BD規格外の要素を盛り込んでいるので
> 問答無用で、瞬間的にUSB2.0の帯域を凌駕しちまうソースがちらほらです


 ‥それ以前の話として、圧縮率はどうなのか?
 そこはまぁ当たり外れがある点に変わりはありません。
 当たりなら4割減で‥1080pなのにサーチキュルキュル状態に置き換えられます。

 (画質はきっと特異点でしょう)

 しかしながら、サーチキュルキュルを楽しむには
 4Kテレビに付いているUSB3.0の帯域が欠かせない雲行きです。(なんてこったい)

 (まぁ通常利用でも、イカしたカットをほとんどIフレームに置き換えちまうんで)
 (それはそれで、拾い出しにはもってこいでしょう)


> ‥ぶっちゃけ、特定則で追随品質エンコードしていくと
> 576pでも1536pでも1080pとそれほど差が無くなってしまっており
> メリットになるほどの差が無いともなれば、そりゃ時間コスト掛けても1080pって事でしょう
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 22:25 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月12日

【エンコード日記】キュルキュルサーチ虎の巻(速報版)

↓2)記稿.2020/05/12

> テレビUSB挿し視聴においてキュルキュルサーチは憧れだ(とくに逆転サーチ)
> サーチ機能はあれどもほとんど利かず‥ならば、そんな残念リップに用は無い


 ‥だが、単にキュルキュルサーチできれば良いというものではない
 一番に即決なのは参照枚数を1枚にして、Bフレームを無しにしてやる事だが
 それはそれで、ソースとの印象が随分と違ってしまうケースも予期される

 ここでは、動きの境の勉強も兼ねて
 キーフレーム単位での動きの境を的確に捉えた美麗にて鑑賞したいのである
 シーンの切り替えが正確にあれば十分としたデフォルトの意図など、とても許容できないのである
 (そういうお馬鹿な要望があっても決して不思議しくない)


> ところで、エンコーダーはきちんと動きの境を的確に捉えるのだろうか?
> 同じソースなんだから場面の検出箇所は常に同じだろうと思っていませんか?


 そりゃGOPの長さが変われば、それに沿うようにエンコーダーは処理を要求される
 結果、ヒトの側が何をどう思おうが、何食わぬ顔で
 とんでもないところをIフレームに選んじまっていたりする
 それは、GOPの長さばかりではない
 他の設定が同じでも、解像度を変えただけでもIフレームの位置ずれは起こり得る
 CRF値を変えるだけでも、細かい所では悩ましく移動しちゃっていたりするのだ
 ソースタイプ毎に、Bフレームを付ける付けない‥でも、かなり違う
 キーフレームの入りもよく、サイズ感にも満足しようと、静止画画質がダメダメだったりもある

 (そこが単にシーンの頭さえ捉えれば良しとしているデフォルトとの壮絶な違いだ)
 (美麗キュルキュルサーチは修羅の道だった‥とかなんとかほとほとにうんざりだった)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 12:58 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年05月08日

【エンコード日記】1080p以下なのにレベル5.2は必要か?

↓3)記稿.2020/05/08

> BD規格の上限はレベル4.1である
> つまり、1枚あたり8192枚、1秒あたり245,760枚のマクロブロックに制限される


 1920×1080を単純に16x16のドット数で割ると8100の区画に分解できる
 但し1080は割り切れないので、最下段の分を繰り上げすれば8160までの分解を必要とする
 つまり、1枚あたりに8x8のマクロブロックを追加する余地はほとんど無い

 一方で、使用できる秒間での枚数は
 24枚(195,840)、30枚(244,800)だから、ちょいオーバー程度だ

 これでは、16x16のブロックしか使われていないと断言しても差し支えないだろう
 では、どうして8x8のブロックがBフレームまで使えるようになっているのだろう?
 (とても不思議で止まぬ疑問を点し続けざるを得ない)


> なので、唯一8x8のブロックが働くのは、24フレームの場合だけで有り
> 放送用の30フレームにおいて利用するには、横幅を1440に縮めて利用できている内訳だろう


 (それにしたって、1枚あたりの制限にそぐわない‥どうなっているのか?)

 ‥そこで曲者なのが、インターレース時のマクロブロックの使われ方になる
 単純に縦幅を半分にして使うと考えれば
 その分、IとPに8x8のマクロブロックを利用できる余地がでる‥
 それでもBフレームでの8x8はPフレームからのコピーに置かれるのが大抵だろう
 新規に8x8ブロックを割り当てできる余地があるとはとても思えない

 なので

 基本的には、同じマクロブロックを利用する仕組みをフル回転させていると思って良い
 (その分をカウントから外してると考えるのが自然だろう)
 それの強化版が、参照フレームMix利用ということになる


 ‥ところが不思議なことに
 レベルに付随するプリセットやらの設定度合いを確認すると
 参照フレームMix利用をデフォルトにしているのはより低いレベルでの扱いだ
 (これではプリセットの狙いやら機能推奨での意味がわかりづらい)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 13:02 | Comment(0) | 春嶺到夏 | 更新情報をチェックする