x264 prevent standby/sleep

[turbojet]

When x264 is running and the computer goes to sleep it resumes after waking up but encodes the last frame before it went to sleep until it reaches the initial framecount.

Is there any way of preventing it from going to sleep when x264.exe is running?

Some things I've tried:
1. powercfg -requestsoverride x264.exe system
2. powercfg -change -standby-timeout-ac 0 before x264 and enabling after works but if the script doesn't finish, computer won't sleep.

Apparently there's a way to program into the exe, would that be considered?

Also a bit OT but is there a way to escape x264? Ctrl-C waits until after x264 is done encoding to ask to terminate.

[laserfan]

I run x264 from a batch file wherein I precede the CALL to my x264.cmd with this:

powercfg -change -standby-timeout-ac 0
powercfg -change -hibernate-timeout-ac 0
powercfg -change -monitor-timeout-ac 1

and then at the end of the batch I restore with this:

@echo Restore Hibernate mode!

@echo ON

powercfg -change -standby-timeout-ac 5
powercfg -change -hibernate-timeout-ac 5

@echo OFF
echo.

PAUSE

powercfg -change -standby-timeout-ac 30
powercfg -change -hibernate-timeout-ac 30
powercfg -change -monitor-timeout-ac 5

The "standby" is still in there though I've switched to Hibernate so a power failure won't kill everything. Anyway after my batch file is over, the PC hibernates after 5 minutes and then when I awaken it the cmd window is still open for me to look at & copy/paste, and then of course when I close-out of it all my power settings are restored to normal. It all works perfectly for several years now, since Windows 7 got aggressive about power.

[turbojet]

I'm using something similar but if the script doesn't finish for some reason, sleep stays disabled.

Except for flash, for obvious reasons, x264 is the only software I use that needs to prevent sleep but doesn't offer any way to do so.

[LoRd_MuldeR]

Should be straight forward to implement in x264, at least for Microsoft Windows:
http://msdn.microsoft.com/en-us/library/aa373208%28v=vs.85%29.aspx

[Groucho2004]

Should be straight forward to implement in x264, at least for Microsoft Windows:
http://msdn.microsoft.com/en-us/library/aa373208%28v=vs.85%29.aspx
Or a simple launcher app that runs x264 through CreateProcess(), polls the process exit code periodically and keeps the system from sleeping.
Something like this:
STARTUPINFO si;
PROCESS_INFORMATION pi;
::ZeroMemory(&si, sizeof(STARTUPINFO));
::ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));
si.cb = sizeof(STARTUPINFO);

if (::CreateProcess(NULL, lpCommandLine, NULL, NULL, FALSE, NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi) == 0)
return FALSE;

if (pi.hProcess)
{
::WaitForInputIdle(pi.hProcess, INFINITE);
DWORD dwExitCode = STILL_ACTIVE;
while (dwExitCode == STILL_ACTIVE)
{
::WaitForSingleObject(pi.hProcess, 1000);
::GetExitCodeProcess(pi.hProcess, &dwExitCode);
::SetThreadExecutionState();
}
}

::CloseHandle(pi.hProcess);
::CloseHandle(pi.hThread);

The launcher could also set the priority for x264.

[LoRd_MuldeR]

Sure, that's possible. But why make a separate "launcher" program instead of integrating one line of code into x264 itself or into the GUI of your choice?

BTW: Instead of calling SetThreadExecutionState() in a loop to manually reset the idle counter every second, you can permanently prevent standby with a single call.

Just see example on the MSDN site:
// Television recording is beginning. Enable away mode and prevent the sleep idle time-out.
SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_AWAYMODE_REQUIRED);

// Wait until recording is complete...

// Clear EXECUTION_STATE flags to disable away mode and allow the system to idle to sleep normally.
SetThreadExecutionState(ES_CONTINUOUS);

[Groucho2004]

why make a separate "launcher" program instead of integrating one line of code into x264 itself or into the GUI of your choice?
Who knows when/if this will be implemented. And a gui is a launcher, isn't it?

BTW: Instead of calling SetThreadExecutionState() in a loop to manually reset the idle counter every second, you can permanently prevent standby with a single call.
True, I just briefly read the documentation.

[laserfan]

I'm using something similar but if the script doesn't finish for some reason, sleep stays disabled.

Hmm why don't your scripts finish? Mine never (ever) fail to complete.

Incorporating the STES feature into x264 might be nice but there are numerous programs on my PC which Bill Gates doesn't like, so I even have a "can't sleep" cmd I run for those...

[LoRd_MuldeR]

Hmm why don't your scripts finish? Mine never (ever) fail to complete.

Maybe CTRL+C ;)

Who knows when/if this will be implemented. And a gui is a launcher, isn't it?

For what it's worth, here is a very simple patch:

[turbojet]

Hmm why don't your scripts finish? Mine never (ever) fail to complete.

An error, which rarely happens here but it does. Power outage, switch user, log off, etc. Thing is it can happen and while not nearly as disastrous as going to standby with x264, the result is unexpected.

It's silly windows would sleep with so much cpu load but it beats XP's sleep which often doesn't work. Powercfg -requestsoverride really should work but probably another windows bug thats reported that will likely never get fixed.

For what it's worth, here is a very simple patch:

Nice, crossing my fingers an x264 developer notices.

[turbojet]

While patching I get this:

$ patch -p1 < "c:\x264\x264_thrad_exec_state.diff"
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|index 5d3f0c9..75a2e10 100644
|--- "a/x264.c"
|+++ "b/x264.c"
--------------------------


Any ideas?

Or if someone could build a patched version it would be appreciated, x264_est_size.2358.diff (http://komisar.gin.by/old/2377/p/x264_est_size.2358.diff) and x264_enc_time.2358.diff (http://komisar.gin.by/old/2377/p/x264_enc_time.2358.diff)are also very helpful.

[LoRd_MuldeR]

Looks like some Windows/Unix formatting issue. Try with the attached version (or simply type "x264.c" when it asks for the file to patch).

[turbojet]

Thanks, it was windows style git files, which is default git. Once changed to as is, it patches, the other patches I mentioned fail however.

I'm using this guide: http://doom10.org/index.php?topic=26.0.
C:\x264 is where git and patch files are. configure exists but msys gives me:

vbox@VBOX-PC /c/x264
$ ./configure
sh: ./configure: No such file or directory


Any ideas?

Maybe I'd be better off installing linux on a vm and doing it, ugh.

[LoRd_MuldeR]

Thanks, it was windows style git files, which is default git. Once changed to as is, it patches, the other patches I mentioned fail however.

I'm using this guide: http://doom10.org/index.php?topic=26.0.
C:\x264 is where git and patch files are. configure exists but msys gives me:

vbox@VBOX-PC /c/x264
$ ./configure
sh: ./configure: No such file or directory


Any ideas?

The script file "configure" is included with the x264 sources. It is located in the root directory (http://git.videolan.org/?p=x264.git;a=tree;h=1ca7bb943d15165a4b9631002a655587d923be63;hb=1ca7bb943d15165a4b9631002a655587d923be63) of x264. So either you were in the wrong directory or your x264 sources are incomplete!

Maybe I'd be better off installing linux on a vm and doing it, ugh.

If you wish to build a native Linux binary, you definitely should do this under Linux. If you wish to build a native Windows binary, you need to use MinGW/MSYS on Windows.

Cross-compiling a Windows binary from Linux is possible, but it's much more complicated ;)

See also here:
http://forum.doom9.org/showpost.php?p=1659399&postcount=33

[turbojet]

x264/configure exists but msys isn't seeing it that way. Years ago I compiled it using directions like on doom10's things must have changed a bit. I started over with your instructions and it compiled okay. Are GPAC and make fprofiled vids= needed anymore?

Unfortunately computer is still sleeping when the compiled x264.exe is running but I do get this:

powercfg -requests

DISPLAY:
None.

SYSTEM:
[PROCESS] \Device\HarddiskVolume4\Tools\megui\tools\x264\x264.exe

AWAYMODE:
[PROCESS] \Device\HarddiskVolume4\Tools\megui\tools\x264\x264.exe

Any ideas?

Is there anything else needed for x64 other than umount mingw and mount mingw64?

[LoRd_MuldeR]

x264/configure exists but msys isn't seeing it that way.

Just follow the instructions that I linked in the last post and it should work.

Are GPAC and make fprofiled vids= needed anymore?

If you want MP4 output, then either GPAC (http://gpac.wp.mines-telecom.fr/downloads/) or L-SMASH (https://code.google.com/p/l-smash/source/checkout) will be required. If you are fine with MKV output, you don't need those. Also you can remux later.

Building with "fprofiled" is supposed to give a slightly faster binary. But, in my experience, the speed-up usually is homeopathic ;)

You could also try extra options like ./configure --extra-cflags="-march=corei7" when building for modern CPU's only. But don't expect a magic speed-up!

Is there anything else needed for x64 other than umount mingw and mount mingw64?

I don't think so. Just make sure you do a clean re-build of x264.

[turbojet]

Clean rebuilding meaning configure again?

Also it might be my computer that is sleeping too aggressively. I've never seen anything in powercfg -requests that didn't prevent the computer to sleep.

Here's x264.exe and x264.c. (http://www.sendspace.com/file/1vwkdh) Does it prevent sleep for others?

[LoRd_MuldeR]

Clean rebuilding meaning configure again?

I'd do a fresh checkout followed by a ./configure --host=mingw64, just to be sure :)

Unfortunately computer is still sleeping when the compiled x264.exe is running but I do get this:

powercfg -requests

DISPLAY:
None.

SYSTEM:
[PROCESS] \Device\HarddiskVolume4\Tools\megui\tools\x264\x264.exe

AWAYMODE:
[PROCESS] \Device\HarddiskVolume4\Tools\megui\tools\x264\x264.exe

Any ideas?-REQUESTS
Enumerate application and driver Power Requests. Power
Requests prevent the computer from automatically powering off
the display or entering a low-power sleep mode.

This looks like the "power request" has been setup up as expected. I have no idea why the system would go to sleep anyway, though.

[nhakobian]

You can also run:
git clean -x -d --forceThis removes all non-tracked files and directories from the current directory and all subdirectories (-x removes ignored files, -d removes untracked directories). If you've modified any source files you might also want to run:
git reset --hardwhich will reset all the tracked source files to their original state.

[turbojet]

after umount mingw and mount mingw64.

$ ./configure
No working C compiler found.

$ gcc -v
Using built-in specs.
COLLECT_GCC=f:\tools\compile\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=f:/tools/compile/mingw64/bin/../libexec/gcc/x86_64-w64-mingw
32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32

Any ideas? EDIT: Nevermind, ./configure --host=mingw64 worked.

-march=corei7, -march=bdver3 and fprofile didn't give any speed benefit but pthreads gave a consistent 1.5-2% speed increase over win32threads.

The compiled exe prevented sleep on 2 other computers, so it's this computer. Googling hasn't been very helpful, does anyone have an idea of why it's sleeping when there's system and awaymode requests? EDIT: Solved it by deleting x264.exe requestsoverride with "powercfg -requestsoverride process x264.exe". I thought earlier that would prevent sleep.

Also this patch may not work for xp, it apparently doesn't have awaymode, more info at http://stackoverflow.com/questions/629240/prevent-windows-from-going-into-sleep-when-my-program-is-running. Mac and linux have ways to do it as well, haven't searched yet but will do if it's planned for completeness and hopefully picked up by official x264 or komisar. Maybe a more meaningful patch name like x264_prevent_sleep.2377.diff?

EDIT: Only issue remaining is compiling with ffms, lavf, etc. 64 bit exe. 32 bit works fine. I'm using komisar's mingw 4.8 and libpack.

$ ./configure --host=mingw64
platform: X86_64
system: WINDOWS
cli: yes
libx264: internal
shared: no
static: no
asm: yes
interlaced: yes
avs: avisynth
lavf: no
ffms: no
mp4: no
gpl: yes
thread: posix
opencl: yes
filters: crop select_every
debug: no
gprof: no
strip: no
PIC: no
bit depth: 8
chroma format: all

Any ideas?

[LoRd_MuldeR]

-march=corei7, -march=bdver3 and fprofile didn't give any speed benefit but pthreads gave a consistent 1.5-2% speed increase over win32threads.

Unfortunately, there seems to be some incompatibility between x264 and the PThreads library that ships with recent MinGW builds.

Got some strange effects where x264 was running with less than 1 fps, unless "--threads 1" is specified. Problem was resolved for me when building with "--enable-win32thread".

EDIT: Only issue remaining is compiling with ffms, lavf, etc. 64 bit exe. 32 bit works fine. I'm using komisar's mingw 4.8 and libpack.

You need to make sure that the required header files are in your include path, and the required lib files are in your library path.

Assuming you have your x264 sources in "c:\sandbox\x264" and the library pack in "c:\sandbox\libpack", then you'd need to add the following:

./configure --extra-cflags="-I../libpack/include" --extra-ldflags="-L../libpack/lib"

(And if it still doesn't recognize the external libraries then, just have a look at "config.log" to see what exactly went wrong)

[turbojet]

./configure --host=mingw64 --extra-cflags="-I../libpack/include" --extra-ldflags="-L../libpack/lib" had no effect. I had originally merged libpack with mingw, which worked for x86 but not x64. Separate libpack with that configure line doesn't compile with ffms, lsmash, etc. This might have something to do with it:


$ ls i686-w64-mingw32
bin ffmpeg.tag include lsmash.tag zlib.tag
binutils.tag ffmpegsource.tag lib mingw-w64.tag
bzip2.tag gcc482.tag lib64 pthreads.tag

$ ls x86_64-w64-mingw32
ffmpeg.tag ffmpegsource.tag include lib lsmash.tag

Oh nevermind, lib and include weren't in the libpack dir. Is it bad practice to merge libpack with mingw for x86? Thanks again for all the help, I'm good to go now.

[LoRd_MuldeR]

Is it bad practice to merge libpack with mingw for x86?

IMHO: Yes! Once you start experimenting with different MinGW and/or LibPack versions things will get messy ;)

I'd rather keep my MinGW installation clean from third-party lib/headers and, instead, add the required include/lib paths via "-I" and "-L", respectively - and only when needed.

[turbojet]

No sign of this in r2389. It's a shame because it's required for x264 to function with a windows computer set to sleep, which is by default.

Luckily the patch still works and here's x86 and x64 builds with komisar's latest gcc 4.8x libpack from today: http://www.mediafire.com/download/3io9pw49pbi42fm/x264-2389_nosleep.zip

[turbojet]

Having an issue with the current x264 sources and libpack. With 2389 x264 and komisar's older libpack 2014-01-22 32 and 64 compiles with lavf/ffms. With 2405 x264 source and old libpack, 32 bit builds fine but 64 bit is missing lavf and ffms although configure displays yes, binary is only 2 MB. With 2405 x264 and latest libpack 2014-03-14 neither 32 or 64 bit build with lavf and ffms. Any ideas?