Dual Processors

[chinaboy]

I'm wondering does a dual processor system speed up the conversion? right now I'm using a 1gz athlon with 1gig of ram on xp. it took me 12 hours to do a 95 minute movie.

[mkanar]

A 2nd processor will only offer a 5-15% gain in speed. This is because a single process chain can only run on 1 CPU at a time. Obviously, your money is better spent on a faster chip, for example an Athlon XP 1700.

mkanar

[Necro]

Yes, and send me your setup once you get the new processor :D . I would think that this would aid in the ability to USE the computer when it's doing an encode if you set the encode on high priority on that proc.

[da franksta]

since so many progs are used under dvd2svcd, and so many processes are run serially, maybe smp support is not such a bad idea. A speed gain of 40% should theoretically be possible.

[Labersack]

No, it would not help much, because at every time only one single prog is running.
And the long lasting prog, CCE, did not support a second CPU. Sure it would save some time, but it would be only some minutes...

[Kedirekin]

Actually CCE does have SMP support, but CCE takes a surprisingly small portion of the total clock cycles while encoding. The bottle neck is in the frame serving - I'm pretty sure neither dvd2avi nor AviSynth are SMP enabled.

It's been reported that if you encode directly from an pic video mjpeg encoded avio on an SMP machine, you get huge speed gains (apparently the pic video codec is SMP enabled). I've always meant to test that, but have never gotten around to it. I do know that encoding from a huffy avi is not much faster.

[Labersack]

If this is true, 2 CPUs WOULD speed up much. One CPU could do the frameserving and the other one the ebcoding. Does anyone know for shure if this would work?

[Kedirekin]

It does speed up, but not by much. Depending on filters used, you get anywhere from 51% to 65% processor usage while encoding. This is because the decoding/frameserving creates a bottle neck, thus CCE doesn't get frames fast enough to fully utilize the second processor (or at least that is the theory).

As this is only about a 15% gain over a single processor machine, it hardly justifies the cost of the extra processor. You'd be better off spending the extra cash to buy a faster single processor.

[Kedirekin]

Okay, just for the fun of it, I performed a little test encode using the pic video mjpeg codec. Here is what I did.

Using vDub, I opened the avs file that DVD2SVCD created for a movie. I marked off 1 minute's worth of the movie and saved it as an avi using the pic video mjpeg codec at its highest quality setting. Since I used the avs, it picked up all the resize and TS filtering. vDub took a bit less than 2 minutes to save this 1 minute clip (this was all done on a 1 GHz PIII dually).

I then encoded the avi using CCE and the same settings that I used for DVD2SVCD (5 pass BTW). I got approx 75% processor usage, and a CCE speed of 2.325 (and it was still climbing when it finished, so a full encode would be slightly faster). Yes, that's 2.325 - the full 6 passes (vaf pass + 5 pass encoding) for this one minute clip took about 2½ minutes.

For comparison, when encoding directly from the avs, I get processor usage of about 55% and a CCE speed of about 0.55. The same 5 pass encode for the 1 minute clip would have taken about 11 minutes. Even including the 2 minutes to encode it to an avi, the avi approach is still over twice as fast.

You may not think this makes sense - there's only a 20% difference in processor usage - how can CCE be over 4 times as fast? But remember, the decoding/frame serving takes the first 50%, so the real difference is between 5% (55-50) and 25% (75-50), which is a factor of 5.

I have to admit that a sizable portion of this speed gain is realized because we're only resizing and applying TS filter once (in the save-to-avi step) instead of on every pass. A fairer test would be to encode both ways with no resize or TS, but that's not what I do in real life, so I'm not going to.

And on the down side - processor usage wasn't 100%, so the pic video mjpeg codec is not SMP enabled. We'd realize even more speed if we could find an efficient codec that was SMP aware.

The moral of the story:
- if you have gobs of hard drive space,
- if you do 4 or 5 pass encoding,
- *and* if you don't mind a slight drop in quality from the use of the lossy mjpeg codec,
- you can realize significant overall encoding speed gains by encoding to avi as an intermidiate step on an MP machine.

[Mozart]

Hi folks,

did anybody between you - dual processor owner - have already tested what happens if you use 2 encoding process, instead of only one(question)

what I mean: using 2 CCE with 2 different encodings at the same time reaches full (both) processor(question)

what happens with the total speed (speed of encoding A plus speed of encoding B, both done at the same time) (question)

[Kedirekin]

This was discussed quite some time ago in another forum (can't remember which one - but it was back in the days of ezboards). What we discovered
- with CCE and single-pass CBR, you can run two instance. Total processor utilization was 100%, and speed is what you'd expect - about 40-45% faster than a single instance alone.
- with CCE and multi-pass VBR, you can only run one instance. If you try two, you get an error message in both instances when it restarts after the vaf pass.

I can't remember what the error was, and there were only two of us trying to get it to work, but we tried a number of different things trying to get it to work (like assigning each instance to it's own processor) - with no success.

Like I said, there were only two of us testing. Fill free to try it yourself. I'd be very happy if someone finds a way to make it work.