Log in

View Full Version : Workflow when PAR is not 1:1


Reign
14th November 2018, 22:49
So, i have a 720x480 source but the Pixel Aspect Ratio is not 1:1 (DVD).

I've been told to use the following workflow with VS > Encode
1. Resize to match pixel aspect ratio (720x540 in this case)
2. Crop (optional)
3. apply filters
4. encode

Now, I'm pretty sure this is correct because this way the Vapoursynth filters are being applied at the correct aspect ratio. But another person was telling me that I shouldn't resize with Vapoursynth at all, and instead just use --sar on the encode instead. The result will both be the correct, but I'm concerned this will mean the filtering will not work as it should, is this correct?

poisondeathray
14th November 2018, 23:14
So, i have a 720x480 source but the Pixel Aspect Ratio is not 1:1 (DVD).

I've been told to use the following workflow with VS > Encode
1. Crop (optional)
2. Resize to match pixel aspect ratio (720x540 in this case)
3. apply filters
4. encode

Now, I'm pretty sure this is correct because this way the Vapoursynth filters are being applied at the correct aspect ratio. But another person was telling me that I shouldn't resize with Vapoursynth at all, and instead just use --sar on the encode instead. The result will both be the correct, but I'm concerned this will mean the filtering will not work as it should, is this correct?


It depends on which filter , specifically.

For example, some overlays would require par correction, either on the source or overlay otherwise there will be AR distortion . Some denoising/ deblocking filters work best on the original macroblock compression sizes such 16x16 blocks, and resizing beforehand will limit the effectiveness . ie. in that case the filter is addressing issues that were caused by the compression while it was in 720x480.

In general, resizing is a lossy procedure (some exceptions like nearest neighbor up/down powers of 2 multiples) , so you want to avoid it if possible

But the output goal, or how it's going to be used might influence your decision too - eg. if the destination receiving hardware/software is only meant to be square pixel you're resizing it anyways

Reign
15th November 2018, 00:14
Well, what would you recommend? I'm only using QTGMC and BM3D + knl to denoise luma/chroma. The output is to be used only for software/hardware that has a 1:1 PAR.

poisondeathray
15th November 2018, 01:34
Well, what would you recommend? I'm only using QTGMC and BM3D + knl to denoise luma/chroma. The output is to be used only for software/hardware that has a 1:1 PAR.

Apply filters to the original 720x480, then resize if you have to

Boulder
15th November 2018, 19:07
Why wouldn't the filters work? They don't know what exactly is in your source, they work on single pixels or areas regardless of the aspect ratio. So just filter as it is, crop the black borders off beforehand if there are any and set the correct --sar when you encode.

Reign
15th November 2018, 20:52
I know the filters will work, but i was concerned that since the filters are being applied at 720x480 (which is stretched since vs assumes square pixels) that the filters wouldn't be 100% accurate since the filters are being applied before it gets passed to x264 which stretches it horizontally to account for the different PAR in the source.

_Al_
16th November 2018, 02:32
I'd be rather concerned about correct ar, if its coming from DVD, you might need to cut off something left and right i, total 16pixels and only then to resize to 4:3.
Then you might crop to keep ar, but why anyway.

Q3CPMA
17th November 2018, 16:26
Personally, I always do "deinterlacing/IVTC -> resize to its square PAR dimensions -> crop -> other filters" since having a PAR != 1:1 just means you're gonna resize when viewing the video, which is useless when you could do it during encoding.