Why use Fast Recompress?

[ChAoS Overlord]

I see that doom9 states (http://www.doom9.org/divx5-vdub.htm) that you should use fast recompress with divx5. Why is this? Is the quality equal?

[rui]

Because is MUCH faster. And i for one don't notice any quality degradation.

[zulu]

fast recompress doesn't involve YUV <-> RGB conversion (which is required by vdub filters if i remember correctly...)

[ChAoS Overlord]

So: as long as you don't use any filters, fast recompress is the way to go, am I right?

[Klumsy]

Absolutely

[rui]

Originally posted by ChAoS Overlord
So: as long as you don't use any filters, fast recompress is the way to go, am I right?

You can still use other filters, like the ones called in the avisynth script.

For more details read doom9's gnot guides

[Klumsy]

Ouch, how could I forget the avisynth-filters :scared:

[facts]

Fast recompress doesn't give me any extra speed in first pass divx 5.0 on my tbird 1.2, wierd.

[muralin]

what sort of speed improvement one can expect with fast recompress? i have never used it even though generally, i am a very loyal follower of doom's guides.

[rui]

Well, an example:

When encoding The Replacements trailer, with my P2-350, when using Full Processing, it takes 47 minutes give or take a minute.
When using Fast recompress it takes 13 minutes, give or take a minute again.

Faster, humm? ;)

But maybe you should look in the Vdub forum for more info.

[ProfDrMorph]

as already mentioned Fast Recompress skips the YUV<->RGB conversions. Since VirtualDub's filters won't work in YUV colorspace you have to use AviSynth to filter your source. By avoiding conversions between two colorspaces ( YUV & RGB ) your CPU has less to do and you actually improve the quality since no conversion is done ( such a colorspace conversion is always "lossy" in some way ). But actually nobody should be able to see a difference between a movie that has been encoded with or without YUV<->RGB conversion ( since the quality loss is VERY small but it is there ). The only difference may be the brightness but you can "fix" this while playback by changing the decoder filters properties.

[theReal]

In another thread somebody (sorry, forgot who it was) said recently that using fast recompress would result in bigger files than normal recompress in Nandub when using a fixed quantizer.

Is that true? And what is the exact difference between fast and normal recompress (you also cannot use VDub filters with normal recompress as far as I know)?

[Zhnujm]

@rui

are you sure these values are correct ,more than 3x faster with fast recompress ?
i get max 30%+ with my 1800xp. and i cant believe the xp is so much faster when converting yuv->rgb->yuv.

[muralin]

i just did a quick test. i see between 30% speed improvement in encoding. did a 1-pass quality. but, when i tried to playback the video (fast recompress), i got a black screen.

if i used full processing, the result is perfect.

what am i doing wrong?

[Teegedeck]

Originally posted by theReal
In another thread somebody (sorry, forgot who it was) said recently that using fast recompress would result in bigger files than normal recompress in Nandub when using a fixed quantizer.

Is that true? And what is the exact difference between fast and normal recompress (you also cannot use VDub filters with normal recompress as far as I know)?

It isn't true. Perhaps I was too polite when I warned people from listening to that guy in the thread you mentioned. But do some testing yourself - it always is good if knowledge is put to the test.

[theReal]

Teegedeck,
thanks, somehow I must have overlooked your warning.
However, I didn't really believe that guy (sorry, still can't remember the name) but didn't have time for testing.
I had in mind that the doom guides and the Gknot help both say you can safely use fast recompress when you don't need VDub filters - I guess they both wouldn't say it like this if there was the slightest quality loss with fast recompress.

Still, what is normal recompress for, then??


P.S.:"The cat sat on the mat."Linguist??

better: "The cat sat on the mat, but I don't believe it." ;)

[philippas]

You should use fast recompress almost always except when you encode with nandub+divx3.11(use antishit then), because it is likely sometimes to get shit.

@rui
Fast recompress is faster by 20-30% not 3 times faster :eek:

[movmasty]

i need to do more tests,but seems to me,from test of one year ago, that using fast recompress when doing final encoding in divx3 produces oversized movies respect the normal compress mode.
in nandub more often than in vdub

[rui]

Well, i seem to have raised some surprise with my above post :)

Thats what my lowly p2-350 (in my work, where i made that small test) would take to make both encodings.
Maybe because it's a p2-350 that i see those diferences, i don't know.

I never made that test in home, where i have a AMD XP.

[ProfDrMorph]

I also tested Fast Recompress speed compared to Full Processing Mode: 30% faster is correct.

Normal Recompress is the same as Full Processing Mode without filters.

In case my previous post wasn't clear: actually Fast Recompress has the HIGHER quality than Full Processing mode since useless color space conversions are skipped.

[movmasty]

@ProfDrMorph
Full Processing Mode without filters is....Full Processing Mode without filters.
normal compress is another thig, is different to just use Full Processing Mode without filters.....

normal compress is noticeably faster than full processing,more near to fast recompress,
i always use normal c. for final encodings.

[ProfDrMorph]

I looked into the help file of VirtualDub and you're right Normal Repack is more than just Full Processing Mode without filters: in additation to disabling all filters VirtualDub also doesn't convert the output of the decompressor. E.g. if you have an AVI file and the codec it uses only outputs 16-bit RGB but the codec you want to use to compress the video doesn't accept 16-bit RGB Normal Recompress won't work while Full Processing Mode would convert the images to 24/32-bit RGB so that you can use your codec of choice.

The difference between Normal Repack and Fast Repack is ( as already said ) that Normal Repack uses RGB images and Fast Repack uses YUV images. Since most of the modern codecs store the frames internally working in YUV colorspace Fast Repack is faster since no conversions between RGB and YUV are done.

[philippas]

The difference between Normal Repack and Fast Repack is ( as already said ) that Normal Repack uses RGB images and Fast Repack uses YUV images

@ProfDrMorph To clear things a bit.

When using fast Recompress the color space stays as it was in the source file, fast recompress doesn't operate in YUV only.
For example, if you capture a file using RGB 16 or 24 and then compress using fast Recompress, the colorspace stays RGB16 or RGB24 respectively it doesn't change to YUV and it doesn't only operate in YUV.

Using full processing mode decompresses the source to RGB32.
So if you have a source with RGB24 colorspace the souce will be decompressed first to RGB32. Thus you have RGB24-->RGB32->colorspace of the compressor.
But if you use slow repack you have RGB24-->RGB24(no change)-->colorspace or RGB16-->RGB16(no change)-->colorspace of the compressor.

[TheWEF]

i'd like to add one thing: when you finally watch the movie, color-space has to be converted to rgb in any case to appear on your rgb monitor. some gfx-drivers and some players can cause problems with yuv-avis, at some desktop-color-depths you might not get a working hardware overlay.
so there is a little drawback with fast-recompress, but only few systems are affected, and normally the problem can be solved easily with a different player or a driver-update.
imho the speed-gain is definitely worth it.

wef.

[Pio2001]

The speed improvement depends on the filters used.
I remember having tried once fast recompress with de-interlace/cropping/resizing in avisynth and got no speed improvement over full processing mode.
Usually, the speed improvement is about 9fps to 12 fps (so 30 %).

[movmasty]

when you finally watch the movie,that is almost never,since we have others to encode :D ,
the colour space used will be that of the codec used,
then,if divx uses rgb we'll have:
Fast recompress:
rgb24--->rgb24, or
yuv----->rgb24....no good
Normal recompress
rgb24--->rgb24, or
yuv----->rgb24

if divx use yuv
Fast recompress:
rgb24--->yuv...no good
yuv----->yuv
Normal recompress
rgb24----->yuv, or
yuv-->rgb-->yuv.

so, what colourspace is divx using??
and if yuv, the 16,12 or 9 bits one??

and what about oversized divx encodings using fast recompression?
seems to me that earlyer versions of vdub output oversized divx with fast r., the newer versions dont, while nandub still does.

[ProfDrMorph]

even the old JPEG and MPEG codecs use YUV colorspace since it's easier to say where encoding errors a more visible ( luminance part, Y ) or where they are less visible ( chrominance part, UV ). If DivX get's RGB as input it will convert it to YUV ( specifically to YV12 if I remember correctly ). So differences in encoding with YUV and RGB are simply bugs in either the program that converts the colorspace or the codec.

@TheWEF: your post is a bit unclear: isn't the colorspace conversion done by the gfx card on most of the modern systems? A software conversion would only need CPU time while the GFX card is falling asleep since it has nothing to do ( except sending the images to the screen ) ;).