dual cpu system for encodiong?

[atifsh]

i want to know any encoding program that will use the dual capability of my dual p3 1Ghz system. as for now i found better results in terms of quality and speed with my Athlon XP 1800.

programs i use for mpeg 1 / 2 encoding

1: Cyberlink powerdirector pro 2.55 (for Divx encoding too)
2: Ulead VideoStudio 7
3: Pinnacle Studio 8
4: Virtual Dub (Yes for Divx)

[khp]

I'am pretty sure that no program will use 2cpus for encoding (this is cirtainly true for divx, I'am only 99% sure about mpeg1/2).

What you might be able to do, is use 1 cpu for decoding the source and another for encoding.
I'am pretty sure this works in virtualdub, when running the source through avisynth.

But even then, a 2 * 1ghz P3 would at best, only be slightly better than the Athlon 1800. And I suspect the P3 might actually be slower, since the 2 cpu's have to share the single 133Mhz Ram bus.

[atifsh]

ok thnks but pls would u more specify, what u mean by using one cpu for decoding and one for encoding using virtualDub?

[shiny#3]

I do slightly disagree to your analysis,

KHP.

a twin cpu of 1ghz pentium can be significantly faster
than a 1800. It is mainly a matter of how good the used programs
are optimized for multiple cpu use.
but 2 cpu also have to chacheram. which yields in the fact that
there are more registers that can be adressed. since
a simple calculation like adding two numbers, does need
several cycles you will see that most oft the cycles
are spent on getting the values into the appropriate registers
before the requested calculation can be performed.
double chacheram, double registers and most
important double ALU and FPU units can do a lot
if the program is optimized

you might try to check how many microword oprations are needed,
of wich most are used for setting busses and loading
values, for a simple:

Mov ax,23 ;h
Mov bx,65 ;h
ADD ax,bx ;h

and you see what I mean.

To answer your question atifsh;

The new cinema craft encoder Version 2.68 supports
Dual cpu processing, but not a quadriga or so on.
This is an Mpeg 1/2 encoding tool tool.

I also think that you have a compiler that is optimized
for dual processors use assorted with some useful macros
to adapt a sourcecode for dual processor use.
why not downloading the Xvid source code from the
software section and adapt it and compile it for your needs??

good luck!

EDIT: http://www.cinemacraft.com/eng/product.html

[atifsh]

thanks shiny#3 now looking for the program u told me, hope those do some better.

about Xvid source code what language they r in and what kind of optimizations ur talkin bout?

[shiny#3]

The lanquage of the Xvid source code is C .
Some assembler routines are also implemented.

I thought someome running a dual processor system
surley has some programming skills.

what I was thinking of was that you might try to
compile the source code anew using a C-Compiler
and if neccesary a assembler compiler that is optimized
for a multi processor windows system after adapting
the source code with some precompiler macros,that you might have. those "precompiling" sets normally allow you to generate
a C- skeletal structure in which the sourcecode can be imported
after adapting it.

I have to admit that I unfortunatly never was never able to lay

my greedy hands on a multi processor system running windows as an OS

I only was able to gather experience on Unix/(linux) , Solaris Sun
systems.

I guess you are more skilled in the windows multi thread and multi processors "wolrd". especially in, if there are good GNU compilers
optimized for multi processor systems.

good luck!!!

since MR.Shrink is dealing with multithread matters at the moment
maybe he will be able to give you good advice in what compilers to choose.

You can also take a look on the Open Source project of
Genias in regensburg germany that is a 100% daughter of Sun!
They mainly deal with optimizing applications for multiprocessors platforms. Some of the mainconcepts that are presented there may also help you.

for now.....
here is the Xvid home page with a lot of how to do and
codes in different states and a forum as well.

http://www.xvid.org/index.php

[khp]

Originally posted by atifsh
ok thnks but pls would u more specify, what u mean by using one cpu for decoding and one for encoding using virtualDub?

Asuming that you are not encoding from an uncompressed source, each image has to be decompressed before it can be encoded. If you load an avi or mpeg-1 into virtualdub or most other encoding apps, the decoding will be preformed automatically by the encoding app (assuming that the needed codec's are present). If you let virtualdub handle the decoding, I believe it'll use the same process for decoding and encoding, and limit the conversion to only use 1 cpu.
On the other hand if you use avisynth for frameserving into virtualdub, you should be able to use both processors, although you usually won't get both processors working at 100%.

Originally posted by shiny#3
It is mainly a matter of how good the used programs
are optimized for multiple cpu use.

No, it's not simpley a matter of optimization. It's a matter of designing algorithms that can use multiple cpu's, and this is far from a trivial matter. Video encoding is extremely poorly suited for multi processing, because of the strong dependencies in the encoding algorithm. There is no good way to split the workload between processors (excepting maybe when using B-frames or interlaced encoding, yuck).

1. You can't split the movie in 2 or more segments, first of all because that kills the encoders ability to freely distiribute the bitrate, optimally along the entire movie, second, because each segment would have to start with a key frame, which might not be needed. There is an encoding app that does this, I can't remeber which, you should be able to find by searching the forum.
2. You can't have each processor doing every other frame, because the encoding of p frames depends on the encoding of the previous I or P frame. I suppose this approach might work if you were encoding with B frames enabled, but IMHO implementing this would be a lot more truble than it's worth. And I'am pretty sure than the divx and xvid developers have the same view.
3. You can't let each processor encode half of each frame, because motion vectors might cross from one half to the other. The exception here is, if you are encoding interlaced encoding, which essentially treats the picture as two independent sub fields, which might then be encoded seperatly.
4. Splitting the work at a lower level than this would cost too much terms of interprocess communication and syncronization.

Originally posted by shiny#3 but 2 cpu also have to chacheram. which yields in the fact that
there are more registers that can be adressed.

Oh god no, each cpu has it's own cache and registers. The first cpu have no way of addressing the cache and registers of the second cpu (even if it did it would be rather slow). As far as multi processing goes, cacheing is a curse not a blessing. Because the system has to worry about cache coherency between the two processors.

On a multi cpu system, every process has the exact same registers they would have had on a single cpu system. You will usually get fewer cache misses, because fewer processes are competing for space in each cache. But in video encoding the difference will most probably be next to null, because each frame will tend to trash the cache several times.

since
a simple calculation like adding two numbers, does need
several cycles you will see that most oft the cycles
are spent on getting the values into the appropriate registers
before the requested calculation can be performed.

Exactly my point. The athlon most likely has double the memory bandwith of the P3 system, and has exclusive use of the memory bus. While the P3 memory controller has to spend time on arbitration, and most likely uses registered ecc ram, which has a higher latency than standard ram. All in all this means that the P3 has much higher latency than the athlon. And high memory latencies absolutly kills the encoding speed.

Mov ax,23 ;h
Mov bx,65 ;h
ADD ax,bx ;h

lol, I'll admit I know next to nothing about assembler. But fortunatly that is completly besides the point in this case. On the other hand I do know quite a bit about multi processing, algorithms and video encoding. Which are all much more important issues in this case.

The new cinema craft encoder Version 2.68 supports
Dual cpu processing, but not a quadriga or so on.

Do you have any details on how this works ?.
I would tend to suspect that, it just use 1 cpu for source decoding and 1 cpu for encoding.
And perhaps it can use 2 cpu's for interlaced encoding.

I will of course also be quite interrested to hear, how well this preforms ?.

I also think that you have a compiler that is optimized
for dual processors use assorted with some useful macros
to adapt a sourcecode for dual processor use.
why not downloading the Xvid source code from the
software section and adapt it and compile it for your needs??

Modifying xvid to use multiple cpu's, is not really a compiler issue. But an algorithmic issue, and a rather complex one, I might add.

But by all means do check the xvid forums, I'am pretty sure these issues, have been discussed before, and as I recall, the xvid developers tend to share my point of view.