How to Properly Crop the Overscan in VirtualDub [GUIDE]
 

As anybody converting VHS tapes to DVDs/Youtube quickly discovers, the video signal contains a lot of junk on the edges of the screen -- noise not seen when it was played on a television. This is actually an intentional "feature" of traditional video signals, as it allowed broadcasters to hide non-video signal functionality which did present itself as noise. Closed caption data, for example.

That concept has been explained in depth here: http://www.digitalfaq.com/forum/vide...converted.html

You want to hide this when making DVDs -- never crop it! :eek:

This is referred to as a "mask" in most editing programs. VirtualDub, a popular freeware, doesn't natively contain an obvious mask function, but it is there. You have to leverage the resize filter in conjunction with the crop function, in order to create a mask. It's a simple three-step process:

Step 1: Set the Resolution

Attachment 2577

^ After opening your recorded VHS video in VirtualDub, go to the Video > Filters menu, click the Add button, and select the Resize filter. Configure the options to match the input of your source video -- be it 352x480, 704x480, 720x480 for NTSC; or 325x576 or 720x576 for PAL -- and input those numbers into both boxes shown above. Most importantly, be sure to select the proper radio (dot) button options, as shown above. OK when done.


Step 2: Set the Crop

Attachment 2578

^ Enter the Cropping function on the Filters page, and alter the X and Y dimensions. Always select in multiples of 2. Otherwise you'll mess up the interlacing.

The X is left and right, and Y is top and bottom. Ideally you hide 8 pixels removed from each side.

• At 352x resolutions, you don't really want to hide more than 12 on the Y (24 total) or 12 on the X (24 total).
• At 704/720x resolutions, you don't want to hide more than 12 on the Y (24 total) or 20 on the X (40 total).
• Hiding more pixels may show black edges on the screen, as you've left the overscan, and are now within the TV image area.

Note: You do NOT have to select the same numbers for each box, as sometimes the picture is shifted badly within the signal. This is where you can not only hide the overscan noise, but fix the image offset at the same time. Also understand that it's the total number that counts when hiding pixels. If you remove only 4 pixels on a Y side, you can remove 20 from the other side, and the picture will re-center itself, with a net overscan hidden of 12 pixels per side.

Guides like this are meant to help you think -- not let you monkey-see/monkey-do!


Example of Proper Overscan Mask

Attachment 2579

^ This is an example of a hidden overscan. Notice that there is twice as much hidden on the left/right (X) as there is on the top/bottom (Y). This is a good example of proper overscan removal (masking) for interlaced video.

Nothing looks worse than a video with squiggly junk on all sides, when you're wanting to enjoy it. :(

It's easy to fix, using this method, prior to encoding and authoring for DVD. :cool:

I'm not sure of the significant differences (if there are any) between the two methods, but this is also achievable in VirtualDub using the 'fill' filter if one prefers, although I cannot recall if that is a built in feature or not with a stock copy of VDub. Edit: Yes, it appears to be one of the internal filters.

You would use multiple instances of the 'fill' filter, one for the top, bottom, left and right portions of the screen (if you wish to mask all of them). Similarly to the above method, you have the option of choosing a color to mask the frame. To achieve the effect, you simply adjust the x/y offsets to isolate the area that will be the masked out portion of the frame (you can do this either by adjusting the values in the boxes or clicking and dragging the guides in the actual video frame). So for example, if the left 15 pixels of the frame are going to be masked, you would want just those pixels visible (and nothing else) in the filter window. Repeat for the other parts of the frame you wish to mask.

Also -- I haven't tried it myself but let's say you have a simple VHS to DVD recording on a DVD recorder that you want to mask, but don't wish to re-encode. This person came up with a clever solution using a subtitle.

http://forum.videohelp.com/threads/3...ut-Re-encoding

I'll have to try that subtitle trick. Very nice!

noob question here on the above guide. why would you resize first and crop later. shouldn't it be crop first and resize later?

besides, some other digitalFAQ guide specifically said not to resize, but mask instead. so, which guide is actually right?

thanks!

First off, understand this guide is very accurate. :2cents:

All video software tends to behave different, when it comes to cropping and masking. Many refer to "cropping" improperly, while others use nonsense terms like "clipping" to describe a mask/crop. ("Clipping" is a specific video and audio jargon, and NOT at all related to crop/mask!)

Avisynth, Adobe Premiere, Final Cut Pro, etc etc -- they're all different in behavior.

And in fact, there's several ways to accomplish masking in VirtualDub!

Technically, this is how masking works:
- first you have to crop a video (remove unwanted pixels)
- then pad it back with a solid color to create a mask (thus restoring the original resolution)

Some software has a "crop/mask/clip" filter/button/whatever. But crop-then-pad is the underlying task that is always taking place. VirtualDub is simply one of the few programs that reveals this fact.

Now, you can do the very manual method, by using the "null" filter, and cropping the footage, following by a second filter (including resize) to pad it back.

But the easiest method is to use only the "resize" filter, and cropping the video. First it crops ("crop" function in VirtualDub, under Video Filters), then it pads ("crop to size" in the Resize filter). This is all done in a single pass.

Make sense?

Perhaps the guide needs another image or two. :hmm:

Note: You must be very careful with source resolutions with cropping or masking in VirtualDub. For example, full SD PAL is 720x576, while full SD NTSC is 720x480. You need to change accordingly. This was explained in the above quickie guide, but it needs to be emphasized. A bad crop will screw up the video.

thanks lordsmurf for your explanation. i trust you but want to understand and not just blindly follow a script that i don't understand.

what is the function of the first resize filter? after all the resolution is not changed (352x480->352x480). is this the same function as the null filter some people use?

are you saying that the crop function in VD is actually doing masking and not removing pixels (as the name implies?)

i'm not so sure, when i used the VD crop function during capture, that resulted in decreased size (and resolution) of the frames.

now, how about capturing cropped (720x568) and then resize using VD filter with 720x576 and one of the letter box options?

i can try it tonight, if that's a better solution than the simple border control filter.

Never blindly follow anything. That's a wise move on your part. Test, then test again! Verify it does what you need before committing. It's too easy to screw up video, so be diligent.

The "crop" function crops doesn't work without a filter.

Attachment 5045

But add a filter, then you can crop.
It crops BEFORE that filter runs, not after. This is important, and why this method works.
Note: You could add a null filter (does nothing), then add yet another filter to pad it (in order to mask it).

Attachment 5046

If we add the resize filter, this function acts as a mask:

Attachment 5047

The crop>resize does this: (imagine VirtualDub talking to itself) "Okay, cut off pixels. But we can't actually remove any pixels, since the resolution is defined to be the same as the source. We're also not allowed to stretch anything. The only option is to just leave blank (black!) data."

Note: It shows 320x240 because I didn't load a video. I'm not on a video system right now.

And no, never capture interlaced footage as anything other than x576 PAL or x480 NTSC. You cannot capture wrong, then pad it back to fix it. Never try to crop/mask footage in realtime, aside from some special situations (namely the mask ability of ATI MMC, with MPEG-2 capturing, with an ATI AIW Radeon card).

Mr. Jacek brought my attention to his project, so upon reviewing his posts, I came across this. Could I just interject to add, that I think this was a problem in terminology or definitions. If I were to see some suggestion to "crop then resize", I would picture say, cropping 480->472, then resizing to 480, implying a (to use a better term?) "rescaling" that is a stretching back to 480, which is a definite no-no.

The key lies in how the "resize" options in this particular program work, with the steps described; they are actually doing a padding in order to resize, not a stretching. In this case I find calliing that a resizing somewhat ambiguous, as I usually think of resizing as being a stretching of pixels. The end effect I would call, masking.

The guide is fine, however I would hesitate to call it a crop/resize or resize crop, rather I would point out that "I'm doing a masking, but in this particular program it can be achieved by specific settings under the resize function".

"re-scaling" is actually a perfect word to describe what VirtualDub is NOT doing here. :congrats:

thanks. it was the goofy terminology that got me confused here.

I know that when cropping, the amount taken off of each side needs to be a multiple of 2. Is the same true when adding borders back onto it?

For example, if I remove 10 pixels from the bottom of the frame to get rid of overscan, and 0 pixels from the top, is it safe to add 5 pixels of border back onto the top and bottom to re-center the video vertically?

I am using AviSynth's Crop and AddBorders to do this, but I would think that the same rules would apply in VDub. AviSynth's AddBorders won't let you add odd numbers of pixels on the left and right, but it allows it on the top and bottom. I just want to make sure I'm not screwing up the interlacing by doing this.

You can crop and add vertically by increments of 1 but to maintain the original field order, you must not alter the top of the image by 1. Altering the field order shouldn't cause a problem; you just need to know that you did it so that you can flag any encode correctly.

Horizontal is where you're limited to increments of 2 (both cropping and adding borders). This is because in the 4:2:2 format, chroma is subsampled by a factor of 1/2. 2 luma pixels share 1 chroma sample. Cropping 1 luma pixel would mean you would need to crop 0.5 chroma samples, which is obviously impossible.

6 / 2 = 3 = NO
8 / 2 = 4 = YES!
10 / 2 = 5 = NO
12 / 2 = 6 = YES!
etc

Get it? Both numbers must be even. :wink2:

It's entirely about field order. The mess it makes is not worth 1 pixel. Do pairs, and KISS (keep it simple, stupid).

I agree that it is silly to use odd numbers vertically when padding the video. How would you ever notice it is off-center by 1px? Especially when you're technically shifting the image center down by some pixels by adding black to the top if you only cropped the bottom.

If there was 1 line of garbage at the top, though, I would personally bother to not overcrop... since I know the risks and I want as many video lines intact as possible. :) Technically you lose about 320 "pixels" worth of VHS video for every line you remove.

I'm jumping on to this old thread with a follow up question about masking/Virtualdub/Avisynth. I'm doing this because my question is ABOUT this issue and this seems to be THE site guide which is referred to by other threads. I "get" why masking is preferable to cropping. Suppose though I have a video where I want to mask a lot more on the left than on the right or a lot more on the bottom than on the top, but end up with a product which is "centred". I can see the Avisynth method given would allow me to do this manually. I read that the Virtualdub method will centre itself automatically. Well suppose I don't want it to? Or wish to introduce a deliberate L/R or up/down shift to the whole frame. Can Virtualdub do that?

So I followed the guide, the results were great. But my file size went from 16.6 gb to 158 gb! Is this expected? Did I do something wrong?

I did change one thing. Instead of Letterbox/crop to size, I used Letterbox to aspect ratio.
I'm a very much a newb at this, but it was showing a crop down to 320x240 which seemed a great reduction in resolution.
Using the "Letterbox to aspect ratio" it took the resolution up to 720 x 540, so the increase is expected, just not a 9 fold increase.

My intention was to take my 720x480 DV (AVI's) capture from VHS, crop out the overscan lines and then use Handbrake to compress the size down for streaming. Handbrake can take a 16 gb down to 2-3 gb using HEVC compression. But 158 gb is still going to be ridiculous in size even after compression. Is there a better, less space consuming way to crop the overscan? Or again did I do something wrong?

Ok wait, I missed this line:
"Configure the options to match the input of your source video -- be it 352x480, 704x480, 720x480 for NTSC; or 325x576 or 720x576 for PAL -- and input those numbers into both boxes shown above"

I thought VirtualDub was inputting it's own values based on calculation, but I guess I have to put in my own resolutions.

Does maintaining a 100 x 100 relative percentage matter?
Because once you edit the crop, that percentage changes.

Ok followed the guide to a tee this time. Kept everything at 720 x 480. Edited 18 pixels off the top (because of some bad tape) and 6 off the bottom for the overscan, saved to AVI and I got a 140 gb file. What is going on?

any help would be greatly appreciated.

What codec did you choose?
Video > Compression

Note for VirtualDub newbies like me:

Filters are only access-able on 'Full Process Mode' (took me couple of tries to understand why it's greyed out). And because it's being processed again, make sure set the Compression and Colorspace to what you used during Capture (in my case, HufYuv and YUV2).

Please correct me if I'm wrong or there's more settings needed to be made in order to keep the original Capture file quality when Reprocessing.

EDIT: By the way. I'm assuming "Always select in multiples of 2" - means 0 is also valid (in case you want to crop 8 pixels from the bottom and none at the top?)

Correct.

0 is valid, not cropping a side is fine. 0 is a multiple of 2. 2x0=0
good = 0-2-4-6-8-10-etc
bad = 1-3-5-7-9-etc

Thank you (as always) for confirming it lordsmurf :-)

In the year 2021 when one will almost certainly never be burning any of these files to a DVD, is there any good reason not to just crop and eliminate the black borders? Overscan is a thing of the past. YouTube, etc will happily display video of any resolution including something weird like 636x476, no?

Also, and this might be a silly question that I can easily answer myself, but when capturing at 720x480 on my 600 USB capture device, am I capturing an additional 40 pixels on each side of the screen of width or am I now dealing with non-square pixels?

I think you still want to just mask out the overscan for the broadest compatibility with devices and to maintain the interlacing if you don't need to use filters that require deinterlacing. I believe you can crop as long as you do it in multiples of four and still maintain the interlacing but why potentially mess with that and create a wonky sized video that some device might totally misread? Standards are there for a reason.

You're not understanding video. I shall educate... :)

For starters, Youtube butchers video. More often than not, Youtube will rape/molest your video as it sees fit. Quality is not even secondary, but shoved way a down a priority list. Youtube should never be your yardstick to quality, or anything else. Youtube is about uploading compressed video for $$$ (sometimes shared with you, sometimes not), the end.

What I focus on is ingested video, pre-delivery. Not Youtube, not optical (DVD-Video, BDAV/BDMV).

- When you resize vertically, you screw up interlace.
- Almost all video software and players require specs, not random sizes. Resizing to spec can alter the aspect ratio, and even small upsizing can screw up in-image quality (sharpness, geometry, etc).

I have never understood the OCD/ADD insanity of avoiding evil "black bars". It's extremely stupid to stretch 4x3 to 16x9, or to insist on cropping off <5% black borders that are there to retain image quality/integrity. You're supposed to enjoy the content, not flip out on areas when content is not. (I will say that postage stamping is bad video work.)

Not true. HD broadcasts, and sometimes even HD releases, have overscan data.

720x480 is not active image. The active is 704x480 in 4:3 AR (and coming from an analog tape, has overscan that includes head-switching, CC, etc). So you'd crop 720 to 704, then resize 704 to 640. Matte the overscan, watch/upload/whatever. If you start to crop pixels, quality will only degrade.

Yep, 704x480 (704x576 PAL/SECAM) is the least resolution you can crop to without screwing the aspect ratio or the validity of the file, If 16/9 is a must you can add frosty borders on the left and right sides.

Most consumer video tapes will leave some black borders even after cropping to 704 but some do eliminate them completely or take some of the active area with it, depends on the origin of the tape, But the vertical 480 leaves a big chunk of head switch on the bottom and sometimes a black strip on the top especially 8mm/Hi8 tapes.

In my entire time since I started this hobby I came across one and only one VHS tape that doesn't have the head switch in the active video area at the bottom and the horizontal active area is exactly 704. It is a home recorded tape from a broadcast TV that picked up for free in a lot of tapes, I wish I know what VCR model recorded it because this VCR has to be freaking special, possibly a pro deck, though I've seen pro decks do produce head switch noise in the active video area.

Here is a sample from a lossless file for that tape (no aspect ratio set yet), Anyone who thinks I cropped this and resized it to fake it I can send you the actual video tape.

Cropping degrades quality? How so?

And resizing 704->640. Would this not result in quality loss? Stuffing 704 pixels into 640. Intuitively it seems like it would be better to simply capture with square pixels (640x480) from the get-go.

No, you're still not seeing it... :wait:

When you "crop" to a spec (specific allowed sizes), you must upsize/downsize. If you start with a 720x480 capture, and lop of 10 pixels from each size, then two things happen: (1) the aspect ratio is screwed up if disallowed from viewing 1:1, which is common even with the most modern players, (2) quality is lost, especially by adding aliasing and a loss of sharpness, by upsizing the now-700x460 back to 720x480. And then interlace is also screw up if interlaced, the video becomes an unviewable mess.

You cannot just arbitrarily crop to random sizes.

No. It's horizontal. And VHS is arguably not even 352x480, much less 640 or 704.

This statement makes no sense. Nothing is "stuffed".

The problem here is the way capture cards ingest (usually due to drivers). The ATI AIW cards, for example, were intelligent about active pixels and aspect. But your average capture card is pretty stupid, if not capturing 720x480. Most cards are dumb about any other size beyond 720x480, as that's all the chip or driver was optimized for. If you attempt other resolutions, odd things can happen, mostly AR/sharpness/aliasing issues.

Ok, so maybe cropping is the wrong word. I was talking about lopping off those pixels and outputting say 700x460. I get that for something like DVD this is bad. But I expect to play these files on computer screens, phone screens, and maybe a 1080p TV. So the SD standard resolution becomes irrelevant. I don't really see what is superior about having a 720x480 (or 640x480) file vs 700x460 (for example).

Understood that the VHS source does not have 640 or 720 pixels worth of horizontal resolution. But once captured at that resolution, there is unique data in each pixel. Resizing from 720 to 640 requires "stuffing" 720 pixels worth of data (including noise) into 640 pixels. By stuffing, I mean using some sort of scaling algorithm. Sampling 640 pixels per line instead of 720 from the get-go on the capture card should result in a better image.

Are you suggesting that the capture card is actually just always capturing 720 pixels and scaling down to 640 internally when using a lower resolution? If so, then it makes sense just to capture the full 720 for our lossless initial file.

My 720 captures have black bars on each side. I'm guessing this is the 720 vs 704 width discussed elsewhere. If I am understanding correctly, 704x480 should be resized to 640x480, not the full 720. The black bars are not part of the 4:3 aspect ratio. Is that right?

Again, still not understanding... :o

It's NOT just DVD (or to be precise, the DVD-Video format; "DVD" is just the disc).

Phones don't play video.
TVs don't play video.
Websites don't play video.

Players play video.

Players often will not understand non-standard resolutions. Backing up even more, editors and encoders often do not understand non-standard resolutions. Something like 700x460 would require 4x4 DCT encoding (using another random number, like 698x458, would be 2x2 encoding). But players may insist on standard 16x16 block size, and stretch the content to 16x16 regardless of AR flags. Or 8x8, 4x4.

Even if 2x2 is allowed, the player may only understand a certain number of AR flags, like 4x3 or 16x9 -- not whatever weird AR that 700x460 would plop out.

No.

The pixels are a palette. The actual resolve is not pixel matched. So a 300x480 standard (max) resolution VHS would have pixels where content is essentially duplicated. 2+ pixels would be near identical content. Remember, analog video doesn't have pixels.

No.

You have to separate the content from the pixels. Scaling the content won't really be affected by a downsize. At most, your may introduce some aliasing, but not at those resolution with a mere 704>640. And the deinterlace will make this a moot argument, as that's far more drastic.

In theory. But not in practice.
Theory is nice to fill books, have debates, etc -- but I care about practical application.

Correct. That happens. Go back some decades, and look at the BT8x8/CX cards, which couldn't even handle 720x704 correctly, and fubar'd the AR.

Crop 720 to 704.
Resize 704 to 640.

This assume the AR was correct to begin with. I've seen cameras that record the wrong AR, and the 720>704>640 would actually make a mess. So content matters. You'll need to locate some geometric (example: a round clock) to confirm the footage is actually standard.

Lots of people monkey-up video, including pros (and "pros" aka quacks), due to misunderstanding. I've made some mistakes in my past as well, everybody does or will, but I don't double-down like some of these clowns I see online. I'm also very careful, test and view. I never just batch a job, only to later realize I made a mistake and have to redo it (or worse, shrug it off, just do a terrible job, as lots of hack "professionals" and "services" do).

The whole purpose of resizing to 640 is to have a square pixel, in other words it forces the 4:3 AR so dumb devices will display it correctly, This was an issue back in the day but now I haven't come across a device that doesn't recognize the SAR flag, So far I've tried 2 iPhones, 2 Android phones, 2 Samsung Tablets, 3 LG TV's, nVidia shield, PS4, Xbox, a media player built in ATSC tuner and they all recognized the SAR flag and displayed 704x480 in a perfect 4:3 ratio. If you don't have the need to don't resize to 640 just leave it at 704 and assign an aspect ratio flag sar=10/11 (sar=12/11 for PAL/SECAM).

Yep. :congrats:

And the same players can choke on oddball resolutions that are not 16x16 or 8x8 macroblocks with standard DAR. Sometimes more DCT are understood, sometimes not. Often not.

So you have double the reasons to leave aspect alone. Just mask overscan noise, enjoy the remaining 95%+ of the visible content, and make your own life easier.

Ok, so sounds like the issue with odd-size files is the mpeg encoding/decoding step. Fair enough. I don't love the "picture framing" that comes from viewing 4:3 content with black bars at the bottom/top on a widescreen but oh well. I do wonder if something like 704x464 would be a good answer though (multiple of 16). But looking at my sample, I might lose 8px of content going that route. 704x472 looks about ideal, but then I'm looking at a multiple of 8 vs 16.

Over at VH I saw a thread with some commentary on lower capture resolutions. It basically sounds like cards always capture at "standard" 720px internally, regardless of what the capture resolution is set to. Seems reasonable enough. In which case saving the full 720px vs blindly scaling as part of the capture step before any filtering etc makes perfect sense. If PAR is truly supported universally with mp4 these days, then I'd consider leaving at 704 with the correct PAR set. Based on my searches, it sounds like this could be an issue with some Plex clients which is a problem. But I guess it's worth me testing a bit first.

To be clear, I do plan on saving the originals for any future editing, etc. But the reality is that the output progressive h.264 encoded files will likely be the only files ever viewed. So I'm looking to optimize compatibility and quality on those as best I can.

No, not MPEG. All encoding, including Huffyuv, H.264, etc.

No.

No.

Sort of correct. It varies. For example, the ATI AIW cards, the Theatre chips, had native chip of about 712x480, and padded out 8 pixels to get to 720. You can see this offset in some of the early drivers.

Yep. Plex is a player. Players have issues.

Yep. Just realize v2.0 of the player, or an update, or another shiny new upgrade brand player, may totally tank your past work. It's sort of like color correcting the video to your monitor, instead of to the video. Because that monitor will go someday.

Well, there you go.

I don't like keeping Huffyuv archives, my collection is too vast, so I archive the Huffyuv as high bitrate MPEG 422@ML, masking beforehand to appease the encoding. (Noise aka overscan = wasted bitrate, lower quality.)

Probably. That's why I archive as MPEG, as I can watch those with time consuming re-encodes to H.264, for the few times I'll likely view them (noting others will view them, not just me).

Then mask. You have the guide, in this thread, use it. :)

It's generally less than 10 pixels after re-center. I don't understand the freak-out over such a slim area. If you're watching on a HDTV or a phone, you won't even notice it. It arguably the least distracting "error", given how Youtube is so full of butchered videos anyway.

The next comment is usually "how do I make my VHS into HD and widescreen?" -- same mentality, usually from the same folks. Unwillingness to have slight imperfection, but totally willing to completely fubar the image and quality to chase a unicorn. Again, I don't get it.

Don't be that (weird) person.