View Full Version : nnedi3 plugin for VapourSynth
jackoneill
10th November 2012, 18:23
Source: https://github.com/dubhater/vapoursynth-nnedi3
DLLs can be found in the "releases" section (https://github.com/dubhater/vapoursynth-nnedi3/releases).
Please test and report back. Patches are welcome too.
nnedi3_rpow2 can be found here: http://forum.doom9.org/showthread.php?t=172652
kolak
10th November 2012, 22:10
8bit precision only or also 10bit (16) ?
jackoneill
10th November 2012, 22:48
8bit precision only or also 10bit (16) ?
Precision?... If you're asking what bit depths it accepts for input, only 8. (This might change in the future.) Internally it does the same as the avisynth filter. It's mostly the same code.
Revgen
11th November 2012, 00:15
I notice that there is no "Threads" option for this filter like there is for the avisynth filter. So it can't do multi-threading internally?
mandarinka
11th November 2012, 00:59
Nice job!
Reel.Deel
11th November 2012, 01:04
@ jackoneill
Thank you very much for taking time to port NNEDI3, Histogram, and TemporalSoften. Awesome work :).
I'll test them out and report back if I find any discrepancies.
=============================================
@ Revgen
This post (http://forum.doom9.org/showthread.php?p=1591455#post1591455) might answer your question on multi-threading.
jackoneill
11th November 2012, 07:41
I notice that there is no "Threads" option for this filter like there is for the avisynth filter. So it can't do multi-threading internally?
Indeed, there is no internal threading anymore. There is no need for it, because Vapoursynth makes it process several frames in parallel.
lansing
11th November 2012, 09:46
just ran a speed test against the avisynth nnedi3 on a 720x480 clip, encode with x264 ultrafast preset, the avisynth one's got 30+ fps, and the vs' got only 3.x fps, something must be wrong
jackoneill
11th November 2012, 10:22
just ran a speed test against the avisynth nnedi3 on a 720x480 clip, encode with x264 ultrafast preset, the avisynth one's got 30+ fps, and the vs' got only 3.x fps, something must be wrong
Nothing is wrong. The avisynth version has optimised SSE2 code. Mine doesn't.
You'll get about the same low speed from the avisynth version with opt=1.
jackoneill
16th November 2012, 10:53
Hi!
A new build is available for testing, now with more speed. Use opt=2, but keep the other parameters at their default values, for now (or it will eat your cat). I have only converted a few of the asm functions — those that are used when all parameters are at their default values (except for opt, of course).
opt=2 requires SSE2, obviously.
This new build also requires VapourSynth R15.
Also, it now accepts any colorspace with 8 bits per sample, not just YUV.
https://github.com/dubhater/vapoursynth-nnedi3/downloads
Revgen
16th November 2012, 21:46
Quick test. Played back through vdub using a 1920x1080i mpeg2 source and compared vapoursynth SSE2 version (using version R15) and the latest avisynth version (using an avisynth script) with my Q6850 quadcore cpu & WinXP pro. Vapoursynth version runs most optimally with vs.Core(threads=5). Changing it to threads=6 didn't seem to be much better. Avisynth version worked optimally at threads=4. Vapoursynth version runs about 2-3fps faster than avisynth version.
Vapoursynth script
import vapoursynth as vs
import sys
core = vs.Core(threads=5)
core.avs.LoadPlugin(path=r'C:\dgindex\DGDecode.dll')
core.std.LoadPlugin(path=r'C:\Program Files\VapourSynth\nnedi3-testing.dll')
ret = core.avs.MPEG2Source(r'E:\mympeg2.d2v')
ret = core.nnedi3.nnedi3(clip=ret,opt=2,field=3)
last = ret
17fps-18fps
Avisynth scrpt
mpeg2source("E:\mympeg2.d2v")
nnedi3(opt=2,field=3,threads=4)
15fps-16fps
kolak
16th November 2012, 23:06
Interesting :)
Keiyakusha
16th November 2012, 23:11
Can you also check CPU usage? Because when we'll do actual encoding something like 18fps and 50% cpu load won't make things faster than 10fps and 25% load
Also I posted it before but deleted suggestion cause I'm not sure anymore, but to utilize vapoursynth's MT better, maybe it is good idea to add more filters. Like 2 consecutive nnedi or something (but make sure that it doesn't bottlenecks elsewhere, like overly high resolution...)
Revgen
16th November 2012, 23:29
Vapoursynth is running at 98-99% load and avisynth is running at 87-88% load.
Revgen
17th November 2012, 00:06
Tried double NNEDI3. Had to bump it up to vs.Core(threads=7) to optimally use vapoursynth this time. Threads=4 was stilll the most optimal for avisynth. Avisynth CPU load was 90% to 91%. Vapoursynth was 97% to 98%. Avisynth was about .5 to 1fps slower than vapoursynth. Vapoursynth ran 12.5fps-13fps while avisynth ran 12fps to 12.5fps. However, there was a huge discreprancy in memory usage. Avisynth was using about 1gb of RAM before I stopped playback. Vapoursynth was always consistently at 200mb of usage.
Myrsloik
17th November 2012, 00:10
Tried double NNEDI3. Had to bump it up to vs.Core(threads=7) to optimally use vapoursynth this time. Threads=4 was stilll the most optimal for avisynth. Avisynth CPU load was 90% to 91%. Vapoursynth was 97% to 98%. Avisynth was about .5 to 1fps slower than vapoursynth. Vapoursynth ran 12.5fps-13fps while avisynth ran 12fps to 12.5fps. However, there was a huge discreprancy in memory usage. Avisynth was using about 1gb of RAM before I stopped playback. Vapoursynth was always consistently at 200mb of usage.
The ram difference is just because of different cache strategies. Avisynth caches everything until it bumps into the set memory limit. VS keeps track of the cache request history as well and is decent at detecting linear scans and minimizing cache sizes then.
Revgen
17th November 2012, 00:22
Okay, I used SetMemoryMax(250) this time. Memory usage is under control and avisynth performance is still the same.
jackoneill
17th November 2012, 13:08
Thank you all for testing. I'm glad to see it's working.
I'm done with the asm. The new build should be fully functional now. opt=2 is default. Please try your favourite combination of exotic parameters.
Reel.Deel
17th November 2012, 13:30
Internally it does the same as the avisynth filter. It's mostly the same code.
If I understand this correctly, this means NNEDI3 works in 16-bit internally, then dithers/rounds/truncates(?) to 8-bit. Correct?
High bit depth input/output would be lovely. :)
*edit*
My previous question (NNEDI3 internal processing) is irelevant. I (somehow) misinterpreted the quoted statement and thought that NNEDI3 works like avisynth's internal resizing filters. Sorry for being dumb. :o
jackoneill
17th November 2012, 20:08
If I understand this correctly, this means NNEDI3 works in 16-bit internally, the dithers/rounds/truncates(?) to 8-bit. Correct?
High bit depth input/output would be lovely. :)
No idea. Investigating the possibility of high bit depth input and output is on my todo list.
mandarinka
18th November 2012, 01:18
At least some internal operation are done in higher-bitdepth, judging by this and following posts - http://forum.doom9.org/showthread.php?p=1427793#post1427793.
The behaviour (what gets used internally) depends on the fapprox option though.
jackoneill
18th November 2012, 14:18
Could someone please test if these two produce exactly the same output (md5sum or similar)?
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(path="ffms2.dll")
core.std.LoadPlugin(path="nnedi3.dll")
ret = core.ffms2.Source(source="8-bit-h264.mkv")
ret = core.nnedi3.nnedi3(clip=ret, field=0, opt=1)
ret = core.std.Trim(clip=ret, first=0, last=99)
ret.output(sys.stdout, y4m=False)
ffvideosource("8-bit-h264.mkv")
nnedi3(field=0, opt=1)
trim(0, 99)
Chikuzen
18th November 2012, 14:48
Could someone please test if these two produce exactly the same output (md5sum or similar)?
import vapoursynth as vs
core = vs.Core()
core.std.LoadPlugin('G:/vsplugins/vsrawsource.dll')
core.std.LoadPlugin('G:/vsplugins/nnedi3.dll')
clip = core.raws.Source('D:/test_media/derf/soccer.y4m')
clip = core.nnedi3.nnedi3(clip, field=0, opt=1)
clip = core.std.Trim(clip, first=0, last=99)
out = open('nnedi3_test.y4m', 'wb')
clip.output(out, y4m=True)
out.close()
https://dl.dropbox.com/u/19797864/subtract_nnedi3.png
not same output.
Reel.Deel
18th November 2012, 14:54
Just for reassurance, the checksums between the two are indeed different.
jackoneill
18th November 2012, 16:10
All right. Thank you.
Reel.Deel
15th December 2012, 15:45
Hi jackoneill, I recently noticed that GitHub no longer has the downloads section. If it's not too much trouble maybe you can re-upload the dll's some place else?
A couple of weeks ago I was searching along and I came across this NNEDI3 wrapper for VapourSynth (http://www.binrand.com/post/4226552-base-vapoursynth-i-had-write-a-vapoursynth-wrapper-of-nnedi-3-base-on-loren.html) based on akupenguin's implementation (http://forum.doom9.org/showthread.php?p=1427793&highlight=nnedi#post1427793). I was wondering if maybe it would be a good idea to adopt the upscaling part onto your ported NNEDI3 plugin? If that's too much work than sorry for bothering. :)
(Sorry for the link, but I couldn't find the original one posted at pastebin.)
jackoneill
15th December 2012, 17:52
Hi jackoneill, I recently noticed that GitHub no longer has the downloads section. If it's not too much trouble maybe you can re-upload the dll's some place else?
Yeah, they axed that feature (https://github.com/blog/1302-goodbye-uploads). I'll probably upload them to uloz.to.
A couple of weeks ago I was searching along and I came across this NNEDI3 wrapper for VapourSynth (http://www.binrand.com/post/4226552-base-vapoursynth-i-had-write-a-vapoursynth-wrapper-of-nnedi-3-base-on-loren.html) based on akupenguin's implementation (http://forum.doom9.org/showthread.php?p=1427793&highlight=nnedi#post1427793). I was wondering if maybe it would be a good idea to adopt the upscaling part onto your ported NNEDI3 plugin? If that's too much work than sorry for bothering. :)
As far as I know, tritical's version can do everything akupenguin's can, and more.
Now that fmtconv exists and works in Linux, I can probably recreate nnedi3_rpow2.
Tima
19th December 2012, 22:46
Yeah, they axed that feature (https://github.com/blog/1302-goodbye-uploads). I'll probably upload them to uloz.to.
You can still download binaries from github:
https://github.com/dubhater/vapoursynth-nnedi3/downloads
This method will be working for 90 days after 2012-12-11, according to the statement in their blog post.
jackoneill
28th December 2012, 15:08
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
core.std.LoadPlugin(r'C:\Program Files (x86)\VapourSynth\filters\nnedi3.dll')
clip = core.ffms2.Source(r'test.mp4', threads=1)
clip = core.nnedi3.nnedi3(clip, field=0, nsize=0, opt=2)
clip = core.nnedi3.nnedi3(clip, field=0, nsize=4, opt=2)
clip.output(sys.stdout, y4m=True)
The above script will directly crash python without any error message. test.mp4 (http://www.mediafire.com/?x9m9d19pvamy36c) is just a video encoded from ColorBars(pixel_type="YV12") of avs. Setting opt=1 in second nnedi3 call eliminates the crash problem. The strange thing is if I use core.std.BlankClip(format=vs.YUV420P8) as the source clip and keep opt=2 in both nnedi3 calls, it doesn't crash. However it has nothing to do with ffms2, because I have tried d2vsource to load a d2v as source clip and it crashes too.
Sorry about that. I fail at C.
New dll here: http://uloz.to/xSuqyUw/nnedi3-dll. sha256sum: 45e712f038d23718b912b69fa69a8d603329a02bb19701f06873c2e84ef52dad
Please test and let me know if it works.
jackoneill
28th September 2013, 22:04
I added nnedi3_rpow2 (requested by aegisofrime). The readme.rst is updated, and DLLs can be found in the "releases" section (https://github.com/dubhater/vapoursynth-nnedi3/releases) on github.
For 4:2:0 and 4:4:4 (including RGB) the output should be the same as with the Avisynth version. For other formats, maybe it's correct, maybe not.
aegisofrime
29th September 2013, 03:50
I added nnedi3_rpow2 (requested by aegisofrime). The readme.rst is updated, and DLLs can be found in the "releases" section (https://github.com/dubhater/vapoursynth-nnedi3/releases) on github.
For 4:2:0 and 4:4:4 (including RGB) the output should be the same as with the Avisynth version. For other formats, maybe it's correct, maybe not.
Thanks very much! :)
Edit: Whelp, sorry I'm going to need your help again after your hard work adding rpow2. When I load libnnedi3.dll I get an error saying that "Python exception: 'No entry point found in C:\\Program Files (x86)\\VapourSynth\
\filters\\libnnedi3.dll'" Is there something that I'm missing here?
jackoneill
29th September 2013, 09:09
Thanks very much! :)
Edit: Whelp, sorry I'm going to need your help again after your hard work adding rpow2. When I load libnnedi3.dll I get an error saying that "Python exception: 'No entry point found in C:\\Program Files (x86)\\VapourSynth\
\filters\\libnnedi3.dll'" Is there something that I'm missing here?
Ah, that. It should be fixed now. I replaced the archive.
jackoneill
19th August 2014, 09:49
v2.0 is out, with support for up to 16 bits per sample. There is no asm for this, so it's slower than with 8 bit input. As usual, DLLs can be found at Github (https://github.com/dubhater/vapoursynth-nnedi3/releases).
Basically I hacked the float code path to take 16 bit input. It required working around an overflow and adjusting the prescreener weights for larger pixel values.
Does anyone want to volunteer to write asm?
foxyshadis
19th August 2014, 23:55
Now you're talking my language. Is it compiled to target any particular instruction set?
jackoneill
20th August 2014, 10:09
Now you're talking my language. Is it compiled to target any particular instruction set?
I don't know about the C code. I didn't pass any special options to gcc. The asm requires SSE2.
jackoneill
24th August 2014, 18:25
Here is v2.1 (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v2.1), which is ~6 times faster than v2.0 (measured with pscrn=0). No new asm was needed to obtain this speed-up, because the most important asm functions work with floats. It was just a matter of using them.
Mystery Keeper
25th August 2014, 01:41
Great work! ^_^
jackoneill
7th February 2015, 23:59
Since nnedi3 consists of lots of multiply + add operations, why not try FMA3/4? But of course my CPU is a Core 2, so someone else will have to test. Here is a set of DLLs with a few functions modified to use the vfmaddXXXps/vfmaddps instructions:
http://ulozto.net/xs6NnLV5/vapoursynth-nnedi3-v2-1-fma-win32-7z
http://ulozto.net/xC17v6dj/vapoursynth-nnedi3-v2-1-fma-win64-7z
To compile your own, check out the "fma" branch at Github.
Test with a 16 bit clip using the default parameters, or with an 8 bit clip using the default parameters and the following: "pscrn=1, fapprox=12". I'm very curious to see if it gets any faster. (Also if the output looks the same.)
Select FMA3 code with "opt=3", and FMA4 code with "opt=4". The default is still "opt=2".
Myrsloik
8th February 2015, 00:44
A small test on my computer with 12 threads gives:
8bit: 96fps (opt=3) and 80fps (opt=2)
16bit: 71fps (opt=3) and 62fps (opt=2)
Are_
8th February 2015, 02:35
I guess I did nothing wrong:
import vapoursynth as vs
core = vs.get_core()
v = core.d2v.Source(r'VTS_01_1.d2v', nocrop=True, rff=False)
v = core.fmtc.bitdepth(v, bits=16)
v = core.nnedi3.nnedi3(clip=v, field=0, pscrn=1, fapprox=12, opt=2)
v.set_output()
for ((i=1; i<=$@; i++)); do
vspipe test.py -e 2000 - 2>> speed.txt | md5sum >> integrity.txt
sleep 1
done
8bit,opt2
Output 2001 frames in 31.08 seconds (64.38 fps)
Output 2001 frames in 31.19 seconds (64.15 fps)
8bit,opt4
Output 2001 frames in 102.01 seconds (19.62 fps)
Output 2001 frames in 102.06 seconds (19.61 fps)
16bit,opt2
Output 2001 frames in 37.82 seconds (52.91 fps)
Output 2001 frames in 37.34 seconds (53.59 fps)
16bit,opt4
Output 2001 frames in 123.19 seconds (16.24 fps)
Output 2001 frames in 123.99 seconds (16.14 fps)
8bit,opt2
ebf18035a42531bbb518f56225539e90 -
ebf18035a42531bbb518f56225539e90 -
8bit,opt4
9e37a7ff03966a7915fd5c4896a4b53f -
9e37a7ff03966a7915fd5c4896a4b53f -
16bit,opt2
f6e42b870661c88de977fb868a075904 -
f6e42b870661c88de977fb868a075904 -
16bit,opt4
b5b73f2abe2008fbee8cf03f640e0e75 -
b5b73f2abe2008fbee8cf03f640e0e75 -
And indeed the output for opt=4 is wrong, chroma missplacement to the right and interlacing artifacts.
jackoneill
8th February 2015, 09:48
I guess I did nothing wrong:
[...]
And indeed the output for opt=4 is wrong, chroma missplacement to the right and interlacing artifacts.
Oops. There was a mistake in the FMA4 functions. I replaced the links.
Are_
8th February 2015, 13:37
No problems now. Even if the output is not bit identical, neither is the one from opt=1 with the one from opt=2, I can't spot a single difference.
16bit2opt
Output 2001 frames in 37.40 seconds (53.50 fps)
Output 2001 frames in 37.48 seconds (53.39 fps)
16bit4opt
Output 2001 frames in 32.51 seconds (61.55 fps)
Output 2001 frames in 32.62 seconds (61.35 fps)
8bit2opt
Output 2001 frames in 31.70 seconds (63.12 fps)
Output 2001 frames in 30.97 seconds (64.61 fps)
8bit4opt
Output 2001 frames in 25.44 seconds (78.67 fps)
Output 2001 frames in 25.32 seconds (79.03 fps)
kolak
18th February 2015, 00:24
Only 25% speed difference between 8 and 16bit- looks like a good result.
So can we have yadifmod now working at 16bit?
Reel.Deel
18th February 2015, 01:04
So can we have yadifmod now working at 16bit?
Yadifmod supports 9-16 bits since r2 (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-Yadifmod/releases).
Edit: also, here's the appropriate thread: http://forum.doom9.org/showthread.php?t=171028
kolak
18th February 2015, 23:38
Heh- I had a long break from avisynth/vapoursynth. I can remember now (I was chasing for it). Great!
MonoS
19th February 2015, 14:03
No problems now. Even if the output is not bit identical, neither is the one from opt=1 with the one from opt=2, I can't spot a single difference.
It's expected for the output to not be bit identical cause FMA instruction have higher precision than a mul followed than an add [that's because the fpu have infinite precision while fp register have finite precision IIRC]
jackoneill
22nd February 2015, 21:12
v3 is here (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v3).
* Use FMA (fused multiply-add) instructions in some functions. Speeds up the float paths a bit.
* Add another SIMD function for a little more speed with 16 bit input.
* Automatically select the best functions if opt=True, use only C functions if opt=False.
* Don't embed the weights into the DLLs. "nnedi3 weights.bin" needs to be in the same folder as the DLL.
"nnedi3 weights.bin" can be downloaded from Github: https://github.com/dubhater/vapoursynth-nnedi3/blob/master/src/nnedi3%20weights.bin It's the same file that's embedded in the Avisynth plugin.
There is theoretical support for architectures other than x86 now. Little endian ones. If anyone wants to run nnedi3 on something big endian, that can be arranged too, I think. You'll just have to volunteer to test it a bit.
mawen1250
6th March 2015, 19:33
With 9-16bit input and FMA3 opt, nnedi3 produces corrupt result. From what I observed, the pixels interpolated by nn predictor are either white or black.
http://i683.photobucket.com/albums/vv197/mawen1250/EP01%20-%20.vpy%20-%2020921_zps9dby6ecb.jpg
jackoneill
9th March 2015, 20:00
Here is v4 (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v4).
* Fix copy-paste error in the FMA functions
* Rename "nnedi3 weights.bin" to "nnedi3_weights.bin"
Due to an unforeseen limitation of Automake, the weights file has been renamed. v4 expects the new name.
The broken output reported in the post above is fixed.
jackoneill
23rd April 2015, 20:08
Here is v5 (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v5).
* Adjust the frame durations when doubling the frame rate.
* Fix buffer overflow with images wider than 8192 pixels or so (inherited from the Avisynth plugin).
* Hopefully prevent crashes with images that require more than 2 GiB per plane.
* Refuse to create clips longer than INT_MAX (often 2**31-1).
* Use the _FieldBased frame property to determine each frame's field order, for sources where it changes.
If the _FieldBased property is present in the input clip and you need to force a different field order, use std.ModifyFrame (http://www.vapoursynth.com/doc/functions/modifyframe.html) to overwrite the _FieldBased property.
lansing
30th April 2015, 01:33
the separate link for nnedi3_weights.bin file is broken in the download page
jackoneill
30th April 2015, 10:47
the separate link for nnedi3_weights.bin file is broken in the download page
Thanks. Fixed it.
lansing
30th April 2015, 20:07
it works now, the underscore is missing in the downloaded bin file name, and I'm also getting a "libwinpthread-1.dll is missing" error message
jackoneill
30th April 2015, 23:02
it works now, the underscore is missing in the downloaded bin file name, and I'm also getting a "libwinpthread-1.dll is missing" error message
The link is in the v3 release notes, so I made it point to the version of the file that works with v3, which has a space instead of underscore. I'll add links to the v4 and v5 release notes too.
I uploaded new builds of v5. The error message is no more.
lansing
10th May 2015, 00:09
I'd encounter problem again. I got a "no attribute with the name nnedi3 exists" error with v5. With v4, the video loads fine but crash on seek.
Try with vapoursynth R27.
lansing
10th May 2015, 01:47
I installed vapoursynth R27 rc1 and it gave me a series of error on startup on plugins
VapourSynth plugins manager: Failed to get pointer to the plugin Plugin1!
VapourSynth plugins manager: Failed to get pointer to the plugin Plugin10!
...
jackoneill
10th May 2015, 11:28
I installed vapoursynth R27 rc1 and it gave me a series of error on startup on plugins
VapourSynth plugins manager: Failed to get pointer to the plugin Plugin1!
VapourSynth plugins manager: Failed to get pointer to the plugin Plugin10!
...
That comes from the editor. Please report it here: http://forum.doom9.org/showthread.php?t=170965&page=5
Does it still crash when seeking?
jeremy33
15th May 2015, 11:59
Hello,
I try to use nnedi3 with VapourSynth on Linux and this is what I get :
http://img11.hostingpics.net/thumbs/mini_464396screenshot.jpg (http://www.hostingpics.net/viewer.php?id=464396screenshot.jpg)
What can do this ?
I'm on Netrunner 14 x64 (Kubuntu derivative) with nvidia 349.16 drivers, MPV 0.91 and VapourSynth 27 from this ppa https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth
jackoneill
15th May 2015, 12:08
Hello,
I try to use nnedi3 with VapourSynth on Linux and this is what I get :
http://img11.hostingpics.net/thumbs/mini_464396screenshot.jpg (http://www.hostingpics.net/viewer.php?id=464396screenshot.jpg)
What can do this ?
I'm on Netrunner 14 x64 (Kubuntu derivative) with nvidia 349.16 drivers, MPV 0.91 and VapourSynth 27 from this ppa https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth
Pretty. Please post your VapourSynth script. Also, what version of nnedi3 is that? Does it happen with opt=False?
jeremy33
15th May 2015, 12:20
This is my test script :
import vapoursynth as vs
core = vs.get_core()
clip = video_in
clip = core.nnedi3.nnedi3_rpow2(clip, 2)
clip.set_output()
It happen with opt=False.
It's nnedi3 from this ppa https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth?field.series_filter=trusty
This is not happening here with nvidia 349.16 and mpv, nnedi3 and vapoursynth from git. Does this happen outside of mpv?
jeremy33
15th May 2015, 13:37
What do you mean by saying "Does this happen outside of mpv" ?
sl1pkn07
15th May 2015, 14:25
with vapoursinth-editor or directly with pipe to x264
jeremy33
15th May 2015, 14:35
I try with vspipe but I don't find how to use a file as a clip ?
jackoneill
15th May 2015, 14:36
Okay, more info, please:
- exact resolution of the input video
- YUV? RGB? Something else?
- subsampling
- bit depth
text.ClipInfo() displays all of this.
jeremy33
15th May 2015, 14:47
This is the output of text.ClipInfo()
VideoNode
Format: YUV420P8
Width: 1280
Height: 544
Num Frames: 134217727
FPS Num: dynamic
FPS Den: dynamic
Flags: Is Cache, No Cache
jackoneill
15th May 2015, 16:17
Try this script:
def nnedi3_rpow2(src):
clip = src
clip = c.nnedi3.nnedi3(clip, field=1, dh=1, nsize=0, nns=3)
clip = c.std.Transpose(clip)
clip = c.nnedi3.nnedi3(clip, field=1, dh=1, nsize=0, nns=3)
clip = c.std.Transpose(clip)
if src.format.subsampling_h == 1:
clip = c.fmtc.resample(clip, kernel="spline36", sy=-0.5, planes=[2, 3, 3])
# if correct_shift:
clip = c.fmtc.resample(clip, kernel="spline36", sx=-0.5, sy=-0.5)
clip = c.fmtc.bitdepth(clip, csp=src.format.id)
return clip
import vapoursynth as vs
core = vs.get_core()
clip = video_in
#clip = core.nnedi3.nnedi3_rpow2(clip, 2)
clip = nnedi3_rpow2(clip)
clip.set_output()
The output should be just as broken as before. After you confirm that it's still broken, comment out the fmtc lines, one by one, starting with the last one, to see if it's any of them causing the problem.
jeremy33
15th May 2015, 16:50
Ok I tried and it is these 2 lines that cause the problem :
clip = c.fmtc.resample(clip, kernel="spline36", sy=-0.5, planes=[2, 3, 3])
clip = c.fmtc.resample(clip, kernel="spline36", sx=-0.5, sy=-0.5)
If I remove it, it work. If I only remove sy=-0.5 and sx=-0.5, sy=-0.5 it work to.
jackoneill
15th May 2015, 16:58
Ok I tried and it is these 2 lines that cause the problem :
clip = c.fmtc.resample(clip, kernel="spline36", sy=-0.5, planes=[2, 3, 3])
clip = c.fmtc.resample(clip, kernel="spline36", sx=-0.5, sy=-0.5)
If I remove it, it work. If I only remove sy=-0.5 and sx=-0.5, sy=-0.5 it work to.
Excellent. It appears the bug is in fmtconv, not nnedi3. Please complain here: http://forum.doom9.org/showthread.php?t=166504&page=6
jeremy33
15th May 2015, 17:01
Ok thanks ;)
jackoneill
28th May 2015, 12:15
NNEDI3 now has NEON optimisations!
I was curious about NEON (and somewhat bored), so I translated the "hottest" SSE2 functions into NEON intrinsics. Testing on an ODROID-U2 shows that it is ~3.6 times faster with 8 bit input and default parameters, and ~2.1 times faster with 16 bit input and default parameters, compared to plain C code.
captainadamo
28th May 2015, 18:58
Cool. Did you have a specific script you were using for benchmarking? I'm curious to see what profiling it on my Air 2 looks like. Also there might be some ARMv8 instructions that can even be used to speed some stuff up even more. Such as the intrinsics for SADDLV/UADDLV in AArch64 which allows you to sum up all the values across the vector in a single instruction which I noticed provided a decent performance gain over having to do it the ARMv7 way.
jackoneill
28th May 2015, 19:35
Cool. Did you have a specific script you were using for benchmarking? I'm curious to see what profiling it on my Air 2 looks like. Also there might be some ARMv8 instructions that can even be used to speed some stuff up even more. Such as the intrinsics for SADDLV/UADDLV in AArch64 which allows you to sum up all the values across the vector in a single instruction which I noticed provided a decent performance gain over having to do it the ARMv7 way.
No particular script, just pass opt=False when you need to disable the new code.
Did you try to use these ARMv8 instructions in nnedi3?
captainadamo
28th May 2015, 19:48
No particular script, just pass opt=False when you need to disable the new code.
Ok.
Did you try to use these ARMv8 instructions in nnedi3?
Not yet, pulling down your latest code now and will see what benefit I can get.
feisty2
11th June 2015, 16:23
so most internal functions work at float point according to the previous posts
any chance to make nnedi3 work at single float point precision also?
jackoneill
11th June 2015, 20:45
so most internal functions work at float point according to the previous posts
any chance to make nnedi3 work at single float point precision also?
There is a pretty good chance.
feisty2
12th June 2015, 07:01
There is a pretty good chance.
okay... gonna happen anytime soon?
jackoneill
12th June 2015, 11:32
okay... gonna happen anytime soon?
I don't know. I'm working on something else at the moment. How urgent is it? :wink wink:
feisty2
12th June 2015, 15:41
I don't know. I'm working on something else at the moment. How urgent is it? :wink wink:
take your time please, but sooner the better. :)
feisty2
24th June 2015, 07:49
I was float-izing nnedi3 and got into trouble and it got me weird and corrupted results
my guess, I did something wrong to "extract_m8_C" and I actually modified it like this
http://i.imgur.com/VtS2gd4.png
http://i.imgur.com/D1rlcqH.png
some tips to fix things plz?
jackoneill
24th June 2015, 11:21
Instead of screenshots of the code, please post the relevant part(s) from the output of "git diff". Actually, just commit the changes you have now and push them to your fork. I'll look at them there.
Also, screenshots from the source and from the corrupted output may help.
feisty2
24th June 2015, 14:00
I stripped lots of stuff like asm, 8bits support, nnedi3_rpow2 and other irrelevant things down to trace the problem
stripped working version (remains support for 16bits only) https://github.com/IFeelBloated/nnedi3float/blob/master/working.cpp
broken float point version (with compares to the stripped working version) https://github.com/IFeelBloated/nnedi3float/commit/5a52880df627c9aff5bb55134578e3d72f43de72
screenshots
source
http://i.imgur.com/I7PnWle.png
import vapoursynth as vs
core = vs.get_core()
clp = core.raws.Source ("Y.rgb",736,480,src_fmt="GRAYS")
clp = core.nnedi3.nnedi3 (clp,0,True)
clp.set_output ()
http://i.imgur.com/Mmr5YBI.png
edit: I just found an error minutes ago at line 213, corrected, I'll test it again and report back
feisty2
24th June 2015, 15:04
okay, still no luck with line213 corrected, now, that scan line kinda crap is gone, but things work really fast, even faster than the original version with asm opt, that gotta be wrong, so I turned pscrn to 0, and "scan line" came back instantly, that shows the "edi" interpolation is not working at all, it's just plain bicubic interpolation, I'm 80% sure problem comes from "extract_m8_C"
cretindesalpes
24th June 2015, 16:35
I just had a quick glance at the code, but are you sure the ranges of the mstd[] values are correct, or correctly scaled? They feed some non-linear stuff using exp, if the values are not in the expected range, you’ll run into massive overflows or null results. Checking the differences between 8- and 16-bit code may help.
feisty2
24th June 2015, 17:04
not sure... I'm done with direct methods, I'll turn float values to uint16_t within extract_m8_C to get correct mstd values
feisty2
24th June 2015, 17:45
okay, I did those 2 100.f changes, chroma clamping can wait for now, and it's not working
I tried to convert float to uint16_t within extract_m8_C to get correct mstd values
https://github.com/IFeelBloated/nnedi3float/commit/d9ebc0c2b98d08a6053d59578c89f877ef219a7f
not working still, anyways, I'm going out cuz it's like around 10AM, I'll get back to this when I get home
feisty2
25th June 2015, 13:53
still can't get it to work, I did another even more aggressive strip-down (removed pscrn and fapprox) to trace errors
"computeNetwork0", prescreener, removed
"processLine0", bicubic, removed
"elliott_C", prescreener helper, removed
"pixel2float48_C", prescreener helper, removed
"e0_m16_C", fapprox, removed
"e1_m16_C", fapprox, removed
now it's just the pure and raw actual "nnedi" core, all irrelevant stuff (opt... whatever) got kicked out
lite 16bits version (working) https://github.com/IFeelBloated/nnedi3float/blob/master/NNEDI3int16.cpp
lite 8bits version (working, with compares to 16bits version) https://github.com/IFeelBloated/nnedi3float/commit/fea017531c691da63db2c348b41034a9c439b381
lite float version (not working, with compares to 16bits version) https://github.com/IFeelBloated/nnedi3float/commit/e1d470a3968c1da95ba60fbed302e4185ec50886
@cretindesalpes, why that range stuff affects no shit to 8bits version, I modified that float version just like the 8bits one, but it just gives me shit
ah, everything I'm trying, fails
I'm freaking exhausted... :(
feisty2
20th August 2015, 05:46
yeah... I'm still on the mission of floatizing nnedi3
and yet I noticed "evalFunc_0" is the troubled stuff here
it should insert a white blank line between every row of the source clip cuz I removed "pscrn", and instead of that, it actually inserts black blank lines (= evalFunc_1, the actual nnedi3 is disabled)
template <typename PixelType>
void evalFunc_0(void **instanceData, FrameData *frameData)
{
ntestData *d = (ntestData*)* instanceData;
float *input = frameData->input;
const float *weights0 = d->weights0;
float *temp = frameData->temp;
uint8_t *tempu = (uint8_t*)temp;
// And now the actual work.
for (int b = 0; b < d->vi.format->numPlanes; ++b)
{
if ((b == 0 && !d->Y) ||
(b == 1 && !d->U) ||
(b == 2 && !d->V))
continue;
const PixelType *srcp = (const PixelType *)frameData->paddedp;
const int src_stride = frameData->padded_stride[b] / sizeof(PixelType);
const int width = frameData->padded_width[b];
const int height = frameData->padded_height[b];
PixelType *dstp = (PixelType *)frameData->dstp[b];
const int dst_stride = frameData->dst_stride[b] / sizeof(PixelType);
for (int y = 1 - frameData->field[b]; y < height - 12; y += 2) {
memcpy(dstp + y*dst_stride,
srcp + 32 + (6 + y)*src_stride,
(width - 64) * sizeof(PixelType));
}
const int ystart = 6 + frameData->field[b];
const int ystop = height - 6;
srcp += ystart*src_stride;
dstp += (ystart - 6)*dst_stride - 32;
const PixelType *src3p = srcp - src_stride * 3;
int32_t *lcount = frameData->lcount[b] - 6;
for (int y = ystart; y<ystop; y += 2)
{
[B]memset(dstp + 32, 255, (width - 64) * sizeof(PixelType));
lcount[y] += width - 64;
dstp += dst_stride * 2;
}
}
}
guess the "memset" stuff is just wrong for floats, 1.f is not FFFFFFFF obviously...
so how should I make it work?
EDIT:
so I removed the "pscrn" switch in evalFunc_1
template <typename PixelType>
void evalFunc_1(void **instanceData, FrameData *frameData)
{
ntestData *d = (ntestData*)* instanceData;
float *input = frameData->input;
float *temp = frameData->temp;
float **weights1 = d->weights1;
const int qual = d->qual;
const int asize = d->asize;
const int nns = d->nns;
const int xdia = d->xdia;
const int xdiad2m1 = (xdia / 2) - 1;
const int ydia = d->ydia;
const float scale = 1.0f / (float)qual;
for (int b = 0; b < d->vi.format->numPlanes; ++b)
{
if ((b == 0 && !d->Y) ||
(b == 1 && !d->U) ||
(b == 2 && !d->V))
continue;
const PixelType *srcp = (const PixelType *)frameData->paddedp;
const int src_stride = frameData->padded_stride[b] / sizeof(PixelType);
const int width = frameData->padded_width[b];
const int height = frameData->padded_height[b];
PixelType *dstp = (PixelType *)frameData->dstp[b];
const int dst_stride = frameData->dst_stride[b] / sizeof(PixelType);
const int ystart = frameData->field[b];
const int ystop = height - 12;
srcp += (ystart + 6)*src_stride;
dstp += ystart*dst_stride - 32;
const PixelType *srcpp = srcp - (ydia - 1)*src_stride - xdiad2m1;
for (int y = ystart; y<ystop; y += 2)
{
for (int x = 32; x<width - 32; ++x)
{
[B] //if (dstp[x] != 1.f)
//continue;
float mstd[4];
d->extract((const uint8_t *)(srcpp + x), src_stride, xdia, ydia, mstd, input);
for (int i = 0; i<qual; ++i)
{
d->dotProd(input, weights1[i], temp, nns * 2, asize, mstd + 2);
d->expfunc(temp, nns);
d->wae5(temp, nns, mstd);
}
dstp[x] = VSMIN(VSMAX((mstd[3] * scale), 0.f), 1.f);
}
srcpp += src_stride * 2;
dstp += dst_stride * 2;
}
}
}
now I got a working floating point nnedi3, nice!
more details at https://github.com/IFeelBloated/nnedi3float/blob/master/nnedi3sp.cpp
but I lose the compatibility of pscrn by doing that and it works reeaally slow
I want pscrn back later so I want an answer to that memset problem :)
jackoneill
20th August 2015, 08:30
If you're using the highlighted memset line, it's not setting the pixels to 1.0f, but to 0xffffffff, which apparently is NaN (not a number). You'll want to use vs_memset_float to actually set them to 1.0f: https://github.com/vapoursynth/vapoursynth/blob/master/src/core/filtershared.h#L46
foxyshadis
20th August 2015, 11:19
1.f is 0x3f800000, btw. If you're going to hack around with bytes like that you should use a hack like *(int*)(dstp+x) to read it back. (Or define a union.) But yeah, vs_memset_float already does what you want.
feisty2
20th August 2015, 15:02
works, thx for all your help :)
feisty2
21st August 2015, 06:13
G, nnedi3 without asm works outrageously slow, I decide to bring SSE2 "machine code" (like, technically) back to those untouched functions (computeNetwork0, weightedAvgElliottMul5_m16, e0_m16, e1_m16, e2_m16, dotProd)
now I got these:
https://github.com/IFeelBloated/NNEDI3SF/blob/master/NNEDI3SFSSE2.cpp
https://github.com/IFeelBloated/NNEDI3SF/blob/master/nnedi3.asm
https://github.com/IFeelBloated/NNEDI3SF/blob/master/x86inc.asm
but how can I connect them all together, tried lots of things in MSVC and all failed...
jackoneill
21st August 2015, 11:33
Can't you just incorporate your changes into nnedi3, without removing anything?
feisty2
21st August 2015, 12:00
Can't you just incorporate your changes into nnedi3, without removing anything?
wish I could, but.. I just don't have that much programming skill to do that, I'll simply strip the filter down piece by piece till the core function is the only thing left, then I'll modify it as how I want it to work and fix errors till it actually works..
it's sort of hard to get those removed back and make sure they will be okay along with the modified functions :(
feisty2
21st August 2015, 13:25
well, I couldn't get your asm file to work but this (https://github.com/jpsdr/NNEDI3/blob/master/nnedi3/nnedi3_asm_x64.asm) works perfectly...
so I did a (partial) SSE2 opt
jackoneill
8th September 2015, 11:29
v6 is here. (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v6)
* Normalise the frame rate when doubling it.
* Add support for 32 bit floating point images.
* Deprecate the 'Y', 'U', and 'V' parameters in favour of the standard 'planes' parameter.
* Only allocate temporary buffers for the planes that are actually processed.
* Remove the nnedi3_rpow2 filter.
And a change that affects only (some) users of ARM CPUs:
* Add NEON intrinsics (translated from the x86 ASM). They make it go fast(er).
feisty2: Thanks for finding all the places in the code that needed changes to support floats. It made my job easier, even if I didn't use any of your code.
The Y, U, and V parameters still work, so your existing scripts won't break, but please don't use them in new scripts.
I removed nnedi3_rpow2 because it really should be a Python script, rather than a filter. And also to make it someone else's problem.
feisty2
8th September 2015, 11:46
wow! cool, I can throw away my rough idea nnedi3 to the trash can now,will you add floats to mvtools too or should I keep my own floating point mvtools?
jackoneill
8th September 2015, 12:56
will you add floats to mvtools too or should I keep my own floating point mvtools?
MVTools is much more awful, so no.
feisty2
8th September 2015, 13:05
http://i.imgur.com/5Xmeovw.png
import vapoursynth as vs
core = vs.get_core()
clp = xxx
clp = core.fmtc.bitdepth(clp, fulls=False, fulld=True, bits=32)
clp = core.std.ShufflePlanes(clp, planes=0, colorfamily=vs.GRAY)
clp = core.nnedi3.nnedi3(clp, 0, True)
clp.set_output ()
okay, I just replaced all "YUV" stuff with "planes"
but this new version is... somehow buggy
it gives me things like that image above at both uint16_t and float
jackoneill
8th September 2015, 21:42
v7 fixes everything. (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v7)
Khanattila
11th September 2015, 08:51
v7 fixes everything. (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v7)
Good job. I still can not understand the algorithm of nnnedi3. :D
jackoneill
27th January 2016, 19:36
v8 is here (https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v8). It was here a few days ago already, but I forgot to post this.
* Fix crash with more than 8 but less than 16 bits per sample (bug introduced in v6).
Anybody want to try a semi-portable binary for 64 bit Linux? It should require only Glibc 2.14 or newer. Or, I guess, other libc implementations that pretend to be glibc. You'll probably get some error message about symbols if yours is too old/incompatible.
Muxketeer
24th February 2016, 19:55
Sorry to be "that person," but with nnedi3_rpow2 being removed from the plugin, how do we use the python version to increase resolution? I see a python version here http://forum.doom9.org/showthread.php?p=1722246#post1722246, but that doesn't seem to offer a way to increase , both, the width and height.
Is there a already written python version nnedi3_rpow2 ? How can the one at http://forum.doom9.org/showthread.php?p=1722246#post172224 be modified to match nnedi3_rpow2's capabilities?
Are_
24th February 2016, 20:05
http://forum.doom9.org/showthread.php?t=172652
Muxketeer
24th February 2016, 20:25
http://forum.doom9.org/showthread.php?t=172652
Perfect, thanks!
asarian
5th April 2016, 14:17
So, what's the deal with nnedi3_weights.bin?! Seems the only source is just a Makefile. I put it in my plugins64 directory nonetheless, but got:
vapoursynth.Error: nnedi3: 'C:/Program Files (x86)/VapourSynth/plugins64/nnedi3_weights.bin' has the wrong size. Expected 13574928 bytes, got 862 bytes.
jackoneill
5th April 2016, 16:50
So, what's the deal with nnedi3_weights.bin?! Seems the only source is just a Makefile. I put it in my plugins64 directory nonetheless, but got:
vapoursynth.Error: nnedi3: 'C:/Program Files (x86)/VapourSynth/plugins64/nnedi3_weights.bin' has the wrong size. Expected 13574928 bytes, got 862 bytes.
If you downloaded the DLL, you must have seen the link to nnedi3_weights.bin. It's right there between the list of changes and the download links for the DLLs.
asarian
5th April 2016, 18:52
If you downloaded the DLL, you must have seen the link to nnedi3_weights.bin. It's right there between the list of changes and the download links for the DLLs.
No, I don't see it. :) Or, rather, I'm seeing a link to a Make.am source file, at:
https://github.com/dubhater/vapoursynth-nnedi3/blob/v6/src/nnedi3_weights.bin
My knowledge doesn't extend far enough (on Windows) on how to compile this into a new, 64-bit dll.
EDIT: Nevermind, LOL, I found it in the zip file! :)
AzraelNewtype
5th April 2016, 21:54
No, I don't see it. :) Or, rather, I'm seeing a link to a Make.am source file, at:
https://github.com/dubhater/vapoursynth-nnedi3/blob/v6/src/nnedi3_weights.bin
My knowledge doesn't extend far enough (on Windows) on how to compile this into a new, 64-bit dll.
EDIT: Nevermind, LOL, I found it in the zip file! :)
It's good that you found it in the source zip I suppose, but I mean...
http://i.imgur.com/IKbHv0P.png
his instructions on where to find it were not exactly unclear. Or wrong.
asarian
5th April 2016, 22:11
Silly me, it was in the RAW file all the time. ;P I kept clicking on the filename itself, which is just a text file. :)
feisty2
9th April 2016, 15:40
I think the floating point support needs some correcting, and I made a pr on github
Pulp Catalyst
12th May 2016, 08:03
i'm trying to incorporate a yadifmod + NNEDI3 into staxrip,
but i don't know VS, could some one just post a simple example of what the script would look like.
i want yadifmod + nnedi3 but double framerate (50fps) so to avoid the jerky (stutter) effect.
i have looked through all the posts, but havent found a combination of yadifmod and nnedi3 together.
Thanks,
foxyshadis
12th May 2016, 18:15
That would be something like:
yadifmod.Yadifmod(yourvid, edeint=nnedi3.nnedi3(yourvid), mode=1)
If it's not working right, then your source isn't setting _FieldBased correctly, and you'll have to preface that with:
core.std.SetFrameProp(yourvid, prop="_FieldBased", intval=X) where X is 1 for bff and 2 for tff.
Pulp Catalyst
14th May 2016, 13:39
thankyou foxy, much appreciated.
jackoneill
23rd August 2016, 17:49
https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v9
* Float pixels are no longer clamped to the usual ranges of [0.0, 1.0]/[-0.5, 0.5].
* Fix a crash in OS X and possibly 64 bit Linux.
* Fix a bug in the NEON intrinsics.
* Always set the _FieldBased frame property to progressive.
* Ignore the _FieldBased frame property when "dh" is True and use the _Field property instead.
* Remove the deprecated parameters "Y", "U", and "V".
* Replace the bitfield parameter "fapprox" with the parameters "int16_prescreener", "int16_predictor", and "exp".
The fapprox parameter was too annoying to use.
hydra3333
24th August 2016, 14:39
x64, replaced nnedi3 v8 with the new nnedi3 v9 and received this error:
"C:\SOFTWARE\Vapoursynth-x64\VSPipe.exe" "T:\HDTV\WDTVlive\MP4-VS\x64-1\test.mpg.2016.08.24.22.56.27.68.vpy" - --y4m | "C:\SOFTWARE\ffmpeg\0-homebuilt-x64\x264-mp4.exe" - --stdin y4m --thread-input --frames 45810 --profile high --level 4.1 --preset slow --interlaced --tff --no-cabac --crf 16 --sar 64:45 --colormatrix bt470bg -o "s:\HDTV\WDTVlive\MP4-VS\x64-1\test-temp.2016.08.24.22.56.27.68.h264"
Script evaluation failed:
Python exception: nnedi3: Function does not take argument(s) named U, V
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1491, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:26905)
File "T:\HDTV\WDTVlive\MP4-VS\x64-1\test.mpg.2016.08.24.22.56.27.68.vpy", line 496, in <module>
main()
File "T:\HDTV\WDTVlive\MP4-VS\x64-1\test.mpg.2016.08.24.22.56.27.68.vpy", line 122, in main
video = haf.QTGMC(video, TFF=True, Preset="Very Slow", Sharpness=1.2, SLMode=2, EZKeepGrain=1.2, NoiseProcess=2) # result is double framerate progressive, so re-interlate it later
File "C:\SOFTWARE\Vapoursynth-x64\havsfuncTS.py", line 1130, in QTGMC
edi1 = QTGMC_Interpolate(ediInput, InputType, EdiMode, NNSize, NNeurons, EdiQual, EdiMaxD, bobbed, ChromaEdi, TFF)
File "C:\SOFTWARE\Vapoursynth-x64\havsfuncTS.py", line 1411, in QTGMC_Interpolate
interp = core.nnedi3.nnedi3(Input, field=field, U=CEed, V=CEed, nsize=NNSize, nns=NNeurons, qual=EdiQual)
File "src\cython\vapoursynth.pyx", line 1356, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:24822)
vapoursynth.Error: nnedi3: Function does not take argument(s) named U, V
x64, reinstated nnedi3 v8 and received this error which I expected since it was a test script under development:
"C:\SOFTWARE\Vapoursynth-x64\VSPipe.exe" "T:\HDTV\WDTVlive\MP4-VS\x64-1\test.mpg.2016.08.24.22.59.13.71.vpy" - --y4m | "C:\SOFTWARE\ffmpeg\0-homebuilt-x64\x264-mp4.exe" - --stdin y4m --thread-input --frames 45810 --profile high --level 4.1 --preset slow --interlaced --tff --no-cabac --crf 16 --sar 64:45 --colormatrix bt470bg -o "s:\HDTV\WDTVlive\MP4-VS\x64-1\test-temp.2016.08.24.22.59.13.71.h264"
Script evaluation failed:
Python exception: bitdepth: you cannot specify both a colorspace and a pixel format.
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1491, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:26905)
File "T:\HDTV\WDTVlive\MP4-VS\x64-1\test.mpg.2016.08.24.22.59.13.71.vpy", line 496, in <module>
main()
File "T:\HDTV\WDTVlive\MP4-VS\x64-1\test.mpg.2016.08.24.22.59.13.71.vpy", line 143, in main
video = core.fmtc.bitdepth(video, csp=vs.FLOAT, bits=32, flt=1) #convert to 32bit float
File "src\cython\vapoursynth.pyx", line 1383, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:25212)
vapoursynth.Error: bitdepth: you cannot specify both a colorspace and a pixel format.
This seems to indicate nnedi3 v9 is not backward compatible with v8 and thus breaks QTGMC per the statement Remove the deprecated parameters "Y", "U", and "V". For the time being I'll need to stick with v8 until havsfunc is updated ...
Script:
# preliminary stuff
video = haf.QTGMC(video, TFF=True, Preset="Very Slow", Sharpness=1.2, SLMode=2, EZKeepGrain=1.2, NoiseProcess=2) # result is double framerate progressive, so re-interlate it later
# Vine only accepts 32bit float input
video = core.fmtc.bitdepth(video, csp=vs.FLOAT, bits=32, flt=1) #convert to 32bit float
video = Vine.Dehalo(video, radius=[2, None])
video = core.fmtc.bitdepth(video, csp=vs.INTEGER, bits=8, flt=0) #convert to 8 bit integer
# other stuff
jackoneill
27th August 2016, 14:16
Oops, v9 has a bug that makes it process 16 bit and float input with just the cubic interpolation.
https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v10
Sm3n
24th September 2016, 15:28
Thank you for your work!
ShogoXT
11th November 2016, 09:00
Hi all!
Noob here been learning vapoursynth through Staxrip.
I thought I was doing things wrong adding in nnedi3 for resizing, which needed the nnedi3_rpow2 linked in the OP.
I tried to use it, but kept getting fapprox errors. I noticed that setting is gone in v8 and rpow2 hasnt been updated in 10 months. I probably will try the older version for now, but I guess it wont work til adjusted?
Thanks for your hard work!
EDIT: Nvm, Staxrip doesnt allow me to use the non v10 version of nnedi3, so I guess im stuck.
jackoneill
11th November 2016, 19:33
Hi all!
Noob here been learning vapoursynth through Staxrip.
I thought I was doing things wrong adding in nnedi3 for resizing, which needed the nnedi3_rpow2 linked in the OP.
I tried to use it, but kept getting fapprox errors. I noticed that setting is gone in v8 and rpow2 hasnt been updated in 10 months. I probably will try the older version for now, but I guess it wont work til adjusted?
Thanks for your hard work!
EDIT: Nvm, Staxrip doesnt allow me to use the non v10 version of nnedi3, so I guess im stuck.
nnedi3_rpow2 doesn't really do anything with the fapprox parameter, so just delete it.
jackoneill
19th January 2017, 15:17
https://github.com/dubhater/vapoursynth-nnedi3/releases/tag/v11
* Allow the use of the int16 prescreeners with 9..16 bit input. This
means the faster "new" prescreener (pscrn=2..4) can be used and so
9..16 bit input is processed faster with default parameters.
* Allow the use of the int16 predictor with 9..15 bit input. This
means 9..15 bit input is processed faster (theoretically) with
default parameters.
* Fix memory leak when nnedi3_weights.bin is missing or has the
wrong size (bug introduced in v3).
* readme.rst finally explains what all the parameters are.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.