PPC x264 encoding vs Dual Intel

[ACoolie]

I've been running my x264 encodes on an Intel Core 2 Duo, and I am thinking about using a 2.0 GHz PPC iMac to speed up. I'm preprocessing my AviSynth into an FFV1 avi. I'm just wondering if I will notice any quality difference over an Intel chip?
I understand that one-core encoding yields better quality, but I am unsure if any assembly code is non-functional on PPC (which could lead to lower quality).

[LoRd_MuldeR]

I understand that one-core encoding yields better quality.

Since when? :confused:

[Dark Shikari]

I've been running my x264 encodes on an Intel Core 2 Duo, and I am thinking about using a 2.0 GHz PPC iMac to speed up. I'm preprocessing my AviSynth into an FFV1 avi. I'm just wondering if I will notice any quality difference over an Intel chip?
I understand that one-core encoding yields better quality, but I am unsure if any assembly code is non-functional on PPC (which could lead to lower quality).Sure, the assembly on PPC is totally different (and less optimized), but why would it affect quality? All assembly has to give exactly the same output as the equivalent C code, or it would be considered broken.

[ACoolie]

Since when? :confused:

The motion estimation code is less efficient over multiple threads, same with scenecuts (im pretty sure).

Alright, thanks for the answer. I was unsure if x264 behaved differently under a different architecture. Some of the newer features like b-adapt and psytrellis may not have been fully implemented.

[Dark Shikari]

The motion estimation code is less efficient over multiple threadsThe effect is so minimal that on some sources I've gotten bitwise equivalent results between singlethreaded and multithreaded mode.same with scenecuts (im pretty sure).I personally think the multithreaded scenecut is better.

[LoRd_MuldeR]

The motion estimation code is less efficient over multiple threads, same with scenecuts (im pretty sure).

I know that multi-threading with slices is less efficient, but x264 doesn't use slices. It uses frame-based multi-threading since a long time :)

[cogman]

Considering that x264 is more optimized for an ix36 platform and sees almost a linear speed increase with the number of cores you have, I see absolutely no reason to want to make your switch. If quality is really THAT big of a deal for you, then throw in an extra reference frame and use Tesa for your motion searching. For the same encoding speed you will get better quality with multi-cores vs single cores.

[ACoolie]

I'm doing a tv series, so if I can do two episodes on this box in the time it takes me to do eight on the other, then I'm 20% more efficient at the same or better quality.

[nurbs]

Wouldn't that mean you are 75 percent less efficient at the same or neglegibly better quality?

edit: Wait, I see what you mean now. :)

[LoRd_MuldeR]

I'm doing a tv series, so if I can do two episodes on this box in the time it takes me to do eight on the other, then I'm 20% more efficient at the same or better quality.

As said before: The speed of x264 increases linear with the number of cores and the loss in compression-efficiency is totally negligible, if at all!
So I'd always go with the Dual Core, or even better with a Quadcore. You'll get a speed-up of 2x or 4x without any noticeable/measurable loss in quality.
Also note that Core2 Quads have become quite cheap. I'd never go back to less than 4 cores. Many people here will agree with that...

Running several encodes concurrently is another story. But at some point the HDD thrashing will become the bottleneck and kill your encoding speed.
So running the encodes consecutively but multi-threaded might be faster in fact ;)

[Blue_MiSfit]

The Core 2 Quad processors are quite simply the best possible way to encode x264. They are stupid cheap (under $200 for a Q6600), have great motherboards, and are rock-solid stable.

I found that one encode at a time (for HD anyway) seems to be the way to go on a quad.

With more processing power (8 core server), even 3 HD encodes at once doesn't seem to thrash the HD too badly. I can get 100% utilization, and at least with my sources (50mbps MPEG-2) DGDecode is the bottleneck for first pass anyway. I did some testing, and 3 in parallel seems to give the most throughput.

~MiSfit

[Sagekilla]

Well, it also depends on encoding speed + settings. To read at 100 MB/s (a good "max" sequential transfer speed) or about 800 mbps, you'd have to be encoding VERY fast, meaning a single HD can feed many cores.

But, I think one at a time is best. If you're doing some preprocessing on a Blu-ray source, you're eating up a LOT of CPU time just to decode + process the video, let alone encode it.