Re: Issues related to "Processing Threads" when set to "Auto"

This's interesting and give us a hope smile

=====
Try do reduce ExBuffAheadAdd value in %APPDATA%/SVP 3.1/Settings/SVPMgr.ini, which is 3 by default.

Re: Issues related to "Processing Threads" when set to "Auto"

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.

28 (edited by AndreaMG 12-11-2012 19:07:34)

Re: Issues related to "Processing Threads" when set to "Auto"

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 sad

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 smile

Re: Issues related to "Processing Threads" when set to "Auto"

MAG79 has some progress with the issue smile
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...

30 (edited by AndreaMG 12-11-2012 19:26:00)

Re: Issues related to "Processing Threads" when set to "Auto"

Chainik wrote:

MAG79 has some progress with the issue smile
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? smile

Re: Issues related to "Processing Threads" when set to "Auto"

Nope smile
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.

Re: Issues related to "Processing Threads" when set to "Auto"

Ok, let me know. Thanks for now and keep up the good work smile

Re: Issues related to "Processing Threads" when set to "Auto"

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. smile

I working on this issue too but from another side. wink

Re: Issues related to "Processing Threads" when set to "Auto"

Thanks, as soon as I get back home from work I will try it.

35 (edited by AndreaMG 13-11-2012 13:27:05)

Re: Issues related to "Processing Threads" when set to "Auto"

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 smile ) Hope it helps. Please let me know if you need me to make other tests big_smile

Re: Issues related to "Processing Threads" when set to "Auto"

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. hmm

Re: Issues related to "Processing Threads" when set to "Auto"

Thank you Mag, very much appreciated! big_smile

Re: Issues related to "Processing Threads" when set to "Auto"

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.

Post's attachments

SVPMgr_HighFramerate_Fix.zip 378.79 kb, 547 downloads since 2012-11-14 

Re: Issues related to "Processing Threads" when set to "Auto"

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) smile

Re: Issues related to "Processing Threads" when set to "Auto"

AndreaMG
Take it, but don't tell anybody it was me big_smile

Post's attachments

helper.dll 38 kb, 590 downloads since 2012-11-14 

41 (edited by AndreaMG 14-11-2012 20:03:17)

Re: Issues related to "Processing Threads" when set to "Auto"

Thanks, my system is updating...within a few minutes I will try it smile

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 wink :

(...) 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.

42 (edited by AndreaMG 14-11-2012 20:30:03)

Re: Issues related to "Processing Threads" when set to "Auto"

Chainik wrote:

AndreaMG
Take it, but don't tell anybody it was me big_smile

big_smile 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 smile

Re: Issues related to "Processing Threads" when set to "Auto"

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.

Re: Issues related to "Processing Threads" when set to "Auto"

With the fix the issue for me is solved smile 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 smile
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 big_smile

Re: Issues related to "Processing Threads" when set to "Auto"

AndreaMG
Good news!
We will apply this fix to next SVP version.

46 (edited by mark007 27-03-2013 19:23:21)

Re: Issues related to "Processing Threads" when set to "Auto"

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.  hmm 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.

Re: Issues related to "Processing Threads" when set to "Auto"

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.

48 (edited by travolter 28-03-2013 11:07:36)

Re: Issues related to "Processing Threads" when set to "Auto"

@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.

Re: Issues related to "Processing Threads" when set to "Auto"

travolter
Nothing strange. Interpolation can not work correctly without frame buffer ahead.
You can only decrease threads number and decrease frames ahead buffer size.

Re: Issues related to "Processing Threads" when set to "Auto"

MAG79 wrote:

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?