A real CCE SpeedTest

[DDogg]

The point of this exercise is to create meaningful comparisons of CCE encoding speeds. Many of us are tired of the nonsense posts and waste of bandwidth. Although this test is primitive and will reflect a speed much slower than you will actually get using proper source, it should allow an exact comparison of speed on various platforms. In other words, two machines of the exact same configuration should return identical results.

This assumes I have thought it out correctly and did not screw up :) If everybody uses the same source and the same ecl to ensure the same settings, it seems to me this ought to work. Feedback welcome if I missed something.

Instructions (follow exactly):

1> Create directory on your HD as "CCESpeedTest01"
2> Copy and paste AVS file below into notepad. Save into the above directory as "CCESpeedTest01.avs"
3> Copy and paste the two ECL files into notepad one at a time. Save each as "CCESpeedTest01_CCE2.5.ecl" and "CCESpeedTest01_CCE267.ecl"
4> Edit the ecl files using the replace function of notepad. Search and replace "G:\" to the HD drive letter where you created the dir in step 1 above.
5> Run CCE and load the appropriate ECL file. Make NO changes. Press encode and note the speed after exactly 3 minutes of encoding.
6> Report that speed along with the information on your machine.

#start of CCESpeedTest01.avs
ColorBars (720,480)
ShowSMPTE(24)
converttoyuy2()
#end
CCE2.5x ECL
; Cinema Craft Encoder SP -- Encoder Control List

[item]
title=CCESpeedTest01.avs
vid_out=1
vaf_out=0
aud_out=0
vid_file0=G:\CCESpeedTest01\CCESpeedTest01_CCE2.5.mpv
vid_file1=
vaf_file=
aud_file=
file_focused=0
encode_mode=0
packet_size=4096
timecode=0x1000000
width=720
height=480
vmode=0
frame_rate_idx=4
cbr_brate=6000
opv_q_factor=32
opv_brate_min=300
opv_brate_max=8000
vbr_brate_avg=2257
vbr_brate_min=1194
vbr_brate_max=2565
vbr_bias=30
vbr_pass=3
quality_prec=17
use_filter=0
filter_val=6
seq_endcode=1
dvd=0
half_width=0
half_height=0
fast_mode=0
progressive=1
alternate_scan=0
non_linear=1
top_first=0
lum_level=1
intra_dc_prec=-1
aspect_ratio=2
gop_m=3
gop_nm=5
gop_hdr=15
seq_hdr=1
all_closed_gop=0
fix_gop_length=0
mpeg1=0
mpeg1_cps=0
samples_per_sec=48000
stereo=2
brate_idx=7
crc=1

[file]
name=G:\CCESpeedTest01\CCESpeedTest01.avs
type=0
frame_first=0
frame_last=107892
encode_first=0
encode_last=107892
CCE 2.67 ECL
; CCE SP Trial Version -- Encoder Control List

[item]
title=CCESpeedTest01.avs
vid_out=1
vaf_out=0
aud_out=0
aud_mode=0
vid_file0=G:\CCESpeedTest01\CCESpeedTest01_CCE267.mpv
vid_file1=
vaf_file=
aud_file=
file_focused=0
video_type=2
width=720
height=480
timecode=0x1000000
tc_ref_frm=0
drop_frame=0
cbr_brate=6000
opv_q_factor=32
opv_brate_min=300
opv_brate_max=8000
vbr_brate_avg=2230
vbr_brate_min=300
vbr_brate_max=2530
vbr_bias=30
vbr_pass=3
create_new_vaf=0
pulldown_detect=0
letter_box=0
panscan=0
aspect_ratio=2
credits_tweak=0
credits_start=0x00000
credits_brate=1000
h_filter=0
h_filter_idx=8
use_filter=0
filter_val=4
dither=0
dither_max=8
quality_prec=25
intra_dc_prec=2
alternate_scan=0
non_linear=1
progressive=1
gop_m=3
gop_nm=5
gop_hdr=15
seq_hdr=1
seq_endcode=1
dvd=0
all_closed_gop=0
fix_gop_length=0
fix_vbv_delay=0
offset_line=0
half_width=0
half_height=0
uscc=0
lum_level=1
packet_size=2048
frame_rate_idx=4
qmat_idx=0
mpeg1=0
mpeg1_cps=1
brate_idx=7
stereo=2
samples_per_sec=48000
crc=1

[file]
name=G:\CCESpeedTest01\CCESpeedTest01.avs
type=0
frame_first=0
frame_last=107892
encode_first=0
encode_last=107892

[DDogg]

My tests:

CCE 2.5x 1.50
CCE 2.67 1.41

[Edited - Better speed after reboot]

Biostar M7NCDP | XP1700 (AXDA1700DUT3C - JIUHB 0312VPMW) @2.1 Ghz (11*192) VCore 1.70 v - SiSoft PR 3064 (Est.)| GFrce 2 MX400 | 4 Maxtor 40g| Zlmn Flower w/ 120 fan @ 2000 rpm| Enermax 330 watt r82 tweak | (2) 256 meg PC3500 HYP_X (7-2-2-2 VDim 2.8 v| Enermax CS 307 Case

[KeyserSoze]

I'm getting the following error:

D:\CCESpeedTest01\CCESpeedTest01_CCE2.5.ecl is not a ECL for Cinema Craft Encoder SP."

I'm getting the same with CCESpeedTest01_CCE267.ecl file!!

[DDogg]

Sure thought they should load OK, crap. Well just set either of them up for One Pass VBR Q32 Min 300 Max 8000 and no VAF creation. Set Zigzag and Progressive on. No internal filters engaged of any kind. Make sure DVD compliant is not on. That should work, but without loading the ECL's we can't consider it apples to apples.

What exact version/s of CCE are you trying to use?

Has anybody else got them to work ok?

[coona]

Hi DDogg,

I really appreciate your work ;). Solution (as usual :D) is very simple - ECL file has to start with this line:

; Cinema Craft Encoder SP -- Encoder Control List

My result is:

CCE 2.5x 0.391

I´ll post my configuration later because I´m at work and I have to check what hardware I really use here, hehe.

***EDITED

Asus CUSL2-M, PIII 866, 512 MB SDRAM, Ati Rage XL AGP,1x IBM 60 GB, 1x IBM 75 GB, Toshiba SD-M1502

***EDITED

[DDogg]

jarvis1781, did you use the ECL above? That speed surprised me.

[KeyserSoze]

2.67.00.10---->1.42

2.50.01.00---->1.514


XP2400+ at 2000Mhz(12x166,harmless o/c :D,Vcore 1.65) Dual Channel Winbond CH-5 (5-2-2-2,VDim 2.6v)

CCE 2.67 is ofcourse optimised for P4 CPUs, and CCE 2.5 for Athlons .

(no background apps this time)

[DDogg]

KeyserSoze, were you able/how did you get the ecls to load? Note your speed and mine are nearly exact, so we can see the benchmark works and returns similar results on like machines.

[DDogg]

forgot to note that my CPU is OC'd to 3.5 yeah, that would make a bit of difference :rolleyes: :)

[KeyserSoze]

Originally posted by DDogg
KeyserSoze, were you able/how did you get the ecls to load? Note your speed and mine are nearly exact, so we can see the benchmark works and returns similar results on like machines.

Your old version of scripts had that extra line on the top.....
Those didn't work in CCE2.5 but worked in 2.67(EclCCE).
Now everything is ok on both scripts.
I just followed coona's advice:D

[DDogg]

OK, thanks. As you noticed I edited out those extra lines in the ECLs above. Now everybody should be able to just copy and paste them into notepad and save them. The only edit needed is to change "g:\" to the drive they use.

The benchmark seems to work well now. Let's see some more testing results, people! :)

[chipvideo]

Doesn't do smp very well with this test. I get 58% on my processors. While I do the dvd2dvd process with the highest bicubic resize method I get 72% on average usage.

[DDogg]

chipvideo, the data we are interested in was what speed you obtained. Once we get enough of that data we can then develop a factor to convert the result to one that more closely indicates real world encoding. Keep in mind that this method removes avisynth and mpeg2decX from the equation, as well as resolution/aspect ratio.

In your case, this shows CCEs processor usage alone. It may be that jarvis1781's single processor machine will actually encode faster than yours. If so, that is useful data to know (although not something you may particularly appreciate :) )

[chipvideo]

Well I doubt that he can encode 70% faster than my machine. He would have to encode a dvd with bicubic resize at around RT5.3 on Titanic.

I know that your machine isnt the same speed as mine for encoding. I have my procs OC'd to 2400mhz each. LIke I said this test shows CCE using only 58% processor while using the real method shows a CCE using 72%.

That is all I am saying. Based on this test one would assume that a dual processor system is a waste and doesnt perform any better than a single one when in fact a dual system enocdes much faster.

[DDogg]

That's interesting, but as before we don't have your speed on this test so as to put it into perspective.when in fact a dual system encodes much faster. I don't have experience with dual processor systems. However, I do wonder if what you said above is always so. My understanding was that a single instance of CCE would not use the capacity of both processors. Is that correct? If so, could not a single very fast processor like jarvis1781's potentially out perform your slower duals?

[chipvideo]

My speed was 1.51 using your test. If cce didnt utilize the both processors then I would get a max of 50% on cce. I get 58% with cce using your test and 72% when using the dvd2dvd method.

His single processor is not beating my dual encodes by 70% encoding a dvd material. You must be crazy to think that your system is as fast as mine as well. But it isn't. I think a better way to figure this out would be for a few of us to use the dvd2dvd method and use the same settings. Bicubic resize and use ntsc source. Maybe we could make a list of some movies that people have and then see if we can get some results.

I have Titanic, Saving Private Ryan and that other hanks movie on the Island. Those are good movies as they are long ones and would show that true power of the system. I mean I get 3.3RT with Titanic. I highly doubt your processor running at much lower than mine is goign to do as well. I know this is a early stage test and I am glad your willing to take the time, but we need to get more realife results.

[Kedirekin]

I feel compelled to comment, as I've spent a fair amount of time thinking about multiprocessor (MP) systems.

This test isn't just testing CCE encoding speed, it's also testing the speed of AviSynth.

On a single processor system, the script might be using something like 86% of processor cycles, leaving the other 14% for CCE.

On a dual processor system, all of one processor (100%) can be dedicated to the script. All of the left over processor could be dedicated to CCE, but the script is only capable of delivering data so fast, so CCE only ends up using 16%.

The apparent result is a 15% increase in CCE encoding speed, but the test is somewhat biased by a slow script. With a more efficient script, the ratios are completely different, and tend more and more in MP's favor.

Just a point of clarification, CCE is MP enabled. The reason you don't see 100% processor usage is that AviSynth is not MP enabled.

A more fair test of CCE sans frame server might be to use the script to create a Huffy (or raw) avi file, then encode from that. That would really show off the advantages of MP systems. Unfortunately that is misrepresentative of what you're really trying to test (frame server+encoder performance) in the other direction.

BTW: why is that script so slow? I wouldn't think ColorBars or ShowSMPTE would slow the script down so much.

[DDogg]

You must be crazy to think that your system is as fast as mine as well. My goodness, chipvideo :) I would never think that. What I am attempting here is a reliable method of comparing CPU platform to CPU platform that removes from the equation issues like NTSC/PAL, aspect ratio/total encoded pixels, variant of mpeg2dec and IDCT, color conversion, etc., etc., etc., ad nauseum.

This is only the first stage of that process. Typically I normally have a bit of method in my madness. Over the years I've found that the only way to accomplish something on this board is to cause a challenge scenario. It is just the way people are. Its neither good nor bad, it just is. :) So thanks for the input.

Perhaps you and/or Kedirekin can make a major contribution so we can actually have an intelligent method of reportage instead of the silliness of "WoW, bubba, I got 9 x realtime!!!! er, 'course that was 160x120 resolution, but who cares cause 9x makes me feel like I have a big Johnson:rolleyes: I suspect this irritates you, and especially Kedirekin, who knows more about this stuff than most will ever learn.

I think you are completely correct about this particular test as it not only concerns multi processors, but the general full process itself. I would wholeheartedly concur with a more proper method as you suggested that uses real source. When I have suggested something similar (repeatedly over the years) the response has been underwhelming. As said, this is the first stage, and it does supply a legitimate method of comparing [single :)] CPU systems. In other words, a machine that returns 1.25 will be proportionately slower than a machine that returns 1.55. What that proportion is is still up in the air at the moment. For that reason alone I think this method is useful and serves a strong purpose.

Now we just need to work together and come up with the next iterations. However, that method must be transparent to NTSC and Pal, else it is a waste of time. Nobody wants a dual benchmark, IMO. This gets us into a easily downloadable common source and the required bandwidth which has always been one of the hangups.

So, you want to help or just bitch at me? :D (I really am grinning)

So nowBTW: why is that script so slow? That always puzzled me too. Maybe because it is so static. Once...it was either Dividee or Steady wrote this brilliant avs script for me that better mimicked a real video source. I don't know what came of it. I think that was on the old EZboard which kinda tells you how long I have wanted a decent benchmark.

[Kedirekin]

Actually I think your proposed test is perfectly valid for SP systems. I wasn't trying to denigrate it. It may not represent real-world performance, but as an apples-to-apples test is should be accurate. As you said, the relative performance differences should track into real-world circumstances.

It's probably valid for MP systems as well, but only for comparing to other MP systems.

Unfortunately things break down when trying to compare SP and MP systems, and it isn't really the fault of the test; the breakdown is present in real-world situations as well. For example, your MP setup could encode one project 40% faster than a comparable SP system, and the next project might only be 10% faster.

Taking that into account, I don't think it is possible to create a test that will ever allow apples-to-apples comparisons between SP and MP systems. It's kind-of sad really - if everything were MP enabled, the MP system would always be 85-95% faster than the comparable SP system.

BTW: chipvideo, if you want to see how much added oomph your MP system gives you, try setting your CCE processor affinity to only use one processor.

[DDogg]

When we get more data, that is, when we can get a few more people to get motivated, run the test and report the results, we can then pick a few folks to also run an encode on a common DVD source. [Hey, it only takes five minutes!]

That data should establish the proportion of this artificial benchmark to a real world encoding job. Ultimately I think (hope) we can end up with a multiplier to apply against the benchmark number that will yield a close approximation to real world speed using the common encoding method of mpeg2dec3/avisynth. Hopefully that would also use, as part of the factor, the amount of pixels to be encoded so we can take into account aspect ratio/res. I'm still fuzzy on that. Most folks know I am a math dropout.

There is something else tickling the back of my brain but I can't get a handle on it yet :confused: I think it is something to do with pixels and some way of a PAL or NTSC person computing equivalence. May be clueless.

[Kedirekin]

Interesting idea. In terms of analog bandwidth, I've heard that PAL and NTSC are nearly identical. The increased resolution of PAL is offset by the decreased field rate.

The math supports this conclusion:
720 x 480 x 60 = 20,736,000
720 x 576 x 50 = 20,736,000

This equivalence would translate into DVD encoding, but unfortunately (or fortunately) most NTSC DVDs are encoded at 24 fps which throws the equivalence out of balance. I'm not sure if the situation is as simple as this, but...

(720 x 480 x 24)/(720 x 576 x 25) = 0.8

I think that means NTSC encode speeds will be 25% faster than PAL speeds, all other things being equal (which of course they can't be - different resolutions implies different sources, if nothing else).

[Kedirekin]

PS. Sorry I can't run the test myself. I don't have all the latest software.


I just ran the test against what I have.
CCE 2.5: 2.898

I have a pretty generic 1½ year old Micron Millenia 2.26 GHz P4 with a propietary motherboard and everything (sound, graphics, enthernet) onboard. This speed looks suspicious to me, but I did check the script in VirtualDub and it is working fine. I am using an older version of AviSynth (2.08); perhaps the script isn't as slow in that version.



Sorry for the misinformation. I let the encode run to completion and found my error (had the avs file in the wrong directory - surprised CCE didn't throw an error). I re-ran the test and got much more pathetic results.
CCE 2.5: 0.82

As I mentioned, my PC is very generic. Even though it's 2.26 GHz, it's no speed demon.

This does bring up a point though; if people are reporting suspiciously high speeds, it might just mean they messed something up like I did.

[sh03z]

@ chipvideo: have you tried two instances of CCE???

[DDogg]

Does anybody know an online source of 720x480 4:3 video of at least 5-6 minutes length that is, and would probably remain, available?

[sh03z]

What exactly are you asking DDog???

LOL

[DDogg]

:stupid: Right. I should have mentioned the obvious, as well as the sample needs to be AVI if possible, although a VOB would work out nicely also. We can then use it as part of a readily available and replicatable benchmark.

[sh03z]

OK. maybe a small vob with a lot of action, or two merged vobs with action/still...

problem is finding the place to put it on.

[nuno]

Hi!
I made a test with cee 2.5 and everything went ok, but with 2.67.00.13, i get the error "Frame size is 1024x32 is not supported. Supported frame size is up to 720x576".
Speed in cee 2.5: 4.29. Work concluded in 13 min and 40 seconds

P4 2.60c GHZ, 800-MHZ System Bus, 512-KB L2 Advance Transfer Cache, Supporting Hyper-Threading
Board: Asus P4C800 Deluxe, Intel 875 Chipset, Fsb 800 MHZ, Dual DDR 400
Memory: 1 GB 400 MHZ

[DDogg]

nuno, I think if you look at the mpv created you will see no video, only a red on black error message. Read what Kedirekin said above. Try playing the avs script in media player. I think you must have an error, even though your machine looks very fast. Let us know.

[nuno]

Hi!
You're absolutly right.
After making a manual setting, i've obteined 1.143 in cee 2.5.
Ah, and avithyndt 2.5

[DDogg]

1.143 ... Was that a typo? That now sounds too slow ... Anybody else have a machine similar to nuno's? We need a comparison. His machine should be *way* faster than mine.

[atimoc]

Hi there!

I ain't got cce267 so here's cce250sp only:

speed: 0.383
machine: p3 800/133 @ 840/140
asus p3b
320 mb ram
avisynth 2.53
win2ksp4

... have a nice day ...

[auenf]

XP1800+
Asus nforce2
DTLA-307060 (75GXP)
rest doesnt really matter...

CCE 2.66: 1.02 (with a little bit of mozilla surfing in the forground ;)

Enf...

[KeyserSoze]

Originally posted by DDogg
1.143 ... Was that a typo? That now sounds too slow ... Anybody else have a machine similar to nuno's? We need a comparison. His machine should be *way* faster than mine.


P4 2.6Ghz------------Whetstone-FPU = 1971 /withSSE2=3603
Athlon 1.2Ghz--------Whetstone-FPU = 1890
My XP2400+@2.0Ghz-Whetstone-FPU = 3160

Without SSE2 support from a program, P4's raw FPU calculations are a joke;)
CCE 2.50 doesn't use SSE2(2.66+uses)..............

After all,what's the point of using anything else than CCE v2.50 (the best IQ & the fastest on AMD) :D IMHO

[Rock Hardy]

No 2.67 available to me...

2.50: 1.678

Athlon XP 2500@2200Mhz (11*200) (XP3200); 2*512MB 2-2-2-6 Hyper-X Ram; ABIT NF7-S

rh

p.s.:

did some more testing, but no big changes there:

2.50: 1.697 (10.5*210 (2205Mhz); 2-2-2-6 timings)
2.50: 1.677 (11*200 (2200Mhz); 2-2-2-5 timings))


Edit: values changed after rebooting, added fsb test

[coona]

I did some testing here at work :)

I have only CCE 2.50 avaible:

1.318

Athlon 2500+ (Barton) 1833 Mhz; Asus A7V8X-X nForce 2;Kingston KVR400X64C25 2 x 256 MB Single Channel;Seagate Barracuda 7200, 120 GB UltraATA 100

0.771

P4 2MHz; Asus P4B533VM I845G; 2 x 512 MB, IBM 7200, 40 GB, UltraATA 100

0.391

PIII 866, Asus CUSL2-M, 512 MB SDRAM,1x IBM 60 GB, 1x IBM 75 GB,

[DDogg]

Hmmm, this is getting interesting if I am reading the tests right. (Eventually we can get this data in a spreadsheet and start making better sense of it --- somebody? :) )

Rock Hardy's test results, and I assume he followed the instructions exactly and the results are accurate, would suggest the Barton's extra cache makes a fair amount of difference to CCE. I say that because I can't get that speed with the same timings and fsb with my tbred B xp1700 (yes, I can run 11x200). Just some conjecture on my part as we do not have enough data yet. I hope we can continue to get more results in. When compiled they may show us some trends we were missing.

At the moment, jarvis1781 results are the fastest. However, I think them suspect. Not doubting jarvis1781's integrity in any way, I am just not yet clear on whether the test was followed exactly. We need somebody else with a similar hopped up machine to verify those results.

To save folks hunting around for jarvis1781's results, "... CCE 2.67 on a 2.4C with PC3500 dual channel DDR with SATA Raptor is 2.58 - ... note that my CPU is OC'd to 3.5 and it has HT enabled"



Biostar M7NCDP | XP1700 (AXDA1700DUT3C - JIUHB 0312VPMW) @2.1 Ghz (11*192) VCore 1.725 v - SiSoft PR 3064 (Est.)| GFrce 2 MX400 | 4 Maxtor 40g| Zlmn Flower w/ 120 fan @ 2000 rpm| Enermax 330 watt r82 tweak | (2) 256 meg PC3500 HYP_X (7-2-2-2 VDim 2.8 v| Enermax CS 307 Case

[Rock Hardy]

Rock Hardy's test results, and I assume he followed the instructions exactly and the results are accurate, would suggest...

...well i hope so - checked them again and i think everything is fine.

Ran one more test: this time at stock speed of the xp 2500+ and got 1.389.
Compared to coona´s results this seems quite fast to me. Even tough I dont know if this is caused by 1GB ram, by dual channel or something else..?

However i was wondering if the difference in comparsion to DDog´s setup might also be influenced by the test itself.
I am no IT pro so this might as well be bs: but couldn´t the nature of the .avs (as the .avs mostly consists of non changing colour-bars) favour the barton´s cache?

[Kedirekin]

If there is any question about the encoding speed, you might want to check your results. I assume anyone using CCE will have a copy of DVD2AVI installed on their system.

Start the encode and let it process to completion. Open up DVD2AVI and drag the finished mpv file onto it. If you see color bars and time codes, you know CCE was indeed encoding correctly. If not, the encode would be one of: 1) an red error message on a black background, 2) blackness, or 3) noise (that's what I got).

If you don't want to encode an hours worth of color bars, add the following below the ColorBars command in your script:

Trim(0,3600)

This will trim ColorBars down to approximately 2 minutes of footage. Note that 2 minutes of ColorBars will not be enough to keep CCE going for the 3 minutes required for the speed test, but it's okay for checking that CCE is encoding what it's suppose to.

[KeyserSoze]

New testing(o/c this time):


2.50: 1.581 (Xp2400+ 11*200 (2200Mhz); 2-2-3-5 timings))

It seems that the extra 256kb of a Barton L2 gives some boost!

[nuno]

CCe 2.67.00.13 with ecl --- 1.18

I'm trying to make a different combination on the Hds configuration, because they are connected to work in raid, but only one of them is assigned.

P4 2.60c GHZ, 800-MHZ System Bus, 512-KB L2 Advance Transfer Cache, Supporting Hyper-Threading
Board: Asus P4C800 Deluxe, Intel 875 Chipset, Fsb 800 MHZ, Dual DDR 400
Memory: 1 GB 400 MHZ
Hds: 40gb and 80gb ata 100 ide
Geforce 2 MX400

[auenf]

Originally posted by coona
P4 2MHz

i think your FSB is broken there mate ;)

Enf...

[DDogg]

dragongodz was kind enough to point out this link (ftp://ftp.tek.com/tv/test/streams/Element/index.html) to some online test mpg files. I think the "Element/MPEG-Video/525" files would be perfect for a new test, however I will not have any time till the first of the year to even think about it much. Perhaps somebody else could figure something out? I think the 8 meg stream "525" files like this one (ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/525/mobl_080.m2v) and this one (ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/525/flwr_080.m2v) would be perfect.

Note they are completely legal and legitimate test files (see bottom of page)
Portions Copyright (1996) David Sarnoff Research Center, Inc. All Rights Reserved
TEKTRONIX grants to the web site viewer a royalty free, limited, non-exclusive license, without right to sublicense others, to download the bitstreams present on the TEKTRONIX web site and to use them for research and demonstration purposes only. No warranty is given or should be implied that the bitstreams are free from defects, are fit for any purpose, or are free from infringement of any intellectual property right of a third party.

[syzygytec]

I read through the topic and ran the test exactly as prescribed.

My speed after 3 minutes:

CCE 2.50.00.01SP = 0.570

EclCCE > CCE 2.67.00.23SP = 0.53

That's under normal conditions things running that are usually off when I encode.

Pentium III Taulatin 1.2GHZ on Intel Mobo D815 chipset

[MaXiMuS]

CCE 2.5
0.914
:confused:

http://www.lfchosting.com/divx/_cpu_speed3_CCE.png
http://www.lfchosting.com/divx/_cpu_speed2.png
http://www.lfchosting.com/divx/_cpu_speed.png

[coona]

To MaXiMuS

Posted by KeyserSoze
Without SSE2 support from a program, P4's raw FPU calculations are a joke...
CCE 2.50 doesn't use SSE2(2.66+uses)..............

I hope I will be able to make some tests with Ddogg´s testing mpegs today ;) .

[coona]

I did some quick tests with Ddogg´s files and CCE 2.5.0

I did following:

1) d2v project
2) avisynth script
import("C:\Program Files\DoItFast4U\new.avs\addaudio.avs")
LoadPlugin("C:\Program Files\DoItFast4U\new.avs\mpeg2dec3.dll")
Mpeg2Source("My path to d2v project\my_project.d2v")
AddAudio()
ConvertToYUY2()
3) run encode with 9 passes with:
"add end sequence code" and "zigzag scaning order" checked,
average bitrate 2500,
minimum bitrate 0,
maximum bitrate 9000,
bias 30
all other setting were the same as described in this guide (http://www.doom9.org/mpg/cce-roba.htm).
Here are results:

flwr_080.m2v - 14694 kB before encoding
flwr_080.m2v.mpv - 3648 kB after encoding

average encoding speed ±1.13

mobl_080.m2v - 14655 kB before encoding
mobl_080.m2v.mpv - 4560 kB after encoding

average encoding speed ±1.145

Tested on P4 2GHz (I repaired my FSB, Auenf ;)), 1GB RAM

[windtrader]

My tests went smoothly; did it twice after a clean reboot.

Speed 1.14

CCE 267 (via EcICCE)

Hardware: (as reported by SiSoftware)

CPU: AMD XP2400+ @1.99Ghz (L2 cache 256kb ECC Synch write back)
MOBO: ECS K7S5A
CHIP: SIS735
MEMORY: 512MB DDR-SDRAM (make unknown, PC2100)
FSB: 2x133Mhz (266Mhz data rate)
VIDEO: Matrox G450 Dual Head
HD: Seagate Barracuda 80gb
OS: WIN XP SP1

Dhrystone ALU 7331 MIPS
Whetstone FPU 2994 MFLOPS

[U149113]

Have 4 PC's that I ran the test on. Three are SMP Only have 2.67.x.x to test. All running 2000 SP 4.

PIII Dual 550 IBM Intellistation M Pro - .37
PIII Dual 733 IBM Intellistation M Pro - .39
PIII Dual 933 Tyan Tiger MB - .41
PIII 933 Tyan Tiger MB - .39

[jsoto]

My results, very similar to MaXiMuS (similar machine, similar results)

CCE 2.50.01.00 0.922
CCE 2.66.01.07 0.94
CCE 2.67.00.23 0.94

PC: P4@2,4 GHz (133 Ext clock) 512 MB RAM (333 DDR); MotherBoard: GA-8ST800
But I usually get a little bit more (1.1 or 1.2) during my encodes (PAL-DVDs)

jsoto