Deoldify Vapoursynth filter

[Dan64]

clip buffer size > 100 
Probably related to https://github.com/vapoursynth/vapoursyn...66d6e29a12
did a quick test and lowering the thread count to 1 does seem to work here.

But I'm still unclear why instead of 6 now 12 reference frames are run through the server.
Also, I see:
2026-05-27 18:04:14,654 [INFO] Connection opened  127.0.0.1:12840
2026-05-27 18:04:14,656 [INFO] Connection opened  127.0.0.1:12841
why two connections?

The two TCP connections are opened by the client. xmlrpc.client.ServerProxy creates a new TCP connection for each RPC call — in
the client, there are 2 (is_pipeline_loaded(), colorize_frame()). With HTTP/1.1 enabled on the server side, a connection already served can remain open idle
(keep-alive) waiting for a new request, even if the client transport closes it immediately after reading the response.
When the client terminates, all open TCP connections are closed by the operating system.
Each of the two remaining connections (those of is_pipeline_loaded() and colorize_frame()) produces its own ConnectionResetError. 
Hence the two messages for the connection opened/closed (no intentional division here). 

So you are using R76 with thread count = 1 ?, but this will slow-down the encoding. The best filters for VS are written using API3 and it seems absurd to me that the authors want to abandon them, I think it's either a bluff or that they're completely lost, one more reason to stay away from VS versions > R74. 

BleedOuts is VSGAN filter ?, don't knowing the original colors I cannot say if green is worse than brown, maybe in this context yes, but maybe in other context not.

I will test your new version with R74 (R76 is in the trash).

Dan

---

In the last test version



the parameter Mode should be removed, because in the last RC7 (posted here), I removed encode_mode parameter (only remote CMNET2 processing will be supported).

please update the test version.

Thanks,
Dan