![]() |
|
Deoldify Vapoursynth filter - Printable Version +- Selur's Little Message Board (https://forum.selur.net) +-- Forum: Talk, Talk, Talk (https://forum.selur.net/forum-5.html) +--- Forum: Small Talk (https://forum.selur.net/forum-7.html) +--- Thread: Deoldify Vapoursynth filter (/thread-3595.html) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
RE: Deoldify Vapoursynth filter - Dan64 - 24.05.2026 In effect there is a bug on local encoding mode. The new RC5 (attached) fix it. Thanks, Dan P.S. On my side using local mode with max_memory_frames=4, I reach a pick on VRAM usage of 15.9 GB. (Yesterday, 19:53)Selur Wrote: Restarted the job and it worked again.I can try to remove the trace, but the connection error is normal in this case. Dan RE: Deoldify Vapoursynth filter - Selur - 24.05.2026 Using RC5 with: # colorize using CMNet with external DiT (HAVC)Switching to 'local' # colorize using CMNet with external DiT (HAVC)Cu Selzur RE: Deoldify Vapoursynth filter - Dan64 - 24.05.2026 I updated DiTServerRPC I implemented a clean client-disconnect logging that suppress the alarming traceback that socketserver prints by default when a client closes the connection unexpectedly. Please update your version. Dan RE: Deoldify Vapoursynth filter - Selur - 24.05.2026 Updated and tried it ('remote'). 1st try: client didn't connect (cpu: 0%, gpu: 0%) restarting job, didn't help. 2nd try (restarting server and then the job): now client connected, encoding started and finished. 3rd try, now with 'local': client connected, encoding started with ~0.5-1.2fps (instead of ~11fps during encoding with 'remote') but then stopped after encoding a few frames. Having to restart the server sometimes is a bit annoying, so using this in succession with multiple files is something I wouldn't recommend. Also, the strange stopping in the middle of the processing, is annoying. Will be offline till tomorrow, but can so more testing tomorrow. Cu Selur RE: Deoldify Vapoursynth filter - Dan64 - 24.05.2026 In the case it could be useful, I attached the script that I'm using to run the server. Copy it in the same folder where is located your server. Then create a link on your desktop to this file and assign to it a name and an icon that you like. Inside the script you need to updated the following variables, to match your folder structure set PYTHON_EXE=D:\PProjects\DiTServerRPC\.venv\Scripts\python.exechange the default precision to "int4" (in the script is "fp4") if /i "%PRECISION%"=="" set PRECISION=int4Dan P.S. I don't understand why you are using "virtualenv" while in the instructions provided is requested to use "venv", should be the same, but I don't have tested the installation using "virtualenv". RE: Deoldify Vapoursynth filter - Dan64 - 24.05.2026 In RC3 I reduced the timeout for client connection from 600sec to 60sec. In the attached RC6 I restored the 600sec timeout. Dan RE: Deoldify Vapoursynth filter - Selur - 25.05.2026 Quote: I don't understand why you are using "virtualenv" while in the instructions provided is requested to use "venv", should be the same, but I don't have tested the installation using "virtualenv".you are right virtualenv isn't used and isn't needed --- started server, started script in vsViewer First frame took 41s The first output from the server takes a long time ~41s without any indication. => the server should indicate something when a client is connected,... now it seems to be stuck again, vsViewer is still hidden,... Something is still not okay with the communication. Since both the Python and the VapourSynth Viewer process ar at 0& cpu&gpu, I killed the VapourSynthViewer process. Then I saw: :02,360 [INFO] Connection 127.0.0.1:7423 closed by the client (ConnectionResetError: [WinError 10054] Eine vorhandene Verbindung wurde vom Remotehost geschlossen)Restarted vsViewer, frames get created in the server, but twice as much as before. No clue why,... did you change something else? closed vsViewer, reopened it, first 6 frames get colorized, then the server is stuck again,.. Stopped the server (and vViewer) after a few minutes. also called: set LOGFILE=F:\dit_server.log"started server and vsViewer gain, client doesn't connect (<>nothing is happening),.. killed vsViewer and restarted it. Now it seems to be working,... => this too instable to be usable atm. (at least on my system) Cu Selur Ps.: no "F:\dit_server.log" was created,... |