ejp
2nd February 2006, 19:45
did a search; nothing really helped.
particular to my situation, this issue could fall under many topics, but i think it fits in here the most.
i've been using autogk for the longest time (updated to the last available version) and i haven't had any problems until a couple days ago. it took way too long and i figured maybe it was just one of those encodes which is understandable for a 2+ hour movie. so anyway, i tried a 7 minute video clip, and it took extremely long too.
since virtualdubmod is a main component of autogk (and it's called 3 times before and for encoding), i bring it up. i look at the status. the processing thread priority is set to normal. so then i bring up my task manager and look at its priority. lo and behold, it's set to low. this has obviously never happened before because this is what was slowing it down; i raised it back to normal and the speed was fine again. (and i come to the conclusion that there's no connection with the priority in the status window and the priority in the task manager?)
vdubmod is called for the compressibility test. it was low, so i fixed it. it's closed and called again for the 1st pass. again, it was low, so i had to fix it again. the same idea goes for the 2nd pass.
why is it that vdubmod is defaulting to low priority? i doubt this is an autogk problem, is it? or is it a vdubmod problem? or is XP (pro sp2) "trying" to do something nice by putting a high-memory process (vdubmod) down to a low priority for me?
i don't want it to, so can anyone help?
will re-installing it help? i doubt a log file will help, but i'll post if necessary.
particular to my situation, this issue could fall under many topics, but i think it fits in here the most.
i've been using autogk for the longest time (updated to the last available version) and i haven't had any problems until a couple days ago. it took way too long and i figured maybe it was just one of those encodes which is understandable for a 2+ hour movie. so anyway, i tried a 7 minute video clip, and it took extremely long too.
since virtualdubmod is a main component of autogk (and it's called 3 times before and for encoding), i bring it up. i look at the status. the processing thread priority is set to normal. so then i bring up my task manager and look at its priority. lo and behold, it's set to low. this has obviously never happened before because this is what was slowing it down; i raised it back to normal and the speed was fine again. (and i come to the conclusion that there's no connection with the priority in the status window and the priority in the task manager?)
vdubmod is called for the compressibility test. it was low, so i fixed it. it's closed and called again for the 1st pass. again, it was low, so i had to fix it again. the same idea goes for the 2nd pass.
why is it that vdubmod is defaulting to low priority? i doubt this is an autogk problem, is it? or is it a vdubmod problem? or is XP (pro sp2) "trying" to do something nice by putting a high-memory process (vdubmod) down to a low priority for me?
i don't want it to, so can anyone help?
will re-installing it help? i doubt a log file will help, but i'll post if necessary.