Request for VapourSynth support

[stax76]

I would like to request VapourSynth support, I mean direct support like the avs support and not via lavf in order to achieve the smallest possible binary size.

Sample code:

https://github.com/rigaya/NVEnc/blob/master/NVEncCore/rgy_input_vpy.cpp

https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/vapoursynth.c

[msg7086]

Sorry, cannot help at this moment, due to real life changes and limited capacity. I'm happy to review any pull requests though.

[stax76]

Ok thanks, we'll see what happens.

[stax76]

Could this maybe help:

https://github.com/DJATOM/x265-aMod

[msg7086]

Please try https://down.7086.in/x265-Yuuki-Asuna/vpy-test-3.3.7z . I don't have time to do much test, so it's on you guys. When you are happy I'll rebase to other branch versions.

[stax76]

Yes it's working, fantastic.

Would an 8+10 multi build be possible?

[msg7086]

This is just for testing. Please spread to those who it may concern, let people test it (different bitdepth or colorspace, etc.), and report back if you are confident for this patch to be baked into a formal release. After that, I'll recompile and release a new version.

You can also compile your own copy from current Asuna branch.

[stax76]

Ok, we will test it, thank you.

[DJATOM]

I had some problems with 3.4 branch. Got barely working reader on my machine but it sometimes gives out of order frames (probably I'm missing something in the encoder's logic). It seems in 3.4 branch I can't rely on pic.poc to request desirable frame.

[stax76]

I made a few tests using this code:

clip = core.resize.Bicubic(clip, %target_width%, %target_height%, format=vs.YUV420P8)

formats I tested:

vs.YUV420P8 vs.YUV420P10

vs.YUV422P8 vs.YUV422P10

vs.YUV444P8 vs.YUV444P10

The output looked fine, and I successfully checked the format of the output files using MediaInfo.

[msg7086]

x265-Asuna-3.3+10-gf7ef79cce+34.7z has been uploaded. Let me know how it works.

[stax76]

Where did you upload it?

[msg7086]

https://down.7086.in/x265-Yuuki-Asuna/

[stax76]

I think for most users it would be important to use the last stable version 3.4.

[msg7086]

As DJATOM mentioned there may be issues with 3.4 + VapourSynth support.

Do you have any idea how it works with 3.4?

[stax76]

No, I've used C++ a couple of months this year, but I'm not really advanced with it unfortunately. Same is true about my GIT knowledge, I know the basics but nothing advanced.

[DJATOM]

I'm still curing from covid19 and didn't returned to my work yet, but at least now I can use PC. Abr Ladder stuff made a huge mess in the codebase, making certain code non-working. The last thing I tried was

git diff abrEncApp.cpp
diff --git a/source/abrEncApp.cpp b/source/abrEncApp.cpp
index 2371a5c4b..e17b0bcab 100644
--- a/source/abrEncApp.cpp
+++ b/source/abrEncApp.cpp
@@ -1091,9 +1091,15 @@ ret:
                 if (!dest->planes[0])
                     dest->planes[0] = X265_MALLOC(char, dest->framesize);

-                memcpy(dest->planes[0], src->planes[0], src->framesize * sizeof(char));
-                dest->planes[1] = (char*)dest->planes[0] + src->stride[0] * src->height;
-                dest->planes[2] = (char*)dest->planes[1] + src->stride[1] * (src->height >> x265_cli_csps[src->colorSpace].height[1]);
+                if(!strcmp(m_input->getName(), "vpy")) {
+                    dest->planes[0] = (char*)src->planes[0];
+                    dest->planes[1] = (char*)src->planes[1];
+                    dest->planes[2] = (char*)src->planes[2];
+                } else {
+                    memcpy(dest->planes[0], src->planes[0], src->framesize * sizeof(char));
+                    dest->planes[1] = (char*)dest->planes[0] + src->stride[0] * src->height;
+                    dest->planes[2] = (char*)dest->planes[1] + src->stride[1] * (src->height >> x265_cli_csps[src->colorSpace].height[1]);
+                }
                 m_parentEnc->m_parent->m_picWriteCnt[m_id].incr();
             }
             else

and it started to encode again. Hope that might help. Check carefully output frames order, I'm getting mixed order clips from different runs.

[msg7086]

Yea I remember that abr thing messing my patches as well.

It seems to me like the code assumes a consecutive space allocations for all 3 planes, right? Maybe I can try meeting that demand instead of modifying core code.

[DJATOM]

Yeah, I just tried to avoid plane copies, but if you will craft "copied" frame, it should also work.

[msg7086]

OK, long story short,

1) You need to set all fields in pic, such as width height depth csp

2) You need to craft a frame with consecutive space allocation (assuming not changing core code)

3) You must not rely on pic.poc, simply use nextFrame and count from 0 instead

I've uploaded a new test version, and as before, please spread and test it thoroughly and let me know when I can bake it into a formal release.

https://down.7086.in/x265-Yuuki-Asuna/3.4%2B13-g729a838d3%2B35-test.7z

[stax76]

Great work guys!

[mugiritsu]

https://down.7086.in/x265-Yuuki-Asuna/3.4%2B13-g729a838d3%2B35-test.7z

This one doesn't seem to work for me, do I need to set something specific on the cmd?

x265y.exe %1 --preset veryslow --input-depth 10 --tune vcb-s --crf 15.5 --aq-mode 3 --qcomp 0.6 --vbv-bufsize 18000 --vbv-maxrate 18000 --output %1_enc.mkv

It doesn't report any error but the encoding never starts, same thing happened to a friend. 3.3 worked flawlessly for us with the same arguments.

[stax76]

@mugiritsu

Unfortunately not reproducible, these settings work fine here.

Maybe you can try the same settings with staxrip to see if there is a difference.

It's not necessary to use --input-depth 10 here, is it?

[msg7086]

You can start with the simplest option.

x265 input.vpy -o enc.mp4

But I don't see a reason why it doesn't start.

[mugiritsu]

Tried: x265.exe 23.vpy -o enc.mp4 For some reason it keeps alocatting more and more RAM even when the vpy script is just this

[msg7086]

Can you please try this?

https://down.7086.in/x265-Yuuki-Asuna/x265-Asuna-3.4%2B13-g729a838d3%2B38.7z

If it doesn't work either, I'll compile a debug version for you.

[mugiritsu]

Maybe you can try the same settings with staxrip to see if there is a difference.

Couldn't make my portable VS work with Staxrip, but I'll try with the r52 installer later.

https://down.7086.in/x265-Yuuki-Asuna/x265-Asuna-3.4%2B13-g729a838d3%2B38.7z

Works flawlessly!

And the memory issue is also solved:

[msg7086]

By the way, if you are interested, you can also try the external library function.

Simply put your vsscript.dll path before you input file like this:

[D:\some\path\vsscript]://23.vpy if your VapourSynth is extracted inside D:\some\path. This way I think it can support multiple / portable version to some degree.

[stax76]

Couldn't make my portable VS work with Staxrip, but I'll try with the r52 installer later.

Portable works only with the included vapoursynth, it's expected to be in a fixed location.

[D:\some\path\vsscript]://23.vpy if your VapourSynth is extracted inside D:\some\path.

I'm not really understanding the concept, please elaborate.

This way I think it can support multiple / portable version to some degree.

staxrip just prepends the VS folder to PATH

[msg7086]

What concept? Which part do you not understand? To read from VapourSynth script you need to dynamically load vsscript.dll. You simply provide the path in the input file name, so the VPY input module can get its path, and load the dll instead of the default one.

I'm not searching anything in PATH. PATH is used for searching executables. DLLs are not executables and are not invoked from command line, so it has nothing to do with PATH.

[mugiritsu]

I'm not really understanding the concept, please elaborate.

What msg7086 said means that that applied to a bat file lets x265-Yuuki/Asuna use any portable VS that is not on Path: x265.exe [D:\VapoursynthPortable3\VapourSynth64\vsscript]://23.vpy -o enc.mp4

I think I'm gonna make good use of it soon cause I have many portable VS folders somewhere on my system lol. Altought one can just drop an x264/x265.exe binary to where a portable vapoursynth.dll is and add that folder to Path and it would work just fine.

staxrip just prepends the VS folder to PATH

I guess it is because my multiple installations are a mess right now and my vsutil/lvsfunc.py were a pain in the ass to update and make it work with a certain script and that broke some other script, but it works just fine on a fresh system.

[stax76]

I'm still not understanding what it means and have never seen something like this before.

Vapoursynth is located here OK:

D:\VapoursynthPortable3\VapourSynth64\vsscript

But what means this:

://23.vpy

What if script and vapoursynth are located on different drives and what if script path and vapoursynth path contain spaces?

Please note that by default Windows DLL loading using LoadLibrary PATH is included in the search, problem is avisynth is installed at system32, and it has higher priority so when avisynth is installed portable will not work unless symlinks are used or the app has a way to define the DLL location via cli option or env var.

Default DLL load search of LoadLibrary:

1. startup
2. system32
3. PATH

I suggest CLI options --avsdll and --vsdll

[msg7086]

OK, loadlibrary does search PATH but as you said, it's still not a reliable way.

It's easy to put annotation in the filename because filename is passed into the input module. In other words, this is the implementation that is easy for me to write, so take it or forget about it. You are free to suggest CLI options, but then you can grab someone to write all the code and pass the options all the way down to input module.

Pull request welcome, but I'm not going to do that big project for now. I'm at limited capacity.

[msg7086]

Fixed Linux support. Now vpy input works properly on Linux.

[msg7086]

There's severe memory leak under Linux. Need some debug work.