Request: Decomb for RBG

[Cyberia]

@neuron2 - May I request that you add RBG support to Decomb? I have several AVIs I would like to clean up and re-encode, but they are RBG and I would like to avoid unnecessary conversions.

Thanks

[sh0dan]

Unless you are compressing to an uncompressed source, you material will probably be converted to YV12 anyway, so you might as well do this in AviSynth.

[Guest]

@Cyberia

What are you going to encode them with?

[Cyberia]

I was planning on using Nandub.

[Guest]

Originally posted by Cyberia
I was planning on using Nandub. LOL! :D

What final format: DivX, Xvid, TMPG MPEG2, CCE MPEG2, MPEG1, DV ... ?

[Cyberia]

Well, if I use Nandub, that sort of necessitates DivX 3.11a.

However, I will be switching to XviD, with either Vdub or VdubMod as the encoder, as soon as it settles down.

Out of curiosity, why do you ask? Both Divx and Xvid support RGB, correct?

[MasterYoshidino]

he's rite about the colorspacing, what if he was making a Quake III Arena demo using targas ???
:D

yes those codecs support 24bit/32bit RGB

[Guest]

Originally posted by Cyberia
Out of curiosity, why do you ask? Both Divx and Xvid support RGB, correct? No, they both encode to YV12 (they accept RGB as input, but that is different). That is why sh0dan suggested to convert to YV12 in Avisynth prior to Decomb, then use Fast Recompress in VirtualDubMod to encode directly to YV12 in DivX or XviD. sh0dan's point is that if you encode to DivX/XviD, you will have an RGB-to-YV12 conversion somewhere. You can do it prior to Decomb in Avisynth, thereby avoiding any need for an RGB Decomb. Please see the YV12 FAQ for details.

[Cyberia]

Guys, we have a problem. What neuron2 just said about DivX and XviD both storing info in the YV12 colorspace ONLY(!) caught me completely off guard. So I decided to do what he said, and test this...

I found that XviD ALWAYS saves into the YV12 colorspace, but DivX ALWAYS saves to RBG.

I tested VdubMod 1.4.13 with XviD (XviD-04102002-1) using the same input clip. The clip is natively RGB32. I used this script as a YUV input:

AVISource("E:\Movies\The Return of the King.avi")
ConvertToYUY2()
Trim(0,500)
#Info()


And this script as a YV12 input:

AVISource("E:\Movies\The Return of the King.avi")
ConvertToYV12()
Trim(0,500)
#Info()


Under Fast Recompress OR Full Recompress, VDubMod (XviD) would ONLY produce YV12 output. However, the same test performed under Nandub (DivX) would ONLY produce RGB32 output.

I tried this from scratch twice.

So then I thought, 'go back to basics.' Using vanilla VDub 1.5.2, with DivX Low Motion, I tried all the tests again under Fast Recompress and Full Processing mode. The output was ALWAYS RBG!

I changed compressors to XviD. Now the output was ALWAYS YV12, regardless of mode or input colorspace.

Guys, this is Very Bad! It could mean any or all of the following:

1) The primary developers here (possibly including the XviD team) are unaware that DivX supports other colorspaces.
2) We have no compressor that lets us passthru RGB, YUV or YV12. With Xvid, a colorspace conversion is REQUIRED unless we begin with YV12 and with DivX a colorspace conversion is REQUIRED unless we begin with RGB32.
3) I am a complete idiot, and have no idea what I am talking about, let alone being able to run a competent test.


I am leaning towards #2 being true. #1 and #3 might be true though. ;)

[Guest]

I'm leaning towards #3. :D

I just finished a DivX 5 encode feeding it YV12 and using Fast Recompress with VirtualDubMod. The resulting Avi is reported by three applications as YV12 (BSPlayer, Avisynth Info(), VirtualDub).

Tell us your exact process to make the DivX file and *why you believe* it is using RGB color space.

EDIT: I just repeated it with DivX 3 Low Motion. It made YV12 as expected and according to the MPEG4 spec.

[Cyberia]

Ahh yes, but you didn't start with RGB input and use DivX 3.11a.... So #3 is still unproven. ;)

VDubMod 1.5.1.1a
Nandub 1.0rc2 (Build 1853) + Lumafix
AVISynth 2.51 Build:15 May 2003
DivX 5.05 Pro
XviD 04102003 Koepi
DivX 3.11a

For these tests I used this input script:

AVISource("E:\Movies\The Return of the King.avi")
ConvertToRGB32()
Trim(0,500)
#Info()


Using VDubMod in Fast Recompress Mode I encoded the video three times, producing three output files. One encode for DixV 5.05, one encode for XviD, and one encode for DixV 3.11a. The output files were named:

vmod-FRM-RGB-DIV5.avi
vmod-FRM-RGB-DIV3.avi
vmod-FRM-RGB-XVID.avi

Then, to determine the colorspace of the output file, I opened this script (CheckInfo.avs) in VDubMod:

AVISource("vmod-FRM-RGB-*.avi") <-select filename
Info()


Here are the results:
vmod-FRM-RGB-DIV5.avi colorspace=YV12
vmod-FRM-RGB-DIV3.avi colorspace=RGB32
vmod-FRM-RGB-XVID.avi colorspace=YV12

Encoding the input script in Nandub (Fast Recompress) generated this file:
nan-FRM-RGB.avi

Which, when opened through CheckInfo.avs, reported this result:
nan-FRM-RGB.avi colorspace=RGB32

[Guest]

So you've established that the hacked DivX 3 is in fact hacked. Beyond that, do you have a point?

[Cyberia]

Uh well,

Is the DIV3 output really in RGB32?
If that's true, how can that be?
Why don't the newer codecs support this obviously useful feature?

I can also deduce that in the very immediate future, ALL filters for AVISynth are going to require YV12 ONLY. Since, we can only output to that format, why even create versions for the other colorspaces?

[Guest]

Originally posted by Cyberia
I can also deduce that in the very immediate future, ALL filters for AVISynth are going to require YV12 ONLY. Since, we can only output to that format, why even create versions for the other colorspaces? You are so out in left field here! There are codecs that output to different color spaces. You can use HUFYUV for YUY2, for just one example. Your deduction that all filters will soon support only YV12 is silly.

[Cyberia]

OK, well thanks for your time.

[Suikun]

For reasons beyond me the DivX3 codec will output RGB32 primarily if asked to decompress anything, even though it internally stores all data in YV12, like all MPEG4 codecs. So when using it with avisynth and reencoding it to whatever other format you'll most times have two colorspace conversions: one in the DivX3 _decoder itself_ from YV12 to RGB32 (which is later on output to avisynth) and again one from RGB32 to something else, as almost no codec natively encodes in RGB32, but most likely to YV12 again.
As a solution you could for example uninstall it and let all DivX3 videos be decoded by ffvfw (search the forum for it) and you'll notice that it will indeed output YV12.

Bleh, talked too much again. Summa summarum it's just a glitch in the DivX3 codec, which forces it to output to RGB32 at all costs.

[Cyberia]

Suikun - Thanks for the good explaination, it's all clear to me now.