VirtualDub border masking? (not cropping!)
i captured some home VHS material and removed the lower border (8 pixels) with VCR noise and resized back to the full size (720x576, PAL). the results looked OK, but i was scolded about doing this on another site, and learned that cropping and resizing is a tabu in this hobby. since then, i spent countless hours searching on ways to remove the noise the correct way. the digitalFAQ guide explains how the border should be masked, but not cropped, but without showing how. then i found this sticky post here: http://www.digitalfaq.com/forum/vide...erly-crop.html
i read it and it's about (...gasp!) cropping and resizing. what am i missing here? thank you very much (in advance) for clearing my confusion. BTW, i wanted to try the cropping guide method anyhow, but there there is no "cropping" filter in VD i can find. do i need to download that plugin? i personally used the crop function on capture. PS. i just tried the border control VD plugin. it masked the noisy line and the clip resolution is unchanged according to the GSpot info. sounds like an easy solution. would this be considered acceptable? |
2 Attachment(s)
Cutting = NO
Covering = yes Cover with black border am I doing here with Avisynth or in Edius. Edius works internally in YUV. In VDub the filter "border control" means Unfortunately, most filters operate only in RGB............see screen ---------------- Material is in YUY2 [YUV] and is already cut, then .. Customize Add Border..exakt Example is here but in PAL,see screen 2 |
There's no way I would go along with that guide you refer to. Seen it. No, thanks.
If you removed 8 pixels from the bottom of a 720x576 capture and resized the remainder, you filled the frame but you changed the original image height from 568 to 576 pixels. Other than different aspect ratios, one problem is that resizing is never free: it always costs quality, more or less, and some resizers are just plain bad. Another problem with that full-frame resize is that the usual TV overscan will cover that bottom area anyway (yes, modern TV's still use overscan, unless you've disabled it on yours). So you didn't gain anything in height by altering the image. In fact, you lost some pixels during play. Another matter you might consider: if your original video was for 4:3 display, there were likely anywhere from 8 to 16-pixels of side black borders as well, either all on one side of the frame or unevenly/evenly placed on each side. A 4:3 capture in most systems, if they comply with all that complicated SMPTE engineering garbage, fills only 704 pixels in a 720-pixel frame. Give or take a few pixels. A 16:9 video will take up more horizontal pixels, with maybe a thin border somewhere along the sides that is negligible. If you let those 4:3 side pixels stay where they were, your video likely doesn't play at exactly 4:3 anyway; it's slightly off. Not much, but off. How do you get around that? You remove the side pixels and encode at 704x576 for "true" 4:3 display -- but if you can see the difference in normal circumstances, well...you're pretty good. For 16:9 you need all the width you can get. In fact, BluRay won't let you get away with 16:9 standard def video in anything but 720 horizontal pixels for PAL or NTSC. Another reason for not masking and not resizing (other than the fact that resizing always has a quality cost, even if small): Lots of people think Hollywood shot Gone With The Wind, Shane, Casablanca, and all those classic movies from the 1930's thru the early 1950's as 4:3 (1.3333:1) images. Nope. Hollywood never shot movies at 1.3333:1. Only TV movies and shows were shot that way. Hollywood shot movies on 35mm film at 1.37:1, which is slightly wider than 4:3. Often, then, you'll get classic movies captured with 10 or 12 pixels at the bottom instead of 8 because, in fact, to make that slightly wider image fit inside a 704-pixel width, the image height is just a tad less than "real" 4:3. But, then, you can't be responsible for correcting everything that DVD makers, tape labs and broadcasters do to the original image (unless they totally screwed it up, in which case you'd likely be justified in fixing things the way they should be). And then again, some VCR's just don't get the image correct to begin with. It's a crazy world. As Goldwingfahrer mentioned, applying that black mask in VirtualDub and most NLE's is an RGB conversion, which eventually has to go back to YUV for encoding to DVD, BluRay, AVCHD, etc. You can avoid that in Avisynth, which is one advantage of Avisynth to begin with. Another advantage is that Avisynth functions let you keep the image more centered in the frame without altering the original content. If you cover the bottom 8 pixels with a black mask, the image will sit 8 pixels high on playback. No big problem, until you get TV overscan and some of the top of the image gets covered. In Avisynth you can get around it this way: Code:
Crop(0,0,0,-8) #<- cut 8 pixels off the bottom Code:
Crop(12,0,-4,-8) #<- 8 off the left, 4 off the right, 8 off the bottom You can do that in YUV without an RGB-and-back conversion. Of course, you might have wanted to go to RGB for other processing, in which case Avisynth is a little more careful about it: interlaced video: Code:
ConvertToRGB32(matrix="Rec609",interlaced=true) Code:
ConvertToRGB32(matrix="Rec609",interlaced=false) |
There nothing wrong with the guide at this site. It's 100% accurate.
I responded to questions about it here: http://www.digitalfaq.com/forum/vide...html#post39273 The "border control" plugin for VirtualDub is not as accurate. There's more fine control with the method outlined here. If you were "scolded" on another site, then I would suggest that the members of that other site were (a) not reading, but rather skimming your post (b) not experienced with VirtualDub (c) simply not very knowledgeable about video in general "Masking" is, in essence, crop-then-pad. Virtual does this true method. Others just dummy it up, and have added a "mask" function in the software. There is not "cropping filter" in VirtualDub. It's not a filter. It's a base function of the software, and is a button inside the Video Filters window. But again, it's not a filter. sanlyn prefers Avisynth. That's fine. Sometimes I do too. It's just another way of doing things. :) Understand better? |
Quote:
how about this: 1. i capture 720x568 in VD using the crop on capture function, video capture card settings to fix the colors/brightness isssues, and huffyouv compression. 2. i edit the video in VD using neat video filtering (i know, it will be slow). 3. then i run the avisynth script to resize to 720x576 and recenter the video (you are right about the side border problem, but lets ignore it for a moment). 4. then i go on to use the final AVI file in my DVD authoring software (i had good luck with nero vision express so far). i don't need to worry about the YUV->RBG conversion at this point, do i? thanks you all for help. this is not exactly easy or intuitive (at least for me). |
I use NeatVideo often myself.
The problem isn't masking as much as resizing is. Don't resize in avisynth, just add border pixels top and bottom. For YUY2 interlaced, you must add pixels in 2's, so 4 at top and 4 at bottom will restore the frame height without resizing. AddBorders() is an Avisynth built-in function, you don't need to add any plugins. The syntax for the function is AddBorders(left,top,right,bottom). So the code would be: Code:
AddBorders(0,4,0,4) You can save time by typing this script before opening the video in VirtualDub: Code:
AviSource("drive:\path to the video\all in quotes\videoname.avi") |
Quote:
http://avisynth.nl/index.php/First_script a final question. why the conversion to RGB upfront? just curious. is it because doing any processing in VD requires RGB conversion? |
Quote:
The three lines of Avisynth text I posted would be the entire .avs script for what you want to do. Tell you what, you wouldn't even have to crop during capture. The same script can do it for you. The Crop() function is also built-in and has similar syntax. The oddity with crop is that you use negative numbers for the pixels you want to remove from right and bottom, positive numbers from left and top (Long story about that. We'll be here all night). In this case the syntax is Crop(left,top,-right,-bottom). So.... Code:
AviSource("drive:\path to the video\all in quotes\videoname.avi") The same articles are in Avisynth's online help. Click Start -> All Programs -> look for the Avisynth program group, expand the group and click "Avisynth documentation". The first page has an alphabetic matrix in the left-hand table of contents that links to functions and commands that begin with those letters. |
I almost never use NeatVideo, as it's too harsh with filtering. I find various Avisynth and VirtualDub filters to be more nuanced. There is more fine control.
Avisynth will not mask with Crop() alone. It need to be followed immediately by a AddBorders(). I saw some funny-looking scripting up there, and wanted to point it out. You need both, not just one or the other. The reason I hate Avisynth masking is because the numbers are easy to transpose. It reminds me of coding shorthand CSS. I prefer the visualization of VirtualDub. I've also caught Avisynth doing some weird stuff over the years, when stacking filters, including this one. I like to KISS the scripts (keep it simple, stupid). You need AvsPmod to use Avisynth with a preview. The 720/704 thing seems quaint in the HD era, seeing as how major networks screw up so much geometry on a regular basis. (The problem was 720 and 704 were not handled uniformly by hardware and software.) |
Quote:
after that initial conversion to RGB, followed by masking and neatvideo filter (that is my routine now), and saving back compressed with huffyuv, is the video kept in RGB color space after i open it later for further editing in VD? is that OK for DVD authoring? |
Quote:
(a) specify an output colorspace. The default is RGB. (b) specify a compressor. The default is uncompressed. Quote:
Quote:
|
1 Attachment(s)
Quote:
Attachment 5170 Matching the in/out can be important. In this image, I have 4:2:2 in (Huffyuv), process RGB native in VDub, output YUY2. Part of the issue here is that the YUY2 output could possibly be turned into YV12. But then I don't know how MainConcept handles input. It may expect 4:2:2 at not 4:2:0 YV12. I can tell the difference. So, as I often say, I'm not overly worried about colorspace conversions. It's only something to stay cognizant of when you see something wrong. Or when dealing with a studio, that demands certain specs be met (however, I'll tell you that this is rare). Quote:
|
Quote:
Quote:
Quote:
thanks again. |
Quote:
Canopus Procoder, TMPGEnc or HCEnc.... Nero is a fuel programme with bad EnCoder. As an Authoring Ulead DVD power tools 2. xx... or Ulead Movie Factory 4 or TMPGEnc Authoring Works. |
Quote:
Quote:
Edit: Never mind. I did find and purchased Ulead Movie Factory 4SE. Would that be capable of transforming PAL captures into NTSC DVD? |
Quote:
On DVD the protections have been burnt by the "IFO" and BUP" in blocks side by side. .... these blocks must be burnt far apart on the DVD. ImgBurn is able to do this cleanly Nero is not able. Closed all GOPs.... only the first GOP properly put from M=3 and N=12 [PAL] M=3 and N=15 [NTSC] adapt from "intra DC precision on 9 or 10 or 11," je after bit rate. Here a few years ago we had made in Europe 2 big comparative tests with different mpeg2 Encoder. We saw result...... with bit rates of 6000 kbps no big differences with CCE [Cinema Craft Encoder] Canopus Procoder, TMPGEnc and HCEnc. CCE was the quickest. There were differences, however, with interlaced material with deep bit rates. There the winner Canopus Procoder was in the mast's ring mode. Quote:
In English the tool Ulead DVD Movie Factory is called. Is already very old from 2004, me, however, much rather than TMPGEnc Authoring Works or Encore of Adobe. To the testing I had the last week on a PC the English version of Ulead Movie Factory 4. Under Win 7 64 there were no problems with the Install. Problem is only. mine in English is with 1% Ulead Movie Factory can carry out no norm change. Norm change of NTSC to PAL or vice versa goes in big videotools like Of MediaComposer Sony Vegas 13, Adobe premiere and Edius only with "Blends" I make norm change with Avisynth or with the Capturen with Kramer SP-11D http://www.hdtvsupply.com/kr-sp11d.html Give me sometimes a test clip. |
goldwingfarher,
thanks for your comprehensive help on this project. while i'm waiting on that Ulead MF4SE disc, i'll experiment with avstodvd/imgburn for authoring in both PAL and NTSC. it was recommended on this and some other forums. |
I've never liked Ulead Movie Factory, but some here have reported success with it in the past.
Never use Nero. It's a burning program. Using it to convert video is like going to the oil change gas station to order lunch. That's just not at all what it should be used for. |
Hi everyone,
I came back with an update. Using the knowledge acquired here 2 years ago, I captured 4 VHSc and burned one slick DVD with avstodvd/imgburn. I had material for a few more, but project got interrupted by health issues and family emergencies (quite a few too many). Fast forward 2 years, I decided to restart the project, but was set back by forgetting the details and the capture rig failed from old age and had to be rebuilt. I did some searches that lead me back to this very thread. Now, even though I know the major principles and I'm proficient at using the main tools, I still have lack of clarity what happens behind the scenes. I'm a bit concerned about that YUV and RGB conversions happening with my filtering/processing. Here are my followup questions: 1. I've heard somewhere on this forum that huffyuv is not lossless when YUV to RGB conversion (or the opposite) happens. Is it true? 2. From reading how NeatVideo works: Neat Video converts an RGB input frame to the YCrCb working color space, the initial capture is in YUV, mind you. Later, that's converted back to RGB at the end (I'm saving filtered clips in huffyuv RGB). So, basically, it's YUV->RGB->YUV->RGB per cycle of neat video in VD, and later -> YUV on DVD. Is all that somehow problematic for the quality? There might be some more questions later, but these are the main ones I remember now. Anyone willing to answer them? Thanks! |
Huffyuv has nothing to do with RGB -> YUV colorspace changes. Those conversions are external to huffyuv. Codecs like huffyuv, Lagarith, and UT Video are lossless, period, and they don't in themselves make colorspace conversions. Those conversions are made by video applications and the people who use them.
Like every other VirtualDub filter (and like NeatVideo plugins for programs like Adobe Premiere Pro, Vegas Pro, After Effects, Final Cut Pro, etc.), Neat Video expects RGB input. Internally it does work in a proprietary YCbCr colorspace. I use NeatVideo myself for specific purposes, but it's not a cure-all, doesn't affect many noise issues, destroys detail and causes posterization effects when carelessly used, and should never be used at its default settings. Input into Virtualdub and most other editors automatically converts to RGB for display. Depending on the processing mode, that RGB conversion occurs for filtering and is kept as the output unless you instruct Virtualdub or other processor apps to either convert it to something else on output, or to not filter processing at all. In VirtualDub, "full processing mode" always converts to RGB, even if you save the results as something else and even if you don't apply VirtualDub filters. To avoid a colorspace change you can use another processing mode, such as "fast recompress" or"direct stream copy" (if you use those Virtualdub processing modes, any filters you've loaded will not be applied and no "real" RGB conversion to the original signal occurs). The YUV colorspace isn't always YUY2. It could be any number of other variations, most often YV12 used for video encoding and for most Avisynth filters. It's lower-resolution color like YV12 to RGB that causes problems after a successive chain of conversion back and forth -- due to numeric rounding errors in computing the interpolation between one colorspace and the other. Most editors screw up YV12->RGB or YV12->YUY2 and back again in one way or another and to a certain degree -- probably not enough to notice with a single conversion but the errors accumulate. Errors also accumulate with YUY2-> RGB, but they're not as noticeable as lower-to-higher-resolution and back again. I always use huffyuv for analog capture because of huff's speed and reliability with YUY2. But the misgiving I have with huffyuv is that a great deal of Avisynth processing works with YV12, and huffyuv can't compress YV12. So if you want to save a YV12 job with huffyuv compression, you have to convert to YUY2 or RGB. Do that often enough and you'll start to see subtle color shifts and other changes that you don't like. For post-processing I use Lagarith to avoid unnecessary YV12-YUY2-RGB colorspace conversions and to exercise more control over multiple processing stages. I don't always use Virtualdub filters for cleanup, so I don't have an RGB conversion issue, and when I do need that conversion I do it in Avisynth. Eventually, for most encoding, I use Avisynth for saving a file as YV12 for MPEG or h.264 encoding. Normally, colorspace conversions don't cause a great deal of trouble. This assumes, however, that your YUV luma and color levels are within the preferred YUV spec of y=16 to 235. Expansion of out-of-spec YUV values when converting to RGB causes clipping of dark and bright details that can't be recovered later. With proper YUV levels you won't see much difference between a YUV->RGB conversion or two. But after several such conversions you'll undoubtedly encounter accumulated interpolation errors. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.