Running out of memory, even with "4 GB fix"/large address aware (Page 1 of 2)

No dice. MPC-HC climbs to ~2.9-3.2 GB of commit size, and then crashes.

I'm thrilled to hear that an SVP update is going to have better 4K compatibility, though!

4K content is somewhat stable with these settings, although my CPU's certainly got a lot of overhead left to improve image quality even further. This still isn't fully stable either; for most footage, it clocks in at just under 3 GB of commit space, and if it hits that magical 3 GB point, it will promptly crash. Really looking forward to the version of SVP that either lowers memory requirements or introduces 64-bit.

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.

And so it does   Thanks.

If it's anything like 1080p on old low-end Intel iGPUs, D3D Fullscreen may also work much better than EVR-CP.

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

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.

Fresh SVP 3.1.6 installation + "hotfix" patch.
4K musik video from YouTube, h.264 @24 fps
MPC-HC, EVR video renderer
Latest Avisynth 2.6 MT

"old" libs: 88% CPU load average
"new" libs: 69% CPU load average

No dropped frames in both cases.

For whatever reason any OSD message displayed by SVP drops performance by 2-3 times 
So turn them off (SVP -> Settings -> Show OSD messages)
Looks like ffdshow issue, 2K (1440p) videos aren't affected.

I'll gladly supply system config details and script samples.

yes, please

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'

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

MistahBonzai
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.
this probably doest matter but delete cpu gpu dlls from plugin folder

MistahBonzai
That way I can override down scaling the video within SVP and pass it along to the GPU full size (3840x2160/60fps).

I don't get it. There's a built in option in SVP to manage downscaling.