Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th September 2014, 14:03   #1  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
Eedi2

EEDI2-r6.7z
https://github.com/HomeOfVapourSynth...urSynth-EEDI2/

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

Last edited by HolyWu; 16th May 2015 at 20:39. Reason: r6
HolyWu is offline   Reply With Quote
Old 4th September 2014, 18:47   #2  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 723
Nice.

Is it as slow as EEDI3?

https://github.com/HolyWu/VapourSynt...EDI2.cpp#L1294
This looks like more than one thread will write to d->cx2 and friends, since you use fmParallel.
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 5th September 2014, 00:38   #3  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
Quote:
Originally Posted by jackoneill View Post
Nice.

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

Quote:
Originally Posted by jackoneill View Post
https://github.com/HolyWu/VapourSynt...EDI2.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?
HolyWu is offline   Reply With Quote
Old 5th September 2014, 09:20   #4  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 723
Quote:
Originally Posted by HolyWu View Post
I can't do speed comparison at the moment as my computer is doing encoding.


Eh...looks like so. Do I have to use fmParallelRequests instead? Or is there any way to overcome this?
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, you may avoid allocating and freeing those things on every frame request.
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 5th September 2014, 17:03   #5  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
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 is offline   Reply With Quote
Old 10th October 2014, 07:08   #6  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
Released r3.

Fix an error that one of the data members is modified in the GetFrame function and may produce incorrect results.
HolyWu is offline   Reply With Quote
Old 14th May 2015, 20:36   #7  |  Link
Are_
Registered User
 
Join Date: Jun 2012
Location: Ibiza, Spain
Posts: 279
I don't know exactly when neither why or even if it was always like this, but:
Code:
$ vspipe make-crash.py /dev/null 
Segmentation fault
Script:
Code:
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.

Is this happening only to me? :/

EDIT: Everything at latest git.

Last edited by Are_; 14th May 2015 at 20:38.
Are_ is offline   Reply With Quote
Old 14th May 2015, 22:21   #8  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Ikea Chair
Posts: 2,002
Quote:
Originally Posted by Are_ View Post
I don't know exactly when neither why or even if it was always like this, but:
Code:
$ vspipe make-crash.py /dev/null 
Segmentation fault
Script:
Code:
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.

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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 14th May 2015, 22:38   #9  |  Link
Are_
Registered User
 
Join Date: Jun 2012
Location: Ibiza, Spain
Posts: 279
I think this time I got it right.
Some debug gibberishv2.
Are_ is offline   Reply With Quote
Old 14th May 2015, 23:00   #10  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Ikea Chair
Posts: 2,002
Quote:
Originally Posted by Are_ View Post
I think this time I got it right.
Some debug gibberishv2.
Probably memory corruption in the middle somewhere. Next step is to run it in valgrind and see what it says...
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 14th May 2015, 23:30   #11  |  Link
Are_
Registered User
 
Join Date: Jun 2012
Location: Ibiza, Spain
Posts: 279
I don't know how to run that exactly, here them go a few trys:
valgrind logs

They were generated with this command lines:
Code:
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
Are_ is offline   Reply With Quote
Old 15th May 2015, 16:20   #12  |  Link
sl1pkn07
Pajas Mentales...
 
Join Date: Dec 2004
Location: Spanishtán
Posts: 448
same here, tested with gcc 5.1.0 and gcc 4.9 and clang 3.5.0

with use this flags

Code:
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
sl1pkn07 is offline   Reply With Quote
Old 15th May 2015, 18:05   #13  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
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?
HolyWu is offline   Reply With Quote
Old 15th May 2015, 18:27   #14  |  Link
sl1pkn07
Pajas Mentales...
 
Join Date: Dec 2004
Location: Spanishtán
Posts: 448
sorry, the problem is in linux (like @Are_)

Last edited by sl1pkn07; 15th May 2015 at 19:07.
sl1pkn07 is offline   Reply With Quote
Old 16th May 2015, 12:06   #15  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 723
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).
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 16th May 2015, 15:41   #16  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
Thank you, jackoneill. Could you or Are_ / sl1pkn07 confirm that the latest commit resolves the segmentation fault problem?
HolyWu is offline   Reply With Quote
Old 16th May 2015, 15:43   #17  |  Link
sl1pkn07
Pajas Mentales...
 
Join Date: Dec 2004
Location: Spanishtán
Posts: 448
Code:
└───╼  vspipe esee.vpy /dev/null
Output 240 frames in 1.20 seconds (200.62 fps)
yup! \(^o^)/
sl1pkn07 is offline   Reply With Quote
Old 16th May 2015, 20:47   #18  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 641
Update r6.
  • Fix crash that a frame reference is not properly freed.
HolyWu is offline   Reply With Quote
Old 25th June 2015, 12:51   #19  |  Link
BakaProxy
Registered User
 
Join Date: Jan 2015
Posts: 47
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?
BakaProxy is offline   Reply With Quote
Old 25th June 2015, 14:30   #20  |  Link
mawen1250
Registered User
 
Join Date: Aug 2011
Posts: 104
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
mawen1250 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.