• Thanks: 33

Topic: Processing madVR before SVP

I mentioned this before and would like to put more emphasis on an important point.

Using SVP + madVR works GREAT with 60hz 768p or up to 1080p. However, as technology increases (120hz and 4k), the performance cost also grows exponentially which makes it non-practical to get the best of both.

Let's consider this scenario.

24fps video played at 60fps 1080p. With SVP, you generate 60 frames per second, which gives madVR 16ms to process each frame. With NNEDI3 and SuperRes, you could pull all the juice out of a Nvidia Titan, and it will look GREAT!

But then, if you play 24fps at 120fps 4k, you won't nearly be able to pull out the best results even with a Titan. At 120hz, you get 8mz to render each frame. To upscale 1080p video into 4k with NNEDI3 and SuperRes, I don't think you'll achieve that in 8ms even with a Titan.

If, however, madVR would run first, a 24fps video would have 41ms to render each frame with madVR, then SVP could easily generate extra frames from there. When you think about it this way, the performance cost on the GPU would be 5x lower in this scenario by processing madVR before SVP, which isn't currently possible, but which would be possible if both were somehow integrated.

For now I don't have an issue with 60hz 1080p display, but I would hesitate to buy a 120hz 4k display knowing that the computer couldn't make the most of it.

I don't think this will happen in the near future, but as technology evolves, it might be something to consider. It will become a necessity at some point.

One option would be to bundle SVP within madVR. madVR already contains a Smooth Motion feature but it isn't nearly as good as SVP. Madshi didn't program the algorithms in the software, he's merely bundling the best stuff into a package that can be applied on live videos.

I don't know what would be the best option but for 4k 120hz it definitely will become a necessity. This would affect performance by a factor of 5x!

  • MAG79
  • SVP developer
  • Offline

Re: Processing madVR before SVP

Mystery
Theoretically frames processing by madVR before SVP is interesting. But practically it has many additional problems/questions:
1. SVP must to work with RGB 24bit instead of YUV 12bit. But SVP can't do it now. It need to be realized.
2. SVP must be integrated to madVR to be called after frame upsize/downsize/converted to RGB 24bit. It need to be realized.
3. SVP at monitor resolution in RGB color space may show very big CPU and GPU consuption. Much more than at file resolution in YUV 12bit. So 41,6 ms maybe not enough to SVP to process every pair of frame to generate new interpolated frames between them.

  • Thanks: 33

Re: Processing madVR before SVP

1 and 2 are not technical issues but things that would have to be programmed; and I understand that the focus for now is in getting the new version out and getting it to work with AviSynth+ x64!

But these things could be on the roadmap afterwards. By then, 120hz 4k displays will become more common.

For processing RGB 24bit instead of YUV 12bit, is it really an issue, and is there a solution? There is always a solution when you sleep on it.

  • Thanks: 33

Re: Processing madVR before SVP

MAG79, the problem you're saying about RBC instead of YUV, isn't it the exact same problem as 4k instead of 1k resolution? The solution is then to decrease the motion vectors precision.

Re: Processing madVR before SVP

Try two fury x and go for 50 hz, that should be doable.

  • Thanks: 1

Re: Processing madVR before SVP

Threads like these make me think I'm "doin' it wrong" by using SVP without madVR, a program that as far as I can tells seems to be designed to thrash my PC for very minor graphical improvements  lol

I'm thinking the answer lies in getting SVP to use the GPU more heavily itself.  GPU makers, especially AMD, are hyping their GPU compute functionality for video work with their recent GPUs but SVP hasn't gone all-in on using the GPU.  SVP's GPU compatibility page rams that point home.

If GPU usage were to scale linearly with resolution, my mid-range, last-gen GPU wouldn't even be 50% utilized at 4K based on what I see now with SVP.

  • Thanks: 1

Re: Processing madVR before SVP

I'd say switch from madVR to MPDN. I've been using NEDI + SuperRes and while I can't see obvious quality changes, the performance cost is much lower.

As for madVR before SVP, that'll just be pointless. Why? Because you'll be stuck with identical frames for huge periods, which destroys smoothness. 8ms refresh time and 41ms render time means 5 identical frames before the next frame show up. Why would you even need SVP, then? The point of frame interpolation is to have as many frames out with minute changes as possible to create the illusion of smoothness, right? You'll just get a stuttery mess is what I think will happen.

It's like gaming, what you're describing. Either you lower settings to a point where 120Hz is possible, or you live with lower frame rates. You can't really have both.

  • Thanks: 33

Re: Processing madVR before SVP

madVR also offers NEDI+SuperRes

You can switch the order and still render in 60fps. I'm converting videos with an automated upscaling script and I found that what works best is
Denoise
Frame Double + Sharpen
SVP
Frame Double + Sharpen

Of course, running SVP live right in the middle would be asking too much tongue But it can be done with AviSynth.

  • Thanks: 3

Re: Processing madVR before SVP

Sorry to bring up an old thread, but I asked madshi about this: http://forum.doom9.org/showthread.php?p … ost1773438