【超解像】Lada part4

590です。
モデル強化は全然まだなんすけど、2080Ti→4080Superの効果だけでもjasna的にデカい所と思った所をご報告

両者のベンチマークはググると以下の通り
https://technical.city/ja/video/GeForce-RTX-2080-Ti-vs-GeForce-RTX-4080-SUPER
この数値では2倍までは行ってないのだけど、実際にjasnaを走らせた体感はめっちゃ早くて、
換装前がほぼ動画時間位→換装後は動画時間の半分か40％くらい（ざっくり45％）
つまり、時間当たりの出来高は１÷45％＝2.22倍＝222％→�@
寝る前に仕込んで走らせて、朝起きた時の出来高が2倍以上、これはまあまあビックリする

一方の消費電力は、換装前350W→換装後450Wくらい（ざっくり130％→�A）
つまり、動画1本あたりの処理にかかる電気代は、電気代÷出来高＝�A÷�@＝130÷222＝58％

おそらく、おれんちの電気代のうちjasnaに食わせてるのは9000円くらい
同じ本数の処理に留めれば、節約できる電気代は9000円×58％＝5220円
今回の中古4080Superの落札価格は約160000円、これを節約電気代で割ると 160000÷5200＝30.7か月＝2.6年

・・・・ということで、省エネ投資案件としてはイマイチだけど、時短案件としてはアリかと。(´Д`)

電気代の計算めっちゃ間違えました。電気代節約分は100％-58％＝42％で、節約できる電気代は9000円×42％＝3780円、
投資額÷節電額＝160000÷3780＝48.8か月

というわけで、省エネ投資案件としては全然アカンです。謹んで訂正の上お詫び申し上げます。orz

plを50%にしたら

そもそもエロはエコじゃない

それで、0.5.xと0.6.x-alphaはどちらがえぇんや…

stream機能を使いたかったら0.6.0-alpha5一択
後は処理時間と仕上がりのトレードオフじゃないかな
0.5.xの仕上がりに文句がないなら処理は速いに越した事はないよね

LADA、JASNAアプリ削除しようと思ったら、フォルダーごとゴミ箱ポイで問題ない？

lada-ex+cu130nightly(Ubuntu)が俺環でちゃんと動作する構成に辿り着いた気がしたからlada-exとzelefans+jasna0.5.1(Windows)とVR動画メインで比較検証中。
今のところ、lada-exの復元品質はconf: floatやtrack_buffer他の値を調整してzelefans+jasnaの画質にかなり近付いたけどArtifactが若干多い。しかしtensorrt、vsr、torchcodecなどオプションてんこ盛りでの処理速度は4K60FPSのfisheyeタイプVR動画の場合にlada-exでは41fps、zelefans+jasnaでは17fpsと大差が付いた。
jasnaの処理の部分のみ着目すると片目で95fps位出てるもののfisheye変換で80fpsに復元で40fps位の速度になるからトータルでは遅くなるようだ。
また、8KのVR動画検証はまだ途中なもののlada-exでVRAM24.7GB超えてたから1分位の細切れ動画にしないとVRAM16GBクラスのGPUだとフルオプション処理できないかもしれない。

うちはzelefans jasna０．６がまだうまくいってない
lada-exは動いたけどｖｒは速度の前に質の面でまだまだだな

VRは一つ一つの処理ごとに高解像度のエンコードがあるから
速度が出ないのはどうしようもないかなあ

当然だが、VRは一時ファイルのビットレートを落とせば、作成・読み込み共に高速になるけど、最終結果の品質も落ちることになる
ただ、どうせまたやり直すことになるだろうから、今回の所は落としておいてさっさと済ませるという考え方もできる

あと、個人的には30fpsに落としても全然問題ないと思っていて分割の際に落としているが、これをしておくだけでスピードアップとなる
また、いまだにOculus Goを使っている友人に渡す時は、8KVRだと見ることができないので分割の際に4KVRに落としている
こちらは、面積が1/4になることから、かなりのスピードアップとなるし容量も減る

うろ覚えで間違っている可能性大だが、オ◯ニー1回は50m走と同じエネルギーらしい。そのエネルギーを発電に変換できれば地球温暖化は防げるらしい。どうやって変換するかは別問題だがw

>>619
はいライン越え

30fpsの動画はLosslessScalingで60fps再生したほうがかなり良いと思うから
60fpsの動画を30fps化して平気とか信じられないわ

TVAIで120fpsまで上げてみたことあるけど60fpsと差が良くわからなかった。

>>622
それじゃ、基本24fpsの映画なんで見てられないってこと？

映画やアニメは絶対フレームレート弄らないし
ゲームも最悪30fpsで問題なく遊べるけど
実写のエロだけはフレーム補完してでも60fps以上にしないと気が済まない自分みたいなのもいる

>>623
最近4K180Hzのディスプレイ買ったからTVAIで4K24fps→4K120fpsに変換して再生してみたけどヌルヌルで笑った。

本家Windows版のIntel Arcバージョン使ってる人、調子いいですか？
今Nvidiaバージョン使ってるけど調子良ければIntel Arc買ってみようと思ってます

SFとかマーベルとかの実写ヒーローものを60Fps化すると、途端にコスプレした痛い人達になるのは何でなんだろう？

VR対応についてはばらつきが大きくてまだ当面は過渡期なのでとりあえず３０ｆｐｓでもいいよ　どうせまた同じのをやり直すから

VR物は女優の演技力次第だからなぁ・・・
もうちょっとバリエーションが欲しい。
男優の主観じゃなくてもいいのよ。

まんまと騙されたよ
alpha-5＋rfdetr-v5がいいというから使っていたけど、一瞬モザイクが残ることがあった
理由がわからなかったが、某サイトのサンプルをキャプチャーしたものを使ってみたらはっきりとわかった
たった3分のサンプルで、シーンが切り替わってから終わるまでずっと処理がされないシーンが2か所あった
しかも、画面半分の巨大藻なので閾値などは当然無関係だし、v2/v4/ladaでは問題なく処理される
要するに、rfdetr-v5の顔モザ無視の判断が甘くて、ま〇こを顔だと間違えてるわけだ
顔モザ無視なんてどうでもいいことのために肝心の部分の処理が抜けるなんて、もう絶対にrfdetr-v5は使わん
rfdetr-v5使って処理したのはチェックして藻残りが起きてるやつはやり直しじゃ

俺は逆にlada-yolo-v4使っててモザ残りが頻発してrfdetr-v5に変えた。結局相性なんかな。

>>632
それで、rfdetr-v5に変えて、藻残りは発生しなくなったの？

他の例ではrfdetr-v5でstream再生していると、藻が一瞬出ることが2回あった動画も他の検出モデルでは全く出なかったこともあるし、
どれを使っても一瞬出てしまう動画もあったので、どれを使っても出るやつに顔に勘違いしてのモザ無視が加わってしまうのだと思うが

ナスの動画でははっきりlada-yolo-v4のほうがいいってわかるけどそれじゃダメなんかねｗ？

>>633
オレ環では発生しなくなったよ。

yolo-v4はモザイク検出は良くない、v2_accurateに入れ替えてからは不満ない
rfdetr-v5はv2_accurateで取りこぼすモザイクを検出できる事がある、遅いし常用はしなけど

jasna-guiを使っているけど、検出しきい値を調整すれば、モザ残りって少なくならないですかね…
個人的にはあまり差は感じないので、lada-yolo-v4使って速度重視にしてます。
ただ、処理が早過ぎる為か、時々PCフリーズしてしまうのが…

yolo-v4はボロボロ取りこぼす、>>2の手順でv2_accurateに替えてみればはっきり改善される
検出しきい値いじるのはその後

torchcodec公式がようやくWindows版のCUDA対応wheel(0.13.0)をリリースしたんで
早速Windows版lada-exに組み込んで最速パスを動かしてみたら処理動画に謎のマゼンタアーティファクトが発生する・・・
俺環？と思ったけどGPU違う2台で同じ現象が出たので、どこかに問題がある
せっかく組み込みが楽になったのに、これじゃ使い物にならん

簡単なところからエンコードオプションに-b 0入れてみたらどうかな？

rfdetr-v5がま〇こを顔と認識したということは、逆に言うと顔がま〇こそっくりな人がいるということだろうか
本当にそんな人がいたら、マスクは真の意味での顔パンツということになり、しないと猥褻物陳列でタイーホだな

>>640
サンクス　原因は割と意外だった
--live-preview機能を使って処理映像を見ながら地道に切り分けたらnvvsrとtorchcodecの組み合わせ問題でした
lada-exで使っているnvvsr(cu12系)と今回組み込んだtorchcodec(cu13系)が同名のバージョン違いDLL(nppicc64)をvenvの中に持っていて
torchcodecがcu12のDLLを先に読み込む処理になっていたもんだから不整合が起きて色情報を破壊していたっぽい
RTX VSR側のDLLをtorchcodec側のDLLで上書きする回避策で直った

また学習失敗した
GANの学習で一気に不安定になる

jasnaってGPUスケジューリングONのまま使っても問題ないのだろうか
OFFだとゲームでDLSS FG使えないから切り替えるの面倒なんだよね

>>644
jasna動かしたら処理動画がカクカクします→GPUスケジューリングがONでした
というテンプレやり取りがよくあったけど、おま環でその問題が出ないなら大丈夫じゃね
って、0.5.1と0.6.0-alpha5はSystem CheckでGPUスケジューリングを確認してたっけ

>>645
だめだったわ
ONにすると仰る通りカクカクで解析部分がズレてた
面倒だけど再起動するしかないか

全然アップデートがないな、Jasna
さっさと正式リリース版出してくれねーかな

>>647

作者が転職して忙しみたい。

更新は続けると言ってたから
気長に待て。

jasna使おうとしたらエラー出たが、文字化けしてて、どういうエラーなのか全くわからん。先週やった時は問題なかったのにな。
フォルダごと削除して、プログラムを解凍し直したら動いたけど、何が原因だったのか。

jasna-cliのmodel_weightsフォルダ参照問題を改良するパッチを作った
v0.6.0-alpha5へのパッチとWindows版のビルド手順書を置いたので興味がある人は試してみて
jasnaが組み込んでいるパッケージのライセンス回りが良くわからんので
ビルドしたものを配布するのは止めておく

<注>
Windowsでしか試してないです
わからないところはAIに聞くなりして、基本自分で何とかできる人向けです
パッチや手順書に間違いがあったらゴメン

<今のjasna挙動>
--detection-model-path / --restoration-model-path のデフォルトが jasna-cli.exe と
同じフォルダ内の model_weights\ 相対パス
jasna-cli を PATH に通して任意フォルダから実行すると、コマンドを実行したフォルダの中の
model_weights\ を探して FileNotFoundError

<改良版>
以下優先順でmodel_weights\フォルダを探す
1. 環境変数 JASNA_MODEL_WEIGHTS_DIR で指定したフォルダ
2. jasna-cli.exe と同じフォルダの中の model_weights\
3. コマンドを実行したフォルダの中の model_weights\
4. jasna ソースの親フォルダの中の model_weights\ (uv pip install -e . でソースから動かす人向け)

ttps://13.gigafile.nu/0902-ce3ed12899d6afbe880bd397d559ff2a0
ダウンロードパス：jasn

jasnaのRTX SR UltraとTVAIのiris2をgrid playerで見比べてるけど全く違いが分からん

TVAIが一番効くのはahq12だと思う。GUIでは選択できないが、cliで--tvai-model ahq-12 --tvai-scale 4を指定してみればRSRよりシャープなのが分かる

破解にRSR、破解後の全体仕上げにTVAIの
Starlight Precise2.5を使う俺のようなやつは
少数派なのかな？

そんな使い方してたらGPUはすぐサヨナラされて星になってしまう。

sbsのVRでfisheyeオンしても□が傾く件だが、2つのパターン（またはその複合）を確認した
いずれも、fisheye変換前の片目部分の左右にあるカマボコのサイズを調べる
1.カマボコの左右の横サイズ（厚さ）が異なる場合
　画面左右の中心部分にあるモザは縦がまっすぐになるはずが斜めに傾くことになる
　この場合は、fisheye変換時に視線を横向きに振ってやる必要がある
2.カマボコの画面左右端の縦サイズが普通のものと違う（普通より大きい）
　上下角（v_fov）はデフォルトでは180度だが、モザ処理後hequirectに変換する際にそれを小さくしたと思われる
　この場合は、元の値を探し出し、それを使ってfisheye変換しないと元に戻らない

>>654
今は数分の動画だけの処理が現実的。
NVIDIA3080tiで、1～2時間ものの動画はさすがにやってられない。

h264を100%とすると、hevcなら約50%、av1なら約30%程度のビットレートで同じ程度の画質が得られると聞いてVRの最終ファイルをav1_nvencにしてエンコしてみた
処理時間は、hevc_nvencの時と変わらなかった
しかし、うちのQuest2では、VR再生アプリにはav1対応と書かれていたが、ハードウェアの方が対応していないらしく、8kVRはもちろん4kVRのav1すら再生できなかった

まあav1対応してんのはquest3だからな…3sはどうだっけ

650だがClaude Opus 4.8がリリースされたんでJasnaのLinux版のビルドガイドを頼んだらさくっと作ってくれた
俺環で次まで検証完了:
・vali / PyNvVideoCodec / jasna のソースビルド
・凍結バイナリ生成（dist_linux/jasna/jasna、GUI＋CLI 兼用）
・GUI 全ダイアログ表示、RTX Super Res、lada-yolo / RF-DETR 検出、実動画の復元処理

試したい人がいたら以下からゲットして
ガイド
・ttps://github.com/sh202603/jasna/blob/docs/docs/BUILDING_WINDOWS_ja.md

パッチ (Linux環境固有のパッチが一つ増えた)
・ttps://github.com/sh202603/jasna/blob/docs/patches/build-and-runtime-improvements.patch
・ttps://github.com/sh202603/jasna/blob/docs/patches/fix_linux_gui_and_rtx_vsr.patch

Linux版のガイドはこっちだった
・ttps://github.com/sh202603/jasna/blob/docs/docs/BUILDING_LINUX_ja.md

俺は正式リリース版のLinux版を待つわ

>>661
了解。興味ある人だけチャレンジしてみて

Max 5xのサブスク期限が来る前に勢いで機能追加も頼んだらあっさりやってくれた
さすクロ
BT.601の動画10本位で軽くヒートラン回してWin/Linux両方で動作確認できてます

jasna の出力段を拡張した改造ブランチです
本体の GPU 完結パイプライン（NVDEC→復元→NVENC）はそのまま、エンコード出力の自由度を上げてます
■変更点
　AV1出力対応（--codec av1、ファイル出力のみ）
　8bit(NV12)出力＋ビット深度選択（--bit-depth auto/8/10、既定はソース連動）
　色空間を保持（BT.601 / BT.709 / BT.2020 を入力から維持してタグ付け）
　出力コンテナは拡張子で選択（.mkv / .mp4、AV1-in-MP4も可）
　torch 2.12 / CUDA 13 スタックで再ビルド
■検証
　Win/Linux両方でCLI ＋ GUI 連続処理 ＋ 凍結バイナリ（PyInstaller）動作確認済
　HEVC 8/10bit・BT.601/2020・AV1(8/10bit)・--bit-depth両方向の実機検証済
■公開先
　ttps://github.com/sh202603/jasna （branch: feature/av1-nv12-colorspace）
■詳細
　 docs/CODECS_AND_COLORSPACE_ja.md ／ 変更点: docs/CHANGES_vs_upstream_ja.md

元動画の都度BT.709への変換は面倒だね。

>>663
バッチでバッチリやろ

662です
jasna v0.6.0系で入ったexperimental blendingの性能デグレ原因もわかっちゃったんで
昨日連絡した版(feature/av1-nv12-colorspace)に処理速度の改善を入れときました
クローン済みの人は取り込んどくのがおすすめです

ブレンドマスク生成の畳み込みの計算(2次元blurフィルタ)を素直にK×Kでやっていたのを分離化(一次元フィルタの計算×2回)に変えた
こうすると計算量がO(K^2)→O(2K)に減るのでデグレ分はほぼ解消
実測(同じ1080pのクリップ、31524 フレーム、凍結バイナリ)：処理時間がだいたい3〜4割短縮
- Windows 7:37 → 5:13
- Linux 6:26 → 4:00
出力も変わりません(差はエンコーダの実行ごとのゆらぎ由来) 画質も挙動も変化なしです
対策版コミット：e92dccc

#本家にも報告しておいた

>>662
すみません
これの使用方法を具体的におしえてください

>>666
興味を持ってくれてありがとう
以下リンクにビルドガイドを公開しているからこれを見ながら自分で
jasna-cliとjasna-guiを作るという使い方です
わからないところはAIに聞いて解決するスタイルでお願いします
ttps://github.com/sh202603/jasna/blob/feature/av1-nv12-colorspace/docs/BUILDING_WINDOWS_ja.md

このガイド自体もClaude CodeでOpusに書いてもらってます
各手順の実行→確認はさむとか、途中自分が詰まった所をトラシューとしてまとめるとか
結構くどい位な内容になってます

個人的な実験ブランチなのでバイナリパッケージ公開の予定は無いっす
そのうち本家が対応してくれるかも？

本家のLADAは全然更新されないな

662です
ビルトインのフレーム生成機能をとりあえず追加した (--frame-gen 2x/4x)
中身はRIFE補間で、元の尺・音声はそのままfpsだけ倍にする
(モニタがしょぼいので4xは試してない)
ファイル出力のみ対応
手順とスクリプトは置いといたので重みは自分で用意してね
modiブランチに入れてある

ただ最適化はまだ
1080p(30fps, 31524 フレーム)でざっくり実測（Linux / lada-yolo-v4 + rtx-super-res 4x ultra）:

　frame-gen none (4:00) vs frame-gen 2x (26:40)

全解像度のRIFEをエンコードと同じスレッドで回してるだけなんで
ベースが速いほど補間がモロに効いてガクッと落ちる模様
TRT化とか専用スレッド分離は今後の課題
あと frame-gen 2xにするとrtx-super-res の ultra はVRAM 8GBだと普通にきつい

まあ「とりあえず動く版」です

Jasna の正式リリースまだかよ
夏になっちまうじゃねーか
冬なら暖房機がわりになったのに

GANの学習むずすぎ！何度も失敗してる

https://ja.unifab.ai/video-refiner-ai.htm
>UniFab 高精細復元AI（ローカル版）
>AIを使ってブロッキーアーティファクトを除去し、映像の詳細を復元します。

今までのように一度クラウドに投げる必要が無くなったみたいだけど
はたしてこれは使い物になるのでしょうか。

興味ない

>>665
ubuntu 26.04 にドキュメント通りにコピペのみでインストールできました。ありがとう。
ただ一点、レポジトリ設定の影響か不明だが
python3.14がインストールされるのでこれを3.13に変更する必要があった。

>>672
試用してみたが検出精度が悪すぎてLADA/JASNAと比べるのが失礼なレベル
復元部分の品質は悪くないのとVRAM使用量が少なく処理速度が速いことが救いとは言える

少なくともこのスレの住民の皆様が料金を支払う価値は全く無い

>>674
インストール報告あざます
助かりました原因わかりました
Ubuntu 26.04 って既定の python3 が 3.14 なんですよね
ガイドがそれを想定してなくて、3.14 だと vali / PyNvVideoCodec と
torch cu130 wheel が噛み合わず動きません
なので 3.13 に変えたのは正解です
modi ブランチに対策入れときました
指摘ありがとう、地味に大事なやつでした

Linux jasnaで処理動画カクカク現象に遭遇したら
CUDA_LAUNCH_BLOCKING=1 を先頭につけてjasnaを実行してください
処理速度落ちるけど現状の回避策

Linux jasnaの処理動画カクカク問題を対策したら
WindowsでGPUスケジューリングをONにした時のカクカク問題もかなり改善された
テスト動画で見た限りはWindowsとLinuxが同等の仕上がりになった
が、この問題は完全には解決できないようなので、品質を求めるならGPUスケジューリングOFF
(LinuxならCUDA_LAUNCH_BLOCKING=1)は必須

jasna v0.6.0系でGPUスケジューリングをONにしてても
最初のシステムチェックで弾かれるのと最後の合成をずれないように出来ないのかね

>>679
GUIのシステムチェックはソースを直さないとガードが外れない感じだね
CLIはffmpeg/ffprobe/mkvmergeのバージョン番号しか見てないからGPUスケジューリングがONでも動く
が、Claude Codeに調べてもらったところjasna v0.6.0系の動画処理パイプラインは問題を抱えていて
GPU処理の順番待ちができていない所があり、まだ処理中のデータを別の処理が読んだり上書きすることがある
同じ動画でも実行ごとに微妙に中身が変わり、検出位置が不安定になっているようだ(これがカクカクになる原因)
頑張って問題箇所2つ見つけて9割がたの処理はうまくいくところまできたが、完全解決は至っていない
GPUスケジューリングをOFF(LinuxだとCUDA_LAUNCH_BLOCKING=1)にするとこのGPU処理の順番待ち問題が出なくなるのできれいに処理できる

>>680
詳しい解説をありがとう
暫くは再起動しながらやっていきます

jasna v0.6.0で音ズレする原因がわかるかたおられますか？

jasnaの作者さん活動再開したっぽい

jasna v0.6.1、システムチェックは通るけどファイル読ませて実行しようとするとといきなりプログラムごと落ちる

jasna v0.6.1変更点を勝手に解説

＜重要事項＞
Torchスタックが更新されたのでエンジンファイルの使い回し(コピー)不可
以前のバージョンでコンパイルされたエンジンファイルがあったら消すこと

＜変更点＞
9fdfda2 NVIDIA ドライバ要件を 580+ に緩和 (#117)
02b7a91 frozen バイナリ時に jasna-cliがある場所のmodel_weightsディレクトリを見に行く >>650 の作者さん対策版
94a4222 PATH に無い nvidia-smi を一般的なインストール先から探索
23f93f7 GPU適用の .cube カラーLUT対応（CLI/GUI、#142）− 新機能
5879815 unet simplification（unet4x_secondary_restorer を簡素化）
f4b57d7 separable conv（blending）>>665 の対策が本家に入った 作者さんのGPUだと4kの効果が顕著
903b005 fp16/fp32 fixes（restorer/crop_buffer 周りの dtype 整理）
37d2098 update pytorch（torch 2.12 化）>>662 の内容と一緒
ce239ab bt601 support（HEVC VUI 書き換え＋BT.601 経路）>>662 の内容の一部を作者さんが実装
45abf01 stream sync（video_decoder.py）→ d346efc で 即 Revert（=v0.6.1）
d2029a2 mute warnings（_suppress_noise.py、torch/tensorrt の起動時警告抑制）

＜特記事項＞
・Linux版バイナリ配布は今回もなし
・カクカク問題は作者さんもまだ格闘中 (45abf01入れたが即リバート)
　なので、Windowws/Linux設定でのGPUスケジューリング対策は継続必要

>>665
すごいな

0.5.0からどう変わったかおせーてください

githuのログくらい確認しようぜ
VRAM使用量が減って速度が上がった感じか
特に4K

Jasnaの話がよく分からず、開発途中だから手を出さずに読み流してるんだけど
結局、Jasnaって本家Ladaと比べてどういう機能が便利でみんな使ってるのん？

俺は処理の速さとRTX Super ResによるSecondary Restoration機能 (Lada-EXもそうだが)

本家は線ががたがたになるときあるけどそれが起きない

pt/pthファイル差し替えてlada-yolo-v4で再コンパイルしてみたがonnxでエラーが出たわ

>>689

>>589

>>692
v0.6.1のソース確認したが、jasna.specファイルにyolo系のエンジンビルドに必要なパッケージ(”onnx", "onnxslim", "onnxruntime")が定義されてないから
このspecファイルを使って凍結バイナリを作っていたらyolo系はコンパイル通らないな

作者はrfdetr推しだと思うし、仕様か不良かグレー

lada-yoloが使えないと処理が遅くてしょうがない

>>690
>>693
ありがとう。どっちかつーとモザイク検出力よりも処理速度重視なのね

v0.6.1　進化あったのかな･･･？あまり変化を感じなかったが

>>697
v0.6.1の修正内容は性能デグレ対策、バグ対、BT.601対応、model_weightsの読み方改善など
細々したものが多いが作者が更新再開したことに意義があるんじゃね
今後に期待

>>680 の続き
残っていたカクカクはvaliのデコーダをcuvid → nvdec に変えることで解消できた
従来の cuvid だと動画の先読み処理がGPU計算とぶつかり、これが元で表示のズレが起きていたようだ
これを nvdec 経路を作って切り替えたら順番どおりに安定して処理できるようになりズレが解消
Windows/Linux側の設定でGPUスケジューリング対策をしなくても俺環ではカクカクが出なくなった！

なお、この方式は vali の修正と再ビルド・再インストールが必要

作者に報告したいが、現在githubのアカウントがシャドバン中・・・
金曜に+modiブランチの方に中華ニキがLinuxカクカク問題のイシューを報告してきたので
そのやり取りしていたら無邪気にNSFWな動画のBefore/Afterリンクを貼り付けてきた
すぐ消すように伝えて消してくれたけどgithubの監視に引っ掛かった模様

申し立てしたけど、いつ直ることやら

v0.6.1のソース確認したが、lada-yolo-v4で再コンパイルしてみたがonnxでエラーが出た
どうすればいいでしょうか？

試してみたけど、コンパイル済みエンジンがコピー不可で、しかもyoloはコンパイルできない
どうやら締め出しのようなのでαに戻しました

yolo不可か、見送りだな

ストリーミング再生とシーク時の反応が良くなっているのでストリーミング再生時だけv0.6.1を使おうかと思ったけど、
しばらく再生していると、映像と音声がかなりずれてしまっていた
元動画によるのだろうか？

yolo-v4より標準のrfdetr-v5の方が性能高いから無理してyolo-v4を使う必要ないぞ

jasna v6.0.2が出た
更新早いな
・カクカク問題(たぶん)解決
　Windows/Linux側の設定でGPUスケジューリング対策不要に
・yoloモデル対応(onnxは入れ忘れだったみたい)

>>704
別のyoloモデルに差し替えて使いたい層がいる
検出モデルは好みもあるので良し悪し議論は荒れる

>>705
0.6.2は他の（旧）バージョンと共存できるのですかね？

>>705
すまない。6.0.2です。

お、Linux版 0.6.2 が出たな、Jasna

zelefsnsと組み合わせているがjasnaの処理の部分は0.6.0alpha5から比べて10倍位速くなってる。

>>706
凍結バイナリを別のフォルダに展開すれば別バージョンとも共存出来る
但し、v6.0.1でtorchスタックが更新されたので以前のバージョンからエンジンファイルをコピるのはNG
また、GUIの設定ファイルは%APPDATA%配下に保存されるから、これは前のバージョンと共有される
別バージョンで設定を更新したらその内容が新しいほうにも伝搬するので注意

>>705
やっぱりonnxは入れ忘れだったんですか…　昨日苦労して諦めましたが、元々問題あったとは。
今度入れ替えてみよう…

こんだけやる気出してくれたならtodoのVRサポートも期待できるな
ここでやり方共有してくれる人いたけどワイにはハードル高かったから

検出モデル　v2_accurateはリネームして使えるのでしょうか？

>>713
>2 のやり方が使える
>4 のやり方で lada_mosaic_detection_model_v2.pt にリネームすると lada-yolo-v2 で選択可能になる
(v4_fastと共存できて、選べるモデルが3つになる)

カレントフォルダ問題だけど、jasna-cli0.6.2（0.6.1も同じ）で初回コンパイルがある時、カレントドライブにexe本体がある時は正常に動作するけど、別ドライブだとエラーする
コンパイル済みの場合は、別ドライブにあっても正常に動作する
まだまだ修正が甘いな

ここに書いても作者見てないから
改善して欲しいならgithubで報告して

0.6.0alphaで普通に完走するファイルが0.6.2だと途中エラーが出て未完になるな
仕上がりに違いは無いからalphaのが良い

おま環だろ、それ

>>714
ありがとうございます。無事出来ました。稼働も問題ないです。
後、細かい設定ですが、二次修復などはどれがベストでしょうか。自分は全てULTRAにしています。

v0.6.2を起動しようとしたら、マカフィーに隔離された。今までのバージョンでは起きたことなかったんだけどな。

jasna v0.6.2 でカクカク問題が本当に解消したのを確認
1080p, 31524フレームの動画を同条件で2回処理 → 検出結果が完全一致(処理毎の非決定性ゼロ)
LinuxとWindows(GPUスケジューリングON ＝一番症状が出やすい条件)の両方で確認できた
これで性能デグレとカクカク問題の両方解決！

>>714
好みによるから自分が良いと思ったものがベスト

0.6.2の検知モデルrfdetrでエラー、yoloは完走
21:58:56 PM ERROR [primary] thread crashed
Traceback (most recent call last):
File "jasna\pipeline_threads.py", line 171, in primary_restore_loop
File "jasna\restorer\restoration_pipeline.py", line 101, in prepare_and_run_primary
File "jasna\restorer\basicvsrpp_mosaic_restorer.py", line 70, in raw_process
File "torch\nn\modules\module.py", line 1778, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)

>>722
ちょうど横でClaude Codeで作業してたんで聞いてみた
砕けた感じの回答↓

それ検知(rfdetr)のバグじゃないっす。落ちてんのは一次復元のBasicVSR++のほう。
ログ末尾が raw_process → self.model(...) なんで、rfdetrは引き金なだけ。

rfdetrとyoloで差が出るのはたぶんVRAM。rfdetrは検出多め＆768pxの常駐エンジンで重いから、
yoloより先に足りなくなるパターンかと。crop準備は通ってるしshapeは正常っぽいんで、
CUDA OOMくさいです。

ただ貼ってくれたログ、_call_implの直後で切れてて肝心のエラー文が見えないんよね。
もしよければ
・その下の続き(RuntimeError: CUDA out of memory…みたいなやつ)
・GPUとVRAM
貼ってもらえればもっとわかるかも。

>>722
rfdetrは性能が高いから小さすぎるモザイクも検出しちゃう
小さすぎるモザイクだとBasicVSR++でエラーが起きる
しきい値を少し大きくすれば消える
って上の方に書かれてたやつだろ、それ

>>723
ログ出力してなかったから改めて試行、0.6.2、rfdetr-v5

05:11:19 AM ERROR [blend-encode] thread crashed
Traceback (most recent call last):
File "jasna\pipeline_threads.py", line 301, in blend_encode_loop
File "jasna\pipeline_threads.py", line 90, in decode_detect_loop
File "jasna\pipeline_processing.py", line 129, in process_frame_batch
File "jasna\mosaic\rfdetr.py", line 131, in __call__
File "jasna\mosaic\rfdetr.py", line 85, in _preprocess
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 380.00 MiB. GPU 0 has a total capacity of 8.00 GiB of which 0 bytes is free. Of the allocated memory 712.48 MiB is allocated by PyTorch, and 453.52 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://docs.pytorch.org/docs/stable/notes/cuda.html#optimizing-memory-usage-with-pytorch-cuda-alloc-conf)

NVIDIA GeForce RTX-4060 Laptop GPU 8.00GB
GeForce 591.4 WHQL DCH-[r591_66]

>>725
CUDA out of memory って出ているからClaude Codeの見立てて合ってる
回避策は環境変数 PYTORCH_CUDA_ALLOC_CONF=expandable_segments を設定する
そうするとCUDAエラーを回避できる可能性がある (できない場合もある)

それでもだめなら >>724 指摘の通り検出しきい値を少し大きくする

処理設定次第だけど、rfdter+Secondary Restorationとか使っているなら
経験的にVRAM 8GBだと1080p解像度でRTX Super Res x4, Quality ultraとかは荷が重い

検出モデルや除去モデル変わらなきゃ大して変化ない？
いまだV0.5.0alpha10

>>727
仕上がりに差はないよな？

まだ数本しかやってないが、v0.5.0アルファ10と仕上がりと時間は同じ程度じゃないかな。

jasna v0.6.2ではWindowsのGPUスケジューリングONで処理してもカクカクしなくなるが、元々OFFで使っていたら仕上がりは変わらないな
ゲームやる人がいちいちリブートしなくて良くなるメリットはある
性能デグレは使っているGPUと処理動画の解像度により効果が変わると思う
>>709
みたいなケースもある

v0.5.0-alpha10からだと性能デグレが直っただけか
v0.6系でブレンディングの仕方が変わっているからその辺は仕上がりに影響あるかも

>>726
rfdetrは検出しきい値0.95まで上げてもエラー、1.00にすると完走、復元未処理ファイルが出力された
yoloは検出しきい値0.10でv2v4共に完走
0.6.2のrfdetrはおれ環で使用不可という事で、新しいの出たら再度試してみる

yolo後に更にrfdetrをするとより鮮明になる気がするが気のせいかな？

もう２D対応の基本性能は完成に近いだろ
VRはまだずいぶん取りこぼしがあって興ざめ

>>732
俺環のWindowsデスクトップのRTX4060だと1080pの動画でもrfdetr-v5+RTX Super Res 4x, quality ultraは完走した
デスクトップ向けとノートPC向けの4060はそんなに性能違わないみたいだが、なんだろね
メインメモリの容量とか関係するのか？
あとできそうなのは、Max Clip Sizeをデフォルトの90で使っているなら60に下げてみるとか
初回にBasicVSR++のコンパイルがもう一度走るけど使用するVRAM量は減るはず

>>732
お前だけの特殊ケースだ
そもそも問題だらけの GeForce 591.44ドライバーを使っているのが悪い

zelefansさんの別プロジェクト？CUDA特化版
https://github.com/zerochocobo/VR-Video-Toolbox-CE