SVPflow motion interpolation (Avisynth + Vapoursynth, Linux, Mac?) [Archive] - Page 5

Reel.Deel

1st April 2014, 14:18

SVPflow 1.0.10

+ GPU rendering in linear light by default (see "linear" param in SVSmoothFps)
= SAD functions updated to the latest x264 code
= minor changes in black borders filling (it can fill very thin - 2px - borders now)

direct link (http://www.svp-team.com/files/gpl/svpflow-1.0.10.zip)

Thank you chainik, long time no see :).

johnmeyer

1st April 2014, 17:46

Some comparisons about "linear light": ... Those pathological test cases look absolutely amazing. If that translates to real video cases, the improvements will be quite substantial. Thank you!

chainik_svp

5th May 2014, 23:03

SVPflow 1.0.11

= Fixed crash in CPU rendering mode with pel>1 and blend=true
= Fixed rounding error in GPU rendering mode (leads to flickering (+-1 luma) visible on dark scenes)

Additional thanks to SubJunk for not pointing me to the 1st one.

SubJunk

5th May 2014, 23:10

My computer has been broken so I couldn't do good testing until it was fixed. Glad you fixed it!

mark0077

5th May 2014, 23:33

cheers for the update!

franketto

24th June 2014, 11:06

I have crash in VD on the KernelBase.dll just after loading the avs script, trying settings with higher value on threads .

i.e I have a script:

SetMemoryMax(1024)
global svp_scheduler=true
threads=10
global svp_cache_fwd = threads + 2
SetMTMode(3,threads)

source = AVIsource(".......avi")

setmtmode(2)

#some filters....

If I set threads = 8 all is ok, but with >= 10 it crashes. (I have an i7 920 4core 6GB ram, W7 pro 64bit)
With other (less) filters I can raise a bit until it crashes again.

I tried to change all other settings (setmemorymax), but nothing changes.

So, is this the only method to detect how many threads can we use? Raise the threads value until it crashes on load in VD? Or are there some other tricks to raise that value?

For the rest, thank you chainik_svp, with SVConvert I get a 40% increase in speed.

EDIT:
Even if it loads in VD, I had to lower threads to 7 to make it render to x264, otherwise it crashes... but this way I get CPU @ 45%: this vanishes the speed gain vs plain avisynth 2.6 MT...!

StainlessS

2nd August 2014, 10:06

Just thought I'de point something out, it is not a problem for me.

With
svpflow1.dll v1.3.5.0, svpflow2.dll v1.5.8.0 and svpflow_cpu.dll v1.7.2.0, supplied with Interframe v2,
in my plugins directory, and running VS 6.0, selecting to debug one of my plugs, VS debugger runs selected app
VirtualDubMod, but pops up an error message "First Chance Exception in VirtualDubMod.exe, (NTDLL.dll); 0xC0000008: Invalid Handle".
Problem disappears on removing these three plugs from plugins folder (still occurs if only svpflow1.dll in plugs dir).

Might be an indication of a problem in the plugins. (Interframe does not seem to be affected).

EDIT: I tried also copying svpflow_gpu.dll v1.8.4.0 to plugins, where I get this message,

"The application has failed to start because OpenCL.dll was not found. Re-installing the application may fix the problem."

and then on OK'ing the alert box I get the original error message. Might assist in knowing that the original error occurs
after the gpu dll tries to access OpenCL dll. (I dont use the gpu dll).

Groucho2004

2nd August 2014, 10:22

Just thought I'de point something out, it is not a problem for me.

With
svpflow1.dll v1.3.5.0, svpflow2.dll v1.5.8.0 and svpflow_cpu.dll v1.7.2.0, supplied with Interframe v2,
in my plugins directory, and running VS 6.0, selecting to debug one of my plugs, VS debugger runs selected app
VirtualDubMod, but pops up an error message "First Chance Exception in VirtualDubMod.exe, (NTDLL.dll); 0xC0000008: Invalid Handle".
Problem disappears on removing these three plugs from plugins folder (still occurs if only svpflow1.dll in plugs dir).

Might be an indication of a problem in the plugins. (Interframe does not seem to be affected).
What version of Avisynth? I get these "First chance" exceptions all the time when I debug something that loads the AVS+ avisynth.dll. These exceptions can apparently usually be ignored and you can disable them in the debugger.

StainlessS

2nd August 2014, 10:30

I'm currently using Official v2.6. (think I'll switch again to using your ICL build).
the debug messages are of little concern, just thought the devs might be interested to know.
thanks Groucho.

chainik_svp

3rd March 2015, 22:56

SVPflow 1.1.12

= up to 20% faster (0)
+ "64-bit ready" (1) - assembler code (still not all of them) ported/rewritten in intrinsics, target compiler is VC++2013
+ new option in SVAnalyse - search.main.coarse.width (2) - to get more than one "finest" levels
+ SATD for 32-x blocks (3)
= reduced memory usage for large number of small blocks (4)
= refactoring - removed svpflow_cpu/gpu modules - merged with svpflow2

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.12.zip)

Comments:

(0) For example: default settings (16x blocks, 1/4 overlap, pel 2), 1080p, 5:2 FRC, single thread: 27 fps vs. 22.7 fps.
But 32-x block will be much slower with default settings - see (3)

(2) Coarse levels differ from finest level in some processing options, like search type/distance, usage of SATD, "trymany" and sorted blocks order. This option allows to divide levels into "finest" and "coarse" by their width - levels with width less than "coarse.width" will be processed with "coarse" options. Default value is 1050.

(3) 32-x block was always processed with SAD function regardless of options used

(4) You possibly won't ever see this with regular Avisynth 2.6 :D But it's something like 1.8 GB vs. 1.4 GB memory usage for 1080p @4x blocks, or 4K @8x blocks

(1) In fact I have 64-bit build working with 64-bit AVS+ MT. Still AVS+ (and especially MT) is far for being stable enough for SVP :(

kolak

3rd March 2015, 23:02

Any thoughts about adding phase correlation?

chainik_svp

3rd March 2015, 23:10

I'll be happy enough if/when it'll work in x64 with built-in MT.
Sadly it's too much work on a paid job...

kolak

4th March 2015, 00:22

I assume same answer for 16bit pipe:)

chainik_svp

4th March 2015, 00:38

gpu rendering pipe is floating point already
MVs search part is quite good with 8 bit integers
What exactly are you asking for? :)

SubJunk

4th March 2015, 01:47

Thanks a lot for the update!

kolak

4th March 2015, 09:11

gpu rendering pipe is floating point already
MVs search part is quite good with 8 bit integers
What exactly are you asking for? :)

16bit pipe, so I can preserve 10bit.

feisty2

4th March 2015, 11:05

16bit pipe, so I can preserve 10bit.

vaporsynth mvtools can grant your wish

Reel.Deel

4th March 2015, 14:49

vaporsynth mvtools can grant your wish
Yeah but in terms of motion interpolation quality, SVPFlow is definitely much better.

gpu rendering pipe is floating point already
MVs search part is quite good with 8 bit integers

I second kolak request, would be nice for SVP to support 16-bit input/output. Regarding SVAnalyse only supporting 8-bit, we can always dither to 8-bit and perform the actual interpolation on the 16-bit clip.

chainik_svp

4th March 2015, 15:45

Correct me if I'm wrong but to be able to use 16-bit video formats plugin should be compiled with 2.6 avisynth.h. So I'll be forced to release rendering plugin under GPL. Right?

Another question - why the hell all of you people need 10 bits? :) I really don't understand. 10 bit is an encoder option/feature to compress 8-bit sources better. And somewhere after decoder you always need to dither it down to 8 bits. So why just don't do it right after the decoder?

Reel.Deel

4th March 2015, 16:07

Correct me if I'm wrong but to be able to use 16-bit video formats plugin should be compiled with 2.6 avisynth.h. So I'll be forced to release rendering plugin under GPL. Right?

No, a regular 2.5 plugin would suffice. Take a look at Dither, (http://forum.doom9.org/showpost.php?p=1386559&postcount=3)it's a 2.5 plugin. 16-bit processing in AviSynth just uses the Stack16 (http://forum.doom9.org/showpost.php?p=1631712&postcount=7) format which splits the MSB/LSB. MSB at the top, LSB at the bottom, thus the stack 16 format is always double in height.

feisty2

4th March 2015, 16:13

Another question - why the hell all of you people need 10 bits? :) ?
I don't want 10 bits, I want float point, you might input an 8 bits clip and output 8 bits for the result clip, but you need every step in between to be at the highest possible precision to avoid rounding error add-ups, it doesn't matter if all you need is one simple filter, but it does matter if you got a process filter chain
like, if every filter only takes integer input and outputs integer result
input : 120
process : 120 / 7 = 17.14285714285714.., round to 17
process : 17*7 = 119

or you result integer, but everything in between is at float point
input : 120
process : 120 / 7 = 17.14285714285714..
process : 17.14285714285714.. * 7 = 120

that's why it matters

kolak

4th March 2015, 16:15

Because even if final delivery is 8bit you should always keep your main master at 10bit (specially when you had nice 10bit source material).
You may want to do legalisation, dithering etc, so 10bit master is a very useful. It's rather for pro market, but 10bit is quite often a must there.

SEt

4th March 2015, 16:36

Correct me if I'm wrong but to be able to use 16-bit video formats plugin should be compiled with 2.6 avisynth.h. So I'll be forced to release rendering plugin under GPL. Right?
There is no 'official' support for >8 bit even in Avisynth 2.6. Also, you can make 2.5 plugin with support of 2.6 colorspaces – I don't think that interfaces are subject to license restrictions.

And somewhere after decoder you always need to dither it down to 8 bits. So why just don't do it right after the decoder?You are definitely wrong. I have 10+ bit pipeline from decoder to monitor and don't need to go back to 8 bits anywhere.

chainik_svp

4th March 2015, 18:34

I have 10+ bit pipeline from decoder to monitor

You - may be.
But most people take 8-bit anime encoded in 10-bit, send it as 8-bit to monitor that shows it on 6-bit LCD panel :D And they all really think they watching 10-bit video...

Sparktank

5th March 2015, 01:15

:D And they all really think they watching 10-bit video...

Pretty sure in this century they know by now they're not watching 10bit.
To them, they're just watching less banded material than the sources.

mark0077

5th March 2015, 21:09

Thanks for the update!

I guess 20% improvement isn't in work sent to the cpu? I am using GTX 980 with core i7 920 @ 3.6ghz. I'm always able to play 1080p -> 59.94fps conversion with 16 block size and overlap 2 without frame drops, ~45% cpu load max, but switching to 8 block size as is default for Medium preset in Interframe, the cpu usage seems to always be my bottle neck. It hits 100% and I get frame drops. I guess theres nothing I can do about it as my cpu is limiting factor now and not the gpu?

gpu load is only 17% according to gpu-z in this scenario, cpu 100% when I go to 8 block size :D Is there any possibility of future updates to move more of this work to the gpu do you think or is not feasible?

SubJunk

5th March 2015, 22:10

Yeah it would be really cool to see the GPU do more :)

chainik_svp

5th March 2015, 23:03

I guess 20% improvement isn't in work sent to the cpu?

Well, it is.
Like I said before - at default settings (16x blocks, 1/4 overlap, pel 2), 1080p, 5:2 FRC, single thread: 27 fps vs. 22.7 fps

mark0077

5th March 2015, 23:24

ah ok, I guess my cpu isn't good enough then :D Is the work thats being done on cpu currently, even possible to do on the gpu efficiently? My lovely GTX 980's fans arn't even spinning but my poor cpu is maxed out :D

chainik_svp

9th March 2015, 16:04

SVPflow 1.1.13

= fixed broken SVConvert function

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.13.zip)

TCmullet

9th March 2015, 21:09

SVPflow 1.1.13

= fixed broken SVConvert function

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.13.zip)
Good news. Thank you!

But as I seek to copy the two dlls over, I see the date for svpflow1.dll is a day earlier (1/27/2015) than the last known version (1/28/2015). Are you sure something's not mixed up?? (I always expect equal or later dates, not earlier ones.)

chainik_svp

9th March 2015, 21:13

TCmullet
Are you sure something's not mixed up??

I believe you'll tell me :D

TCmullet

9th March 2015, 21:25

TCmullet
Are you sure something's not mixed up??

I believe you'll tell me :D
I just did. :) I trust you'll have an explanation for why the later one has an earlier date (a boo-boo IMHO) and maybe a fix.

chainik_svp

9th March 2015, 21:39

I have no idea. My screen's showing me right now the contents of zip file downloaded from the link above:
"svpflow1.dll 356864 2015-03-06 14:25"
which is the exact binary from there (http://www.svp-team.com/forum/viewtopic.php?pid=47347#p47347)

TCmullet

9th March 2015, 21:47

Partial mistake by me. It is svpflow2.dll, not 1.dll. I got it again from where you say "direct link". That is, I downloaded again after your last reply. Date still says 1/27/2015, whereas the prior one (the one SubJunk gave out with InterFrame 2.8.0 as dependencies) was 1/28/2015.

Sparktank

10th March 2015, 00:25

It is svpflow2.dll.
Date still says 1/27/2015, whereas the prior one (the one SubJunk gave out with InterFrame 2.8.0 as dependencies) was 1/28/2015.

I got:

svpflow-1.1.12\svpflow2.dll
created:‎ July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

svpflow-1.1.13\svpflow2.dll
created: ‎July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

InterFrame-2.8.0\Dependencies\svpflow2.dll
‎created: March-‎04-‎15, ‏‎8:09:58 PM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

Whatever you're using to extract could be changing the dates to the day you extract them.
There should be options to keep original dates of the files inside the archive.

svpflow1.dll has the same (modification) dates between svpflow-1.1.12 & InterFrame-2.8.0: ‎January-‎27-‎15, ‏‎5:37:26 AM
Only svpflow-1.1.13 has different date for svpflow1.dll: ‎March-‎06-‎15, ‏‎3:25:21 AM

TCmullet

10th March 2015, 01:41

I got:

svpflow-1.1.12\svpflow2.dll
created:‎ July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

svpflow-1.1.13\svpflow2.dll
created: ‎July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

InterFrame-2.8.0\Dependencies\svpflow2.dll
‎created: March-‎04-‎15, ‏‎8:09:58 PM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

Whatever you're using to extract could be changing the dates to the day you extract them.
There should be options to keep original dates of the files inside the archive.

svpflow1.dll has the same (modification) dates between svpflow-1.1.12 & InterFrame-2.8.0: ‎January-‎27-‎15, ‏‎5:37:26 AM
Only svpflow-1.1.13 has different date for svpflow1.dll: ‎March-‎06-‎15, ‏‎3:25:21 AM
Okay, you've gotten me suspicious. I killed the WinRAR I was using. Now only Windows Explorer (Win 7) is handling things. One question about YOUR data... How can a modification date be EARLIER than a creation date, unless one has grossly tampered with the system clock?

I've reextracted all from the InterFrame 2.8.0 zip file. W7 sadly mucks the mod dates. But creation dates are as follows:
InterFrame2.avsi 3/5/2015 4:01pm
InterFrame2.html 3/5/2015 4:08pm
Dependencies:
Builds.txt 3/4/2015 10:02pm
svpflow1.dll 1/28/2015 1:37am
svpflow2.dll 1/28/2015 1:46am

Things could be off by hours at worst due to time zones, but maybe SubJunk could confirm who's dates are correct.

And just for the fun of it, I redownloaded 2.8.0 from:
http://www.spirton.com/interframe/ and got same creation dates.

I need to revisit all this now that I am looking at creation dates vs mod dates. It appears that unzipping mods the mod date. (I'm disliking Win7 more and more.)

TCmullet

10th March 2015, 01:57

Furthermore, I've redownloaded from "direct link" and the creations dates are:
svpflow1.dll 3/6/2015 1:25pm
svpflow2.dll 1/27/2015 3:46pm

So.... does SubJunk need to update his dlls to be current? (But maybe unnecessary if InterFrame does not use any svp.dll changes since 1/28 or 1/27.)

And btw, I see one potential difficulty. As these 2 dlls seem to be "copied around", there is no way to associate them with any particular version of SVPFlow (1.1.13 in this case). There are no dates in the change log.

I guess the important question for me is, should I copy these dlls, obtained from "direct link" to my plugins folder for Avisynth and use them for all things I might use them for, and disregard the ones that came with InterFrame 2.8.0?

Sparktank

10th March 2015, 02:02

How can a modification date be EARLIER than a creation date

The extraction settings were set to retain original dates/times from whatever was archived by whomever archived the files.

Downloaded Interframe and extracted and got the same results.
Removing settings to retain original dates changed all dates to current date/time that I extracted.

But, I checked CRC values for different versions.

CRC for svpflow2.dll in svpflow-1.1.12 and InterFrame-2.8.0 are identical.
svpflow-1.1.13 doesn't match anything because it's obviously updated.

The affected dates in SubJunks Interframe archive are probably due to the date/time he extracted and/or created his archive and depending on what software and settings he used.
SubJunk can confirm what software he's using and the settings.

An alternative to WinRAR is 7zip.
It has settings to retain original dates for the archived files, whether you're extracting or archiving.

You might be able to retain original dates in Windows own extractor, but probably if you use the CMD instead of the integrated shell.
I don't know, never used OS extactor.

That's as far as I'll continue on the subject of the dates for the files.

Back on topic, I appreciate the updates to SVPflow.
I'm noticing considerable performance increase on full 1080p (non-cropped) remuxes (in regards to using SVP).

Sparktank

10th March 2015, 02:04

InterFrame 2.8.0?

Has not been updated to use SVPflow v1.1.13 yet.
(it will probably be released as v2.8.1)

kaefert

24th March 2015, 14:45

I have a question about SVP: When I have Avisynth running on a computer without a compatible GPU from this list:
http://www.svp-team.com/wiki/GPU_Compatibility

and use SVP with the "{gpu:0}" parameter set - will this only run slower, or will I also have a lower quality of the motion interpolated frames than the GPU-Version?

Background: I do not view the result live, but encode it for later viewing it on an hardware media player - therefore I can tolerate slower speeds, but I would like to know if the CPU version is "only" slower or also lower in quality then the GPU version of SVP.

mark0077

24th March 2015, 20:22

gpu being used does increase quality. See below quote from the SVP user Manual http://www.svp-team.com/wiki/SVP:User_manual

"Attention: GPU acceleration enhances the frame interpolation quality"

kaefert

24th March 2015, 20:45

gpu being used does increase quality. See below quote from the SVP user Manual http://www.svp-team.com/wiki/SVP:User_manual

"Attention: GPU acceleration enhances the frame interpolation quality"

well, this guide is focused on live playback of motion interpolated frames. this will of course be better quality with a gpu than without, since the cpu can't perform the same level of caluclations in real time that a gpu can - but when the real time requirement is lifted, is that statement still true?

Sparktank

24th March 2015, 20:56

is that statement still true?

Should still apply to offline.
InterFrame uses SVPflow and is intended for encoding and benefits greatly from using GPU.

mark0077

24th March 2015, 20:59

well, this guide is focused on live playback of motion interpolated frames. this will of course be better quality with a gpu than without, since the cpu can't perform the same level of caluclations in real time that a gpu can - but when the real time requirement is lifted, is that statement still true?

All the same, InterFrames Medium preset is pretty much as good quality as you can get at the moment (live or offline), and it works in realtime on medium / fast PCs. Saves having to convert all movies offline.