Divx transcoding on dual xeon - suggestions?

[AmazingRando]

I just got my new dual xeon system up and running. It's got 2 x 2.8GHz Xeons (800MHz FSB, SSE3, etc etc.), 1.5GB of DDR2 ram, and a bunch of other goodies running WinXP Pro SP1a.

I ran my first encodes on it yesterday and was disappointed to see how few of the transcoding frontends and codecs support SMP, or even hyperthreading for that matter. Feels like I've gone back in time five years. :angry:

With hyperthreading enabled, and using Dr. Divx 1.05 and Divx 5.2, I did a transcode with "high" settings of the movie Red Planet with the AC-3 track previously demuxed. First pass never used more than 50% CPU utilization and second pass never used more than 25% CPU utilization with only one of the virtual CPUs being used (at 100%). Total encode time was 1 hour 42 mins.

I also noticed similar results with Gknot .32 and Xvid 1.0.1. With only one CPU installed and HT on, I did the same encode in 2:00, and with two procs in 2:22 (due to second pass not being HT aware?). By comparison, on a single 3.0 GHz P4 (northwood), the transcode ran in 1:58.

Does anyone have any suggestions on what (if anything) out there I can use for a frontend/codec combo that will make use of SMP, HT, and SSE3?

Thanks

AR

[TCM]

if you got this system for the sole purpose of encoding, then you could run multiple encodes at once? this way, a single encode won't be faster but you can do more in the same time.

i don't know if the app and the codec you use allow multiple instances, just a guess.

[AmazingRando]

Thanks for the suggestion. I did try that approach last night. I can't get Gknot to run multiple instances (anyone know how??), but I was able to concurrently run Gknot with an XviD encode while I ran Dr. Divx doing a Divx encode. The Gknot encode was really smooth - it took the same amount of time as when I benchmarked when there was only a single processor in the machine, despite Dr. Divx also running (presumably on the other physical or virtual processors). Dr. Divx is all messed up though. It appears to have problems with hyperthreading (someone mentioned it might be a bug in v1.05), so it would only run on one virtual processor, meaning 25% utilization or about 50% of one processor, so it was quite slow. I also ran the two encodes off two different sata drives to cut down on I/O contention.

One way to look at this is that at least I can be encoding and have a very responsive system running at the same time. I was able to play some games while I encoded with no affect on the Gknot encode time. Though, when I played a more processor-demanding game like Battlefield Vietnam, with Dr. Divx and Gknot both encoding, the game was noticably slower - though not unplayable.

Until we get SMP and HT aware frontends and codecs, this might be my best use of the system. And I suppose this will have to be dealt with by the time dual core processors arrive next year. There will be a lot of pissed off people with dual core systems if they have problems like this.

[b0b0b0b]

I advise vmware or virtualpc

[BBugsBunny]

The new DivX 5.2 codec has got a SMP/HT optimization for the first time - before the release of 5.2 there was some talk about it on the general DivX forum of divx.com.
Reading this prerelease talk on the forum I expected a bit more of the SMP optimization of what it now actually got...
The optimization that was done, is that you can turn on the preview window of the codec without any performance penalties, you get if you have an uniprocessor system.

But I think it's planed to integrate more SMP/HT in future versions of the codec.

A codec that is quite well SMP optimized is the Mainconcept DV codec.
Cool Edit / Adobe Audition uses SMP in the denoiser filter.

If you use the msharpen filter of VirtualDub you could try my SMP optimized version...
http://members.chello.at/nagiller/vdub/index.html
I wonder if it gives the same results on a new Xeon system as it does on my old system.

With DivX I think we have to wait for a future version...

Perhaps you could also try to encode 2 videos at the same time with VirtualDub. Perhaps it does not mess up that much.

At the moment I still have my dual PIII 900 on an old BX board (Slot 1), but I'm planning to upgrade to a new Xeon Nocona system soon.

I think SMP support will be increasing with the upcoming dual core CPUs.

[starship]

I have also a dual Xeon and can tell you are lucky because virtualdub can be SMP awaring with the help of avisynth. I have HT disabled so windows only see 2 physical Xeons.

If you load your source through avisynth to virtualdub, and make all your filtering and resizing in avisynth, you get 100% cpu usage, above all with high resolutions . This way frame input is made with a CPU an encoding with the other.