Megui is extremely slow?

[cornery19]

Hi guys, here I am with yet another problem.

I've been trying to render a video edited in sony vegas using the FrameServer+NeroAAC+ MEGUI method, basically as it is explained HERE . The problem is that MEGUI has been processing the a ///12/// minute video for more than 12 hours now and it's only 77% done. The processing rate is INSANELY SLOW at 0,36 fps and I have no idea what to do. The priority is set to high yet it's still taking forever?

Does anybody know what might be causing the problem? Granted I don't have the best PC ever, it runs at only 4GB RAM with a core i3 @1,80 GHz, but come on, it can't be running this slow.

A screenshot of the processing window for your thoughts

[hello_hello]

It's most likely the frameserving. If you encode a "normal" video, what's the speed like? Did you use AVISource() to open the frameserving AVI in the script creator? Similar to this:

AVISource("E:\video.avi", audio=false).AssumeFPS(24000,1001)

Are then any other filters in the script (aside from MeGUI's standard filtering)? And what happens if you open the frameserved AVI in a media player. What's the playback speed like?

[racer-x]

It's definitely not a problem with the FrameServer (that's real-time), more likely you are using heavy filtering in Vegas or megui/avisynth.

[cornery19]

It's most likely the frameserving. If you encode a "normal" video, what's the speed like? Did you use AVISource() to open the frameserving AVI in the script creator? Similar to this:

AVISource("E:\video.avi", audio=false).AssumeFPS(24000,1001)

Are then any other filters in the script (aside from MeGUI's standard filtering)? And what happens if you open the frameserved AVI in a media player. What's the playback speed like?

Hi, thanks for the reply.

I cannot tell you as of now because it's my first time using Megui and I haven't encoded a normal video before. I can't encode it now either, as the one I'm currently encoding is very close to finishing and I can't abort it, that would mean 17 hours of waiting gone to waste. However, as soon as it's done I'll give it a shot and I'll get back to you.

If you watch the video and see what the guy does, I did EXACTLY what he did. I went to tools, created an avi script, then opened the avisynth script, the frameserver video, the audio(which is the same as the video) etc.

I also use x264vfw, just like the guy in the video.

It's definitely not a problem with the FrameServer (that's real-time), more likely you are using heavy filtering in Vegas or megui/avisynth.

/scratches head I was just following the tutorial aforementioned so.. I've really no idea whether I'm using heavy filtering or not. It's weird, because if you look at the tutorial, the video processes as smooth as butter for the guy.

[poisondeathray]

Open up taskmanager, what is your memory usage during this ? You should close down unnecessary services and programs

I didn't watch the video closely, but did you use the same encoding settings ? You can encode 10-20x slower or 5-10x faster by adjusting the encoding settings. There are severe diminishing returns once you get into the slower encoding settings - it's usually better to use a faster encoding preset and higher bitrate

[cornery19]

Open up taskmanager, what is your memory usage during this ? You should close down unnecessary services and programs

I didn't watch the video closely, but did you use the same encoding settings ? You can encode 10-20x slower or 5-10x faster by adjusting the encoding settings. There are severe diminishing returns once you get into the slower encoding settings - it's usually better to use a faster encoding preset and higher bitrate

my memory usage looks something like this

I can't close sony vegas because of frameserver, I've got a chrome tab open for this site, megui and... yep that's about it. Can't go lower than that. However I've read topic here that someone with a 8GB ram + quadcore was experiencing something similar with megui, and I'm sure it couldn't be a insufficient memory problem as he had plenty of it.

I used the same identical settings he used. The video was explaining everything very thoroughly and he also made some presets with the settings he used so whoever tried it out didn't need to go through the hassle of configuring everything manually, but I did it anyway.

What settings do I need to mess around with to increase the speed anyway? Anyhow I'm using a bitrate of 50000.

Oh btw, major update. The processing fps has now dropped to 0.29. I've been processing this for 18 hours so far.

[hello_hello]

I cannot tell you as of now because it's my first time using Megui and I haven't encoded a normal video before. I can't encode it now either, as the one I'm currently encoding is very close to finishing and I can't abort it, that would mean 17 hours of waiting gone to waste. However, as soon as it's done I'll give it a shot and I'll get back to you.

You can start another encode while one is running. Add the encoding job to the queue, right click on it, and select "run in temporary worker". MeGUI also lets you add/delete "workers". The upshot being you can choose how many encodes to run at a time. If I'm using slow filtering in a script, I generally run two or three at a time.

One "gotcha". The Abort button under the Queue tab aborts all running jobs, and right clicking on a running job and selecting Abort does the same. If you want to abort only one of the running jobs, you need to use the Abort button at the bottom of the appropriate encoding progress window.

There's an option in the x264 configuration called "stitchable". It allows encoded video to be appended (assuming the same encoder settings). If you keep it checked, it can help to recover from accidentally aborted encodes.
If you abort an encode before it's finished, you can open the output video with MKVMergeGUI and split it. Basically, you save it as a new MKV while discarding a section near the end, preferably at the beginning of a scene change. Then you can start the encode again from the point where you split it. The AVS Cutter under MeGUI's Tools menu lets you add "cuts" to a script so you can encode just the bits you want. When the remaining encoding has finished you can append the encoded video with MKVMergeGUI, add the audio etc, and save that as a complete MKV.

I also use x264vfw, just like the guy in the video.

How and why are two questions that come to mind. I don't think you can use the vfw version with MeGUI and I've no idea why you'd want to. Maybe whatever you've done there is the problem. Did you replace the version of x264 that comes with MeGUI? I didn't watch the whole video but I didn't see x264vfw mentioned.

I was just following the tutorial aforementioned so.. I've really no idea whether I'm using heavy filtering or not. It's weird, because if you look at the tutorial, the video processes as smooth as butter for the guy.

None of MeGUI's filters are "heavy", in respect to being slow. If you were to use slow filtering, it'd be something you'd add to a script yourself.

Not that it helps you, but I had an odd one yesterday. Using QTGMC in some scripts, encoding two at a time, and for some reason one of them slowed to a crawl. Only one. The rest were fine and I couldn't see a reason for it. Eventually it dropped to less than one frame per second so I gave up and aborted it. When I ran it again, changing nothing, it ran at normal speed. CPU usage was only a couple of percent the first time. When I started the encode again that went back to normal too. Maybe it was some odd Windows multi-threading issue?

Normally I can run an encode while the CPU sits on 100%, or close to it. If I'm using slower filtering I run more than one at a time and keep the CPU busy that way. When I do, MeGUI can sometimes have memory issues if I preview scripts while multiple encodes are running, but that's just the video player. The running encodes keep going at normal speed. I'm using XP

What settings do I need to mess around with to increase the speed anyway? Anyhow I'm using a bitrate of 50000.

The general x264 rule of thumb is to load the default settings, pick a profile/level and tuning if you so desire, select a quality (CRF value) and use the slowest x264 speed preset you can stand. The default is medium. I mostly use medium or Slow. If you want more speed, use a faster x264 speed preset. There's mostly no need to fiddle with x264's advanced settings, and you shouldn't unless you really know what you're doing.
The idea behind selecting a bitrate is it allows you to control the file size. If you pick a quality instead, you can't know what the bitrate will be, but you'll know what quality to expect. CRF18 is roughly where the x264 encoder is considered to be "transparent" (default settings). If you want absolute perfection, you can go as low as CRF16 or 15, but the file sizes will increase a fair bit. I don't know why the guy who created the video used presets or what settings they might involve, but generally it's not necessary. I've seen some quite "odd" recommended settings over the years.

[poisondeathray]

You need more memory. You don't have enough to frameserve from vegas. That's probably part of the reason - you're swapping memory to your page file

Megui has a slider for the presets on the 1st page. You can choose something faster, like "very fast". The default is medium.

[cornery19]

I cannot tell you as of now because it's my first time using Megui and I haven't encoded a normal video before. I can't encode it now either, as the one I'm currently encoding is very close to finishing and I can't abort it, that would mean 17 hours of waiting gone to waste. However, as soon as it's done I'll give it a shot and I'll get back to you.

You can start another encode while one is running. Add the encoding job to the queue, right click on it, and select "run in temporary worker". MeGUI also lets you add/delete "workers". The upshot being you can choose how many encodes to run at a time. If I'm using slow filtering in a script, I generally run two or three at a time.

One "gotcha". The Abort button under the Queue tab aborts all running jobs, and right clicking on a running job and selecting Abort does the same). If you want to abort only one of the running jobs, you need to use the Abort button at the bottom of the encoding progress window.

I also use x264vfw, just like the guy in the video.

How and why are two questions that come to mind. I don't think you can use the vfw version with MeGUI and I've no idea why you'd want to. Maybe whatever you've done there is the problem. Did you replace the version of x264 that comes with MeGUI? I didn't watch the whole video but I didn't see x264vfw mentioned.

I was just following the tutorial aforementioned so.. I've really no idea whether I'm using heavy filtering or not. It's weird, because if you look at the tutorial, the video processes as smooth as butter for the guy.

None of MeGUI's filters are "heavy", in respect to not being slow. If you were to use slow filtering, it'd be something you'd add to a script yourself.

Not that it helps you, but I had an odd one yesterday. Using QTGMC in some scripts, encoding two at a time, and for some reason one of them slowed to a crawl. Only one. The rest were fine and I couldn't see a reason for it. Eventually it dropped to less than one frame per second so I gave up ands aborted it. When I ran it again, changing nothing, it ran at normal speed. CPU usage was only a couple of percent the first time. When i started the encode again that went back to normal too. Maybe it was some odd Windows multi-threading issue?

What settings do I need to mess around with to increase the speed anyway? Anyhow I'm using a bitrate of 50000.

The general x264 rule of thumb is load the default settings, pick a level and tuning if you so desire, select a quality (CRF value) and use the slowest x264 speed preset you can stand. The default is medium. I mostly use Medium or Slow. If you want more speed, use a faster x264 speed preset. There's mostly non need to fiddle with x264's advanced settings, and you shouldn't unless you really know what you're doing.
The idea behind selecting a bitrate is it allows you to control the file size. If you pick a quality instead, you can't know what the bitrate will be, but you'll know what quality to expect. CRF18 is roughly where the x264 encoder is considered to be "transparent" (default settings). If you want absolute perfection, you can go as low as CRF16 or 15, but the file sizes will increase a fair bit. I don't know why the guy who created the video used presets or what setting they might involve, but generally it's not necessary. I've seen some quite "odd" recommended settings over the years.

Oops, pardon me really. I basically know nothing about Megui and how it works, I guess that's a big downside for me. Thank you for the precious input! However I tried what you told me to do and processing a "normal" video is basically 12023232923x times faster, and I'm not exaggerating. Okay maybe I am a little bit, but sweet heavens did it process quickly.

Facepalm's on me again, I wrote vfw because I'm an airhead, I was talking indeed about x264.

This is what the x264 config window looks like for me. The settings weren't changed that much, except I have no idea what the stuff written at the bottom is.

[racer-x]

You need more memory. You don't have enough to frameserve from vegas. That's probably part of the reason - you're swapping memory to your page file

Megui has a slider for the presets on the 1st page. You can choose something faster, like "very fast". The default is medium.

I also believe this is your main problem.

I can tell you that earlier today I just finished encoding my Family Xmas video(1 hour in length). I frameserved out of Vegas into Virtualdub and encoded to x264 + aac mp4. I averaged 28 fps encoding speed for 1080p @ 24fps output. This is on my new i7 with 4GBs of RAM. My old Q9300 averaged about 10 fps encoding speed for the same settings. Your's should be faster than that.

[cornery19]

You need more memory. You don't have enough to frameserve from vegas. That's probably part of the reason - you're swapping memory to your page file

Megui has a slider for the presets on the 1st page. You can choose something faster, like "very fast". The default is medium.

I also believe this is your main problem.

I can tell you that earlier today I just finished encoding my Family Xmas video(1 hour in length). I frameserved out of Vegas into Virtualdub and encoded to x264 + aac mp4. I averaged 28 fps encoding speed for 1080p @ 24fps output. This is on my new i7 with 4GBs of RAM. My old Q9300 averaged about 10 fps encoding speed for the same settings. Your's should be faster than that.

Okay so if my main problem is my memory, it means it has nothing to do with Megui itself at all? As I said, my knowledge of Megui is very limited as I'm a noob in the field (though I'm more than eager to learn).

In a fit of rage (dang me for being impulsive) I aborted the processing when it was at 80% (AFTER 20 HOURS WTF) and I started all over again thinking that would help. Nope, the average processing fps doesn't go above 0.30. I'm really desperate as of now.

I hear you speak about virtualdub, does it do a similar job to Megui's? would it be more effective?

I just... really need a solution for this, dang it

[hello_hello]

This is what the x264 config window looks like for me. The settings weren't changed that much, except I have no idea what the stuff written at the bottom is.

It's the commandline sent to the x264 encoder. If you change an encoder setting to something other than the default value, it'll be added to the command line. Keep in mind, the x264 speed presets are just different configurations of x264's advanced options, so when you change a speed preset some of the defaults for the advanced options change accordingly. As an example:

Open the x264 encoder configuration, load the defaults, check the "show advanced settings" box, and under the Frame-Type tab, change the number of Reference frames to 5. --ref 5 will be added to the command line. Now change the x264 speed preset to slow. --preset slow will be added to the command line. If you go back to the Frame-Type tab and check the Reference frame value again you'll see it's still 5, but it's not added to the command line any more as --ref 5 is the default for the slow x264 speed preset. Hopefully that makes sense.....

[newpball]

You need more memory, plain and simple.

4GB is really insufficient for video processing. I would recommend 16GB or 8GB if you want to push it to the minimum.

Memory is cheap you can easily get 8GB for under $75, that's 21 grande lattes at Starbucks.

[_Al_]

4GB and using Vegas, frame serving to megui or whatever else should be ok ...

[racer-x]

4 GB Ram may not be ideal, but it is perfectly usable. That's what I've been using the past 6 years in fact. Just to prove the point, here is a live screen recording while I edit 4k HEVC 4096 x 2160 @ 24p on my old Q9300 with 4 GB RAM. I left the Sys Monitor running for referance....

https://forum.videohelp.com/attachments/29132-1418585754/4K_HEVC_edit.mp4

This guy's problem is "avs4x264mod.exe" (whatever the hell that is) is sucking up all his memory. Probably some kind of leak.

[poisondeathray]

Okay so if my main problem is my memory, it means it has nothing to do with Megui itself at all?

Correct, it has nothing to do with megui or x264, since when you encode without frame serving or vegas, it's much faster

95% memory usage is going to slow down your encodes eitherway. It might not be the only factor, but it's definitely contributing. The way windows handles memory is it swaps out to the page file even around 50-60% usage (probably even lower). Even if you have a SSD for your page file, it's going to be slower. A mechanical HDD will be even slower

Frameserving adds overhead. Avisynth (which is a frameserver too) adds overhead . All those things add up. But a large contributing factor is the memory consumption


You don't have to frameserve from vegas. Another option is to use a lossless intermediate (eg. ut video codec), then use that as input into x264 or some gui like megui

[racer-x]

When encoding x264, your CPU should be maxed out, not memory. Your CPU is only at 4%.

Look for anything you don't need running and kill it off. Example Chrome and your antivirus.

Here is my screenshot while frameserving from Vegas to Virtualdub and encode to x264 + aac .mp4

[cornery19]

Okay this is a reply to everyone. As Racer-x said above, the thing that eats up most of my memory is the avs4x264mod.exe , which from what I've read online is related to avisynth. Racer, maybe you could PM me and tell me exactly how you do it? Maybe if I follow your exact indications I will be able to achieve some decent processing speed too.

Since I'm broke as heck I cannot afford investing even as little as 75 into more memory, so that's not an option, sadly I'll have to manage with what I have at hand.

Given the shitty little memory I have, does any of you know any other efficient way to render from Vegas? Even if the quality would degrade a little, it doesn't matter as long as the difference isn't too significant. Thank you all


Edit : Racer, but last night I left my PC on while I was sleeping so the video could also process overnight if needed and I had nothing opened except for the necessary : MeGui and Vegas. No Chrome, maybe the antivirus yes but memory consumption from other sources was minimal. The thing that eats up most memory is the avs mod thingy.

[racer-x]

As luck would have it, there is a thread on that here. https://forum.videohelp.com/threads/367446-Virtualdub-External-Encoder-feature

Make sure to read it over and you understand it, I don't have the time to hold your hand. You could also try something simple like Vidcoder. If Vidcoder doesn't import the frameserve.avi, the make an Avisynth script for it to feed Vidcoder.

[cornery19]

As luck would have it, there is a thread on that here. https://forum.videohelp.com/threads/367446-Virtualdub-External-Encoder-feature

Make sure to read it over and you understand it, I don't have the time to hold your hand. You could also try something simple like Vidcoder. If Vidcoder doesn't import the frameserve.avi, the make an Avisynth script for it to feed Vidcoder.

Well seeing that you've been actively replying to my thread I thought you could give me a hand, but it's fine, I'll manage with the link you've given me

I'll also try the Vidcoder way and pray it'll work... cross your fingers for me guys

[racer-x]

You shouldn't need avs4x264mod.exe anyway.

1) Copy the command below into Notepad as save as FrameServe.avs and place it in the same folder that you save the frameserver.avi file in.
2) Frameserve out of Vegas and save as serve.avi
3) Load FrameServe.avs into MeGui and encode as usual.

AviSource("serve.avi")
ConvertToYV12()

[hello_hello]

95% memory usage is going to slow down your encodes eitherway. It might not be the only factor, but it's definitely contributing. The way windows handles memory is it swaps out to the page file even around 50-60% usage (probably even lower). Even if you have a SSD for your page file, it's going to be slower. A mechanical HDD will be even slower

Frameserving adds overhead. Avisynth (which is a frameserver too) adds overhead . All those things add up. But a large contributing factor is the memory consumption

I subscribe to the school of thought that memory not being used is memory being wasted, but it doesn't necessarily mean it's required. Even the paging file..... programs ask Windows for memory and it tries to give them what they're actually using from RAM and it assigns what they're not using to the paging file. That keeps the programs happy but it doesn't mean the paging file is actually being used for data.

I've never used Vegas so I can't comment there, maybe it's a hog, but I regularly run 2 or more encodes with QTGMC in a script, while watching a movie and browsing this forum. I have 4Gb RAM (3.5gig available to Windows). Sometimes a new movie is a little slow to open, and sometimes if I've got lots of tabs open and haven't used it for a while, the browser takes it's sweet time coming back to life, but none of that seems to put much of a dent in encoding speed. It stays pretty steady.

[hello_hello]

Okay this is a reply to everyone. As Racer-x said above, the thing that eats up most of my memory is the avs4x264mod.exe , which from what I've read online is related to avisynth. Racer, maybe you could PM me and tell me exactly how you do it? Maybe if I follow your exact indications I will be able to achieve some decent processing speed too.

avs4x264mod.exe is an "intermediate" between AVIsynth and the x264 encoder, letting you output stuff with AVISynth x264 doesn't understand. Some types of high bit depth video as an example (although MeGUI doesn't use it for that). http://forum.doom9.org/showthread.php?t=162656
Actually, MeGUI only uses it under certain circumstances. I kind of remember it's only when using a 64 bit x264 with 32 bit MeGUI, but that could be wrong. I asked about it in the MeGUI thread at doom9 a while ago but I can't find the post. I'm fairly sure I've never seen it running on my 32 bit XP PC. If I remember more details, I'll post back.

Found it. I remembered correctly.
http://forum.doom9.org/showthread.php?p=1689559#post1689559

"MeGUI includes avs4x264mod in it's collection of tools/utilities, but I've no idea when it decides to use it."

"When 32bit MeGUI (and therefore 32bit AviSynth) is used together with 64bit x264."

[poisondeathray]

95% memory usage is going to slow down your encodes eitherway. It might not be the only factor, but it's definitely contributing. The way windows handles memory is it swaps out to the page file even around 50-60% usage (probably even lower). Even if you have a SSD for your page file, it's going to be slower. A mechanical HDD will be even slower

Frameserving adds overhead. Avisynth (which is a frameserver too) adds overhead . All those things add up. But a large contributing factor is the memory consumption

I subscribe to the school of thought that memory not being used is memory being wasted, but it doesn't necessarily mean it's required. Even the paging file..... programs ask Windows for memory and it tries to give them what they're actually using from RAM and it assigns what they're not using to the paging file. That keeps the programs happy but it doesn't mean the paging file is actually being used for data.

Page file is always used for data. Even if you disable it. Even if you had 60% usage, in theory, it could keep everything in DRAM, right? But Windows doesn't it actively swaps. For him, at 95-100%. Now that's going to be a problem.

I've never used Vegas so I can't comment there, maybe it's a hog, but I regularly run 2 or more encodes with QTGMC in a script, while watching a movie and browsing this forum. I have 4Gb RAM (3.5gig available to Windows). Sometimes a new movie is a little slow to open, and sometimes if I've got lots of tabs open and haven't used it for a while, the browser takes it's sweet time coming back to life, but none of that seems to put much of a dent in encoding speed. It stays pretty steady.

Well how nice for you, but you're not at 95-100% memory usage. This is called a "bottleneck". Why do you think this CPU usage is 4% ? x264 is starved for data, waiting ... idle...




x264 has a lookahead function that gets larger with the slower presets. It stores frames in cache and "looks ahead." x264 by itself should take ~1GB on medium, maybe ~1.2GB on slower for 1080p . So the faster the preset, the less memory usage as well. Avisynth also caches frames in memory it gets larger with more functions, more complex scripts

MeGui is spawning avs4x264mod.exe. I wouldn't bother with frameserver or megui in a low memory situation . I would export a temporary lossless RGB intermediate, close vegas and everything else, then use that as input file to x264 directly. x264 builds can be complied with avs support directly

(You need to use avisynth, because vegas , in 8bit mode will be using "studio RGB" for the conversions to RGB if you had YUV input. You to essentially reverse that by using PC levels in the script)

[hello_hello]

Page file is always used for data. Even if you disable it. Even if you had 60% usage, in theory, it could keep everything in DRAM, right? But Windows doesn't it actively swaps. For him, at 95-100%. Now that's going to be a problem.

I'm not convinced the page file is always being used for data, even when it's being used as such. Windows thinks unused memory is wasted memory too. It tries to use it all, so unused memory assigned to programs is allocated to the swap file. That way, RAM isn't wasted.

I wasn't using 90% memory, so I started a third encode. Memory usage for the first two has dropped a bit. It was shown as around 1,100,000 each before I started the third one. I'm still browsing. I'm still watching a movie. uTorrent is still downloading. I'm saving screenshots. This is an old Q9450 quad core. It's feeling less responsive, but encoding speed is still normal..... for single threaded QTGMC.

[poisondeathray]

It's feeling less responsive, but encoding speed is still normal..... for single threaded QTGMC.

Are these 3 SD QTGMC encodes with the same settings? It's definitely not "normal" since all 3 have different encoding speeds. A 58% difference from fastest to slowest is significant difference wouldn't you say ?

[hello_hello]

It's feeling less responsive, but encoding speed is still normal..... for single threaded QTGMC.

Are these 3 SD QTGMC encodes with the same settings? It's definitely not "normal" since all 3 have different encoding speeds. A 58% difference from fastest to slowest is significant difference wouldn't you say ?

Even when everything is the same, encoding speeds are rarely identical when using QTGMC. Maybe it's to do with process priority, or sometimes the phase of the moon.

The first was QTGMC de-interlacing with some noise filtering. Two and three are QTGMC in progressive mode. I aborted number three after posting. Number one is currently plodding along at 7.08fps. Number two at 3.80fps. So I lost 3 or 4fps by cancelling the third encode and the first gained 1fps as a result. CPU usage is currently sitting on 86%. You've got to admit, speed differences aside, I'm still nowhere near 4% CPU usage bottleneck territory and less than 1fps encoding speed. And remember, while his encode was crawling along cornery19 ran a (simultaneous?) test encode which ran at normal speed, despite the fact I'm fairly sure it'd use RAM too. I agree cornery19 has a bottleneck somewhere, but I'm not convinced its a lack of memory.

[poisondeathray]

Encoding speeds should be the same with single threaded QTGMC (or very close). The windows scheduler should roughly evenly distribute between them

yes, I said above there are probably other factors, but high memory usage is definitely contributing. Or are you convinced high memory usage has absolutely nothing do to with reducing performance ?

To do a better test (not cpu limited), you could eat up memory by opening some tabs in a browser, or some large images

He said aborted his encode. I'm assuming that was to do the standalone megui test

[hello_hello]

They were very close. The first encode was being de-interlaced so it can't be compared with the other two. The others were running QTGMC in progressive mode and the speed difference was less than 1fps.

I've used QTGMC in scripts more times than I can remember. I could guarantee 99.9999% if I aborted one of the simultaneous encodes, memory usage would drop, CPU usage would drop, and the speed of the remaining encode would barely change, if it changes at all. If two encodes are running at slightly different speeds they'll do so if they're run individually or at the same time (quad core). Default x264 settings, slow or medium preset, with the default QTGMC settings.... it usually takes running a third encode before the first two take any sort of a speed hit, but the PC becomes somewhat unresponsive.

x264's encoding speed tends to change as an encode progresses. More complex motion seems to slow it down a bit. I'd be surprised if the same didn't apply to QTGMC, so I'd almost expect the speed to vary a bit.

I still doubt it's memory usage. To my way of thinking it's unlikely to be enough of a bottleneck to slow encoding speed to almost nothing. If it's a lack of memory and the paging file is being used extensively the hard drive should be constantly busy swapping data around, and the PC would probably be unusable for anything else. My guess is the hard drive LED is indicating very little activity and all other software is running at normal speed, but cornery19 would need to report on that one.

[newpball]

I'm not convinced the page file is always being used for data, even when it's being used as such. Windows thinks unused memory is wasted memory too. It tries to use it all, so unused memory assigned to programs is allocated to the swap file. That way, RAM isn't wasted.

The swap file?

I am watching your explanations of operating systems with a bit of astonishment.

XP has no swap file by the way, and yes there is a difference between a page and a swap file.

Seems to me a lot of effort is spent to question the obvious here: he needs more memory!