color adjust necessary in capture->SVCD?

[george_zhu]

I capture video from analog camcorder and encode it into SVCD or VCD to play on TV. I use CCE for SVCD and TMPG for VCD. In the Avisyth's guide, they suggest some color adjustment about to change YUV value to 0-255. Do I need to do it since the final is also in limited range? Or is it better to input full-range clip as the source in CCE/TMPG?

[trevlac]

I believe it all depends upon your process.

For example:

- If you capture in YUY2, you should have a range of 16-235
- If you ever convert to RGB, you probably now have a range of 0-255
- Capture with an mjpeg codec is an exception. You can get RGB 16-235 out of one of them.

You should match what you have with the encoder options. For example, it is my understanding (from a quick look at the manual), that the 16-235 option for CCE means your input is RGB 0-255 and CCE will convert it to 16-235 YCbCr. The 0-255 option means your input is RGB 16-235 (like from mjpeg) and CCE will not change it when it converts to YCbCr. From what I can tell, this option should only effect RGB input. It also seems backwards, but my comments are based upon the formula they show.

If you are asking if you should intentionally change things, I'd say no.

If you tell me if you have RGB or YUY2 source and what codec you used, and what you do in the middle (like with avisynth), I will be more specific.

[george_zhu]

Thanks. My procedure is: capture at PicMJPG(Q19), edit it in adobe premiere, then encode into SVCD (CCE) or VCD (TMPG).

Originally posted by trevlac
I believe it all depends upon your process.

For example:

- If you capture in YUY2, you should have a range of 16-235
- If you ever convert to RGB, you probably now have a range of 0-255
- Capture with an mjpeg codec is an exception. You can get RGB 16-235 out of one of them.

You should match what you have with the encoder options. For example, it is my understanding (from a quick look at the manual), that the 16-235 option for CCE means your input is RGB 0-255 and CCE will convert it to 16-235 YCbCr. The 0-255 option means your input is RGB 16-235 (like from mjpeg) and CCE will not change it when it converts to YCbCr. From what I can tell, this option should only effect RGB input. It also seems backwards, but my comments are based upon the formula they show.

If you are asking if you should intentionally change things, I'd say no.

If you tell me if you have RGB or YUY2 source and what codec you used, and what you do in the middle (like with avisynth), I will be more specific.

[trevlac]

When you capture do you choose RGB or YUY2? PIC supports both. If you choose RGB, what capture card do you have?

You should capture in YUY2, use YUV only in Adobe, then there should be no problems in CCE.

If you capture in RGB, you probably should pick 16-235 in CCE.
If you capture in YUY2 but use RGB in adobe, you probably should pick 0-255 in CCE.

I don't know what the options in TMpeg do. Regardless, you can test all of this by making a black clip in avisynth (RGB=0) and running it thru the process. If the end product is not black (like RGB=16,16,16) then you have a problem. Use a color picker to see the values all the way thru the process if you can.

To try to answer your original question: You need to know your range from the start. If you do, there is little reason to change. You must tell your encoder the proper range.

Hope this helps.

[Arachnotron]

In TMPEGEnc choose:

MPEG settings,
Quantizise matrix tab,
enable/disable "Output YUV data as Basic YCbCr not CCIR601"

From the Help text:

then, Y range of MPEG YCrCb is not 8-235 but 0-255.
Since DV format is already recorded as CCIR601, better result can be expected if this option is enabled.

I assume the 8 is a typo and should be 16.

I do not know if TMPGEnc accepts pure YUV sources, or converts to RGB first. I read somewhere TMPEGEnc always converts to RGB if you enable one of the filters, but the quote above makes me unsure of this.

If there is a RGB conversion involved, you have to know which codec does that and what that one does.

[george_zhu]

I think Adobe only use RGB32, doesn't it?

Originally posted by trevlac
When you capture do you choose RGB or YUY2? PIC supports both. If you choose RGB, what capture card do you have?

You should capture in YUY2, use YUV only in Adobe, then there should be no problems in CCE.

If you capture in RGB, you probably should pick 16-235 in CCE.
If you capture in YUY2 but use RGB in adobe, you probably should pick 0-255 in CCE.

I don't know what the options in TMpeg do. Regardless, you can test all of this by making a black clip in avisynth (RGB=0) and running it thru the process. If the end product is not black (like RGB=16,16,16) then you have a problem. Use a color picker to see the values all the way thru the process if you can.

To try to answer your original question: You need to know your range from the start. If you do, there is little reason to change. You must tell your encoder the proper range.

Hope this helps.

[Wilbert]

I assume the 8 is a typo and should be 16.

Yup.

I do not know if TMPGEnc accepts pure YUV sources, or converts to RGB first. I read somewhere TMPEGEnc always converts to RGB if you enable one of the filters, but the quote above makes me unsure of this.

Afaik it always converts to RGB24.

enable/disable "Output YUV data as Basic YCbCr not CCIR601"

From the Help text:

quote:

then, Y range of MPEG YCrCb is not 8-235 but 0-255.
Since DV format is already recorded as CCIR601, better result can be expected if this option is enabled.

If this is true, something weird is going on. Because, in general, it is false. A while ago I made some tests (last 2-3 three posts of mine):

http://www.kvcd.net/forum/viewtopic....r=asc&start=48

My conclusions were:

"conclusion: the scaling (16,235)->(0,255) is performed when the option "output YUV as Basic YCbCr and not CCIR601" is checked."

"My conclusion is that all YUV values with Y<16 is clamped to (Y,U,V)=(16,128,128) when leaving "output YUV as Basic YCbCr and not CCIR601" unchecked.

I guess all values with Y>235 are clamped to (Y,U,V)=(235,128,128), but I didn't check this."

Strangely enough, in the tests, TMPGEnc was feeded with RGB24. So, no color conversions took place.

IMO: If you feed it with DV-avi, it will do the conversion to RGB24 by itself. If the conversion is done correctly, you should uncheck that option. I don't have time to do some tests

I think Adobe only use RGB32, doesn't it?

Yup.

[Kika]

Wilbert, i'm sorry, but you are wrong.

TMPGEnc is working this way:
In CCIR-Mode, the range is compressed from 0-255 to 16-235.
In YCbCr-Mode, the range isnt changed. So if your Source is already in 16-235, use YCbCr. Is it in 0-255 then use CCIR.
TMPGEnc never clamps anything.

But be carefull about the Source, it depents on the Conversion (YUV-RGB) what exactly happens.

As an Exampel: If the Source is PICVideo MJPEG from a TV-Card in YUY2-Mode, you have Source with the Range of 16-235. If you are using AVIsynth with AVISource and Pixeltype = YUY2 to open it, the Range is shifted to 0-219! By using Pixeltype = RGB24, the Range is correct. If you are using TMPGEnc on this Source, you MUST use YCbCr-Mode to get the correct Luma-Range.

[Wilbert]

We have had this discussion before on the german forum. That behaviour of PicVideo you saw is somehow caused by PicVideo itself and not by TMPGEnc. If you don't agree, you will have to explain me the results of my tests.

I asked you for:

1) A PicVideo test-avi + codec. So, that I also could have a look at it.

2) Whether you could do this test with other codecs, like huffyuv.

As an Example: If the Source is PICVideo MJPEG from a TV-Card in YUY2-Mode, you have Source with the Range of 16-235. If you are using AVIsynth with AVISource and Pixeltype = YUY2 to open it, the Range is shifted to 0-219!

This is a very important remark, it explains a part of the strange behaviour! How did you check this? Could you try the following:

a) Shift the range back to 16-235 by using ColorYUV(off_y=16)

b) Add (as a last line) ConvertToRGB24 line in AviSynth.

c) Use TMPGEnc which the setting checked _off_

What are the results?

Anyway. I still don't completely understand what's going on. If you open the avi directly in TMPGEnc, then I assume that PicVideo is converting to RGB24 by itself. In your post, you said that the conversion to RGB24 was accurate: "By using Pixeltype = RGB24, the Range is correct." Ok, that's in AviSynth, but that doesn't matter. If you turn of the setting in TMPGEnc, nothing should happen. But remembering, our discussion at the german forum, it is still messed up.

[Kika]

@Wilbert

Since our Discussion i've tested this with a lot of Source-Materials, not only MJPEG. From DV with different Codecs, from MPEG2-Source, i've checked TMPGEncs behavior also with Pictures and many other things. I've used AVISynth or other Methodes to get the Source into TMPGEnc. But the Results are always the same:

YCbCr: It takes the Source as is.
CCIR: It compresses the Range.

That's the TMPGEnc-Part. This Encoder act's like descriped in the Help-Text (look at Arachnotrons Posting).

Do you remember the AVISynth Scipts i postet in our Discussion?

avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToYUY2(interlaced=true)


avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()

They are just for testing. On my machine, TMPGEnc can read YUY2 directly, but if i use ConvertToRGB24() at the End of the Script, the Results are the same.
Source is MJPEG from my TV-Card in YUY2-Mode.

The first Script is giving me the correct Luma-Range, the Second is shifting the Range. Shifting it back by using ColorYUV corrects this. Guess, that's a fault of PicVideo, but it shows a Problem: What is AVISynth or an other Program using for decoding while Reading an AVI? And does this Codec do a correct Conversion if needet?
The first Script gave me the same Results like opening the MJPEG-Video directly in TMPGEnc. If i'm capturing in HuffYUV than it's also the same. I have to use YCbCr in TMPGEnc to get the correct Luma-Range.

Things are changing completly, if i'm capturing in RGB24, not YUY2. Than i get a Source-Luma Range of 0-255! And than i have to use CCIR-Mode in TMPGEnc.
ConvertToRGB24() as the last line is only needed (on my PC) if anything other used than RGB or YUY2. In most cases, i'm carfull, so i use this Line.

I think, the Problem isn't TMPGEnc. It realy acts like i wrote, that's proven and it does make a lot of sense. The problem is the Source:
What Decoder is used?
What Luma-Range is used?
If converted, is the conversion correct?

[trevlac]

I would have to humbly disagree with Wilbert's conclusions.

• I assume TMPGEnc only accepts RGB. If it accepted YCbCr, I doubt it should be messing with conversions and clamping because it is going to output YCbCr
• Any RGB source input into TMPGEnc got that way because of some other program. If it came from Avisynth with an explicit ConvertToRGB, Avisynth did the conversion from YUV to RGB. If it came from Avisynth without conversion, the default system codec did the conversion. If it came in as a direct avi file, the codec for that avi file did the conversion.
• TMPGEnc does not clamp. The codec/avisynth whatever does the clamp when it converts.
• In Wilbert's test, he created YUV source and did an explicit convert to RGB using Avisynth. This is where the clamp occured.
• In the test, Avisynth also mapped from the 16-235 range to 0-255 with the ConvertToRGB command. So when TMPGEnc was "unchecked", it mapped back to 16-235.
• Unchecked should be the default. Most RGB is in the range of 0-255.
• When MJpeg codecs convert from YCbCr to RGB, they do not seem to change the range. So in this case, if you have YUV in MJPEG check the box in TMPGEnc

Since george has not said if he captured in YUY2 or RGB, I'll assume YUY2. George should use the 0-255 option in CCE and Check the box in TMPGEnc.

Why?

YUY2 is captured in a range of 16-235. If you open the avi in Adobe, PIC will convert to RGB and keep the same range. (It will look washed out in Adobe). Unless Adobe changes the range, it will output RGB in 16-235 Range. In CCE 0-255 means CCE should not mess with the range. This is good if you already have 16-235. In TMPGEnc, checked means TMPGEnc should not mess with the range. Again, this is good if you already have 16-235.

This of course is all just connecting the dots on my part. George should make a black clip and run it thru his process. Pick the color before and after. If it's still the same, regardless of the conversions that take place in the middle, it's probably good enough.

[Kika]

@trevlac

That's exactly what i meant.


(and maybe, somedays, my english becomes good enough to write such stuff not the clumsy Way i'm doing now... )

[Arachnotron]

Quote from Kika:

Things are changing completly, if i'm capturing in RGB24, not YUY2.

To add to the confusion:

According to the specs, my Philips SAA7134 tries to put black at 16 and white at 235 in YUV. If you ask it for RGB, it will keep this range, so 16 is still black in RGB. It does NOT convert the Y 16-235 to 0-255 RGB ! But, this might not be the case for other capture devices.

RGB is hell....

[edit] corrected a mistake (bold)

[Wilbert]

TMPGEnc does not clamp. The codec/avisynth whatever does the clamp when it converts.
In Wilbert's test, he created YUV source and did an explicit convert to RGB using Avisynth. This is where the clamp occured.
In the test, Avisynth also mapped from the 16-235 range to 0-255 with the ConvertToRGB command. So when TMPGEnc was "unchecked", it mapped back to 16-235.

Ok, I agree with this. Btw, I never disagreed with the latter.

What did you think about the first conclusion:

"conclusion: the scaling (16,235)->(0,255) is performed when the option "output YUV as Basic YCbCr and not CCIR601" is checked."

When MJpeg codecs convert from YCbCr to RGB, they do not seem to change the range. So in this case, if you have YUV in MJPEG check the box in TMPGEnc

Are you saying that the first conversion YCbCr -> RGB is incorrect? This is not the case according to Kika:

"avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToRGB24()

(...)

The first Script is giving me the correct Luma-Range"

edit: with incorrect I mean [16,235] YCbCr to [16,235] RGB or something like that.

I'm also wondering about this:

If you are using AVIsynth with AVISource and Pixeltype = YUY2 to open it, the Range is shifted to 0-219!

How is this possible?

[Kika]

Are you saying that the first conversion YCbCr -> RGB is incorrect? This is not the case according to Kika:

Wilbert, that's correct and exactly what i said. The internal Conversion of MJPEG-Codecs (YUY2 -> RGB24) does not touch the Luma-Range.

I'm also wondering about this:

--- snip ---

I guess that's a Bug, no idea where it come from. Maybe it's a Bug in PICVideo, maybe in AVISynth, i don't know.

[trevlac]

Hi,

This is all a bit messy... but I'll try to be clear on what I think.

Originally posted by Wilbert
What did you think about the first conclusion:

TMPGEnc never should go 16,235 -> 0,255. That only makes sense for a YCbCr -> RGB conversion. It should only ever do RGB->YCbCr. Checking the box should tell it that RGB source is in the 16,235 range and it should not change it.

Are you saying that the first conversion YCbCr -> RGB is incorrect? This is not the case according to Kika:

"avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToRGB24()

(...)

The first Script is giving me the correct Luma-Range"

I like how PIC converts. It gives RGB without clamping. So incorrect depends on what you are trying to do.

He said that input from PIC RGB or YUV gives different results. At the point of input to Avisynth, they are the same range 16-235. When he inputs to TMPGEnc the YUV one gets converted by his default YUY2 codec (in the registry, probably microsoft) to RGB. Now it is 0-255. So he sees different results in TMPGEnc. If he puts a ConvertToRGB24 at the end of his scripts, it probably does nothing to the RGB input (so it stays as 16-235) and it converts the YUV to RGB 0-255. So his results are the same using ConvertToRGB24 or letting the default codec convert to RGB.

I'm not sure if TMPGEnc really accepts YCbCr. You can test this with PIC. Under the advanced config of the codec you can check "Force YUY2 Output". If you can open some PIC YUY2 source in TMPGEnc with that checked, TMPGEnc is ok with YUY2. VirtualDub for example is not.

His comment about correct is not clear. PIC YUV input to Avisynth as RGB will be in the range 16-235. Same as PIC YUV avi input to TMPGEnc. In these cases I would check the box. That way TMPGEnc does not change the range.

I'm also wondering about this:
AVS and AVISource YUY2 = 0-219
How is this possible?

I don't think that is the case. Regardless, to back that up, one would have to say what the source is, and how it was determined that a shift occured. The codec would more be the suspect than AVS.


BTW: I did a few tests on PIC and tried to explain some other test results in the following thread.

http://forum.doom9.org/showthread.ph...0&pagenumber=1

[Arachnotron]

quote:
I'm also wondering about this:
AVS and AVISource YUY2 = 0-219
How is this possible?

I don't think that is the case. Regardless, to back that up, one would have to say what the source is, and how it was determined that a shift occured. The codec would more be the suspect than AVS.

This looks like 16-235 which has been given a new offset. substract 16 and you get 0-219.

[Kika]

His comment about correct is not clear.

OK, ok, it's my clumsy english...

PIC YUV input to Avisynth as RGB will be in the range 16-235. Same as PIC YUV avi input to TMPGEnc. In these cases I would check the box. That way TMPGEnc does not change the range.

Yes, that's what i wanted to say.

If i use YUY2 as Pixeltype, the Range isn't correct, if i use AVISource without the Pixeltype Statement, the Range also isn't correct. In both cases, this Shifting occurs (0-219). I think, that's a Bug of the Codec. Only with Pixeltype RGB24 i get the correct Luma-Range.
I said correct because the Captures are in YUY2 with the Range of 16-235, so that's what i need in AVIsynth and in TMPGEnc.

Checking the box should tell it that RGB source is in the 16,235 range and it should not change it.

Yes.

TMPGEnc only accepts RGB-Input. Without ConverttoRGB24() at the end of a Script, a System-Codec is used to convert to RGB. And on my maschine, this conversion is not distorting or clamping or compressing the Luma-Range.
BTW: Is there i way to determine which Codec is used to do this?

Edit:

This looks like 16-235 which has been given a new offset. substract 16 and you get 0-219.

Yes, that's what happens. It can be correct by this Line:
ColorYUV(off_y=16)

But i don't like this much. Every time, i use ColorYUV to correct anything, the Histogram shows me a slight distortion of the Levels.

[Arachnotron]

BTW: Is there i way to determine which Codec is used to do this?

look in the registry for

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]

"VIDC.YUV2"="?????????????"

(fill in your codec dll here)

[edit] default is msyuv.dll

[Kika]

Guess i have to try this at Home. On my PC here in the Office (Win98SE) there's no msyuv.dll.

At home (also Win98SE), i have deleted msyuv while the Testing.
Whatever, it works, that's what realy matters.