Small (visual) bug in x264

[mariush]

I was having some fun with the park joy sequence (the 500 frames for the decoder comparison) and tried to use preset placebo on it...

The system is q6600 4 GB of ram but on 32 bit so only ~ 3.25 available. x264 version is 1853


x264.exe --preset placebo --tune film --pass 1 --bitrate 30000 -o test.mkv park_joy_1080p.avs
avs [info]: 1920x1080p 0:0 @ 50/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1



First there was this...

[0.2%] 1/500 frames, 0.02 fps, 1.#J kb/s, eta 7:06:13


On the next frame it showed something like 54655 kb/s

Then there was this...

x264 [error]: malloc of size 9142272 failedb/s, eta 1:32:39
x264 [error]: x264_encoder_encode failed


now this i figured it's probably the 2 GB per process limit of 32 bit. The curious thing is that I was looking at Task Manager and right before it crashed at about 10 frames processed, the memory was at about 2623 MB used and after the crash it was at 1250 MB...

ps.. with preset veryslow it starts first pass at around 820 MB and goes up with about 2 MB on each frame.

[burfadel]

I'd say you're simply running out of memory. 32 bit programmes do have a 2gb, although this can be changed to 3gb. I'm not sure whether this is the default with Vista or Windows 7, or simply it has been set by yourself or another programme. Either way, its a normal condition and you should try less intensive settings.

[Blue_MiSfit]

Indeed. Time to use a 64 bit operating system :)

~MiSfit

[Dark Shikari]

--preset placebo --bframes 8 will give good enough results and won't cap out memory on a 32-bit system.

[MasterNobody]

or --preset placebo --sync-lookahead 0 if you don't want sacrifice --bframes

[CruNcher]

Also that a Windows application can use the PAE extended Memory space it needs to be compiled with a special Compiler Flag /LARGEADDRESSAWARE that sets IMAGE_FILE_LARGE_ADDRESS_AWARE in the PE header, not sure if GCC does that by default, or supports it @ all ?

See here for the Flag in Microsofts Compiler http://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx , geez it's over hard to find any information about GCC and support for IMAGE_FILE_LARGE_ADDRESS_AWARE, actually i didn't find any information @ all only that the Linux Kernel supports PAE but nothing about GCC as a compiler and how to activate it for 32 Bit Windows applications that get cross compiled ???

O actually i found something :)
http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/b1548cd5e7c15a8b/05628751f5f46111?#05628751f5f46111 so a MingW Cross Compilation toolchain actually supports it i wonder which binary makes use of this it should be easily readable out of the PE header if the compiled binary supports it or not :)

so ld --large-address-aware that's how to link x264 with to support PAE

from the LD Man Page


--large-address-aware
If given, the appropriate bit in the ‘‘Charateristics’’ field of the COFF header is set to indicate that this executable supports virtual addresses greater than 2 gigabytes. This should be used in conjuction with the /3GB or /USERVA=value megabytes switch in the ‘‘[operating systems]’’ section of the BOOT.INI. Otherwise, this bit has no effect. [This option is specific to PE targeted ports of the linker]

[Warperus]

PAE won't help here. Windows XP/Vista/7 32-bit limits addresses to 4Gb even in PAE mode. It is done intentionally on OS side to avoid conflicts with some drivers and some hardware. You might be able to use 3Gb if your OS is configured properly, but it's possible without PAE anyway.
PAE will work well in windows server versions though.

In similar situation for me 64-bit x264 solved the problem (32-bit version failed like this).

I wonder if lower threads setting will help here (it will reduce encoding speed obviously).

[mariush]

I'm using Windows 2003 so if I enabled PAE I would have been able to use more than 4GB without issues though I have only 4 now. I don't enable it because my TV tuner is not aware of it and reads the tv image from the old memory location causing just black screen.

Anyways... I knew from the start it's 32 bit and 2GB per process limit related - I wrote the first post actually for that

[0.2%] 1/500 frames, 0.02 fps, 1.#J kb/s, eta 7:06:13

the #J in the text... I don't even know if it should be fixed, because it would appear only for the first frame ever for maybe a ms if user encodes with this insane settings. but I wonder if maybe some GUIs would crash when they don't get this status as they expect...