【超解像】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/07(水) 19:37:00.27

本家
https://flathub.org/en/apps/io.github.ladaapp.lada

Github
https://github.com/ladaapp/lada

Windows版
https://pixeldrain.com/u/sXEq2C2V

Linux版もWindows版も無料です
有料の派生版がありますが無視しましょう

**名無しさん＠お腹いっぱい。** · 2026/01/07(水) 19:47:01.17

無料gui版作ってくれてる人にも感謝
去年からお世話になってます

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

Mac版(前スレ974氏による)
https://codeberg.org/lada_for_mac/lada_for_mac

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

ladaへ頻繁にアクセスしてる国はどこのどいつだ

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

>>11のMac版、CLIしか試していないけどコレ凄い
これまでの派生Mac版を遥かに凌駕している
はじめてGUIの環境整えようと思ったわ

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

● JavPlayer との違い
・モザイク破壊の原理は basicvsrppでJavPlayerのBVPPと同じだが
　学習素材にNSFWを使用しているためモザイク破壊がより綺麗にできる
　（TecoGANは無い）

・JavPlayerではグニャグニャになっていた作品も綺麗に破壊可能
　２D作品なら基本的にはどのメーカーでもOK

・JavPlayerにはあったウザいウォーターマークが無い
・JavPlayerよりも高速処理

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

数年前に無修正流出して潮吹きがホースだったの判明した動画あるけど
モザイク版をlada破壊したらちゃんとホース出てくるんだろうか

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

●処理速度の目安
-- CPU: Intel 265K
-- GPU: 5070ti(16GB)
-- DRAM 64GB
-- OS: Linux, Cuda 13.0, Pytorch 2.9.1
-- Lada ver. 0.10.0
-- モザイク検出モデル v4-accurate
-- モザイク破壊モデル basicvsrpp-v1.2
--encoding-preset hevc-nvidia-gpu-uhq
で、コマンドラインから実行した場合
FHD ならソース時間の 1/4～1/3
4kならソース時間の 2x ～

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

>>13

lada_parallel_gui.py

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

>>17
えぇ、それはそうなんですけど、その前にシステム直下にGTKとかlibadwaitaが必要では？
このままCLIで十分な気もしてきた

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

確かpythonだけでいけるやつ。
gtkも作ったけど、今のやつの方が良い感じ。
私もcliでいい感じ笑

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

超解像ってことで、この板には以下スレもあるです

【超解像】画像拡大ソフト総合スレ12【waifu2x】
https://egg.5ch.net/test/read.cgi/software/1710421297/

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

>>19
おわ、開発者さん！ありがとうございます
確かにLADATurbo画面が出ました（lada_parallel_gui.pyではなくlada-parallel-gui.pyだったw)

次の3連休が無くなるよコレ

**名無しさん＠お腹いっぱい。** · 2026/01/07(水) 22:05:07.37

ffmpegの作業ディレクトリがあるとスワップが起きやすいことがわかったので、スクリプトを最新に置き換えて--temp-dirで必ず外部を指定して。ウチ環だと速度かなりアップしました。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 00:41:26.86

>>15
ちょうど中華破壊あったから見てたけどホースもわかるぞ

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 07:51:13.49

>>23
自分で試したいので品番頼む。

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

>>11
前スレ993だけど、会社のMac Studio M4 Max 128GBで試した結果載せるわ。
720p 2時間動画を並列4で試して約60分でエンコ完了。処理中もまだ余裕ある感じだったので、恐らくもう少し並列処理上げられそう。自分の周りハイスペ環境がMacしかないのでマジ974氏には感謝だわ。

Device: mps / workers=4 / segment=30
Detect: v4-accurate (face mosaics: OFF)
Restore: basicvsrpp-v1.2 / max-clip-length=300

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 08:39:47.27

自営だよな

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 09:11:41.23

>>25

asitopで見てGPUが100％張り付くように並列処理を調整すればよいと思います。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 10:39:05.87

x86プロセサ＋ nVidia GPU なら FHD ２時間動画を30分で処理できるのになんで Mac にこだわるかね
Mac 使いって昔からほんとに…

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 10:46:40.25

あのスクリプトはx86でも使えるはずよ。
試す環境がないのでないやってないけど。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 11:10:09.82

>>25

検証してないけど並列10まで行けるようにしてみた。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 11:37:29.05

そもそも lada には並列処理なんていう概念が無いから何を並列させてるのか知らんけど
階層ディレクトリ探索させながら lada-cli を実行するbash スクリプトを組んで１つ１つ順番にバッチ処理させるのが一番効率的だぞ

階層ディレクトリじゃなくてどこか１つのディレクトリにまとめてソースをおいて一括処理するならスクリプトもいらん
lada-cli で入力にディレクトを指定すればいいだけ

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 11:48:33.36

並列と逐次実行は目的が違うぞ。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 11:48:44.33

macじゃそれが通用しないのよ笑
M1 Macだと普通にすると一本エンコするのに2日とかかかっちゃう笑

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 12:23:59.40

新参者です GUIの方でも処理を早くする方法はありますか？変換したい動画が数十本あってなるべく短縮したいです。
マシンのスペックは
Core i9-9980XE
メモリ128GB
GeForce RTX 2080 Ti
です。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 13:17:07.14

windowsのEXEでも並列処理できた。
pip install torch torchvision torchaudio
で仮想環境に必要なパッケージをインストールして以下のプログラムをコピーして実行
python3 process_video_parallel.py --input xxx.mp4 --output xxx.mp4 --temp-dir /tmp --parallel-workers 2 --device cuda
EXEにして配布もできるね
効果は検証中

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 13:30:25.87

最初に--segment-durationで分割しないと効果ないよ。

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 13:39:51.46

おっと、そなのか
4070でgpu 90%使ってるようだからx2ぐらい高速化する予感

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 15:06:14.60

>>24
STARS480

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 15:12:49.58

HINBAN警察の方、出番ですよぉｗ

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 19:20:33.47

WindowsとMac持ってるけどMacで破解する気はしないなぁ
それぞれ用途に見合った使い方するのが一番

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 20:06:45.59

無臭見みたけりゃ無臭買えって論破されそうw

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 20:32:06.10

無臭は無臭で嗜んでるけど、隠されてるものが見える様になることには別の価値がある

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 20:41:43.47

見たいんだ。【おまんこ】

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 21:06:11.75

そこに見れないまんこがあるから見るんだよ

**名無しさん＠お腹いっぱい。** · 2026/01/08(木) 21:47:56.72

>>36

並列処理スクリプトありがとう。Windowsでも動いたのでご報告

<環境>
ハード：Ryzen 9700X+DDR5 64GB+RTX 5060Ti 16GB
OS：Windows 11 25H2
NVIDIAドライバ：Studio 591.74
PyTorch： 2.9.1 CUDA 13.0
lada：0.10.0-dev (32d9a7d)
lada実行設定はencoding presetだけhevc-nvidia-gpu-hqを指定

＜入力ファイル＞
　FHD　17:31　(Segment数 18)

<結果>
オリジナルlada-cli　660.1秒 (11.1分)
process_video_parallel.py
　並列数1　850.8秒 (14.2分)
　並列数2　604.8秒 (10.1分)　8%高速化
　並列数4　531.7秒 (8.9分)　20%高速化
　並列数6　530.4秒 (8.8分)　頭打ち

単発ファイルの処理は並列数4でオリジナルlada-cliより2割高速になった

**名無しさん＠お腹いっぱい。** · 2026/01/09(金) 05:41:56.96

>>34
そんな焦りなさんな
バージョンアップで精度が上がればまたやり直すことになる

**名無しさん＠お腹いっぱい。** · 2026/01/09(金) 08:25:15.24

macのvideotoolbox使う時の設定間違えてたので修正しました。

画質大幅アップ。

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

4gb,Maxwellというド底辺環境のためcu126でビルドし、
30fps,sdを処理しているのだが、
実際に使えるVram量を身誤るのか、
大抵8秒周期で、7秒処理、1秒未処理
の動画になってしまう。
どこを書き換えれば良いのだろうか？
QuadroK2200なのだが、同じ4gbでもGTX970ならそういったことがほぼない。

**名無しさん＠お腹いっぱい。** · 2026/01/09(金) 17:33:28.52

>>46
基本放り込んで放置だから、どれだけ時間かかってるか確認してなかったけど、出力結果見たら動画の実時間より短い時間で終わってるみたい。高望みしてました。失礼しました。

**名無しさん＠お腹いっぱい。** · 2026/01/09(金) 18:30:38.38

0.10で連続破壊したら結構な頻度でスキップ発生するんだけどなんだろう？
もちろん再度やり直すと普通に破壊できる

**名無しさん＠お腹いっぱい。** · 2026/01/09(金) 20:58:26.60

超博士、頑張ってください、応援してます！

**名無しさん＠お腹いっぱい。** · 2026/01/09(金) 22:05:35.46

30本くらい変換して、満足の精度だったけど、さっきやったやつはダメだったから、やはり得意不得意はあるんだな。
JAVPLAERよりは精度が高いのは確実だけど。

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 04:00:52.74

破壊力は圧倒的にLADAが上だけど、精度自体はJAVの方が高い。
LADAの精度自体はjavスレに投下された初期verから変わってないというか、
むしろGUIの利便性と引き換えに悪くなってるくらいよ

なんか末期のEZの流れを見てるようで不安がよぎるわ

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 04:43:55.56

まず、破壊力とか精度とか何を指して言ってるのか分かりまてん

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 05:44:08.61

分からないならまだ二流ということだ。一流の人達ならたぶん分かる

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 07:17:17.98

全てにおいてきめえな

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 09:10:55.91

実際v2とv4の違いってなんなの

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 11:45:24.86

>>56
よっ、二流！

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 12:11:44.99

前スレ974氏へ
-encoder-options を ffmpegによるmerge_videos 時に適用するようにできませんでしょうか？
lada-cli --list-encoder-options hevc_videotoolbox で見ると pyavとffmepgでは適用できるオプションが異なるようなので

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 16:37:06.50

>>59は撤回します。
無視してください。申し訳ないです。

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 16:54:48.20

>>59

merge_videos時に—encoder-optionsを適用するのは時間が倍かかる気がするので、できないと思う。

claudeに投げて、帰ってきた答え通りをアップしてみました。

試してみて。

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 18:44:39.09

>>33
AppleとNVIDIAは対立関係だから
Macユーザーは「M1/M2/M3/M4」チップで頑張るしかない

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:08:01.78

>>61
早速の対応ありがとうございます
そもそもの>>59の提案は、ladaでvideotoolboxを使用すると
品質と引き換えでのファイルサイズの節約ができなくなるためでした
pyavでは未対応？？？

今回も -q:v 80 の設定は有効になってない感じがします

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:15:56.52

1つの動画を分割して並列処理は、分割・結合にムダな時間がかかるのと再エンコードによる劣化が伴う
そうではなくて複数の動画を並列処理するというようにはできないものだろうか？
これなら分割・結合による時間のムダも再エンコードもなくていいと思うんだが

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:22:03.91

無劣化の編集ソフトなら再エンコードはないでしょ
カットした部分だけあるかもしれないが

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:34:11.15

ソースを見た限りでは、分割の映像・音声と結合の音声は無劣化コピーだけど、結合の映像は再エンコードに見えるけど

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:37:29.60

複数動画並列は自分でコンソール複数枚でやればいいだけでは
処理しつつキュー管理や並列スロット増減とかするuiでも欲しいんかい？

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:39:59.37

すんまそん、結合の映像も'copy'でした

def merge_videos(segment_paths, output_path, encoder='copy'):
[中略]
if encoder == 'copy':
cmd.extend(['-c', 'copy'])
else:
cmd.extend(['-c:v', encoder, '-c:a', 'copy'])

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 19:55:03.10

>>63

-q:vしか設定していないのでファイルが大きくなっているようです。
他のパラメーターを調整中。

しばらくお待ちください。

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 20:00:01.50

>>67
こわくてやったことなかったのですが、コンソール複数枚で同時に処理しても問題は起きないんですか？
それならやってみます、ありがとうございました

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 22:13:54.60

>>69

-q:vやめました。pyav経由だとffmpegにうまく伝わらないようです。

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 22:24:34.97

>>70
VRAMが多い環境なら、複数同時でも全然いけますよ
自分は今、並列2プロセスで回しながら、裏でPython使って別動画の結合を同時にやってますが、VRAM 8GB～10GB前後(MAX24GB)の安定推移でクラッシュも起きてません。
ただ、max-clip-lengthを上げすぎると一気にメモリを食って共倒れするので、並列なら180以下くらいに抑えておくのが安パイです。

**名無しさん＠お腹いっぱい。** · 2026/01/10(土) 23:19:48.11

Windows用のEXE実行タイプのGUI使ってるけど、便利だけど余り細かいことできないのね。
Python使ったGUI使えばいいんかな？
それともCUI？CUIだとバッチ処理出来るんかな？

1度に出来れば２つ処理したいんやけど、、

無知ですまん

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 00:03:38.71

0.10.1 にしたら lada-cli が使えなくなったぞ😠

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 01:11:47.50

>>74
試してみたけどGUIもCLIも問題ないようだが？

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 03:08:24.61

0.10.0でCLIの引数結構変わっているから、0.9.xか0.8.xから0.10.1に上げたのなら戸惑うかも

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 09:19:18.84

>>76
そうだよね、0.10.0で急に「--crf」が廃止になったからえ？と思ったよね
恐らく、nvenc使用時に変える必要があるのが「--codec」指定なら判定できるけど、
「--custom-encoder-options」で直接ffmpegに渡されると面倒なのでやめたんだろうけど

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 10:26:27.96

>>77
0.10.0から--encoding-presetでプリセットを選択するか、--encoderと--encoder-optionsを使って細かく設定するかの使い方になったようだ
自分はffmpegのオプションには詳しくないので、面倒だからnvidiaのデフォルト設定(hevc-nvidia-gpu-hq)で使っている
lada/utils/encoding_presets.csvを見てみたらこの設定は以下でffmpegのオプションを構成している様だ
Encoder: hevc_nvenc
Encoder options: -preset p7 -tune hq -rc constqp -qp 20 -spatial_aq 1 -aq-strength 6 -bf 3 -b_ref_mode middle -rc-lookahead 32

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 12:18:07.78

lada-cli使ってます。
--encoder libx264 --encoder-options "-crf 10 -preset slower"
で出来上がったmp4ファイルをTMPGEnc Video Mastering Worksで編集エンコードする際、かなりの確率でハングアップします。
その際はタスクマネージャーから強制終了させ、「Out Process for VME」も終了させないと再びTMPGEnc Video Mastering Worksを使えません。
mp4コンテナと相性悪いのかと思いladaでproresコーデックを指定してみたのですが、
Error on export 'mp4' format does not support 'prores' codec
と言うエラーが出て終了してしまいます。
mp4コンテナ以外を指定すれば良いのかと思いましたが
ERROR:libav.prores:Specified pixel format yuv420p is not supported by the prores encoder.
ERROR:libav.prores:Supported pixel formats:
ERROR:libav.prores:yuv422p10le
ERROR:libav.prores:yuv444p10le
ERROR:libav.prores:yuva444p10le
ERROR:libav.prores:Specified pixel format yuv420p is not supported by the prores encoder.
ERROR:libav.prores:Supported pixel formats:
ERROR:libav.prores:yuv422p10le
ERROR:libav.prores:yuv444p10le
ERROR:libav.prores:yuva444p10le
Error on export [Errno 22] Invalid argument: 'avcodec_open2(prores)'; last error log: [prores] yuva444p10le
と言うエラーが出てしまいます。どこか見落としてる箇所があればご指摘戴けませんでしょうか。

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 12:21:38.73

>>78
詳しい説明ありがとう
0.10.0以降対応の VR_Single_File.bat で crf だけでなく preset も消えた理由がよくわかったよ
しかし、このVRでは lada 通した片目ファイルは一時ファイルで、その一時ファイルで超遅い p7 を使ってファイルを高画質＋小さくする意味はないな
試しに、lossless を使って左右分割と lada 処理をしたらどうなるかやってみたが、試したVR動画では、処理スピードは約3倍になったが、各ファイルサイズは約70倍になった
そこで、処理の順番を左目動画抽出⇒左目lada通す⇒左目動画削除⇒右目動画抽出⇒右目lada通す⇒右目動画削除⇒左右目lada結合⇒左右目lada削除に変えてみた
見てみても最終SBSファイルの違いはよくわからないが、速くなったからいいか

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 13:28:43.79

>>79
Windows/Linuxでnvidia積んでいるのだったら急がば回れで、lada-cliは >>80のようにlosslessでやるか>>8 に書いてある通り --encoding-preset hevc-nvidia-gpu-uhq で処理して後でproresにトランスコードする方が確実じゃね？

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 13:42:02.16

wcswidth　が flatpak の manifest に入ってねぇんだよ

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 14:04:46.06

AV総合板にLADA part3スレが建っているが、荒らしが一人で工作してる糞スレになってるや

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 14:12:30.78

codebergに置いてあるlada-python-dependencies.yamlにはwcwidthが追加されているが、githubのflathub/io.github.ladaapp.ladaに置いてあるやつは0.9.0版になっててwcwidthがないな

イシュー発行だ >>74

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 14:12:53.99

ド新規の3流連中があっち行ってくれればええがな

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 14:20:59.18

lada-0.10.0-mps.zipってどこからダウンロードできるの？

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 15:23:05.86

86 無視してもらって大丈夫です失礼しました

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 17:13:39.54

lada-gui.exe待ちやわ

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 18:01:02.25

>>81
有難うございます。
そう思ってprores選んだんですけどエラーが出て困った次第で。
んーどうした物か。

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 18:22:17.51

LADA 0.10.1が出たよ

CLI+GUI: FP16 が有効になっている場合の Nvidia 50 シリーズ GPU のパフォーマンス低下を修正
CLI+GUI: ワーカーのいずれかがクラッシュした場合には、復元パイプラインを停止し、エラーを表示するようにします。
GUI: 別のファイルを開いたときに時々フリーズしたり、スピナーが動かなくなる問題を修正

らしいよ

本家
ttps://flathub.org/en/apps/io.github.ladaapp.lada
windows GUI+CLI
ttps://pixeldrain.com/u/KTaf6p3n

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 18:34:23.69

>>89
再エンコードが1回余計に入るけど、ladaはhevc_nvencでファイルサイズ大・高品質設定で処理して、出来たファイルをその後ffmpegとかでproresにトランスコードするのが確実では、ということを言いたかった

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 18:59:38.03

>>91
有難うございます。
再エンコードとなるのですね。
折角ladaにprores対応ってなってるのに何で駄目なんですかね。

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 19:39:12.55

>>90
可変の修正とかいうの入ってないんだな

**名無しさん＠お腹いっぱい。** · 2026/01/11(日) 21:26:14.09

パフォーマンス低下を修正と言われても開始したらほったらかしだからわからん

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 09:20:42.48

losslessでやると、一時ファイルを作るその処理は高速だけど、その次の、できた超巨大一時ファイルを使った処理が超低速になるので全くダメでした
結局、hevc-nvidia-gpu-uhq か hevc-nvidia-gpu-hq でやるのが現実的ですね
それか、hevc をやめて h264-nvidia-gpu-fast にしたら高速だろうけど、品質はどれぐらい落ちるんだろう？

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 11:03:46.54

Encoding Presetの構成は以下の通りだった

h264-nvidia-gpu-fast|h264_nvenc|-preset p4 -rc constqp -qp 23
hevc-nvidia-gpu-hq|hevc_nvenc|-preset p7 -tune hq -rc constqp -qp 20 -spatial_aq 1 -aq-strength 6 -bf 3 -b_ref_mode middle -rc-lookahead 32
hevc-nvidia-gpu-uhq|hevc_nvenc|-preset p7 -tune hq -rc constqp -qp 18 -spatial_aq 1 -aq-strength 6 -bf 3 -b_ref_mode middle -rc-lookahead 32

h264_nvencのp4はmedium (default)、hevc_nvencのp7はslowest (best quality)
hevcに比べてチューニング頑張っていない様だから、画質はそこそこ？

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 11:50:49.80

ladaで処理した動画をTMPGEnc Video Mastering Worksで何の編集しているんだろう。。。

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 15:44:03.05

普通は編集してからladaにつっこむのにな

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 15:59:44.13

--encoding-preset の中に codec も入っているので、--encoding-preset を指定したら --encoder を指定する必要はない
それどころか、両方指定して、使用する codec が異なっていると、--encoder の指定だけが採用され、--encoding-preset は無視される
また、--encoding-preset を指定して、--encoder-options で別の codec を指定すると「無効なエンコードプリセット」のエラーとなる
ということで、合体させて
--encoder h264_nvenc --encoder-options "-preset p7 -tune hq -rc constqp -qp 18 -spatial_aq 1 -aq-strength 6 -bf 3 -b_ref_mode middle -rc-lookahead 32"
を試してみたが、hevc_uhq よりも遅いしファイルサイズも1.6倍ほどになってしまった

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 19:02:46.56

今まで何も考えずに動画を放り込んでたけど、解像度が無駄に高いと時間かかるんだな。どうせ8インチのタブレットでしか視聴しないから、変換ソフトで解像度下げてから破解するようにしたら、半分くらいの時間で終わるようになった。これなら捗るな。

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 20:43:23.26

何を今更

**名無しさん＠お腹いっぱい。** · 2026/01/12(月) 21:43:56.03

最近知って、使い始めてまだ10日くらいだから

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 00:38:39.94

そうか。頑張って極めてくれ

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 03:38:38.76

お、manifest が修正された

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 14:14:59.50

10.0も10.1も　顔モザイクを検出　はＯＮしたらダメだな
肝心なところのモザイクが取れないシーンが多くなる
顔モザイクを検出　をＯＦＦにしてやり直すと取れなかったモザイクが取れている
顔モザイクを検出ＯＮで結構数処理したのでＯＦＦでやり直しだわ

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 14:20:13.60

皆さん、変換にはどれくらいの速度が出てますか？

ワイ環境ではFHDで実時間0.8～1.1倍かかります。oculinkがボドルネックになってるようだから、新しく自作PCを組もうか考慮中です

CPU Ryzen 9 8945HS
RAM 32GB
1TB SSD
RTX 5070Ti 16GB（外付けGPU）
oculink接続（PCIe 4.0 x4）
OS Windows11
lada v0.10.1

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 14:25:15.83

検出精度はv4-accurateよりv2の方が優秀なんですよね？

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 14:54:20.79

zelefansが10.3へバージョンアップされてワンクリックでのfisheyeモードが追加されたから試してたがVR画面の端のモザまで処理してくれるケースが増えて格段に変換精が上がった感じ。
ただ処理ステップが増えたので処理時間は掛かる。

**名無しさん＠お腹いっぱい。** · 2026/01/13(火) 15:28:03.22

>>106
ryzen5700x
メモリー32GB
RTX2060super
SSD500GB

これで元の1,2～1.8くらいだな
JAVが5-6倍かかっていたのに比べたらダントツに早いから
早さよりもモザイク残りをどうにかしてほしい