What kind of pc to buy for encoding?

[george_zhu]

I am going to buy a new computer and encoding is probably the most heaby burden for it. From my old experience the video card and memory is more or less irrelevant. The most important is the CPU and the hard-disk. I have already had a 7200rpm ATA100 8M cache HD. I guess that is enough. The faster is too expensive. I feel the Intel CPU is better in encoding than the similar AMD, like 2.0G P4 vs. Athlon 2000+. Is that right? Please correct me if I am wrong. My budget is limited and I want to optimize the encoding with it. Please give me your priority to optimize it Thank you.

[sysKin]

The most important are processor, chipset and speed of memory. Amount of memory (once you have, say, 256mb), speed of harddisk, video card etc are irrelevant.

The fastest P4 are definitely faster than AMDs now. If you aren't buying the fastest possible, AMD might be a better choice (especially for xvid) but I can't tell, I don't even know the prices.

Would be nice to have a comparison between P4 and AthlonXP. Any ideas how to do it, to make it fair?

Radek

[GolovachLena]

I think you should buy AMD processor if you're using Xvid. It's working better on AMDs than P4s. Ask people. I have a P4 and i've never got those fps that happy Athlon owners have.

[Joe Fenton]

DivX is faster on P4s, but QuickTime and WMV9 are both faster on the Athlon 64. I haven't seen any comparisons with XviD between the two, so I can't say if XviD would be faster or slower on the Athlon 64. All the audio encoders I have seen benchmarks on also run faster on Athlon 64.

Remember that this is with existing 32 bit software. Once 64 bit encoding software comes out, the Athlon 64 will have a considerable advantage over the P4.

[Teegedeck]

AFAIK WMV9 is faster on P4s because it is heavily optimized for those. A test in c't 20/2003 had following chart:
(less is better)
Athlon XP 3200+: 47 secs
Athlon 64 3200+: 46 secs
Athlon 64 FX-51: 41 secs
P4 3200: 39 secs

Generally, P4s should still have a little advantage over Athlons when it comes to MPEG-encoding because they're clocked much higher (a kind of crude advantage). Here's MPEG2 and MPEG4 benchmarks (no XviD, though): Tomshardware (http://www.de.tomshardware.com/cpu/20031224/cpu-kaufberatung-17.html)

Anyway, the best budget choice might be a overclockable XP-2600 for less than 100 bucks when compared to a stilly pricy (about double the price) P4 FSB800 2.6 Ghz.

[b00zed]

Six months ago I would have definitely recommended P4 over Athlon XP, but the Athlon 64 appears to have somewhat closed the gap. It still isn't as fast as the P4 when it comes to DivX, but considering the price of the A64 3000+ (which has the same clockspeed as the 3200+, just half the L2 cache), it's a nice option. Of course, now the price of the P4 3.2C isn't as insane as it was back then either.

Other factors to consider are whether you want to do anything else with the computer other than video encoding, which would sway my decision towards the A64.

The question you want to ask yourself is basically "do I want to spend ~100% more on the processor for 21% more gordian knot (http://www.anandtech.com/cpu/showdoc.html?i=1941&p=9) performance?"

[Teegedeck]

Well, when I look into the pricelist of my favourite store, the Athlon 64 3000 could be a good choice. It is 50 Euros cheaper than the Athlon XP 3200+ which goes for the same price as the P4 3.0 Ghz. The Athlon 3200+ (should be comparable to the A 64 3000) needs 216 seconds for Tom's test, the P4 needs 192 seconds.

I guess speed freaks would overclock a P4 3.2. Benchmarks look quite marvelous...

Though you can save a lot of money if you overclock your XP 2600+ to the same clock speed as the 3200+ (I'm not sure how stable this would run though...).

Edit: For other things than encoding, the FX-51 is much better than either the plain Athlon 64 or the P4 (not much of a difference between these two). But memory (RAM) with optimal specs for it is not readily available. So it would (as always) be good to wait - for either cheaper FX-51s with well-designed MBs and memory or Athlon 64s with higher clockspeeds.

[sh0dan]

DivX != XviD.

Someone just posted a link to an article (http://www.digit-life.com/articles2/intelamdcpuroundupvideo/index.html) that shows how different encoders (among this XviD) reacts to different CPU's. The exact settings are not posted, but it clearly shows that DivX encoding times are not representative of the XviD encoding times.

An Athlon XP 2500+ outranks a P4, 3.2Ghz in XviD beta 2.

[Alxemi]

I´m also planning a new hardware buy, maybe in a couple of months, and i have decided Athlon XP (core barton) the higher the better already.
The only thing i´m thinking about right now is if deserves the money to buy a dual motherboard. Any experiences out there?

By the way, an off-topic question:
Is XviD an acronimus of Xvid is not Divx? :)

[GolovachLena]

Originally posted by Alxemi

The only thing i´m thinking about right now is if deserves the money to buy a dual motherboard. Any experiences out there?

I've tried encoding on dual Xeon 1400 mhz system and think it hasn't much sense because codecs don't use multiple threads and they don't gain any benefits from two or more processors. I haven't noticed any considerable speed boost, so don't waste your money.

[b00zed]

Originally posted by sh0dan
DivX != XviD.

Gah!

Following the active threads link, and in my haste to post the reply, I completely missed the fact that I was on the XviD forum. My mistake :(

[mikeX]

i have both an Athlon XP 1800+ and a P4 1.8
though they can't be directly comparable since they have different motherboards and different RAM speeds (msi @ 333 for AMD,qdi@ 266 for P4) and even though i haven't made extensive testing i'd say the speed difference wasn't that noticeable, although the AMD system was faster overall

[Teegedeck]

Thanks, sh0dan! Very interesting reading.

[P0l1m0rph1c]

Memory speed is also important in encoding speed. Do AthlonXP have 800MHz FSB and RIMM memory?

This should also be taken in consideration.

[george_zhu]

Thank you all.


It is interesting to learn that xvid is optimize for AMD. Almost all the benchmarks I saw in Tomshardware or other places favor P4 when comparing the same level CPU (2000+ vs 2.0G P4) in audio/video encoding.

I used to thought to buy a P4, now I might choose to buy a barton 2500+ or 2600+ and overclock it. //:)

[Human_USB]

If you can wait the AMD 64 4000+ is coming out soon. I plan on getting an AMD 64 but I'm a poor college kid. RAM and lots of it help encoding. Make sure to have 512 or more. On my computer I plan on have 2 GBs of ram with a Dual AMD 64 4000+. Over kill yes, but linux loves to kill.

BTW..... if you want fast ram, read this;

**Wrong link.... let me find it.

***Found it

http://www.anandtech.com/memory/showdoc.html?i=1902

[Teegedeck]

For those who understand German, there was a comprehensive review of the current CPU families (including MAC G5s) in c't 20/2003.

And yes, the Athlon 64 does have 800 Mhz FSB-speed with 3.2 GB/s memory transfers in both directions at the same time (equals 6.4 GB/s). It also got an integrated memory controller which makes it unneccessary to use the mainboard's chipset for accessing the memory. RIMM memory has been abandoned for the time being by Intel because only in theory it provides a gain over PC400 DDR-RAM.

Edit: Still, the P4 is superior when it comes to memory transfers. Edit: ...compared to the Athlon64 (not FX-51) - if I got that correctly - because that one only has single channel memory access. (My head starts to hurt now.)

What counts in the end are the benchmark results that tell us whether all those techniques yield a measurable advantage.

[george_zhu]

As far as I understand, RAM is more or less irrelevant to encoding, isn't it?

[Teegedeck]

RAM clock speed and latencies are of some importance (not important enough for me to pay the steep prices that Corsair or TwinMOS charge for their modules, though). The amount of RAM can become important if you have more than two heavy-weight applications running at the same time. I guess 512MBs are fine for most people.

[Human_USB]

I also plan to doing compiling and code work so it all works out.

[b00zed]

Originally posted by Human_USB
On my computer I plan on have 2 GBs of ram with a Dual AMD 64 4000+.

The Athlon 64 doesn't support SMP.

[Joe Fenton]

Originally posted by b00zed
The Athlon 64 doesn't support SMP.

The Athlon 64 can't be used on dual (or more) processor boards, so that is technically true. If you are refering to AMD64, the Opteron does support SMP.

There are two kinds of Opteron mobos: the first is less expensive - the SMP mobo uses one Opteron to access all the memory and the other Opteron accesses the memory across the HyperTransport link; the second is more expensive - the NUMA mobo has each Opteron control its own memory, and the other Opteron accesses the non-local memory across the HyperTransport.

[Alxemi]

I haven't noticed any considerable speed boost, so don't waste your money.
Very usefull information, thanks a lot GolovachLena :)

[temporance]

Originally posted by sh0dan
DivX != XviD.

Someone just posted a link to an article (http://www.digit-life.com/articles2/intelamdcpuroundupvideo/index.html) that shows how different encoders (among this XviD) reacts to different CPU's.Also different settings, different versions of encoders and different video resolutions will react differently to different CPU's.

This article is excellent for an overview, but don't choose your CPU by reading this.

[Wam7]

I read an encoding review a good while ago but I do remember it saying that once you start to use filters then that favours the AMD architecture. If that's the case then I'm begging the Xvid programmers to help us P4 folks out!

[Blue_MiSfit]

DivX != XviD. Someone just posted a link to an article that shows how different encoders (among this XviD) reacts to different CPU's. The exact settings are not posted, but it clearly shows that DivX encoding times are not representative of the XviD encoding times. An Athlon XP 2500+ outranks a P4, 3.2Ghz in XviD beta 2.

Hah I just remembered. Do you all recall Andndtech using Xmpeg to benchmark video encoding? their settings had to be minimum quality high bitrate shit to get 70+fps out of divx 5! So I wrote them an e-mail suggesting they use doom9's guides for showing a real world situation. Looks like me / other people that have surely done the same thing actually made something of an impact on them...

right on. even if im not responsible it still feels good to have them update a little eh?

~misfit

[Danzel]

@wam7

Dont forget that XviD got some SSE2 optimizations in the 1.0betas, and they definately improve the speed a bit, my 1400celeron (with sse2) is now worth encoding with, lol

Danzel.

[Wam7]

Yes, I read that in the specs. As a matter of fact using Xvid 1b3 my system does actually enocde Xvid slightly faster than DivX when I use comparable settings (Xvid=VHQ1), plus the quality for me is slightly better but these are my own unscientific subjective findings. ;)

[Bear]

I have 2 machines for video encoding:

1. P4 3.2
2. Dual AMD 2600 MP

From my experiences, P4 is more stable for video encoding.

As for as the speed, I found P4 is faster for wmv9 encoding. As for xvid, they are I think P4 and Dual AMD are more or less the same. But I still prefer to use P4 to encode, becasue it's more stable.

I usually use procoder and don't use any filter.

[Arcon]

Originally posted by sh0dan
An Athlon XP 2500+ outranks a P4, 3.2Ghz in XviD beta 2.
a bit OT, but is this just a question of compiling the codec with more p4-friendly settings or would one have to optimize the source itself to get a good performance for p4 users?

[odysseus]

Encodes probably are CPU bound so memory is not CRUCIALLY, drop-dead important. BUT, I've seen avisynth/vdub use up 450 meg for ONE encoding. If I didn't have 1 gig the swapping would slow down the encode.

I used to run 2 encodes at a time on my Abit BP6 to get use out of both processors (both overclocked, the temp alarm going off every 10 minutes ....).

If I were still doing 2 parallel encodes at a time my 1 gig of ram would be looking pretty pitiful.


Originally posted by sysKin
The most important are processor, chipset and speed of memory. Amount of memory (once you have, say, 256mb), speed of harddisk, video card etc are irrelevant.

Radek

[Sharktooth]

Ok, let's clear something up.
For the video encoding the memory quantity is not as important as the memory access time and transfer speed.
Actual socket 939 athlon 64s (newcastle core) have dual channel integrated memory controller and 1000Mhz (1Ghz) HyperTransport bus (Athlon 64s series doesnt have a FSB...). That means faster memory transfers and a much lower access times.
A bigger cache also helps a lot during encodings (the 4000+ model has dual channell integrated memory controller and 1MB of L2 cache) coz reading data from cache is extremely faster than reading the same data from the system ram.
BTW, the performance of a codec highly depends on optimizations and, as i said in another thread, a 64bit version of the codecs could improve a lot encoding times (by the use of the new xmm8-15 SSE registers and other optimizations).
But keep in mind P4s execute SSE instructions (vastly used by video and audio codecs) faster than athlon CPUs due to their higher core frequency.
Still some tests of a 64bit version of Lame (in a 64 bit compiled linux OS) shown an increase in performance of over 50% vs. the 32 bit version runnig on the same CPU...
So what PC buy for encoding?
Sincerely i don't know... when we'll have a 64 bit version of windows maybe we'll see the first serious codec ports to x86-64 and the real performances of those athlon CPUs.

[akupenguin]

Originally posted by odysseus
BUT, I've seen avisynth/vdub use up 450 meg for ONE encoding. If I didn't have 1 gig the swapping would slow down the encode.
If you didn't have 1 gig then it wouldn't have used 450 megs. Avisynth caches recently generated frames, to avoid recalculating them if you (or your filters) want to look at them again. By default, it doesn't start forgetting old frames until it has filled half of all available RAM. (You can change the limit with SetMemoryMax().) But when encoding, you're not seeking, so the only caches that matter are those within your filter chain. Unless you have a very complex script with lots of temporal filters, you should be able to drop down to easily 50MB of cache or less with no speed penalty. (Consider that a 720x480 YV12 frame takes ~500KB).

[odysseus]

Was this true for past versions of avisynth? I have vague recollections (nothing I'd swear to) of avisynth/Vdub using 300 meg when I had 256 meg of RAM.

In light of what you wrote, maybe I was doing something really strange on that encode.

As for LRU lists & frame aging, I seem to do a lot more seeking using avisynth/vdub than most people. I love cutting & mixing up DVDs into dozens of highlights. I've started a couple of threads on ways to do fast-preview type operations.

I probably should get Premiere ; ) .

I have not seen this option before, but you're telling me that on vanilla encodes it would not help to use SetMemoryMax higher than normal, even if most of my gig is not used.

Originally posted by akupenguin
You can change the limit with SetMemoryMax().) But when encoding, you're not seeking, so the only caches that matter are those within your filter chain. Unless you have a very complex

[akupenguin]

The documentation says that the defaults have been different in the past, though I don't remember it ever using more than my physical RAM.

No, you weren't doing anything strange: Avisynth saw that it had plenty of memory, and didn't bother trying to be memory-efficient. This might or might not have saved any CPU time, depending on the script.

When I said seeking, I don't mean that a large cache would help for cutting and mixing large clips. But if you access one frame, then grab a small clip from somewhere else (no more than a few seconds, maybe 30 sec with a full 1GB RAM and little filtering) and then return to the first position (or adjacent), then Avisynth can reuse some calculations.

But main use of caching is for temporal filtering: If you have a filter that uses frames n-2 through n+2, then instead of running the preceding filterchain 5 times per frame, it runs it once and remembers the results. But that example would only need 5 frames worth of cache (or maybe a little more considering that LRU isn't omniscient), so 500MB is overkill.

Where a large cache does help is previewing: If you're looking at the avs in VirtualDub or the like, and framestepping around, then you will likely view the same frame multiple times, and a bigger cache is always better.

[Blue_MiSfit]

I recently upgraded to 1gb of ddr400 and an athlon64 2800 from 512mb ddr400 and an athlonxp 2500.

I have barely noticed a difference in encoding, aside from vdub using 300+mb of ram (real producer uses 500+ sometimes!!). Speed seems to be the same.

Here's what you should get:

Athlon XP 2500+ Barton Core (CRUCIAL, this has 512k L2 cache and loads of overclockability)
nForce2 chipset mobo
512MB+ memory (2 sticks for dual channel) with TIGHT TIMINGS!
Video/HD/etc.... doesn't really matter

Memory and L2 cache latency is a huge factor in encoding. Make sure your RAM can run CAS2 or CAS2.5 (lower is better) in full dual channel mode at 400 mhz. You will probably have to pay for this, but it will make a very big difference. If you can afford it, the socket 939 athlon 64's have the badass integrated dual channel memory controllers all on hypertransport. I dont think even Intel's new 921 chipset with ddr2 is faster.

[odysseus]

Is there any way to ask avisynth to always try to read ahead a large number of frames (100, 200, whatever my memory can hold) for fast previewing?



Where a large cache does help is previewing: If you're looking at the avs in VirtualDub or the like, and framestepping around, then you will likely view the same frame multiple times, and a bigger cache is always better.

[Mnl]

Originally posted by Blue_MiSfit

Memory and L2 cache latency is a huge factor in encoding. Make sure your RAM can run CAS2 or CAS2.5 (lower is better) in full dual channel mode at 400 mhz. You will probably have to pay for this, but it will make a very big difference. If you can afford it, the socket 939 athlon 64's have the badass integrated dual channel memory controllers all on hypertransport. I dont think even Intel's new 921 chipset with ddr2 is faster.

Are you sure? In my experience it really doesn't make that much of a difference. Actually I would say that it isn't worth the extra price charged for those ram modules.

This test (http://www6.tomshardware.com/motherboard/20040119/index-08.html) indicates that the difference between fast and slow timings are rather small when it comes to encoding.

[akupenguin]

Originally posted by odysseus
Is there any way to ask avisynth to always try to read ahead a large number of frames (100, 200, whatever my memory can hold) for fast previewing?
Interesting idea. I don't know of any such option. It might be doable as a filter: multithreaded, with one thread responding to avisynth requests while another precaches in the background. But I'm not experienced enough in win32 programming to write it.

[pelle412]

Sorry to chip on this thread but I didn't want to post a new one. I am planning to upgrade one of my PCs for the only purpose of speeding up video encoding. My current specs are:

Motherboard: ASRock P4S61
CPU: Celeron 2.8 Ghz (400 MHz FSB, Northwood core)
Memory: 2x 512MB PC3200 (Nanya M2U51264DS8HC1G-5T) not very good RAM, the cheapest no-name stuff I could find but works.

The two things I want to go FAST are:
1. XviD encoding
2. AviSynth filter processing (e.g. PixieDust)

I don't want to spend too much money so I've looked at either a Celeron D 340 processor, or a P4 3.0 GHz Prescott (1MB L2 cache). I'm open to consider other options too if it's not a lot of money. The Celeron D (local retail store) goes for $140 and the P4 CPU goes for $200.

Do you have any suggestions? My main PC is a Athlon XP 2800 and I have no plans to upgrade that one, it's reasonably fast as it is.

[odysseus]

I've never done win32 programming, so ....

But yeah, I've been looking for an easy way to speed up my virtualdub seek-to-cut-points operations (Alt-left/Alt-right) & I've noted the HUGE speed increase when I need to go back&forth over the same scenes several times.

The solutions so far have been to drop various # of frames, which speeds things up but it means when you do cuts in virtualdub you're not being exact.

That would be a Originally posted by akupenguin
Interesting idea. I don't know of any such option. It might be doable as a filter: multithreaded, with one thread responding to avisynth requests while another precaches in the background. But I'm not experienced enough in win32 programming to write it.

[Sharktooth]

Originally posted by pelle412
Sorry to chip on this thread but I didn't want to post a new one. I am planning to upgrade one of my PCs for the only purpose of speeding up video encoding. My current specs are:

Motherboard: ASRock P4S61
CPU: Celeron 2.8 Ghz (400 MHz FSB, Northwood core)
Memory: 2x 512MB PC3200 (Nanya M2U51264DS8HC1G-5T) not very good RAM, the cheapest no-name stuff I could find but works.

The two things I want to go FAST are:
1. XviD encoding
2. AviSynth filter processing (e.g. PixieDust)

I don't want to spend too much money so I've looked at either a Celeron D 340 processor, or a P4 3.0 GHz Prescott (1MB L2 cache). I'm open to consider other options too if it's not a lot of money. The Celeron D (local retail store) goes for $140 and the P4 CPU goes for $200.

Do you have any suggestions? My main PC is a Athlon XP 2800 and I have no plans to upgrade that one, it's reasonably fast as it is.
AMD chips are faster for xvid encodings, but since you use heavy AVS filters maybe the right choice would be a P4 with HT.
1 HT unit for filtering and the other one for encoding. It should be fast.

[pelle412]

Well, I went and bought a P4 3.0 Ghz Prescott. I'll drop it in tonight and see if I get some oomph. In the meantime, I did some tests on PixieDust filtering and XviD compression with the computers I have available at hand, including a IBM Thinkpad T41 laptop with a Pentium M processor.

A 5 minute, 32 second chapter of Bourne Supremacy with alot of high motion scenes and shaky camera action.

1. Plain crop and PixieDust(limit=2), no resizing and compress to huffyuv.
Athlon XP 2800 = 22 min, 36 sec
Pentium M 1.6 Ghz = 30 min, 21 sec (34% more time than XP2800)
Celeron 2.8 Ghz = 38 min, 17 sec (69% more time than XP2800)

2. Feed the output AVI from test 1 into XviD, 1-pass encoding Q2 with VHQ4, QPEL, AQ, Trellis, etc.
Athlon XP 2800 = 15 min, 59 sec
Pentium M 1.6 Ghz = 19 min, 3 sec (19% more time than XP2800)
Celeron 2.8 Ghz = 21 min, 3 sec (32% more time than XP2800)

Looking at the results for Pentium M at the 1.6 Ghz clock speed, I feel comfortable buying the Pentium 4 Prescott at 3.0 Ghz, believing I'll get a nice performance boost.

[pelle412]

Ok, the 3.0 ghz prescott was disappointing. It runs filtering about as fast as the XP 2800 but XviD encoding is actually slower. This CPU is going back tomorrow and I'll get an Athlon64 instead.

And to top it off, the prescott CPU fan runs very loudly at 4800 RPM.

[pelle412]

Ok, continued evaluation of the 3.0 GHz Prescott revealed that some of my earlier results are a bit misleading. My computer case is not suited for a P4 in that it doesn't allow enough air flow around the processor. This is the primary reason the CPU fan had the pedal to the metal. Running the CPU with an open case brings the temperatures and fan speeds down quite a bit.

As Sharktooth pointed out earlier, combining heavy filtering and XviD compression using hyperthreading does provide an advantage. A test showed that using this method it beat the XP 2800 by about 20%.

[eidenk]

Have two or more well defragmented hard drives and encode from one disk to the other. Speed is usually significantly increased as there are no constant successive read/write operations in different places of the same disk. The difference is especially visible when encoding at high bitrate with fast CPU and codec. If you want to use your OS and other programs while encoding, one disk for the OS and the programs and two disk to transcode from one to the other is ideal. You may even want to use a motherboard with SATA RAID controllers who offers the possibility to install additional hard drives working optionally as one if you need to break the limit of disk read or write that is usually around 20-25MB/s for good 7200rpm non-SCSI drives and that can be reached fairly easily with fast lossless DVD sized compression for example. As for brands I would not recommend Maxtor as I have experienced terminal mechanical failures of Maxtor drives. I use now Caviar. I can't say whether they are objectively better or more reliable though.

[odysseus]

What I'd love to see is someone with the right skill set port XVid to one of those PCI cards with 6 Analog Devices SHARC chips.

real-time or faster DVD->XVid encoding possible?


Originally posted by Sharktooth
AMD chips are faster for xvid encodings, but since you use heavy AVS filters maybe the right choice would be a P4 with HT.
1 HT unit for filtering and the other one for encoding. It should be fast.

[Shinigami-Sama]

I agree
port the audio to the s-card and the video to the vid card and use the cpu for filtering
well maybe the s-card wouldn't work yeah..

[odysseus]

Actually these are not "viceo cards" or "sound cards"

The SHARC are digital signal processors, DSPs. They can do some operations faster than regular CPUs.

There're some companies that make PCI cards full of these. In this configuration they're called "attached processors" or co-processors, a little bit like the old 8088, '387, '487 & Weiteks.

Originally posted by Shingami-Sama
I agree
port the audio to the s-card and the video to the vid card and use the cpu for filtering
well maybe the s-card wouldn't work yeah..

[Sharktooth]

Originally posted by pelle412
As Sharktooth pointed out earlier, combining heavy filtering and XviD compression using hyperthreading does provide an advantage. A test showed that using this method it beat the XP 2800 by about 20%.
Ok, that's what you asked for :)