and that's what it's currently doing?
SVPlayer for 🍎 iPhone | iPad | Apple TV and 🤖 Android
SVP 4 for Windows and macOS: 30 days FREE TRIAL.
Read FAQ & follow SVP @ Facebook, Twitter
You are not logged in. Please login or register.
SmoothVideo Project → Posts by Mystery
and that's what it's currently doing?
The setting in SVP to remove artifacts seems to decrease fluidity to prevent artifacts.
Would it be effective to instead process the output to remove or process artifacts? Kind of like an "anti-ringing" filter after upscaling.
But honestly, I haven't seen any difference between RC version and the other version before. Is it going to make any difference in terms of performance or memory usage? Perhaps a little bit more stable? I doubt it will change much.
When resizing the input, it uses the Bicubic algorithm. Doesn't spline give a better output without costing much more on performance?
Ideally the best would be the equivalent of madVR's Spline 4-taps with Anti-Ringing filter, but I might have to search a little bit online if Anti-Ringing is supported with AviSynth Spline.
Is this a MT version that is more recent than what was available before?
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.
With the Diamond video, when I play it without SVP, it does appear to already be playing at 60fps with 29.97 interpolated. It's a fluid 60fps with great quality. So although this driver version causes SVP+madVR to lag, it DOES appear to be doing the right thing.
Whereas before, with a different driver version, SVP+madVR would work properly but the video's quality would be lower. Maybe the interpolation mode was different for some reason to generate 29.97fps instead of 59.94fps.
So when I look at the video information, it says 29.97, and it appears to be playing 59.97 already. SVP is then trying to generate frames with a 2:1 ratio, which is where lags occur.
Here's the log
11:03:09.406; ===== Detected playback with ffdShow. AppName: mpc-hc.exe PID: 13112
11:03:09.407; GetDimensionAndFPS_fromOSD start. Duration: 44 ms
11:03:09.451; GetDimensionAndFPS_fromOSD result: 1920x1080 29.97 1/1
11:03:09.452; T1T: begin
11:03:09.453; T1T: GetAllMediaParams
11:03:09.454; ### CorrectStereoModeByAppAndFilename: Diamond.tp
11:03:09.455; T1T: SettingsPrepare
11:03:09.459; T1T: Preparing smooth playback...
11:03:09.460; T1T: WriteAllMediaParamsToIni
11:03:09.460; SVPMgr: main "C:\ProgramData\SVP 3.1\" 1366 768 29.97 1920 1080 2 1. Duration: 141 ms
11:03:09.601; ===== Playback
29.97 * (2 : 1) = 59.94 fps
11:03:09.601; SetPriorityPlayer: 2. Duration: 810 ms
11:03:10.411; frame #10 crop detected: 1 4 1 0
11:03:10.412; frame #11 crop detected: 1 4 1 0
11:03:10.412; frame #12 crop detected: 1 4 1 1
11:03:10.413; frame #13 crop detected: 1 4 1 11
11:03:10.413; frame #14 crop detected: 1 4 1 0
11:03:10.413; frame #15 crop detected: 1 4 1 0
11:03:10.493; frame #16 crop detected: 1 4 1 0
11:03:10.493; frame #17 crop detected: 1 4 1 0
11:03:10.587; frame #18 crop detected: 1 4 1 0
11:03:10.593; SVPMgr: main "C:\ProgramData\SVP 3.1\" 1366 768 29.97 1916 1076 2 1. Duration: 461 ms
11:03:11.054; ===== Playback
29.97 * (2 : 1) = 59.94 fps
Auto crop: [2:4:2:0]
Ok now I understand what's going on. Shouldn't SVP automatically disable itself for interlaced video?
How do I configure my computer to use vector adaptive deinterlace and deactivate SVP?
I have some .TP and .TS videos that cause some problems. With madVR alone, it plays normally. With SVP, however, madVR displays weird deinterlacing times that cause the video to lag.
I currently have the latest Catalyst driver 15.4. There are some driver versions that don't cause this problem (at least one driver version that I kept reverting back to).
Here's a screenshot with madVR alone, then with madVR+SVP.
You can download the video here
https://mega.co.nz/#!KYpSlJYD!c4XNTi0jy … cLxWkOvsRA
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.
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!
madVR includes a Smooth Motion, but not nearly as good as SVP.
And Madshi isn't doing the effects himself. He's taking the best algorithms out there and bundling them together into a player.
So far, SvpFLow 1.1.15 + AviSynth 2.6 MT are playing perfectly well. Will let you know if I encounter any other issue.
Thanks for the great work!
It certainly would be nice to have SVP included within madVR. It would remove AviSynth dependency and avoid having to run SvpManager in the background.
This also would give more control as to the order of operations.
There are more and more 120hz TVs which is GREAT with SVP, while madVR is coming out with even better (hungry) algorithms. Videos upscaled with NNEDI3 and SuperRes look GREAT!
However... it's practically impossible to pull out all the juice even with the top cards.
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 X.
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 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.
That's very unlikely to happen in the near future though.
There's a considerable difference in file size:
svpflow1.dll is 505kb instead of 359kb
svpflow2.dll is 632kb instead of 475kb
What explains such a difference in file size for fixing only one bug?
SVP doesn't work well with anime, but these settings can help
x64 beta? Did you manage to work around the x64 ffdshow bug?
For now I'm dumping AVS+ MT because it doesn't sync audio and video.
I'm also dumping the new SVP because it plays jerky on some videos.
I still get to keep the consolation prize: LAV Filter update.
Here's another video with the same high CPU usage problem with the new libs.
Not sure why these screenshots have high rendering time. I played again, it showed 21ms, I put it in full-screen, rendering time is 10.2ms, back to windows mode, 9.5ms. So I don't know why it was 21ms but it's not actually an issue.
Here's the video file
https://mega.co.nz/#!6EhU2ArI!GyIjNkuFd … Jl_KCkOTTE
Chainik, I'll save you the pain.
That has already been discussed. The new AviSynth+ MT will make it possible to have a x64 version (although there are still a few bugs in it), and the SVP code has been rewritten. However, ffdshop x64 has critical bugs and the project is dead since a long time.
It seems I reversed OldSVP and NewSVP images! NewSVP is the one with higher CPU usage.
And by the way, this file shouldn't have anything abnormal as I encoded it myself. It is an upscaling of a 188p VCD into 720p with AviSynth and x264 encoder. I re-encoded many videos that way and all the others play perfectly fine.
I seem to be having more issues with videos having complex lighting patterns; not sure if that could be related.
I've been playing 29.97 videos on 59hz display for a while with a 2:1 ratio and never noticed anything wrong. Not sure what those jerks are.
Here are screenshots of the video that is taking more CPU with the new version than with the old. I'm using AVS 2.6 in both cases.
Here's the video file
https://mega.co.nz/#!adhnXIDY!-g-FeRb8E … Vsgnswq32I
Edit: File names are reversed. The new SVP has higher CPU usage.
SmoothVideo Project → Posts by Mystery
Powered by PunBB, supported by Informer Technologies, Inc.