Avisynth+

[wOxxOm]

Originally Posted by Groucho2004

... let me know if the memory usage that it reports is correct.

Tried setmemorymax(12000) n = 20000, got a 12-13gb mem usage, correctly reported, checked against processhacker/procexp.

[Groucho2004]

Originally Posted by wOxxOm

Tried setmemorymax(12000) n = 20000, got a 12-13gb mem usage, correctly reported, checked against processhacker/procexp.

OK, thanks for testing.

[Groucho2004]

@AVS+ devs
Any chance you could change the version string (from internal.h) to something more useful?
The build date and time should probably be moved to the change log.
I'm thinking more of a version string that clearly identifies the version (or build number) and whether it's a 64 or 32 bit build.

[ultim]

Originally Posted by Groucho2004

@AVS+ devs
Any chance you could change the version string (from internal.h) to something more useful?
The build date and time should probably be moved to the change log.
I'm thinking more of a version string that clearly identifies the version (or build number) and whether it's a 64 or 32 bit build.

I'll add the architecture (x86/x64) to the version string, but for now I'd like to keep using dates as actual version numbers. The reason is, choosing any "traditional" numbering scheme makes little sense. Should we call it 0.x or 1.0? That would confuse people thinking it is older than 2.6. Should we call it 2.6? Not good because Avs+ is evolving much faster right now than classic Avs. 3.0? 4.0? Those have already been used in Avs. For anything larger, we didn't even have that many releases yet.

Of course one can argue that Avs+ is a totally separate project from Avs and thus Avs's historic numbering scheme shouldn't affect our versioning. You might even be right, but those who don't live on these forums (unlike us) might still mistake Avs+ for Avs and vice versa, at least initially. Also, even if, when do we increment the main version? Every time when a major feature is added (which according to the wish-list will be more than a few)? Or we can go the Linux way for libraries that only reaches 1.0 when the API is stable.

Of course all the above questions can be decided upon arbitrarily, but the different answers would make different amount of sense to different people, depending upon how you try to interpret the version numbers. IMHO using the release date as the version avoids such interpretation ambiguities, because if you see "2013-11-25" nobody will try to give it a special meaning, aside from the fact that it was released on that date. Which version is older or newer still remains clear, even compared to classic Avisynth. And as an added benefit, it also makes it easier to search for the corresponding release post on the forums, or for the appr. Git commit if tagging is ever forgotten.

[qyot27]

'4.0' is AvxSynth, not the original project (and I wouldn't really expect anyone to bring that into the discussion because I really don't know how widespread the knowledge that AvxSynth calls itself '4.0' is; even so, anyone who does know that probably also realizes that AvxSynth was based on 2.5.8 and probably considers the '4.0' to be irrelevant to the topic). And 3.0 never really went anywhere; it stalled and died in development hell before it ever became useful. All I really want to say is that my objection to '4.0' isn't because of it already being used by AvxSynth, it's because I think '4.0' is an excessively large jump.

A '3.1' would be enough to distinguish it from the old AVS3.0, IMO. Or it could go like the classic one did and jump from 2.0->2.5 - no one mistakes AviSynth 2.5 for 2.0. 3.5 wouldn't get mistaken for 3.0, but like '4.0', I still think that's a bit much to suddenly jump to. The angle that it's distinctly referred to as AviSynth+ would mean that the following version number would be attributed to the project name that came before it - AviSynth+ 3.1 =/= AviSynth 3.0 (for one, AVS3.0 was going to be implemented in Ruby). If it does increment with every new major feature, then it would quickly gain a much higher version number and there'd definitely be little chance of getting Classic and Plus mixed up. It could also be counted retroactively: 3.0 for the initial fork, 3.1 for 64-bit (maybe?), and so on. Git's tagging feature can come in handy whenever a change on this does happen (whatever it ends up being).


That kind of argument aside, I'd say sequential revision numbers are even more preferable than a date (not the build time displayed in the output of Version(), the use of the date in the revision), since you can build an earlier revision at a later date, but you can never build an older revision with a newer revision number (barring Git branch trickery; but for this purpose, let's assume the use of master). Git can generate this information with 'git rev-list --count branchname'. The X.X version can be used alongside it for 'stable' releases (like x264 or FFmpeg do), but the sequential revision is always incrementing upward and it's easy to tell how many commits separate any two revisions taken at random. If you want to isolate it to only those commits unique to AviSynth+, then have a 'trunk' branch that only consists of the commits from 2.6's CVS and use ^ notation to subtract them: 'git rev-list --count master ^origin/trunk'

[turbojet]

Why not keep it simple and version 1, 2, 3, etc. like x264/x265 does?

Also avisynth dll's have always been difficult to tell the difference in without naming it manually. This could easily change.

[Jeroi]

Originally Posted by turbojet

Why not keep it simple and version 1, 2, 3, etc. like x264/x265 does?

Also avisynth dll's have always been difficult to tell the difference in without naming it manually. This could easily change.

I second this. The 3.0 and 4.0 was ridicolous already because one was more like planned version of avs and second was linux port by some company.

I would like to see Avisynth+ start from 1 when it gets first stable release. Until that there could be 0.0.0 versions for development.

[qyot27]

Originally Posted by turbojet

Why not keep it simple and version 1, 2, 3, etc. like x264/x265 does?

You're not being clear.

x264 0.140.2377+29 8d4d435
(libswscale 2.5.101)
(libavformat 55.21.100)
(ffmpegsource 2.19.0.0)
built on Nov 11 2013, gcc: 4.8.2
configuration: --bit-depth=8 --chroma-format=all --disable-opencl
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: GPL version 3 or later
WARNING: This binary is unredistributable!

The version number in this case is 0.140, which is analogous to AviSynth(+) using '2.6' or whatever. The 2377+29 is the revision number, which is actually what I was just suggesting with the use of git rev-list --count. Under that model, avsplus would be:

Counting all revisions to the master branch, including those from classic AviSynth:
git rev-list --count master = r1545

Counting only the unique AviSynth+ revisions:
git rev-list --count master ^trunk = r292


Just to put something in perspective here, 292 revisions back from the 2.6 CVS trunk is commit efe6aa3f1b95647c2301df6e503622d8d51b4ba3, from Tue Jul 1 07:08:59 2008 +0000 - which if I'm not mistaken, was during 2.5.8's development cycle (2.5.8 was released at the end of 2008). There have been as many commits to AviSynth+ in the last 2½ months as there have been to classic AviSynth in the past 5½ years.

[qyot27]

But to add a different idea about versioning, how about something like this:

0.6.1.2.1545 (or 292)

this translates to:

0 = a quasi-standard non-1 major version, similar to x264
6 = the value of AVISYNTH_INTERFACE_VERSION (currently it's still 5, but there's been talk of bumping it to 6)
1 = the value of a hypothetical AVSPLUS_INTERFACE_VERSION
2 = MINOR_VERSION, for bugfixes or other non-API-breaking stuff, perhaps on some sort of monthly or commit-valued schedule
1545 (or 292) = REVISION_NUMBER based on total commits or only commits to AviSynth+

This way, the versioning reflects actual versions that developers need to take into consideration. One rather baffling thing about the advertised versions in classic AviSynth is that they don't match up with the value of AVISYNTH_INTERFACE_VERSION. '2' was pre-2.5.6 or 2.5.7 (can't remember), 3 was through 2.5.8, 4 was unused, 5 was the 2.6 alphas, and either 5 or 6 might be the final one for 2.6.

With the above scheme, some numbers are always incrementing (minor version and revision number), while others stay the same until something big happens and breaks the API, upon which the MINOR_VERSION is set back at zero (REVISION_NUMBER always climbs).

Of course, omitting the 0 and just using INTERFACE_VERSION for the MAJOR_VERSION would also make sense. Even though that'd mean versioning would be 5.whatever for AVISYNTH_INTERFACE_VERSION, at least the number would have a distinct meaning. If the rationale was just 'let's go higher than AvxSynth to avoid confusion' it'd be perpetuating that problem. If the rationale is to make the internal and external versions consistent, then I don't object.

[ryrynz]

The only problem I have with that is I think you'll forever be x.6.x.x.xxxx, there just aren't enough commits to Avisynth for it to be worth it basing Avisynth+'s version numbering off of it.
It should just have it's own version numbering system, this can happen whenever Ultim prefers to switch to it.

[ultim]

I'm still not convinced that any of these alternatives is better than dates (maybe with the exception that the build date does not necessarily equal the commit date). But there seems to be a consensus here and even on IRC that version numbers are better than dates (for whatever unnamed reason). Also the whole versioning "issue" is really not that important to me, so, fine, let's change it. But at least let's keep it simple and avoid "0.6.1.2.1545"-hell. If you're fine with it, I'd propose rXXXX-style sequence numbers (based on git rev-list --count master), tagging official releases x.x(.x)-style too.

[Groucho2004]

Originally Posted by ultim

If you're fine with it, I'd propose rXXXX-style sequence numbers (based on git rev-list --count master), tagging official releases x.x(.x)-style too.

Works for me.

[qyot27]

rXXXX is fine by me - I used that notation in the CLI build guide alongside the output of the date command, and tend to find sequential revisions more informative than point versions most of the time.

My basic point was that a MAJOR.MINOR[.MICRO] type of point version should reflect *something* about the API directly, such as the interface version (if there is/are plans to have a discrete AVSPLUS_INTERFACE_VERSION, that would be the obvious choice).

[turbojet]

I had forgotten x264 had versions other than revision, always seen it referred to as revision number.

Is there any other filters besides resizers that use softwire? Or is there any other filters that may be slower than avisynth on an amd cpu?

Does a pull request for this help out? Or is 'issues' more appropriate?

[TurboPascal7]

Originally Posted by turbojet

Is there any other filters besides resizers that use softwire? Or is there any other filters that may be slower than avisynth on an amd cpu?

Filters that used softwire: Limiter, RGB<->YUV conversions (YV24, Y8, YUY2, BackToYUY2). Don't remember anything else.
Filters that may be slower on an amd cpu: no idea. No one tested.

Originally Posted by turbojet

Does a pull request for this help out? Or is 'issues' more appropriate?

Pull request is when you want to contribute e.g. some code to the project. Issues is more appropriate but there is no need. We played around with it a bit and decided that possible optimizations are not worth it right now. So yeah: for the time being, singlethreaded performance of resample filters will be worse in avs+ on some CPUs (this also affects sandy/ivy bridge afaik).

[turbojet]

Originally Posted by TurboPascal7

Filters that used softwire: Limiter, RGB<->YUV conversions (YV24, Y8, YUY2, BackToYUY2). Don't remember anything else.
Filters that may be slower on an amd cpu: no idea. No one tested.

Would it help development to have these tested on AMD?

Pull request is when you want to contribute e.g. some code to the project. Issues is more appropriate but there is no need. We played around with it a bit and decided that possible optimizations are not worth it right now. So yeah: for the time being, singlethreaded performance of resample filters will be worse in avs+ on some CPUs (this also affects sandy/ivy bridge afaik).

Thanks for the explanation, I noticed you wrote pull requests were welcome in a reply about the slower performance but I wasn't sure if it was requested towards me.

[TurboPascal7]

Originally Posted by turbojet

Would it help development to have these tested on AMD?

Right now - not really. You're welcome to post your results and we might look into performance drops if there are some significant ones (which I really doubt because all other filters weren't nearly as optimized as resamplers) but we aren't specifically working on optimizing core filters right now since there is a lot of more important things to do.

[Groucho2004]

Originally Posted by TurboPascal7

So yeah: for the time being, singlethreaded performance of resample filters will be worse in avs+ on some CPUs (this also affects sandy/ivy bridge afaik).

Did a quick test with some resizers - it's about 20% slower on my i5 2500K. Possibly worth mentioning, AVS+ uses more memory than the official Avisynth. With a script like this:

colorbars(width = 1920*2, height = 1080*2, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
spline36resize(width() - 64, height() - 64)
spline64resize(width() + 64, height() + 64)
bicubicresize(width() - 64, height() - 64)
sincresize(width() + 64, height() + 64)

AVS+ uses ~150 MB, the official Avisynth ~ 55 MB.

[turbojet]

Originally Posted by TurboPascal7

Right now - not really. You're welcome to post your results and we might look into performance drops if there are some significant ones (which I really doubt because all other filters weren't nearly as optimized as resamplers) but we aren't specifically working on optimizing core filters right now since there is a lot of more important things to do.

OK I'll pass on it for now.

Originally Posted by Groucho2004

Did a quick test with some resizers - it's about 20% slower on my i5 2500K. Possibly worth mentioning, AVS+ uses more memory than the official Avisynth. With a script like this:

colorbars(width = 1920*2, height = 1080*2, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
spline36resize(width() - 64, height() - 64)
spline64resize(width() + 64, height() + 64)
bicubicresize(width() - 64, height() - 64)
sincresize(width() + 64, height() + 64)

AVS+ uses ~150 MB, the official Avisynth ~ 55 MB.

http://forum.doom9.org/showthread.ph...96#post1655396 what were you benchmarking here? The numbers got me really optimistic.

[Groucho2004]

Originally Posted by turbojet

what were you benchmarking here? The numbers got me really optimistic.

Different script, different resolution, apples and oranges...