RIFE: gpu_thread must be between 1 and 1 (inclusive) (Page 1 of 2)

This is what a Vulkan driver reporting about the hardware caps, we can do nothing about it.

Refund the Radeon RX 7900 XT and get any cheap RTX.
Or downgrade the driver like gerappa managed to fix it here:
https://www.svp-team.com/forum/viewtopi … 001#p84001

According to this video it says that installing "Driver Only" prevents issues:
https://www.youtube.com/watch?v=xCX3acP3At4&t=128s
Does the GPU thread issue persists even in this case?

gerappa try to go to
https://github.com/styler00dollar/Vapou … n/releases
and download each windows .dll from recent releases, rename it to rife_vs.dll and replace the initial "C:\Program Files (x86)\SVP 4\rife\rife_vs.dll"

more specifically it mentions on this commit that they changed the crashing "gpu_thread must be between 1 and 1 inclusive" into a warning:
https://github.com/styler00dollar/Vapou … r9_mod_v14

not sure if it would actually fix anything, but please take a look.
Thanks!

@SVP devs, for us to correctly use the latest rife_vs.dll file from https://github.com/styler00dollar/Vapou … n/releases do we need to update something else too?

We want this:
1. to just keep stuff up to date whenever possible
2. to see if gerappa can use 2 threads if that line was turned into a warning:
more specifically it mentions on this commit that they changed the crashing "gpu_thread must be between 1 and 1 inclusive" into a warning:
https://github.com/styler00dollar/Vapou … r9_mod_v14
3. maybe u can recompile the old SVP compatible vs_rife.dll file with that fix so gerappa can check if it unlocks that extra thread?

.dll attached

Woowww, believe it or not it's working. (almost)
The video when i switch to RIFE, i can play even 4K videos. The only problem is if i fast forward to another time position the player immediatelly die with the error (see the picture at the bottom)

A little additional info:
Before the topic started i used avisynth i just changed to vapoursynth for testing purpose (but same error message as avisynth about the thread numbers). Now i changed to Vapoursynth because of the dll.

On the other hand i understand why Chainik said it doesn't matter if we replace the vs_rife.dll to the latest one, because with the current dll and with the old driver would allow the 2 threads.
So the limitation should be on driver level, if i understands well.
But in this case i don't understand what they fix in the Vapoursynth at r9_mod_v14 -> adjusting gpu_thread related code and changing workflows to latest vapoursynth

Overall, it looks like it's not the driver problem anymore, the vs_rife.dll was the problem, but still have this seek error. i will try another player (now i use  Potplayer)

EDIT:  with MPC-HC i got this dump when i try to seek forward in the video:

rife_vs!VapourSynthPluginInit2+0x1baa7
rife_vs!VapourSynthPluginInit2+0x34f1d
rife_vs!VapourSynthPluginInit2+0x34903
rife_vs!VapourSynthPluginInit2+0x2cccf
rife_vs!VapourSynthPluginInit2+0x2c6f8
rife_vs+0x2235
rife_vs+0x505b
vapoursynth!getVapourSynthAPI+0xcadf
vapoursynth+0xfe1c0
vapoursynth_cp38_win_amd64+0x83eac
python38!Py_CheckFunctionResult+0x516
python38!Py_BuildValue_SizeT+0x884
python38!PyObject_GenericSetAttrWithDict+0xcf7
python38!PyDict_SetDefault+0x3be
vapoursynth_cp38_win_amd64!PyInit_vapoursynth+0x1732e
vapoursynth_cp38_win_amd64+0x4c31c
vapoursynth_cp38_win_amd64+0x4b906
python38!Py_gitversion+0x9af4
python38!PyEval_EvalFrameDefault+0x195a
python38!PyEval_EvalCodeWithName+0x228
python38!PyEval_EvalCodeEx+0x9b
python38!PyEval_EvalCode+0x2d
vapoursynth_cp38_win_amd64!PyInit_vapoursynth+0x1be5f
vapoursynth_cp38_win_amd64+0x709f8
vapoursynth_cp38_win_amd64+0x742dc
vapoursynth_cp38_win_amd64+0x74f19
vsscript!vsscript_evaluateFile+0x17b
vapoursynth_filter_64!DllMain+0x10e6a
vapoursynth_filter_64!DllMain+0xdf18
vapoursynth_filter_64+0x1938a
vapoursynth_filter_64!DllMain+0x16d3c
lavvideo!CLAVVideo::DeliverToRenderer+0x12b0
lavvideo!CLAVVideo::Deliver+0x273
lavvideo!CDecD3D11::DeliverD3D11Frame+0x1f9
lavvideo!CDecD3D11::HandleDXVA2Frame+0x107
lavvideo!CDecAvcodec::DecodePacket+0xcbe
lavvideo!CDecAvcodec::Decode+0x1a5
lavvideo!CDecBase::Decode+0x13a
lavvideo!CLAVVideo::Receive+0x219
lavvideo!CDeCSSTransformInputPin::Receive+0x5e
lavsplitter!CLAVOutputPin::DeliverPacket+0x4ae
lavsplitter!CLAVOutputPin::ThreadProc+0x272
lavsplitter!CAMThread::InitialThreadProc+0x4c
lavsplitter!thread_start<unsigned int (__cdecl*)(void *),1>+0x50
kernel32!BaseThreadInitThunk+0x1d
ntdll!RtlUserThreadStart+0x28

SVP devs please provide the avisynth rife.dll too with same fix applied. Maybe it won't have the seek crash.
Thanks!

well, whatever you did the base problem solved, just still can't use because of the seeking problem.
Thank you anyway, and also thanks for flowreen91 to not give up on this

"the same problem" is only regarding AMD cards and AMD drivers
it has nothing common with NV cards and mpv versions

That DLL finally allowed my 7900XTX to work 4 threads and do x4 framerate (24->96). Fantastic. That's with currently latest AMD drivers v24.6.1.

Yep, MPC-BE crashes every time, so I switched to MPV that comes with SVP - no problems with it whatsoever. Works better than MPC-BE, in fact: faster and stable as a rock. But I had to tinker with the config file to set it up to my liking, which is pretty much its biggest downside. The manual is pretty detailed, though: https://mpv.io/manual/stable/#options

Yep. Unfortunately, only those players' developers can solve this issue, since it's tied to the player's renderer. I don't know about PotPlayer's devs but MPC-BE devs have never been receptive to fixing issues they don't encounter themselves, so we're most likely out of luck with them.