民立布悦へのVision

　「10万円給付、貯金に回った」

＞　今やマイナンバー名目で、電子マネー利用を仕向けているのは政府です
＞　電子マネー利用でサクッとネットを介してチャージするには、銀行に入れておくのが筋です
＞　ここにおいて電子マネーはタンス預金と同義になります


　さらに経済が停滞して給与を相殺されているコロナ禍状況に置いて
　経済の規模が横ばいぼちぼちなら、電子マネー利用枠での推移まで同じなら
　給付金の効果が相殺されて見えたとしても、貯金とは限りません
（持ってる人まで無理に使う必要は無いからです、マイペースでしか減らないでしょう）

　なので、給付金が無かったらそれだけ落ち込んでいるはずです

　それの動きのすべては

　電子マネーで移動するだけになるので、どう見たって経済効果として有ったように見えてこない
　つまり、数値の見方を誤っているだけになっちまいます


＞　麻生太郎の「給付金は貯金に」発言は
＞　時代感覚錯誤、政策経過予想錯誤の「何言ってんのあんた」状態です


　貯金前提になるのが、そもそもの電子マネー利用推進の結果です
　と言っても、電子マネーを積極的に活用している層を三分の一
　困り果ててる側の層が三分の一
　どっちつかずでとりあえず銀行振り込みのまんまが三分の一だと仮定すると
　まぁそこそこ半分は預金に回るだろうが妥当な推測でしょう


　ならば生活補助としては、そこそこに成立したと解釈しても良さげでしょう


　‥日本の実力なら、それぐらいに持ち堪えられるからそれぐらいだろうね‥
　とした考えもどこ吹く風で、貯金になるからもうやらねぇ空気くさいのは
　どこか確信犯ぽくって頂けない口調かと

　（いくらなんでも、もう少し分析に聡いところを見せるべき）

　‥取り扱うソースはBDts（アニメ）になります
　BDtsアニメのBD.709を如何に保持して576ｐダウンコンバートをやらかすか
　という悩ましい問題解決としての技になります


＞　まずAviUtlで、BT.709指定で入力と出力をやります
＞　次に解像度576でBMPだしをやらかします（すると量子化がほどけて美麗ドット画になります）
＞　それを今度は、BT.601指定で入力と出力をやります
＞　それをUt Video（BT.601，420‥422）で出力します（この時点でドット画から量子化に劣化する）
＞　得られたファイルをXMedia RecodeでBT.601指定でエンコードします（圧縮劣化する）


　（※記事の内容はUtVideo420ですが、422出しの方が色みが安定します）
　（444はなぜか不能です‥というかVLCからして封印してある空気っぽ‥謎）

　‥ポイントは、BMP出しをやらかすと
　AviUtlでのベストなドット画状態で出力が得られるという点です
　これを動画ファイルに変換する際に量子化劣化します（16ｘ16などの格子化状態の発生）

　ところが、BMPなら、色規格をスルーできるのです

　実写はその辺どうか知りませんけど、創作画ともなれば
　誰が原画を見て、これはBT.601ですね、BT.709ですねなどと振り分けできるでしょうや
　そこを思えば、BMPに出して再読み込みすれば、その色が‥の色だったなんて関係ないんです
　読み込ませる段階で、変換の際の解釈が発生するだけのことです


＞　というわけで、BT.601になりすまして再度読み込ませれば良いんです


　BT.601解釈なら
　AviUtlの内部変換で劣化することもなく、格子化状態にそのままの色を受け渡せます
　受け渡すと言っても、最終的なエンコードを終えるまで
　色々とした色の変転を得ているかも知れませんが、無事に辿り着くようです
↓/続きを読む/↓

　‥デフォルトで
　ＩフレームはＰフレームの×1.4のかさ増しがされ
　ＢフレームはＰフレームの÷1.3の間引きがされる

　そしてこの比率を確かにするには、時間軸間引きをシャットアウトすることが条件になる
　そうで無い場合、Ｂフレームの比率は変動的に扱われる

　（もっとも平均ビットレート方式の場合、時間軸間引きを使用するとかえって増量するっぽ）


＞　ビットレートの最大と平均との適切さを導くのにこれが使えるのでは？
＞　そこで、1.4＋1.3＝2.7つまり27に対しての黄金比を割り振れば良いのでは？


　（そう思ってやってみた）

　黄金比：1.6180339887
　27÷黄金比＝16.68691769676173

　つまり、Ｐの画質を平均ビットレートでの品質に見立てた場合
　Ｂフレームよりの方が裾野が広いのだから、得るべき黄金比ポイントは逆になる

　27−16.68691769676173＝10.31308230323827

∴　最大ビットレート量を1.31308230323827倍程度よりぷち多めに丸めた値が適当に思われる
　（Ｉフレーム品質よりにＰフレームの平均を寄せないとＢフレームも怪しくなる為）


　※　ＤＶＤとＢＤの規格を参考にした場合
　最大と平均の比率はそれよりもたいてい少ない、結果的に
　演出効果としての不足や不十分の発生を指摘せざるを得ない
　（これは著生の感覚だが、ＦＨＤモニターからの観察が不可の環境なのでその辺は未知を含む）


＞　では、平均ビットレートをいくつにすれば良いのだろうか？
＞　当然それは、静止画画質において、ＭＡＸ綺麗なポイントが得られて然るべきである


　それらはなぜか、解像度バイト数を2.25で割った数になる
　但し、ＤＶＤだけは比率が異なる事から３で割った数が適切になるらしい（増量は確実）

　‥語るまでもないが
　ＦＨＤサイズでの指定は指定不可能の値を得てしまうので例外とせざるを得ない

　ＨＤサイズ用の割り出し平均値でも
　FHDにおいては、ほぼ踏襲的に代用できるようだが、最大値は未だ闇の中だった
　（特に、ＢＤtsの1080iの場合においては、1080解像度での細部の再現度やら容量が悩ましい）
↓/続きを読む/↓

＞　もう一度よく見たら、Bitrate Viewerの表記がkbbsだった？？？


　‥不可解しいだろう、テレビのUSBメモリー帯域の振り切れが起きるのは
　Bitrate Viewerのそれからは、明らかに600000の辺りだ
　どうみたって、そうでしかないのだから、それはb/sに思われる
　（USB2.0の最大帯域は480Mbps＝600000×８）
　Bitrate Viewerの表記の方が誤っているとしか思えない


＞　‥ということで
＞　bbsをどうして1000で割って、b/sを1024で割るのかの謎が解けた


　文系のオーナーつまり多くの資本家からすると、カネ勘定と同じやり方の方が判りやすい
　その点、ビットの数え方はそのままに点の量でしかないから十進数でええやろうという話になった

　さらに、そこを隠すかのように、見た目格好の付く単位を付けた

　（そうとしか思えない）

　理系の技術者は、最初こそ戸惑ったが伝送量の宣伝に都合が良い事に気が付いた
　同じ帯域を利用する上で、倍のビット量に値する符号を伝送できれば
　二倍の圧縮率を語っても問題が無い

　だがしかし、二倍の伝送量と二倍の圧縮率の見出しは
　同じようでいて、実はかなり怪しい

　なぜなら、実際のファイルサイズが半分に成る成らないに縛られる事なく
　規格においての正しいやり方においてだけ
　二倍のビット換算での符合量を伝送できればそれで良いからだ
　これには、それを可能とする為の技術的な細かいところは伏せてしまっても構わない都合がある

　（どちらかというと、伏せておきたいのが本音）
　（現場ではできていても、素人がやるとそうには成しがたい）


＞　其を思い込ませる為の話術として


　‥１ｋサイズ、２ｋサイズ、４ｋサイズを持ち出した
　実際の計算はどう考えたって、どこか曖昧だ

　どうしたって、はだかの王様の論法だし
　１０００と１０２４の判りづらさのままを引きずっている

　だが其を押し通せば、二倍の圧縮率云々思い込ませる事ができるとかなんとか‥

---

＞　実際のところＡＶＣの実力は、ＨＤとＦＨＤの中間程度
＞　見た目でＦＨＤの方が綺麗だったからその塩梅を調整してできているように見せている

---

　無論、商業的な流れの都合を満たしているなら、それ以上をツッコんでも意味が無い
　（だが、そのツケは、精度を得たい大衆と文化に勘違いを巻き起こす）


　‥伝送量として二倍に成っても
　必ずしも、すべてのケースで其を担保する程では無い

　デジタル映像技術のすべては予測なのだから
　宣伝言葉にしたって、半分はその範疇でしかない（そう思って構えるべきである）


＞　ＨＥＶＣにしてもＦＨＤと4ｋの中間程度だろう
＞　ＶＶＣになってようやく４ｋでの圧縮率に期待を持てる程度に思われる


　どうしてプチ背伸びしてまで過剰宣伝に、慌ただしいのかが実に謎
　技術的に放送用の伝送量が二倍を達しえても
　売り言葉に買い言葉で、どうにも都合のまずい部分があるからとしか言いようがない

　（技術競争のやらかしでもあるから、まぁそれはそれだろうけど）

＞　ダウンコンバートすれば、基本的に、色潰れもテクスチャー潰れも発生します
＞　でも、静止画を抜き出して参考に
＞　万遍なく均一になる具合比を探り当てれば、画質は格段にUPするっす
＞　（平均ビットレートが多ければ多いほど良いという話では無い）


　‥ところがこれをやると、うんざりするほど圧縮率が上がらない
　それこそ制作の品質って感じで、ＨＤＤが何台あっても足りなくなりそうだから
　再リップするのがアホらしくなる

　（だがしかし、興味は尽きない）

　そこで[1024ｘ576]と[768ｘ576]のそこん所を探ってみた
　そしたら、BT.601（SMPTE-170M）を指定すると
　最大ビットレートと平均ビットレートの項目で、最大値25000に制限される
　（指定無しだと、その境をまたいで指定できる）

　‥つまりなんだ

　例の三点盛りを、付ける付けないとした意見の根本が
　この「250000bbs」を境に色規格の理解が変わっちまうから
　そこんところは機械に任せて、考えない事にしようって
　煮え切らない派が、口をごもごもさせて付けないにしてきた‥なーんて‥（訝しげ）

　‥つまりなんだ

　ちまたに転がる、アニメ一話あたり1.5GB程度でよろしく1080ｐリップの多くは
　ビットレート割り当てに置ける色みの都合適には
　BT.709とBT.601をまたいじまってるって中身に相違ないのだろう

　（CRF値でやってるとそこを曖昧にできる‥まさにBlackBOXで思考停止）
　（品質規格だから色みだけは担保してあるのかも知れないが‥謎‥またがり前提くさッ）
　（BT.709とBT.601の混合再生ありきって事かも‥謎‥）


＞　結局、DVDの領域で色の解釈が止まっているのが世間の空気らしい
＞　そんなこっちゃ「ＨＤＲすげー」の日常風景なんざまだまだ１０年先の話だな


　‥新しい圧縮方式で２倍の‥謳い文句にしたって、そのそもそもは
　テレビ業界の都合にあるＨＤレベル放送帯域で
　ＦＨＤをやらかしたい、４Ｋをやらかしたい、８Ｋをやらかしたい
　という無茶に基づいているので、なんだかんだで放送用のファイルサイズは横ばいに思われる

　つまり、使用する解像度が倍になったと言うだけのオチで
　誰もが期待する従来のファイルを半分に削り込めるとした解釈とはわけがちがう


　‥例えば、解像度比４倍になりました
　ファイルサイズは1.5倍で収まります
　圧縮比効率の実質は、1.333333333333333倍です
　計算すると、従来比想定２倍の圧縮率を得ました（チーン）

　（まぁそんな勘定をやらかしているのが実態に思われる）
　（UHD規格のそれを思うと、例えのそれでも期待しすぎかも知れない）


＞　‥そして


　其を実現せしめる為に、スムージング・パワーが強化されちゃってるので
　従来ソースを再リップする場合、気をつけないと要素が削られやすいというオチだったりする

　（いやぁまったく‥もう‥）

　‥なんだかんだと細部を維持しようとすればするほど
　圧縮率はさして上がらないと思っていた方が間違いがない（ンゴ）

　‥だがしかし、不足してそうな場面目当ての補強用にビットレートを追加してみると
　そこだけは改善しちゃったりするのが実に悩ましい（くそったれが‥）

　（制作サイドなら、そりゃ、場面毎にちぎってエンコードしてあとで繋げれば良い）ご苦労様です

　‥XMedia Recodeの打ち込みは（k？）バイトｂｂｓ単位でした‥（どうもすんませんm(_ _)m）
　↓こちらのバイト計算は、そのまんまになります

（MediaInfoで確認するとbbs表記になってる？？？‥kb/sとb/sとbbs‥？？？）
（さらにツッコむなら、XMedia Recodeの方のbbsは、一桁目を端折ってる）
（あれれ？‥ということで記事の表記が間違っている？？？）
（でもまぁ上手く仕上がるから、そこは気にしなくて良いか‥）

（Bitrate Viewerで確認しているのは、バイト単位？？？）
（1000000b/sとか600000b/sとか8倍すると600000b/s＝4800000bbsで合ってる）

　‥ということなので
　記事内の表記は、数値はそのまま単位だけ脳内置き換えしてください‥m(_ _)m

　（勘違いが編みだした数値ということですん‥まぁよくやらかすことである‥）


＞　1920×1080×3×24÷1024＝145800
＞　1280×720×3×24÷1024＝64800


　　145800÷64800＝2.25
　　64800÷2.25＝28800
　　28800×1.5＝43200

　　28800÷1.125＝25600


＞　説明すると、25600kb/s0bbsは1280ｘ720p用です
＞　28800kb/s0bbsが1920ｘ1080p用の平均ビットレート値です
＞　43200kb/s0bbsを、共通とした最大ビットレート値とします


　（但しこれは1920×1080プログレッシブソースBDtsにのみ使えるっぽ）

　‥4ｘ4のマクロブロックを効かせる為にLevel6.0にして確認すると
　ほぼテクスチャーパターンを潰さない状況に、サクッと到達したのですが
　720ｐでさえ、VLCプレイヤー側で格子欠け？格子落ち？を連発する始末なので
　4ｘ4のマクロブロックを全撤去して、Level5.1で試してみたところ

　この状況でもテクスチャーパターンを恐ろしいほどに乱さずに20％程度を削り取る‥（アニメ）

　例えるなら、鉄筋を20％ほど巧妙に引っこ抜いてビルもとい画を構成する感じ
　（実際には多少なりとも劣化しているのだが、どうにも判らない程度に収まるできばえ）


　‥んですが、今度はなんかこう動きで見ていると画が違う感じで
　仕方がないので、Level4.1にして8ｘ8のマクロブロックを全撤去して
　16ｘ16のマクロブロックだけにしてみても
　テクスチャーパターンが崩れてないし、こちらの方が画が落ち着いているので

　‥怒濤の16ｘ16マクロブロック主義にどはまりに堕ちましたとさ‥

　（あそれ、1920ｘ1080ｐでも1280ｘ720ｐでもイケます）
　（恐ろしい事に720ｘ480ｐ[43200÷6＝7200]でも‥アレって言うぐらいに落ち着いているし‥）
　（BT.601に落としているのに、規格解像度だとそれほどに色変動しないっぽ）


＞　調子に乗ってインターレースソースでもイケちゃうかなぁとやり出したら
＞　再び切りがなくなって‥凹んでいる最中です‥OTL


　ちなみに、720ｐで出しても1.15倍程度の差にしかなりません
　この辺が平均ビットレートの利点でもあり、うんざりな点でもあるわけです
　（ビットレートの量×時間が前提でして、解像度は概ね見映えでの判断のみと考えて良い）

　業界がHDサイズを蹴って、FHDサイズに切り替えるのに異論など有るわけが無かったのでーす
　でも、エンコード時間は倍違います

　（なので4ｘ4のマクロブロックどころか8ｘ8のマクロブロックも怪しい扱いだった）
　（だって、時短で16ｘ16で十分だったらそうなるっしょ）


　‥こういうオチになるとは‥（してやられた、もとい、してやっちまったって感じ）

＞　理論値Level6にしてみたところ、ＢＤtsソースの静止画画質の正確さがアップした
＞　さらに、GOP（8）が最強だった
＞　720ｐの最高ポイントは、25600kb/s0bbs（平均ビットレート）に達する


（どうやら単位を誤っていた‥XMedia Recodeの打ち込みはbbs単位でした‥すまん）

　‥マクロブロック数制限によるすり合わせ要素が失せた分、速度向上
　‥テレビUSBに挿せば、最高滑らかプリンになるっす
　‥マムシにも動じなくなる傾向が良さげです
　（強制的に固定タイムスタンプ‥なんちゃらは必須らしい‥音飛びに強くなるっぽ）


＞　≒30フレームまでの場合
＞　480iはレベル5.1、解像度720と1080はレベル6.0でないとマクロブロックが不足します


　（P4ｘ4使用時：partitions all）

　基本的にマクロブロックが使用できる理論値最大数で足りていると
　不足しがちなマクロブロック数で、涙ぐましいやり繰りをしなきゃならない計算を省けて
　ちゃちゃっとした割り算だけになるので計算が単純化します

　さらに平均ビットレートならではの合理化で
　それがＩだろうとｂだろうとＰだろうと、ＧＯＰ毎、秒単位ごとのビットレート割り振りが
　限定して決まってしまっていれば、必要なビットレートを複雑に間引き計算する事無く
　マクロブロック数で割るだけです

　（見映えが悪ければ、再度平均ビットレートをやり繰りする設定をすりゃ良いだけです）

　それこそ平均的にビットレートを
　マクロブロック単位に割り振ってくれるので、複雑な計算やら難しい判断に悩む必要が無い

　それこそ、サイズと時間が同じなら、割り振られるビットレート量はどれもほぼ同じ
　違うのは、内部的な多寡による自動調整分の増減だけ


　（なんでこんな簡単な数学的視点からの説明を誰もしていないんだおう‥）


　それこそ平均的に、ＩもｂもＰもその数の割合に関係なく、秒間で同じに割り振っちまうんだから
　あとはどれだけ、マクロブロックを使い回せるかって方向で、間引きをやらせれば良い

　（なので平均FPS値がほぼ一定になる傾向を見せる）


＞　ところが、肝心のＶＬＣプレイヤーでの再生時に格子乱れが‥それとなく生ずるハメに‥
＞　（レベル6以上頻度を想定していない模様）


　‥どうにもＶＬＣプレイヤー側のバッファが貧弱らしい
　ということは、テレビの方がバッファをふんだんに盛ってあるらしい（これは意外）
　（造り込みとしては、スーパーハイビジョン互換以上の想定だったって事になるらしい）

　さすが日本のお家芸テレビジョン、ちんけなＰＣプレイヤーを上回っていたでやんす♪

　映像再生専用装置なんだから、負けてたら立場無いっすからね
　（但し、ここの色はどうしても違うwwwってのは、USB挿しでは極希にあります）

＞　BDの一般的な画像部のビットレート最大値は40.0 Mbbsである
＞　これをDVDソースにもそのままに盛ってみた（平均は9600）
＞　ソースにびんちょうタンを選んだ


　‥まずＧＯＰ（5）とＧＯＰ（7）の差だが
　ＧＯＰ（5）はＤＶＤ向きで、ＧＯＰ（7）はＢＤ向きだった
　そうしないとＤＶＤにありがちなパンのカク付きがすっきりとしない

　（カク付きの問題はさらにビットレート量の不足も絡んでいた）

　デジタルアニメに用いられるようになった
　フェードぼかしによる前後のピント交換表現法だが
　その手の場面の効きの弱さもビットレート不足が絡んでいた

　（テスト不足で、こちらもＧＯＰ（7）に適性があるかはまだハッキリとしないが）
　（BDソースからしてもその傾向があるのだからGOPが長すぎても弱いのは明らかだ）

　そして、あのいやんなシミに関しては、ＧＯＰ（7）の方が良いらしい

　（やはり多少は距離を持たせないとシミが濃くでちまうらしい）
　（どうしようもない選択になったｚ）


＞　‥特にびんちょうタンのようなデジタルアニメ（ＤＶＤ）の場合
＞　とくにフワッとした印象が特徴のそれは
＞　インターレースが目立たないのも合わせて、ビットレート不足に因んだ効果だった


　‥単純に16：9を詰め込んであるのだから
　不都合が好都合になっていたというオチらしい（じゃ、デジタル放送も同じだな）
　なので、逆に同じく一般的なインターレースが目立たなくて綺麗に見える程度の画質に

　多量のビットレートを割り振ると途端に風合いが崩れる（どぎつい）


（つまり４ｋ放送はプログレッシブの選択にせざるを得なくなったと）
（でないとコストカットのアップコンバートが無理になる）


　見ていてその色みの怪しさが気になるのと同時に
　インターレース特有のエッジがサーチに顔を出す（やはりインターレースだったとした印象）

　‥ところが‥

　ダイナミックモードだと色みはそこまで気にならない
　一方のスタンダードモードだとやはりその手の変化が気になる
　（モード差はやはりでるので確認すべきである）


＞　それにしてもその色合いはBT.709の規格に沿えば適切な風合いになりそうな気はする
＞　だがそれはテレビUSB挿しにおいてサーチ要素を捨てるか
＞　アップコンバート＆プログレッシブ化を意味する
＞　試してみる価値はあるにしろ、関心はむしろAVCでの適切なBT.601でのビットレート量だ


　‥なぜか不思議と平均ビットレート量指定を無視して
　最大ビットレート量指定の方を優先しているっぽい

（今のところＤＶＤなら最大は平均の1.6倍程度で良いと思っていたがやや不足らしい）

　一方で、刻まれているのは反対に平均ビットレートの方が優先らしい

　断定的判定はしがたいが、色定義の想定内に収めるには
　定義された解像度だけではなく、適切なビットレート量も重要と言う事らしい

　（HDR化が上手く行かないと思ったらそういう事かも知れない‥）
　（4ｋサイズだしBT.2020だからと、HDRになったはずと思うのは早計らしい）


＞　ならば、720ｐにおいても色定義としての風合いを確かにするには
＞　適切なビットレート量が求められることになる


　‥おっとその前に1080ｐか
　SD並のビットレートでのFHDサイズなどBT.709として怪しいと言わざるを得ない
　ということなのだろう

　（その程度の認識でHDRなどと推し量れるわけが無い）

　‥で720ｐを色定義の堺にしているというのがまた味噌で
　720ｐの色の鮮やかさが最高に出るポイントより下ともなると
　1080ｐとしては論外の品質程度ということになる

　大体それは、平均ビットレートだと２０４８０ぐらいらしい
　参考：XMedia Recodeにて、BT.601設定すると最大25000に制限される

　（当然最大ビットレート値は、BDと同じにすべきが筋だろう）
　（それが色規格の範囲とした理解になる）
↓/続きを読む/↓

＞　GOPを（5）から（7）にすると、サーチの具合がさらによろしくなる（M=3,N=6）
＞　でも（M=3,N=6）と入力すると（M=4,N=5）にされちまうのでご注意


　‥だがしかし
　普通に思い込んでいると、ファイル容量が微減するはずと思うところだが大間違い
　（M=3）にガッチリとハマりきるソースもあるのでご注意！


＞　‥さて、ここまで読まれた方の多くは
＞　「肝心のビットレート容量は如何ほど‥」と思われているに違いない


　それは著生が答えずとも、たいていのソースにはその手の情報が刻印されている
　つまり、業界のルールに従えばはじめからくりそつにできるって事だった


＞　‥だからだろう
＞　無料アプリでそこまではお断りとばかりのラスボスが登場した


　すべてのそれのリップのスタート数秒間のどこかに、高負荷情報が追加される仕組みらしい
　（XMedia Recodeにおいては、BD：1000000b/s、DVD：300000b/sを超える場合もある）


　‥これはつまり、「焼かせねーから」とした警告と受けとるべき内容だ
　（チープなUSB2.0のUSBメモリーだとDVDからのそれとて引っ掛かる）
　（ＨＤサイズにしても、600000b/sを超えちまうソースもありありだ）


　‥ハード的にクリアーすりゃ良いだけなら４Ｋテレビに挿せば良い話だが
　引っ付いちゃってるイヤンな虫は付いたままというのがすっきりしない

　なら、市販のプロ用ツールでなら問題無さそうではあるが、どうなっているかなど知らん


＞　じゃ、ペガシス買うか？（はぁ~悩ますぃ）
＞　じゃ、ペガシス買うか？（はぁ~悩ますぃ）
＞　じゃ、ペガシス買うか？（はぁ~悩ますぃ）


　‥ＶＶＣ対応版やら対応グラボやらと考えていくと
　ペガシス６だけ買っても何だかなぁと思わざるを得ず

（ちんけに切り抜け手法をやらかすにも作業用ドライブが必須な上に手間になるのでやる気しねぇ）

　‥ＶＶＣ対応版のペガシス８を待ったって、価格はお高いに決まってる
　（そしてそれはWindows１０でしか起動しないとか何とか）


　‥待ってる間に視聴を済ましてしまった方が、ＨＤＤの更新に予算を振れる（そういうオチだ）
　‥どちらかというと、マイクロ波アシスト磁気記録方式ＨＤＤ待ちっすから（保管が大前提）
　‥ところがこれのドライブの扱いできる規格というのがきっとやって来る（そういうオチだろう）
　‥なら、ほいそれと別の事に集中しちまうと使わなくなるアプリに掛けるカネなんかねぇ
　（少なくとも二号機エンコード専用マシンこそが先手で必須だ、現状無理ッ）

　動画エンコードにおいて、平均ビットレートと聞くと
　圧縮率を気にする者からすると、「できれば2passで‥」を指すのだろう

　しかし、ここでのエンコードは、むしろ１ｐａｓｓのみを前提とする
　なぜなら、テレビUSB挿しをする為の目的が、テレビについてるサーチ機能の活用だからだ
　サーチをキュルキュルと機能させる為の割り当てがすでに圧縮率効率云々から遠ざかっている

　ならば、１ｐａｓｓで良しとしよう

　それでなくても、平均ビットレートの利点を最大限に得る為にも１passの方が良い

　その利点とは、DVDやBD規格に沿わせて収録したソースの状態と言う奴は
　とくにDVDにおいては、泣く泣く割り振りの不足がちな場面発生が避けられない
　その結果、特定場面だけボケていたり、カクついたりとしがちである

　‥そのような場合、平均ビットレート方式であったなら‥

　平均ビットレート値を上げるだけで
　他の場面の増量を避けつつ、狙った場面だけの増量のみを狙えるのだ
　さらに最大値を上げれば、全体的に不足していたなら、全体での品質の足しにできる
　‥とした使い分けのできる仕組みだった

　但し盛りすぎはてきめんだ（フィルムグレインなど‥あっという間にどぎつさが際立つ事になる）
　その辺の塩梅が妙実に現れることこそ、平均ビットレートの本質だった
　業務用途での利便性を理解するなら、圧倒的に、平均ビットレート（1pass）が有利にある


　‥ということで技術的な欲求に掻き立てられるのも、この平均ビットレート方式由来だったりする
　なぜなら、ビットレートをそれ以上に割り振っても画質の向上にならないとしたら
　残された選択肢は、もはや解像度UPということになる

　アップコンバートを許容帯域内で継続的に可能とする為にも
　対応する上位規格の登場が欠かせない

　NHK発の懲りない探究心は、そんな現場ながらの好奇心だった事だろう

　（１６Ｋ映像への挑戦とか、ほんと半端ねぇ‥）


＞　だが、業務用でさえ手の出しづらい機器開発に、なんの意味がある？
＞　そんなの‥根回しのねぇ政治や対話無き政治と同じなんだってばさ


（つまり、ＮＨＫによる税金泥棒化の見られ方をされてもやむなしの空気充満だった）
（ＢＤに取って代わられちまった放送画質最高神話の崩壊は、庶民に対する裏切りだった）
（たとえるなら、まったく出玉のでないパチンコ屋と同じ）

　‥４ｋ・８ｋ放送開始と言ったって
　実態は、スーパーハイビジョン放送を略したくさいハイビジョン放送だった流れだから
　詐欺商法この上ないもとい過大広告だったこの上ないのだから‥（知れば知るほどお粗末だった）

　（基礎技術は素晴らしくとも運用の劣化はものすげー）
↓/続きを読む/↓