Vapoursynth

[Myrsloik]

Nice. Would you like to attach ICC profiles of images as frame properties via imwri? Like here (https://github.com/YomikoR/VapourSynth-ICCConvert/blob/882e460b6896c4f3658ad6c7c4d17ee271aaf3fb/src/magick/magick.cc#L11-L15). The ->datum is unsigned char * so nothing will be fancy. Typically ICC profiles are from 1KB to 1MB. For preparation, it suffices to build imwri with Little CMS (will add ~500KB to the plugin dll) with MAGICKCORE_LCMS_DELEGATE macro checked on build.

Sure, patches welcome I guess. As long as attaching it can be disabled and there's something interesting to do with the information.

[l33tmeatwad]

Was the ffms2 used with the tests a custom build or does the latest revisions on the main branch include VapourSynth audio support?

[Myrsloik]

Was the ffms2 used with the tests a custom build or does the latest revisions on the main branch include VapourSynth audio support?

No ffms2 builds have VS audio support. I'd actually recommend BestAudioSource instead unless it causes problems for you. If it does cause problems please do report them so I can try to improve it.

The ffms2 master branch has both API 3 and 4 support.

[l33tmeatwad]

I assume best audio source is included in VapourSynth?

[DJATOM]

No, considering the size.

[Myrsloik]

I assume best audio source is included in VapourSynth?

Binaries available here (https://github.com/vapoursynth/vapoursynth/releases/tag/R54-API4-test1).

[l33tmeatwad]

Was looking to compile for macOS, I assume the repository is up to date for BAS?

[Myrsloik]

Was looking to compile for macOS, I assume the repository is up to date for BAS?

Yes, should work. Haven't really tested it myself so feel free to submit fixes for annoying compile warning messages.

[lansing]

What is the difference between freeMap() and clearMap()? If I have a map that contains a video node and I want to delete it and reuse the map, do they both achieve the same thing?

[Myrsloik]

What is the difference between freeMap() and clearMap()? If I have a map that contains a video node and I want to delete it and reuse the map, do they both achieve the same thing?

clearMap only resets the map to its initial state (removes all values set in the map).

freeMap frees the actual map as well so then you'd have to allocate another one with createMap.

[Myrsloik]

Apparently vsrepo updates broke since my host now requires user agent headers to handle requests.
You can get a fixed vsrepo.py from here (https://github.com/vapoursynth/vsrepo/blob/master/vsrepo.py)

[Selur]

Downloaded "VapourSynth64-Portable-R55-API4-RC3.7z" from https://github.com/vapoursynth/vapoursynth/releases
looked inside the sdk/VapourSynth.h and it states:

#define VAPOURSYNTH_API_MAJOR 3
#define VAPOURSYNTH_API_MINOR 6

Did you forget to include the new headers with the portable version or am I missing something? Shouldn't it incude the API4?

Cu Selur

[Myrsloik]

Downloaded "VapourSynth64-Portable-R55-API4-RC3.7z" from https://github.com/vapoursynth/vapoursynth/releases
looked inside the sdk/VapourSynth.h and it states:

#define VAPOURSYNTH_API_MAJOR 3
#define VAPOURSYNTH_API_MINOR 6

Did you forget to include the new headers with the portable version or am I missing something? Shouldn't it incude the API4?

Cu Selur

Will be fixed

[Selur]

Okay, thanks!

[Yomiko]

Do you have a secret way to build a slim imwri.dll?

[Selur]

@Myrsloik: Do I see it right, that R55 will use API4 without any backward compatibility?

[Boulder]

I just found out that something happened between R53 and R54 which broke the function that calculates MDSI (found in muvsfunc.py). I used the exact same script and vsrepoed mvsfunc.py and muvsfunc.py to test. R53 works, R54 produces weird results.

More details here: https://forum.doom9.org/showthread.php?p=1951673#post1951673

[Myrsloik]

@Myrsloik: Do I see it right, that R55 will use API4 without any backward compatibility?

No. Get glasses.

[Myrsloik]

Do you have a secret way to build a slim imwri.dll?

By slim do you mean as a single dll? I think the one I distribute was cross compiled from linux by @jackoneill. No idea what trickery he used exactly but with visual studio it's probably near impossible to do.

[Selur]

No. Get glasses.
Okay, just read the 'Vaporusynth Editor 2' thread and it sounded like new R55 would require that viewers need to be updated. But good to know that is not the case and at least for R55 upgrading to the new API is optional.

[Myrsloik]

Okay, just read the 'Vaporusynth Editor 2' thread and it sounded like new R55 would require that viewers need to be updated. But good to know that is not the case and at least for R55 upgrading to the new API is optional.

The compatibility is more like this:
Plugins: 99% no change needed
Scripts: Minor changes needed if you used the deprecated get_core() function or YCOCG that's all removed. There are a few more smaller differences but a 2 minute change at most and many scripts are already adapted for it.
VSScript users: Most of them use the COMPAT* formats for output but they're removed. The rest is completely compatible.

Moral of the story: Planar formats FTW.

[Selur]

Okay, so at least most of the editor will need to be updated or they can't use R55.

[Boulder]

I just found out that something happened between R53 and R54 which broke the function that calculates MDSI (found in muvsfunc.py). I used the exact same script and vsrepoed mvsfunc.py and muvsfunc.py to test. R53 works, R54 produces weird results.

More details here: https://forum.doom9.org/showthread.php?p=1951673#post1951673

As this can be reproduced outside Zopti, I'll post here. Just use the test clip from the Zopti thread.

import vapoursynth as vs
import muvsfunc as muf
import mvsfunc as mvf

core = vs.core

orig = core.ffms2.Source(source=r"c:\zopti\strangerthings_s02e01.avi")

alternate = core.resize.Bicubic(orig, width=1280, height=640, filter_param_a=-0.7, filter_param_b=0.35)
alternate = core.resize.Bicubic(alternate, width=orig.width, height=orig.height, filter_param_a=0, filter_param_b=0.5)

orig = core.resize.Bicubic(orig, format=vs.RGB24, matrix_in_s='709')
alternate = core.resize.Bicubic(alternate, format=vs.RGB24, matrix_in_s='709')
clp = muf.MDSI(orig, alternate)
clp = core.text.FrameProps(clp)

clp.set_output()

Open the script in VapourSynth Editor and jump to frame 80.
R53 shows MDSI score 0.211945
R54 shows MDSI score 127114388.903713

There are several frames where this happens.

[ChaosKing]

Even simpler. I get also very high, almost random, numbers. Tested with R55.
clip=mvf.ToRGB(clip)
clip = muf.MDSI(clip, clip.text.Text("A"))
clip = core.text.FrameProps(clip)

Must be something related to Expr https://github.com/WolframRhodium/muvsfunc/blob/6abd811bfdab38fd75b90938522c17f6099b4695/muvsfunc.py#L4636

EDIT
It's OK with core.std.SetMaxCPU("none")

[ChaosKing]

If I replace the 3 expr lines https://github.com/WolframRhodium/muvsfunc/blob/6abd811bfdab38fd75b90938522c17f6099b4695/muvsfunc.py#L4713
core.std.Expr([ix_l1, iy_l1], ['x dup * y dup * + sqrt']) with something else (or the convolution line from above) , then the score shows the same value with/without cpu none.

[Quadratic]

Why does vspipe produce different errors based on the order of the script? This is a nightmare to debug...

Two scripts, the content is the same only the order is different. Both scripts "work", I can preview them in VSEdit, but vspipe errors.

import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(format=vs.RGBS)
clip2 = core.ffms2.Source('bunny_anim.gif')

rg = core.rgsf.RemoveGrain(clip, mode=1)

rg.set_output()

import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(format=vs.RGBS)

rg = core.rgsf.RemoveGrain(clip, mode=1)
clip2 = core.ffms2.Source('bunny_anim.gif')

rg.set_output()

AttributeError: No attribute with the name ffms2 exists. Did you mistype a plugin namespace?
AttributeError: No attribute with the name rgsf exists. Did you mistype a plugin namespace?

[Myrsloik]

Probably memory corruption somewhere in rgsf.

[feisty2]

remove grain mode 1 is the same as std.Convolution([1,2,1,2,4,2,1,2,1]), use that instead.
I haven't touched removegrain in years and I'm afraid I don't have time for this any time soon

[Quadratic]

Thank you for the prompt responses, but this does not give me an answer.

Running this script gives me an attribute error for ffms2
import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(format=vs.RGBS)
clip2 = core.ffms2.Source('bunny_anim.gif')

rg = core.fake.function(clip)

rg.set_output()
How can this be prevented? I can easily imagine this happening by mistake in a large script.

remove grain mode 1 is the same as std.Convolution([1,2,1,2,4,2,1,2,1]), use that instead.
I haven't touched removegrain in years and I'm afraid I don't have time for this any time soon

I understand and thanks, Convolutions have already been implemented where possible here: https://github.com/Irrational-Encoding-Wizardry/RgToolsVS

Unfortunately, there are some modules which contain functions that rely on rgsf.RemoveGrain/Repair such as https://lvsfunc.encode.moe/en/latest/

Maybe I can ask them to remove them but I don't know if there's any replacement filters which could be used in their stead.

[poisondeathray]

Why does vspipe produce different errors based on the order of the script? This is a nightmare to debug...

Two scripts, the content is the same only the order is different. Both scripts "work", I can preview them in VSEdit, but vspipe errors.

I don't get those vspipe error messages. It work ok for me on Windows

vspipe --info script.vpy gives no error message

Pipe into ffmpeg is also ok. eg. 1st script, no error message


import vapoursynth as vs
core = vs.core
core.std.LoadPlugin(r'PATH\RGSF_x64.dll')

clip = core.std.BlankClip(format=vs.RGBS)
clip2 = core.ffms2.Source(r'PATH\test.gif')

rg = core.rgsf.RemoveGrain(clip, mode=1)

rg.set_output()



vspipe script.vpy - | ffmpeg -f rawvideo -pix_fmt gbrpf32le -s 640x480 -r 24 -i - -an -f null NUL


Maybe your ffms2 version ? Or maybe different RGSF ? I am using old version r5, the most recent compiled binary on github

[Quadratic]

I noticed that all third-party plugins were now broken, I spent the entire night removing everything Vapoursynth related from my system (scorched earth) and reinstalling everything.

Things are working again, including core.rgsf.RemoveGrain. I still do not know the root cause.

Thanks and apologies for my behavior.

[Myrsloik]

New release. Now the API4 builds are the normal builds. Audio support and performance for everyone!
Also windows 7 support is back since you can use both python 3.8 and 3.9 now.

Full blog post with the changes here (http://www.vapoursynth.com/2021/09/r55-audio-support-and-improved-performance/).

For the more conservative of you there's R55-API3 which is the same as R54 with a few bug fixes.

Have fun reporting bugs.

[Izuchi]

It doesn't seem like imwri is included in vsrepo, nor is it included with the R55 build so how can we get it exactly?

Edit: As a temporary solution, I copied the imwri binary from R54 API4 test1 build.

[Myrsloik]

It doesn't seem like imwri is included in vsrepo, nor is it included with the R55 build so how can we get it exactly?

Edit: As a temporary solution, I copied the imwri binary from R54 API4 test1 build.

Basically producing single dll windows builds is hard. What would be really helpful is if someone contributed an imagemagick port to vcpkg so I can easily do the rest myself.
Alternatively someone could use mingw/cross compile a single dll and contribute that.

Simply grab it from the R55 api3 portable archive if you really need it for now.

[Myrsloik]

What to do with https://github.com/vapoursynth/vs-imwri/blob/c961cd3adf9ca77eb580e2d2ee58d8c1fbbacd04/src/imwri.cpp#L40-L41 and https://github.com/vapoursynth/vs-imwri/blob/c961cd3adf9ca77eb580e2d2ee58d8c1fbbacd04/src/imwri.cpp#L45? Could you clean them first?

Probably cleaned up now.

[ChaosKing]

@Myrsloik Could you check if the vsrepo addgrain commit is the "correct" way of upgrading a plugin to hybrid api4 / api3 releases?

[Myrsloik]

@Myrsloik Could you check if the vsrepo addgrain commit is the "correct" way of upgrading a plugin to hybrid api4 / api3 releases?

It's not. See the correct place to specify api version here:
https://github.com/vapoursynth/vsrepo/commit/67ac70c35e82f593c7c7770879a1ea4af78360c4

[ChaosKing]

Thx. Kinda missed the example package.

[NullNix]

Hm. OK so after a bit of thrashing around creating new meson build systems for eedi3, miscfilters and removegrain, and diking out vs.YCOCG and vs.COMPAT from everywhere, I've tried current master out (commit ae11137cdf4605) with my own slightly-hacked-about copy of the wonderfully effective, unfortunately long-vanished-from-the-net G41Fun.RemoveGrain2. It seems to work!

But... I am sorry to report that rather than being 10% faster, with this workload v55 is consistently about 10% *slower* than v54 was, at 6.3fps rather than 6.9. I'll do some profiling and figure out where the speed is going :( perhaps a Broadwell-EX is not a "modern" CPU, but given that Intel are (still!) selling fairly-high-end servers with this CPU it's certainly not old. I was hoping for a speedup, dammit! *throws toys out of pram* (cost of pram: $0; obligations of pram manufacturer: nil, so I'll track this down rather than whining: or I'll try to: given how nondeterministic modern CPUs are, I'm not confident it'll be possible to identify a cause).

(This is using Python 3.9.7, Cython 0.29.24 and GCC off the 10 release branch as of May 21: not exactly a new GCC, but the rest is pretty up-to-date.)

[Myrsloik]

Hm. OK so after a bit of thrashing around creating new meson build systems for eedi3, miscfilters and removegrain, and diking out vs.YCOCG and vs.COMPAT from everywhere, I've tried current master out (commit ae11137cdf4605) with my own slightly-hacked-about copy of the wonderfully effective, unfortunately long-vanished-from-the-net G41Fun.RemoveGrain2. It seems to work!

But... I am sorry to report that rather than being 10% faster, with this workload v55 is consistently about 10% *slower* than v54 was, at 6.3fps rather than 6.9. I'll do some profiling and figure out where the speed is going :( perhaps a Broadwell-EX is not a "modern" CPU, but given that Intel are (still!) selling fairly-high-end servers with this CPU it's certainly not old. I was hoping for a speedup, dammit! *throws toys out of pram* (cost of pram: $0; obligations of pram manufacturer: nil, so I'll track this down rather than whining: or I'll try to: given how nondeterministic modern CPUs are, I'm not confident it'll be possible to identify a cause).

(This is using Python 3.9.7, Cython 0.29.24 and GCC off the 10 release branch as of May 21: not exactly a new GCC, but the rest is pretty up-to-date.)

Performance problems have been located. R56 will be faster again.

[NullNix]

Performance problems have been located. R56 will be faster again.

Aha great! If you need confirmation I'm happy to test. I'm just happy that a change of this magnitude broke so little! Nice backward compat, that.

In the meantime I have possible speedups in fftw -- ha ha like I can wring any more speed out of that, but some possibilities have occurred to me which I should investigate -- and maybe possibly in removegrain, which may be obsolete but is still costing me 4% of my CPU time doing a lot of insertion sorts :)

I might well be able to rope in some floating-point demigods whose shoes I am not fit to clean as well. Gosh it's convenient that my coworkers are spending time speeding up libm right now and are also interested in fftw. Why yes $MEGACORP it is a great use of your employees' time to speed up mathematical operations if it means that I can get a properly denoised blu-ray Red Dwarf set a day earlier than otherwise. YES IT IS.

(it will probably speed up a bunch of other simulation work too. And everyday use, apparently, though it escapes me how much everyday use needs FFTs and complex arithmetic. Denoisers in the sound domain, I suppose, though most of those are in hardware. And jpeg etc, I guess, though again those tend to implement their own stuff rather than using anything in libm, let alone fftw.)

[NullNix]

Hm. OK so after a bit of thrashing around creating new meson build systems for eedi3, miscfilters and removegrain, and diking out vs.YCOCG and vs.COMPAT from everywhere, I've tried current master out (commit ae11137cdf4605) with my own slightly-hacked-about copy of the wonderfully effective, unfortunately long-vanished-from-the-net G41Fun.RemoveGrain2. It seems to work!

I spoke too soon. --timecodes appears to be doing nothing. We get a timecodes file but it is always empty in my testing, as if outputError got set, but no error messages are displayed.

I'll look at it tomorrow (exhausted right now after LPC or I'd do it now), because I swear this worked in my first testing...

[NullNix]

I spoke too soon. --timecodes appears to be doing nothing. We get a timecodes file but it is always empty in my testing, as if outputError got set, but no error messages are displayed.

I'll look at it tomorrow (exhausted right now after LPC or I'd do it now), because I swear this worked in my first testing...

ok this is obvious, fixed :) PR submitted.

[Selur]

Does anyone have a Windows 64bit build of https://github.com/VFR-maniac/VapourSynth-ReduceFlicker ?

[Yomiko]

The link to isxdl.dll for building an installer is now redirected to "Inno Setup Dependency Installer". I ended up finding it from istool.

[vxzms]

Does anyone have a Windows 64bit build of https://github.com/VFR-maniac/VapourSynth-ReduceFlicker ?

You may be need https://github.com/chikuzen/ReduceFlicker

[kedautinh12]

You may be need https://github.com/chikuzen/ReduceFlicker

It's avisynth ver

[poisondeathray]

It's avisynth ver

it also has vapoursynth folder

https://github.com/chikuzen/ReduceFlicker/tree/master/vapoursynth

[ChaosKing]

The release dll is only for avisynth.

[Myrsloik]

The link to isxdl.dll for building an installer is now redirected to "Inno Setup Dependency Installer". I ended up finding it from istool.

Fixed. It's no longer needed.