Vapoursynth

[Myrsloik]

Originally Posted by Selur

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]

Originally Posted by 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.p...73#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/mu...sfunc.py#L4636

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

[ChaosKing]

If I replace the 3 expr lines https://github.com/WolframRhodium/mu...sfunc.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.

Originally Posted by 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

I understand and thanks, Convolutions have already been implemented where possible here: https://github.com/Irrational-Encodi...rdry/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]

Originally Posted by 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.

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.

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]

Originally Posted by 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.

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]

Originally Posted by HolyWu

What to do with https://github.com/vapoursynth/vs-im...ri.cpp#L40-L41 and https://github.com/vapoursynth/vs-im.../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]

Originally Posted by ChaosKing

@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/vsrep...a1ea4af78360c4

[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]

Originally Posted by 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.)

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