AviSynth+ thread Vol.2

[manolito]

Personally I do not use MEGui, but just looking at the MEGui threads at Doom9 and seeing how active they are I can only assume that a lot of folks do use MEGui.

AviSynth is not a software which is used by itself, it is a frame server which is used in conjunction with other software. So I believe that the AVS devs always must keep an eye on this other software which depends on AviSynth.

Releasing a new AviSynth version without even having tested it with MEGui and some other encoder GUIs is simply embarrassing. Why are you AVS+ devs in such a hurry to push out your latest and coolest achievements? Can't you just leave this turf to VS?

[Stereodude]

Originally Posted by manolito

Why are you AVS+ devs in such a hurry to push out your latest and coolest achievements? Can't you just leave this turf to VS?

Perhaps a better question that should be answered first is what tangible problems are they trying to fix/improve that even warrant these dramatic changes (that break things)?

[Groucho2004]

Originally Posted by manolito

Releasing a new AviSynth version without even having tested it with MEGui and some other encoder GUIs is simply embarrassing.

That's a matter of opinion, I suppose. I think the "GUI" guys should keep up with current developments and update their Avisynth interfaces accordingly. Hard-coded interface versions such as found in the megui wrapper are ridiculous.

[pinterf]

Originally Posted by manolito

Not happy with AVS+ 3.6...

[...]
Whenever an AVS filter in Staxrip is added or modified, the filter will be called to test it, and after a successful test the process will be terminated and released from memory. With AVS+ 3.6.0 this does not work any more. My source filter is DSS2Mod with LAV Filters, and now I get at least 3 instances of the LAV splitter and LAV Video source filter.

When something is kept in the memory it's not normal, and it means the resource if not freed up properly.

Question 1:
I have found DSS2mod on an Internet wayback machine linked from Avisynth.nl, is it the latest one?
Question 2:
Are you using the avss_26.dll?

[manolito]

1. I believe it is.
2. Yes, I do use avss_26.dll, dated from 2014-10-05

Right now I am in the middle of a long encode, I will test how ffms2 and LSMASH behave under AVS+ 3.6 ASAP and report back.

[MeteorRain]

It is very arguable. MeGUI is coded to work with a specific range of avisynth versions. It's the author of MeGUI's responsibility to support new versions. If you use a toolkit package like MeGUI where it maintains its own tool sets, use that, use whatever version it tested with.

If MeGUI was tested with 2.5, use 2.5 and not 2.6 2.7 3.0 3.6 3.7 4.0 or anything else, or it's your risk of having things broken, or your work to get it fixed.

[Groucho2004]

Originally Posted by MeteorRain

MeGUI is coded to work with a specific range of avisynth versions.

I have never used megui so I wonder what that means. As I understand it, megui is just a frontend for various encoders and uses Avisynth to gather information about the source file/script. So, if I'm correct it just has to load the script and extract the information from it, right?

[manolito]

Originally Posted by manolito

I will test how ffms2 and LSMASH behave under AVS+ 3.6 ASAP and report back.

ffms2 behaved nicely under AVS+ 3.6, but LWLibavVideoSource did not. I used the latest STVG and Holywu versions. So I still will go back to AVS+ 3.51

[StainlessS]

As time goes on relentlessly, so some apps get stuck in time warp, not sure, think MeGUI devs have been abscent now for some time (I aint updated
MeGUI for maybe 9 months [actually stable XP build for maybe 2+ years], as some things just dont work for XP, and if it dont work for that, then is of little use to me).

I have never used megui so I wonder what that means.

As various whotsits change, so args etc [EDIT: or even OS version compatibility] change and so no longer comply with MeGUI expectation of function arguments etc, ie no longer work proper/at all.

EDIT: And if one thing dont work proper, the whole shabang can/will fail.
EDIT: Just like Smaug's missing scale, one small imperfection and that damn iron arrow killed the cute cuddly little critter.

[StainlessS]

Originally Posted by tebasuna51

MeGUI is a Windows soft and don't need the Avs+ 3.6.0 new version. Also there are plugins than don't work with this new version.

Use the Options -> Main -> Always use the included AviSynth

Above good advise. [Above from one of the MeGUI threads]

Also, maybe about time that Avisynth(+) had a thread in Avisynth Usage forum, where current stable build should be posted, not really right that
users have to visit devs forum for what might be a stable version.
(this has always been a problem, and not just Avisynth, several other culprits [among many] being ffms2 and LSMash, mvtools, masktools and more)
(devs dont like dirtying their hands talking to users, I can appreciate that, I dont likem' either, nothing but trouble).

[videoh]

Originally Posted by StainlessS

devs dont like dirtying their hands talking to users

What a load.

[StainlessS]

What a load of bullcrap.

Agreed, really sad, time for Usage forum threads.

EDIT: Usage forum thread originator need not be constantly present, others would probably be more than happy to give advice there,
its just somewhere where users can ask a simple question without feeling that they are intruding into the devs area,
it scares the hell out of me just reading stuff in devs forum.

EDIT: JohnMeyer [somebody some devs may / or may not have heard of] said some time ago that he
did not visit devs forum often / at all, so could be a mistake to think that lesser mortals visit devs forum at every opportunity

[qyot27]

Originally Posted by real.finder

since I am not with or against new fork but if it will be new fork in the end, then maybe better call it AvxSynth+ (since there are old AvxSynth) because it work in Linux and so

There's no need to fork anything (and let AvxSynth rest in peace; the only reason it even had a different name was because it was not a 1:1 extension of AviSynth onto Linux - it was a separate port based on a not-even-current-at-the-time version of AviSynth, and it lost the ability to build on Windows at all, never mind all the other things that were idiosyncratic to it). If there are important fixes that users want applied to an older release series, they can be either backported from the master branch or written explicitly for the older branch. Look at many other projects out there that have periodic bugfix releases for older branches in parallel with releases from the current stable branch.

We've not had to do so yet, but the means to facilitate it already exists: every time a new release series happens, I create a branch for it. 3.4 has one, 3.5 has one, 3.6 has one. Since 3.4 had only one release, and 3.5 had two, those branches basically just tracked the current state of the master branch at the time. All someone needs to do is request something to be backported, and after a certain amount of time/number of commits have accumulated in the older release branch, a new bugfix release from that branch could be made. But that requires actually notifying us of changes that should be backported, and for the user to know it was fixed in a later version to be able to ask in the first place (meaning: we will ask you if it works in the current release or git version; if you can supply the commit hash itself, even better). I would generally consider the 3.4 branch as end-of-life unless there's some catastrophic reason to issue a bugfix for it, not least because having support for more OSes means more eyes potentially looking at the code and finding issues to fix. And 3.5 is the baseline for the other OSes because it's the first one that supports them. 3.6 would be a similar baseline for non-x86 processors, although the ability to do so would be a candidate for backporting to 3.5 (it was originally developed against 3.5.1, but I don't think I have the old 3.5.1-based branch around anymore).

And, for that matter, anyone that wants to actively contribute can help us by assisting with that backporting effort and then opening a pull request so that it gets applied to the upstream repository. Because of the fact that we do support Linux now, this division of labor between development branch/current stable/old stable is part-and-parcel of the way many Linux distributions or FOSS projects in general operate, and I'd expect that something like this will end up happening anyway as any hypothetical maintainers of AviSynth+ packages in various repositories find things that need bugfixes for what their distro ships¹. There still comes a point where old branches are just left alone, but a new release series does not mean the automatic end of the old one, git allows them to be maintained in parallel, albeit probably with reduced frequency for the older branches unless we suddenly get a flood of new contributors that accelerate the main branch's development and can simultaneously identify all the things that can be backported to older releases.

¹because distros that operate on point release versions themselves will often prefer to stick to a particular release series for one or several iterations of the main distro, before finally making the switch some time later. For instance, if AviSynth+ had miraculously gotten an upstream package in the repositories for Ubuntu 20.04 LTS, it would have frozen 3.5.x and only possibly package subsequent bugfix releases from the 3.5 branch. 20.10, 21.04, or 21.10 might also stick to shipping 3.5.x, only moving to 3.6.x during the cycle for 22.04 LTS (and by that time, who knows if we'll still be actively on the 3.6 branch or have moved up to some other milestone). The cycles are long and that means probably having to field support questions on a particular release.

[FranceBB]

Oh boy, it broke everything here on XP x86 (SSE4.2 capable CPU).

ColorBars(848, 480)

Access violation in AVSMeter 2.9.9.3, total freeze followed by a crash without any report in VirtualDub2 build 44282.

SetMaxCPU("C")
ColorBars(848, 480)

Access violation in AVSMeter 2.9.9.3, total freeze followed by a crash without any report in VirtualDub2 build 44282.
3 errors one after the other on avs2yuv.exe





ffmpeg instead complains about my SetMaxCPU("C"):



so I removed it and tried again with just ColorBars(848, 480):



I thought it was going to work as it correctly received both the audio and video stream, however it quickly stopped encoding and it generated a completely empty (0 byte) output file:




avs4x264mod.exe:



AVSEditPlus 1.25 crashes without any error.
Avisynth_ProxyGUI:





Potplayer version 1.7.21212 (latest):



but then, when I was going to abandon every hope, I found out that MPC-BE was working just fine! It's really weird!




"It cannot be!" I though, so I tried with a different script which involves at least an external filter such as ffms2:

FFVideoSource("Analog_bad_source.avi")

And there it was, working as expected.

So I tried a few filters like:

FFVideoSource("Analog_bad_source.avi")

neo_dfttest(sigma=64, tbsize=1, Y=3, U=3, V=3, dither=0, opt=0)

and suddenly it became black. No error, it did allocate RAM, but the window was completely black:



So I thought: "I got it! It must be some incompatible plugin!"
So I removed every plugin from plugins and plugins+ and I ran AVSMeter again, but... nothing. Still access violation.
I even checked Avisynth.dll with Dependency Walker just to make sure, but everything was fine and of course I have all the C++ Redistributable and .NET Framework installed, so... what's going on?

Setup Log: https://pastebin.com/M5LizfCW

[poisondeathray]

I got some weirdness with AviSynth+_3.6.0 (files only install), tested in avspmod x64 and vdub x64

colorbars(pixel_type="YV12")
qtgmc()

error message

Script error: expected `)'
((null), line1, column 4)
(SMDegrain 3.1.2.104s.avi, line 879)
(QTGMC_3.364.avsi, line 186)

smdegrain line 879

    IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0

qtgmc line186

	        sisphbd = AvsPlusVersionNumber > 2294

Reverting back to 2.5.1 works ok

[StainlessS]

I am reluctant to class avs+neo, same as, the Nekopanda Avs Neo, cant really compare them, dont know what to do with either
but they are not similar.
EDIT: The script writer has to make some sense of it, but there aint any.

EDIT: Above rant related to "IsAvsNeo".

[stax76]

I had to do some updates and minor tweaks but after that everything works.

[real.finder]

Originally Posted by poisondeathray

I got some weirdness with AviSynth+_3.6.0 (files only install), tested in avspmod x64 and vdub x64

colorbars(pixel_type="YV12")
qtgmc()

error message


smdegrain line 879

    IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0

qtgmc line186

	        sisphbd = AvsPlusVersionNumber > 2294

Reverting back to 2.5.1 works ok

update qtgmc and smdegrain

[poisondeathray]

Originally Posted by real.finder

update qtgmc and smdegrain

I did today already; is there anything newer than these ?

(SMDegrain 3.1.2.104s.avsi, line 879)
(QTGMC_3.364.avsi, line 186)

[real.finder]

Originally Posted by poisondeathray

I did today already; is there anything newer than these ?

(SMDegrain 3.1.2.104s.avsi, line 879)
(QTGMC_3.364.avsi, line 186)

Check the Thread in my signature