51 Reply by Nintendo Maniac 64 (edited by Nintendo Maniac 64 07-02-2016 05:50:50)

Re: SVP 4 artifacting is unacceptable

mashingan wrote:

But just be aware, the larger the value (the pixel that to be analysed), the more burden to CPU. Even changing -8 to -10 could give significant rise in CPU usage (especially if combined with Exhaustive Search).

To be honest, the difference in CPU utilization between "Average" and "large" always seemed within margin of error to me...

mashingan wrote:

SVP4 seems to use analyse.main.search.coarse.type = 2, it's Hexagon Search while SVP3 is using the value 4, Exhaustive Search. The Hexagon Search is way lighter than Exhaustive Search. I personally use 4 for 720p and 3 for 1080p (Uneven Multi Hexagon search, UMH).

This to me seems like the kind of thing that should have a visible setting in the GUI when you're not using the "Automatic options selection" no?

52 Reply by mashingan (edited by mashingan 07-02-2016 07:16:37)

  • Thanks: 37

Re: SVP 4 artifacting is unacceptable

Nintendo Maniac 64 wrote:
mashingan wrote:

... could give ... (especially if combined with Exhaustive Search).

To be honest, the difference in CPU utilization between "Average" and "large" always seemed within margin of error to me...

Of course, for 720p video and Hexagon search, the rise should within "common" CPU's capabilities. Especially if one has very good CPU, the different of CPU usage can be neglected.

But not so with laptop, the higher the CPU usage, the faster battery will be exhausted. Again, this is depended on how the laptop user tolerates the CPU usage though. (Well, the idea of watching video/film comfortably using laptop already questionable too wink )


Nintendo Maniac 64 wrote:

This to me seems like the kind of thing that should have a visible setting in the GUI when you're not using the "Automatic options selection" no?

SVP3 is available, SVP4 only pro. Since I don't use SVP Manager anymore so cannot say for sure.

53 Reply by Nintendo Maniac 64 (edited by Nintendo Maniac 64 07-02-2016 19:32:49)

Re: SVP 4 artifacting is unacceptable

mashingan wrote:

Of course, for 720p video and Hexagon search, the rise should within "common" CPU's capabilities. Especially if one has very good CPU, the different of CPU usage can be neglected.

My HTPC only uses a 2.4GHz Core 2 Duo with no GPU acceleration nor HW decoding...

On the other hand, my primary desktop system is a 4.6GHz Pentium G3258.

mashingan wrote:

SVP3 is available

3.1.7 gives me crazy juddery flickering 80-90% of the time (unless I disable GPU acceleration) and 3.1.6 and earlier is noticeably slower than SVP4.

Re: SVP 4 artifacting is unacceptable

Someone posted early 317 beta claimed it works much better than final. Did you test it ?

Re: SVP 4 artifacting is unacceptable

dlr5668 wrote:

Someone posted early 317 beta claimed it works much better than final. Did you test it ?

I wasn't a beta tester at the time, so I've no idea where such a thing would even be.

  • Thanks: 37

Re: SVP 4 artifacting is unacceptable

Nintendo Maniac 64
I misread your post by I meant available in SVP3. As far I know, the search type is not available via GUI. I don't know in SVP4.

The default value is 4 (exhaustive search) though. So it would be best if you check your "last used script" and check variable analyse_params whether the main.search.type is redefined in there. If not, it's safe to say you're using default value.

My setting for search distance pixel and search type have different value between 720p and 1080p video. 1080p considerable lower setting with distance = -6 and type = 3, while for 720p distance = -10 and type = 4.

57 Reply by ThomasLiddiard (edited by ThomasLiddiard 08-02-2016 20:17:35)

  • Thanks: 2

Re: SVP 4 artifacting is unacceptable

After some further analysis I would like to address a couple of errors in my previous post:

1. The setting "analyse.main.search.coarse.type" is in fact "analyse.main.search.type" (an easy mistake to make) which cannot be modified in any way in the settings of SVP 3 and SVP 4 and the default values are again 4 and 2 respecively. This has a slightly different effect of changing the search type of the finest level of interpolation instead of the coarse levels.

2. I somehow overlooked comparisons of several consecutive frames from the same source material which revealed frames that did not match, due to another script parameter. This was surprising since I managed to select 3 test frames from different source materials which did match, amongst the pool of matching and mismatching frames in each source material.

The parameter in question is "scene.mode" and in fact made another large difference in artifacting on those frames which did not match. The value used (with the profile settings given previously) in SVP 3 is 3 and in SVP 4 is 1. This is very strange since according to the documentation this controls the overall interpolation mode and should be set to 1 to force 1m mode and 3 to force adaptive mode. However one can alternatively keep adaptive mode and change the threshold values for switching from uniform to m1 and m2 in order to force 1m, 2m, 1.5m modes (see documentation on "scene.limits" for info on this.) SVP 3 and SVP 4 already have the threshold values both set to zero which forces 1.5m mode, but it appears that the value of 1 used for "scene.mode" in SVP 4 overrides this to m1 mode (more artifacts).

Therefore for now the value of 3 must also be specified for "scene.mode" in the override.js script to prevent SVP 4 from using 1m mode instead of 1.5m.

This appears to be an error in how SVP 4 generates scripts using 1.5m mode and should be fixed by the developers. It would also be nice if the "search range" had more options which correspond to smaller steppings in the value of "analyse.main.search.coarse.distance", such as a slider like on the main screen. This would allow, without much added confusion, better tuning that can allow us to get the same settings for SVP 3 "medium" and "large".

Home this helps! smile

Re: SVP 4 artifacting is unacceptable

Maybe it's be a good idea to make your own thread in the dev forum section dedicated to these results?  That is, just to give said results more visibility.

Also, so as to not make it sound redundant, you probably don't want to name such a thread something similar to this thread but rather maybe something along the lines of "Differences and mistakes in underlying interpolation between SVP3 and SVP4?"

  • Thanks: 1

Re: SVP 4 artifacting is unacceptable

Any updates on this?

Will the differences between version 4 and 3 be "fixed" ?

I am about to switch back from svp4 pro to svp 3.1.7 because of the increase of halo artefacts, but am willing to wait if I know a fix is on the way..



Ronald

Re: SVP 4 artifacting is unacceptable

Well there will be a large update (4.1?) that will coincide with the Linux release...

Also I believe the error with 1.5m has since been fixed.

  • Thanks: 1

Re: SVP 4 artifacting is unacceptable

Ok thanks for the info, I will  wait for the update then :-)

Re: SVP 4 artifacting is unacceptable

I should have clarified, the 1.5m error has been fixed in recent updates - no need waiting for the supposed "big update".

Re: SVP 4 artifacting is unacceptable

I tried using SVP 4, however I still "noticed" that 3.1.7a is slightly better.
I "experimented" with using an updated version of svpflow1.dll & svpflow2.dll from the SVPflow 4.0.0.128 (Avisynth plugins).
Also noticed the image artifacts reduced... tried it out and let me know what you think.

  • Thanks: 3

Re: SVP 4 artifacting is unacceptable

Nintendo Maniac 64 wrote:

I should have clarified, the 1.5m error has been fixed in recent updates - no need waiting for the supposed "big update".

And it's back again in a similar form, but still different. The artifacting is similar to having an increased motion vectors grid. This is something that was not present 2 or 3 versions ago. This is getting ridiculous.

Re: SVP 4 artifacting is unacceptable

i have the same problem how do fix blur