Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
17th March 2009, 18:59 | #1 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Resource/memory allocation (x264)
How exactly is this handled under a Linux system? The reason I ask is because while testing out my own builds of x264 on both my computer (Celeron II/PIII "Coppermine", 256 MB RAM, Ubuntu 8.10) and my grandparents' computer (Athlon64 "Orleans", 512 MB RAM, Ubuntu 8.10 64-bit), it seems to use way more resources than the Windows versions do, to the point that the mouse becomes just this side of unresponsive - something I have no memory of noticing when running it under Windows, even using the same encoder settings. It is true that the Linux builds report back higher fps values, which I assume is due to better resource management - if this aspect is just the way it is, then I can live with that.
But on the Orleans, going into standby (something I didn't expect to happen in the first place) seemed to lock up the resources in such a way that an encode that was going relatively smoothly - ~575 frames in about an hour and 15 minutes, as I was using insane settings - just about stopped, and spit out only about four more frames over the course of the next half hour; and this was after coming back out of standby. At least, I assume it was in standby - I'd shut off the screensaver, but the monitor had still shut off on its own and the power light was blinking as if it had gone on standby. It isn't like there was anything the matter with those frames either - I later encoded the same video under Windows and that frame range was encoded and passed just as fast as the rest of the video had been. What sorts of things would cause this? Is it an issue with the compiler (I use gcc 4.3.2; the Windows builds are Skystrife's x86 builds, which use gcc 3.4.6), an underlying OS difference, or something else entirely? When compiling I do use -march=pentium3 and -march=athlon64 CFLAGS, respectively. Would using a different, light-weight environment (like Fluxbox, which I used to use as my main DE a couple years ago; these behaviors were observed under Gnome) be the solution? Anything other than just getting more RAM, basically. |
17th March 2009, 19:21 | #2 | Link | |||
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
Quote:
Quote:
Quote:
|
|||
17th March 2009, 20:20 | #3 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
And yes, I've used x264 under Windows on both of the computers, as they're both dual-boot setups. XP Home 32-bit on both (mine is SP3, their's I think is still SP2, but I could be wrong). |
|
17th March 2009, 20:38 | #4 | Link | |
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
Quote:
How do you feed the input video to x264? |
|
23rd March 2009, 13:17 | #6 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
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 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 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 Code:
VIRT=518m RES=160m %CPU=5.8 %MEM=64.8 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 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 |
|
23rd March 2009, 14:30 | #7 | Link | |
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
Quote:
The way how other running programs behave under these kind of extreme situations is determined by the process CPU and I/O priorities and how much the programs access disk and use RAM. I don't see how Windows would work better when a process runs out of memory and the system starts swapping. To get decent performance out of x264, swapping must be avoided anyway. By using less references and b-frames (when using b-adapt 2), memory consumption is significantly lower (~100 MBs with --ref 5 --bframes 3), encoding is much faster and you don't really sacrifice any significant amount of quality. Last edited by nm; 23rd March 2009 at 14:33. |
|
23rd March 2009, 16:13 | #8 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Ok, so it is simply running out of memory. Normally I don't encode 720p sources, but this was an odd case.
When you say 'over 420 MBs', is there any kind of set-in-stone limit for how much memory would be needed at a minimum for those options (with or without 720p as a deciding factor - as I said, I usually don't encode 720p, the cutoff is usually 720x480; or is the 518m that was reported by top said memory requirements?). The reason being, according to the spec sheet for the i810e, I can put up to 512 MBs of RAM in; while I'm sure that even that still isn't enough, it would provide some level of relief, right? I realize how much of a case of diminishing returns it is to use that many b-frames and reference frames, but I designed that as an insane profile. |
23rd March 2009, 16:51 | #9 | Link | ||
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
Quote:
Quote:
|
||
23rd March 2009, 19:01 | #10 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
Yeah try something along the lines of 5 reference frames and 5 b-frames. Having 16 for both of these creates a massive speed loss, increase memory usage, and doesn't really provide much more benefit. Increasing the reference frames to 10 can be beneficial for animation but even then its usually only a few percent in those cases.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|