This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Vapoursynth R72 released
#1
Hello Selur,

   Recently has been release Vapoursynth R72
   
   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.

   Recently the support was added in x265 as reported in this post: vspipe: redirect unwanted stdout to stderr
  
    
 Dan
Reply
#2
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.
Reply
#3
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.

[Image: attachment.php?aid=3143]

Dan

P.S.
I noted that StaxRip is using by default the direct synth loading if the selected encoder is supporting it.


Attached Files Thumbnail(s)
   
Reply
#4
Nope, not using patched versions, too much trouble.
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#5
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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)