New filter: Fix Telecined Fades

[sl1pkn07]

unfortunately, I don't know how to "if detect, compile it"...


something like:


#ifdef VAPOURSYNTH_H
static void VS_CC VapourSynthPluginViInit(VSMap *in, VSMap *out, void **instanceData, VSNode *node, VSCore *core,
const VSAPI *vsapi) {

NLMVapoursynth *d = (NLMVapoursynth*) * instanceData;
vsapi->setVideoInfo(d->vi, 1, node);
}
#endif //__VAPOURSYNTH_H__


(taken from knlmeans code)

but with CPU capabilities

EDIT: better example
EDIT: that is called conditionals? (sorry, im not coder, idk what is a real name of this)

[feisty2]

something like:


#ifdef VAPOURSYNTH_H
static void VS_CC VapourSynthPluginViInit(VSMap *in, VSMap *out, void **instanceData, VSNode *node, VSCore *core,
const VSAPI *vsapi) {

NLMVapoursynth *d = (NLMVapoursynth*) * instanceData;
vsapi->setVideoInfo(d->vi, 1, node);
}
#endif //__VAPOURSYNTH_H__


(taked from knlmeans code)

but with CPU capabilities

EDIT: better example
EDIT: that is called conditionals? (sorry, im not coder, idk what is a real name of this)

The past tense of "take" is "took", perfect tense "taken" :p
Anyways, it's called conditional compilation and I know how to do it theoretically but still can't do it, because it involves whole lot of compiler-specific macros that are not part of the C++ standard...

And since your compilation worked, I assume you figured out how to get yasm to work?
And does the compiled binary run correctly? (Checking if the "opt" parameter actually works)

[sl1pkn07]

about yasm

something like this?


diff --git a/Source.cpp b/Source.cpp
index 5409d6e..3dbd174 100644
--- a/Source.cpp
+++ b/Source.cpp
@@ -1,12 +1,13 @@
-#include "VapourSynth.h"
-#include "VSHelper.h"
-#include "cpufeatures.hpp"
+#include <VapourSynth.h>
+#include <VSHelper.h>
#include <cmath>
#include <cstring>
#include <algorithm>
#include <immintrin.h>
#include <malloc.h>

+extern "C++" int CPUFeatures();
+
struct FixFadesData final {
const VSAPI *vsapi = nullptr;
VSNodeRef *node = nullptr;


(you can avoid the first change)

but i get https://sl1pkn07.wtf/paste/view/f32ca689

(takEN (XD) from https://github.com/vapoursynth/vapoursynth/blob/f65402b242b1eac05de1e485306ea1466d54541e/src/core/x86utils.h (with this help http://wiki.osdev.org/C%2B%2B_to_ASM_linkage_in_GCC)

about of test, give me time

[feisty2]

Include "cpufeatures_gnu.hpp" and remove that "extern "C++" int CPUFeatures();" thing

[sl1pkn07]

em, is the same as i tried before (only work with -march=haswell)(?)

or you mean convert the cpu.asm to object with yasm* and include it in the linker step?

*

yasm -f elf -m ${_m} -DARCH_X86_64=${_darch} -o cpu.o cpu.asm


can you share a clip/video sample? or how doing it with blankclip()

[JoeyMonco]

Anyways, it's called conditional compilation and I know how to do it theoretically but still can't do it, because it involves whole lot of compiler-specific macros that are not part of the C++ standard...

But compiler-specific cpuid functions are part of standard? Since when?

[Myrsloik]

Now you see why asm is kinda your friend.

There's a pile of pitfalls here you missed. And some you found.

1. You compile the whole file with avx2/whatever instrction set you selected. That means avx2 instructions may be emitted for you plain C++ code too. Solve it by placing the avx2 code in a separate file and use different compiler settings.

2. You can't put sse and avx intrinsics in the same file either. For example subps can get turned into vsubps to reduce register copies. So then the sse path needs avx too...

3. Cpuid is horrible in intrinsics, that's why I use asm. Lrn2yasm. Or write code that requires gcc or clang where convenient intrinsics are available. Clang is even available as a simple dropin for visual studio nowadays.

[Mystery Keeper]

Why do conditional compilation at all when you can compile function for every instruction set and use CPU information to select the proper function in runtime?

[feisty2]

or you mean convert the cpu.asm to object with yasm* and include it in the linker step?
yeah


can you share a clip/video sample? or how doing it with blankclip()
blankclip is okay, long as it's not crashing.

But compiler-specific cpuid functions are part of standard? Since when?
no they are not, but I can google this individual function and learn to use it, I can't however google thousands of compiler-specific macros and memorize them all.

[JoeyMonco]

yeah


blankclip is okay, long as it's not crashing.


no they are not, but I can google this individual function and learn to use it, I can't however google thousands of compiler-specific macros and memorize them all.

Thousands? Uhh no. There is __GNUC__ and __clang__ and _MSC_VER_.

http://stackoverflow.com/questions/28166565/detect-gcc-as-opposed-to-msvc-clang-with-macro

That was the first link in googling "how to detect gcc vs msvc"

[feisty2]

Now you see why asm is kinda your friend.

There's a pile of pitfalls here you missed. And some you found.

1. You compile the whole file with avx2/whatever instrction set you selected. That means avx2 instructions may be emitted for you plain C++ code too. Solve it by placing the avx2 code in a separate file and use different compiler settings.

2. You can't put sse and avx intrinsics in the same file either. For example subps can get turned into vsubps to reduce register copies. So then the sse path needs avx too...

3. Cpuid is horrible in intrinsics, that's why I use asm. Lrn2yasm. Or write code that requires gcc or clang where convenient intrinsics are available. Clang is even available as a simple dropin for visual studio nowadays.

1. got it
2. got it
3. the thing is I can't set it up... yasm doesn't seem to have an installer like clang that gets everything done automatically, also the manual setting-up documentation on the yasm website is obsolete, the visual studio folders it mentioned don't even exist anymore! I could switch to clang but that won't solve the xgetbv problem cuz it's not defined in clang's immintrin.h... and back to square one, I have to set up yasm first which is impossible.:(

[sl1pkn07]

yeah


blankclip is okay, long as it's not crashing.


Ok, but how? Xd

[feisty2]

Ok, but how? Xd

I separated the source code into 2 files.
just compile "Source.cpp" with "-march=native" and "Source_AVX_FMA.cpp" with "-march=haswell" and it should work, you don't have to edit the source code this time, I added the conditional compilation macros and it would pick "cpufeatures_gnu.hpp" automatically if you're on GCC

test script

import vapoursynth as vs
core = vs.get_core()
clp = core.std.BlankClip(width=1920, height=1080, format=vs.GRAYS, length=20000)
clp = core.ftf.FixFades(clp)
clp.set_output()

[sl1pkn07]

http://stackoverflow.com/questions/6121792/how-to-check-if-a-cpu-supports-the-sse3-instruction-set

if help you

[feisty2]

http://stackoverflow.com/questions/6121792/how-to-check-if-a-cpu-supports-the-sse3-instruction-set

if help you

I know how to do that SIMD extension detecting at runtime and it's already there in the source code, I don't need any help

I'm asking if it's working cuz I'm not sure about that..

[sl1pkn07]

Failed to evaluate the script:
Python exception: No attribute with the name ftf exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "src/cython/vapoursynth.pyx", line 1712, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:34991)
File "/home/sl1pkn07/aplicaciones/vapoursynth-test/fixtelecided-test.vpy", line 4, in
clp = core.ftf.FixFades(clp)
File "src/cython/vapoursynth.pyx", line 1306, in vapoursynth.Core.__getattr__ (src/cython/vapoursynth.c:28067)
AttributeError: No attribute with the name ftf exists. Did you mistype a plugin namespace?



all:
g++ -c -std=c++14 -fPIC -march=native -O2 -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I. -I/usr/include/vapoursynth -o fixtelecinedfades.o Source.cpp
yasm -f elf -m amd64 -DARCH_X86_64=1 -o cpu.o cpu.asm
g++ -shared -fPIC -Wl,-O1,--sort-common,--as-needed,-z,relro -o libvsfixtelecinedfades.so fixtelecinedfades.o cpu.o

[feisty2]

Failed to evaluate the script:
Python exception: No attribute with the name ftf exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "src/cython/vapoursynth.pyx", line 1712, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:34991)
File "/home/sl1pkn07/aplicaciones/vapoursynth-test/fixtelecided-test.vpy", line 4, in
clp = core.ftf.FixFades(clp)
File "src/cython/vapoursynth.pyx", line 1306, in vapoursynth.Core.__getattr__ (src/cython/vapoursynth.c:28067)
AttributeError: No attribute with the name ftf exists. Did you mistype a plugin namespace?



all:
g++ -c -std=c++14 -fPIC -march=native -O2 -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I. -I/usr/include/vapoursynth -o fixtelecinedfades.o Source.cpp
yasm -f elf -m amd64 -DARCH_X86_64=1 -o cpu.o cpu.asm
g++ -shared -fPIC -Wl,-O1,--sort-common,--as-needed,-z,relro -o libvsfixtelecinedfades.so fixtelecinedfades.o cpu.o


then I think I won't be able to help you with that... sorry
I'm really just not familiar with all that gnu stuff and

1. there's the runtime simd extension detection so the unsupported forcibly-compiled functions won't matter cuz they will never get called.
2. you compiled "Source.cpp" which contains functions that will actually get called with "-march=native", so there should be no unsupported instructions in those functions.

so logically I can't see why your binary failed to work, maybe you should ask others that are more familiar with the whole gnu world..

[feisty2]

anyways, if you really wanna use this plugin,
manually comment out:
line3
line123
line124
line156 - line161
in "Source.cpp",
line10 - line14 in "Shared.hpp"
and compile it and it should work..

[jackoneill]

Python exception: No attribute with the name _____ exists. Did you mistype a plugin namespace?

If you get this error and you know you have the plugin, try to load it manually to find out what's wrong with it:

core.std.LoadPlugin("/your/plugin/here.so")

[sl1pkn07]

@jackoneill the steps for build the plugin whit yasm is correct?

edit:


Failed to evaluate the script:
Python exception: Failed to load /usr/lib/vapoursynth/libvsfixtelecinedfades.so. Error given: /usr/lib/vapoursynth/libvsfixtelecinedfades.so: undefined symbol: _Z24fixfadesGetFrame_AVX_FMAiiPPvS0_P14VSFrameContextP6VSCorePK5VSAPI
Traceback (most recent call last):
File "src/cython/vapoursynth.pyx", line 1712, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:34991)
File "/home/sl1pkn07/aplicaciones/vapoursynth-plugin-fixtelecinedfades-git/fixtelecined-test.vpy", line 3, in
clp = core.std.BlankClip(width=1920, height=1080, format=vs.GRAYS, length=20000)
File "src/cython/vapoursynth.pyx", line 1604, in vapoursynth.Function.__call__ (src/cython/vapoursynth.c:33131)
vapoursynth.Error: Failed to load /usr/lib/vapoursynth/libvsfixtelecinedfades.so. Error given: /usr/lib/vapoursynth/libvsfixtelecinedfades.so: undefined symbol: _Z24fixfadesGetFrame_AVX_FMAiiPPvS0_P14VSFrameContextP6VSCorePK5VSAPI

[jackoneill]

Gah, you made me look at the code.

You forgot to compile Source_AVX_FMA.cpp.

[sl1pkn07]

but that is not only for AVX CPU compilant?

Source.cpp -> older CPU
Source_AVX_FMA.cpp -> newer CPU

because Source_AVX_FMA.cpp needs build with -march=haswell, amd my cpu is not capable (don't have AVX or FMA3)

[jackoneill]

but that is not only for AVX CPU compilant?

Source.cpp -> older CPU
Source_AVX_FMA.cpp -> newer CPU

because Source_AVX_FMA.cpp needs build with -march=haswell, amd my cpu is not capable (don't have AVX or FMA3)

If the author did everything right, the code from that file will only be used if the CPU has FMA3. You still have to compile it.

[sl1pkn07]

ok. done

[feisty2]

ok. done

is it working now?

[sl1pkn07]

i think yes, but i need make more test

if all is ok, then i think you can merge the Source{,_AVX_FMA}.cpp again

sorry :S

[feisty2]

i think yes, but i need make more test

if all is ok, then i think you can merge the Source{,_AVX_FMA}.cpp again

sorry :S

no, I can't(shouldn't).
if I do merge Source.cpp and Source_AVX_FMA.cpp into one file, you'll have to compile that file with -march=haswell, and the compiler will probably generate unsupported instructions for the C++ functions..

[feisty2]

i think yes, but i need make more test

if all is ok, then i think you can merge the Source{,_AVX_FMA}.cpp again

sorry :S

I think you should make a PR on GitHub so I can merge those GNU compiling files into the repo

[sl1pkn07]

Then need making more refraction in Source.cpp, because as @jackoneill said,build Source.cpp with march=native and build Source_AVX_FMA3.cpp with march=haswell and merge both in the library, the plugin now load without problem. build

[feisty2]

Then need making more refraction in Source.cpp, because build It with march=native and build source_avx_fma3.cpp with march=haswell and merge both in the library the plugin now load without problem. Like @jackoneill said

what do you mean by "more refraction in Source.cpp"?

[sl1pkn07]

because if only build Source.cpp

https://forum.doom9.org/showpost.php?p=1796109&postcount=70

and if build both source.cpp and Source_AVX_FMA3.cpp the plugin is loaded and seems work

[feisty2]

of course you should compile both files, what's the problem here?

[sl1pkn07]

again. this make conflicts if the processor don't support AVX/FMA3?

[feisty2]

again. this make conflicts if the processor don't support AVX/FMA3?

ahh, I wish I could speak Spanish so it would be less painful for us to communicate..

like I said a million times before, you MUST compile Source_AVX_FMA.cpp (even if AVX and FMA are not supported by your CPU, forcibly compile it with -march=haswell if that's the case)
and it won't matter because the AVX/FMA functions will be rejected at RUNTIME if they are not supported by your CPU.

[sl1pkn07]

then all fine

[Jindadil007]

Really Good Filter...Got very good results...Thanks Feisty2

[KingLir]

Trying to build this on macOS and getting the following error. Any ideas ?

meson-log seems ok, here is a copy. (https://mega.nz/#!B84Wja4Z!4jysdgIqJfmuh68cZRo9jSqYDFRaJlTUXZlQ9XF3ekQ)

[1/4] Compiling cpp object 'avxfma@sta/Source_AVX_FMA.cpp.o'
FAILED: avxfma@sta/Source_AVX_FMA.cpp.o
c++ '-Iavxfma@sta' '-I.' '-I..' '-I/usr/local/Cellar/vapoursynth/36/include/vapoursynth' '-I/usr/local/Cellar/zimg/2.4/include' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-std=c++14' '-O3' '-mavx' '-mfma' '-MMD' '-MQ' 'avxfma@sta/Source_AVX_FMA.cpp.o' '-MF' 'avxfma@sta/Source_AVX_FMA.cpp.o.d' -o 'avxfma@sta/Source_AVX_FMA.cpp.o' -c ../Source_AVX_FMA.cpp
In file included from ../Source_AVX_FMA.cpp:1:
../Shared.hpp:8:10: fatal error: 'malloc.h' file not found
#include <malloc.h>
^
1 error generated.
[2/4] Compiling cpp object 'fixtelecinedfades@sha/Source.cpp.o'
FAILED: fixtelecinedfades@sha/Source.cpp.o
c++ '-Ifixtelecinedfades@sha' '-I.' '-I..' '-I/usr/local/Cellar/vapoursynth/36/include/vapoursynth' '-I/usr/local/Cellar/zimg/2.4/include' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-std=c++14' '-O3' '-MMD' '-MQ' 'fixtelecinedfades@sha/Source.cpp.o' '-MF' 'fixtelecinedfades@sha/Source.cpp.o.d' -o 'fixtelecinedfades@sha/Source.cpp.o' -c ../Source.cpp
In file included from ../Source.cpp:1:
../Shared.hpp:8:10: fatal error: 'malloc.h' file not found
#include <malloc.h>
^
1 error generated.
ninja: build stopped: subcommand failed.

[feisty2]

Trying to build this on macOS and getting the following error. Any ideas ?

meson-log seems ok, here is a copy. (https://mega.nz/#!B84Wja4Z!4jysdgIqJfmuh68cZRo9jSqYDFRaJlTUXZlQ9XF3ekQ)

[1/4] Compiling cpp object 'avxfma@sta/Source_AVX_FMA.cpp.o'
FAILED: avxfma@sta/Source_AVX_FMA.cpp.o
c++ '-Iavxfma@sta' '-I.' '-I..' '-I/usr/local/Cellar/vapoursynth/36/include/vapoursynth' '-I/usr/local/Cellar/zimg/2.4/include' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-std=c++14' '-O3' '-mavx' '-mfma' '-MMD' '-MQ' 'avxfma@sta/Source_AVX_FMA.cpp.o' '-MF' 'avxfma@sta/Source_AVX_FMA.cpp.o.d' -o 'avxfma@sta/Source_AVX_FMA.cpp.o' -c ../Source_AVX_FMA.cpp
In file included from ../Source_AVX_FMA.cpp:1:
../Shared.hpp:8:10: fatal error: 'malloc.h' file not found
#include <malloc.h>
^
1 error generated.
[2/4] Compiling cpp object 'fixtelecinedfades@sha/Source.cpp.o'
FAILED: fixtelecinedfades@sha/Source.cpp.o
c++ '-Ifixtelecinedfades@sha' '-I.' '-I..' '-I/usr/local/Cellar/vapoursynth/36/include/vapoursynth' '-I/usr/local/Cellar/zimg/2.4/include' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-std=c++14' '-O3' '-MMD' '-MQ' 'fixtelecinedfades@sha/Source.cpp.o' '-MF' 'fixtelecinedfades@sha/Source.cpp.o.d' -o 'fixtelecinedfades@sha/Source.cpp.o' -c ../Source.cpp
In file included from ../Source.cpp:1:
../Shared.hpp:8:10: fatal error: 'malloc.h' file not found
#include <malloc.h>
^
1 error generated.
ninja: build stopped: subcommand failed.

the error basically tells you that a header file "malloc.h" is missing
"malloc.h" should be provided by the compiler and it's also where the dynamic stack memory allocation function "alloca()" (unlike C99 and later versions of C, variable length array in stack frame (std::vector is a heap array, which means it's much slower than alloca()) is not allowed in C++, which leaves alloca() the only option to do such thing) should be defined..

"malloc.h" should be available in Visual Studio and GCC, maybe you should try one of these 2 compilers

[jackoneill]

the error basically tells you that a header file "malloc.h" is missing
"malloc.h" should be provided by the compiler and it's also where the dynamic stack memory allocation function "alloca()" (unlike C99 and later versions of C, variable length array in stack frame (std::vector is a heap array, which means it's much slower than alloca()) is not allowed in C++, which leaves alloca() the only option to do such thing) should be defined..

"malloc.h" should be available in Visual Studio and GCC, maybe you should try one of these 2 compilers

You wouldn't need the nonstandard alloca function if you would use the plane pointers directly.

Try to include alloca.h instead of malloc.h.

[KingLir]

"malloc.h" should be available in Visual Studio and GCC, maybe you should try one of these 2 compilers

The instructions says to use meson build system - so that what I used. Anyway, it's not straightforward to just build it with Visual Studio on macOS :)

I did what jackoneill suggested and changed the line in Shared.hpp to alloca.h instead of malloc.h.

It now build successfully with just one warning:

../Source.cpp:165:23: warning: 'VapourSynthPluginInit' has C-linkage specified, but returns user-defined type 'auto' which is incompatible with C [-Wreturn-type-c-linkage]
VS_EXTERNAL_API(auto) VapourSynthPluginInit(VSConfigPlugin configFunc, VSRegisterFunction registerFunc, VSPlugin *plugin) {
^
1 warning generated.

Is this warning OK ? And are there any forseen impact (performance and etc) in using alloca instead of malloc ?

[feisty2]

You wouldn't need the nonstandard alloca function if you would use the plane pointers directly.

but alloca freed me from the misery of pointer arithmetic which is dangerous and error-prone and a very ugly style of programming imho, it also restored the image back to its physical representation (2D instead of 1D in RAM), so "alloca" is definitely a big YEEESSSS to me


Try to include alloca.h instead of malloc.h.

got it.

[feisty2]

The instruction says to use meson build system - so that what I used. Anyway, it's not straightforward to just build it with Visual Studio on macOS :)

I did what jackoneill suggested an changed the line in Shared.hpp to alloca.h instead of malloc.h.

It now build successfully with just one warning:

../Source.cpp:165:23: warning: 'VapourSynthPluginInit' has C-linkage specified, but returns user-defined type 'auto' which is incompatible with C [-Wreturn-type-c-linkage]
VS_EXTERNAL_API(auto) VapourSynthPluginInit(VSConfigPlugin configFunc, VSRegisterFunction registerFunc, VSPlugin *plugin) {
^
1 warning generated.

Is this warning OK ?

it's okay, just ignore the warning.


And are there any forseen impact (performance and etc) in using alloca instead of malloc ?

alloca() could be translated into simply 1 assembly instruction if inlined (ignoring the 16 byte alignment of rsp)

sub rsp, size

and "malloc()" is much more complicated than "alloca()" at the assembly level, so alloca() is WAY faster than malloc(), at least ~1000 times faster from my previous tests.

[KingLir]

Thank you guys! You should go and do a commit with the change.

A newbie question, what does it means " vapoursynth.Error: FixFades: input clip must be single precision fp, with constant dimensions. " ?
I am using a DVD (mpeg2) source. What conversation should I do ?

[feisty2]

core.fmtc.bitdepth(xxx, bits=32, fulls=False, fulld=True)

[KingLir]

core.fmtc.bitdepth(xxx, bits=32, fulls=False, fulld=True)

Thanks. I am getting only "pipe:: Invalid data found when processing input" for the following script:

clip = core.ffms2.Source(source.mkv)
clip = core.fmtc.bitdepth(clip=clip, bits=32, fulls=False, fulld=True)
clip = core.ftf.FixFades(clip=clip, mode=0, threshold=0.002, color=[0.0, 0.0, 0.0], opt=True)
clip.set_output()

[feisty2]

your script is correct, maybe your output program does not support 32bits precision videos (I mean even the crappy 10bits gets to be so called "high bitdepth")

[jackoneill]

but alloca freed me from the misery of pointer arithmetic which is dangerous and error-prone and a very ugly style of programming imho, it also restored the image back to its physical representation (2D instead of 1D in RAM), so "alloca" is definitely a big YEEESSSS to me


got it.

srcp[i] = reinterpret_cast<const float *>(vsapi->getReadPtr(src, plane)) + i * src_stride;
dstp[i] = reinterpret_cast<float *>(vsapi->getWritePtr(dst, plane)) + i * dst_stride;

That's pointer arithmetic right there.

[feisty2]

srcp[i] = reinterpret_cast<const float *>(vsapi->getReadPtr(src, plane)) + i * src_stride;
dstp[i] = reinterpret_cast<float *>(vsapi->getWritePtr(dst, plane)) + i * dst_stride;

That's pointer arithmetic right there.

I think pointer arithmetic like this is kind of safe at least, basically because it's a one-time thing, initialize once with pointer arithmetic and no more afterwards.

and if there's no alloca() doing the dirty work before you get the actual thing started, you will have to later write a lot of crap like

srcp += src_stride;
dstp += dst_stride;

everytime you dereference the pointers within a loop...

and say you're out of your mind for a sec and forget to write that crap in the loop, what's about to happen is:
BOOM! crash!

and when that happens, it's again, extremely hard to find where the program went wrong.

and "alloca()" freed you from all these troubles

[KingLir]

your script is correct, maybe your output program does not support 32bits precision videos (I mean even the crappy 10bits gets to be so called "high bitdepth")

Oh, I am using ffmpeg. Should I look for a special build of ffmpeg that support 32bits precision ? Do you know where I can find it ?

[jackoneill]

Oh, I am using ffmpeg. Should I look for a special build of ffmpeg that support 32bits precision ? Do you know where I can find it ?

ffmpeg doesn't like floating point formats. You'll have to convert back to some integer format before output.

Or nag feisty2 to add support for integer clips, because there's no reason not to.