Re: Issues related to "Processing Threads" when set to "Auto"
This's interesting and give us a hope
=====
Try do reduce ExBuffAheadAdd value in %APPDATA%/SVP 3.1/Settings/SVPMgr.ini, which is 3 by default.
You are not logged in. Please login or register.
SmoothVideo Project → Using SVP → Issues related to "Processing Threads" when set to "Auto"
This's interesting and give us a hope
=====
Try do reduce ExBuffAheadAdd value in %APPDATA%/SVP 3.1/Settings/SVPMgr.ini, which is 3 by default.
Just wanted to update since you linked to my old thread; with the latest version of SVP, and MadVR off, everything works fine, even 1080p videos, up to 60fps. Sorry you are still having problems; it sounds like it is the same as what I was having. I have no idea what "fixed" it for me, I just chalked it up to installing the latest version of SVP that was on the website.
Chainik
Try do reduce ExBuffAheadAdd value in %APPDATA%/SVP 3.1/Settings/SVPMgr.ini, which is 3 by default.
Thanks, but it doesn't work for me, the problem is still there
spotpuff
with the latest version of SVP, and MadVR off, everything works fine, even 1080p videos, up to 60fps. Sorry you are still having problems
Thanks, in my case the delay is not related to the video render though, I tried each and every one of them and the result is always the same, the issue in my case is with that damn buffer back/ahead "15/18" that is triggered when playing material that is not supposed to be interpolated in the first place because natively high frame rate.
I will try to try different ffdshow versions and different avisynth ones to see if something happens hoping for a fix in the next release of SVP
MAG79 has some progress with the issue
At least he was able to reproduce it.
What if manually set "buffers ahead" value to 1?
It seems that in recent ffdshow versions it shouldn't give any problems...
MAG79 has some progress with the issue
At least he was able to reproduce it.What if manually set "buffers ahead" value to 1?
It seems that in recent ffdshow versions it shouldn't give any problems...
Thank you Chainik (and Mag too of course), you mean I have to install a new ffdshow version and then change the number to 1 in %APPDATA%/SVP 3.1/Settings/SVPMgr.ini?
Nope
SVP Manager changes "damn buffer back/ahead" values cause some times ago there were some problems like frame drops etc. when those values was too small.
May be (may be) it's not an issue now so we need to check it first.
Ok, let me know. Thanks for now and keep up the good work
AndreaMG
You can check it on your system with SVP 3.1.2.
- open 60 fps video, wait for SVP smoothing enabled, point in SVP profile to not add new frames (frame interpolation mode: off)
- open ffdShow settings window from system tray
- change buffers back/ahead size as you wish (I recommend to try 0/1), press Apply, values will be applied immediately
- after that you can rewind in player, buffers will save your values until you close this video
Please tell about results, especially if it let you to avoid the audio sync problem.
I working on this issue too but from another side.
Thanks, as soon as I get back home from work I will try it.
AndreaMG
Please tell about results, especially if it let you to avoid the audio sync problem. smile
I played a lot of 720p59.94 videos and the results are the same (indipendently from the video render uused MadVR or EVR)
I followed your instructions: if I manually set "buffer back/ahead" to "0/1" the sync problems is not solved, even whith settings like "0/20" the video is still out of sync; if I press the "use current" button in ffdshow the buffering (for all the 720p videos that I played) changes to "0/31" and video and audio are perfectly in sync, at my eyes even let's say "0/30" or "0/29" seems to be ok, but if the out of sync is very minimal is very difficult to be noticed (at least to untrained eyes such mine ) Hope it helps. Please let me know if you need me to make other tests
AndreaMG
Thank you. Soon I will finish special "Quick Fix version" for you.
But error, what you found, is more deep than I could imagine in beginning.
Thank you Mag, very much appreciated!
AndreaMG
Here is modification of SVP 3.1.2: SVPMgr_HighFramerate_Fix.zip
This Fix limits threads number for case with smothing coefficient 1:1 to avoid synchro problem.
Instruction
1. Quit SVP Manager
2. Unpack to SVP folder with file replacing
3. Launch SVP Manager
Try it.
Thanks, but I cannot run SVPMgr.exe anymore:
ERROR: Unable to find point of entrance "oclGetDeviceName" of the procedure into the dynamic link library "helper.dll" (translated from my language (italian)
Thanks, my system is updating...within a few minutes I will try it
Regarding the dvd playback issue below what @Nev said in Lav thread that could be (maybe?) the explanation of the "jumping" videos that I encounter when threads are set to high values :
(...) Regarding AviSynth, its possible that the high decode delay of the CUVID decoder is just too much for DVD playback plus AviSynth. CUVID has to buffer quite a few frames to be efficient at decoding, and the DVD Navigator is known to not deliver too much data in advance, so if you need a bunch of frames in the decoder for buffering, and AviSynth needs more frames buffered, they might just not arrive at the renderer in time for display. Can't really change how the CUVID decoder works, but since mpeg2 is so cheap, might as well stick to software.
AndreaMG
Take it, but don't tell anybody it was me
Thanks, it works, but now every video I play has a fixed "0/18" buffer back/ahead, is it ok? I played a few high-bitrate 1080i@23.976 interpolated to 60fps and they seemed to run fine though, but I have some more tests to make in order to be sure that everything is working properly
helper added into zip. zip updated.
AndreaMG
Thanks for explanation about video delay on LAV CUVID decoder. I think I need to try another decoders.
every video I play has a fixed "0/18" buffer back/ahead, is it ok?
It is OK. Your CPU have 8 logical cores. For 8 cores SVP needs 15 threads. In hidden settings placed number of extra frames in buffer. It is 3. And finally you get 15+3 = 18 frames ahead when Threads number set to auto.
I check it on my system. It is no difference between 1 and 18 frames ahead. And I leave this number untouched. It looks like optimization inside ffdShow with frame number correction by threads count. No longer need to point real number. Just zero or not zero.
Try to play 60fps video with SVP enabled. Just this case was fixed.
With the fix the issue for me is solved Unfotunately I have no 1080p60 videos to try it on but with 1080i25 or 1080i30 videos deinterlaced by Lavvideo in "video mode" (i.e. brought to 50 and 60fps after deintelacing) I do not experience any sync problem. That said obviously for those kind of videos I deinterlace in "film mode" in order to be able to interpolate with SVP
I also noticed no performance drop whatsoever after the fix, now I can even watch dvds with Lavvideo if I set it to decode mpeg2 in software mode and if the number of cores in SVP are set to 4. Thanks
AndreaMG
Good news!
We will apply this fix to next SVP version.
Mag79 and all. I use interframe scripts and am using the latest SVP dlls very very happily. All is fine but I'm always tweaking things to get the most quality without dropping frames.
I'm also interested in the ffdshow buffer back / ahead figures. If I use a low value like 0/1 just to see how much of an impact it has on performance, I lose audio sync, I assume because SVP is requesting further than 1 frame ahead and avisynth is therefore giving it only 1 frame ahead as thats all it has?
Is this what causes audio delay? I'm confused though if this is the case because even with 0/1 motion is perfectly smooth. If SVP is actually looking for further than 1 frame ahead, and if I have buffers set to 0/1 shouldn't I also therefore have audio sync problems AND stuttery playback? I only get audio sync problems and no stutters though. Is this an indication of some issue with timestamp handling in SVP with low buffer settings causing sync problems?
I use SetMTMode(3,16) in my initial script setup, and this works great on core i7 920 performance wise no matter what buffer settings I use. Audio sync problems is the biggest effect of changing the buffers so I really want to get a clear picture of what is going wrong.
mark007
SetMTMode(3,16)
It is mean that Avisynth does calculating in 16 threads simultaneously. First thread need current frame and one next frame to calculate motion vectors. Second thread need calculate motion vectors between next two frames. So 16 threads need buffer 16 frames ahead. It is if in two words.
Audio sync problem was only is case 1:1 smoothing coefficient and was resolved in SVP 3.1.3.
What your case? Tell us more details about audio sync problem please.
@MAG79 I want to make a test with SVP and I need your help.
How can I disable the buffer back/ahead of ffdshow?
In 2009/2010 when I started using framedoubling scripts I always got better performance with the ffdshow frame buffer back/ahead checkbox disabled, and also faster seeks when doing forward/backward. It was a default setting in all my frameinterpolation configs.
Now in SVP when I disable the checkbox while SVP is running the video stops and become freezed.
Im testing to edit SVPMgr.ini to decrease the "extra buffer ahead", but I cannt disable these buffers totally.. minimal value is 1... If I reach to 0 video freezes too.
travolter
Nothing strange. Interpolation can not work correctly without frame buffer ahead.
You can only decrease threads number and decrease frames ahead buffer size.
travolter
Nothing strange. Interpolation can not work correctly without frame buffer ahead.
You can only decrease threads number and decrease frames ahead buffer size.
less frames ahead = less cpu usage?
less quality too?
what are the pros and cons about use higher number or lower number of frames ahead?
SmoothVideo Project → Using SVP → Issues related to "Processing Threads" when set to "Auto"
Powered by PunBB, supported by Informer Technologies, Inc.