Building a computer for TMPGEnc

[ses]

Regards everyone,
It was suggested from the forum administrator that I move my post here, so here goes!
I am looking to build a new workstation PC which will have the primary task of compressing video with TMPGEnc; as fast as possible. I have pretty much developed my recording computer for the living room, but with it's far too slow Celeron 2.2 processor, it takes 20 hours to process a film that was recorded in AVI format.
So speed is important. I know that TMPGEnc is not the fastest video compression program there is, but it is the program with which I have recieved the finest picture quality. Even VHS tapes come out better looking after a bout with TMPGEnc.
So which direction should I go? AMD or Intel and how large of a processor do I need to cut down compressing a 90 minute film from the 20 hours that it now takes to four to five hours, or at least less than 10 hours. Then there is the question of which motherboard would be the best choice to handle all this power as well. It seems that TMPGEnc is more dependant on the processor than the RAM memory. I have increased my memory and have seem no improvement in processing speed with the program.
For the record, I'm running the nVida Personal Cinema FX5200 card. I use the iuVCR recording program to record in .avi format. I have a 2.2 Celeron with 768 MB of RAM (DDR). If it's a long film, I use the Huffyuv codec, if it's a one hour program or less, I'll just used a pure .avi file. And of course, run it through TMPGEnc for the final result.
How I'm going to transport these mega files to the workstation computer is another question. First, I thought about gegabit network cards, but then I'd need to get a new router and all that. So, recently I thought maybe I'd try copying an already recorded .avi file to a portable harddrive via firewire and then plug it into the workstation machine for processing. I tried recording .avi directly into a portable harddive via firewire but that didn't work at all.
It would be great to keep the living room computer small and have the power in the workroom if I can.
There's so much stuff out there that I have no idea which way to go.

[dZeus]

video editing and transcoding is not really 'HTPC' use. Here in the Desktop Video forum you are more likely to get usefull answers

[Sciascia]

You know I was doing something similar but decided after a while that it was just easier to buy an AIW 9700 Pro and record to MPEG2 DVD spec in realtime. The quality is quite impressive and by the time you spend all that money you are still looking at about 12 hours minimum, plus hard drive space. The AIW 9700 Pro is only about $195 at newegg and you could probably even go with an AIW 9600 for less than that.

As for which CPU, Intel is usually faster at video encoding and the higher the clock rate, the faster it is, so basically as fast as your wallet will let you go. For a MB, go with an 875 or 865 chipset, they are dual channel DDR (PC3200 ram) and run at 800MHz. I did some testing for Hulk a while back with dual channel and non dual channel it was quite an increase in speed. More ram is better, but with encoding it is usually the CPU as the bottleneck. It is usually better to go from one HD to another, but as I just said the CPU will be the bottleneck so it shouldn't make a lot of difference.

You could also look into another encoder like CCE, it is WAY faster and actually better quality than TMPGEnc. There are different versions out there available so look around and see which one fits your needs. I know that it used to be really expensive, but I think that they have a lower end version out now. Just to let you know that there are a lot of "demo" versions of it out there. You can atleast check it out to see if you like it and then buy it. It really is impressive.

[Debbie]

It often depends on what material you have. I you have to use filters, encoding can take four times longer than it will take without.

Also a reduction in encoding speed will result if you have to change the x and y of the frame size.

If you are upgrading your hardware, get the fastest processor available and surely not less than 512 mb. of ram. As for the brand of the processor, I would go for Pentium and also Pentium chipset. SIS cipset is also quite good. This is what I'm using at the moment and I'm quite pleases with its performance.

I started with VIA cipset but today I avoid it "like the plague". Also get a fair size power supply (PSU) 400W or better.

If you're after high quality do'nt expect "real time" jobs. Remeber that what you encode will last much longer that the time it takes to do the job. As for gear, it all depends on the "size" of your pocket

Debbie

[Dr Mordrid]

Capture cards just cannot encode with the quality of a standalone encoder if for no other reason than many/most of them use the Ligos GoMotion encoder engine.

The Ligos GoMotion engine is not looked upon very highly these days dispite its being used in many capture cards, where its main advantage is low development cost. In return for low development cost you get saddled with inferior motion compensation, lower quality and a limited number of settings.

This is a major reason why Ulead dropped GoMotion from MSPro and went with MainConcept as the core of MPEG.now. MainConcept has been making great strides in quality and speed while GoMotion has improved very little in the same period.

Yes; GoMotion is used in the RT.X100 realtime export engine....but even so I'd rather export MPEG from the RT.X100 using Premiere's MainConcept encoder than the Ligos engine because it offers more control and higher quality.

In terms of standalone encoders IMO the best bang for buck is now MainConcept 1.4. It costs about the same as TMPGEnc 2.x, less than TMPGEnc 3.0 and is 2 - 2.5x faster than either when doing 1-pass encoding. The only real advantage to TMPGEnc these days are its embedded video filters.

On an AthlonXP 2400+ system or faster MainConcept can encode *.avi's to DVD faster than realtime using 1-pass encoding while maintaining higher quality than capture encoders. It does about 2 - 2.5x realtime using 2-pass. See my SIG for a system capable of this kind of performance.

2-pass encoding is of good utility when you have video with lots of motion in it. The first pass analyzes the video for sequences that need special attention and the second pass does the actual encoding. MC's 2-pass mode is better than TMPGEnc's.

Dr. Mordrid

[Hulk]

Hi. Last year I did some TMPGENc tests on my P4 3.06 to investigate the effect of hyperthreading on encoding performance.

HT does help encoding and interestingly, as the motion search is increased HT provides less benefit. I an only assume that the motion search routine is NOT multithreaded while the bulk of the encoding process is. So as the motion search portion of the encode increases HT is not used as much in relation to the rest of the encoding tasks.

Here are the numbers I recorded:

HT increase fps
slowest 7.8% 9.4
slow 21.4% 15.7
normal 30.0% 21.1
motion 35.3% 24.8
fast 40.3% 26.7
very fast 41.1% 28.9

Settings were CQ 75 and Field A. Audio was also encoded to mp3 format.

As you can see, at the "very fast" setting my system can almost encode at realtime. I don't know how an AMD system would compare but the P4 w/HT on does a very good job with TMPGEnc.

I usually encode using "slow" since the quality is very good and there is a significant bump from HT. But, as Doc stated, the 2-pass Main Concept encoder has improved so much over the past year it has almost caught up to TMPGENc.

I hope that helps!

- Mark

[spadnos]

Originally posted by Hulk
[snip
HT does help encoding and interestingly, as the motion search is increased HT provides less benefit. I an only assume that the motion search routine is NOT multithreaded while the bulk of the encoding process is. So as the motion search portion of the encode increases HT is not used as much in relation to the rest of the encoding tasks.
[snip]
- Mark

This may have nothing to do with multithreading.

A couple of points about HT:
Remember that there is actually only one processor. HT provides a second register set, and facilities to make the processor look like two CPUs, but there are no extra execution units to go along with it. Because the two "CPUs" share execution resources, there's only one SSE unit, which is shared between the "processors". (actually, everything except the registers and "machine state" is shared).
So, if you have an algorithm that's memory bound or that uses a lot of SSE / floating point instructions, the benefits of HT will be reduced.

HT is just a way of utilizing more of the transistors on the chip by getting multiple paths to the execution units.

- Steve

[Hulk]

Steve,

Interesting. I was just trying to make an educated guess.

Do you have any ideas as to why HT increases in rendering decrease as motion search increases?

Mark

[spadnos]

Originally posted by Hulk
Steve,

Interesting. I was just trying to make an educated guess.

Do you have any ideas as to why HT increases in rendering decrease as motion search increases?

Mark

I suspect that increasing the motion search distance (for lack of a better term) makes the calculation be more memory-bound rather than CPU bound. Remember that the CPU is running between 10 and 20x the speed of memory. If your data set is larger than the cache, then the CPU will be stalling waiting for memory to be fetched into the cache. In HT mode, if the data set is larger than 1/2 the cache, then each process will slow down because of cache misses. In fact, you could get thrashing if the two processes each want say 75% of the cache for their data (when one HT processor asks for some data that's a little stale, and there isn't enough room in the cache for it because the other process has its data there, they keep evicting each other's slightly older data, which wouldn't have happened if the processes were running independently).

The other possibility is that the program is optimized for certain operations - that it uses different algorithms depending on the parameters you set. If they start using floating point once you go past some threshold, but use integer approximations below that point, that would change the resource sharing that can be done using HT.

I don't know what the real culprit is - these are just possibilities based on what I know of the architecture.

- Steve

[ses]

Well thanks to everyone for your answers. I am new to this site and it's nice to get such good , quick responses.
Yes, I did learn the "hard" way that on the fly encoding doesn't work. I was ready to junk my card until I discovered .avi recording.

I'lll have to see just how "big" my pockets are later, right now we are getting a HUGE car repair bill, so there went that computer!

Thanks to you all for your answers