What resolution for capturing AVI from a PAL VHS player? 720 or 768?

[manono]

Yes, it's because Ive always took the term "upscale" as meaning resizing while preserving the original display aspect ratio of the image.

It's partly my fault as I was using it to mean 'increase the resolution', regardless of the original aspect ratio. I was gently corrected in subsequent posts, but I'm not entirely sure I was wrong:

to increase the size; scope, or scale of (something)

https://www.merriam-webster.com/dictionary/upscale
But that definition isn't applying specifically to video. Maybe I should have said 'upsize'. Does that include both 'upscale' and 'resize'?

[bergqvistjl]

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.

[DB83]

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.

[bergqvistjl]

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.

I've never done this before, so you're right, I was getting confused thinking the Output from VirtualDub was the resolution I was capturing at, i'm sorry. It's starting to make sense now

[bergqvistjl]

Let's keep this all straightforward (keeping it predominantly as PAL, since that's what you're talking about)...

1. There's the Analog video on you cam/vcr, etc.
   
2. There's the Digital stream after conversion from analog, BUT BEFORE BEING ENCODED AND STORED on hdd.
   
3. There's the Digital encoded file, AS STORED on your hdd.
   
4. There's the Digital encoded file, AS SHOWN on your monitor.
   
5. And there's the version you want/need to send to Youtube.

#1 is ??? x 625 lines, 576 of which are valid video. The ??? is because it is a continuous sweep, so theoretically infinite, but in practice & constrained by bandwidth, etc is likely ~300 equivalent if taken from VHS, up to 500-600 if taken off broadcast receiver, up to 700+ if taken from a broadcast camera/switcher.

#2 when captured by INDUSTRY STANDARD cards/devices (which follow BT.601 rules) is 720x576, or 702 or 704x576*. That's it. It is either 4:3 DAR or 16:9 DAR (much rarer). Either one of those DARs attached to any of those resolutions means the PAR is non-square (aka NOT 1:1). This is how it is coming in, REGARDLESS of what you set in your settings for capture encoding & storage. So don't waste.

#3 is where you get to decide how it is first stored & encoded. If you are trying to MAINTAIN BEST QUALITY, you will NOT do any resizing yet, and you will encode to lossless AVI. Thus, you should have it stored as 720x576 or 704x576 (possibly 702, but that isn't mod4 so might cause problems with some encoders). If your encoded/stored format supports DAR or PAR flagging (you only need to do 1 not both), here you can put this in. But it doesn't really matter if it doesn't support it, because this is just your storage format. So AVI, which doesn't normally support flagging is still ok. Note that even when some containers, like AVI, don't support AR flagging, the codec still might.

#4 when you VIEW it, you are now seeing how a certain player reads such a file and maps it to your monitor screen (whether in a window or in fullscreen). If you view this in a player that doesn't support flagging, and you didn't encode any AR flags in either the container nor the codec stream, this will now display on your (1:1) monitor as wrong/stretched. If you use a player that allows for adjustment of AR (e.g. VLC), you can just tell it to use that AR and it will correct your image's display on the screen, though it does nothing to the underlying file. If you use a player that supports AR flags, AND you were able to encode those flags, that player should be able to make that AR correction automatically. At this point, even though it is still stored at, say 704x576, it will show up as 768x576 (when using 4:3 DAR and being shown a 100% zoom in a window).

#5 if you want YT to give you the best download/streaming playback quality, you have to force it by uploading a 1080-level copy. That way, it (YT) allocates much more bitrate to the down-rezzed encodes it puts out. For 4:3 DAR, you RESIZE from 720/704 x 576 straight to 1440x1080 (best to apply QTGMC or similar deinterlacing as well to make it p60 instead of p30 or Interlaced - since that's what the original was - and p60 will look much smoother on YT). You should ignore the DAR or PAR as stored and let the final encoder treat it as square pixelled and include the necessary stretch manually, or depending on the encoder, let it read the AR flag and just tell it that final res (1440x1080) and it should auto give you a 1:1 PAR output.

Notice, you didn't need to resize AT ALL until going to #5. You didn't really need to crop at all unless you wanted to get rid of the black bars in #2->#3. You didn't need to do a lossy encode except in #5. This setup gives you the best quality sampling resolution (#2), the best quality encoding (#3 & #5), and the least destructive modifications (#2/3 or nothing when cropping, #5 when resizing, and #5 when deinterlacing).

Also, I'm pretty confident that your "768" setting is NOT what it's capturing stream as, but what it's being encoded/stored as, thus it is resizing if you do that. Maybe it's adding sharpening as well. Both not a good idea for encoders.

Scott


*occasionally a card allows for 1/2 or 1/4 D1 capture options natively, but those aren't recommended for quality.

OK, so I would like to remove the nominal analogue blanking area at the edge of the captured image, and then stretch what's left to compensate for that, as I believe this is what a CRT TV would do when playing a properly-mastered VHS.

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?

[Cornucopia]

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).
or
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.


Scott

[dellsam34]

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.

[bergqvistjl]

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.

That makes sense, thank you very much!

Now wondering if cropping to 704 is necessary or not, or if I'm overthinking that part

[FLP437]

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.

[FLP437]

Fig 3 included in the previous zip was wrong, this is the correct one.

[dellsam34]

That makes sense, thank you very much!

Now wondering if cropping to 704 is necessary or not, or if I'm overthinking that part

Like I said, 16 pixels squeeze is not noticeable, what is noticeable though is big grey bands on the sides of the frame, This was not an issue with CRT monitors as they have an overscan area, but with modern flat panels and widescreen it is there to see. It is lossless and can be done in one step with resizing, just add the crop filter first and the resize filter second and vdub will do them in one operation.

[bergqvistjl]

That makes sense, thank you very much!

Now wondering if cropping to 704 is necessary or not, or if I'm overthinking that part

Like I said, 16 pixels squeeze is not noticeable, what is noticeable though is big grey bands on the sides of the frame, This was not an issue with CRT monitors as they have an overscan area, but with modern flat panels and widescreen it is there to see. It is lossless and can be done in one step with resizing, just add the crop filter first and the resize filter second and vdub will do them in one operation.

That's what I meant though, the overscan area to the side of the frame, no? If I crop my raw 720 image to 704/702, that will remove those black bars. Then resize what's left to 768. Should I definitely crop those out is what I'm asking?

[dellsam34]

Yes, And 704, 702 is not a legal resolution.

[DB83]

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

[dellsam34]

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

[bergqvistjl]

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.

[DB83]

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.

[_Al_]

Kinda wish I could crop by 9 pixels on one side and 7 on the other, but avisynth wont let me, oh well.

you can, just follow the order:
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.

[dellsam34]

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.

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.

[Stanley]

For cropping and resizing I recommend Vdub2 in one single process and then use avisynth for encoding if you wish.

I have a similar concern so I decided to chip in.

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?

[manono]

...with slightly adjusted framerate because audio was desynced.

You should synch the audio to the video, not the video to the audio.

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.

If I'm understanding you correctly, you did it wrong. You should use AviSynth for this kind of work.

[dellsam34]

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?

Vdub2 has some encoding filters but I have never tried them to be honest.

[jagabo]

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.

You can do this with the resize filters' built in cropping values. For example:

Spline36Resize(768,576, 9, 0, 704, 576) # output width, output height, source left, source top, source width, source height

You could also do it by converting to RGB or YV24, cropping, then back to YV12:

ConvertToYV24()
Crop(9,0,-7,-0) # or Crop(0,0,704,576)
ConvertToYV12()

[dellsam34]

The cropping in script is trial and error since you don't have a way to monitor the edges you're cropping off that's why vdub is very handy.

[Firsh]

I get my "source" material from a 3rd party which I have no control over, VHS digitized with who knows what device, as 720p. I need to transcode this to a selfhosted video delivery platform (web). I decided to just use square pixels to avoid the mess, output is in mp4, RF 20 x264, 768x576 at whatever FPS my original is at (it's supposed to be PAL but my source says 29.97, go figure - not sure if I should slow that down?). I took a screenshot from my player, applied a 4:3 selection in photoshop and it nicely covered the video frame. In handbrake I crop 160 from left and right, then downscale that to my output res. I have black bars within that but if I were to crop a few seemingly random amounts more from each side while maintaining the 4:3, I'd chop off useful data from some sides, since the atrocious quality of VHS. Some sides are curved

[Attachment 60750 - Click to enlarge]
I guess if I don't mess with the cropping, the output will have a more nostalgic feel to it and it'll be clear this is from a VHS and people maybe will just accept that. Either that or I'm butchering this even more by discarding useful data (top left and bottom right)

[themaster1]

remove all that chroma noise please!! Nostalgic feel...yeah, more like lazy feel

avisource()
spotless()

[Alwyn]

I guess if I don't mess with the cropping, the output will have a more nostalgic feel to it and it'll be clear this is from a VHS and people maybe will just accept that. Either that or I'm butchering this even more by discarding useful data (top left and bottom right)

Nah, get rid of it. Only the purists will recognise it's VHS from that switching noise; others (including me) will just think it's ugly or slack editing. It's obvious it's an old video from the overall quality and 4:3 resolution; you don't need to deliberately leave all that rubbish in it.

Crop crop crop!

[lordsmurf]

The VirtualDub CCD filter works works no chroma noise.
Use it.