Disillusioned and Confused -- DivX vs. Xvid Encoding Speed

[Zach]

Re: Xvid 1.1.3 Released (http://forum.doom9.org/showthread.php?t=127472)
Re: Multithreaded XviD - official thread (http://forum.doom9.org/showthread.php?t=107783)

I've been user of DixX Pro for years, and have been particularly fond of it for the last six months since I built an Intel Core 2 Duo system since DivX supposedly has great "multi-core" support. (I admit it always gives me a warm fuzzy seeing both my cores maxed out in CPU monitor when I'm encoding. :p)


Long story short, I'm doing some system benchmarking (focus is on XP vs Vista32 actually, not encoders), but for the first time ever, I decide to encode my test video using Xvid 1.1.3 instead of DivX 6.7 just for fun, and to my great surprise, the speed difference was neglible. (11:40 vs. 11:49 min:sec)

Everything in the chain was the same; the only change was in VirtualDub where I changed the compression from DivX to Xvid. For Divx, I used the 720HD profile (with "Enhanced multithreading" checked), and for Xvid I just selected the "Highdef" profile and left everything else alone. Probably not a perfect match, but close enough for vague ballpark comparisons I would think.


So I'm confused. Does Xvid 1.1.3 (Koepi's build found here (http://www.free-codecs.com/Koepi_XviD_download.htm)) have the built-in MT/MP support, or is it just a uni-core version and DivX it just faking it (like maybe just running an empty loop on the second core :p)? Or is Xvid that much more efficient that it encodes twice as fast as DivX? ;)

[squid_80]

Xvid 1.1.3 has no multithreading.

[plugh]

virtualdub uses multiple threads; so even though the encoder is a single thread, your (for example) avisynth script is being processed in a seperate thread.

[Zach]

Xvid 1.1.3 has no multithreading.
Yeah, I didn't think so. :(

virtualdub uses multiple threads; so even though the encoder is a single thread, your (for example) avisynth script is being processed in a seperate thread.
Multi-threaded is not synonymous with multi-processing. But disregarding the semantics, are you saying VirtualDub (this all was executed on the latest 1.7.5 build) segments the video stream and then allocates segments to each processor (core)?

I thought, at most, VirtualDub would split the audio and video streams to separate processors, but not split up the stream itself.

Well, regardless, based on squid_80's clarification, I should get a SMP version of Xvid before I analyze this any further so that I am comparing apples to apples. :)

Thanks, guys!

[plugh]

No, I'm not saying that.

Encoding is only 'half' the job. You have to feed the encoder with frames of data. Where do those frames come from, and in particular how much processing is involved in preparing them? (rhetorical question - don't bother answering it)

It is entirely possible that an 'involved' input processing step could be the limiting factor on your throughput. Your clock time is determined by the slowest link in the processing chain.

If your input stream can only deliver X frames per second to the encoder, it being able to encode 2X frames per second won't speed things up.

You indicate you have a dual core system. If one assumes that you are using all the resources of one core to prepare the frames for encoding, then the number of threads being used by the encoder is irrelevant, right? You only have one core left.

Whether this is actually your case, I don't know. I was simply pointing out that vdub ITSELF already uses multiple threads (for the input-prep and encoding parts, for example), and that the reason your clock times came out the same MAY have nothing to do with *encoder* multi-threading (or lack thereof).