1 Reply by Minimunch57

(4 replies, posted in Using SVP)

Chainik wrote:

it IS implemented from the very beginning big_smile

add a "user defined option" (in Application settings panel)
title: <insert yours>
script name: rife_trt_keepsize
scope: FRC profile
ON or OFF

I have done a few tests and this does indeed work. Out of curiosity, why is this not default behavior? Was my application just misconfigured?

Go to forum: Using SVP

2 Reply by Minimunch57

(4 replies, posted in Using SVP)

Ah, I figured it would've been possible already! Great work, thanks Chainik!

Go to forum: Using SVP

3 Reply by Minimunch57

(4 replies, posted in Using SVP)

Do any developers have any thoughts about this? Could this fix be implemented?

Go to forum: Using SVP

4 Topic by Minimunch57

(4 replies, posted in Using SVP)

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!

Go to forum: Using SVP

5 Reply by Minimunch57

(2,340 replies, posted in Using SVP)

Minimunch57 wrote:

From my testing comparing v4.6 to v4.8, I only saw the transcoding fps drop by around 3 on average. Not bad. In most cases, artifacts were reduced with the newer model. In rare cases, frames contained new artifacts and are slightly worse than what v4.6 produced. As I said though, this is rare. v4.8 is certainly an overall visual improvement. I did not notice any major difference with my thermals, but I did not measure. I just checked during a v4.8 test and the numbers I was getting seemed similar to what I remember getting previously with v4.6.

It is also worth noting that I measured slight savings in file sizes with the newer v4.8 model. My guess is that this is related to how video data is saved and processed. With less artifacts and random, inconsistent splotches of stray pixels, there are less pixel changes to store between video frames. This leads to minor reductions in the size of the outputted file. On a 3-pass interpolation test, I got a file roughly 10% smaller in size. For normal transcoding usages, I wouldn't expect 10% though. Maybe others can comment on their results and correct me on the logic here if I am wrong.

I just wanted to update and say that I performed visual testing with v4.9, and the results were, in most cases, worse compared to v4.8. In frame comparisons, v4.9 won in only a few cases, but v4.8 was far more consistent and preserved more details in both 2D and 3D scenes. It seems like the consensus on here is that v4.9 provided some performance improvements, but it seems to have worsened the visuals in my testing. Maybe coincidentally, my previous theory seems to be holding up, as v4.9 transcoding outputs yielded slight file size increases rather than decreases.

EDIT:
Forgot to specify that I was running v4.9, NOT v4.9 v2.

Go to forum: Using SVP

6 Reply by Minimunch57

(2 replies, posted in Using SVP)

Minimunch57 wrote:

https://github.com/AmusementClub/vs-mlr … l-20220923

For anyone looking for updates on this, it is being discussed in another thread here: https://www.svp-team.com/forum/viewtopi … 1&p=37
The link to the onnx files for v4.8 is quoted above. They are inside the attached 7z file on the GitHub release.

As @MAG79 said above, you can manually add v4.8 to your SVP installation in the meantime. Locate your SVP 4 installation (likely in Program Files (x86) if you are on Windows). Go into rife/models/rife and replace one of the existing models with the new one. You have to rename the new model file to have the same name of the model you are replacing in order for the application to recognize and use it. Once you have replaced the model, open SVP 4 and go to the Video Profiles tab. Edit RIFE AI engine and switch the AI model setting to use the model you have just replaced. As of writing this post, you should have the options 4.4 and 4.6. If you are using TensorRT, you will have to repeat the waiting period before transcoding a new resolution. This can be a good indicator that you successfully replaced and changed models.

Go to forum: Using SVP

7 Reply by Minimunch57

(2,340 replies, posted in Using SVP)

From my testing comparing v4.6 to v4.8, I only saw the transcoding fps drop by around 3 on average. Not bad. In most cases, artifacts were reduced with the newer model. In rare cases, frames contained new artifacts and are slightly worse than what v4.6 produced. As I said though, this is rare. v4.8 is certainly an overall visual improvement. I did not notice any major difference with my thermals, but I did not measure. I just checked during a v4.8 test and the numbers I was getting seemed similar to what I remember getting previously with v4.6.

It is also worth noting that I measured slight savings in file sizes with the newer v4.8 model. My guess is that this is related to how video data is saved and processed. With less artifacts and random, inconsistent splotches of stray pixels, there are less pixel changes to store between video frames. This leads to minor reductions in the size of the outputted file. On a 3-pass interpolation test, I got a file roughly 10% smaller in size. For normal transcoding usages, I wouldn't expect 10% though. Maybe others can comment on their results and correct me on the logic here if I am wrong.

Go to forum: Using SVP

8 Reply by Minimunch57

(2 replies, posted in Using SVP)

My post did not go through?

[Edit]
My original post was just stating that RIFE GitHub added a new v4.7 model optimized for anime scenes. Was wondering if it was possible to add that to SVP 4's transcoding on PC. The current v4.6 model is great for 3D, but is not as great with 2D scenes.

[Edit 2]
ANOTHER New Model Added October 23
They added a v4.8 model literally today as well. https://github.com/hzwer/Practical-RIFE … model-list
https://github.com/AmusementClub/vs-mlr … l-20220923

[Edit 3]
My bad, I should have done more digging on the forum before posting. I see that I can add it myself in the meantime. Sorry to bother!

Go to forum: Using SVP