deen("c3d")

[Marc FD]

my filter for xmas ^^

this is a preview, but "c3d" mode is fully functionnal.
i've a lot of new beta/alpha-code for deen, but i keeped my trusted c3d mode to have a solid basis. read the readme, enjoy, and report the results ^_^

(i know the dll is big, and when i would add full mmx 3d/2d msoften stuff, it'll be even bigger. it's normal, there's a lot of assembly. the "c3d" mode take less than 10 Kb ^^)

(attached "deen beta 1.zip")

@sh0dan : i can change some stuff to use 100% aligned loads, but i only gain some fps, nothing terrible :-/ (not implemented here)

[sh0dan]

Looks very promising indeed! Great work.

Regarding usability, I think it would be great if you used named, optional parameters. If you are going to implement several different softeners (which is a great idea!) I think it would be easier to use. for some reason it's easier for me to remember 'c3d_matrix = "121"' than 'mode = 0' - that way you could also implement optional different thresholds for temporal softening, etc. Donalds filters are great inspiration for that.

Does that make any sense?

ps. a few fps more is good enough for me, if the filter gives me 3fps I'd be happy to look through your implementation - feel free to mail me the source

[Marc FD]

>Looks very promising indeed! Great work.

thx

>Regarding usability, I think it would be great if you used named,
>optional parameters. If you are going to implement several different
>softeners (which is a great idea!) I think it would be easier to use.

well, i have 5 methods : "c3d","a3d","m3d","a2d","m2d" and they all need the same parameters, so it makes sense i share them

>for some reason it's easier for me to remember 'c3d_matrix = "121"' than
> 'mode = 0' - that way you could also implement optional different
>thresholds for temporal softening, etc.

-> exactly the same as vlad's filter to avoid confusion.

>Donalds filters are great inspiration for that.

sure ^_^

>Does that make any sense?

well, if i need to split things, i'll do it ^^

>ps. a few fps more is good enough for me, if the filter gives me 3fps
>I'd be happy to look through your implementation - feel free to mail
>me the source

a few fps like 23+3 fps
accessing unaligned data don't seem to be a big deal
BTW, i could improve pairing, to make 8 check in 11 cycles (currently 13 or 14). but i don't think i can do it much faster ^^

[FuPP]

Sorry Marc, but I don't manage to make that thing working.

I always get a message saying

Avisynth open failure
deen : name list : 'c3d','a3d','m3d','a3d', or 'm2d'

my script :

LoadPlugin("C:\video\avsfilters\deenyv12.dll")
avisource("f:\capture\capture.avi")
converttoyv12()
deen("c3d",1,10,12,3)
bicubicresize(480,576,0,0.75)
converttoyuy2()

I've tried with native yv12 source : same message...

Using W2000, AMD xp 1800+ and avisynth 2.5 build 29/12
So ?

Regards,

FuPP

[Marc FD]

strange. i'll check what could cause that.
it worked flawlessly on MPEG-2 and AVI (MPEG-4) YV12 sources

EDIT : i tested everything i could. i'm still unable to reproduce it. does anyone encounter the same problem ?

[celeron]

Hi
@Marc FD
Nop no problems in here.

PS: thks for your work this filter works very good

[Marc FD]

thx celeron.

if it works, i'll continue then.
there's massive alignement and pairing + some new isse code i want to test ^^

[seewen]

Originally posted by Marc FD
[ i tested everything i could. i'm still unable to reproduce it. does anyone encounter the same problem ? [/B]

I've got exactly the same problem.

I've copied/past your suggestions on the Help-file. Everytime I've got the same error :
" Deen : name list : "c3d", "a3d", "m3d", "a2d" or "m2d" "

I've tried with "deen("a3d",1,10,12)" (your suggestion in the Help file ). I try the same with differents "names" ( c3d, m3d, etc..).

Then I try about 30 others combinations ( with 5 params instead of 4, etc.. ), but I have always the same error.

-----------
I've got Aviynth 2.5 ( 29.12.2002), VdubMod 1.4.13.1, WinXP SP1, AMD Athlon XP.


A+

EDIT : It works.. But not all time. If I open/close the same script some times, suddenly i've got this error.. ( and I didn't touch the script at all meanwhile)

[$$$]

Had the same problem. Here is what I did:
- frameserving the following AVI files to VDubmod
- XP SP1, P4-M

File 1, AVI uncompressed
- no chance to apply deen(), same error message as reported above

File 2, AVI with code IV32
- no chance to apply deen(), same error message as reported above

File 3, AVI with code dvsd
- using AVISource(), deen() throws error message
- using DirectShowSource(), deen() works
- in the same VDub session, deen() works then even with AVISource()

$

[seewen]

It happend very often, if you add "deen" after other filters.

And the only way to make it work ( at least for me ) is to close VdubMod, and then Restart it. And at this moment, the script is ok.

This error happen with "AViSource" and "Mpeg2Source". It happen with other filters and without other filters.
The order of the "loadplugin" declaration (if there' many filters) has no effect.
The order of the functions call has no effect too.

And again, one of the easiest way to reproduce this error, is to make a script with 2-3 filters (1 internal + 2 external, like Conv3d and aSharp. Just need to load those plugins, not necessary use them), and then load this script in VdubMod.
Then open the AvsEditor, and :

1) Replace the "LoadPlugin("Conv3d.dll")" by "LoadPlugin("deen.dll")" , and then add "deen("m2d",1,10,12)" for example

2) Add "LoadPlugin("deen.dll"), and then add "deen("m2d",1,10,12)" for example

But with 1), it append more often. Like if there was a problem when 1 plugin was loading and another Unloading at the same time..

It doesn't happend every time, but really often.
(sometimes you can make it work without closing/re-opening VdubMod, but just in adding a 5th parameter : "deen("m2d",1,10,12)" -> "deen("m2d",1,10,12,3)" . But again it's not 100% sure.).

[Marc FD]

okay, i'm still unable to reproduce it, but i totally rewrote argument parsing, it should be rock solid now.

BTW, new stuff (mass alignement & new isse code) is disabled, i want it to work first ^^ (i don't want to add potential bugs now, so i keep trusted code)

sh0dan, mass alignement didn't help. maybe it's the overhead of my method. but i heard that alignement was crucial with sse2 code, so maybe it would be great for a sse2 version (because i can use only movdqa), the problem, i don't have any sse2 capable cpu ^^. whatever, i think changing all mm# to xmm# would work. i'll need PIV owners to test. potential huge speedup ^_^

(attached deen beta 2.zip)

[sh0dan]

@MarcFD: Yes - my own preliminary results show the same. I get a very good speedup in the processing part, but the initial realignment is _much_ slower than I anticipated.
I am not finished with the tests, but I'm working on a mmx-optimized unpack (currently in C), that writes 4-byte aligned.
Processingwise I'm able to test and blend 8 bytes in parallel, with a perframe-variable matrix.
I cannot seem to fit in the temporal tests, that skips the temporal part - that work make the code branching, and probably slower. Now that the matrix is variable it could actually be funny to try adjusting it on a per-frame basis. Perhaps it could be merged with something along the lines of dup(), using the information to adjust blending.

[Marc FD]

>@MarcFD: Yes - my own preliminary results show the same. I get a very >good speedup in the processing part,

no speedup at all.

> but the initial realignment is >_much_ slower than I anticipated.

not really for me. but it's simple code. no interleaving.

maybe usefull for sse2 i think.

[sh0dan]

What's interesting is that it could actually be made into a generic filtering code, applying any matrix you'd like, much like the resize filter.

I can post the code, when I get the unpacking done (it isn't interleaved, but re-aligned) - I think our approach is slightly different. And yes, with sse2 will speed up the processing part even more - I still don't have a P4 to test it on though.

[FuPP]

Originally posted by Marc FD
okay, i'm still unable to reproduce it, but i totally rewrote argument parsing, it should be rock solid now.

ok Marc, works fine now ; I play a little bit with it and then will report.

Regards
FuPP.

[wotef]

there's lots of fun to be had playing with this filter!

regarding mode, i prefer a3d > c3d > a2d > m2d

regarding thresholds i would say:
very clean dvd source --> don't bother!
light cleaning --> deen("a3d",3,4,1,4)
medium cleaning --> deen("a3d",3,6,1,6)
heavy cleaning --> deen("a3d",4,9,1,9)

one thing i'd like to know more about is how the modes differ from one another, in terms of operation and logic, e.g. a3d vs c3d

in any case, well done, marc - i think this could be a real useful yv12 filter

[Marc FD]

just one thing

>deen("a3d",3,4,1,4)
>deen("a3d",3,6,1,6)
>deen("a3d",4,9,1,9)

is you don't want to filter chroma, use thrUV=0, it'll give a nice speed boost.

[FuPP]

hem,

Probably a stupid question, but parameters you both describe in your last posts don't seem similar to the ones Marc suggests in his "readme".

I quote marc .txt : you can try deen("a3d",1,10,12)

I quote your posts: >deen("a3d",4,9,1,9)

What is mode 4 ?
Is 9 temporal influence ?

FuPP

[frank]

Marc please correct the right syntax.

Your Readme says:
deen(string "name",int "mode",int "thrY",int "thrUV", float "ti")

Or, did you changed it to:
deen(string "name",int "mode",int "thrY",int "thrYtmp,int "thrUV", int "thrUVtmp)

???

[Marc FD]

>Your Readme says:
>deen(string "name",int "mode",int "thrY",int "thrUV", float "ti")

and it's how it works.

when i think about it, wotef used strange settings.
he could give a second look ^^