【超解像】Lada part3

**名無しさん＠お腹いっぱい。** · 2026/01/07(水) 14:46:33.37

前スレ
【超解像】 Lada　part2
https://mercury.bbspink.com/test/read.cgi/avideo/1761381502/

【超解像】 Lada　
https://mercury.bbspink.com/test/read.cgi/avideo/1758433407/

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 18:42:17.75

VRAMが一杯になったりエラーが起きるようなら減らした方がいい
そうじゃない場合は値を上げてもできた動画が対して変わらんならデフォルトの180でいいやろ

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 19:57:08.27

最適値は自分で探さんと意味がない
短く切り出した動画で試せばいいだろう

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 21:20:16.81

フレーム数の指定。30fpsの動画ならデフォだと6秒ぶんか
この値変えたことないが、大きくすると何かいい事ある?

Maximum number of frames for restoration. Higher values improve temporal stability. Lower values reduce memory footprint. If set too low flickering could appear

復元処理で使用する最大フレーム数。値を大きくすると時間方向の安定性が向上します.小さくするとメモリ使用量を抑えられますが、低すぎるとちらつきが発生する可能性があります

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 21:23:36.99

うん、GUIにもそれ書いてあるけど、時間的安定性ってなんやねんっていう

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 21:40:54.08

読んでそのまま、時間軸の一貫性をどのくらい先まで考慮するかって事じゃね？
短くすると前後の繋がりの悪いフレームが出やすくなって、それがチラついて見えると

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 22:28:59.57

一番破壊したい部分抜き出した15秒位のテストピース作って条件振って試せばいいだけやないかい

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 22:41:55.00

知ってる人がいるんなら聞いた方が早いけど
知ってる人はいないんだよ

**名無しさん＠お腹いっぱい。** · 2026/01/21(水) 22:48:49.91

何でもタイパで人に聞いて済ませようとしたり、自分の感覚より他人と合ってる方を優先する点にZ世代を感じる俺は老害

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 04:01:01.61

BasicVSR系は何フレームか一度に読み込んでピクセルの移動を追跡しながらフレーム間が滑らかに繋がるように復元してく
これが小さいとピクセルの移動の追跡が細かく途切れるからチラついたり色味が安定しなかったりする

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 05:40:53.42

前スレにも書いたけど要はclipを長くすると読み込みフレーム量(時間)が長くなる
ladaは読み込んだフレーム内で前後が破綻しないようにするから一定アングルのシーンに関しては長めの方が安定するとも言える
ただアングル変更や場面転換を巻き込みやすくなるから位置ズレや取りこぼしの発生が増えるかもしれない
clipを少なくつまり短くすれば長い時のデメリットは解消するけど長いシーンでデモザの結果が安定しなかったり外れたりチラつくようになるかもしれない

というわけでデフォルトから長くするも短くするもメリデメがあって大して良し悪しはない
自分で1シーン切り出して処理するなら長めでもいいと思うけど一作品丸ごとの時はデフォルトでいいんじゃない
プレビューの時は短めの方が読み込み早いかもね
ただ短いclipの時は読み込み->gpu処理のサイクルが頻繁になるのでgpu使用率は高めになるかな

VRAM消費量は動画解像度×フレーム数(clipの値)で計算出来るけどもぶっちゃけ動画数秒数分なんて大したサイズじゃないのでVRAM8GBあれば1000だろうが10000だろうが問題ないしグラボによって最適値なんてもんはない
(もちろん4kだの8kだのVRだのサイズが大きければ消費量は大きくなるがアホみたいなclipサイズにするメリットは皆無なので考慮しない)

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 09:21:29.23

ありがとうございます
めちゃくちゃ早口で言ってそう

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 09:31:57.21

馬の耳に念仏

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 10:05:05.96

>>220-221
完全に理解した！ありがとう
180のままにします

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 10:06:08.81

>>221-222だったすまん

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 16:18:17.45

Jasnaはどうなんだろうか

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 19:07:32.09

ladaapp氏はrfdetr.onnxをv5として求めるかな～
プライド高そうな気もするし厳しいか

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 21:29:54.05

Jasna試してみた
確かにGPUの負荷は常に100％近辺に張り付くが、出来た動画は時折モザ部分のバウンディングボックスが真っ黒く残ったりとか、破壊は発展途上か
仕上がりは試した動画だとボケ気味なのが気になった
処理速度は俺環だとむしろLadaより遅い
VLCで再生するとリサイズに追随しないのには困った

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 22:50:23.46

あかん、性能が低いのかVRの破壊はかなりの確率で途中でフリーズすんな
8Kなんて確実にフリーズする
終盤まで行ってのフリーズは時間の無駄で辛いわ😭

**名無しさん＠お腹いっぱい。** · 2026/01/22(木) 23:41:23.24

まだ、lada試してないから外してたらごめんだけど。
複数ファイルに分割して全部通ったら結合したら良いんじゃない？
パンツ脱ぐまでのモザイクいシーンはかけなくて良いし。

**名無しさん＠お腹いっぱい。** · 2026/01/23(金) 00:09:04.97

それだとエンコード揃わなくて結合時に全体の再エンコードが必要になる可能性大だから処理不要な部分のファイルも変換しておいて、結合時に-c copyで走らせた方が結果的に早くなる場合がある。やる前に要計算だね。8kのエンコードは時間かかるから。