Megui is extremely slow?

[poisondeathray]

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.

This is true

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.

It's a contributing factor. For sure.

Do you read any hardware review sites or benchmarks? Even when usage is relatively low ,say 50% usage, having more memory will increase performance in many types of applications a few % due to reduced paging. Overall it might be 2-3% across all applications . These are proven reproducible facts, on Windows and Mac OS (probably Linux too). Many websites publish "how much memory is enough" benchmarks those sorts of things etc...(But it's not all that straightforward, occupying more memory channels can actually reduce performance and memory SPD timings , CAS settings, so there are many other things going on, and it depends on the type of memory, motherboard, bios settings, etc... ) . Even x264 benchmarks, which are largely CPU limited in most situations, benefits from more system RAM. It's not because of the application usage itself, it' s from the system swapping memory in the background.

Well whoopty doo... can this tiny few % explain what he's seeing? Well, for one thing he's not at 50% usage, he's near 100%. That's going to negatively impact performance. Can it be the only reason or explain it all by itself? Well he's got a bunch of things going on , vegas, frameserving , etc... That combination along with high memory usage might be critical. You're not testing what he's testing. If you've ever used a NLE, they grind to a halt when you have low free memory. One way to determine what is going on would be to increase system memory on his configuration. If it suddenly increases in speed, you have your answer. He's said that' s not an option for him, but I would bet money that low system memory is contributing a large part

Eitherway, the "answer" to "what to do next" is the same. Just forget about frameserving. Export a lossless intermediate, shut down vegas, and that should even be enough to encode with megui if he wanted to.

[somespirit]

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

you are crazy man, you using bitrate of 50000 ha ha ha ha ha ha ha ha ha ha many times ha ha ha ha aha ..............

lets we assume that you have video with x,y resolution (1280x720 for example) then you can calculate the Bits/(Pixel*Frame) to be some where 0.200 - 0.220 and you can get the rigth bitrate (4500 for 720p video), you can use Bitrate calculator in MEGUI for that purpose ........

[hello_hello]

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

After reading your recent posts in the hard drive cloning thread, I'm not surprised.
http://superuser.com/questions/457301/why-does-windows-7-use-the-page-file-when-theres...e-physical-ram

Applications frequently allocate memory pages which are used very rarely, such as start-up code (used once and then not needed), shut-down code (used once and then not needed), or update code. It's not practical to keep all this in memory when there are much more important uses, so once Windows identifies sections of code that haven't been needed for the current operation of an application, it happily pages out those sections to the pagefile, even if it technically could retain them in memory.
(And actually, depending on the applications, systems might frequently allocate more memory than they actually have, expecting most of it to wind up paged out. If you're looking at a detailed memory breakdown, the "Commit" or "Commit" charge is how much memory Windows has allocated to various applications. The pagefile is used to provide guarantees for this memory, even if it doesn't have enough physical RAM to cover it.)

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

Please enlighten me.
http://en.wikipedia.org/wiki/Paging#Terminology
"On Windows NT based systems, dedicated swap space is known as a page file and paging/swapping are often used interchangeably."

http://www.computerhope.com/jargon/s/swapfile.htm
Alternatively referred to as a page file or paging file, a swap file is a file stored on the computer hard drive that is used as a temporary location to store information that is not currently being used by the computer RAM.

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

Seems to me no effort was spent at all to support that opinion with fact. Thanks for playing though.

[newpball]

You may be delighted to know that Windows 8 does have a separate swap and page file.

[hello_hello]

You may be delighted to know that Windows 8 does have a separate swap and page file.

I'm delighted to see your inability to answer questions remains unchanged, and amused by the fact you mention Windows 8 now when originally your comment was regarding the swap file and XP.

[hello_hello]

It's a contributing factor. For sure.

I will confess I've never quite got my head around understanding page file usage. If the hard drive thrashes a lot, I assume it's being used too much. I wonder if cornery19's hard drive is thrashing away while he's encoding at less than 1fps?

I just checked my page file size. It's 2GB. It's set to 2GB minimum, 6GB maximum. XP_PageFileMonitor agrees it's currently 2GB, but seems to think only 363MB of it is currently in use, and maximum page file usage since last boot is 770MB.
Looking at task manager, it appears there's somewhat of a pagefile usage party going on. The hard drive LED is just flashing once in a while. I guess I don't understand all of the numbers, but how can task manager show 3.07GB of page file usage when Explorer says it's not that big? According to File Properties, the page file hasn't even been accessed in nearly two days.

[newpball]

You may be delighted to know that Windows 8 does have a separate swap and page file.

I'm delighted to see your inability to answer questions remains unchanged, and amused by the fact you mention Windows 8 now when originally your comment was regarding the swap file and XP.

Well, may I say that life, at times, is delightful and amusing:

[racer-x]

Attached are the processes running while I Frameserve from Vegas to Virtualdub to x264. Notice that FrameServer and Virtualdub are light users, while Vegas and x264 are the heavy users. That's how it's supposed to work. Clearly the OP has other pressing issues...

Note that I only have 4 GB or RAM.

[Acımasız]

60fps: --no-deblock --keyint 30 --bframes 2 --b-adapt 2 --b-pyramid none --no-weightb --ref 3 --weightp 2 --no-fast-pskip --range pc

30fps: --no-deblock --keyint 15 --bframes 2 --b-adapt 2 --b-pyramid none --no-weightb --ref 3 --weightp 2 --no-fast-pskip --range pc

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Encoding-for-YouTub...lts-83876.aspx

[hello_hello]

Attached are the processes running while I Frameserve from Vegas to Virtualdub to x264. Notice that FrameServer and Virtualdub are light users, while Vegas and x264 are the heavy users. That's how it's supposed to work. Clearly the OP has other pressing issues...

Note that I only have 4 GB or RAM.

A voice of reason from beyond the "need more RAM" wilderness!
I was a little tempted to download Vegas and test frame-serving myself, but the motivation didn't reach a high enough level. Plus I suspected I might need to make a new video of my "I was right" dance for uploading to this thread later on, and now that's looking more likely, I'd prefer to practice the "I told you so" bit at the end.

I wonder if avs4x264mod.exe could be the bottleneck. Not because of a lack of memory, but for some other reason. I've never used it myself. Apparently MeGUI only uses it when MeGUI/Avisynth are 32 bit and the x264 encoder is 64 bit, but I don't know if there's a way to tell MeGUI not to use it. Maybe it won't if the 64 bit x264 is replaced with a 32 bit version. I don't know how it works exactly as I'm all 32 bit.
Is there any chance Vegas is frame serving video that's not particularly AVIsynth or 32 bit friendly? Or that might cause avs4x264mod.exe to slow to a crawl? I've never used Vegas, but thought it might be worth asking.

Was it established the video is being frame-served by Vegas at an acceptable speed? Is it playing at a decent speed when the AVI is opened with a media player? Or if it's converted to a lossless AVI first? I've had the odd frame serving issue in the past. The problem I've had with VirtualDub's frame server is getting it to work, so that's speed related in a way. I think I had it working once, but it's not worked since, although it has been a couple of years since I've allowed it to drive me nutty.

cornery19,
If you check "Add pre-rendering job" before adding an encoding job to the queue (in the video section), MeGUI will add a few extra jobs too. I think the first job is your normal script, used to encode to lossless AVI (huffyuv), the AVI is indexed, and the lossless AVI is re-encoded with the x264 encoder. However many jobs it adds to the queue, you can delete all but the first one. If you run the first one, the output should be huffyuv/AVI and that should let you check the encoding speed without avs4x264mod.exe or x264 getting involved.

[poisondeathray]

Another way you could indirectly test the role of memory, is frameserve a SD project, which will consume much less memory for vegas , x264, avisynth , and avs2x264mod . This will also test if debugmode frameserver is actually working properly or not in the first place . Although a SD encode would encode faster normally in the first place, his glacially slow speeds are clearly abnormal. If he suddenly gets fast speeds relative to his abnormally slow speeds, that would suggest low free memory is playing a large role in this

Lower free system memory reduces x264 encoding speed, this is a proven fact . The benefits are even measureable when you add RAM so that your usage drops to 25% vs. 50% usage. As for the reason "why", the hardware testers/enthusiasts all say it's related to the page file, and reduced paging, but I don't know if the actual mechanism has been conclusively proven.

[Groucho2004]

Another way to test the frame serving and exclude megui/piping would be to run the Avisynth script through AVSMeter the check CPU load/memory requirements.

[cornery19]

I thank everyone who wasn't quick to jump on the " NEED MOAR RAM" bandwagon without trying to find other solutions to my problem too; yesterday evening while I was giving it another try something that pleasantly surprised me happened :


5fps was the maximum speed I was able to achieve and it never dropped below 2 fps. As you can notice from the list of tasks in task manager, the avs mod isn't there anymore and instead it is replaced by the ffmpeg.exe . I have no idea what happened though, all that I had done differently than before is that this time around I had the "Add pre-rendering job" box checked.


However, just for the heck of it, today I tried enconding it again, this time around without the "Add pre-rendering job" box checked and I encountered the same problem I had encountered before; even if the the fps averaged around 2.56, guess what? Avs4x264mod made a comeback, effectively eating up most of the memory.

[poisondeathray]

The pre rendering job uses ffmpeg to encode a lossless intermediate. It' s not actually encoding your final video with ffmpeg. Also , 5fps seems very slow for a pre-rendering job.

But if you're going to do that, you might has well do it with vegas to a lossless intermediate instead of frameserving, that way you have less overhead , less memory consumption. Encoding from pre-rendered lossless intermediate will always be faster than frameserving through vegas

[cornery19]

The pre rendering job uses ffmpeg to encode a lossless intermediate. It' s not actually encoding your final video with ffmpeg. Also , 5fps seems very slow for a pre-rendering job.

But if you're going to do that, you might has well do it with vegas to a lossless intermediate instead of frameserving, that way you have less overhead , less memory consumption. Encoding from pre-rendered lossless intermediate will always be faster than frameserving through vegas

For the rest of the encoding it was averaging at 4fps, I actually had the whole encoding done in about 3 hours? If not less.

Hmm, you give interesting advice, sounds like a very good option to me actually. What lossless intermediate should I use though?

[poisondeathray]

ut video codec is a favorite of most people that use NLE's. Decoding speed is very fast (low latency), such that they are even usable in the NLE for scrubbing (other lossless codecs are too slow to decode). Because of the low latency, x264 encodes actually become a few % faster, than when using slower lossless intermediates like lagarith. Other options are magic yuv, huffyuv, ffv1, x264 lossless. FFV1 is probably the most compressed (lowest filesize) . Magic yuv is interesting, it's even slightly faster than ut, but it hasn't been as thoroughly tested yet (relatively new)

[hello_hello]

I'm late back to the party but I realised today there is a way to take avs4x264mod out of the equation when using MeGUI (I'm pretty sure). Under external program configuration in MeGUI's settings there's a checkbox for enabling the 64 bit version of x264. With it unchecked, MeGUI should use the 32 bit version and therefore not avs4x264mod.
I'm using XP so the option's completely greyed out and I forgot it was there, but it'd just be a way to confirm avs4x264mod isn't causing a bottleneck for some reason.