[64bit AVS&MT and whatnot]

This forum is for video and audio help and discussion.

[64bit AVS&MT and whatnot]

Postby EvaFan » Fri Jun 29, 2012 1:31 am

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.
"The people cannot be [...] always, well informed. The part which is wrong will be discontented, in proportion to [...] the facts they misconceive. If they remain quiet under such misconceptions, it is lethargy, the forerunner of death to public liberty. What country can preserve its liberties, if it's rulers are not warned [...] that this people preserve the spirit of resistance? The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants."-Thomas Jefferson
User avatar
EvaFan
 
Joined: 21 Mar 2004
Location: Somerset, KY
Status: (*゚▽゚)o旦~ ー乾杯ー♪

Re: Ut Video x64 vs x86

Postby Mister Hatt » Fri Jun 29, 2012 3:34 am

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.
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: Ut Video x64 vs x86

Postby mirkosp » Fri Jun 29, 2012 3:48 am

EvaFan wrote: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. :book:

Also the main problem of setmt is that it's not safe for temporal filtering. :roll:
Image
User avatar
mirkosp
MODkip
 
Joined: 24 Apr 2006
Location: Gallarate (VA), Italy
Status: (」・ワ・)」(⊃・ワ・)⊃

Re: Ut Video x64 vs x86

Postby EvaFan » Fri Jun 29, 2012 7:22 am

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.
"The people cannot be [...] always, well informed. The part which is wrong will be discontented, in proportion to [...] the facts they misconceive. If they remain quiet under such misconceptions, it is lethargy, the forerunner of death to public liberty. What country can preserve its liberties, if it's rulers are not warned [...] that this people preserve the spirit of resistance? The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants."-Thomas Jefferson
User avatar
EvaFan
 
Joined: 21 Mar 2004
Location: Somerset, KY
Status: (*゚▽゚)o旦~ ー乾杯ー♪

Re: Ut Video x64 vs x86

Postby mirkosp » Fri Jun 29, 2012 7:39 am

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).
Image
User avatar
mirkosp
MODkip
 
Joined: 24 Apr 2006
Location: Gallarate (VA), Italy
Status: (」・ワ・)」(⊃・ワ・)⊃

Re: Ut Video x64 vs x86

Postby Mister Hatt » Fri Jun 29, 2012 8:38 am

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
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: Ut Video x64 vs x86

Postby EvaFan » Fri Jun 29, 2012 9:14 am

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.
"The people cannot be [...] always, well informed. The part which is wrong will be discontented, in proportion to [...] the facts they misconceive. If they remain quiet under such misconceptions, it is lethargy, the forerunner of death to public liberty. What country can preserve its liberties, if it's rulers are not warned [...] that this people preserve the spirit of resistance? The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants."-Thomas Jefferson
User avatar
EvaFan
 
Joined: 21 Mar 2004
Location: Somerset, KY
Status: (*゚▽゚)o旦~ ー乾杯ー♪

Re: [64bit AVS&MT and whatnot]

Postby mirkosp » Fri Jun 29, 2012 10:32 am

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.
Image
User avatar
mirkosp
MODkip
 
Joined: 24 Apr 2006
Location: Gallarate (VA), Italy
Status: (」・ワ・)」(⊃・ワ・)⊃

Re: [64bit AVS&MT and whatnot]

Postby Mister Hatt » Fri Jun 29, 2012 10:43 am

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?
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you


Return to Video & Audio Help

Who is online

Users browsing this forum: No registered users and 2 guests