https://www.merriam-webster.com/dictionary/upscaleto increase the size; scope, or scale of (something)
But that definition isn't applying specifically to video. Maybe I should have said 'upsize'. Does that include both 'upscale' and 'resize'?
+ Reply to Thread
Results 31 to 54 of 54
Anyway, because people were surprised that I could capture above 720x576, I though i'd post some more examples of what i've been trying.
My capture card is a Magewell Pro Capture HDMI, and i'm capturing via S-VIdeo
If I open VirtualDub2, and go to the Capture AVI mode, and open Video->Capture filter, I see the following:
[Attachment 55752 - Click to enlarge]
The 720x576i on the Input box, and also in the "Crop input" box are on 720x576 regardless of the resolution I actually pick to capture at.
Onto resolutions. If I click on Video->Capture Pin, I have a bunch of presets I can pick from. The default (in bold at the top 768x576) is in bold regardless of what resolution i've picked from, but as you can see, I have plenty of options available:
[Attachment 55753 - Click to enlarge]
The image is stretched/shrunk to match whatever resolution I pick, it does not crop. I.e. if I picked 1280x720, a 4:3 video would look streched.
I've done captures at the following resolutions: 704x576, 720x576, 768x576, 788x576 & 1280x720. Here are screenshots of all
[Attachment 55754 - Click to enlarge]
[Attachment 55755 - Click to enlarge]
[Attachment 55756 - Click to enlarge]
[Attachment 55757 - Click to enlarge]
[Attachment 55758 - Click to enlarge]
Is this what people were expecting? I get the impression people were thinking that by expanding the horizontal resolution, i'd end up with the same proportioned image in the centre, just more black pixels either side, which is not the case.
If I take the 720x576 image, crop the sides to 702x576, then expand that to 768x576, the image looks identical to if I took the 788x576 image and cropped the sides to 768x576. However the latter image is of a superior quality, presumably because i haven't need to stretch the image further after capturing.
Forget YouTube right now, My intention is to produce a final video at 576px high, which has a DAR of 4:3 and a PAR of 1:1, which I believe should have dimensions of 768x576. Because of my intended PAR of 1:1, I believe I need to compensate for this by cropping the black bars either side and expanding what's left to 768 pixels wide. Is this right? (I'm going off this website here https://bjohas.de/wiki/Tutorials/Video/Pixel_Aspect_Ratio). I am working under the assumption that I will be playing this video on a player which will always display the pixels square.
Last edited by bergqvistjl; 6th Nov 2020 at 05:07.
Did you actually bother to read and understand reply #28 ? Scott knows what he his writing about. Certainly more than me and much more than you.
Once again and for the last time. You are NOT capturing at > 720 pixels. Your capture device is allowing you to OUTPUT > 720 pixels. But maybe you also do not understand the difference between INPUT as per your first screen and OUTPUT as per you second screen.
BTW Those images prove nothing. To get a true reflection of visual accuracy you need a perfect circle at INPUT.
But I am now done with this since you continue to ask the same question over and over despite already having been told the answer MORE than once.
1. I should take my 720x576 input in VirtualDub
2. Save it as a 720x576 AVI file.
3. Crop the black bars either side, so I'm left with 702x576
4. Stretch what's left so I get a 768x576 file, still with square pixels. (Forget upscaling further for now)
Is this right?
Last edited by bergqvistjl; 6th Nov 2020 at 09:22.
Skip the "blanking" terminology, as it seems you are conflating that with overscan and with sampling buffer zones.
Blanking refers to when the signal tells the TV scanline to TURN OFF while it recycles back to its starting points (either horizontally or vertically or both).
The sampling from analog to digital is all about timing the sampling to match the visual/non-blanking sections of the screen (i.e. it should never sample the blanking). But since modern cap cards are meant to support multiple source standards, there is a little play. This comes from the difference between 720 and 704(702). The black sections on left and right of 720-scanned images from 704-based streams might be considered to include a minor amount of blanking, but it basically is a buffer zone in the sampling timing. If you don't like them, you can crop them. Doing so may further adjust your aspect ratios, so that could be a way to get them as accurate as possible (though it often isn't necessary, as most people cannot distinguish the difference).
Overscan is a different thing, and has to do with the display. Because CRTs use (primarily) analog electronics, there is bound to be some amount of variability in accuracy, thus the image shown is usually covered over by a bezel (or the equivalent of zoom+crop) to mask the inaccuracies. Digital (LED, LCD, Plasma) monitors do not ever need or (often) use overscan, because the electronics in their devices are all digital, accurate, pixel-based, as are the pixel-based digital signals that are being sent to them. Analog signals such as from a VCR may still exhibit inaccuracies in playback that one might like to fix (e.g. head-switching tearing on the bottom few lines), but that can be done with cropping or masking in post-processing. In general though, you do NOT want to use overscan on displays anymore, and it is often a best practice to change the setting on your displays to 1:1 (aka "Just Scan" aka "Dot Perfect", etc) so your display shows every pixel mapped 1:1 (i.e. without any zooming, which interpolates) for better sharpness. This is particularly true when sending a signal from a PC/Mac.
I do NOT recommend stretching anything unless you can't avoid it. But I understand many users cannot be bothered with having to make adjustments on the fly.
Take your 720x576i in Vdub,
Save it as a 720x576 AVI lossless file.
(Optional) Crop it to 704x576 (or 702x576 if you must) and resave to AVI lossless file.
Play it with a player that allows for AR correction (in this case, applying 59:54 PAR - or more easily the 12:11 PAR, stretching 704->768, which will give you a 4:3 DAR).
If you can't stand having to manually do AR correction, and you don't have a file format that fully supports AR flagging (and AVI has that issue), you would have to stretch to 768x576 & re-encode (hopefully also losslessly).
So, yes, you were on the right track.
BTW, I agree with what DB83 was trying to get across to you: the magewell card you were using shows the same 720x576 as input, and is only showing the 768x576 as output, BECAUSE it is assuming you want a square-pixelled output. Not too surprised that there would be some issues w/ Magewell, as they are a Chinese company and while their products by and large are quite good (and I have used them a lot), the Chinese aren't big on following international standards (of which BT.601 is one).
But the magewell is resizing (whether with sharpening applied, we don't know, but I suspect), and that is a form of interpolation (a "guess") with accompanying loss of quality. The sharpening is probably compensating for that, and it might be (over-) compensating to the point where it might look better to you. But it is NOT better to an encoder you might need to use downstream.
Last edited by Cornucopia; 6th Nov 2020 at 13:06.
There is a reason why it is not recommended to capture analog video with an analog to HDMI converter, and it is because what Scott mentioned above, the added resizing options in the HDMI stage and other video processing, Some have mandatory de-interlacer, at least yours gives you the option to keep the video interlaced, So to summarize what everyone trying to tell you above, Your card is capturing natively at 720x576 (D1 statndard and all capture cards should adhere to), but the HDMI chip is giving you the option to resize to any resolution you'd like, So when you output to 768 or whatever resolution you choose then crop to 704x576 and resize back to 768 you have just done double resizing. Instead, What you should be doing is this:
- Capture AND output at 720x576 to keep the resizing feature off.
- Crop to 704x576 to get the real aspect ratio -> this should be your master file
- Resize to 768x576 for playback, or to 1440x1080 for online streaming platforms from the above master file.
I hope this solves your dilemma.
Last edited by bergqvistjl; 6th Nov 2020 at 14:14.
The Magewell cards do have a FPGA on board (ADV7842 chipset and a Xilinx Artix-7 FPGA) and a substantial amount of high speed memory ( about 262 Mb) so they can perform several video processing functions internally such as up/down scaling, aspect ratio conversion, , hue/brightness/contrast/saturation adjustments, deinterlacing, color space conversions , etc-
They also clear identify the incoming video stream specs that can be seen accessing the input tab and you can capture in the native stream resolution or resize to any other resolution not only standard resolutions but any one you do require.
So you can capture, crop, resize and change color format from BT.601 to Bt.709 for instance all in one operation internally in the capture card. You can deinterlace also , but if needed you will get better results doing it externally with avisynth QTGMC.
You have to test but it´s quite possible you will get better results doing all the needed operation internally in the card during capture with zero cpu impact.
Last edited by FLP437; 6th Nov 2020 at 17:04.
Fig 3 included in the previous zip was wrong, this is the correct one.
vdub will do them in one operation.
Last edited by bergqvistjl; 7th Nov 2020 at 04:06.
Yes, And 704, 702 is not a legal resolution.
I will chip in because I can and more so since the red grape is talking.
I will agree with my friend that 702*576 is not a legal resolution >> read up on modulus to understand that. But when 702 pixels is resized to 768, which is a legal resolution, the argument is not so strong.
What is more pertinent is how the resize affects the original visually. If you simply resized 720 pixels to 768 that equates to an increase of approx. 1.07% with the 702/704 active video resulting in 750/752 pixels.
Crop away the side-bars, even at 702, results in an increase of 1.09%.
So you now see that you have a slightly wider active video area (768 compared with 750/752)
Only your own eyes can tell you which is the more acceptable without reference to images, such as a perfect circle, that might look odd. Yet others may disagree Some time ago there was a topic that posted screen grabs of a circle at two slightly different ARs and I could not distinguish between them. But then I have only one good eye and after a few glasses of the red grape even that can be questioned
I insisted on 704 because I suggested to keep those as master files, If the purpose is only resizing then it doesn't really matter what resolution you crop to, I personally use two crops, one permanent from 720 for the master files which is AVI 4:2:2 704x480(576) and one temporary crop from 720 combined with a resize to 1440x1080 in one single pass for online sharing, That temporary crop can be anything down to the bare active video area both vertically and horizontally as long as I keep the resolution ratios intact (not aspect ratio) for NTSC and PAL standards (704:480 and 704:576 ratios, These ratios are defined by the D1 standard and any other resolution used for setting the 4:3 aspect ratio whether by PAR flagging or square pixel resizing will not lead to a perfect picture geometry as scanned in the original camera imaging sensor).
But all what this does is confuses the OP further, It is good to keep things simple for people who just started to learn until they develop new skills and then come back for more advanced questions in the future where then one can address the right issue.
Edit: Added details
Last edited by dellsam34; 8th Nov 2020 at 03:14.
I've found some reference images and if I leave the black bars in there and stretch to 768, it's still squashed, whereas cropping to 704 and then stretching to 768, the images are in proportion, so thanks all! Kinda wish I could crop by 9 pixels on one side and 7 on the other, but avisynth wont let me, oh well.
So you now see the visible difference between a 1.07 and 1.09. It is small but is still significant if your vision permits.
And the reason for the perceived reluctance on avisynth, or any editor that you can crop, is that is that a crop MUST be divisable by 2. So 8 + 8 is allowed and so is 8 + 10. Odd numbers are a no no so even if you had 9 pixels of crud on the right and 9 on the left you could not crop them all away unless you crept in to the active video area and chose 10.
1.take 16pixels total out left and right
2.resize to 4:3 square pixel
3. optional, crop rest of black pixels, this way you still will have aspect ratio perfect, but keep video mod at least 2, no odd numbers
But if you do step 3, any further resizing causes a problem of potential aspect ratio screw up, fo example, someone gets that video and will resize to 1440x1080 and then ar error will be introduced. So personally, I think it is better to leave those black stripes there, whatever left, if videos are yours. If it is presentation, for web, you just use additional step 3.
Vdub allows you that and it's lossless, For cropping and resizing I recommend Vdub2 in one single process and then use avisynth for encoding if you wish. Oh and if you are thinking about vertical cropping, always crop in pairs of lines or you will reverse the field order and that can lead to a disaster.
Last edited by dellsam34; 8th Nov 2020 at 13:59.
I'm capturing in PAL. My master is 720x576, deinterlaced and with slightly adjusted framerate because audio was desynced. At the end I want to edit this file (Premiere/iMovie) and upload in shorter parts to YouTube. According to your advice I applied two filters (crop <precise> to 704x576 + resize <precise bicubic A=-0,75> to 1440x1080) in one go with Video in "Full processing mode" and Audio in "Direct stream copy". I also applied UtVideo YUV422 BT.601 VCM codec as I did during deinterlacing.
Is it a proper way of preparing file for video hosting services? Also as Vdub2 is quite complex now, is it possible to encode it to a lightweight MP4 in the same go so it won't take that long to process?
Last edited by Stanley; 21st Nov 2020 at 17:38.
Yes, you can also encode for MP4 at the same time in VDub2. However, you also have to adjust the colorimetry since you're going from standard def to high def.
If your content is Standard Definition (SD) content use Rec.601; if your content is High Definition (HD) content use Rec.709 – unless the header of the content specifies otherwise.
Spline36Resize(768,576, 9, 0, 704, 576) # output width, output height, source left, source top, source width, source height
ConvertToYV24() Crop(9,0,-7,-0) # or Crop(0,0,704,576) ConvertToYV12()
Last edited by jagabo; 22nd Nov 2020 at 13:54.