Rate my Setup - Capturing Digital8 and Analog

[Sharc]

A complete description should be found in ISO/IEC13818 or in the original DVD spec which probably none of us has ever seen (?).

I have it. Costed a fortune to my company in late nineties. If you need any info from there just let me know

Thanks. I just found the ISO/IEC13818-2. There it is clear from Table 6-3 that the "1:1 aspect ratio" applies indeed for the Pixel Aspect Ratio (aka Sample Aspect Ratio), while the other numbers are for the Display Aspect Ratio (DAR).

[lollo]

In addition in the 3rd volume (video specification) of the DVD specification, you can find the well known numbers about resolutions, aspect ration, 625/50TV, 720/53.33usec, 704/52.15usec, etc:

[Bermuda1]

If I only crop to 704x576, I dont only have head switching noise but would have to keep more noise on the left and right side (distorted colors) that I simply dont want in the footage that I will combine with other clips for a family movie. Cropping how I like will result in different clips with different aspect ratios, which won't be great for combining either. Alwyns approach, resizing to 768x576 seemed logically, to get everything on a common basis. If you say that this is not the "right" way to do it, could you please recommend what I do instead?

Are you serious? If you want to remove more than 8+8 pixels on the side because you have defects, you just mask as you do with the head switching noise, for example: crop(16,2,-16,-10).addborders(8,2,8,10).
You do not have to crop "as you like" but as it should be done.

I was serious, yes . But thats why I am here, to learn. So just to clarify, when you say "you do not crop as you like but as it should be done" and given your example, I understand that I should crop and add borders so that I end up with a video in 704x576? Right? I mean that would work too, as all my clips would then be 704x576 for editing/combing.

If you absolutely want 768x576 square pixels and you have to crop random numbers then you shoud take into account the 4:3 aspect ratio (ant the PAR). I see now that Sharc already talked about excel files and math, apply it!

So actually I did set up an Excel - its just that I need confirmation whether I am even on the right track if I wanted to set up square pixels (PAR 1:1).
I start with an original width and height of 720 and 576 respectively. In my Excel I then e.g. calculate how many pixels I need to take off the sides for each pixel I take of the top [cropped pixels sides / (4/3)]. My question is, do I start applying this method/calculation straight away for each pixel that I crop or do I first take off 16 pixels from the sides, and only then, start applying the above formula for every pixel I take off the top?

Maybe the OP uploads a snippet of his unprocessed video capture so we can give specific help for his particular case

Please find a snippet of the original .avi file attached. There is head switching noise that I wanted to get rid off and especially on the right side there is some purple colloration that I also wanted to crop out. All of this would require cropping more than 16 pixels off the sides. The idea with the resize came because I have several video files that would require different cropping and I did not want to combine them having different aspect ratios. If there is a better way of getting to where I want (i.e. Rec.601 compliant) I am happy to follow that approach. Is it the suggestion by lollo to crop and mask?

Thanks!

[Sharc]

Either you do as lollo suggested with masking, or if you absolutely want square pixels, 4:3, no borders, for example:

AVISource("Original.avi")
assumeTFF()
QTGMC(preset="fast")  #deinterlacing
Crop(12, 0, -18, -12) #crops the fuzzy left and rights and the headswitching
LanczosResize(768, 576)   #or any other 4:3  DAR, like 1440/1080

Take note that when you resize to 768x576 your TV will upsize again which is not the very best, but "it works" (assuming your TV accepts 768x576 of course and upscales it correctly; otherwise 1440x1080 is safer).

[lollo]

Sharc, should not be the frame before resizing 690x552 (or 705x564 -> 706x564 to avoid odd numbers) before resizing to keep proportions?

[Sharc]

My thoughts:
His captured frame is 720x576, PAL
Assuming Rec601 compliant capturing the PAR of the capture is ~12/11=1.090909... (approx. of the exact ITU PAR)
After cropping (12,0,-18,-12) the remaining cropped picture is 690x564. PAR is still 12/11 because cropping does not alter the PAR.
Now we resize to square pixels, means changing the PAR from 12/11 to 1/1, setting the resized hight to 576.
=> the resized width becomes 768.743, calculated as 690/564x1.0909091/1.0x576.
=> 768.743 finally rounded down by 0.743 pixels to 768 => 768/576=4:3.

[lollo]

My thoughts:
His captured frame is 720x576, PAL
Assuming Rec601 compliant capturing the PAR of the capture is ~12/11=1.090909... (approx. of the exact ITU PAR)
After cropping (12,0,-18,-12) the remaining cropped picture is 690x564. PAR is still 12/11 because cropping does not alter the PAR.
Now we resize to square pixels, means changing the PAR from 12/11 to 1/1, setting the resized hight to 576.
=> the resized width becomes 768.743, calculated as 690/564x1.0909091/1.0x576.
=> 768.743 finally rounded down by 0.743 pixels to 768 => 768/576=4:3.

Alrigth, you take into account the 704x576 active frame, and the numbers are ok. I wrongly used 720x576 in my quick calculation and made a mistake.

To OP: if you are not familiar with complex PAR/SAR number/equations you simply define the heigth after cropping (564) and then find the appropriate width as 704 * heigth after cropping / 576 = 704 * 564 / 576 = 690.
So 690x564 is the correct frame after cropping before resizing.

If you prefere you can start with the width after cropping instead of the heigth: given width after cropping 690 pixels, the heigth to respect proportions is 576 * width after cropping / 704 = 576 * 690 / 704 = 564.

One dimension fixed, the other is derived, so you do not have the freedom to crop as you wish, and forced to remove part of the picture or leave garbage/mask anyhow. With masking and rebuilt of original 704x576 frame there is no issue, but you have black borders. With PAR definition (if supported) you can crop whatever you want.

[Bermuda1]

@Sharc @lollo
Thanks to both of you. Really helpful. I adapted my Excel as per your guidance and the resize looks perfectly in line with the proportions of the original capture.

For anyone who might appreciate it, attached is the Excel I use for the calculations based on the above formulas:
https://files.videohelp.com/u/311453/Crop_Before_Resize_Calculation.xlsx

I have decided to use the resize as I want to add several video clips together for a family movie and the resized versions just make it easier to work with. Masking the distortions is not great for that as the black bars would differ from clip to clip. However, for any single clip videos, I will crop to 704x576 and then use the mask (add borders) function to get rid of distortions or, as I have done so far for single clips, crop as I like and encode using SAR 12/11. Seems a good compromise overall for my use.

Thanks again for the support!

P.S. @Alwyn: Your initial description, taking off 16 pixels from the sides and then cropping so that the 4:3 ratio is applied was correct by the way. I must have made a mistake in my initial Excel. Thanks to you too!

[lollo]

Masking the distortions is not great for that as the black bars would differ from clip to clip.

True, but if you crop differently you have an unwanted "zoom effect" from clip to clip. Choose your poison

[Sharc]

@bermuda1: Glad to see that you got it right.
Just a footnote to the square pixel resizing approach. The example I gave was for 768x576 for 4:3 to make the link to the former discussions. In practice I would prefer to go to 1440x1080 as this is a standard 4:3 square pixel resolution. 768x576 is a custom format which has to be upscaled again by the TV, and not all TVs may do it correctly as it is a non-standard frame size, even though it is 4:3 DAR. There is a certain risk I think. 1440x1080 is just more compliant these days.

[lollo]

+1

if you have to resize for TV, better upscale to HD (it will also remove one additional lossy resizing step)

[Bermuda1]

Ok, I will give it a try and instead of using BicubicResize(768, 576) I go with BicubicResize(1440, 1080). The cropping calculations remain the same, I guess?

Just out of curiosity, if I were to crop to 704x576 and mask any noise, encode using SAR 12/11 wouldn't the (modern) TV also upscale and essentially perform a (potentially) lossy resize step?

[lollo]

Ok, I will give it a try and instead of using BicubicResize(768, 576) I go with BicubicResize(1440, 1080). The cropping calculations remain the same, I guess?

use nnedi3 (for example), not BicubicResize

nnedi3_rpow2(rfactor=2, nns=4, qual=2, cshift="Spline36Resize", fwidth=1440, fheight=1080)

Just out of curiosity, if I were to crop to 704x576 and mask any noise, encode using SAR 12/11 wouldn't the (modern) TV also upscale and essentially perform a (potentially) lossy resize step?

The lossy resize step you remove in this case is the 768x576 resizing in AviSynth. And being 704x576 a standard is less "risky" than 768x576 as Sharc noted. Moreover, with the 704x576, you can simply specify the DAR (well implemented everywhere) and not the SAR.

[Sharc]

..... The cropping calculations remain the same, I guess?

Yes.

[Alwyn]

@Alwyn: Your initial description, taking off 16 pixels from the sides and then cropping so that the 4:3 ratio is applied was correct by the way. I must have made a mistake in my initial Excel. Thanks to you too!

My pleasure, glad you've "got" it.

Masking the distortions is not great for that as the black bars would differ from clip to clip.

True, but if you crop differently you have an unwanted "zoom effect" from clip to clip.

In real-world editing such as home videos, this will not be a problem. If you're editing the same clip, you will have already tidied up/cropped the edges. If it's a different clip, the zoom will be irrelevant to the previous clip.

Yes, blanking with black bars might work for "cropping" a whole movie, TV ad or similar, but for editing home videos with different input clips, different-sized black borders will look very amateurish. And now, with YT now displaying the actual frame, any black borders, especially uneven ones, look as bad as those videos that have now cropping at all, showing the VHS headswitching noise and hairy wobbly edges.

And of course if you have a lot of this stuff to do, it's much easier just to drop your deinterlaced 768x576 files into an NLE and use the 4:3 cropping tool to get rid of all the crud (provided you've got the 16 side pixels sorted out). I am sometimes cropping "in" more anyway because the subject is too far away.

[Bermuda1]

The lossy resize step you remove in this case is the 768x576 resizing in AviSynth. And being 704x576 a standard is less "risky" than 768x576 as Sharc noted. Moreover, with the 704x576, you can simply specify the DAR (well implemented everywhere) and not the SAR.

Got it, thanks. So for best quality/least losses either go for 704x576 (DAR specified) before encoding, or if resize is necessary rather go for 1440x1080 since that is a standard vs. non-standard/custom 768x576. File size will surely be much bigger then, but thats ok.

Anyways, if I need to crop out more and do so as needed, resulting in something other than 704x576 format, I will have to specify SAR 12/11 for x264 encoding (as I learned from you guys). So in that specific case, just to be clear, a modern TV would have to be able to interpret the SAR flag and upscale correctly performing a (potentially) lossy resize step? Is that the right conclusion? Just trying to wrap my head around all the options here...

And of course if you have a lot of this stuff to do, it's much easier just to drop your deinterlaced 768x576 files into an NLE and use the 4:3 cropping tool to get rid of all the crud (provided you've got the 16 side pixels sorted out). I am sometimes cropping "in" more anyway because the subject is too far away.

Ok, I see. I would assume though that it would have no impact on quality whether I crop the clips beforehand using Avisynth+ or later in NLE software e.g. DaVinci Resolve. I would actually prefer the first option then. Assuming that in NLE software, I would have to create the final home movie and only then crop (the whole thing), I would likely have to crop away more than needed in some of the clips that are part of the overall movie.

[lollo]

Is that the right conclusion? Just trying to wrap my head around all the options here...

yes

I would assume though that it would have no impact on quality whether I crop the clips beforehand using Avisynth+ or later in NLE software e.g. DaVinci Resolve.

in fact the cropping should be the first operation before processing in AviSynth so the filter can be more effective on the borders working with a clean frame (deinterlacing, stabilizing, denoising, sharpening, ...)

[Bermuda1]

in fact the cropping should be the first operation before processing in AviSynth so the filter can be more effective on the borders working with a clean frame (deinterlacing, stabilizing, denoising, sharpening, ...)

Okay, but I thought that since my original video is interlaced, I have to deinterlace first, crop then and apply further filters/denoising afterwards in Avisynth or risk damaging the video if I crop before deinterlacing. Or would this not apply when I crop according to your formula from above post or crop to 704x576 only?

[lollo]

For interlaced material you need to crop mod 2 before deinterlacing.
Cropping after deinterlacing is also ok, QTGMC in general and in practice has no issues with black borders and head switching nose.
For field matching, cropping before processing is generally better.
I always crop before anything else.

[Sharc]

For interlaced material you need to crop mod 2 before deinterlacing.

Little footnote:
Yes, mod 2 is correct for 4:2:2 interlaced captures - as it should be, and applies for the OP's captures.
For interlaced YV12 4:2:0 the vertical cropping has to be mod 4. Just in case the OP intends to crop YV12 (DVD, Blu-ray, exported as YV12 ....) interlaced video

[Sharc]

And of course if you have a lot of this stuff to do, it's much easier just to drop your deinterlaced 768x576 files into an NLE and use the 4:3 cropping tool to get rid of all the crud (provided you've got the 16 side pixels sorted out). I am sometimes cropping "in" more anyway because the subject is too far away.

For the sake of completeness: The 16 pixels/704 side crop mantra only applies for captures following the Rec.601 or original DVCAM standard, means with PAR of ~12/11 (for 4:3 "PAL") - which should be the case unlesss something is flawed or the standard has been violated.
It doesn't apply for example for your Huffy capture (with a PAR of 16:15) which we discussed some time ago in the context of DV cameras (lazy to find the thread).
That's why I always say in a first step one has to agree on the PAR of the picture. Otherwise it's like finding the way on a map when you don't know where you are.

[Alwyn]

Assuming that in NLE software, I would have to create the final home movie and only then crop (the whole thing), I would likely have to crop away more than needed in some of the clips that are part of the overall movie.

I assume most reasonable NLEs allow you to split your source clips into segments so you can work on each segment separately; mine does. So if you come across a part of the capture that has bigger bars or ones that are lopsided, you can crop/trim just that bit without upsetting the rest of the capture. I have a 4:3 box in mine that I just resize and drag over the video to crop in proportion with no mental gymnastics). This happens to me when a second-generation tape has been compiled with a bunch of clips from various times (when we were saving money on videotape).

[Bermuda1]

And of course if you have a lot of this stuff to do, it's much easier just to drop your deinterlaced 768x576 files into an NLE and use the 4:3 cropping tool to get rid of all the crud (provided you've got the 16 side pixels sorted out). I am sometimes cropping "in" more anyway because the subject is too far away.

For the sake of completeness: The 16 pixels/704 side crop mantra only applies for captures following the Rec.601 or original DVCAM standard, means with PAR of ~12/11 (for 4:3 "PAL") - which should be the case unlesss something is flawed or the standard has been violated.
It doesn't apply for example for your Huffy capture (with a PAR of 16:15) which we discussed some time ago in the context of DV cameras (lazy to find the thread).
That's why I always say in a first step one has to agree on the PAR of the picture. Otherwise it's like finding the way on a map when you don't know where you are.

Good point, thanks. Just checked that. My DV captures for Digital8 tapes have 720x576 with DAR 4:3. PAR 16:15. I wont have to crop anything in those videos. Since no crop is necessary, I woudn't resize (no mixing of those clips will happen).

[Bermuda1]

Actually, one more question. For editing in DaVinci, I read that its better to go with e.g. AppleProRes as format (.mov) instead of encoding the clips as x264 (.mp4) and then editing those in DaVinci (or any other NLE software). I would then only encode the ProRes movie to x264 after editing is completed in DaVinci. For the crops, deinterlace, resize and other filters in Avisynth+ this has no relevance, right? I would simply only compress differently (as AppleProRes) in VirtualDub2.

[Sharc]

Actually, one more question. For editing in DaVinci, I read that its better to go with e.g. AppleProRes as format (.mov) instead of encoding the clips as x264 (.mp4) and then editing those in DaVinci (or any other NLE software). I would then only encode the ProRes movie to x264 after editing is completed in DaVinci. For the crops, deinterlace, resize and other filters in Avisynth+ this has no relevance, right? I would simply only compress differently (as AppleProRes) in VirtualDub2.

Yes. ProRes as a nearly lossless intermediate format is fine, or another lossless or nearly lossless intermediate format which DaVinci accepts, avoiding extra compression artifacts. (.mov or .mp4 are just containers. x264 with --qp 0 or --crf 0 is also lossless btw.).

[Sharc]

Good point, thanks. Just checked that. My DV captures for Digital8 tapes have 720x576 with DAR 4:3. PAR 16:15. I wont have to crop anything in those videos. Since no crop is necessary, I woudn't resize (no mixing of those clips will happen).

Can't tell for sure whether your DV is truly 16:15. It could also be 12:11 with the left and right side padded to 720 with picture data. You would have to do a circle test like Alwyn's wheel to be certain. A consensus from former discussions on DV was that it depends on the videocam model. I can't confirm myself though.