[64bit AVS&MT and whatnot]

[EvaFan]

Point out what ever you want but the average user wont have problems with it, as for stability, I dont use 100 or more chains of code on an avs file like you guys claim to do. Im quite content with 40+ fps and the current limitations 64bit and mt has. Setmtmode does not split it into regions either so that main problem is avoided. I dont encourage it but I'm not going to refrain from using it just cause other people have problems woth it and it does everything I need it to with ease. Also Cs5 + avs editing ftw.

[Mister Hatt]

I just meant that specifically UT Video 64bit is slower than 32bit, and it's got little to do with stability and everything to do with 64bit asm not working. For people who need fast decoding for :reasons:, it is a notable difference.

[mirkosp]

100 or more chains of code on an avs file like you guys claim to do.

Just because I don't like the "claim" in there, I'll share this (which makes me feel uncomfortable since I fear it comes off as a bragging of sorts): http://pastebin.com/JRdPX8dv < latest episode of Lupin (so latest avs I have currently). It's not even the longest thing I have, just about average.
The commented bit after the resize is because I do multiple lossless passes (recon is shitslow).
Either way, it's easy to get past 100+ lines when you freezeframe and use YATTA in general. But the stuff that slows down is tnlmeans and related preset usage.

Also the main problem of setmt is that it's not safe for temporal filtering.

[EvaFan]

Honestly, all things considered, the knowledge I have and the limitations of 64bit and mt is still plenty to tackle most video problems well enough. If bluray is the future, most of my filtering for those has just been merely deinterlacing and occasionally tdecimate. Sometimes I still work on banding, colors, and lines out of preference but again its minimal. That being said, there's even further of a less need to change.

Temporal problems is news to me. If each frame is being processed by its own core, why would that cause trouble getting the data from previous and next frames? I may test this with ft3d on some heavy noise, but I've never had any problems or maybe I dont notice it.

[mirkosp]

Try it with mdegrain perhaps (obligatory mvtools2 link). Although I think the "safety" depends on the mode being used, but as far as I know, in order for heavy temporal filtering (such as multi-pass vector calculations and so on) to not crash, you need to use modes 5 or 6, which if compared to plain single threaded usage end up being slower. Or so I recall from a comparison from a couple years ago or so. Things might have changed for all I know, but eh... I hardly see any real development going on anyway.
Honestly, I'll just fire up a second instance of virtualdub with a trim at a scenechange at some point in the middle of the stream and call it a day. Two concurrent encodes running on two differents threads, and they don't get in each other's ways. That's already mt for all intents and purposes, and it surely does not come in the way of temporal nor spatial filtering (since temporal filters internally try to distinguish scenechanges to begin with).

[Mister Hatt]

The issue with temporal filtering in MT is more about quality than performance/stability imo, and steps from problems in slice based threading when temporal filters won't necessarily line up properly. Just don't do it. Stability issues are more about how avs handles frame caching and queueing.

That aside, this thread was about UtVideo. I wasn't saying 64bit avs or vdub is slower than 32bit, I was talking about explicitly UtVideo. The reasoning for this is that UTV doesn't actually have working 64bit assembly code, although the problem is less severe in windows. NASM hates it and 32bit asm is used instead, with an obvious performance penalty.

Re "claims" of large scripts, have something I had to work on in 2007 and then again recently in HD, around 34,000 lines of fixing frame order on pseudo-interlaced crap. http://pastebin.ca/2165534

[EvaFan]

Sorry to derail your thread hatter, I was replying to mirk about the INB4 Eva comment. I don't care to defend avs64bit and MT cause I know it has flaws, also like I said I don't encourage it. But every instance you guys seem to complain its about your way actually being faster, and for you I'm sure it is, and even better for you. However I keep telling you that I'd rather edit with avs files and not convert a bunch of stuff that I don't even need to do, it's a major time sink and pointless If I can get the source looking fine enough that I'm happy with it and just edit an avs file at 40+ fps even with the cleaning code on it sometimes. This is called preference, telling me not to do it is essentially the same as telling yourself you should try it, cause I know you wont.

[mirkosp]

To contribute some more to this discussion, I'll link sorathread which is another multithreading filter for avisynth, but as opposed to the setmtmode() and mt() approach, it makes a thread for each filter being used, so it's very much safer and has no quality harm. Unfortunately, the speedup may not be as noticeable depending on the chain, but compared to the other solutions it is very safe and the output should be bit-identical to normal single-threaded avisynth.

[Mister Hatt]

Please don't call me hatter, that is someone else. SoraThread is interesting; it looks like a less detailed, single-CPU take on my pipelined MPP frameserving writeup. Certainly more stable than what I expect existing MT stuff to be but I'm not convinced it gets around some of the issues we see thanks to temporal filter frame caching. If it is aware of cache sizes though, it might very well do. The whole pipelining filters and avoiding slice-threading is pretty neat. The multi-process IPC for avoiding memory limits is a pretty cool take on getting around 32bit RAM limits I'll admit. I still find CPU to be my main bottleneck, but this could potentially work in a multi-CPU environment with a bit of pegging, and approximate a single machine massive parallel server. Anyone actually used it?