Why don't I get an appreciable speed increase with fast Reprocess and DivX5.0?

[JimmyBarnes]

Am using VDub 1.4.10 and DivX Pro 5.0 on a Duron 1 GHz/256 MB RAM/WIN Me.

Create D2V project file with DVD2AVI v1.76, use GKnot 0.23 to set cropping and resizing. Open the project file, do Save and Encode, select Neutral Bicubic and save the AVS for use in VDub.

I'm used to using VDub's Full processing Mode but when I try Fast Reprocess and the AVS above, if anything the rip is slower, not faster (doing 2-pass encoding). Others say they get a 30 % processing speed increase from using Fast Reprocess.

Can anyone suggest what my problem is?

thanx
JB

[dragoman]

Hi,

DivX 5 has some new features, like b-frames, gmc, and quarter-pixel settings.

If you use these, especially q-pel, it takes more processing to encode/decode the video stream. This means that while divx5 may be faster in a basic format, the addition of these features slows down the encoding, in some cases slower than divx4!

dragoman

[N_F]

I don't notice a very big difference between Fast recompress and Full recompress either. Perhaps 10%, but that's it for me.

[JimmyBarnes]

Originally posted by dragoman
Hi,

DivX 5 has some new features, like b-frames, gmc, and quarter-pixel settings.

If you use these, especially q-pel, it takes more processing to encode/decode the video stream. This means that while divx5 may be faster in a basic format, the addition of these features slows down the encoding, in some cases slower than divx4!

dragoman

Granted but if the only difference is in using Fast Reprocess or Full Processing Mode (all other settings the same), shouldn't the former be relativelyfaster?

JB

[Acaila]

Granted but if the only difference is in using Fast Reprocess or Full Processing Mode (all other settings the same), shouldn't the former be relativelyfaster?

Not if any of the MPEG4 features use a colorspace conversion to achieve their goal. The point in using fast recompress over normal processing is to avoid the colorspace conversion YUY2->RGB->YV12 and only do YUY2->YV12. Normally this will save time, unless any of the filters/settings you use only work in RGB and thus force a YUY2->RGB->YUY2 conversion internally.

I don't know if the MPEG4 feature do such a thing, but the best thing to test the speed-up with fast recompress is to do it without these features.

[theReal]

Acaila, I think normal recompress does a colorspace conversion, right? And normal recompress for me is almost as fast as fast recompress, and those two are both substantially faster than full processing.

JimmyBarnes, consider buying more RAM. Even in Win98 SE the avisynth-Vdub-Divx5 combination takes at least 160MB (never seen it using less). You could check it out for free by borrowing a 256MB stick from a friend - I think it will help your overall encoding speed as well as the relative difference between fast recompress and full processing.

[dragoman]

Hi,

Yeah, RAM could help too....I used to encode with an Athlon 800, but I had 448 MB Ram....

Now I am zooming at P4 1.6Ghz.....and 512 DDR.....life is good :)

dragoman

[ppera2]

JimmyBarnes
Double check that you saved DVD2AVI project with YUV mode and not RGB.
Fast recompress must be faster 20-30%.

[JimmyBarnes]

Originally posted by ppera2
JimmyBarnes
Double check that you saved DVD2AVI project with YUV mode and not RGB.
Fast recompress must be faster 20-30%.

Yes I have checked it before. Color Space is set to YUV 4:2:2. I never use RGB for this.

However on occasion I have used TV scale rather than PC scale for
YUV->RGB, though even on the default PC scale, Fast Reprocess is no faster the Full Processing Mode.

JB

[JimmyBarnes]

Originally posted by Acaila

Not if any of the MPEG4 features use a colorspace conversion to achieve their goal. The point in using fast recompress over normal processing is to avoid the colorspace conversion YUY2->RGB->YV12 and only do YUY2->YV12. Normally this will save time, unless any of the filters/settings you use only work in RGB and thus force a YUY2->RGB->YUY2 conversion internally.

I don't know if the MPEG4 feature do such a thing, but the best thing to test the speed-up with fast recompress is to do it without these features.

I get your point.

However I am strictly following Doom9's DivX 5 guide at present and he recommends using GMC, Bidirectional processing and Fast Reprocess, so I presime there is a point in using the latter.

I timed a 10000 frame test using Full Processing Mode or Fast Reprocess as the only difference (typical settings for a DivX5 rip as per Doom9). Results were:

FPM 17 min 14 s FR 16 min 12 s

The FR time was 94 % of the FPM time.

JB

[Acaila]

Indeed, 6% speed-up is not something to write home about....

I still suspect you're using filters that slow things down. Things like TemporalSmoother and DeInterlacing usually negate the effect of Fast Recompress on my encodes. And as we all know the MPEG features slow everyone's encoding down too, so I wouldn't be surprised at all that if you used GMC, B-frames, and DeInterlacing you'd lose your speed benefit completely.
I still recommend staying with Fast Recompress, because the fewer colorspace conversions the better, even if it doesn't speed things up for you.

Besides, if you want a real speed-up, buy a faster computer! Mine should be delivered within the next few days, and it will be smoking fast when I put it together! :D

[JimmyBarnes]

Originally posted by Acaila
Indeed, 6% speed-up is not something to write home about....

I still suspect you're using filters that slow things down. Things like TemporalSmoother and DeInterlacing usually negate the effect of Fast Recompress on my encodes.

The only filter I use is resize/crop. Never use smoothers or need to use deinterlace (ripping PAL DVDs only - might be the reason?)


Besides, if you want a real speed-up, buy a faster computer! Mine should be delivered within the next few days, and it will be smoking fast when I put it together! :D

Hey, man my 1 GHz Duron blazes compared to the ol' 200 MHz Pentium
;)

JB

[cordraconis]

I have the same problem; Fast recompress has the same speed as Normal recompress (The only difference is that with fast recompress, I'm not able to see which scene is being encoded, and if I use normal recompress, disabling the "view in- and output" option, gets me some 1 till 2 FPS extra, ... Just as with Fast Recompress.)

The biggest difference I had, was putting in the 256MB DDR extra. (Avisynth is indeed rather greedy on RAM).

Anyway, I still haven't found the problem, but I'm happy with the speed I have now ;)

[theReal]

Right now, Taskinfo2000 reports a RAM usage from Avisynth/VDub of 192 MB.
The total memory load (used by programs) is 50%, but I have only 79 MB of free available RAM left (while 110 MB are being used as cache).

This is in Win98 SE with pagefile disabled. I really think 256 MB would be not enough.

[N_F]

Aren't PAL DVDs usually interlaced?

[Acaila]

No, exactly the opposite. I haven't found a single PAL interlaced movie yet (thank god! :)), but they do exist.

[JimmyBarnes]

Originally posted by N_F
Aren't PAL DVDs usually interlaced?

Ripped some 40+ PAL DVDs so far and never had to worry about deinterlacing. Some may report as interlaced in DVD2AVI but this is incorrect apparently (I think Doom9 or some other heavy pointed this out). No horizontal black lines typical of interlacing ever seen.

JB

[N_F]

That's strange... I've got about 20 DVDs that I'm currently ripping. Most of them are bought in scandinaivia (is that an english word?) and usually have swedish/danish/finnish/norweigan subtitles. DVD2AVI reports all of these as PAL 4:3 interlaced and that's how I've treated them. Come to think of it, some of these haven't looked interlaced in DVD2AVI or Gordian Knot and some have, but I've still used deinterlacing on them all which perhaps was a mistake if DVD2AVI indeed reports wrongly sometimes.

Is this perhaps something particular to Scandinavian DVDs?

[Acaila]

DVD2AVI mis-identifies most normal PAL progressive DVD's as interlaced. NEVER trust what the stats windows says, but always scan through the preview if you see the actual interlacing artifacts or not. About 99% of the time you won't see interlacing for PAL sources, not even if they come from Scandinavia :D.

[N_F]

OK. When can one expect to see interlaced DVDs?

[theReal]

I think the Smartripper logfile says better what kind of format you are dealing with. I also never had an interlaced PAL DVD (although I haven't ripped too many DVD's.
PAL DV is interlaced, unfortunately, just like PAL tv captures, so I have to deal with it quite often...

[ppera2]

Originally posted by theReal
Right now, Taskinfo2000 reports a RAM usage from Avisynth/VDub of 192 MB.
The total memory load (used by programs) is 50%, but I have only 79 MB of free available RAM left (while 110 MB are being used as cache).

This is in Win98 SE with pagefile disabled. I really think 256 MB would be not enough.

Hmmm... I didn't see much speed increaase in Win Me between 128 and 256 MB, maybe 1-2 %.
And I have same speed in XP, which is more memory hungry, and I didn't make any optimizations until now.

[Bill_st]

Originally posted by N_F
OK. When can one expect to see interlaced DVDs?

I have ripped some anime DVDs (I hate animes, my bro forced me to do it :angry: ), and they always seem to be interlaced, probably because most of them were interlaced from the beginning (direct to TV).

[grug2k]

The only time you will ever see interlaced on a PAL DVD is stuff that is converted from NTSC. ie, anything shot on video rather than film, music videos, anime (TV anime, not movies.), Simpsons, etc. Often "making ofs" and even trailers will be interlaced due to the fact they appear on TV at some point in NTSC.

It to sorta preserve the 30fps in a 25fps world. Of course, with a movie at 24, it just speeds it up to 25.

If I'm getting something NTSC-sourced, (Simpsons Box Set, for instance), I'll usually get the NTSC disc.

---

Back on subject, I have an Athlon @ 1466 and 256Mb and I see no difference either. It must be the RAM.