Fast and normal again

[movmasty]

Still seems to me that normal compression gives less size than fast at same quantizer, since xvid uses yv12 instead of yuv i made some other test.

Results for a shorth clip encoded in mjpg 1:1:1(rgb) and 4:1:1(yv12),
this why if i could use fast i can feed the codec with a movie in yv12,
but if, as seems to be, normal gives less size so it is better to use it,
a movie in yv12 will be decompressed in RGB and then recompressed by xvid in yv12,
and im not sure if this would be a losseless step, so it is better to have the clip already in RGB format.

The clip was encoded in one pass costant quantizer 4.

mjpg 1:1:1 fast compr 4,777,984
mjpg 1:1:1 normal com 4,257,792

mjpg 4:1:1 fast compr 4,775,936
mjpg 4:1:1 normal com 4,270,080

Fast recompress always gives to me higher size so i dont see why use it.

[Sirber]

"Fast" and "Normal", are they XviD settings or VDub settings?

[movmasty]

Vdub

[jggimi]

Wrong forum - this belongs in the Vdub forum.

AFAIK, Fast Recompress keeps the original colorspace, whereas Normal/Full convert to RGB. I may be incorrect, it may only be Full that converts to RGB.

It is my guess -- and only a guess -- that the differences you are seeing may be colorspace conversion related, since the codec will store video in YV12.

[Koepi]

It's a clear case of misunderstanding things - the same misunderstandings you had 1 year ago.

YV12 (the source: i.e. mpeg2 [dvd]...) -> RGB -> YV12 (the encode: i.e. XviD) is a _lossy_ chain.

Obviously it's possible to manage to not just loose quality but also real necessary information/details as the encoded file size at fixed quantizer gets less in your case with colour space conversions (you should also notice more washed-out colours. But I doubt that you'll notice the difference as quant2 and quant3 make no difference for you either, at least that was the case 1 year ago.).

I'd prefer if you, movmasty, could read around a little about colour spaces and video compression backgrounds, before posting things like these again.

We're talking scientifically here about such issues, not "out of our guts".

Thank you.

[movmasty]

Originally posted by jggimi
Wrong forum - this belongs in the Vdub forum.

AFAIK, Fast Recompress keeps the original colorspace, whereas Normal/Full convert to RGB. I may be incorrect, it may only be Full that converts to RGB.

It is my guess -- and only a guess -- that the differences you are seeing may be colorspace conversion related, since the codec will store video in YV12.
yes, this is the(known) difference between fast and normal,
with normal the codec has to read a rgb frame
with fast has to read a frame with the codec it was encoded with,
so if a clip is not in rgb, normal decompresses it, and then the codec compresses again, and i dont know if yv12-->rgb-->yv12 is losseless or not.

BUT, if you use a rgb clip fast and normal should work the same on the colourspace side, the codec has always to work with a rgb frame,
so why size is bigger with fast?
When full recompression is not used is always adviced to use fast, but fast gives more bits for same quality:
mjpg 1:1:1 fast compr 4,777,984(rgb-->yv12)
mjpg 1:1:1 normal com 4,257,792(rgb-->rgb-->yv12)

mjpg 4:1:1 fast compr 4,775,936(yv12-->yv12)
mjpg 4:1:1 normal com 4,270,080(yv12-->rgb-->yv12)(only in this case fast and normal differ)

THEN, using normal cause of its less size output, and doesnt knowing if yv12-->rgb-->yv12 is losseless or not,
to avoid a colourspace conversion i use clips encoded in rgb(mind the the vdub filters output is in rgb)
so there is only one unique colorspace conversion from rgb to yv12 with the final encoding,
as would be if output a clip in yv12 and then use fast recompression.

on the other side, saving movies in mjpg 1:1:1 takes more space than in 4:1:1, almost double space....

What i am saying is that if this is a bug in the fast recompression routine, and could be fixed, we could use the fast recompression saving intermediate movies in 4:1:1 and thus saving space,

or i'd like to know iif decompressing a movie from yv12 to rgb and then compressing again in yv12 is a losseless step when no other modifications are applied to it.

[stephanV]

Originally posted by movmasty
Still seems to me that normal compression gives less size than fast at same quantizer, since xvid uses yv12 instead of yuv i made some other test.

Results for a shorth clip encoded in mjpg 1:1:1(rgb) and 4:1:1(yv12),

mjpg 1:1:1 fast compr 4,777,984
mjpg 1:1:1 normal com 4,257,792



This doesn make sense... either the colorspace conversion in your MJPEG is broken, or MJPEG doesnt use RGB as internal colorspace (think its the latter).

As for your results, colorspace conversions (as done by using normal recompress on a non RGB source) work like a smoothening filter. No wonder you get better compressibility. But do you get the same quality? Visually perhaps, but not in reality. Perhaps some PSNR measurements could bring some light onto this (if the difference is large enough).

In any case, the compression method used in VirtualDub is not intended to be related to file size, although it might do this due to colorspace conversions. And if you wanted to test this, use a lossless compression like huffyuv in RGB.

[edit] colorspace conversion are NOT lossless

what is your RGB source?

[movmasty]

Originally posted by stephanV


[edit] colorspace conversion are NOT lossless

what is your RGB source?
i know that colorspace conv is not losseless itself,
if you convert rgb-->yv12 you loss, BUT

if you convert yv12-->rgb-->yv12, do you loss something?

for this test source was picvideo motion jpg, but im testing fast/normal since years and with all the codecs

[stephanV]

Originally posted by movmasty
[B]i know that colorspace conv is not losseless itself,
if you convert rgb-->yv12 you loss, BUT

if you convert yv12-->rgb-->yv12, do you loss something?

yep, youll lose something

[edit]

i just tried and do *not* see any size differences between fast and normal recompress with a RGB source (huffyuv). with an yv12 source (AVS-script) the "normal recompress"-file was larger. done in virtualdub 1.5.10 and used ffdshow mjpeg to encode with quant 4.

in virtualdub 1.6.0 normal and fast recompress have become redundant as its supports yv12 decoding now and will by-pass the filter chain if no filters are used.

[movmasty]

Originally posted by stephanV
yep, youll lose something

[edit]

i just tried and do *not* see any size differences between fast and normal recompress with a RGB source (huffyuv). with an yv12 source (AVS-script) the "normal recompress"-file was larger. done in virtualdub 1.5.10 and used ffdshow mjpeg to encode with quant 4.

you should encode in xvid or divx, not a light compression code as mjpg, in fact i use mjpg like source

[stephanV]

just tried it with DivX 1 pass quality based... doesnt matter for results (and why should it???)

*sigh*

[movmasty]

ok, just tested another clip of the movie with losseless picvideo,

now size is the same for fast and normal.

but i have no space to save movies in losseless format.

losseless fast 7,494,430
losseles normal 7,494,430
mjpg1:1:1 fast 8,587,914
mjpg1:1:1normal 7,494,430

then mjpg isnt good for fast recompress, and it is widely used.

[stephanV]

the quality of the smaller file is lower due to colorspace converions, so what are you talking about?

have you actually read anything that is said here?

[movmasty]

Originally posted by stephanV
the quality of the smaller file is lower due to colorspace converions, so what are you talking about?

have you actually read anything that is said here?
read the last test, there is not a smaller file, there is a bigger,

the size of normal compression,both from losseless or mjpg, is the same as the fast compression from losseless,

but the fast compression from mjpg is bigger...THEN dont use motion jpg with fast compression, even in 1:1:1 colorspace, this im talking about