You are not logged in. Please login or register.
SmoothVideo Project → Using SVP → New RIFE filter - 3x faster AI interpolation possible in SVP!!!
Hey @flowreen91, I just wanted to say a huge thank you for your help! Thanks to your clear instructions, I was finally able to use the R79. I actually brought this topic up a few posts back, but no one really showed any interest at the time. I truly appreciate you taking the time to help me and for bringing this topic back to the table. Thanks again!
> I was finally able to use the R79
so, is it any better?
(hint: no 
)
Drakko01 wrote:could you share how exactly you got R79 to work with SVP?
I'm trying to test it myself, but MPC-HC crashes instantly as soon as I try to use R79.I had only tested their performance with vspipe: SVP's RIFE (TRT and TRT-RTX) and svpflow scripts at 1080p and 4K on R73 and R79 (RIFE also on R80 via a ported plugin), all the same speed within noise.
If you actually want to run R79, try this (works in both MPC-HC and SVP's mpv, RIFE and seeking fine). Don't replace anything in SVP's folder, both players can be pointed at a separate R79 folder instead:
1. Download VS-R79.zip from here and extract it to C:\ so you get C:\VS-R79\python.exe
https://drive.google.com/drive/folders/ … XX-S2JMOXD2. Add a user environment variable (Win+R, type SystemPropertiesAdvanced, Environment Variables..., New under "User variables"):
Name: VSSCRIPT_PATH
Value: C:\VS-R79\Lib\site-packages\vapoursynth\vsscript.dll3. Close SVP and the player completely, start them again and play a video.
The player then loads R79 from that folder instead of SVP's R73. To undo, delete the variable.
The zip is just SVP's own Python 3.12 files plus the official R79 package from GitHub.
I'm using standalone MPC-HC and standalone vapoursynth, I followed your instructions to copy the rife folder and generate.js into SVP 4 folder, and added the rife_rtx profile, but when I open a video file, it will say failed to load C:\Program Files\SVP 4\rife\akarin.dll. If I copy akarin.dll to your rife folder and reopen the video, it will say Importing the numpy C-extensions failed. Please check the screenshot attached.
when I open a video file, it will say failed to load C:\Program Files\SVP 4\rife\akarin.dll. If I copy akarin.dll to your rife folder and reopen the video, it will say Importing the numpy C-extensions failed.
Your screenshot shows the cause: your VapourSynth runs on Python 3.13, but the rife\pylib folder in my zip is built for Python 3.12, which is what SVP's own VapourSynth uses, so numpy can't load.
To fix it, either download the archive again and copy it over the same way:
https://drive.google.com/drive/folders/ … XX-S2JMOXD
or run this command, it installs the Python 3.13 versions of the packages TensorRT-RTX needs into your own Python (numpy, onnx and onnxconverter-common to convert the model to fp16, onnxruntime to prepare the v2 models):
d:\develop\python\python313\python.exe -m pip install numpy onnx onnxconverter-common onnxruntime
Your own packages are used before pylib, so nothing else needs changing. I reproduced both of your errors here with Python 3.13 + R79, and after this command RIFE worked with both the normal and v2 models.
About akarin.dll: the zip's rife folder is meant to be copied on top of SVP's rife folder (merge and overwrite), not to replace it. SVP's own rife folder already has akarin.dll, the models and the rest. If yours was replaced, restore it (SVP's maintenance tool or a reinstall), then copy the zip's rife folder over it again.
redraiderj wrote:when I open a video file, it will say failed to load C:\Program Files\SVP 4\rife\akarin.dll. If I copy akarin.dll to your rife folder and reopen the video, it will say Importing the numpy C-extensions failed.
Your screenshot shows the cause: your VapourSynth runs on Python 3.13, but the rife\pylib folder in my zip is built for Python 3.12, which is what SVP's own VapourSynth uses, so numpy can't load.
To fix it, either download the archive again and copy it over the same way:
https://drive.google.com/drive/folders/ … XX-S2JMOXDor run this command, it installs the Python 3.13 versions of the packages TensorRT-RTX needs into your own Python (numpy, onnx and onnxconverter-common to convert the model to fp16, onnxruntime to prepare the v2 models):
d:\develop\python\python313\python.exe -m pip install numpy onnx onnxconverter-common onnxruntime
Your own packages are used before pylib, so nothing else needs changing. I reproduced both of your errors here with Python 3.13 + R79, and after this command RIFE worked with both the normal and v2 models.About akarin.dll: the zip's rife folder is meant to be copied on top of SVP's rife folder (merge and overwrite), not to replace it. SVP's own rife folder already has akarin.dll, the models and the rest. If yours was replaced, restore it (SVP's maintenance tool or a reinstall), then copy the zip's rife folder over it again.
Thanks, it works! I tested with one 3.5 minutes 4K 30fps video on my 5070Ti, with SVP stock settings + RIFE 4.4v2 model I got 296 skipped frames, while with rtx I got 104. Looks like I still can't perfectly run a 4K 30fps video, but it improves. Also, the engine building process takes significantly less time. Thanks a lot, and hopefully SVP can take this solution into their development roadmap.
> I was finally able to use the R79
so, is it any better?
(hint: no
Very funny! But as I’ve stated many times, I prefer to keep all my components updated unless it breaks something. If that’s really your way of thinking, why do you keep updating it every now and then anyway? And in such a lazy manner. Do you honestly, truly believe that every single VapourSynth version works exactly the same? Because if that’s your brilliant logic, why didn't you just freeze the whole thing at r31 and call it a day.
> Do you honestly, truly believe that every single VapourSynth version works exactly the same?
in terms of performance of a complicated math running in its own native libraries - yes, sure
> why didn't you just freeze the whole thing at r31 and call it a day.
because other open source components depend on newer versions, even if there're no real benefits
this is how open source world works
for example, on macOS mpv should be installed from Homebrew repo, which provides only the latest versions of everything (right now R80) even if it breaks things
> Do you honestly, truly believe that every single VapourSynth version works exactly the same?
in terms of performance of a complicated math running in its own native libraries - yes, sure
You are proving my exact point. Looking at this purely in terms of 'performance math' is where your approach fails to see the bigger picture.
A version can have identical math performance but be fundamentally broken in stability, or introduce visual artifacts that completely ruin the output. Evaluating a tool solely by its performance metrics while completely ignoring stability and image quality.
Software updates aren't just about benchmark numbers or raw execution speed in native libraries. Different VapourSynth versions introduce critical bug fixes, memory leak resolutions, stability patches, and changes in how frames are handled or rendered.> why didn't you just freeze the whole thing at r31 and call it a day.
because other open source components depend on newer versions, even if there're no real benefits
this is how open source world works
for example, on macOS mpv should be installed from Homebrew repo, which provides only the latest versions of everything (right now R80) even if it breaks things
Once again, you are proving my exact point. Software interactions between different versions lead to entirely different results (sometimes).
At the end of the day, the most important thing to me is the final visual result. I care about the quality of the image on my screen, not how fast the engine building process take to build or have a faster seek.
I’m sure you could have given me the same answer Flowreen91 just did when I initially asked about this in my previous post, but you chose not to, but now that someone else did, you only show up to nitpick and minimized.
redraiderj wrote:when I open a video file, it will say failed to load C:\Program Files\SVP 4\rife\akarin.dll. If I copy akarin.dll to your rife folder and reopen the video, it will say Importing the numpy C-extensions failed.
Your screenshot shows the cause: your VapourSynth runs on Python 3.13, but the rife\pylib folder in my zip is built for Python 3.12, which is what SVP's own VapourSynth uses, so numpy can't load.
To fix it, either download the archive again and copy it over the same way:
https://drive.google.com/drive/folders/ … XX-S2JMOXDor run this command, it installs the Python 3.13 versions of the packages TensorRT-RTX needs into your own Python (numpy, onnx and onnxconverter-common to convert the model to fp16, onnxruntime to prepare the v2 models):
d:\develop\python\python313\python.exe -m pip install numpy onnx onnxconverter-common onnxruntime
Your own packages are used before pylib, so nothing else needs changing. I reproduced both of your errors here with Python 3.13 + R79, and after this command RIFE worked with both the normal and v2 models.About akarin.dll: the zip's rife folder is meant to be copied on top of SVP's rife folder (merge and overwrite), not to replace it. SVP's own rife folder already has akarin.dll, the models and the rest. If yours was replaced, restore it (SVP's maintenance tool or a reinstall), then copy the zip's rife folder over it again.
Just a side question, I noticed an issue regarding vertical videos https://www.svp-team.com/forum/viewtopic.php?id=8025, I wonder if you have any ideas why vertical videos consume more than horizontal videos?
I wonder if you have any ideas why vertical videos consume more than horizontal videos?
I tested it here (RTX 5090 Laptop, stock TensorRT, x2 to 60 fps). The difference is small:
RIFE itself runs at the same speed on both. 4K in VSPipe, 3 runs each: 4.4 did 74.6 fps landscape vs 75.0 portrait, 4.4_v2 81.5 vs 79.7.
The difference comes from SVP's script for MPC-HC: it cuts 16 rows off the bottom and pads the frame for RIFE, so a 4K landscape video ends up as 3840x2144 and a portrait one as 2176x3840, about 1.5% more pixels. In MPC-HC with your model (RIFE 4.4 v2 on TensorRT) both held 60 fps at about the same GPU power, 126 W vs 127 W on average.
The rotated monitor made no difference either. I rotated my second monitor to portrait and played both files fullscreen on it in MPC-HC: both held 60 fps, with the same jitter as on a landscape monitor.
My guess: you already get 296 skipped frames on landscape 4K30 with TensorRT, so your GPU is right at its limit, and even 1.5% more work for portrait is enough to turn a few drops into many.
One thing that did cause stutter here: if MPC-HC starts on one monitor and you drag it to a monitor connected to a different GPU, it keeps rendering on the first one (Ctrl+J shows it under "Render device"). If both of your monitors are on the same card, this doesn't apply.
redraiderj wrote:I wonder if you have any ideas why vertical videos consume more than horizontal videos?
I tested it here (RTX 5090 Laptop, stock TensorRT, x2 to 60 fps). The difference is small:
RIFE itself runs at the same speed on both. 4K in VSPipe, 3 runs each: 4.4 did 74.6 fps landscape vs 75.0 portrait, 4.4_v2 81.5 vs 79.7.
The difference comes from SVP's script for MPC-HC: it cuts 16 rows off the bottom and pads the frame for RIFE, so a 4K landscape video ends up as 3840x2144 and a portrait one as 2176x3840, about 1.5% more pixels. In MPC-HC (RIFE 4.6 v2) that showed as about 3% more GPU power, 133 W vs 136 W on average, and both held 60 fps.
The rotated monitor made no difference either. I rotated my second monitor to portrait and played both files fullscreen on it in MPC-HC: both held 60 fps, with the same jitter as on a landscape monitor.
My guess: you already get 296 skipped frames on landscape 4K30 with TensorRT, so your GPU is right at its limit, and a few percent more work for portrait is enough to turn a few drops into many.
One thing that did cause stutter here: if MPC-HC starts on one monitor and you drag it to a monitor connected to a different GPU, it keeps rendering on the first one (Ctrl+J shows it under "Render device"). If both of your monitors are on the same card, this doesn't apply.
I'm connecting both monitors to my 5070Ti, and my CPU doesn't have an integrated GPU. For me the performance is significantly different, I just tested another 3 minutes 54 seconds 4K 24FPS video which my graphic card can handle, I converted it into vertical and played it. For horizontal video there are no skipped frames, and the frame curve in Ctrl-J is very flat; while for vertical video there are 357 skipped frames and the frame curve has a lot of spikes. To avoid the frame skipping when opening the videos, I always play it for 10 seconds and rewind to the beginning and play them from the start. Here are the screenshots.
For horizontal video there are no skipped frames, and the frame curve in Ctrl-J is very flat; while for vertical video there are 357 skipped frames
Your two screenshots come from different monitors. The horizontal video played on the XV272K (primary, 120 Hz) and the vertical one on the P272U PRO (the rotated one, running at 60 Hz). So the video and the monitor changed together, and the stats can't tell which one causes the drops. The vertical one also looks like it's falling behind before the renderer: 47.606 fps measured vs 47.952 target, while the horizontal one is at 47.984.
Could you swap them? Play the vertical video on the XV272K and the horizontal one on the P272U, with the same settings, and check Ctrl+J again. If the drops stay with the vertical video, it's the video/RIFE side. If they move to the P272U, it's the rotated monitor or its 60 Hz. Here the rotated monitor made no difference, but mine is 1440p and I tested with EVR-CP. You use MPC Video Renderer on a 4K screen, so your setup may behave differently.
redraiderj wrote:For horizontal video there are no skipped frames, and the frame curve in Ctrl-J is very flat; while for vertical video there are 357 skipped frames
Your two screenshots come from different monitors. The horizontal video played on the XV272K (primary, 120 Hz) and the vertical one on the P272U PRO (the rotated one, running at 60 Hz). So the video and the monitor changed together, and the stats can't tell which one causes the drops. The vertical one also looks like it's falling behind before the renderer: 47.606 fps measured vs 47.952 target, while the horizontal one is at 47.984.
Could you swap them? Play the vertical video on the XV272K and the horizontal one on the P272U, with the same settings, and check Ctrl+J again. If the drops stay with the vertical video, it's the video/RIFE side. If they move to the P272U, it's the rotated monitor or its 60 Hz. Here the rotated monitor made no difference, but mine is 1440p and I tested with EVR-CP. You use MPC Video Renderer on a 4K screen, so your setup may behave differently.
Just tested, firstly I played vertical video on horizontal monitor, got 748 skipped frames; secondly I played horizontal video on vertical monitor, no skipped frames. Then I wonder if there is any "warm-up" mechanism, so I played vertical video on horizontal monitor again and got 57 skipped frames, which is much better than the first time, but still have some performance drop.
firstly I played vertical video on horizontal monitor, got 748 skipped frames; secondly I played horizontal video on vertical monitor, no skipped frames.
Thanks, that settles it: the drops follow the vertical video, not the rotated monitor. So it's the RIFE side on your card, not the display.
I repeated your setup here with MPC Video Renderer (adjust present time), a 24 fps 4K clip, RIFE 4.4 v2 on TensorRT x2 to 48 fps, on my monitor rotated to portrait and set to 60 Hz, 3 runs per video. No difference between them here: landscape skipped 0 / 129 / 135, portrait 0 / 133 / 139. All of those skips happened in the first seconds after opening the file, none during playback. That matches the "warm-up" you noticed, and why your second run dropped from 748 to 57.
In VSPipe, the portrait frame is about 2% slower for RIFE here (4.4 v2: 81.5 vs 79.7 fps). If your 5070 Ti is right at its limit with 4K x2, the difference may be bigger on your card and enough to tip it over. To check, open Task Manager > Performance > GPU while each video plays: if the vertical one sits at 100% and the horizontal one below, that's it.
redraiderj wrote:firstly I played vertical video on horizontal monitor, got 748 skipped frames; secondly I played horizontal video on vertical monitor, no skipped frames.
Thanks, that settles it: the drops follow the vertical video, not the rotated monitor. So it's the RIFE side on your card, not the display.
I repeated your setup here with MPC Video Renderer (adjust present time), a 24 fps 4K clip, RIFE 4.4 v2 on TensorRT x2 to 48 fps, on my monitor rotated to portrait and set to 60 Hz, 3 runs per video. No difference between them here: landscape skipped 0 / 129 / 135, portrait 0 / 133 / 139. All of those skips happened in the first seconds after opening the file, none during playback. That matches the "warm-up" you noticed, and why your second run dropped from 748 to 57.
In VSPipe, the portrait frame is about 2% slower for RIFE here (4.4 v2: 81.5 vs 79.7 fps). If your 5070 Ti is right at its limit with 4K x2, the difference may be bigger on your card and enough to tip it over. To check, open Task Manager > Performance > GPU while each video plays: if the vertical one sits at 100% and the horizontal one below, that's it.
Both 3D and GPU overall utilization stays around 70%, but I'm not sure if it's already the ceiling RIFE can get. Because if I use 4.6 for vertical, it keeps skipping frames but the utilization is still around 70%. If I use 4.4v2 for vertical, there is no frame skipped. Both works perfectly for horizonal with 0 skipped frame.
If I use 4.4v2 for vertical, there is no frame skipped.
That's the answer then: on your card 4.6 is too heavy for a 4K vertical frame at x2, and 4.4 v2 fits.
I need to correct my Task Manager tip. With the same model and frame rates here (4.4 v2, 24 to 48 fps, no drops), nvidia-smi shows only 63-74% GPU utilization. So utilization doesn't reach 100% even at the limit, and skipped frames are the real test, which you already did.
One difference: my monitor is 1440p, not 4K. RIFE still processes the full 4K frame (SVP doesn't scale it to the window), only the final scaling in the renderer differs.
redraiderj wrote:If I use 4.4v2 for vertical, there is no frame skipped.
That's the answer then: on your card 4.6 is too heavy for a 4K vertical frame at x2, and 4.4 v2 fits.
I need to correct my Task Manager tip. With the same model and frame rates here (4.4 v2, 24 to 48 fps, no drops), nvidia-smi shows only 63-74% GPU utilization. So utilization doesn't reach 100% even at the limit, and skipped frames are the real test, which you already did.
One difference: my monitor is 1440p, not 4K. RIFE still processes the full 4K frame (SVP doesn't scale it to the window), only the final scaling in the renderer differs.
About that, you may want to check Frame Size -> Alter video frame size. Anyway I guess I'll need a more powerful card for any 4K 30fps video, probably when RTX60 release I'll get one lol
Drakko01
> A version can have identical math performance but be fundamentally broken in stability, or introduce visual artifacts that completely ruin the output.
so, do you think that Vapoursynth R73 is "fundamentally broken in stability, or introduce visual artifacts that completely ruin the output", while R80 fixed this? really?
and given the "picture quality", "R31" and R80 are identical
IF there're no "fundamentally broken in stability, or introduce visual artifacts that completely ruin the output" then I personally don't see any reason for running for the latest versions of everything
As a long-time SVP user since its early days, I honestly can't imagine watching videos without it, and I am incredibly grateful to the developers for their work. That said, as I’ve mentioned here before, our different setups and personal experiences naturally lead to diverse opinions which, at the end of the day, don't really help much.
> A version can have identical math performance but be fundamentally broken in stability, or introduce visual artifacts that completely ruin the output.
My previous example definitely pushed things to the extreme to make a point.
so, do you think that Vapoursynth R73 is "fundamentally broken in stability, or introduce visual artifacts that completely ruin the output", while R80 fixed this? really?
Nobody is saying R73 is broken. It isn't broken; it's just that the software naturally evolves.
Chainik
and given the "picture quality", "R31" and R79 are identical
Again no , claiming the output quality is "identical" ignores massive under-the-hood upgrades, bug fixes, and compatibility rewrites that directly impact final visual fidelity.
1. Enhanced Precision and Native Color Format Support
2. Resolution of Core Precision and Rounding Bugs
3. Deep Integration with Modern AI/ML Filters
4. Frame Accuracy and Temporal Stability
IF there're no "fundamentally broken in stability, or introduce visual artifacts that completely ruin the output" then I personally don't see any reason for running for the latest versions of everything
Software evolution isn't limited to avoiding critical failures, but rather aims for continuous excellence. Any improvement in visual fidelity or general stability justifies the update
SmoothVideo Project → Using SVP → New RIFE filter - 3x faster AI interpolation possible in SVP!!!
Powered by PunBB, supported by Informer Technologies, Inc.