2020年06月15日

【エンコード日記】ぶれ駒ゼロ作戦を「北の国から」に試してみた件

記稿.2020/06/15

> まず、AviUtlの「自動」でインターレース解除を試みたところ
> OPテロップが残念な事になった


 ‥仕方がないので、色々と切り替えてみたら「自動24フレーム」で上手く行っている
 「自動24フレーム」なのに、どうにも30フレームのままだ‥(なぜ?)

 (他にも差が無いかチェックしてみたところ‥AviUtlのインターレース解除には)
 (XMedia Recodeで機能していた自動的解除能力は存在しない)
 (それはそのままに、AviUtlでの解像度変更時の性能比を意味する)
 (使用領域を32ビット仕様に制限される点は大きいはず)‥ここ重要‥


 ‥それをUtVideoで一度揚げしてまず確認
 インターレース解除したにも関わらず、やはりというか
 シャッター露光の関係で発生する速い動きぶれ現象はキッチリと存在していた
 それのぶれ度合いの感覚は
 XMedia Recodeにてダウンコンバート(自動的解除)してきたそれらと大して変わらない

 (とはいえ‥1080i→1080pだという点がまったく異なる‥「やったぜ」には間違いない‥)

 ‥最も気になっていた金属反射のジャギは、どうにも金属反射の露光でのぶれの形らしい
 金属反射のキラッとする感じを、色々と変換する過程でジャギとして抽出しちまうらしい
 フィルム映像のそれはもう解像度を上げる以外にどうしようもない感覚だ
 (それともFHDモニターなら違うのか???)


 ‥で、XMedia RecodeのUtVideoで720pで二度揚げしたところ
 ダウンコンバートしたにも関わらず、DVD一枚分に迫る勢いで増量した(なぜ?)

 (ちなみに、この段階ではまだ横幅のクロップを避けるべきに思う)
 (*縦のクロップはやらない方向でのきっちり4:3)


 ‥で、やな感じしかしないそれを三度揚げ
(Dサイズ、Bフレーム(4)、≒30フレーム、GOP(0.2秒)調整)
 の特別設定でキュルキュル仕上げにしてみたところ、予想通りに増量した

 余裕で全話4GB以内で行けると目処を立てていたのに
 全話4GB以内で行けるかどうかがギリギリ怪しい様相になってきた

 とはいえ、川の流れや森の中の奥行きなど‥さらにスッキリと仕上がっている(納得の出来)




> ちなみに、増量する傾向は
> プログレッシブアニメでも同じだ(XMedia RecodeのUtVideoで720p一度揚げあり)


 ‥だがそこでも不可解な現象が起きる
 抽出された一度揚げの映像を確認しても、画質が上がったとも下がったとも言えない状態になる
 つまり、BDの雰囲気から逸脱している部分が出ちまう傾向を否定できない

 ‥だがそれでもSサイズで仕上げると、なぜか画質が上がったように見えなくもない
 というより増量分は確実に上がっていると判定して好い感触だ(なぜ?)

 ‥おまけに、回想シーンやらでのUSB2.0の帯域超えを緩和するらしい
 (なので、やらないという手は無い‥なんとも悩ましい画質向上だろうか‥)


> それにしても、増量の度合いが想定外になるのはなぜだろうか?
> AQ強度が(1.0)だからにしても、一割は余裕で増えるって、どう考えも不可解だ
> (そこまで差が出るものだろうか?)


 ‥考えられることは
 一度で一気にサイズ変更して、そこに変換抽出されて対象となる映像の質と
 きっちりサイズ変更して、無劣化出しした映像の質との差だろう

 「そこには大きな差が発生していた」‥と言うことになる
 (その証拠に、キーフレームの入り具合が細かいところで違っている)


 ‥まぁアプリの都合絡みだったってやつだろうね
 アニメだとそれ程に思わないが
 実写だとXMedia RecodeでのUtVideo変換では、思ったより時間が掛かる
 そのぐらいの差が出てしまうと言うことらしい

 (エンコード時間は早い方が印象高いし、容量増えない方が良いのもそうだからな)


 ‥若しくは、内部で使われている変換より
 UtVideoの品質の方が一段上と言うことかも知れない

 (そういうことになると、解像度変更での二度揚げは必須にならざるを得ない)‥んご!


> ‥ならアニメの場合、CRFをその分程度上げてもテクスチャーは崩れないのか?
> (やれやれ、調べることが増えちゃったおう)



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

2020年06月13日

【インターレース解除】AviUtl×UtVideoでブレ駒ZERO作戦

↓6)記稿.2020/06/13

> ‥ペガシス買うか?
> 否、日用エンコードに掛けて良いコストは、HDDだけだろう
> (敷居は上げても、そこは守らんと誰も付いてこない)


 ‥ということで「AviUtl」に再び首を突っ込むことになりました
 はっきり言って、AviUtlの色の理解がようやくできたかも知れないレベルです

 とりあえず、今回の作戦は
 AviUtl×UtVideoでブレ駒ZERO一度揚げ(但し、多重撮り痕跡を例外とする)
 それの抽出された一度揚げリップをXMedia Recodeで仕上げるとする方向です

 なのでAviUtlの構成は最小限度有れば十分と云うことで、AviUtlのお復習いです


> まずは必要最低限度の調達です


AviUtlのお部屋
aviutl110.zip
exedit93rc1.zip
bmp_output.zip

UtVideo
バージョン 21.3.0(2020-04-18)

L-SMASH Works r940 release1


AviutlColor
https://drive.google.com/drive/folders/0BzA4dIFteM2dQjgwZkhtWUN6Zjg


> ぶっちゃけこれだけになります(なんと簡単)
> でもここからが初心者の第一の関門‥「自由にファイルを読み込ませられるまで」


 (が、しかし、そこはググって勉強しましょう)
 (端折って次に行きます)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 01:52 | Comment(0) | 春嶺到夏 | 更新情報をチェックする

2020年06月08日

【エンコード日記】VOB管理の細かい悶絶

記稿.2020/06/08

> DVDからデータを吸い出すと
> VOBファイルがお目見えするわけだが
> どうやって管理しておくかが実に悩ましい


 ‥まず、規定に沿ってISOの形式にしておくと
 内部で1GBに区切って管理される(これは規格に沿った強制らしい)


(それは、リップの際にいちいち結合させないとやりにくかったりする)


 ‥なら、結合した形で、VIDEO_TS(フォルダー)に収めておけば良い
 実はこれが落とし穴で、フォルダー名変更すると折角のチャプターが使えなくなる
 (基本は、英数字&記号の範囲のみで、日本語表記が使えない)

 どのように使えなくなるのかというと
 VIDEO_TS.IFOの情報が無視される


> ちなみに


 チャプターの位置は、必ずしもIフレームでは無いので
 チャプター頼りにぶった切りしちまっていると、音ズレしまくりになる
 (ファイルのあたま付きの方だけは助かるが、あとはもうボロボロ)

 なので、チャプター付きにこだわるメリットは、ソースの中身の確認用途のみ
 さくっとサーチできたほうがなにかと楽だったりする(まぁその程度)


> さらに


 VOBファイルのままにエンコードをやらかすと
 エンコードする際の総コマ数の表示が、おかしかったりする場合がある
 その辺、しっかり測りたければ、mkvに変換してしまった方が無難だったりする

 (完了予想時間がへんてこりんになる以外、エンコード自体の質に問題は発生しない)


> ならば、エンコードする際の一番に手軽な形式に‥
>(切らずにmkvに収めて、さらに、手前味噌でチャプターを振る‥MAX手間)


 ‥じゃそのまんま手を加えずにRに焼いておけば良い
 これが又落とし穴で、普段使わずに差しっぱにしておくと
 DVD機器の方が逝ってしまっていたりする
 つまり、Rに焼いて置いても肝心の機器がおシャカだと使い物にならない


 ‥じゃ内蔵しないでUSBタイプで
 これがどうにもソニータイマーな事態をやらかしてくれたりするらしい
 もとい、DVD機器の耐久が落ちているのは気象のせいかもしれない

 (管理気温が悪いとレンズが微に変形しちゃうとか)
 (レンズを固定している周りが歪むとか)
 (クリーニングすると多少削れたりするので復活する事も有るとか)
 (そげな案件が絡んでいそうで糞)

 (DVDならまだ良いけど、BDともなると手を出しにくい)
 (さらに上のUHDなんざ、どうにも目を背けざるを得ない)


> ‥結局、HDDに落として置いた方が頑丈だったりする


 理由は、施設内ともに軍事レベルでの使用に耐えうる強度を要求しているから
 DVD機器を戦場で利用すべきメリットなど万に一つも無い
 (部屋に置きっぱというだけなのに、それの差は歴然だ)

 (無論、管理悪いとHDDとて逝っちゃいますけどね)



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

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) | 春嶺到夏 | 更新情報をチェックする