Eedi2

[HolyWu]

EEDI2-r6.7z (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-EEDI2/releases/latest)
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-EEDI2/

Mainly used as building block for anti-aliasing scripts, not really for deinterlacing nowadays.

[jackoneill]

Nice.

Is it as slow as EEDI3?

https://github.com/HolyWu/VapourSynth-EEDI2/blob/847598e668f00f7e7fb5cab8c966ecac6f880bec/EEDI2/EEDI2.cpp#L1294
This looks like more than one thread will write to d->cx2 and friends, since you use fmParallel.

[HolyWu]

Nice.

Is it as slow as EEDI3?
I can't do speed comparison at the moment as my computer is doing encoding. :p

https://github.com/HolyWu/VapourSynth-EEDI2/blob/847598e668f00f7e7fb5cab8c966ecac6f880bec/EEDI2/EEDI2.cpp#L1294
This looks like more than one thread will write to d->cx2 and friends, since you use fmParallel.
Eh...looks like so. Do I have to use fmParallelRequests instead? Or is there any way to overcome this? :thanks:

[jackoneill]

I can't do speed comparison at the moment as my computer is doing encoding. :p


Eh...looks like so. Do I have to use fmParallelRequests instead? Or is there any way to overcome this? :thanks:

1. Use fmParallelRequests so that only one thread at a time writes to those variables. But then your filter won't be parallel anymore and that's sad.

2. Use fmParallel and modify the filter so the getframe function doesn't write to the filter's shared data. You would allocate and free those arrays in the getframe function. If you feel like trying Myrsloik's suggestion (https://github.com/vapoursynth/vapoursynth/issues/69#issuecomment-52828115), you may avoid allocating and freeing those things on every frame request.

[HolyWu]

Thanks for the info. I think I would just allocate and free the space in the getframe function and be done with it.

By the way, released r2 to fix an error that mthresh and vthresh was not properly initialized.

[HolyWu]

Released r3.

Fix an error that one of the data members is modified in the GetFrame function and may produce incorrect results.

[Are_]

I don't know exactly when neither why or even if it was always like this, but:
$ vspipe make-crash.py /dev/null
Segmentation fault
Script:
import vapoursynth as vs

c = vs.get_core()

s = c.std.BlankClip()
s = c.eedi2.EEDI2(s, field=1)
s.set_output()

Some debug gibberish (https://paste.kde.org/pu0ydjqam/a3gktt).

Is this happening only to me? :/

EDIT: Everything at latest git.

[Myrsloik]

I don't know exactly when neither why or even if it was always like this, but:
$ vspipe make-crash.py /dev/null
Segmentation fault
Script:
import vapoursynth as vs

c = vs.get_core()

s = c.std.BlankClip()
s = c.eedi2.EEDI2(s, field=1)
s.set_output()

Some debug gibberish (https://paste.kde.org/pu0ydjqam/a3gktt).

Is this happening only to me? :/

EDIT: Everything at latest git.

Looks like you didn't compile eedi2 with debug symbols. Without that it's impossible to even guess what went wrong.

[Are_]

I think this time I got it right. :(
Some debug gibberishv2 (https://paste.kde.org/peckruruu/wwcl4e).

[Myrsloik]

I think this time I got it right. :(
Some debug gibberishv2 (https://paste.kde.org/peckruruu/wwcl4e).

Probably memory corruption in the middle somewhere. Next step is to run it in valgrind and see what it says...

[Are_]

I don't know how to run that exactly, here them go a few trys:
valgrind logs (https://dl.dropboxusercontent.com/u/36232595/eedi2-valgrind.zip)

They were generated with this command lines:

valgrind --tool=memcheck --leak-check=yes vspipe make-crash.py /dev/null 2> valgrind1.txt
valgrind --track-origins=yes --tool=memcheck --leak-check=yes vspipe make-crash.py /dev/null 2> valgrind2.txt
valgrind -v --track-origins=yes --tool=memcheck --leak-check=yes vspipe make-crash.py /dev/null 2> valgrind3.txt
valgrind --leak-check=full --show-leak-kinds=all -v --track-origins=yes --tool=memcheck --leak-check=yes vspipe make-crash.py /dev/null 2> valgrind4.txt

[sl1pkn07]

same here, tested with gcc 5.1.0 and gcc 4.9 and clang 3.5.0

with use this flags


CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
CXXFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"


greetings

[HolyWu]

The problem is I can't reproduce it on both 32 and 64 bits, no matter the dll is compiled by VS2013, ICC15 or GCC 4.9.2. Could you provide a dll from your compilation that I can load on Windows?

[sl1pkn07]

sorry, the problem is in linux (like @Are_)

[jackoneill]

tmp2_2 is freed twice, first at line 1325, then at line 1413. The tmp2_2 variable in eedi2GetFrame is not affected by the assignment inside the EEDI2 function. You need to pass its address (or something similar with references).

[HolyWu]

Thank you, jackoneill. Could you or Are_ / sl1pkn07 confirm that the latest commit resolves the segmentation fault problem?

[sl1pkn07]

└───╼ vspipe esee.vpy /dev/null
Output 240 frames in 1.20 seconds (200.62 fps)


yup! \(^o^)/

[HolyWu]

Update r6.


Fix crash that a frame reference is not properly freed.

[BakaProxy]

Why would u actually still need Eedi2 while Eedi3 exists and works within vapoursynth?

The same goes for the ediaa function inside HAvsFunc, why did u use Eedi2 instead of Eedi3?

[mawen1250]

1. EEDI3 is much slower than EEDI2
2. EEDI3 links lines more aggressively and can produce weird artifacts in some cases
3. EEDI2 better suits for slight aliasing