Captured S-VHS format

[Rinsin]

I've captured S-Video from my JVC VHS player via my ATI X1900XT card. The source is interlaced 4:3 PAL (PAL_I) and I captured to 720 x 576. I used HuffYUV in RGB mode. But I understand if I want to encode via HCenc I need YV12.

1. If I convert this capture to YV12, would I lose any appreciable quality? What would be the best way to do this?

2. Is there a way that I could capture by source again, but directly to YV12? Would there be any drawbacks Vs capturing to RGB?

3. I may want to run some filters on the captured file prior to frameserving ... does this affect the answers to 1 or 2?

I have access to a DV cam with pass-through if that helps.

Cheers

[themaster1]

henc don't accept yuy2 ? weird.
if you capture in rgb mode with huffyuv then there is YUV>RGB convertion, not a big of a deal but still you wanna avoid this scheme as much as possible.

Anyway virtualdub work in rgb too so i guess that's non issue here.

You will have to fix the luma range though with the LEVELS filter to get it back to 16-235 IRE (rgb is 0-255 which means images are darker essentially).

[jagabo]

HuffYUV can compress in the RGB domain. But capturing RGB is usually the wrong thing to do. Video is natively YUV and usually the best format to capture in is YUY2 (or similar 4:2:2 encoding). This is typically what capture cards capture as. If you specify RGB the YUY2 is converted to RGB in software on the fly. Converting to RGB will usually lose the darkest and lightest shades (video isn't supposed to have Y below 16 or higher than 235 but often does) because most programs (VirtualDub for instance) stretch the luma range from 16-235 to RGB 0-255. That usually isn't a problem for VHS from what I've seen. Luma in VHS rarely goes below 16 or above 235 and in fact the range is usually more like 32 to 200 (necessitating a levels adjustment). This will vary depending on your equipment.

Most programs that convert from RGB to YUV will perform the luma compression to get RGB 0-255 down to luma 16-235. So if you're adjusting levels in VirtualDub you usually want the RGB range to be from 0 to 255.

Depending on what your source was, converting from YUY2 (or RGB) to YV12 will lose some vertical resolution (as the YV12 chroma channels are only half the resolution of the luma channel on both the horizontal and vertical axis). But there's no avoiding this if you are going to make a DVD.

VHS is an interlaced medium so be sure to treat your video as interlaced even if the frames appear progressive (as is often the case with PAL movies). There is a difference in the way chroma channels are handled and treating the frames as progressive will cause even more blurring of the colors. So capture interlaced, perform any filtering with interlace aware filters, and encode as MPEG 2 as interlaced.

HcEnc likes YV12 input from AviSynth scripts. The simplest way to get your interlaced RGB video to YV12 in AviSynth would be:

AviSource("filename.avi")
ConvertToYV12(interlaced=true)

Then encode as interlaced MPEG2 for DVD.

[2Bdecided]

A good post IMO jagabo, apart from this bit...

VHS is an interlaced medium so be sure to treat your video as interlaced even if the frames appear progressive (as is often the case with PAL movies). There is a difference in the way chroma channels are handled and treating the frames as progressive will cause even more blurring of the colors. So capture interlaced, perform any filtering with interlace aware filters, and encode as MPEG 2 as interlaced.

That's just wrong. Yes, it's important to use interlaced chroma for interlaced content, and highly beneficial to use progressive chroma for progressive content, but...

Capture a PAL movie from VHS, stitch the fields together into frames, and you have a progressive image.

So you'd capture 4:2:2 (interlaced or progressive doesn't matter here), and convert entire frames (not individual fields) to progressive YV12.

If you used interlaced chroma, the picture would actually be slightly softer in this case. Not a big deal with VHS (it's very soft horizontally, and there's usually some filtering vertically), but you'd be adding even more chroma blur by using interlaced chroma on a progressive source.

Cheers,
David.

[2Bdecided]

henc don't accept yuy2 ? weird.

Not weird at all. YV12 is the only format supported by DVD and main profile MPEG. HCenc expects you to do the conversion correctly in tools suited to the job.

(Though I think I heard a whisper about 4:2:2 support in an upcomming version of HCenc - might be mistaken! Either way, you can't put 4:2:2 MPEG on a DVD)

Cheers,
David.

[Rinsin]

Thanks (especially to jagabo!); I'm running a new capture in YUY2 now. I'm also going to bite the bullet and learn Avisynth (or as much as I can). I've got a couple more things you might be kind enough to clear up for me :

1. When capturing via Vdub and my GFX card, I'm getting zero dropped frames but a few hundred inserted frames (using default timing settings) for a 2-hour tape. Audio seems to stay in sync. Is this a bad thing? Would capturing via pass-through/firewire be likely to be better in the long run?

2. I'll be doing a 2-pass encode in HCenc. I assume it is beneficial to keep the number of colour space conversions down. With this in mind, and assuming I want to run some filters (via Avisynth) on some captures:

a) should I be looking to only use YUY2 filters? If so, can you recommend any which could be used to (i) tweak colours / levels; and (ii) remove some moderate noise (like Neat Video)?

b) would it actually be better to apply these filters before running through Avisynth (assuming this is possible)? Perhaps Vdub can be used to apply the filters losslessly, thereby saving encoding time later? I have lots of disk space.

If any of the above questions are completely stupid, feel free to tell me (it seems there's a steep learning curve)!

[jagabo]

VHS is an interlaced medium so be sure to treat your video as interlaced even if the frames appear progressive (as is often the case with PAL movies). There is a difference in the way chroma channels are handled and treating the frames as progressive will cause even more blurring of the colors. So capture interlaced, perform any filtering with interlace aware filters, and encode as MPEG 2 as interlaced.

That's just wrong...

You are right. VHS movies captured as YUV 4:2:2 would not normally have interlaced chroma channels.

[jagabo]

1. When capturing via Vdub and my GFX card, I'm getting zero dropped frames but a few hundred inserted frames (using default timing settings) for a 2-hour tape. Audio seems to stay in sync. Is this a bad thing?

I'm not sure. I haven't done much capturing with VirtualDub because it hasn't worked with most capture devices I've had over the years. I think the capture device is occasionally missing the vertical sync pulse from the tape and VirtualDub is substituting frames to make up for it. You might try looking through the captured video and look for duplicate frames during motion. But it might be hard to find given 200 frames in a 2 hour video is roughly an error every 2000 frames.

Do the substitute frames appear at regular intervals or randomly and/or in spurts?

Would capturing via pass-through/firewire be likely to be better in the long run?

That probably depends on what device you're using.

2. I'll be doing a 2-pass encode in HCenc. I assume it is beneficial to keep the number of colour space conversions down. With this in mind, and assuming I want to run some filters (via Avisynth) on some captures:

a) should I be looking to only use YUY2 filters? If so, can you recommend any which could be used to (i) tweak colours / levels; and (ii) remove some moderate noise (like Neat Video)?

If I remember correctly, conversion back and forth between YUY2 and YV12 in AviSynth is lossless beyond the first conversion from YUY2 to YV12. Ie, you lose half the vertical chroma resolution on the fist conversion from YUY2 to YV12, but then converting back to YUY2 and back to YV12 gives exactly the same result as the fist conversion to YV12. I believe the same is true for RGB.

b) would it actually be better to apply these filters before running through Avisynth (assuming this is possible)? Perhaps Vdub can be used to apply the filters losslessly, thereby saving encoding time later?

It's best to use an analog proc amp before capturing. Filtering while capturing should give the same quality as filtering later if you stick with YUY2 throughout. But you run a grater risk of dropping frames. Of course, VirtualDub does all it's filtering in RGB so you would lose precision there.

One AviSynth filter you should get is VideoScope(). It shows an occilliscope image around your video so it's easy to check levels.

I usually use ColorYUV() to adjust levels and colors. Tweak() is useful too. There is no equivalent of Neat Video for AviSynth. But it is possible to use Neat Video in AviSynth. That involves converting to RGB but if you adjust your levels first that's no big deal considering how much Neat Video is going to do for you.

[T-Fish]

Thanks (especially to jagabo!); I'm running a new capture in YUY2 now. I'm also going to bite the bullet and learn Avisynth (or as much as I can). I've got a couple more things you might be kind enough to clear up for me :

1. When capturing via Vdub and my GFX card, I'm getting zero dropped frames but a few hundred inserted frames (using default timing settings) for a 2-hour tape. Audio seems to stay in sync. Is this a bad thing? Would capturing via pass-through/firewire be likely to be better in the long run?
!

the only times i had inserted frames was when the signal errm "froze" for a second. you know those darn interference bars
that can occur on an old vhs tape. its certainly not ideal, but sometimes not avoidable in my experience.
now dropped frames on the other hand, should never occur as that would indicate a problem on the capture side. (having to slow a pc e.g.)

[Rinsin]

OK, I've talked myself into another little corner

I think I may have to use filters in Vdub rather than Avisynth. I understand all Vdub filters work in RGB24. My source is S-Video VHS. My final destination is DVD i.e YV12 via HCenc/AVStoDVD. In the compression options in Vdub when capturing Huffyuv its says:

YUY2 compression method RGB compression method
- predict left - predict left/no corr
- predict gradient - predict left
- predict median - predict gradient
- CONVERT TO YUY2

[ ] Always suggest format for RGB output.

- - - - - - - - - - - -

1. Which options do I choose to capture as YUY2? Which do I choose to capture as RGB?

2. If I choose to capture as RGB how do I know my card isn't first capturing as YUY2 and then converting to RGB? If I choose to capture as YUY2 how do I know my card isn't first capturing as RGB and then converting to YUY2?

3. Which of these will offer best quality output:

capture RGB24 --> filter in Vdub saving as avi (presumably RGB24?) --> load to AVStoDVD and let it convert to YV12

or

capture YUY2 --> filter in Vdub saving as avi (presumably YUY2?) --> load to AVStoDVD and let it convert to YV12

Surely the latter option will have more colour space conversions and therefore be worse? But I recall reading that it is always best to capture as YUY2 as this is closest to S-video source?


Thanks again ... once I've nailed this I think my workflow is finalised.

[themaster1]

just keep it yuy2 and choose predict left for realtime encoding

[jagabo]

1. Which options do I choose to capture as YUY2? Which do I choose to capture as RGB?

To capture and save as YUY2 set your capture card to capture as YUY2 then in the "YUY compression Method" section pick any of the three options. The fastest one gives the least compression, the "best" one gives the best compression but is slowest. If your computer is fast enough use the "best" option.

If you want to caputure and save as RGB set the capture device to capture as RGB then select the RGB compression method in HuffYUV. The options are similar to the YUY2 options except for the addition of "Convert to YUY2" which converts the RGB data to YUY2 and compresses using whatever YUY2 method is selected.

2. If I choose to capture as RGB how do I know my card isn't first capturing as YUY2 and then converting to RGB? If I choose to capture as YUY2 how do I know my card isn't first capturing as RGB and then converting to YUY2?

Analog video consists of a luma channel (Y) and two chroma channels (U and V) at half (or less) resolution, YUV 4:2:2. As far as I know, every card captures as YUY2 (or some other variation of YUV 4:2:2 -- just differences in the order of the Y, U, and V components) then the video is converted to RGB if requested.

3. Which of these will offer best quality output:

capture RGB24 --> filter in Vdub saving as avi (presumably RGB24?) --> load to AVStoDVD and let it convert to YV12

or

capture YUY2 --> filter in Vdub saving as avi (presumably YUY2?) --> load to AVStoDVD and let it convert to YV12

Surely the latter option will have more colour space conversions and therefore be worse? But I recall reading that it is always best to capture as YUY2 as this is closest to S-video source?

Although YUV/RGB conversion is lossy, with the exception of the very darkest and lightest shades (both of which shouldn't appear in a proper video source) the losses aren't visible and at levels lower than the inherent noise in the video source. The biggest issue with YUV to RGB conversion is to make sure you don't lose luma below 16 and above 235.

If I had to use VirtualDub filters I would do this:

1) Capture as YUY2 with HuffYUV. This gives you a source that is a close to the original video as possible.

2) Open that video in VirtualDub indirectly through an AVISynth script. Adjust the levels within AviSynth using ColorYUV() and VideoScope(). Once you have the levels adjusted remove the VideoScope() filter.

3) Perform whatever filtering you need in VirtualDub. Then save with HuffYUV in RGB mode.

You can avoid the ColorYUV() filter in AviSynth and not lose dark and light shades in VirtualDub by converting to RGB without the usual contrast expansion with ConvertToRGB(matrix="PC.601"). But then you must adjust the levels within VirtualDub, Blacks to 0, whites to 255.

And if you're confident your source doesn't have luma below 16 or above 235 (you can check for this with VideoScope()) you can just open the HuffYUV AVI file directly with VirtualDub.

[Rinsin]

Thanks for the informative post again jagabo ... one more thing ... how do I "set" my graphics card (ATI Radeon X1900XT) to capture as YUY2 or RGB? I have catalyst control centre installed but I can't find any such option.

[jagabo]

Thanks for the informative post again jagabo ... one more thing ... how do I "set" my graphics card (ATI Radeon X1900XT) to capture as YUY2 or RGB? I have catalyst control centre installed but I can't find any such option.

I don't know that card but the option is usually set in the capture program. In VirtualDub, when in capture mode, select Video -> Set Custom Format...

[Rinsin]

I'm beginning to get the hang of this now! Does ColorYUV() work in YUY2 mode or require a convert to YV12?

[jagabo]

ColorYUV() works in both YUY2 and YV12.

[zoobie]

oh brother...
I thought that was the purpose of this site...

[Rinsin]

OK, some more help needed please

I have my YUY2 captured avi. When opened via the avisynth script in VdubMod, the levels do not seem to need adjusting (a small adjustment pushes pixels into the brown bands on either side).

I don't really understand what I'm doing with ColorYUV. I am using ColorYUV(Analyze=True) and I can see the range is 0-255.

If I use ColorYUV(levels="PC->TV") the colours looked washed out on my PC. I can't really detect that ColorYUV(opt="coring") does anything. I've read http://www.doom9.org/index.html?/capture/postprocessing_avisynth.html but there isn't really enough for me to understand what I should be doing at this stage. I don't know what I should be "aiming for" with the green and purple wfms.

Hence I'm now puzzled.

From here I want to run Neat Video (I can either do that in Vdub directly or via an avisynth script) - whichever offers the best result is fine for me. Neat Video only runs in RGB32 mode. I don't know if this is significant ... is this where the "bad" changes can happen which I need to be protecting against? I note ColorYUV doesn't work if I do a ConvertToRGB32().

I then want to pass to Hcenc to encode to DVD.

[jagabo]

I have my YUY2 captured avi. When opened via the avisynth script in VdubMod, the levels do not seem to need adjusting (a small adjustment pushes pixels into the brown bands on either side).

I'll go into more detail later, but...

What are these "brown bands" you refer to?

<edit>
Ah, the Histogram() filter...
</edit>

[Rinsin]

Yes, sorry I meant to say that I checked the levels using histogram. Looking forward to the detail jagabo, try not to fry my brain too much

[jagabo]

OK, I have more time now...

If the Histogram() display shows blacks near, but not in, the left brown band and whites near, but not in, the right bright band your levels are correct. DV camcorder footage, for example, often needs to be darkened because the darks don't come anywhere near the left band the the lights go way up into the right band.

When converting to RGB in VirtualDub everything in the left brown band will be crushed to RGB=0, everything in the right brown band will be crushed to RGB=255, and the area in the middle expanded to fill the range from 0-255. So you need to make sure everything you want is between the brown bands.

So now you are ready to apply Neat Video or whatever other VirtualDub filters you need.

[Rinsin]

OK, I now have a different VHS tape which has some luma in the 0-16 and 235-255 range.

1. If I open the source via an Avisynth script and adjust the levels via ColorYUV to the 16-235 range, but then filter via Neat Video, doesn't this cause/require a conversion to RGB which acutally therefore expands the luma which I had just corrected? Even if not, when I then convert to YV12 to pass to HCenc, isn't there going to be an expansion there?

2. What is the difference in correcting the levels via ColorYUV as above and then using Neat Video, as compared to using ConvertToRGB(matrix="PC.601") and then using Neat Video?

[jagabo]

OK, I now have a different VHS tape which has some luma in the 0-16 and 235-255 range.

1. If I open the source via an Avisynth script and adjust the levels via ColorYUV to the 16-235 range, but then filter via Neat Video, doesn't this cause/require a conversion to RGB which acutally therefore expands the luma which I had just corrected?

Yes. But all your luma is between 16 and 235 so dark and light shades are not lost. You do lose a little accuracy.

Even if not, when I then convert to YV12 to pass to HCenc, isn't there going to be an expansion there?

When you convert VirtualDub's RGB output to YV12 for HcEnc the luma is adjusted back to the 16-235 range. Again, you do lose a little accuracy.

2. What is the difference in correcting the levels via ColorYUV as above and then using Neat Video, as compared to using ConvertToRGB(matrix="PC.601") and then using Neat Video?

Using ConvertToRGB(matrix="PC.601") leaves the luma range from 0 to 255 in RGB. When you convert back to YV12 for HcEnc you have to specify that the luma range should not be compressed by using ConvertToYV12(matrix="PC.601").

WhateverSource() # YUV data
ColorYUV() # make sure Y is 16-235
ConvertToRGB() # luma expansion y=16-235 --> RGB 0-255
Neat Video # RGB 0-255
ConvertToYV12() # luma compression RGB=0-255 --> Y=16-235

WhateverSource() # YUV data
ColorYUV() # make sure Y is 16-235
ConvertToRGB(matrix="PC.601") # no luma expansion Y=0-255 --> RGB=0-255
Neat Video # RGB 0-255
ConvertToYV12(matrix="PC.601") # no luma compression, RGB=0-255 --> Y=0-255

Note that when VirtualDub (and almost every other video editing/processing program) performs a YUV to RGB conversion it always does the equivalent of ConvertToRGB() (luma expansion). Conversely, when it does an RGB to YUV conversion it always does the equivalent of ConvertToYV12() (luma compression). So if you use ConvertToRGB(matrix="PC.601") before VirtualDub you have to be careful to specify ConvertToYV12(matrix="PC.601") after VirtualDub.

[Rinsin]

[quote]

OK, I now have a different VHS tape which has some luma in the 0-16 and 235-255 range.

1. If I open the source via an Avisynth script and adjust the levels via ColorYUV to the 16-235 range, but then filter via Neat Video, doesn't this cause/require a conversion to RGB which acutally therefore expands the luma which I had just corrected?

Yes. But all your luma is between 16 and 235 so dark and light shades are not lost. You do lose a little accuracy.

My luma is in the 0-16 and 235-255 ranges - which surely means it is outside of the 16-235 range? So this will "wash out" the file won't it? (Is this what you mean by losing a little accuracy)?

I'll have a play with the rest of the stuff tonight ... no doubt I'll be posting back soon

[jagabo]

My luma is in the 0-16 and 235-255 ranges - which surely means it is outside of the 16-235 range? So this will "wash out" the file won't it?

Yes, if you don't adjust the luma before converting to RGB (with the usual luma expansion), dark areas below luma 16 will all be perfectly black, any detail in bright areas above luma 235 will all become the same brightness, 255.

Is this what you mean by losing a little accuracy?

No. The small loss of accuracy refers to the fact that you are taking 220 integer values (16-235) and converting them to 256 integer values (0-255). The process can't be perfectly linear. As an example take four integer values (1,2,3,4) and convert them to 5 integer values ranging from 1 to 5. You might do it like this:

1 --> 1
2 --> 2
3 --> 4
4 --> 5

So originally you had 4 evenly spaced values, but after conversion you have a discontinuity between 2 and 4. There's no way to evenly spread the range of 1-4 to a range of 1-5 using integers. You could do it in floating point:

1 --> 1
2 --> 2.333
3 --> 4.666
4 --> 5

But this type of video processing is always done with integers.

Conversely, try taking 5 integer values (1,2,3,4,5) and converting them to 4 integer values from 1 to 4:

1 --> 1
2 --> 2
3 --> 3
4 --> 3
5 --> 4

After conversion you can no longer differentiate between the pixels which were originally luma 3 and 4. There's no way to take 5 evenly spaced integers and convert them into 4 integers without losing some accuracy somewhere.

This is further compounded by the fact that you are taking 3 values per pixel (YUV) and converting to three other values (RGB) or vice versa in a complex manner. Not all colors in the YUV colorspace will result in unique colors in the RGB colorspace, and vice versa.