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.
But at the end of the encoding I always get:
Exception occurred during processing of request from ('127.0.0.1', 5402)
Exception occurred during processing of request from ('127.0.0.1', 5403)
Traceback (most recent call last):
Traceback (most recent call last):
File "socketserver.py", line 697, in process_request_thread
File "socketserver.py", line 362, in finish_request
File "socketserver.py", line 697, in process_request_thread
File "socketserver.py", line 362, in finish_request
File "socketserver.py", line 766, in __init__
File "socketserver.py", line 766, in __init__
File "http\server.py", line 438, in handle
File "http\server.py", line 438, in handle
File "http\server.py", line 404, in handle_one_request
File "socket.py", line 720, in readinto
File "http\server.py", line 404, in handle_one_request
ConnectionResetError: [WinError 10054] Eine vorhandene Verbindung wurde vom Remotehost geschlossen
File "socket.py", line 720, in readinto
----------------------------------------
ConnectionResetError: [WinError 10054] Eine vorhandene Verbindung wurde vom Remotehost geschlossen
This should be captured, since otherwise folks might think this is a crash.
Cu Selur
I can try to remove the trace, but the connection error is normal in this case.
# colorize using CMNet with external DiT (HAVC)
clip = havc.HAVC_cmnet2dit(clip, dit_engine_params={"host": "127.0.0.1", "port": 8765, "model_precision": "int4"})
# adjusting color space from YUV420P8 to RGB24 for vsAutoWhite
clip = core.resize.Bicubic(clip=clip, format=vs.RGB24, matrix_in_s="470bg", range_in_s="limited", range_s="full")
# adjusting colors using AutoWhite
clip = color.AutoWhite(clip)
worked.
Switching to 'local'
# colorize using CMNet with external DiT (HAVC)
clip = havc.HAVC_cmnet2dit(clip, encode_mode=1, dit_engine_params={"host": "127.0.0.1", "port": 8765, "model_precision": "int4"})
# adjusting color space from YUV420P8 to RGB24 for vsAutoWhite
clip = core.resize.Bicubic(clip=clip, format=vs.RGB24, matrix_in_s="470bg", range_in_s="limited", range_s="full")
# adjusting colors using AutoWhite
clip = color.AutoWhite(clip)
this time it worked. Initial colorizing of the ref frames (6 in my case) was done as fast as before, then it seemed 'stuck' (no progress), but since the GPU was running at 50% I waited a bit and it worked, now the encoding was really slow. So seems like 'local' is working now too, just rather slow.
Cu Selzur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
I implemented a clean client-disconnect logging that suppress the alarming traceback that socketserver prints by default when a client closes the connection unexpectedly.
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
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
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.exe
set SERVER_DIR=D:\PProjects\DiTServerRPC
set LOGFILE=D:\PProjects\DiTServerRPC\dit_server.log
change the default precision to "int4" (in the script is "fp4")
if /i "%PRECISION%"=="" set PRECISION=int4
Dan
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".
3 hours ago(This post was last modified: 3 hours ago by Selur.)
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)
2026-05-25 09:22:02,360 [INFO] Connection 127.0.0.1:7424 closed by the client (ConnectionResetError: [WinError 10054] Eine vorhandene Verbindung wurde vom Remotehost geschlossen)
(isn't one time enough?)
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"
before starting the server again.
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,...
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.