Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
10th February 2004, 17:53 | #1 | Link |
Registered User
Join Date: Feb 2003
Posts: 72
|
color adjust necessary in capture->SVCD?
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?
|
10th February 2004, 19:58 | #2 | Link |
budala
Join Date: Oct 2003
Location: U.S.
Posts: 545
|
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. |
10th February 2004, 20:11 | #3 | Link | |
Registered User
Join Date: Feb 2003
Posts: 72
|
Thanks. My procedure is: capture at PicMJPG(Q19), edit it in adobe premiere, then encode into SVCD (CCE) or VCD (TMPG).
Quote:
|
|
10th February 2004, 22:27 | #4 | Link |
budala
Join Date: Oct 2003
Location: U.S.
Posts: 545
|
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. |
10th February 2004, 22:41 | #5 | Link | |
Alias fragger
Join Date: Jul 2003
Location: the Netherlands
Posts: 863
|
In TMPEGEnc choose:
MPEG settings, Quantizise matrix tab, enable/disable "Output YUV data as Basic YCbCr not CCIR601" From the Help text: Quote:
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. |
|
11th February 2004, 05:59 | #6 | Link | |
Registered User
Join Date: Feb 2003
Posts: 72
|
I think Adobe only use RGB32, doesn't it?
Quote:
|
|
11th February 2004, 10:40 | #7 | Link | ||||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Quote:
Quote:
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 Quote:
|
||||
11th February 2004, 12:27 | #8 | Link |
Registered User
Join Date: Jul 2002
Location: Germany
Posts: 819
|
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. |
11th February 2004, 13:22 | #9 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
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. Quote:
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. |
|
11th February 2004, 13:53 | #10 | Link |
Registered User
Join Date: Jul 2002
Location: Germany
Posts: 819
|
@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? |
11th February 2004, 14:45 | #11 | Link |
budala
Join Date: Oct 2003
Location: U.S.
Posts: 545
|
I would have to humbly disagree with Wilbert's conclusions.
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. |
11th February 2004, 14:58 | #13 | Link | |
Alias fragger
Join Date: Jul 2003
Location: the Netherlands
Posts: 863
|
Quote from Kika:
Quote:
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) Last edited by Arachnotron; 11th February 2004 at 16:19. |
|
11th February 2004, 16:01 | #14 | Link | ||||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
What did you think about the first conclusion: Quote:
Quote:
"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: Quote:
Last edited by Wilbert; 11th February 2004 at 16:38. |
||||
11th February 2004, 16:21 | #15 | Link | ||
Registered User
Join Date: Jul 2002
Location: Germany
Posts: 819
|
Quote:
Quote:
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. |
||
11th February 2004, 17:03 | #16 | Link | ||||
budala
Join Date: Oct 2003
Location: U.S.
Posts: 545
|
Hi,
This is all a bit messy... but I'll try to be clear on what I think. Quote:
Quote:
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. Quote:
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 Last edited by trevlac; 11th February 2004 at 17:08. |
||||
11th February 2004, 17:20 | #17 | Link | |
Alias fragger
Join Date: Jul 2003
Location: the Netherlands
Posts: 863
|
Quote:
|
|
11th February 2004, 17:29 | #18 | Link | ||||
Registered User
Join Date: Jul 2002
Location: Germany
Posts: 819
|
Quote:
Quote:
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. Quote:
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: Quote:
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. Last edited by Kika; 11th February 2004 at 17:34. |
||||
11th February 2004, 17:37 | #19 | Link | |
Alias fragger
Join Date: Jul 2003
Location: the Netherlands
Posts: 863
|
Quote:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32] "VIDC.YUV2"="?????????????" (fill in your codec dll here) [edit] default is msyuv.dll Last edited by Arachnotron; 11th February 2004 at 17:44. |
|
11th February 2004, 17:49 | #20 | Link |
Registered User
Join Date: Jul 2002
Location: Germany
Posts: 819
|
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|