Search options (Page 3 of 55)

Unless it's in 10bit or you're using mpv, the bitrate doesn't matter for H264 video as that can be hardware decoded on any GPU made in the last 10 years without issue.

And with that hardware decoding I wouldn't be suprised if you could even disable your i7's overclock and you'd still be fine - heck my own Xeon locked at its turbo clock of 3.2GHz combined with H264 hardware decoding almost gets me there when using your exact settings - around 80% of the time it's running at 1.0x SVP index while it's only at 0.9x or so for the other 20% in certain scenes that are apparently more demanding (it's not clear why however as the entire test video is full of motion).

"by two with global refinement" can be a killer of CPU.

With that set to disabled, even my Xeon 3470 @ 2.93GHz can run those exact settings but with "frames interpolation mode" set to 'Uniform' with even software-decoded 1080p 5mbps HEVC @ 25fps --to-> 62.5fps (2.5x) as long as I'm using a 64bit media player (because 32bit HEVC software decoders are quite unoptimized).

For reference, the that 1080p 5mbps HEVC 25fps video interpolated to 62.5fps was my go-to stress test when I was setting up this Xeon system with the logic that, if my hardware could do that just fine, then darned near any 24fps 1080p video should be able to work without issue (unless it was HEVC with a pretty crazy bitrate).  For actual real-world use I'd use 2x interpolation for 25fps videos as my display can run 50Hz without issue (but it can't handle anything above 60Hz without skipping frames).

Uhhh, when using 2m to interpolate at 2x from 24fps to 48fps, there's literally no interpolation occurring - you have to use something greater than 2x for 2m to actually do anything.

But 1.5m does in fact actually result in some interpolation when using 2x.

Wait, really?  That's at least an i7-3770 with a base clock of 3.4GHz, right?

I have a Xeon x3470 @ 2.93GHz (I've disabled turbo for easier undervolting) which is essentially a first gen i7 (performance-per-clock is something like 30% slower than third gen); from my testing and calculations I would think that your third gen i7 should be able to interpolate 4k video with your reduced settings without issue as long as you're using GPU decoding of the video stream (which a 1050Ti should be able to do unless it's something new & fancy like AV1).

When I play back a 1080p video that's hardware decoded by my GPU but I have SVP cranked up to absolutely unreasonable settings so that I'm left with a CPU bottleneck, it shows my CPU utilization at around 65%, so that's essentually my upper limit.

When I played back a 24fps 3840x2160 video that's hardware decoded by my GPU and have SVP set to 2x interpolation with 1.5m, standard shader, two pixels, and 16 px. (see attached screenshot), I have an SVP index of 0.7x but a CPU utilization of only ~40% because my GPU is maxed out and bottlenecking me.  We know my CPU when running SVP can have utilization all the way up to 65% assuming no GPU bottleneck, and 65 is 1.625x that of 40; my SVP index of 0.7 multiplied by 1.625 would be 1.1375 which would mean that I theoretically should have no issue hitting an SVP index of 1.0x if I just wasn't GPU bottlenecked.

Therefore are you absolutely sure that your current i7 can't handle 4k video with reduced interpolation settings (again, see attached screenshot) when combined with GPU decoding of the video?

Also keep in mind that you may experience a weird bug in SVP where setting the "Motion vectors grid" to anything less than 16 px.results in considerably higher CPU utilization than one would expect (24 px. uses more CPU than 28 px. which itself uses more CPU than 32 px; meanwhile 32 px's CPU utilization is actually similar to 16 px.).

Does that apply to GPU performance though?

It was my impression that proper GPU virtualization is only something that's really become a thing in the last year or so (and even then I don't believe it's fully baked yet), and your use of a GT 430 would make all the more likely that you're not using a modern platform that supports such proper GPU virtualization.

One way around this is to use "GPU passthrough" instead, where your host OS uses one GPU by itself and your virtualized OS uses the other GPU by itself (integrated graphics can work as one of these GPUs).  I've never done this myself however and it's my impression that it too doesn't work on all configurations (though I believe it can work on many more configurations than the likes of proper GPU virtualization, especially if integrated graphics is present).

So the wiki says that the HD5000 series is the minimum Radeon GPU that supports full GPU acceleration in Windows (and I can confirm this is the case between my HD4670 and HD5850), but what about Linux?

Also the wiki says to use proprietary drivers, but the mesa open source drivers are the go-to solution for Radeon drivers as the closed-source Radeon drivers for anything other than Nvidia on Linux are a bit of a trainwreck (heck there aren't even separate proprietary drivers available for Intel GPUs as well as really new Radeon GPUs like the iGPU on the Ryzen 2200G and 2400G).  I'm only a Linux newbie so there's not much problem-solving I can do myself, but it seems that my HD5850 didn't have out-of-the-box support for SVP's GPU acceleration even though it did have fully-supported hardware accelerated polygonal 3D rendering in the likes of the Dolphin emulator...but maybe I have to actually do something in order to enable SVP GPU acceleration on Linux.

The Phenom II being faster is most apparent with the CPU utilization for the combination of "half pixel + 14 px."

Nevertheless, the thing is that 45nm Core2-based CPUs pretty much always have faster IPC.  So the fact that the performance was actually a bit in favor of the Phenom II was not at all what I was expecting.

One thing however is that the Phenom II overclocks to 3.6GHz at 1.3v quite easily when combined with the beefy 140w AM3 stock cooler.  However, overclocking the Xeon is limited by the motherboard (which can't handle an FSB past 430), my RAM (I don't have any DDR2-1066) and the CPU cooler (stock Intel heatsink with copper plug).

I can measure that, though no idea how soon I'll get the results.  Nevertheless, they're totally not an apples-to-apples comparison as the Xeons tend to be higher-binned for lower voltages than consumer Core2 CPUs, and the Xeon I'm using is even a low-voltage model but is then overclocked from 2.5GHz to 3GHz.

The Phenom II however is a black edition dual core model that's been unlocked to 4 cores which then requires an extra 0.025v to 0.0375v to run stable but then is underclocked from 3.4GHz to 3GHz.

While I do know what the lowest rock-solid stable voltage is for the Phenom II @ 3GHz (1.125v), I don't know what it is for the Xeon @ 3GHz as I haven't really done any real stability testing outside of making sure it doesn't insta-crash after running a CPU stress test for about a minute or so － I just know that it doesn't BSOD at 1.1v.

Much in the same way that "4k movies" don't have 4000 pixel widths even though 4k technically means it should, and much in the same way that 720p TVs will almost always be 768p, and much in the same way that 23.976fps and 29.97fps are commonly called "24fps" and "30fps" even though they're actually different from 24.00fps and 30.00fps.

Just because a term is used in a specific way does not mean it's actually accurate.  Most of these come down to human nature of feeling its "close enough", but this causes issues when one is trying to deal with specifics.

HD/UHD/SD is a television standard where the common display is 16:9; movie standards follow different resolutions such as 2k (2048x1080) and 4k (4096x2160) which use the slightly-wider 1.85 aspect ratio.

My point was that the specific "decrease to HD" function is therefore not particularly beneficial to those 768p users and they'd be better served by "decrease to screen" (which is SVP's default setting anyway).

There's nothing wrong with SVP's current resizing behavior, but its exposed functionality is a bit limited when compared to SVP 3.1 nevertheless.

SVP's "resize to screen" handles any resolution including non-standard ones, so the ability for SVP to downsize to such non-standard resolutions.

My apologies but I was completely unaware of the existence of this setting under "all settings".

Nevertheless, I'm at a loss on how to actually use such a setting on a per-profile basis as my understanding is that such settings are applied globally.

The issue here is total pixel count and resolution, performance is merely a side-effect as it happens to partially result from those values.  1280x720 is around 0.92 megapixels while 1280x534 is around 0.68 megapixels making the latter considerably below what is considered "HD".

Ideally downscaling based on total pixels vs horizontal/vertical pixels would be two separate options (similar to the way SVP 3.1 had both "1280px width"/"720p height" as well as "75% of original size").

As already mentioned, unless it's a non-x86 tablet or smartphone, 99.99% of all displays marketed as "HD" are actually 1366x768 rather than 1280x720.  Remember that 1024x768 is the minimal resolution for Windows 8 and newer, and you obviously can't fit that on a 1280x720 display without downscaling (which would be sub-optimal for text clarity).

I'm using the pro version and have been since SVP 4 was in beta as I backed the original SVP4 Indiegogo fundraiser (you'll notice my username is present on the "Version and credits").

Nevertheless, unless I'm missing something, you actually can't resize the video resolution to whatever － that only applies to cropping; the only resizing options are "decrease to screen", "decrease to HD", and "resize to screen" and are applied globally.  This is one area what SVP 3.1 was actually more flexible in that it allowed you to resize to a variety of different sizes on a per-profile basis.

You're lucky I randomly revisited this forum to post a question after pretty much a year or so of not being on here.

Nevertheless, your issue would probably be more appropriate to have its own thread, as that's quite a strange issue you have.  The only thing I can think of is that maybe it's the specific video clip you're testing with or maybe your hardware decoder can't quite do 30fps of whatever codec you're using.

Thing is, 5x interpolation of 24fps would be considerably more CPU and GPU intensive than 2x interpolation of 30fps except in terms of hardware decoding the actual source video stream.

Is there a particular benefit for SVP to behave in its current way that I am unaware of?

Apologies for the 13-months-later grave-dig, but I just want to confirm if the above method of using ffdshow to resize the video stream is still the best way to use a lighter-weight downscaling algorithm with SVP.

Unless there's now a way to change SVP's built-in downscaling algorithm to a lighter-weight one?

For reference, I'm planning on moving my HTPC's SVP configuration away from 32bit MPC-HC and I wanted to find out if there's a better way to do things now (in particular, I don't believe the ffdshow method works with players like mpv).