VideoHelp Forum
+ Reply to Thread
Results 1 to 17 of 17
Thread
  1. Member
    Join Date
    May 2005
    Location
    San Diego, CA
    Search Comp PM
    I captured some old VHS tapes using my Canon Elura 50 camcorder and PC (type-2 dv). I then compressed the dv with HuffyUV making sure the video color depth in VirtualDub was set to 'Autoselect' on both the decompression and output format side.

    I then created an AviSynth script to display the color space (Info() method) and YUV details (ColorYUV(analyze=true) method) of the resulting AVI file and it did indeed say the color space was YUY2. I am confused about the luma/chroma information displayed by AviSynth though. It says the minimum lumaY value is 0. Shouldn't it be 16? If I convert the avi to RGB and then back to YUY2 the minimum luma value does change to 16.

    Also, I read the following line in a FAQ on doom9:

    If you feed a YUY2 file into VirtualDub or TMPGEnc, it will be converted to RGB before it gets there.
    Is this still true? There is a specific option in VDub for which decompression color space you want to use and the information displayed about the file in VDub says the file is YUY2.

    Finally I read in a post on another forum that the different DV codecs can affect color space. According to GSpot the decompression codec I am using is 'dsvd - DVC/DV Video' but I can't find any color space information on this codec. I want to find out how it reads luma/chroma information. I think this is just the standard Microsoft DV codec.

    Thanks for your help![/quote]
    Quote Quote  
  2. You have two issues:

    The standard Microsoft DV codec won't work with VirtualDub because VirtualDub uses VFW, not DirectShow. Panasonic DV Codec always decodes to RGB and has bugs that can cause system problems. It performs the usual YUV to RGB luma expansion which loses blacker-than-black (luma < 16) and whiter-than-white (luma > 235) portions of the video. Cedocida is the most configurable VFW DV codec I know of. You can control whether it decodes to RGB, YUY2, YV12, etc. You can also control whether it performs the YUV to RGB luma exapansion. VirtualDub has its own DV decoder but you have to enable it. Options -> Preferences -> AVI -> Prefer internal codecs... I believe it performs the YUV to RGB luma expansion. You can verify which decoder is being used by selecting File -> File Information in VirtualDub.

    I'm not sure how the new colorspace modes in VirtualDub work. It does appear that a YUY2 source can be converted to HuffUV without YUV->RGB->YUV conversion.

    For certain, if you used a DV decoder that decoded to YUY2 and used Fast Recompress mode, the YUY2 data was passed directly to the encoder (assuming it accepts YUY2 input). This is what you want to do.

    Download the VideoScope plugin for AviSynth. It gives you a nice graph of luma levels in your YUY2 source. Open your original DV AVI file and compare levels to your YUY2 file.

    AviSource("file.avi")
    VideoScope()

    DV camcorders rarely produce blacker-than-black but it's very common for them to have a lot of whiter-than-white.
    Quote Quote  
  3. When ever YUV to RGB conversion occurs, there is a high likelihood that something will be calculated incorrectly. Too many decoders use the wrong equations resulting in what you have experienced.

    Certainly, the DV data are 4:1:1 with a 16 - 235 range.

    The only reliable way to avoid the problem is to use codecs that can work with the original YUV data.

    Do you know if HuffyUV does in fact keep everything in the YUV colorspace and that it doesn't (incorrectly) stretch the data to 0 - 255?
    Quote Quote  
  4. Originally Posted by JohnnyMalaria
    Do you know if HuffyUV does in fact keep everything in the YUV colorspace and that it doesn't (incorrectly) stretch the data to 0 - 255?
    If HuffYUV is fed YUY2 video it is compressed without any other manipulation. There is an option to "suggest" RGB output on decompression though. When this is selected I assume HuffYUV will decompress to RGB unless the calling program won't accept it.
    Quote Quote  
  5. Member
    Join Date
    May 2005
    Location
    San Diego, CA
    Search Comp PM
    Captured AVI in VDub says 'Internal DV decoder (dvsd)' in file info.

    Compressed HuffyUV AVI in VDub says YCbCr 4:2:2 (YUY2) in file info.

    So it looks like VDub is correctly doing the compression to HuffyUV using YUY2 but I am still wondering why the lumaY range starts at 0 for a YUY2 color space.

    I installed the VideoScope plugin and the took a look at a frame in two cases.

    The first case I simply opened the HuffyUV AVI and looked at the VideoScope. It shows luma data starting at 0 (there are dots all the way up/down the spectrum.

    Next I modifed the script to call ConvertToRGB and then ConvertToYUY2. This time it shows the luma data being clipped around what i think is the 20 mark. (See picture)

    withrgb.png

    Can someone explain what is happening here? I am still not understanding when things are converting to RGB behind the scenes.
    Quote Quote  
  6. Originally Posted by binister
    Captured AVI in VDub says 'Internal DV decoder (dvsd)' in file info.

    Compressed HuffyUV AVI in VDub says YCbCr 4:2:2 (YUY2) in file info.

    So it looks like VDub is correctly doing the compression to HuffyUV using YUY2
    Not necessarily. If you feed HuffYUV RGB video it may convert it to YUY2 (depending on the settings).

    Originally Posted by binister
    but I am still wondering why the lumaY range starts at 0 for a YUY2 color space.

    I installed the VideoScope plugin and the took a look at a frame in two cases.

    The first case I simply opened the HuffyUV AVI and looked at the VideoScope. It shows luma data starting at 0 (there are dots all the way up/down the spectrum.

    Next I modifed the script to call ConvertToRGB and then ConvertToYUY2. This time it shows the luma data being clipped around what i think is the 20 mark. (See picture)

    withrgb.png

    Can someone explain what is happening here? I am still not understanding when things are converting to RGB behind the scenes.
    The default for ConvertToRGB() is to expand the luma range from 16-235 to 0-255. The reverse, ConvertToYUY2(), will compress the luma range from 0-255 back to 16-235. Blacks and whites will be clipped but the middle ranges will stay about the same (only rounding errors).

    Examine your DV source and you HuffYUV file and compare the graphs. The only part of your video that looks like it might be going below IRE 0 (luma 16) is the black bar at the far right. It looks like Whites are clipped though.

    Here's a sample where whites where clipped at IRE 100 by YUV->RGB->YUV conversion. Source on the left, clipped in the right:



    Note that this sample image was exported from VirtualDub. The two video frames look identical because VirtualDub converted the YUY2 video to RGB before exporting the image. So the unclipped peaks in the source were clipped by the export process. The luma graph was generated by AviSynth before the video was given to VirtualDub so the graphs accurately represent the video files.
    Quote Quote  
  7. Member
    Join Date
    May 2005
    Location
    San Diego, CA
    Search Comp PM
    Here is the graph of the HuffyUV AVI without any conversions/filters. GSpot and Vdub both tell me it is using the YUY2 color space however if you look at the VideoScope you can see the whites definitely don't start at 16. That is what I don't understand.

    How can a YUY2 color space AVI that was from a VHS source have a minimum luma value of 0?

    Could the capture process that the camcorder used expanded the color range?

    Is there any way to find out what color space the raw DV AVI file is using? I can't open it with AviSynth unless I use DirectShowSource and I am not sure if that changes the color space.

    withoutrgb.png

    Thanks for your help and information.
    Quote Quote  
  8. It's not impossible for a video to have luma below 16. In fact, the problem with your capture is that the black level isn't low enough and the white level is a bit too high. It's common for VHS decks to have those sorts of problems. And DV camcorders often don't have dark enough black levels (my older Canon Optura PI has this problem).

    Try adding ColorYUV(off_y=-40, gain_y=40) to your script (before VideoScope). That will give you something like this:



    To open DV files with AviSynth's AviSource() you need a VFW DV decoder. Install Cedocida, force it to decode only to YUY2, and you will be able to open the original DV file with AviSynth.
    Quote Quote  
  9. Always Watching guns1inger's Avatar
    Join Date
    Apr 2004
    Location
    Miskatonic U
    Search Comp PM
    If you don't apply any filters in virtualdub then you can use fast recompress, which should preserve the colourspace of the source (assuming you encode using a codec that allows the same colorspace).

    Also, the current version of virtualdub can load DV natively without having a VFW codec installed.
    Read my blog here.
    Quote Quote  
  10. Originally Posted by guns1inger
    If you don't apply any filters in virtualdub then you can use fast recompress, which should preserve the colourspace of the source (assuming you encode using a codec that allows the same colorspace).
    This isn't quite true. It depends on what the decoder outputs. For example, Panasonic DV codec always outputs RGB. So even fast recompress mode in VirtualDub will involve a YUV to RGB conversion. One of the nice things about Cedocida is that you can force it to output exactly what you want:

    Quote Quote  
  11. Always Watching guns1inger's Avatar
    Join Date
    Apr 2004
    Location
    Miskatonic U
    Search Comp PM
    Originally Posted by jagabo
    Originally Posted by guns1inger
    If you don't apply any filters in virtualdub then you can use fast recompress, which should preserve the colourspace of the source (assuming you encode using a codec that allows the same colorspace).
    This isn't quite true. It depends on what the decoder outputs. For example, Panasonic DV codec always outputs RGB. So even fast recompress mode in VirtualDub will involve a YUV to RGB conversion. One of the nice things about Cedocida is that you can force it to output exactly what you want:

    Hence my caveat

    Originally Posted by guns1inger
    (assuming you encode using a codec that allows the same colorspace)
    Read my blog here.
    Quote Quote  
  12. Originally Posted by guns1inger
    Also, the current version of virtualdub can load DV natively without having a VFW codec installed.
    Does that mean that virtualdub has its own DV decoder or that it uses the DirectShow one?
    Quote Quote  
  13. I think you're still missing the point. Using Panasonic DV codec to decode DV will always produce RGB. No matter what mode you use in VirtualDub, or what codec you use to compress the video again, even if you go back to DV, you will have converted YUV to RGB and lost dark and light detail.
    Quote Quote  
  14. Always Watching guns1inger's Avatar
    Join Date
    Apr 2004
    Location
    Miskatonic U
    Search Comp PM
    Originally Posted by JohnnyMalaria
    Originally Posted by guns1inger
    Also, the current version of virtualdub can load DV natively without having a VFW codec installed.
    Does that mean that virtualdub has its own DV decoder or that it uses the DirectShow one?
    I don't know which it uses. I have recently installed it on a machine that has no VFW DV decoder and opened DV avi files without issue. When I do a File -> File Information it says

    Decompressor : Internal DV Decoder (dvsd)

    which would seem to be saying it now has it's own built in decoder. It does not have a built-in encoder for DV output.

    Originally Posted by jagabo
    Using Panasonic DV codec to decode DV will always produce RGB
    Yes, you are right about this. However the latest version doesn't require the Panasonic vfw codec to open DV files, which may get around this issue. I tried the Cedocida codec in the past, but it only ever crashed for me, or produced output that nothing else would open. That was a while back though, so perhaps it's better now.
    Read my blog here.
    Quote Quote  
  15. Originally Posted by guns1inger
    (VirtualDub)When I do a File -> File Information it says

    Decompressor : Internal DV Decoder (dvsd)

    which would seem to be saying it now has it's own built in decoder. It does not have a built-in encoder for DV output.
    Yes, that means it's using the internal DV decoder. If it was using another decoder it would have given the name of the decoder. For example "Cedocida DV codec (SD format) v0.2.0"

    I just checked the behaviour of the internal DV decoder. With Color Depth set to Autoselect, it appears to decode to a YUV format (no indication of whether it's YUY2, UYVY, or whatever), even in Full Processing mode. As long as you don't apply any filters that YUV data is passed to the output codec (assuming the codec accepts it).

    Originally Posted by guns1inger
    I tried the Cedocida codec in the past, but it only ever crashed for me, or produced output that nothing else would open. That was a while back though, so perhaps it's better now.
    I never had it crash but Cedocida did have some bugs a year or two ago. It seems to be very stable and bug free now.
    Quote Quote  
  16. Member
    Join Date
    May 2005
    Location
    San Diego, CA
    Search Comp PM
    Ok, it is becoming more clear to me now.

    It sounds like VHS and DV can contain signals outside of the standard NTSC SD Rec-601 16-235 range (superwhites and superblacks). These signals when viewed on a regular SD tube television would simply crush.

    Viewing a videoscope of these signals after capture does confirm their presence even though they are technically "outside" of the allowed range for NTSC broadcast. The result is I have a DV file with a YUY2 color space that contains superwhites and superblacks.

    I have confimed this with both VHS captures through my camcorder and with DV footage taken with my camcorder.

    I had mistakenly thought that all Rec-601 compliant captured VHS and DV video could not have luma values outside of 16-235.

    So, now that I know I have DV with superwhites and superblacks I have to decide what to do with them. Since my ultimate destination format is DVD it sounds like those values will eventually be clipped anyway. Do I have any other options?
    Quote Quote  
  17. Originally Posted by binister
    It sounds like VHS and DV can contain signals outside of the standard NTSC SD Rec-601 16-235 range (superwhites and superblacks).
    Yes.

    Originally Posted by binister
    These signals when viewed on a regular SD tube television would simply crush.
    Superblacks will usually crush. Superwhites may still show some detail. All depending on the TV and its brightness and contrast settings.

    Originally Posted by binister
    So, now that I know I have DV with superwhites and superblacks I have to decide what to do with them. Since my ultimate destination format is DVD it sounds like those values will eventually be clipped anyway. Do I have any other options?
    Many MPEG2 encoders have the option of clamping the luma to the 16-235 range. Obviously, you want to make sure that most of your video falls within that range before encoding.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!