【動画プレイヤー】JavPlayer【超解像】 Part.6
レス数が1000を超えています。これ以上書き込みはできません。
JavPlayerは、「動画の特定部位だけ超解像するアプリ」です。
AV鑑賞において、ディテールを損なわずにモザイクを目立たなくする動画プレイヤーとして使用できます。
このスレッドは、JavPlayer の使用法などについての質問や、より効果的な設定、効果が高い動画などについて、ディスカッションする場所です。
「モザイク破壊」などとして、著作権のある動画を「動画の特定部位だけ超解像」して、無断でアップロードすることは、犯罪です。
また、そのようにしてアップロードされている動画を、ダウンロードする事も犯罪です。
違法動画に誘導するリンクを貼ったり、違法行為を推奨する行為は厳禁です。
※前スレ
【動画プレイヤー】JavPlayer【超解像】 Part.5
https://mercury.bbspink.com/test/read.cgi/avideo/1665323989/
【動画プレイヤー】JavPlayer【超解像】 Part.4.1 {Part4がなぜか57で過去ログ入りしたので、Part4.1として新スレ作成}
https://mercury.bbspink.com/test/read.cgi/avideo/1655220450/
【動画プレイヤー】JavPlayer【超解像】 Part.4
https://mercury.bbspink.com/test/read.cgi/avideo/1654779343/
【動画プレイヤー】JavPlayer【超解像】 Part.3
https://mercury.bbspink.com/test/read.cgi/avideo/1646955938/ >>951
BVPPを3並列設定にするという事は
総VRAMから他のタスクで使う分を引いて、そこから少しマージン取って3で割った分を1処理に使うようにバッチファイルで設定するわけで
例えば12G積んでたとして6Gしか使えてないんであればバッチ処理の設定自体を詰め切れてないだけかと >>946
そもそも未だにソースを60fps化なんてしてるのが時代錯誤
フレーム補間も超解像もリアルタイムでできるんだからタイパ悪すぎる
素直に120Hz倍速ついてるテレビ買いな 3.3Gずつ割り振ってる
解像中の画面でも総VRAM9900MBとは出てる >>954
>>817-821当たりに似たような話題があった
ある程度マージンを取らないと2並列以上にならなかったり落ちたりする 問題無く3並列で動いてるし、落ちる事も無いです
4配列だと少し速くなるし、負荷が重たくもなりました
ただ、前の板あたりで4並列だとかえって遅くなると聞いていたのでベストな設定ではないのかな？と心配です
動かないとかでは無く、もっとグラボ、CPUの戦闘能力ギリギリまで使ってくれないかな？という感じです
VISIONモデルだから熱対策にはかなり強いんで発熱は低くても何となく分かるんですが、CPUも60%メモリも6Gくらいしか使用されて無い様なので
ちなみに書かれた安価のやり取りの後
>824で自己解決したのが私です
取り敢えず、グラボのGPUとメモリをOCもっとしてみます
2000くらいだと何も影響なさそうなので 一部訂正
問題無く3並列で動いてるし、落ちる事も無いです
4配列だと少し速くなるし、負荷が重たくもなりました
ただ、前の板あたりで4並列だとかえって遅くなると聞いていたのでベストな設定ではないのかな？と心配です
動かないとかでは無く、もっとグラボ、CPUの戦闘能力ギリギリまで使ってくれないかな？という感じです
VISIONモデルだから熱対策にはかなり強いんで発熱は低くても何となく分かるんですが、GPUも60%メモリも6Gくらいしか使用されて無い様なので
CPU自体も発熱50℃台で至って余裕が有りまくりなのが気になります
ちなみに書かれた安価のやり取りの後
>824で自己解決したのが私です
取り敢えず、グラボのGPUとメモリをOCもっとしてみます
2000くらいだと何も影響なさそうなので 3060使ってるけどTVtestでテレビ観たりネットしたりするから2並列までにしてるわ Safeの時のTG/raw*に入る連番画像の画質が劣化してるのを以前から気になってたからコードを解析してみて、MODで解決するには難しそうなので作者様にご相談です
Texture2D.EncodeToPNGで連番出力を行っているようですが、Unity上の動画では劣化とバンディングが発生しているため、そのまま連番画像も劣化してるんですよね
1passと2passの時も同様に劣化しているし、Unity上で映し出した動画から連番を作っているのが劣化の原因だと思います
作者のJavski2様に提案ですが、連番作成作業もFFmpegを使って処理するのはどうでしょうか？これなら画質が変わらないと考えられます
自分の場合、超解像処理フェーズの後、FFmpegで作成した連番をTG/raw*に入れてからエンコードすると元素材と全く変わらない画質になるからやっぱりこれが原因だと思うんですよね…… >>960
すみません検討違いなこと言ってしまった
Safeはffmpegで連番出力していました、申し訳ございません
Safe時にffmpeg_raw_argという名称のフィールド？を元に-ss 100 -i "myOriginalVideoPath" -ss 0 -start_number 0 -t 10.99999 -r 30 "J:/JavPlayer_200a/TG/rawBuffer/%06d.png"というコマンドをlogで出力されていたのが興味深いです
もし、この連番作成と思われるコマンドをユーザー側で変更できたらSafeの画質は修正できそう
ffmpeg_raw_arg.txtをffmpeg_enc_opt.txtと同じ要領でご用意いただければとてもありがたいです 全然VRAM使ってないじゃんってのは、インプットの画像の解像度が小さいとき。
超解像するときのinputの画像の解像度によってVRAMの使用量はかわると思うよ。
inputのフォルダ内の解像度を見てみれば様々な大きさがある。
大きいサイズはVRAM多用して速度も遅くなる。これはテコガンでも同じ。 インプット画像の解像度によって並列数が変化する仕様ではないとおもわれる。
単純にVRAM割り振ってるだけで、余りを活用しているとかないかと。
違うかな？？博士さん >>964
成程！確かに4kなどは使ってません
使っても2Kまででした >>965
並列数はアプリ、batchでユーザーが指定するから
博士に聞かなくても、そうなんじゃないですか？ >>965
TecoGANと違ってBVPPの場合は更に、intervalってのががあるよ
要するに、画像の解像度が小さい時は、その分たくさん画像をまとめて処理する アニメのモザイクをもうちょっと綺麗にできないんだろうか
元の色数の問題もあるから、モザイクとして認識されなかったり、変な凹凸ができた仕上がりになる作品が多い。
極端な話、チンコとかただの棒でも一切構わんのだが、難しいのかな
AIの導入でSTDで綺麗になるやつは、それなりにおおっと思うレベルにはなったけど
ダメな方が圧倒的に多い。BVPPAの先が欲しいなぁ 元絵が無ければならないのでは？
ほとんどモザイク柄を書いてるだけのような気がする REG6B&IMDNの追加超解像中にアプリが固まることが度々発生します
REG6BやIMDN単体だと問題ありません
VRAMやメインメモリは余裕がある状況です
固まった時はblendフォルダ見ると最後に生成したpngの一つ手前のpngが上下逆さの絵になってます
固まらずに成功するファイルも多いので、原因がよく分かりません それは現状バグと言うか仕様だと思って諦めるしかない SR-BVPPで並列ができていないようで困ってます。
SR-BVPPで無事超解像は完了して作品はできあがるのですが、
超解像部分にかなり時間がかかります。
TGMAINでは問題なしです。
（例えばTGMAINで30分程度なのにSR-BVPPだと4.5時間程度）
VRAM8Gなので、バッチファイルは
「VRAM_USAGE3600.set vram_total=8000.vram_usage=3600」に書き換えてます。
ファイルの書き換え箇所はこの3点だけで良いですよね？
バッチファイルの書き換え以外に他に必要なことはありましたでしょうか？ EZの1.04aが神アプデすぎて、もはや本家いらんってなってる すみません。RTX-2060Sです。
2時間ものだとトータルで、TGMAINなら4.5時間ほどですか、
SR-BVPPなら10数時間以上余裕でかかります。
そんなもんでしょうかね？ 3060だけどそれぐらいかかるよ
2時間だと半日から1日コース JavPlayer以外が使うメモリ量を極端に減らしてるとCUDAのメモリ確保エラーが出てリトライして時間がかかるってことがあった >>977
3060でもそんなにかかるんですか？
SR-BVPPは遅いですね。
コンソールもTGMAINは並列分出てくるんですが、
SR-BVPPのときは一つしか出ないので並列できてないのかなと思ってました。 >>973
そのバッチの値で行く場合は、JavPlayerで
超解像に使用するGPUのVRAM容量＝8GB
超解像ツール以外が使用するVRAM容量＝800MB以下。にする必要がある >>980
その数値の設定はバッチファイルの中でしょうか？
本体tecoGANの中の「超解像ツール以外が〜」の項目は500MBに設定しているんですが。 >>973
set vram_total=8000の部分は、3.6G使って2並列で組ますならばこれでも構わないけど、8000以上なら何でも構わないよ
別にグラボのMAXに合わせる必要はない >>982
あっごめん。グラボに割り当てのメインメモリを足した分は、多分だけど超えたらダメだとは思う >>981
500MBは少ないと思う
コマンドプロンプトから”nvidia-smi”と入力すればVRAM使用量がわかるから、
なにもしていない状態で調べてみてそれ以上のメモリを割り当ててみて
少なくとも自分の環境ではこれでCUDAのエラーが出なくなりリトライ処理が無くなって少し早くなったよ >>981
JavPlayer本体側です
設定の数値は合ってるみたいですね
::VRAM_USAGE 3600
こういうのがバッチと、JavPlayer本体の連絡用の値
本来の仕様では、何並列で動かすかは
（超解像に使用するGPUのVRAM容量-超解像ツール以外が使用するVRAM容量）÷（::VRAM_USAGE）
で決まる
試しに、SR-BVPPtest.batを作って動かしてみたら？
中身は3行
::JP_VER 111
::VRAM_USAGE 1000
pause
これで7並列起動するはず
::JP_VER 111
::VRAM_USAGE 3600
pause
これで2並列起動するはず >>981
あ、一応だけど
バッチを変えたら、JavPlayerの再起動が必要です
多分、起動時にしか反映されないと思う VRAM_USAGE 3600だとVRAM_fraction=45%になってるんですけど、
コンソールが一つしか出てこなくて処理される。
ためしにVRAM_USAGE 7200で並列なしにするとVRAM_fraction=90%になるけど、
VRAM_USAGE 3600のときと処理速度がほぼ同じ。
やっぱり並列できてないですよね。
tgmainのときはコンソールがたくさんでてきて並列されてるのがすぐわかるんですけど。 >>987
一旦3500に下げて試してみたらどうだろうか？
1並列あたり3300でしてるけど問題無く処理出来ているから、3600から下げてもいけるはず 割り当てたぶんをギリで分割設定すると並列化できないことはあるので
マージン取ってみると上手く行くパターンかも >>988.989
3500に下げてみると
VRAMfractionが45から43%に変わったんで、バッチファイルの入力は反映されてるようなんですが、
やっぱり並列はできてないみたいなんです。
せっかく教えてもらったのにすみません。 >>990
そうか…難儀やねぇ
誰かエキスパートさんに期待だな >>991
そうですね。色々ありがとうございます。
BVPPが発表されたときからずっとできなかったんで
なかば諦めてたんですが、何か根本的な事が足りてないかもしれないと思い質問させてもらいました。
しかし、977の方も3060で2時間ものが半日程かかると仰ってるので他にも同じ方がいるかもしれません。
原因は何でしょうかねえ？ >>992
3060でFHDまでしかしてないけど、2時間物だと長いとAI効かせて2passとエンコードで6時間かかって、BVPPも2時間かからないくらいの8時間かなぁ
tgmaimの時間は2passとエンコードは変わらないけど、超解像は14並列してて30分くらい
超解像以外は差はないから、 8時間か6時間半の違い
BVPPとtgmaimの比較なら四倍くらいは違うけど
最初困ってるのを見て、GPU使ってないのかも？と疑ってたけど
VRAM使用率が出てる段階でキチンと使えてるみたいだし、なんやろうね
解決されると良いね アプリの超解像に使用するVRAM容量はいくつにしてる？ >>992
ごめん最後確認したいんだけど
BVPPで解像してる時画面のVRAMの数値
3600/7692
って出てるかな このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 174日 11時間 55分 52秒 BBSPINKの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 専用ブラウザからの広告除去
★ 過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.bbspink.com/login.php レス数が1000を超えています。これ以上書き込みはできません。
