Transcoding with RIFE - 4K Video Height CROPPED by 16px

Hello everyone,

I have repeatedly run into an issue where SVP 4 Pro will crop 16 pixels off the height of any 4K videos during transcoding, even if cropping is disabled.
Through troubleshooting I have discovered a fix which could potentially be implemented directly into SVP. Here is the breakdown.

RIFE requires a tile size divisible by 32.
4K video has a resolution of:

3840x2160

And obviously...

3840/32 = 120

2160/32 = 67.5

Since the height of 2160 is not cleanly divisible by 32, SVP corrects for this by cropping 16 pixels off of the height within:

...\AppData\Roaming\SVP4\scripts\ffff.py

via...

input_m = input_m.std.CropRel(0,0,0,16)

While this allows transcoding to continue, it is not an ideal solution. Though minimal, we do lose data, and the aspect ratio is inevitably not preserved. Yes, you can fix the aspect ratio by scaling the resolution back up after interpolation, but still not ideal.
Instead, we can add 16 pixels to the video height with a border, then crop those 16 pixels from the output after interpolation.

We change the aforementioned line of code to:

input_m = input_m.std.AddBorders(0,0,0,16)

...and add the following just before smooth.set_output() at the end of ffff.py:

smooth = smooth.std.CropRel(0,0,0,16)

This new code adds a 16 pixel border to the video height, making the resolution 3840x2176. Since 2176/32 = 68, RIFE does not complain.
After interpolation, the extra height from the border is then cropped, leaving us with the original resolution and aspect ratio without losing the bottom 16 rows of pixels.

My knowledge of SVP 4 is pretty surface-level, but here's how to trick it into running with the adjusted code:
1. Load a 4K video into the SVP 4 Pro Transcoding tab and select the RIFE profile. Do not start yet.
2. Find ...\AppData\Roaming\SVP4\scripts\ffff.py, make the necessary edits, then change the file permissions to only allow Read & execute.
3. Go back to SVP 4 Pro and start.

Unless I'm missing something obvious, this solution seems quite efficient and solves the original problem with minimal data loss. It should also be fairly simple to implement as a fix or toggle into SVP 4 Pro.
I look forward to reading your thoughts. Thanks!