Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
16th March 2010, 06:10 | #181 | Link | |
Registered User
Join Date: May 2008
Posts: 1,840
|
Quote:
Thanks for autocrop and leakkerneldeint 99% of the time avisynth64 will be my choice the only exception being repal but maybe mvtools with newer srestore will work in those cases. It looks like x64 is by far the more popular windows 7 version according to steam so hopefully x64 encoding is here to stay. A few years ago when squid_80 was working on avisynth64 xp x64 was and still is incompatible with many applications, vista was disliked by many. Also there wasn't many x64 encoding applications, virtualdub64 I think was just coming along, no x264_x64. So let's hope for a better turnout this time. 64 bit directshow filters I think were non-existent then as well, except maybe ffdshow64 which doesn't do much good without a 64 bit splitter. Windows 8 is rumored to not be available in x86 but then again windows 7 had the same rumor. Last edited by turbojet; 16th March 2010 at 06:20. |
|
16th March 2010, 10:37 | #182 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
FYI
I got that weird lockup problem again.. It happened on the 3rd job in the queue. This time I at least got a message out of it.. It said something along the lines of "Something appears to be stuck (thread deadlock) while trying to abort" and asked me if I just wanted to kill everything. I'm assuming it's not Vdub itself since the program was otherwise responsive and interact-able. |
16th March 2010, 13:20 | #183 | Link | |
Registered User
Join Date: Jan 2007
Posts: 530
|
Quote:
I get choppy, stuttery playback. I'm resizing (cropping) a FullHD source, here's the .AVS: Code:
SetMTMode(2,4) #Source File directshowsource("c:\output\Law Abiding Citizen.mkv",audio=false) last = isRGB(last) ? ConvertToYV12(last) : last last = isYUY2(last) ? ConvertToYV12(last) : last #SetMTMode(2,8) #Spline36Resize(1920,800,0,140,-0,-140) Lanczos4Resize(1280,528,0,140,-0,-140) #RemoveGrain(mode=2) trim(0,7500) distributor() |
|
16th March 2010, 15:14 | #184 | Link |
Registered User
Join Date: May 2008
Posts: 1,840
|
I can confirm noee's issue and isolated it to SetMTMode(2). It appears the frames are delivered out of order and some frames break up. However it doesn't happen in every scene. Modes 5 and 6 are working okay. Modes 1,3,4 freeze x264 with mpeg2source or directshowsource only.
Also modes 2 and 6 have randomly rebooted my machine which is like noee's an athlon X4 620@3.5 ghz. This might be caused by avisynth64 but I wouldn't rule out the multiple runs of ffdshow64, coreavc2 or dgdecode. I don't use setmtmode or mt unless I'm doing heavy filtering which is almost never so I don't know if the reboots and freezes of certain modes are typical. With a 'light' script like noee's you lose about 50% of the speed with setmtmode/mt. LeakKernelDeint works as expected but about 3% slower than x86 DGDecode 1.58 works okay too but is 10-15% slower for me then x86, optimized for intel only? TIVTC and autocrop works okay and roughly the same speed as x86 Last edited by turbojet; 16th March 2010 at 15:17. |
16th March 2010, 16:56 | #185 | Link |
Registered User
Join Date: Jan 2007
Posts: 530
|
With the "AMD only" version, I can't even get an encode to run without using SetMTMode(). If I comment it out in the above script, the encode just sits there doing nothing. Every now and then x264.exe will pop 1-2% CPU, but it just sits there for hours doing nothing.
|
16th March 2010, 17:10 | #186 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
*scratches head*.. This is really starting to throw me for a loop.
Despite my previous success reports. It appears optimizations on Dgdecode 1.5.8 are indeed going to be needed. I restarted my queue this morning and came home to find the same file still encoding. It was around 4:45m for completion, as if it were running a non-MT x32 setup. Despite the previous encodes only taking the average 2:40m or so.. The next file in the queue started and I was seeing 4 - 5 hour completion ETA.. I played around with the MT settings in the script and I still could not get it to go higher than 2.5 ~ FPS range. I regrabbed DG Index 1.4.6, re-indexed the same file, redid the yatta project, and set the script to the exact same settings. It started off in the 3 hour range but now it has dropped to currently 2h:40m range.. The FPS does go up and down, but in general seems to stay in the 3 - 4fps range. So currently, it seems Dgdecode 1.4.6 is still the best optimized version to use ? I really need more corroboration on this one though. Can anyone else verify a performance gap through comparing multiple sources? I am prediction when this encode finished, it will have only taken about 2:45m or less. Or very close. Core 2 Duo 2.13Ghz @ 3.2Ghz 8GB DDR2 Windows 7 x64 |
16th March 2010, 17:41 | #187 | Link |
Registered User
Join Date: Feb 2010
Posts: 84
|
@noee
Bizarre on the needing to set the MT mode to get it to run. That really shouldn't be happening. I'll look at the code a while, and see if anything pops out as just plain "wrong." Though, you don't need to call distributor at the end of the script. It's automatically called internally when using a valid MT mode. Also, placing that trim command directly after the source is created will stop the MT mode of avisynth from beginning to render frames outside your region of interest. @osgZach Thread deadlock = not good. I think it's time to remove some parallelism from my build and see if I can kill off the deadlock condition. Overall, at least there's some resize functionality restored, still not to the point I'd like to see it though. I'll continue to wade through the code to see if I can get a flawless version of all the crucial functions that works for everyone. In the meantime, could either of you try this updated AMD compatible binary to see if it alleviates some of your cache and thread woes? @squid80 Any chance you remember the problem sources when compiling 1.5.6? I'm willing to do it by hand, a nudge in the right direction would do be much appreciated. Last edited by JoshyD; 16th March 2010 at 18:59. |
16th March 2010, 18:30 | #188 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
Might want to go off 1.4.6 as that seems to be the best one, and I think Squid said 1.5.6 would likely have performance issues. I would think it better to start with the modified source of the faster performing version?
But that's just my uninformed opinion.. I have to go back to VB 2008 for Dummies now |
16th March 2010, 18:55 | #189 | Link |
Registered User
Join Date: Feb 2010
Posts: 84
|
@osgZach
Funny thing is, I started with the 1.4.6 source and used WinMerge to selectively merge in changes from the 1.5.8 source that shouldn't have effected x64 compatibility. DgDecode 1.5.8 isn't optimimized for a specific architecture, we could be seeing performance loss because some of the inline asm remains hard coded for best use with 32bith processors. This means we don't get to use any extra registers available to us and there are some idiosyncrasies that arise when writing x64 assembler. Some instructions take longer to complete because of internal handling by the processor. The often used Code:
inc regA or dec regA Code:
add regA, 1 or sub regA, 1 Short story, a quick and dirty port can slow you down, a well thought out and carefully coded port can see nice speed gains. To all: If the crashing from SetMTMode and thread deadlocking becomes solved, and the vertical resizers for AMD processors work without issue, I'm going to change the horizontal resize code to use the same concepts as the vertical resize code. Horizontal resize speed, believe it or not, is the slowest part of Avisynth (internally, not counting filters which eat way more processing time) when running TGMC beta2, by a factor of 3 or so, which is pretty substantial. Here's hoping for some good news about the latest builds. Last edited by JoshyD; 16th March 2010 at 19:38. |
16th March 2010, 19:13 | #190 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
Ah, cool.. I know nothing about ASM Language so you already know more than I do
That encode under 1.4.6_x64 just finished. 2h:30m for a 22m:48s video. I guess for now I'll have to stick with 1.4.6 and hope the speed holds up for other sources (4 down, 33 to go). |
16th March 2010, 20:19 | #191 | Link | |
Registered User
Join Date: Mar 2003
Posts: 116
|
Quote:
avisynth64_3-15-10.rar fixes the issue. |
|
16th March 2010, 21:46 | #192 | Link |
Registered User
Join Date: Jan 2007
Posts: 530
|
Okay, that last "AMD" version worked with the resize in my script, but only when I removed the SetMTMode() call. It appears that when I use SetMTMode(), the frame corruption occurs. I've run two test so far with Spline36 and Lanczos without SetMTMode() and they are good.
|
17th March 2010, 04:52 | #193 | Link |
Registered User
Join Date: Mar 2003
Posts: 116
|
Any chance for a tomsmocomp port?
|
17th March 2010, 06:13 | #194 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
With the latest builds I get an error with
mt("TempGaussMC_beta2()",threads=4) Removing the threads=4 works but then its not multi-threaded. I had this working on a older build. setmtmode, doesn't have any speed increases for me.
__________________
http://www.7-zip.org/ |
17th March 2010, 16:35 | #196 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
I hate computers. I can't get stable performance numbers. lol.. Somebody please shoot me.. I think I better stay away from SetMTMode() until a lot of this gets straightened out.. Especially the thread deadlocks - that hits randomly too.
I really don't want to use MT either.. can't solve the overlap misalignments Plus the more time I spend screwing with this, the less time I have to get JoshyD's hosting set up.. |
17th March 2010, 18:54 | #199 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
yeah its a pay app, i can't see neuron giving anyone the code to make a 64bit version as its too risky. It would be nice though. He said he has no 64bit O.S and that if he had 1 he might create 64bit versions of it so if anyone is rich feel free to pay for a copy of win7 pro x64 for him.
|
|
|