Took a few days before I had the time to run the tests (for curiousness' sake, I also tested under Fluxbox). Here were the results. These still used r1127*; I updated to r1129* this morning but haven't tested it. Nor have I tested the Athlon64 machine.
*the custom options+patches used:
--extra-cflags="-march=pentium3"
x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.10_interlace.diff
The command-line used:
Quote:
|
x264 --crf 18.0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock 1:1 --subme 9 --trellis 2 --partitions all --8x8dct --scenecut 100 --threads auto --thread-input --sar 1:1 --aud --progress --no-dct-decimate --no-psnr --no-ssim --output "output.mp4" "input.i420" 1280x720 --fps 59.94
|
Under GNOME:
x264 running
Code:
######@ubuntu-desktop:~$ free
total used free shared buffers cached
Mem: 253568 250060 3508 0 632 28412
-/+ buffers/cache: 221016 32552
Swap: 281096 206236 74860
x264 not running
Code:
######@ubuntu-desktop:~$ free
total used free shared buffers cached
Mem: 253568 85632 167936 0 272 20780
-/+ buffers/cache: 64580 188988
Swap: 281096 132456 148640
x264 running (top)
Code:
VIRT=518m
RES=160m
%CPU=5.8
%MEM=64.8
I noticed that the responsiveness got worse as the %CPU value dropped. It would start out high, and as encoding progressed, it would drop, and eventually plateau around the 3-6% range.
Under Fluxbox:
x264 running
Code:
######@ubuntu-desktop:/media/disk$ free
total used free shared buffers cached
Mem: 253568 250288 3280 0 232 19436
-/+ buffers/cache: 230620 22948
Swap: 281096 215516 65580
x264 not running
Code:
######@ubuntu-desktop:/media/disk$ free
total used free shared buffers cached
Mem: 253568 138780 114788 0 5996 57976
-/+ buffers/cache: 74808 178760
Swap: 281096 77328 203768
(Fluxbox generally rated 10m or so less under VIRT or RES than GNOME did, although I didn't let it plateau like I did on the other test; the %CPU and %MEM values I had to omit since I really didn't want to deal with a possible slowdown again)