CropResize - Cropping & resizing function (Avisynth & VapourSynth versions)

[tormento]

The ringing, or what looks like ringing, definitely exists in the source.
That is what I meant, probably in not my so clear english.

Can you share a unprocessed clip, preferably a clean and well contrasted one?

[hello_hello]

Here's 30 seconds containing 4:3 picture.
VTS_01_1.mkv (https://files.videohelp.com/u/210984/VTS_01_1.mkv)

Edit: I don't know where my head was at earlier, but I'm pretty sure I checked the video again after resizing it to 1440x1152 with PointResize, but I'd also cropped 8 pixels from each side. To simply double the width and height I should have resized to 1408x1152. It shouldn't matter though, given I upscaled with PointResize, should it?
I'll look at it again while resizing as I should have later.

[DTL]

The original analog sources was designed to be displayed at the physical screens with overscan and cropping edges of the physical image by physical frame of the screen/display. So all possible damaged edges of a frame (start/end lines and start/end parts of lines) expected to be cropped out by display and new transients to display's environment created by display (like LCD/CRT/plasma screen frame). If user want to display 4/3 on 16/9 the 'overscan+cropping hardware accelerated' feature of the standard displays need to be completely simulated at the active screen area of the non-standard display. To save from display resizer (or DAC before analog display) overshoot (halo or ringing depend on scaler kernel/filter size) the new transient to 'black' (or any other new border colour) need to be same conditioned as all other 'not-enchanced' transients in the active frame area. This was implemented in new AddBorders (r-param and others). If the overshoot happens this may cause additional distraction of a viewer to the edges of an image from the important center of an image. Other possible 'hardware' option to display 4/3 at 16/9 is to mask sides of the 16/9 screen with a (black) mask with sharp or other shaped edges.

[tormento]

Here's 30 seconds containing 4:3 picture.
I see that's a broadcasted content. There's little I can do to help you, as, usually, those kind of video are so much processed, by hw and not by sw, that they are beyond any reasonable recovery.

My hint, beside training some AI (it depends how much effort you want to put in the recovery) is to use Bore filter for the borders.

P.S: Pixel ratio isn't 1:1, as with almost every modern DVD. I suggest you to process the video as it is and to force proper SAR in the encoder, not to lose data.

[hello_hello]

Using the function I posted earlier to crop the old borders and a couple of pixels of picture each side, then adding new borders after resizing to square pixel dimensions seems to work pretty well. Enabling the AddBorders "R" argument when adding back the borders definitely makes a difference when the video is upscaled on playback. Any blurring of the borders is virtually unnoticeable (CropResize only uses R=2 when it's blurring option is enabled) but it's enough to prevent noticeable ringing or over-shoot when the player upscales the encoded video.

I think adding the R argument to AddBorders was DTL's idea. It was certainly a good one.