Yes I can set decrease frame size to disabled. I could use some help finding where I can set overlap: to 0.

The reason I run SVP within my main AviSynth script is because I have other filters I use in conjunction with SVP. Also doing it that way allows me to balance CPU/GPU utilization. For instance when using MadVR I can run nnedi3 on the CPU thus freeing up the GPU for additional video processing. I hate to see either the CPU or GPU loafing along while the other is maxed out smile

Again, keep in mind that I'm running the SVP script within the 'raw' AviSynth script and not as SVP standalone app.  That way I can override down scaling the video within SVP and pass it along to the GPU full size (3840x2160/60fps).

So, when using the new SVP script (extracted from SVP) I overlooked that there was no overlap: qualifier. After adding overlap:0 to global analyse_params the dropped frames issue cleared up.

What I did discover while comparing AviSynth 2.6 MT to AVS+ was that although the CPU utilization was similar, AVS+ didn't drop frames in the most difficult sections of the video. AviSynth 2.6 MT would drop frames for me when CPU utilization topped 63% while AVS+ would hit 70% in the same section but not drop the frames that AviSynth 2.6 MT did. Perhaps I could eliminate the difference by tweaking threads in AviSynth 2.6 MT... In any case AVS+ coupled with the new SVPflow DLLs works fine as far as I'm concerned.

PROBLEM SOLVED: When reloading SVP 3.1.6 Core to get an old version of the svpflow dlls I overlooked reapplying the hotfix (I screwed-up).  All fixed now. Works very well - perhaps 'smoother' (less jitter) than with the old svpflow dlls with MPC-BE.  I'll perform some controlled testing and report back with CPU/GPU utilization values.

James D wrote:

Did you use AVS+ ffdshow-fix r1800? Please try. https://cloud.pados.hu/index.php/s/0e0d … 11731699b6

Yes, I have been using AviSynth+ (0.1 - r1800) with x86 along with the new SVP 3.1.6 installation and the SVP "hotfix" patch with all my testing.  I've been away this weekend but am now ready to give it another run through. I *think* I only have the dropping frames issue with the new svpfolw* dll files with rendering native (not downsized) 4K/25P file. The old svpflow* dll files ran the test file smooth as could be with latest MPC-BE/ffdshow/lavfilters and Avisynth/+ SetMemoryMax with 1024 (now using 1536) and EVR-CP 32-bit FPS, Mitchell-Netravali4, D3D Fullscreen. I could back-off on the configuration but it did run smooth with the old svpflow dlls.  CPU and GPU utilization looked file with <70% but the frame drops weren't random/occasional - they were 'gawd awful' sad

Edit: Keep in mind that I'm running the SVP script within the 'raw' AviSynth script and not as SVP standalone app - if that makes a difference.  That way I can override down scaling the video within SVP and pass it along to the GPU full size (3840x2160/60fps).

Something isn't playing nice... Swapped in the new svpflow1.dll and svpflow2.dll files.

  • Fired up SVP and configured a 3840x2160/25fps profile using the values I've been using right along while conducting my tests.

  • Rendered the 4K video file (it ran smoothly with ~25% CPU and GPU) and exported the SVP script (just to make sure that nothing had changed with the new SVPflow dll files).

  • Then copied the SVP script into the Avisynth scripts I've been using for AviSynth 2.6 MT and AVS+. Made sure the avisynth.dll files were in the proper folders and the SVP svpflow dlls were in the PluginPath.

Keep in mind I'm using the 4K file with out downsizing. Under AVS+ the CPU was ~65% and GPU ~60% (about what I have been seeing with the 'old' svpflow dll files after I jacked-up the SVP config and video rendering settings), System memory utilization was ~1.4GB. However I was dropping frames all over the place - it was a disaster.

Edit: Tried lowering Threads and Prefetch values from 8 to 6 but no difference with the performance - still dropping frames like crazy.

Swapping over to AviSynth 2.6 MT I experienced the same performance issues running both MPC-BE and MPC-HC as well.  Swapping back to the 'old' svpflow dll files and SVP script solved the issue.

Something ain't quite right. Got any ideas? I'll gladly supply system config details and script samples.

My 40" Sony Bravia LCD 'monitor' (it has never displayed the likes of TV or movies) does 4:4:4 chroma (10-bit panel) and full range RGB. It has better white balance calibration controls than many workstation displays.

Chainik wrote:

There's still too much to make 4K video usable for any housewife.
And SVP is on the bleeding edge!  lol

Using MPC-BE/AVS+ I tried your suggestion about D3D fullscreen. With EVR-CP I enabled D3D Fullscreen, 10-bit RGB output, 32-bit FP Surfaces and Michell-Netravali spline (PS 2.0). CPU unchanged at ~34%. GPU now ~67%. and I gotta tell ya..it's slick as snot on a door knob.

Not only that but being downsized from 4K to 2K on my 40" 1080P Sony Bravia at arms length (it's my monitor) it's looking good. This is starting to be fun  smile  However, I agree with Chainik, I doubt that the 'average' consumer would think as much.

Thanks Chainik and Nintendo - this little experiment has given me a lot of new stuff to contemplate.

Chainik wrote:

MistahBonzai
EVR-CP is not good for 4k@60. Plain EVR works much better.

And so it does smile  Thanks.

To satisfy my curiosity I conducted some comparisons with SVP running on AviSynth (AVS+ and AviSynth 2.6 MT). Using MPC-BE and MPC-HC on my Windows 7 64-bit OS.

  • The test video was the "SONY F55 4K Blue Shanghai Zhen Wang Wei 150mbps.mp4" file mentioned earlier.

    All tests were conducted using an AviSynth script with the SVP configuration embedded within that script. The SVP values were identical in all cases with the global resize_string="". The 4K video (3840x2160/25FPS) was the input to the SVP script. As I have a 1080P display (40" Sony Bravia) set at 60FPS the GPU downsized 3840x2160/60FPS output from SVP to 1920x1080/60FPS.

    The MPC-BE and HC video renderers were EVR-CP 8-bit Integer set to "Nearest Neighbor". I utilized that particular Video Rendering configuration because I quickly discovered that anything more would max my HD-7850. I believe this to be the case due to using "gpu:1" in the SVP values. I tried gpu:0 but it maxed my CPU (Intel i7-3770@3.4GHz).

    The same filters/latest revisions (LAv Video, LAV Splitter, ffdshow raw video, File source async and EVR-CP) were used in all cases.

    Global threads=8 with AviSynth 2.6MT. Prefetch(8) was used with AVS+. Note: As you know the # of 'threads' make a large difference with memory useage. I was a 'set threads to 15 and forget it' kinda guy with AvisYNTH 2.6MT but have now rethought that setting after running these tests.

    Both MPC.** executables were patched for "4K". I did note that I had to re patch them once when changing test configurations - more testing needed to see if that was a result of changing the AviSynth .DLLs. Speaking of which..I simply moved the appropriate AviSynth.dll to the requisite MPC-BE or MPC-HC folder along with changing the AviSynth script when reconfiguring them for AviSynth 2.6MT or AVS+.

Bottom Live:

All tests with MPC-BE and HC yielded similar GPU and CPU utilization (in my case ~50% GPU and 32% CPU).
MPC-BE consistently used ~ 20% more system memory with both versions of AviSynth.
MPC-BE was a bit smoother - less jitter (+/- ~1MS versus +/- ~2MS with MCC-HC)

Actual average memory utilization was:
MPC-BE ~1.84GB with AVS+ -- ~2.27GB with AviSynth 2.6MT
MPC-HC ~1.44GB with AVS+ -- ~1.82GB with AviSynth 2.6MT

In no cases did anything crash and system memory utilization would level out after 5-10 seconds and then remain fairly constant.

Edit: SetMemoryMax(1024). When using "SetMemoryMax(512) with either MPC-BE or HC it will crash.

60

(171 replies, posted in Using SVP)

dlr5668 wrote:

copy right one to player folder. It will have maximum priority

Yup, that's what I've been doing (per your instructions).  By habit I use the appropriate 'system' folders to keep track of them but in this case I used the player folder (with the _player.exe) and left the previous ones in the 'system' folders. From experience I offer that overlooked AviSynth.dll files can leave ya chasing your tail.

Well all right! time for 64-bit cool

61

(171 replies, posted in Using SVP)

dlr5668 wrote:

MistahBonzai
r1825 AviSynth.dll provided by dlr566
did u test this version too https://mega.co.nz/#!YgpG0aSL!7mksBRpYA … gE4nYXV7qo ?

Yup, that's the one I just tested prior to the latest (r1780) from James D. Perhaps the difference between or CPUs is an issue.  When choosing a DLL I go for the vanilla Win7 build as I've run into issues (not unlike this one) with using ones optimized for processor specific support routines.

BTW: What's a good utility for verifying the AviSynth.dll being used? I most likely already have it but I got so many 'tools' I've lost track... sad

62

(171 replies, posted in Using SVP)

FWIW: Using the latest instructions for x86 and the r1825 AviSynth.dll provided by dlr5668 I still get an immediate crash with MPC-HC (x86) however substituting the  r1780 AviSynth.dll provided by James D (ffdshow-fix) works (after throwing an invalid script error).  CPU usage drops 8-10% (from ~50% to ~42% with 1080p/24fps file) with my set-up. I haven't exercised MPC-HC much (no seeking) but at least I have I know I have a valid path(s). Of Course it's 32bit while 64bit is where my head is at  big_smile

Edit: Performance appears to be the same - I usually run SVP via my own scripts in ffdshow raw video via AviSynth support and was comparing apples to oranges. So the AVS+ AviSynth.dll yields about the same performance as the 'old' 2.6MT AviSynth.dll - unless it's latching onto another overlooked AviSynth.dll.

63

(171 replies, posted in Using SVP)

Standard SVP install has been working trouble free. With your changes I get instant crash on my i7-3770 (quad core - 3.4GHz) , HD 7850 and win7 64 bit.  With MPC-BE(x86) and HC(x86) with 4GB patch. SVP 3.1.6.1052 with 4GB patch. Appears to be AviSynth.dll related. Was already up to date with svpflow*.dll. Looking forward to a vanilla AviSynth.dll build.

64

(2 replies, posted in Using SVP)

xDragonking wrote:

Hi, I've strange bug with svptube specifically when trying to play this one video:
www.youtube.com/watch?v=0gFh6hKizV4
Which I just noticed is age-restricted video... maybe that has something to do with the bug?

When I get the link to svptube it creates an error window and then crashes no matter what option I choose... here's a screenshot of the error:
http://i617.photobucket.com/albums/tt253/warriorsc/Untitled_zps0b52b80a.jpg
Thanks

SVPTube 1.1.5 auto launches and plays fine for me but OMG..talk about graphic violence.. It's no small wounder it is age restricted!

65

(9 replies, posted in Using SVP)

I had similar issues with logo overlays causing motion defects when the video panned.  My test file: https://vimeo.com/51322829 smile I run 'SVP' via avisynth so I don't have the SVP settings off the top of my head.  But here is the pertinent part of the avisynth script I use. Basically I reduced the block size to 16 (H&V) and set overlap to 2.  It didn't completely cure it but it's 'not all that bad' now.

BTW: These are settings for a 720P/23.976 video displayed at 59.938

nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=1920,fheight=1080,nsize=0,nns=2,qual=1)
global crop_params=""
global resize_string=""#spline36resize(2560,1440)  lanczos4resize(1920,1080)
global super_params="{pel:2,scale:{up:0},gpu:1,full:true,rc:true}"#pel:1 full:false
global analyse_params="{block:{overlap:2,w:16},main:{search:{coarse:{distance:-10},distance:0}},refine:[{thsad:250}]}"#overlap:0,w:32
global smoothfps_params="{rate:{num:5,den:2},algo:13,mask:{cover:80},scene:{blend:true,limits:{scene:6000,zero:100,blocks:51}}}"
#global smoothfps_params="{rate:{num:24000,den:1001,abs:true},algo:23,mask:{cover:80},scene:{blend:true}}"

MaXimus wrote:

Settings are all at default, using LAV/CUDA with madVR, the framerate plays @ 59 FPS then suddenly drops to 40 FPS then goes back up after a while

What is going on here?
.
.
.

CPU: i7-4700HQ @ 2.40 GHz.

Just a SWAG but might it be the 2.4GHz CPU speed? According to the FAQ it's on the slow side... " for high quality 1080p interpolation you still need powerful CPU and having 4 cores at 3 GHz is a good start." - http://www.svp-team.com/wiki/FAQ