CCE 3-pass VBR Encodng on P4/2.8GHz. Why so SLOW???

[SaSi]

I am trying to do a 3 pass VBR Encodng with CCE. I may be wrong somewhere, but it appears to be a damn slow process. (I do it by the book - manual).

The manual states that you must FIRST encode the movie in CBR with a bitrate equal to the one you will set as average in VBR, so that the vaf file is created. So I did. Selected 4,800 (to fit a 2h long movie in 4.2Gb). It took almost 2 hours (on a P4/2.8GHz).

I now started the VBR encoding (3-pass at 4,800 avg, 8,000max, 500min). It says it will take another 6 hours.

Tmpgenc is supposed to be slow (it is). How about this then? Is this performance normal? CCE is currently transcoding at 0.850 speed (and apart from the browser, is the only application running).

The source AVI is encoded in hufyuv and has no audio.

Can anybody with CCE experience tell me where I'm wrong ?

[Vejita-sama]

I have CCE 2.5sp and an AMD 2200+, I normally get speeds in CCE from 1.45~2.1 or 0.7x to 0.5x the source runtime (per pass).

So to encode a 2hr movie with 3pass VBR takes me ~5.6hrs.

[SaSi]

So I suppose I'm not doing something badly wrong. I still have to reach an x1.5 speed to say it's going fast, but overall, performance is not that much better compared to Tmpgenc.

I can do a complete encoding (either 2 pass VBR or CQ=90) with Tmpgenc in 7-8 hours with very good quality. And that is if I select Highest Quality in Motion Search. The other options provide encoding times in the range of 3-4 hours. So, perhaps, Tmpgenc is not slow after all. Think I am going for a benchmark between MainConcept, CCE and Tmpgenc.

[Vejita-sama]

Well I haven't run TMPGenc in a while but for me it's much slower than CCE. IIRC my TMPGenc times were like 3.5x source runtime. About 4x slower than CCE.

Remember it's about the number of passes. For me TMPGenc CBR was about as fast as CCE 3pass VBR (which is actually 4 passes). I haven't used mainconcept or ulead.

[disturbed1]

The source AVI is encoded in hufyuv and has no audio.

I have horrible encoding speeds with this codec too. Try PicVideo's MJPEG, it's SSE2 enabled and is much faster to decode than huffy.

Huffy looks good, it's (almost)lossless, but takes too much time to decode.

Here's benchmarks of huffyuv http://math.berkeley.edu/~benrg/huffyuv.html#Benchmarks

notice the decoding speeds
PICVideo MJPEG 44.1 fps
Huffyuv / Predict median 13.3 fps

CCE has to decode first before it can encode. You could try to cap in native YUY2 if your card supports it.

[SaSi]

Well, I would have never guessed decoding can slow things that much. I read the benchmarks and it appears that I could easily double the speed with PicVideo. I am downloading it now to try it.

Actually, I tried (once) to encode an uncompressed (segment) of a video. It was 120Gb long and encoding speed was very promising (in the range of x2.1 to x2.3). Of course, no decoding penalty there. But I can't spare that many hundreds of Gbs.

[pijetro]

Correct me if I'm wrong, but Tmpgenc won't go beyond two passes with encoding. You're actually doing an extra pass, and you'll still be able to beat Tmpgenc's speed. Are you frameserving, and if so, with what?? The best I can do with a .VDR frameserve is .260 speed....

[disturbed1]

Correct me if I'm wrong,

Are you frameserving, and if so, with what?? The best I can do with a .VDR frameserve is .260 speed....

He's using huffyuv. Even if use something like Virtual Dub, or Avisynth, that app still has to decode huffyuv to it's native format first.

PicVideo has a YUY2 subset format, so its decoding is much faster in CCE. PicVideo would be slow as snot in TMPG since TMPG must decode to RGB first.

I read the benchmarks and it appears that I could easily double the speed with PicVideo.

Let us know how it turns out. You should at least double your speed. Even so a 2.8 @ anything less than 2.0 speed seems pretty slow coming from PicVideo, I'm guessing you'll see something like 2.5-2.8 for full D1 encoding.

[SaSi]

News from experiments.

First of all, let me state the setup:
I use VirtualDUB to convert an 720x576 mpeg video stream (m2v) into an AVI, while at the same time perform filtering (de-interlace, cropping, a bit of sharpening or smoothering - depends on the capture material). Even if I don't do any filtering, VirtualDUB is used to extract the useful material from un-edited capture material.

Then I use CCE to convert to the final MPEG-2, DVD level stream. First I do a single pass CBR to create the .vaf and then a 2 or 3 pass VBR to create final stream.

First of all, PicVideo is MUCH faster than hufyuv. (Actually, almost everything is faster than hufyuv). VirtualDUB can write the AVI at 40~43 fps (while filtering), when hufyuv would be 17~23.

CCE performs the first pass at a 2.3 ~ 2.8 speed if the file is PicVideo, while it does 0.8~1.01 if it's hyfyuv. On the other hand, the speed goes to 4.1 ~ 4.3 if the AVI is DivX encoded, which I like, however with DivX source, the result is always a black stream. (Any idea why?)

Downside is that encoding quality of the PicVideo is not good. Looking at the PicVideo encoded file, I see jpeg artifacts. Not prominent but visible. Also, dark areas present green macroblocks.

The settings I used for encoding are:

Quality = 20
Luminance Quality = 0 (Default)
Chrominance Quality = 0 (Default)
Subsampling = 4/2/2
2 Fields if more than xx lines = unchecked
Swap Decompress Fields = unchecked
Force YUV2 Output = Checked

Any ideas if the above settings are non-optimal?

Also, I have discovered another issue with CCE and performance.

If you start encoding and no other program is running, speed increases and settles to the maximum possible. If a heavy app is launched (e.g. Media player at full screen), CCE speed drops and CPU utilisation is shared between CCE and Media Player. If Media player is closed, CCE will NOT regain CPU utilization and will continue at a slower pace utilizing no more than 70~75% of the CPU. I have done this test 3-4 times and it always does this. Anybody else noticed this?

[disturbed1]

News from experiments.

Then I use CCE to convert to the final MPEG-2, DVD level stream. First I do a single pass CBR to create the .vaf and then a 2 or 3 pass VBR to create final stream.

The CBR first?

Some CCE tips http://forum.doom9.org/showthread.php?s=&threadid=44369

Downside is that encoding quality of the PicVideo is not good.

You want to configure PicVideo's decoder. You can force it to use higher quality (slower) to decode kinda like divx's decode level.