The most significant improvement is the support to named pipes in vspipe.
This support was added to solve some problems related to vspipe as described in my post #25
Now R72 supports python 3.12 and later in addition to 3.8 on windows and this should facilitate the torch package migration.
Unfortunately few encoders are able to support named pipes in windows.
Yeah, dev currently uses R72-RC1
Don't really plan to use named piped currently. (personally, this sounds like a bad workaround, but I might look into using them in the future.)
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
I do agree with you, I tried to explain the same concept in this post: #1121
But myrsloik preferred and elegant, but not very useful, solution implementing the named pipes.
I think that a better option for Hybrid is to use the x264 and 265 mod versions proposed by Patman86 or DJATOM.
These versions are able to read directly the avs/vpy scripts like NVEnc and so you could implement the same direct synth load option already available in Nvenc.
Dan
P.S.
I noted that StaxRip is using by default the direct synth loading if the selected encoder is supporting it.
Atm. I do the following:
Process_1: vspipe call (with raw pipe '-')
Process_2: encoder call (with raw pipe '-' input)
Connect std::out of Process_1 to std::in of Process_2
Connect std::err of Process_1 and Process_2 to Hybrid to catch error messages&co in the debug output.
Maybe something like:
Process_1: vspipe call (with named pipe)
Process_2: encoder call (with raw pipe '-' input)
Open named pipe and connect it to std::in of Process_2
Connect std::err of Process_1 and Process_2 to Hybrid to catch error messages&co in the debug output.
=> I'll try to look at it over the weekend, maybe this is possible and doesn't cause slowdowns.
Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.