ShawnFumo
13th December 2005, 23:34
This project I'm working on just isn't giving me any breaks. First I had a big memory leak caused by subtitle() which I ended up replacing with a separate subtitle file and vsfilter. Then I had come-and-go issues with avs taking 99% of my cpu, which I think were related to new versions of vsfilter.dll. Going to the version on warpenterprised seemed to help that.
My latest issue is really baffling me, though. I'm doing two-pass compression in h.264 using MeGui, which I've used without issue for other projects. It gets through the first pass fine, but then in the second pass, it gets progressively slower! Memory does rise a bit, but not enough to crash anything. The problem is the fps starts at a good clip (even 20fps on a slower machine), but then it gets slower and slower as time goes on. By the time it gets to 25-50%, the remaining time is greater than when it started!
I've stripped out various things that I thought could be causing it, but it still seems to happen. I may be able to get it to work by trimming it into 5 sections or something and appending them, but I don't see why it should need that. When it comes down to it, it is a bunch of trims from a video clip which get de-interlaced and then dissolved together. It is even happening by using a BlankClip of the correct length instead of my VirtualDub framserving append (to get around the multiple avisource limit).
If anyone could see if I'm doing something really stupid, I'd appreciate it! My code is in here (http://video.yoyoing.com:8080/yoyoing/shawn/videofiles/avisynth/slowproblem.zip).
The main file is _wristmount.avs. I don't think the _genSubsOn/Off files should be afffecting anything (when it is Off is imported, they are just empty functions), so most of the meat of what's going on is in _functions.avs. I mean I've simplified enough stuff now that the only actual decision left is which setting of LeakKernalBob to use for either normal motion or slowmotion. I have it set to use the BlankClip, so it should run as is if you have LeakKernal and vsfilter. It still happens even if you don't use vsfilter though, so you can always comment out that line.
Could it be that the functions to add stuff are accessing a global clip "curOutput"? It seemed that way was much cleaner than having each call be curOutput=dissolve(curoutput, addSection(1)) or whichever. I don't see why it'd make a difference, but I'm running out of stuff to try at this point..
Another thing is that while it doesn't seem too bad playing from start to finish, if I have it in a player like MPC and drag the seek bar around back and forth, I can get the memory to rise high enough to crash the player. So I guess there's still some memory issues, though I don't "think" that has to do with the compression issue, since it doesn't rise that quick during normal playback.
It is happening on two different machines, so I don't think MeGui is to blame, though maybe the fact that the first pass is ok gives a clue to the problem? I believe it also happens during a normal 1pass compression (and in xvid), which is what lead me to think avs is at fault somehow.
Thanks!
Shawn
My latest issue is really baffling me, though. I'm doing two-pass compression in h.264 using MeGui, which I've used without issue for other projects. It gets through the first pass fine, but then in the second pass, it gets progressively slower! Memory does rise a bit, but not enough to crash anything. The problem is the fps starts at a good clip (even 20fps on a slower machine), but then it gets slower and slower as time goes on. By the time it gets to 25-50%, the remaining time is greater than when it started!
I've stripped out various things that I thought could be causing it, but it still seems to happen. I may be able to get it to work by trimming it into 5 sections or something and appending them, but I don't see why it should need that. When it comes down to it, it is a bunch of trims from a video clip which get de-interlaced and then dissolved together. It is even happening by using a BlankClip of the correct length instead of my VirtualDub framserving append (to get around the multiple avisource limit).
If anyone could see if I'm doing something really stupid, I'd appreciate it! My code is in here (http://video.yoyoing.com:8080/yoyoing/shawn/videofiles/avisynth/slowproblem.zip).
The main file is _wristmount.avs. I don't think the _genSubsOn/Off files should be afffecting anything (when it is Off is imported, they are just empty functions), so most of the meat of what's going on is in _functions.avs. I mean I've simplified enough stuff now that the only actual decision left is which setting of LeakKernalBob to use for either normal motion or slowmotion. I have it set to use the BlankClip, so it should run as is if you have LeakKernal and vsfilter. It still happens even if you don't use vsfilter though, so you can always comment out that line.
Could it be that the functions to add stuff are accessing a global clip "curOutput"? It seemed that way was much cleaner than having each call be curOutput=dissolve(curoutput, addSection(1)) or whichever. I don't see why it'd make a difference, but I'm running out of stuff to try at this point..
Another thing is that while it doesn't seem too bad playing from start to finish, if I have it in a player like MPC and drag the seek bar around back and forth, I can get the memory to rise high enough to crash the player. So I guess there's still some memory issues, though I don't "think" that has to do with the compression issue, since it doesn't rise that quick during normal playback.
It is happening on two different machines, so I don't think MeGui is to blame, though maybe the fact that the first pass is ok gives a clue to the problem? I believe it also happens during a normal 1pass compression (and in xvid), which is what lead me to think avs is at fault somehow.
Thanks!
Shawn