Avisynth 2.6 MT [Archive] - Page 4

johnmeyer

20th April 2011, 17:57

I don't know where you heard the fact that avisynth 2.6 dropped RGB24 support...
but that's a complete lie: It's still supported.Supported or not, it no longer works for me and my particular workflow. It used to work just fine.

For 7+ years I have been frameserving out of Sony Vegas Pro into AVISynth scripts. I use the frameserver available from Debugmode (http://www.debugmode.com/frameserver/).

When you start the frameserver from Vegas, you get this dialog:

http://i177.photobucket.com/albums/w208/johnmeyer/Frameserver.gif

For seven years, I have chosen either RGB24 or YUY2, depending on my workflow, plugins used in the AVISynth script, etc. I never had a problem.

For the past several years I have been using AVISynth 2.5.8.5 multi-threaded. The DLL is dated 8/16/2009 and has the name "Jeremy Duncan August 16, 2009" in the Special Build section. This has worked very well, and works with the RGB24 option shown above.

However, in order to get better stability with the QTGMC script in multithreaded usage, I updated to AVISynth 2.6 multithreaded. The DLL is dated 8/16/2009 and is MUCH larger (1,676 KB vs. 339 KB). There is no identifier in the DLL.

When I attempt to open an RGB24 output from the frameserver, using an AVISynth script that is just one line:

AVISource("e:\frameserver.avi")

I get this error message:

http://i177.photobucket.com/albums/w208/johnmeyer/AVISynthErrorMessage.gif

RGB32 and YUY2 continue to work as they always have, but RGB32 is MUCH slower (2-3X slower) than RGB24 (or YUY2) because of the conversions done out of Vegas and perhaps because of the larger data set created. It does work just fine.

Because of subtle color shift errors when serving out using YUY2 into a script that uses QTGMC that don't happen when serving out RGB24, I would prefer to use RGB24. But, if I go back to the earlier version of AVISynth, I get stability issues in multi-threaded mode (although only with QTGMC). Typical engineering tradeoff.

So, in support of what nhope says above, I too have found that AVISynth 2.6 -- at least this particular build -- does not handle something that has worked for over seven years (for me).

Perhaps there is a different 2.6 MT build somewhere that doesn't have this problem?

kemuri-_9

21st April 2011, 00:09

Perhaps there is a different 2.6 MT build somewhere that doesn't have this problem?

chances of that slim, since to my knowledge, no one else has really developed a 2.6 MT build at all...

SubJunk

3rd May 2011, 08:15

Hey guys,
I just added version information to this build because of some programs (like SVP) that read the AviSynth version.
Feel free to grab it from here (http://www.spirton.com/uploads/AviSynth/AviSynth-2.6MT-WithVersionInfo.zip).

It is exactly the same as the 2009.09.19 build from the first post, but with the added version information.

wOxxOm

4th June 2011, 15:54

AVS 2.6.0 Alpha 3 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/) __MT__ anyone?

markanini

4th June 2011, 19:42

AVS 2.6.0 Alpha 3 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/) __MT__ anyone?

Plus one

JEEB

5th June 2011, 16:34

MT was removed from the trunk, and, unless one of you wants to start developing a more working "multithreading" Avisynth, I think you should stop calling it out as if it was something easy to do.

Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.

Chikuzen

5th June 2011, 19:46

Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.

plus one

um3k

6th June 2011, 01:37

I wonder if ThreadRequest (http://forum.doom9.org/showthread.php?t=154886) could be utilized in lieu of native multithreading capability? I know I saw a script somewhere that used it to emulate the SetMTMode functionality (though it is not limited to such use). Might be worth considering.

Zep

6th June 2011, 11:58

Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.

You may not like how it was implemented but fact is i get a 4X speed increase with it and unless you can and are developing a better model you should zip your lip and stop being so critical of others hard work.

kemuri-_9

6th June 2011, 13:34

You may not like how it was implemented but fact is i get a 4X speed increase with it and unless you can and are developing a better model you should zip your lip and stop being so critical of others hard work.

A) Sounds like you're satisfied with your current version of avisynth MT, so don't upgrade.
B) the MT model that was developed is flawed, that's the reason IanB pulled it out of the code in the first place.
C) MT models are generally not that easy to develop and it will take a lot of thought and discussion to get one that is simultaneously useful and stable, which may or may not end with requiring a break in backwards compatibility.

JEEB

6th June 2011, 15:09

You may not like how it was implemented but fact is i get a 4X speed increase with it and unless you can and are developing a better model you should zip your lip and stop being so critical of others hard work.
You're misreading that part of my post.

I'm not being as critical towards the back-then developer, as towards the people that think that the multithreading was removed from the trunk for no reason, and the people who think that bringing back this removed-by-main-developer feature would be easy as pie or even recommendable.

Otherwise kemuri-_9 has served all your needs and added a clear commentary on your position.

RedDwarf1

6th June 2011, 17:54

A) Sounds like you're satisfied with your current version of avisynth MT, so don't upgrade.
B) the MT model that was developed is flawed, that's the reason IanB pulled it out of the code in the first place.
C) MT models are generally not that easy to develop and it will take a lot of thought and discussion to get one that is simultaneously useful and stable, which may or may not end with requiring a break in backwards compatibility.

For some things it can make a very big difference. XVid encoding and the QTGMC de-interlace script to name but two, benefit from the old multi threading method.

For most HD encoding it makes no real difference or is not supported which I suspect is the real reason why some people are slamming it and saying forget it. It was done already using earlier AVISynth code, so how can the current AVISynth 2.6 MT version be that much different from the latest alpha 3 release, apart from the bug fixes and speed ups etc?

pbristow

8th June 2011, 01:36

Priority is surely to get a feature-complete and (reasonably) bug-free 2.6 (single-threaded) first. *Then* people can add in whatever version of MT seems best at that point. Straightjacketing the development of 2.6 to fit a model of MT that probably isn't the one we'll be using in future would be short-sighted, IMHO.

If anyone wants to create their own build of 2.6.0 Alpha 3 with added old-style MT code and see what happens, they're perfectly at liberty to do so, as I understand it.

asarian

11th June 2011, 11:26

So, dummy question here, but will AviSynth 2.6 no longer support multi-threading? Because that's what I'm getting from the above posts.

Would be very sad if that were the case, though. I was ere hoping we'd finally get an AviSynth version that could do multi-threading in a more robust way.

And I guess this is probably not a good time to ask for a stable 64-bit version of AviSynth, is it? :) Seriously, though, the need for multhreading -- in my cases -- is often born out of sheer necessity with the MCTemporalDenoise script, that's often just too memory/resource hungry to deal with full 1080p as a single chunk. So, an actual non-buggy non-memory-leaking-like-crazy 64-bit version of AviSynth would go a long way to avoid having to go multithreaded.

pbristow

11th June 2011, 12:30

asarian: It's not a question of "no longer" supporting multi-threading. MT has always been something that was *added* to the single threaded versions of AVIsynth after they were complete. [EDIT: OK, that's not really true. What I mean is, MT is an additional feature on top of the core features of AVIsynth, and has never really been a comfortable fit - hence the many problems with using it. So we have non-MT development focussed on getting the other features right, and then MT development running parallel with that, somewhat behind.) It is up to the folks who produce the MT versions to decide whether they want to do an updated MT build based any new single-threaded build.

[EDIT: And in the meantime, people are deliberating *better* ways to do multithreading in future.]

Remember, this isn't a commercial project with a boss dictating what the roadmap should be. It's a community project, where what happens depends on who's got the time, the skill, and the commitment to do what. Sketching out and agreeing roadmaps is a good idea, so that the developers can all work towards common goals rather than working at cross-purposes; but what we've seen with the AviSynth 3.0 project is that too ambitious a roadmap for the resources available just leads to stagnation and frustration all round. It's smart to keep the goals smaller and more incremental, more tightly focussed: That way, the new developments actually get finished someday.

(N.B. I am not and never have been an AVIsynth developer, just a keen user, but I've been a developer for other things and had to deal with these kinds of issues.)

Ziddy76

13th June 2011, 01:52

Not to be a dick, but I would hope in 2011, any project would want to be efficient MT. Just about everything it multi-core now, hell even the Tegra has 4 cores now.

Mini-Me

13th June 2011, 07:44

Not to be a dick, but I would hope in 2011, any project would want to be efficient MT. Just about everything it multi-core now, hell even the Tegra has 4 cores now.

The most scalable multi-threaded software tends to exploit fine-grained data parallelism to multi-thread specific areas. There are LOTS of areas for this in video filtering, but from a design standpoint, they're best handled by the authors of individual filters.

Unlike LaTo's SmoothLevels, most filters are not actually coded to be multi-threaded all by themselves, and people are demanding a generic coarse-grained solution from Avisynth developers to "fix" this. Implementing a top-down solution restricts the possibilities for parallelization, because the Avisynth developers cannot actually know how individual filters are going to access data. Some filters rely on neighboring pixels in the same frame (sometimes large neighborhoods), and some filters rely on pixels from neighboring frames (sometimes with a large radius).

Splitting the video spatially requires overlap for correctness, and the more overlap there is, the less effective parallelism becomes (and some filters need the whole picture). Splitting the video temporally can be both robust and effective, as long as filters don't rely on internal state or global variables. (Some of the MT modes actually allowed various levels of stateful behavior, but there's always a price). Ideally, this kind of parallelism should only be limited by memory (cache memory and possibly memory for separate filter instances). However, that limit can still become quite limiting if you have lots of threads and you're chaining a whole bunch of filters and/or using filters that access temporal neighbors.

Although it's not as effective as finer-grained parallelism, splitting the video temporally is a good concept. That's how the modified MT version of Avisynth worked (not the MT function, which worked spatially), but more knowledgeable posters have indicated that it was still broken. If Avisynth had been written from the ground up around this concept, I'm sure it would work great. The problem is, it's hard to hack multi-threading support into existing software that's built on lax data access/modification patterns, and it's a loooooooot harder when that software interacts with arbitrary filters written by other authors.

Ultimately, programs like Avisynth are among the most difficult possible pieces of software to safely multithread. Patching up Avisynth by itself is one thing, but whatever scheme the developers decide to use, a lot of individual filters will need to be fixed to follow it. I can understand why they want to dot their i's and cross their t's before making any final decisions.

Rumbah

13th June 2011, 13:19

I agree that the filters themselves should be mutithreaded (Avisynth could offer mechanisms for that).

But it would be great if the common built in ones would be multithreaded, e.g. the resize filters. It's one of the most used task and it would be great if someone could implement them multithreaded.

ianken

18th June 2011, 09:33

I dunno what the answer is here. But I do know that when I have a script running at 6fps and chewing 10% or less CPU on a 4Ghz six core rig I get cranky. :-)

The old MT solution (hacky as it is) helped a lot. Alas, it's a bug farm and a crap shoot.

-Ian

Didée

18th June 2011, 11:53

asarian

18th June 2011, 12:21

The old MT solution (hacky as it is) helped a lot. Alas, it's a bug farm and a crap shoot.

-Ian

I agree. I have the greatest respect for people involved in developing the new AviSynth, but I need MCTemporalDenoise to work properly, and for that I often really need the job split up over several threads, otherwise something runs out of memory. I know, 'something' is rather vague; but I imagine the 'solution' of multi-threading to lie along the lines of memory requirements being squared, where, say, schematically, 3 threads of 4^2 yields only 48, whereas 1 single thread of 12^2 gives a whopping 144! So I will stay with AviSynth 2.5.8 for the time being.

Also, yeah, the underusage of CPU on a single thread, even when it doesn't crash for one particular HD source, still feels like a waste.

pbristow

18th June 2011, 20:49

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

Heh. :) Certainly MVTools is a challenge to try to multitask "from the outside", and is a prime candidate for having it's own built-in multithreading. For example, I would specify an mt version of MAnalyse so that each thread generates one quarter (if there are 4 threads) of the motion vectors for the output clip, but has access to the whole of the two input frames for matching, so that "out-of-region" matches can still be done accurately without the need for overlapped/duplicated processing (as happens currently when using MT() with a big enough overlap to cover out-of-region motion).

ianken

18th June 2011, 22:37

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

I've observed the same. Unfortunately those tools are the heart of the most capable video-de-hosing scripts.

I've got a script now that 1) plays fine in MPC-HC with setmtmode(2) and rips along at 26fps but load it in vdub and *boom* crash in mvtools. Remove setmtmode and it's weaksauce at maybe 5fps. And this is purely SD content. It doesn't even use an entire single core when running single threaded.

So, I acknowledge that multithreaded coding is a huge challenge. No doubt. But I would hope that somewhere on the AVS roadmap is some sort of plan to allow users to take advantage of their modern rigs. Even if that means that with Version Foo.Bar we make a hard break with the existing architecture and in order to get awesome multi-core perf we need all new MT-safe plugins following a new model.

Sometimes you need to give backwards compatibility the finger.

CruNcher

19th June 2011, 12:29

I can't tell if or by how much the current MT solutions are bugged at the core level. However, it seems that the problems are mainly caused by high memory usage. When multithreading fairly easy scripts, even with HD sources, you'll be hard pressed to find any problems.

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

For me its basicly a hit and miss thing my own scripts (simple ones, coded for speed trying to avoid complex stuff) work rather great in every Avisynth enviroment but for example scripts like MCTD either crash imidiatly trying to optimize them or crash after a while depending on the used Avisynth version lastly i got this error out from 2.6 Alpha with MCTD (trying to threadrequest)

avs [error]: Softwire: caught an access violation at 0x059b4843(code+395),
attempting to read from 0x00000000 occurred while reading frame 2058

with SVPs (OpenCL modified Motion Interpolation 2.5.8 .dll it crashes immediately @ execution ;) )

so yeah it's rather a hit and miss thing currently but once it works it's worth it :)

though the problem is also mvtools now exist in @ least 3 custom versions and then you have 2 different masktool avisynth versions + a mod version ;) and per script you are mostly forced to change your entire workflow that this can't be good is obvious and some guys should really think about building better synergies together.

SEt

14th July 2011, 14:19

Another threading bugfix + updated to CVS version of Avisynth.

I suggest changing SetCacheHints return value to something like intptr_t for obvious reasons.

Groucho2004

14th July 2011, 14:58

Another threading bugfix + updated to CVS version of Avisynth.

Could you post the source for this MT version? I see you included some source files but what about for example avisynth.h?

SEt

14th July 2011, 15:23

See the existing.diff for difference in files already in CVS.

Groucho2004

14th July 2011, 15:36

See the existing.diff for difference in files already in CVS.

Yeah, I saw that. Sorry to be a nag but I've never used CVS, can you not just upload the changed files somewhere?

Boulder

14th July 2011, 15:43

Thanks a lot for the new build! :)

SEt

14th July 2011, 15:57

No, I'm not going to post full sources with builds. If you have 'unchanged' files - you can always apply the diff manually. Also, mentioned 'threading bugfix' is only in cacheMT.cpp.

Boulder

14th July 2011, 18:48

I suggest changing SetCacheHints return value to something like intptr_t for obvious reasons.

Does this mean that (most) plugins need to be recompiled?

I tried the new build but I get only 25% CPU utilization on my quad-core (upon playback in VDubMod). The previous build maxes out the CPU with the same script.

SEt

14th July 2011, 19:29

Oops, I forgot to auto-add distributor to regular scripts. Redownload who got earlier version.

No recompilation unless they need to identify as caches, and it just underwent even greater change from void to int.

Boulder

14th July 2011, 20:36

Thanks, the new build works just fine.

Didée

14th July 2011, 22:37

No recompilation unless they need to identify as caches, and it just underwent even greater change from void to int.
Sorry if I'm a bit thick, but this does mean exactly ... what?
What's the scenario where a filter "needs to identify as cache"?

SEt

14th July 2011, 23:00

For example ffdshow interface for avisynth is good candidate for such cache identification when "Buffer back/ahead" is turned on - no need to insert another cache after it and waste memory.

yup

15th July 2011, 05:16

SEt:thanks:
Your build based on Avisynth 2.6 Alpha 3?
yup.

Boulder

15th July 2011, 05:45

The build is from the latest CVS sources so the code is as fresh as possible.

levi

16th July 2011, 20:16

Another threading bugfix + updated to CVS version of Avisynth.

Thanks Set! This rocks! Any chance we could see a 64 bit compile?

SEt

16th July 2011, 21:29

Maybe. I'm not very interested in 64-bit build now as I have only 6GB of ram and if you really want you can run some time-critical 64-bit code in 32-bit process too.

SEt

19th July 2011, 18:11

Updated to fix two ImageSource() errors. (Discussed here (http://forum.doom9.org/showthread.php?p=1513799) and here (http://forum.doom9.org/showthread.php?t=161953))

Büke

20th July 2011, 18:31

Mini-Me

20th July 2011, 22:00

How about a plugin that loads any avs script into multiple processes, processes about 300 frames in each process, with 30 frames overlapping, sequentially combining the results in the master avs for final processing and encoding.

Additionally, the plugin can restart the processes to clear memory leaks.

AFAIK, coding this as an Avisynth plugin would be exceedingly difficult or even impossible, given how Avisynth works. However, it's manageable for an outside piece of software...and while I haven't tested it myself, Chikuzen has written a Python script for AvsPMod that works very similarly to what you're describing. (http://forum.doom9.org/showpost.php?p=1507911&postcount=18)

Büke

21st July 2011, 05:13

AFAIK, coding this as an Avisynth plugin would be exceedingly difficult or even impossible, given how Avisynth works. However, it's manageable for an outside piece of software...and while I haven't tested it myself, Chikuzen has written a Python script for AvsPMod that works very similarly to what you're describing. (http://forum.doom9.org/showpost.php?p=1507911&postcount=18)

Why would it be so difficult? Interprocess hosting and communication is often done nowadays in the audio plugin world (VST, etc.) for crossing 32-64 bit barriers, for extended memory and stability, and it is done with quiet the low latency, too.

The master plugin needs an exe host counterpart listening for commands from the scheduling master, loads and hosts the given avs, caches the requested frames and sends them back in raw format, it can even use portions of TCPServer() code.

Now I think about it, the overlapping frames are not even necessary, since Avisynth can deliver random access frames as requested by the script and plugins on demand. Runtime scripts often do not (and should not) use progressive global state variable manipulation, as most are made to be randomly seekable. This means, the processes can process less frames in parallel, such as 10-100, and maintain low memory overhead.

Macro parallelization via master controlled sub-processes is a real generic solution to this problem of utilizing all cores, it can even be built into Avisynth natively. The sub processes can even introduce additional compatibility for cross 32/64 bit hosting, and stability by restarting crashing job segments with alternate settings/scripts.

Having this done natively or via a a plugin such as ImportParallel(string AVSFile, int "ProcessCount", int "FrameCount", ...) all in memory will be a lot faster and transparent than using splitting scripts in other languages and using slow disk caches.

SEt

21st July 2011, 05:22

Büke

21st July 2011, 05:41

This is unrelated to this thread. I request moderators to split the posts.

Regarding the suggestion, I think another hack is not what avisynth needs today. It needs clear and mandatory rules for plugins how to deal with multithreading.

Why is this a hack? It is a real solution, that has been proven in other domains.

A host's mission is to make things easier for plugin authors, who would rather focus and specialize on the complexities of the algorithms, rather than their parallelization or optimization, or user interface, etc, etc.

Are you suggesting that new rules be put out and all plugins be rewritten, and new ones with additional complexities?

If the plugin authors were interested in multi-threading more than the core algorithm, they would have done this in majority of the plugins, including the native filters already..

More practical, and less dogmatic, is what I say.

SubJunk

21st July 2011, 22:41

Thanks a lot for the update, SEt!

jpsdr

22nd July 2011, 09:04

Maybe. I'm not very interested in 64-bit build now as I have only 6GB of ram and if you really want you can run some time-critical 64-bit code in 32-bit process too.

Some 64bits pluggins can have sometime speed increase of 30%.
I've noticed, on QTMG for example, an increase speed of around 15% under 64bits.

My personnal thought, at the actual stage is :
The way MT is implemented on avisynth seems not to be very stable, so, the best way actualy to have a stable multithreading would be to not use MT version of avisynth, split your work and start several task. For exemple, launching 6 Vdub task on 6 files.
Using not MT version of avisynth keep garanty stability, and running several tasks make all your core work.
I think, it could be more interesting to focus on single threading 64bits port, because good 64bits port can provide good improvement in speed.
I've noticed it with the unfornutaly dead project of the 64 bits version begun by JoshyD.