Suspending x264 - SysInternals Process Explorer

[dumbas..]

With only one pc, mine has many tasks to perform. Whilst setting a low process priority helps, its not the best when trying to watch HD x264 movies at the same time. They SSttutter a great deal.

So.. I found this little app which may be of use to others of you. I find it useful to suspend the x264 process whilst I devote more processor time to another task (as above) then resume encoding when finished. Of course it has many other uses...

Its free too!

http://www.sysinternals.com/Utilities/ProcessExplorer.html

Hope its of use to you too :)

[bkman]

You can just change the process priority to "low" in the Windows task manager, and it would have a similar effect.

[CruNcher]

yep and be carefull with Process Explorer it can have side effects if running especialy for Video Playback if the refresh time is to fast :P

[dumbas..]

You can just change the process priority to "low" in the Windows task manager, and it would have a similar effect.

I have done just as you say in the past.- Frustration was the result. In my opinion you can still get stuttering.
The senario: Encoding at LOW priority plus decoding as normal can give 100% processor usage on (my A64 3200) pc especially on HD material.
So without aborting the encode or carefully 'planning' watching times :rolleyes: this is the only simple, flexible,free option. But you might have more horsepower?

yep and be carefull with Process Explorer it can have side effects if running especialy for Video Playback if the refresh time is to fast :P

Not been an issue, (most played at 23.98fps) but then again it could happen... sticking your head in a bowl of water can have side effects:D

[CruNcher]

i meant if you set Process Explorers refresh time to low it can hold some other processes for some seconds, you see this especialy well with video playback if it stutters every 2 seconds and you don't know why, most probably the couse are the process explorer refresh settings. Windows process management sucks big time. And this is only if Process Explorer is running in the background also other applications that poll hardware can couse such problems on Windows for example Speedfan try todo a 3dmark benchmark while running it, you gonna see the output stutters :P

[dumbas..]

i meant if you set Process Explorers refresh time to low....

OK, got you :)

[check]

Changing the task priority for the x264 process to low should work fine. At that setting, the encoder will only use space CPU cycles. All the CPU will be consumed, but x264 will be last in line, so to speak. Unless you have some other strange settings, this will present you with no problem.

[dumbas..]

Changing the task priority for the x264 process to low should work fine. At that setting, the encoder will only use space CPU cycles. All the CPU will be consumed, but x264 will be last in line, so to speak. Unless you have some other strange settings, this will present you with no problem.

I agree with all you say check, but the key words are 'should work fine'. From admitedly only my experience, some encoded movies almost max out the cpu on playback. From testing I find that whilst sat at 'LOW' priority does cause interupts and thus taking the cpu upto 100%. So I see no problem in pausing the encoder to enjoy the movie.
After all, what's a few hours in a 24hr plus encode. Compared to the encoder sat at LOW and not gaining many cpu cycles as a consequence. But causing the occasional stutter. Its not as tho' the encode is time critical.

[bkman]

CPU should always be at 100% in low priority mode since x264 is using any spare cycles it can. Doesn't mean that your other programs will run any slower, since x264 is only working when they aren't.

The only lags that can still occur are due to limited memory, as x264 is still a decent bit of memory which your apps may want.

[foxyshadis]

There's actually a lot that can interfere if you're running too close. V-sync is already unpredictable in low-load, at full load the hardware interrupt signals start getting delayed, more memory and disk transfers get queued, and significantly more kernel time is being used to switch between two processes hogging the cpu. Not much, but something as sensitive as video playback on a single-processor machine could have hiccups. It's worse if you have your thread scheduling set to background, but it shouldn't be. If windows was a Real-Time OS it wouldn't make any difference, but it isn't.

Dual-proc or dual-core and limiting x264 to a single core would mostly resolve the problem, I imagine, unless video playback requires more than a whole core.

[Prettz]

Windows process management sucks big time.
I think it works great, actually, for a desktop PC platform. There's nothing I've ever wanted it to do that it doesn't do, at least nothing that would be possible. Totally freezing an application that wasn't designed to be frozen isn't feasible, you could end up freezing it in the middle of an I/O request and cause havoc for the system.

[nm]

Totally freezing an application that wasn't designed to be frozen isn't feasible, you could end up freezing it in the middle of an I/O request and cause havoc for the system.
On POSIX systems (like Linux) it is always possible to send processes a STOP signal and apparently Windows does that too since it is possible through the SysInternals app. Of course it may cause problems if the process expects to get at least some CPU time frequently to run in the right way, but the user/admin should know what he is asking for. Stopping wrong processes is not likely to break anything at the kernel-controlled level, like messing up the filesystem.

[CruNcher]

Totally freezing an application that wasn't designed to be frozen isn't feasible

Then Directshow obvously is no layer that was designed to be stable :P

If i would get 1$ every time i had a "Windows loop delay crash" (Application uses 100% Cpu system doesn't react anymore for several minutes) i would be rich by now :d sure i think everyone can agree that Windows XP is alot more stable then everything before, but still not comparable with Unix/Linux wich should change now finaly with Vista according to Alchin and the Kernel Team (better I/O handling better Process Management Prioritization) but we gonna see that, obvously the best (very valueble brain) that Microsoft aquired in the last months was Mark Russinovich's one :P, but why you need a complete new Designed OS for those Internal Kernel changes is behind me (not really but only economical reasons are behind it) a nice stability update to XP's Kernel and we would all be happy (only the rest of the industry wouldn't) ;).

[Prettz]

On POSIX systems (like Linux) it is always possible to send processes a STOP signal and apparently Windows does that too since it is possible through the SysInternals app. Of course it may cause problems if the process expects to get at least some CPU time frequently to run in the right way, but the user/admin should know what he is asking for. Stopping wrong processes is not likely to break anything at the kernel-controlled level, like messing up the filesystem.
This works if the app was in the middle of writing to the hard drive even? I didn't think that was possible.


but why you need a complete new Designed OS for those Internal Kernel changes is behind me (not really but only economical reasons are behind it) a nice stability update to XP's Kernel and we would all be happy (only the rest of the industry wouldn't) ;).
Because no 2k/XP drivers would work under the new kernel, as I understand it. If everyone is going to have to rewrite their drivers why not just totally start from scratch anyway?

[nm]

This works if the app was in the middle of writing to the hard drive even? I didn't think that was possible.
Such I/O requests are (kind of) atomic and can be blocked indefinitely. In a multitasking OS, processes get suspended all the time because if there is only one CPU core, only one process (and thread) can run at any given time. Think of a situation where your system is swapping heavily because it has run out of memory. Then most of the processes don't run at all for long periods of time and that can be seen on the desktop as frozen windows. Stopping a process is just a matter of not returning to run it for a while. :)

[dumbas..]

There's actually a lot that can interfere if you're running too close. V-sync is already unpredictable in low-load, at full load the hardware interrupt signals start getting delayed, more memory and disk transfers get queued, and significantly more kernel time is being used to switch between two processes hogging the cpu. Not much, but something as sensitive as video playback on a single-processor machine could have hiccups. It's worse if you have your thread scheduling set to background, but it shouldn't be. If windows was a Real-Time OS it wouldn't make any difference, but it isn't.

Dual-proc or dual-core and limiting x264 to a single core would mostly resolve the problem, I imagine, unless video playback requires more than a whole core.

Yep, I think you summed up the situation very well foxyshadis.
Windows task manager does not display peak processor usages, as I understand it. So one might be left thinking usages are not as extreme as it actually is. (I appreciate you can not have more than 100%!) So I theorised that in fast high peak loads the intensive task swapping was causing visible effects. - At least on my setup. Try it and see if you agree anyone!

Run MPC with ffdshow and show processor usage OSD.

I just resumed x264 after a 2hr suspend. No probs with encode results. And I was able to watch the movie with out the stutter.

It works for me, and allows the flexibility to halt, otherwise non-interuptable long process activities.

[Trahald]

i use processxp's suspend for the same reasons. i thought i read somewhere to be careful with multithreaded apps but ive never had an issue. as long as your encoded output is the way it should be, there is no harm. hopefully m$ will add suspend to task manager since they own sysinternals now anyways. (is it in vista?)

[Prettz]

Such I/O requests are (kind of) atomic and can be blocked indefinitely. In a multitasking OS, processes get suspended all the time because if there is only one CPU core, only one process (and thread) can run at any given time. Think of a situation where your system is swapping heavily because it has run out of memory. Then most of the processes don't run at all for long periods of time and that can be seen on the desktop as frozen windows. Stopping a process is just a matter of not returning to run it for a while. :)
Honestly I did not know this was practical to do. I've even taken a CS course "Operating Systems" as part of my Bachelors :o. I guess you could just freeze the app's threads, take the resources away, run, and when it's time to unfreeze the app, you give it the same resources it had before before letting it run again. Now that I think about it, I don't see any problems that would come up from doing this.

Your frozen app still takes up gigantic amounts of memory (especially if you set AviSynth's max memory really high, like I do), so swapping back all its memory when it's time to unfreeze is gonna blow.