Improving CodeFormer videos

[Dan64]

Does it work if the files from Hybrid\64bit\Vapoursynth\torch_dependencies\bin are used?
(not planing to install the CUDA SDK)

I'm using the Hybrid environment which should be based on CUDA 12.x, and the filter is using that libraries.
CUDA is backward compatible with the previous versions and so CUDA 11.4 is a good starting point. 
To be sure I renamed the folder with my SDK installation (which was necessary to compile dblib) in

'C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.4

 
and the filter worked perfectly, so my answer to your question is that the Hybrid\64bit\Vapoursynth\torch_dependencies\bin.
I'm not sure if during the installation of the wheel python checks the existence of the libraries. But given that "python" is very lazy on this kind of controls, I expect that the installation should proceed smoothly.

Dan

---

Hello Selur,

  the fixing of CUDA problem, raised another issue.
  There are situations (or clips) where VSpipe fails to fully encode the movie.
  The error is the following:

  Error: fwrite() call failed when writing frame: xxx, plane: 0, errno: 32

  I was unable to fix this issue.  

  This problem started to happen when I enabled CUDA in dlib.

  I suspect that some library raise some kind of error.

  I tried to fix the problem by adding to the script the following code

  

# Blind Face Restoration using CodeFormer
from vscodeformer import codeformer as CodeFormer
try:
   clipEx = CodeFormer(clip=clip, upscale=1, detector=1, weight=1.0, num_streams=1) # 720x390
except Exception as e:
   vs.core.log_message(2,'Codeformer Error: ' + str(e))
   clipEx = CodeFormer(clip=clip, upscale=1, detector=0, weight=1.0, num_streams=1)
finally:
   clip = clipEx

  maybe the error is raised before or after I not checked all the code.

  But what is really strange is that using "VsViewer" to encode the same video, the encoding proceed smoothly.

  I obtained the same result using the original Codeformer script: 

inference_codeformer.py

  So It seems that the problem is limited to VSpipe.
  But given that also "VsViewer" is using the "pipes" to perform the encoding I expected to see the same problem on "VsViewer".

  I know that you worked on "VsViewer", maybe this the reason why "VsViewer"  is working better that "VSpipe".
  Do you have any idea on how the problem can be fixed ?

  It is theoretically possible to extend "VsViewer" so that can be launched using the command line like "VSpipe" ?

  I guess that "VsViewer" is more robust because the "pipe" is directly controlled by the program, while with "VSpipe" is the OS that control the pipe.

  I attached an archive containing:

    1) the script used
    2) the clip used
    3) the log.

  I hope that this can help.

Thanks,
Dan