Does anyone know if this option need to be checked (ticked) in the encoding software when transcoding miniDV footage to DVD (mpeg2)?
Is miniDV RGB 16-235?
+ Reply to Thread
Results 1 to 25 of 25
I think the answer is NO.
miniDV is YUV 4:1:1.
Is there a difference between RGB 16-235 and RGB 16-255?
MiniDV is internally YUV 16-235. What your encoder gets depends on what DV decoder you are using. Some output YUV 16-235, some RGB 0-255. It's possible for a DV decoder to output RGB 16-235. Cedocida has that option.
Thank you jagabo, you always come to the rescue.
The file was outputted from Avid using the RGB option. I just can't figure out if it was outputted using 16-235 or if I should tick the option on Sorenson Squeeze that says: "input video is RGB16-256". MediaInfo does not tell me the color space when I open the file in it.
Do you know if I should tick the option or leave it unticked as it is by default?
DV video is nominal YCbCr 16-235 but with overshoots up to 255. Pro camcorders manage to these levels.
Consumer DV cams usually cheat levels to 16-255 nominal to show better S/N and low light performance but also show more clipping at 255 and appear brighter overall vs pro DV. To adjust to standard levels, consumer camcorder source needs nominal white adjustment down to 235. Best way to determine this on your AVID "_" is to use the scopes and proc amp features.
Normal DV/DVD/DVB/ASTC/Blu-Ray encoding has black at 16 and nominal white at 235 with overshoots to 255. If you decide to encode 0-255 with 16 mapped to 0 and 235 mapped to 255 for some reason, expect consumer camcorder video whites to blow out (e.g. clouds disappear from the sky).
Most software editors convert everything to RGB for filtering. For definition, normal computer RGB is scaled 0-255 with black at zero and white at 255. All Rec.601/Rec.709 formats are YCbCr 16-235. Pro edit software use so called 16-235 "Studio RGB" conversion formulas which preserve sub black and super white so that 16-235 in to 16-235 out suffers no clipping. You should be running your AVID with Studio RGB.
Post some representative original video (not Youtube) that contains both black and white in the scene. You could do this with a screen caps using software that preserves levels such as VLC snapshot.
I posted a DV AVI with a levels test pattern here:
The video has YUV levels from 0 to 255. The levels below 16 and above 235 should be lost when converting to RGB 0-255.
edDV, thank you for the explanation. The source was shot on a Panasonic DVX 100 at 24p on Master miniDv/HD tapes so I am assuming it would fall under the pro category. I am uploading 3 screenshots. Is it possible to determine if they are RGB 16-235 or 16-256. I am transcoding to mpeg 2 so the playback media is DVD.
In answer to your question if I know what exporting from Avid ticking the RGB does the answer is no, but ticking RGB makes the footage look closer to what I have in the editing software. The other option, 601/709 makes the color look too washed out.
jagabo, I think I understand. I guess encoding a 16-235 to 16-256 couldn't hurt either way right? I mean if the info is not there it's not but true blacker than black would not happen in either case since there is no 0-256 option in my encoder?
You guys are doing a great job at educating me I just have such a hard time making heads or tail of the whole thing. I wish there was a guide that said, here are all the settings to make perfect miniDV source into a DVD.
...and by the way, to top it all off, the source was heavily color corrected in Avid to achieve a particular look ...and the color correction was done in RGB mode (I think).
Your screenshots are labelled "VLC" . VLC will use Rec601 for the conversion. This means Y' 16-235 => RGB 0,0,0 - RGB 255,255,255 . This means both ends (superwhites and superdarks) are clipped . I'm 100% certain the DVX-100 records superwhite data. (Y' 235-255) . This is called a "limited range RGB conversion" . The "studio RGB" conversion that edDV talked about earlier would map the values differently. This would be called a "full range RGB conversion". This would specify Y'CbCr 0-255 => RGB 0,0,0 - 255,255,255
But if you are asking if the screenshots are RGB 16-235 , then yes you can determine that easily. The answer is no. You would use a RGB histogram in your editing program (or even photoshop or gimp). But you know that already, because you used VLC to take the screenshots - you don't even have to use a histogram. It contains values RGB 0,0,0 - 255,255,255 because of the Rec601 conversion.
Here is the problem. If you have a RGB format, you have to convert BACK to Y'CbCr if you are going to DVD . It's the Y'CbCr <=> RGB conversions that cause problems and different programs do it differently. Legal range DVD contains values Y' 16-235, CbCr 16-240 . Small overshoots and undershoots are perfectly acceptable. That is why those values were chosen in the first place.
Thank you poisondeathray, so in the transcoder (Squeeze), would you say that I have to tick (select) the option: "input video is RGB16-256"? or not?
If I understand correctly what you have said I think not. Am I right? Or is this dependent not on the source but on what I exported from Avid?
What you want is for the resulting MPEG file to have Y values from 16 to 235. You want your blackest blacks to be at Y=16, and your brightest brights to be at Y=235 (except for a few overshoots). You want to correct your levels while they are still in YUV. Unless you can convince your software to work in studio RGB (RGB 16-235) rather than computer RGB (RGB 0-255). If you work in studio RGB you need to tell your encoder the RGB data it's getting is studio RGB.
You should use a YUV waveform monitor to examine your video before it's been converted to RGB.
Optimally, if you used the levels DV AVI file I posted earlier, you should be able to preserve the super blacks and super whites on conversion to MPEG. That way you'll know that whatever processing your're doing isn't crushing them. And, if necessary you can recover detail in those areas by adjusting the levels.
In case it's not clear: that DV AVI file has illegal levels (Y<16, Y>235) intentionally -- for testing what happens during your editing. If your camcorder was routinely producing those illegal levels you would adjust them to fall in the 16 to 235 range. Otherwise they would be crushed during playback.
Generally, one can't tell you anything about YUV levels from looking at JPG files because the video has already been converted to RGB. Without knowing exactly how that conversion was done one can't say what the original YUV levels were. But in this case we know you used VLC and that VLC always uses the rec.601 matrix which expands the Y=16-235 range to RGB=0-255. The JPG images have a full range of RGB=0-255 (meaning the original Y ranged from at least 16-235) and the brights and darks don't appear to be horribly clipped so I suspect your camcorder is producing Y=16-235 (not over bright brights like many consumer camcorders).
You should post short unadulterated DV samples instead of JPG files. VirtualDub or AviDemux in copy mode are useful for this.
Last edited by jagabo; 31st Jul 2011 at 08:34.
What you really want to know is if your final MPEG2/DVD is "legal". If you want to quickly determine, just do some tests. Try checkmarking that option on a small sample, and uncheckmarking that option, look at Y' levels in a waveform monitor for the output MPEG2.
Thank you guys. I see this is not a black or white issue ....I mean it is a black and white issue but there is no definite answer
I exported as a Quicktime Reference so the file is pointing to the source material (no transfer there). I will do what poisondeathray said and test on a tiny file and then inspect it in a wavefrom monitor.
Where may I find a waveform monitor?
Also the answer is no to the dv encoder question, Squeeze does not use the system installed DV encoder, it uses the MainConcept encoder.
Procoder was causing an issue with chroma subsampling so I had to switch to Squeeze https://forum.videohelp.com/threads/337152-What-happened-to-the-orange-cone-Vertical-Li...ds-and-oranges
I was unable to fix that issue, squeeze does not have the issue but in turn provides a lover quality output. Strange is the world of digital video when you know so little about what behind the image
I'm not sure what the three attached VLC caps represent but the first looks like good 16-235 levels. The Vegas Pro scope is set for DV project format (zero=16 and 100=235).
The other two files show and expansion to 0-255. If encoded directly as is, these would show crushed blacks and possibly clipped whites.
Thank you very much for doing this for me.
If it was up to you would you select "the input video is RGB16-256" in your transcoder/encoder?
Thank you edDV. I really appreciated your help with this. I will follow your advice.
Hope one day to be able to return the favor
Those pictures are made from RGB conversions of your original YUV videos. Without knowing exactly how those RGB conversions were made looking at the pictures doesn't tell you exactly what is in the source video or what settings you should use in your editor.
Since they were made with VLC it's likely the frames have gone through the usual rec.601 conversion which stretches Y=16-235 to RGB-0-255. Since there doesn't appear to be a lot of clipping at the top (255) and bottom (0), the DV source is probably 16-235. But your editor may not be using the same YUV to RGB transform.
Post un-reencoded samples of your DV AVI files. That's the only way anyone can tell you exactly what you have. Once we know what your camera is producing we can address what settings to use in your software.
Last edited by jagabo; 1st Aug 2011 at 17:33.
Also show the export as well as the camcorder original for the same shot. That way we can see what levels changes occurred during editing/filtering. Best to do this before color correction but we can deal with either.
If your editor doesn't have a luma graph feature you can use AviSynth:
Histogram() is a little easier to read because it marks the super-black and super-white areas of the graph with brownish bars. If you would rather have the traditional horizontal graph use TurnRight().Histogram().TurnLeft(). That will give you a horizontal graph at the top of the frame.
For these sample images I opened your JPG file and converted the RGB data back to YUV using a rec.601 matrix so we shouldn't see anything in the illegal areas. That doesn't mean your original source didn't have anything in those areas because we don't know for sure how your source YUV video was converted to RGB for the JPG images.
Last edited by jagabo; 2nd Aug 2011 at 07:54.
Thank you jagabo.
This is something I will have to be more aware of from now on when I start another project. I had no idea capture settings had an effect on the original source so I never even tweaked them but I guess they do and now I know.
That's what I thought but for some reason your reply let me to believe there was such a thing as capture setting. I'm sure I misunderstood you.
The point I was trying to make is that some DV camcorders routinely record with incorrect levels. My old Canon DV camcorder never has anything below Y=32 but routinely has brights up to Y=255 -- which does not match the digital video spec of 16-235. You would treat that differently than a camcorder that always shoot with Y from 16-235 or 16-255.
The Panasonic DVX 100 with auto settings should manage luma levels to 16-235 but white level may vary using manual exposure controls. Bright lights, reflections and bright sky may extend into the 236-255 range.