MMX optimized LeakKernelDeint 1.5.4

[Leak]

Well, the last version of KernelDeint came out about a year ago, so I decided to take a look at it since I've been heavily using it in my BlendBob plugin.

Much to my surprise, I found that the code was pure C++, with no SIMD optimizations in sight, so I went and optimized it (and took care of a handful of bugs while I was at it):

LeakKernelDeint 1.5.4 (with source) (http://leak.no-ip.org/AviSynth/LeakKernelDeint/LeakKernelDeint_1.5.4.zip)

I've revamped the motion mask code to use a combined motion mask for both chroma planes in YV12/YUY2, which gets rid of some stray chroma artefacts that the older versions of KernelDeint produced when it deinterlaced a spot on only one chroma plane instead of on both.

I've also made the code mirror the top and bottom 4 lines when deinterlacing them so the resolution at the top and bottom is kept intact - the older versions just duplicated every other line there.

Additionally, I've added a LeakKernelBob function to the plugin that takes the same parameters as LeakKernelDeint but does full framerate deinterlacing (i.e. it returns a frame for every field).

And, of course, I've made the whole thing faster using MMX... :D

(I assume that my pure C++ implementations of the various functions perform a bit worse than Donald's code, but unless you force those to be used it'll use the MMX implementations - which, on my machine, are about 2.5 times as fast as the original KernelDeint in YV12 when measured using AvsTimer, and even more in YUY2 and RGB32)

Enjoy. :)

np: Funkstörung - Captured In Tones (ft. Sarah Jay) (Disconnected)

[Boulder]

Nice!

Thank you, I'll try to crash it:D

[Chainmax]

Awesome, I was going to rip my Lion King DVD in a couple of days and I always use KD as a postprocessor for Telecide. Thanks a bunch, Leak :)http://instagiber.net/smiliesdotcom/otn/wink/thumb.gif.

As a side question: what do you guy use for IVTC postprocessing and/or straight up deinterlacing?

[Leak]

Originally posted by Chainmax
Awesome, I was going to rip my Lion King DVD in a couple of days and I always use KD as a postprocessor for Telecide. Thanks a bunch, Leak :)http://instagiber.net/smiliesdotcom/otn/wink/thumb.gif.

As a side question: what do you guy use for IVTC postprocessing and/or straight up deinterlacing?

Well, there's that BlendBob plugin I've written... *whistles innocently*

It's all I've been using lately.

np: Manual - Baja Nights (Until Tomorrow)

[Bogalvator]

Nice work Leak.

A note about the KernelBob() - I notice you say it just does the same as the Scharfis' script. Do you think a "proper" bobbing option can be coded? The patent is still downloadable from the following thread:
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=9

[Leak]

Originally posted by Bogalvator
A note about the KernelBob() - I notice you say it just does the same as the Scharfis' script. Do you think a "proper" bobbing option can be coded? The patent is still downloadable from the following thread:
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=9

Well, I haven't yet read the PDF (it's waaay to late for that today... :)) but I was wondering about a few details of the algorithm itself, so thanks for that pointer.

But still - what do you mean by "proper bobbing"? :confused:

np: Lali Puna - Small Things (Faking The Books)

[sh0dan]

Great! My favorite deinterlacer - now even faster!

:thanks:

[Leak]

Originally posted by sh0dan
Great! My favorite deinterlacer - now even faster!

Glad to be of service... :D

But still - where are the bug reports? Surely I must have messed up _somewhere_? :confused: ;)

np: Underworld - Moaner (Beaucoup Fish)

[Boulder]

I can't get it to crash, but it is nice and fast:D

KernelBobbing the old way with v1.40, I get ~0.33RT in CCE with my regular TV capture script. With v1.50, I get ~0.42RT so there's a real nice improvement. I wonder what those SSE optimizations might provide:)

[Leak]

Originally posted by Boulder
I can't get it to crash, but it is nice and fast:D

KernelBobbing the old way with v1.40, I get ~0.33RT in CCE with my regular TV capture script. With v1.50, I get ~0.42RT so there's a real nice improvement. I wonder what those SSE optimizations might provide:)

I assume you're doing a lot more than just KernelBobbing in your script, right? ;)

Yeah, it's probably not the slowest filter in most chains, so it can't do wonders, but it's still nice to have some speedup... :)

I've sent an email to Milan, as I guess a sped up KernelDeint in ffdshow wouldn't be out-of-place, either...

np: Jimi Tenor - Moon Goddess (Beyond The Stars)

[Boulder]

Originally posted by Leak
I assume you're doing a lot more than just KernelBobbing in your script, right? ;)


That's true;) My standard chain for pure interlaced streams is KernelBob-RemoveGrain-Crop-ColorYUV-RemoveDirt-BicubicResize-Blockbuster-Limiter-AddBorders-SeparateFields-SelectEvery-Weave-ConverttoYUY2. The ~25% speedup is very much appreciated, it used to take about 2h15min to encode a 45-min episode and now it takes a little over 1h45min:) Saves a decent amount of time a couple of times a week, I'd say.

Edited the chain a bit..

[Si]

Just a small point.

Shouldn't you call it something else?

What happens if Donald wants to update his version - you've pinched his filter name and version sequence :eek: :)

Please ignore this if he's given his permission :o

regards
Simon

[scharfis_brain]

@boulder: do converttoyuy2 BEFORE sepfields - selevery - weave

[Boulder]

Originally posted by scharfis_brain
@boulder: do converttoyuy2 BEFORE sepfields - selevery - weave

Sorry for all this OT,

but is that due to getting correct chroma upsampling or is there some other point? I thought that using ConverttoYUY2(interlaced=true) after reinterlacing worked correctly.

[Leak]

Originally posted by Si
Just a small point.

Shouldn't you call it something else?

What happens if Donald wants to update his version - you've pinched his filter name and version sequence :eek: :)

Please ignore this if he's given his permission :o


Well, I tried to ask him 2 weeks ago via PM in his forum, but I haven't heard from him - he's dropped off the planet again obviously... :(

I doubt he'll change his version much, as it hasn't been changed for a year, so I just went with the name and increased the minor version number, as it's mostly optimizations and small bugfixes...

np: Manual - Lunate (Until Tomorrow)

[Cyberia]

Don's away on personal matters. He'll be back when he can, no ETA.

I doubt if he'll mind keeping the same name for the program, but I almost would expect him to find a bug somewhere. ;)

Are further SSE/SSE2/3DNOW/3DNOW2 optimizations possible?

[Leak]

Originally posted by Cyberia
Don's away on personal matters. He'll be back when he can, no ETA.

Well, I guess we'll hear from him then... :)

I doubt if he'll mind keeping the same name for the program, but I almost would expect him to find a bug somewhere. ;)

NOOOOOOOOOooooooo~! :D

Are further SSE/SSE2/3DNOW/3DNOW2 optimizations possible?

I don't have an AMD CPU but a P4, so I couldn't really test 3DNOW, but SSE/SSE2 could be done. It's just that processing 8 pixels in parallel is easy in AviSynth, since the line pitch is a multiple of 8, whereas you have to be careful when processing 16 pixels in parallel so you don't read/write out of bounds...

I'll probably try it, but I guess I'll go back working on my BlendBob plugin first... :)

np: Radiohead - Kid A (Kid A)

[Cyberia]

Well I have an Athlon 3200 which has all those optimizations except SSE2. So even an SSE version would help.

Out of curiousity, does anyone know if AviSynth 3.0 will come in a 64-bit flavor?

[kassandro]

Originally posted by Leak
Well, I tried to ask him 2 weeks ago via PM in his forum, but I haven't heard from him - he's dropped off the planet again obviously... :(

I doubt he'll change his version much, as it hasn't been changed for a year, so I just went with the name and increased the minor version number, as it's mostly optimizations and small bugfixes...

np: Manual - Lunate (Until Tomorrow)
Why don't you call it FastKernenlDeint? After all you did substantial work and an own name is well deserved.


It's just that processing 8 pixels in parallel is easy in AviSynth, since the line pitch is a multiple of 8, whereas you have to be careful when processing 16 pixels in parallel so you don't read/write out of bounds...

You should not assume that the line pitch is a multiple of 8, but you nevertheless can handle an arbitrary line pitch with SSE and even SSE2 effectively(you need a minimum width, though). Look at trbarry's Undot or my RemoveGrain for examples.

[Leak]

Originally posted by kassandro
Why don't you call it FastKernenlDeint? After all you did substantial work and an own name is well deserved.

But it still does the same thing that Don's last version did, so I didn't really want to add yet another new name to the already long-enough list of filters...

You should not assume that the line pitch is a multiple of 8,

http://www.avisynth.org/BensAviSynthDocs

Buffers created by NewVideoFrame are always quadword (8-byte) aligned and always have a pitch that is a multiple of 8.

What other way than NewVideoFrame is there to create a frame, and why would anybody do something like that? And even then, my output buffer will be 8-byte aligned, so all I'd have to do is special-case the last line so I don't do an out-of-bounds read at the very end; if I happen to process some data from the next line at the line end that's not used it doesn't matter. Or I could just copy non-8-byte-aligned frames into a new frame; that's still faster than falling back to the C++-implementation.

but you nevertheless can handle an arbitrary line pitch with SSE and even SSE2 effectively(you need a minimum width, though).

Yes, I know that. It's just that doing so (a loop for the length rounded down to 16 and another one for the beginning or end) would almost triple the size of my KernelDeint DLL compared to what it's now, when adding SSE2 routines alone would probably double it - and it's already over 10 times bigger than the old one.

Also, I'm not convinced that the speedup I'll get from going from MMX to SSE/SSE2 (which mostly added floating point stuff I wouldn't use anyway) is as big as the one I got from going from pure C++ to MMX; I'll do it, but it's further down my To-Do list than working on my own plugin again... :)

np: Markus Guentner - So Well (Audio Island)

[kassandro]

Originally posted by Leak
What other way than NewVideoFrame is there to create a frame, and why would anybody do something like that? And even then, my output buffer will be 8-byte aligned, so all I'd have to do is special-case the last line so I don't do an out-of-bounds read at the very end; if I happen to process some data from the next line at the line end that's not used it doesn't matter. Or I could just copy non-8-byte-aligned frames into a new frame; that's still faster than falling back to the C++-implementation.

You are right: with external filters you can only creat frames with NewVideoFrame, but the internal filters can! For instance, frames generated by crop are usually not aligned to avoid an unnecessary bitblt. Only if you crop with align=true, which is not the default you get a properly aligned frame. While you are correct: it is nearly impossible to get a read access error, if you read only a few bytes beyond the allowed range (a memory page is at least 4 kb), it is simply a dirty programming style to do so. If your mind is not sharpened for these kind of problems, you will sooner or later end up in a mess - at least in larger projects.


Also, I'm not convinced that the speedup I'll get from going from MMX to SSE/SSE2 (which mostly added floating point stuff I wouldn't use anyway)
SSE contains a lot more than some new floating point instructions. While in SSE you can do only single precision floating point stuff in SSE registers, you can do a lot more in the MMX registers. For instance, the very useful instructions pminub and pmaxub are SSE only and you only can emulate them with MMX and the extremely powerful psadbw instruction cannot even emulated. Though there are only very few new integer SSE instruction, they are very useful and fill a gap left by MMX. I could have implemented RemoveGrain (not RemoveDirt) for MMX only, because it doesn't use psadbw, but it would have been much slower. The fun starts with SSE and not with MMX.

[sh0dan]

A sidenote should be that the MMX-extensions kassandro mentions are also refered to as Integer SSE, which is present on 95% of all processors using AviSynth today.

However, I didn't find any obvoius places it would make sense to apply.

A thing you use a lot:
mov ebx,043544354h ; 32768*0.526
movd mm2,ebx
G.P. Register <-> MMX register transfers are bad (=slow). You should either 1) Read it from memory to MMX. or 2) store GPR in memory + read from memory with MMX (yes, this is faster - the CPU will be able to do a Store->Load Forward, if the memory is aligned.

[Leak]

Originally posted by sh0dan
A thing you use a lot:
mov ebx,043544354h ; 32768*0.526
movd mm2,ebx
G.P. Register <-> MMX register transfers are bad (=slow). You should either 1) Read it from memory to MMX. or 2) store GPR in memory + read from memory with MMX (yes, this is faster - the CPU will be able to do a Store->Load Forward, if the memory is aligned.

Well, that might be because when I started dabbling around with assembler 486s were the top of the line and accessing registers was much less expensive than accessing memory - guess I haven't gotten over that yet... :)

I guess I'll fix that and do a comparison; are you sure the difference will be really noticeable?

(EDIT: Okay, so my test script went from 338 FPS to 342 FPS with this change; good to have, but still hardly noticeable...)

Then again, I also made the mistake to use MOVNTQ for writing to the target buffer after reading it's description in Intel's docs thoroughly, only to discover that it tears the filter's performance to shreds... :mad:

np: Komeit - When The Sun Hits (Blue Skied An' Clear comp.)

[Leak]

Originally posted by kassandro
You are right: with external filters you can only creat frames with NewVideoFrame, but the internal filters can! For instance, frames generated by crop are usually not aligned to avoid an unnecessary bitblt.

Ugh. Didn't think about crop there...

Only if you crop with align=true, which is not the default you get a properly aligned frame. While you are correct: it is nearly impossible to get a read access error, if you read only a few bytes beyond the allowed range (a memory page is at least 4 kb), it is simply a dirty programming style to do so. If your mind is not sharpened for these kind of problems, you will sooner or later end up in a mess - at least in larger projects.

I know that. As I said, it didn't occur to me that crop would fail the assumption I had made; but still - all I need to special case is the last line (assuming the line is at least 8 bytes long, which would IMHO be a sensible constraint to be checked in the constructor) of each field - still a bit messy, but it takes a lot less code duplication. Overreading from one of the other lines into the next one is totally harmless.

SSE contains a lot more than some new floating point instructions. While in SSE you can do only single precision floating point stuff in SSE registers, you can do a lot more in the MMX registers. For instance, the very useful instructions pminub and pmaxub are SSE only and you only can emulate them with MMX and the extremely powerful psadbw instruction cannot even emulated.

Yeah, it could be emulated, but it'd need a lot of effort... still, I can't really use it as I need the absolute difference for each pixel, not the sum of them - and that's something that's doable with reasonable effort in MMX. If you add some shuffling and unpacking you can emulate PSADBW...

Though there are only very few new integer SSE instruction, they are very useful and fill a gap left by MMX. I could have implemented RemoveGrain (not RemoveDirt) for MMX only, because it doesn't use psadbw, but it would have been much slower. The fun starts with SSE and not with MMX.

As I said, I'll do a SSE/SSE2 version as well, but it's further down my to-do list; I started with an MMX version as I wanted it to run on every machine that's capable of running AviSynth.

It's already a lot faster than the last version, and I'm quite happy about that, and to be totally honest I did it to be able to integrate part of it into BlendBob...

np: The Notwist - Trashing Days (Neon Golden)

[Leak]

KernelDeint 1.5.1 (with source) (Old version; see first post for newest version)

This version includes the changes sh0dan suggested (which resulted in a small speedup) and doesn't read beyond the end of frames anymore if your pitch doesn't happen to be a multiple of 8.

EDIT: There's one other change I forgot - in 1.5.0 the order parameter was inverted for RGB32 video; is anybody even using it for that? ;)

Still, if your pitch isn't evenly divisible by 8, you'll get a minor drop in speed if the frame is still aligned on an 8 byte boundary (for example if you just crop off something to the right), but you'll get a bigger speed drop if that's not the case as unaligned memory access just plain takes longer (which can happen when you cut off stuff on the left with crop) - in that case, always use "align=true" with crop.

Or, in numbers:


Testclip FPS
============================= ===
Normal 332
Crop(0,0,716,480,align=false) 329
Crop(2,0,716,480,align=false) 282
Crop(2,0,716,480,align=true) 325


My testclip is a 720x480 VOB read via MPEG2Source, and the FPS of doing a KernelBob(1,8,linked=false) were measured using AvsTimer.

np: Markus Guentner - Sleep Well (Audio Island)

[Bogalvator]

Originally posted by Leak
But still - what do you mean by "proper bobbing"? :confused:

In KernelBob's current state it is working as a single rate deinterlacer, shifted by a field and then simply reinterleaved.

It seems to me that the aim of a "proper" bobber would be to return each field to to it's full resolution - which may involve different strategies than that of a deinterlacer thats aiming to give best results for 25 fps or 29.97 progressive output.

I hope that made some sort of sense.

[Xesdeeni]

Originally posted by Bogalvator
In KernelBob's current state it is working as a single rate deinterlacer, shifted by a field and then simply reinterleaved.

It seems to me that the aim of a "proper" bobber would be to return each field to to it's full resolution - which may involve different strategies than that of a deinterlacer thats aiming to give best results for 25 fps or 29.97 progressive output.

I hope that made some sort of sense.As I understand it, bob was created for displaying an interlaced video on a progressive display, normally creating the same number of progressive frames as input fields. I.E. PAL would result in 50 progressive fps, while NTSC would result in 59.94 progresive fps (obviously then using frame duplication for display at 70, 72, 75, 85 etc. Hz).

Deinterlacing is basically the process of creating the progressive frames from the interlaced input. But the term also seems to have evolved into the process that outputs progressive frames at the input frame rate (i.e. PAL would result in 25 progressive fps, while NTSC would result in 29.97 progressive fps), normally to improve video encoding by feeding progressive instead of interlaced frames to the codec.

In my book, technically inverse telecine is deinterlacing as well, but it's so specific to film (and the output for NTSC is not the input frame/field rate) I think it's a class of its own.

So at the risk of being pedantic, I guess I'd say a "proper deinterlacer" would use any technique possible (including inverse telecine, field matching, etc.) to create a progressive output at the input frame rate (25 or 29.97), while "proper bob" would use the same techniques to create a progressive output at the input field rate (50 or 59.94).

BTW, my interest in deinterlacing is for standards conversion, so bob is much more useful to me :).

Oh, and just to throw out a little controversy :devil:, the better the deinterlacer, the harder the image will be to compress. So saying that the output of a particular deinterlacer is "harder to compress" can mean the quality is better! [To prove this, you'd need perfect deinterlacing. The closest we have is inverse telecine. So if you don't believe me, take a telecined video and IVTC it, and compare compressing this to a video deinterlaced using your favorite deinterlacer. (Be sure to match frame rates.) Barring out-and-out failures of the deinterlacer (combing left in), the IVTC should be at least as difficult to compress, and usually more difficult.]

Xesdeeni

[Nicholi]

The shiny packages reference to the chroma artifacts possibly being lessened doesn't seem to hold true for all the things I've tried so far.

Wondering if anyone else has though? And what type of source?
Dealing mostly with anime's here and the 1.4.0 and 1.5.1 images look exactly the same.

[Leak]

Originally posted by Nicholi
The shiny packages reference to the chroma artifacts possibly being lessened doesn't seem to not hold true for all the things I've tried so far.

Whoa there - could you please use less double negatives? I'm having a hard time figuring out if you get more or less chroma artifacts.

Wondering if anyone else has though? And what type of source?
Dealing mostly with anime's here and the 1.4.0 and 1.5.1 images look exactly the same.

Could you please post some images then?

Also, what I've fixed was one kind of chroma artifacts (which produced some faint chroma ghosting when one plane was deinterlaced and the other wasn't), I didn't say it'd fix _ALL_ possible chroma artifacts; if you mean the slight ghosting KernelDeint causes now and then then that's something inherent in the algorithm that can't be avoided.

Try using a threshold of 0 on the images you get artifacts on, if they stay they're not of the kind that my change fixes.

np: Sole - Teepee On A Highway Blues (Selling Live Water)

[Nicholi]

Err yeah sorry. Edited accordingly. I suppose we are talking about different things, my mistake. I speak of the usual "ghosted" lines from the deinterlaced movement. Already on thresh=0 also.

I would upload the pics if I could, but alas I have no webhost or such. So it seems what I was looking for is not actually here, heh. And also unavoidably removed...oh well. There is always Sangnom to alternate with on occasion.

Thank you for continu'ing work on an already great filter however. :)
KernelDeint is my default choice for deinterlacing, and mayhaps when DG returns he will hopefully implement your hard work.

[DDogg]

Nicholi, - For image hosting try this. (http://imageshack.us/index3.php) It is great. You don't even have to register.

[Boulder]

There seems to be something wrong with KernelBob.

With this script I get a bad result:
MPEG2Source("c:\temp\captures\startrek.d2v",idct=7)
KernelBob(order=1,sharp=true,threshold=7)
SeparateFields()
SelectEvery(4,1,2)
Weave()

With this script it's OK:
MPEG2Source("c:\temp\captures\startrek.d2v",idct=7)
KernelBob(order=1,sharp=true,threshold=7)
ConverttoYUY2()
SeparateFields()
SelectEvery(4,1,2)
Weave()

Here are the screenshots:

YV12
http://www.saunalahti.fi/sam08/yv12.jpg

YUY2
http://www.saunalahti.fi/sam08/yuy2.jpg

The original material
http://www.saunalahti.fi/sam08/original.jpg

If I replace KernelBob with a simple Bob(), both scripts give a proper result. I didn't test whether the v1.4.0 with scharfis_brain's function would behave the same way.

The screenshots are not exactly at the same frame so don't pay attention to that. Just pay attention to the amount of combing in the subtitles in the YV12 version.

The funny thing is that this weird behaviour is not seen throughout the whole clip, it's just a small portion in the middle. I also tried order=0 and SelectEvery(4,0,3) but it didn't help.

[Boulder]

Just tried it with KernelDeint v1.5.1 and scharfis_brain's function from the Restore24 package, and it gives a correct output without a need to convert to YUY2. So there's something wrong with Leak's implementation of the function;)


function kernelbob(clip a, int "th",bool "mask")
{ mask=default(mask,false)
th=default(th,5)
ord = getparity(a) ? 1 : 0
f=a.kerneldeint(order=ord, sharp=true, twoway=false, threshold=th,map=mask)
e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=true, twoway=false, threshold=th,map=mask)
interleave(f,e).assumeframebased
}

[Leak]

Originally posted by Boulder
There seems to be something wrong with KernelBob.

...

If I replace KernelBob with a simple Bob(), both scripts give a proper result. I didn't test whether the v1.4.0 with scharfis_brain's function would behave the same way.

The screenshots are not exactly at the same frame so don't pay attention to that. Just pay attention to the amount of combing in the subtitles in the YV12 version.

The funny thing is that this weird behaviour is not seen throughout the whole clip, it's just a small portion in the middle. I also tried order=0 and SelectEvery(4,0,3) but it didn't help.

Hmmm... yeah, taking a close look at KernelBobs output it seems something isn't totally right; could you try setting the threshold to 0 and have a look at the b0rked segment again? I have the nagging feeling that I've got an error in my motionmask code, so if there's no artifacts using a threshold of 0 (which turns KernelDeint into something closer to a regular Bob()) I know where to look.

Also, could you cut out a short part of that sequence and upload it somewhere? :)

I'm pretty sure it's got something to do with the order of the fields getting passed into MotionMask, but I can't put my finger on it...

np: Plaid - Crumax Rins (Spokes)

[erratic]

I have noticed that with Leak's KernelBob I have to use SelectEvery(4,0,3) to maintain the field order. If I use SelectEvery(4,1,2) the field order is reversed. This happens with both TFF and BFF sources.

No matter what the source is, with scharfis_brain's kernelbob function I have to use SelectEvery (4,1,2) to get TFF, and SelectEvery(4,0,3) to get BFF.

[Leak]

Originally posted by erratic
I have noticed that with Leak's KernelBob I have to use SelectEvery(4,0,3) to maintain the field order. If I use SelectEvery(4,1,2) the field order is reversed. This happens with both TFF and BFF sources.

No matter what the source is, with scharfis_brain's kernelbob function I have to use SelectEvery (4,1,2) to get TFF, and SelectEvery(4,0,3) to get BFF.

That might be because I do an AssumeTFF() internally before calling SeparateFields in my filter to get a fixed field order. Maybe this problem also crops up because I'm not doing an AssumeFrameBased() at the end of KernelBob - Boulder, could you try if adding that after KernelDeint helps?

np: Plaid - Assault On Precinct Zero (Double Figure)

[Boulder]

OK, I'll do the test and get you a small sample tomorrow - unfortunately I probably won't have the time today:(

[erratic]

I just ran a short test and with AssumeFrameBased after KernelBob it behaves like scharfis_brain's kernelbob function: SelectEvery(4,1,2) results in TFF, SelectEvery(4,0,3) results in BFF.

EDIT: as far as the field order is concerned, Avisynth's internal Bob() command works like scharfis_brain's kernelbob function.

[Mug Funky]

that's bizarre, because i haven't encountered this at all and i've been using the leak version since it was released.

maybe i should check my plugin directory for avsi files with kernelbob in them?

[Leak]

Originally posted by Mug Funky
that's bizarre, because i haven't encountered this at all and i've been using the leak version since it was released.

maybe i should check my plugin directory for avsi files with kernelbob in them?

Nah, it's true. My KernelBob is not doing the AssumeFrameBased() after bobbing, so the frames seem to keep the TFF flag I force on them in my filter when doing another SeparateFields() afterwards - which of course was something I didn't do when testing, as I'm always going for a progressive result and which won't cause havoc until going back to fieldbased processing (which I hardly ever do) afterwards...

Try this: add a call to Info() after KernelBob() and then add a AssumeFrameBased() in between and compare the parity...

Still, a AssumeFrameBased() after KernelBob() should do the trick until I release the next version; it's just that I currently don't have much time to work on AviSynth filters...

Now I'm just wondering if that was what bit Boulder as well...

np: The Black Dog - Frisbee Skip (Spanners)

[Boulder]

Yep, I had the time to do a little test and AssumeFrameBased() got rid of the problem:)

[Xesdeeni]

If anyone is familiar with my port of Gunnar Thalin's SmoothDeinterlacer to AVISynth, you might know I have a workaround in the scripts, for what I thought was in the plugin. I'm not absolutelyn positive, but I think the problem may be the same you guys are seeing. I found the same AssumeXXX() workarounds as you guys. Perhaps this isn't in the plugins?

Xesdeeni

[Kika]

SelectEvery(4,1,2) results in TFF, SelectEvery(4,0,3) results in BFF

SelectEvery(4,1,2) always reverses the Field Order, that's a normal behavior. It's the 1 which is doing this - this gives you an Offset of 1 Field, the first Field will be dropped - and that's a perfect way to change the Field Order.

Two Tipps:
Never forget the AssumeTFF (or, if needed, AssumeBFF) after opening the Video.
Always use SelectEvery(4,0,3) if no Field Order Change is needet.

[Xesdeeni]

Originally posted by Kika
SelectEvery(4,1,2) always reverses the Field Order, that's a normal behavior. It's the 1 which is doing this - this gives you an Offset of 1 Field, the first Field will be dropped - and that's a perfect way to change the Field Order.

Two Tipps:
Never forget the AssumeTFF (or, if needed, AssumeBFF) after opening the Video.
Always use SelectEvery(4,0,3) if no Field Order Change is needet. I think I see why this is true, but I'm not sure it should work that way.

After you have run an interlaced video through a smart bobber (i.e. a deinterlacer to the field rate), you have a progressive stream. At that point, there is no field polarity information at all. It doesn't matter what the input video is, the video is a sequence of full frames.

When you do SeparateFields(), AVISynth must choose which field to use first. It appears that the original field polarity is used, although it really has no meaning at this point. That's why SelectEvery(4,0,3) gives you the original field order. But by all rights, when the stream is progressive, there is no field polarity. I'd guess the field polarity should be undefined. I guess when you do SeparateFields(), you should have to specify which field order you want. AssumeXFF() before obviously does the same thing, but it's not as obvious, and it doesn't make sense to me that a progressive video would have a field polarity.

One other problem with field polarity associated with progressive video is that this field polarity appears to sometimes be lost through other filters. I created a stream the other day that broke an input video into three sections. The first and third needed to be deinterlaced, but the middle was all film, so I was able to avoid the deinterlacer for that section. In this section I used ChangeFPS() instead. When I viewed the individual sections, all was well. But when I concatenated them, the field polarity was altered in mid stream. What's really weird, is the polarity didn't change at one of the boundaries, it changed in the middle of the first section!!! I had to add an AssumeFrameBased() to the middle(!) section to fix the first section. (You can imagine how much trial and error it took to find this seemingly unrelated fix.)

I'm certainly not sure about any of this. But this is how it seems to work.

Xesdeeni

[Boulder]

Hmm, I don't get this. I have a TFF clip, which is then smartbobbed with KernelBob(order=1). Supposedly SeparateFields().SelectEvery(4,1,2).Weave() reverses the field order, so why is the field order still TFF after SelectEvery?

Xesdeeni, I've seen the situation you described in some of my TV caps when dealt with the original KernelBob function and KD v1.4.0. If I had forgotten AssumeTFF() from the beginning of the script, there sometimes were really weird artifacts in the result as the original KernelBob takes the field order from some info that Avisynth provides.

N00b talk:D

[Kika]

so why is the field order still TFF after SelectEvery?

Because SelectEvery does not set any Field Order. So if the Source was TFF, it will be flagged as TFF no matter what you are doing with the Video (except AssumeBFF).

After Bobbing, the First Field is the first frame, the second field is the second frame.
After SelectEvery(4,1,2), the second frame will be used as the first Field and so on. That's why the Field Order always changes after SelectEvery(4,1,2).

[erratic]

Originally posted by Kika
That's why the Field Order always changes after SelectEvery(4,1,2).Avisynth's internal Bob() command works differently.

# Source AVI is TFF
AviSource("cap-tff.avi").AssumeTFF()
Bob()
SeparateFields().SelectEvery(4,1,2).Weave()Result is TFF (field order has not changed).
With SelectEvery(4,0,3) the field order changes to BFF.

# Source AVI is BFF
AviSource("cap-bff.avi").AssumeBFF()
Bob()
SeparateFields().SelectEvery(4,1,2).Weave()Result is TFF (field order has changed).
With SelectEvery(4,0,3) the field order remains BFF.

So Bob() with SelectEvery(4,1,2) always results in TFF,
while Bob() with SelectEvery(4,0,3) always results in BFF.

It's less confusing if all bobbers work like the internal Bob() command as far as the field order is concerned.

EDIT: like I wrote earlier, KernelBob() followed by AssumeFrameBased() works like Bob(). SelectEvery(4,1,2) always results in TFF. SelectEvery(4,0,3) always results in BFF.

[Kika]

OK, that's what i used for Testing:

The Testscript:

LoadPlugin("E:\AviSynth2.5\AVS25Plugins\kerneldeint.dll")
avisource("CAPTURE.00.avi", true, "RGB24").assumeTFF()
ConvertToYUY2(interlaced=true)
KernelBob(order=1, sharp=true, twoway=true, threshold=0)
BicubicResize(672,544,0,0.6)
SeparateFields.SelectEvery(4,0,3).weave()
ConvertToRGB24(interlaced=true)


And that's for checking:

avisource("CAPTURE.00.avi", true, "RGB24").assumeTFF()

(just a Dummy for Checking)

At last, i opened the Video directly with TMPGEnc.
All encodings done by TMPGEnc with Top Field First.

Both Scripts do result in TFF-Videos also the Direct-Encoding without AVISynth.

[erratic]

Yes, your script results in TFF, but if you replace KernelBob() with Bob() it results in BFF, so Bob() and KernelBob() give different results with a TFF source.

With KernelBob() SelectEvery(4,1,2) always changes the field order.
With Bob() SelectEvery(4,1,2) always results in TFF, even if the source is TFF.

I assume that's because Bob() always resets the field order to the Avisynth default (BFF) by calling AssumeFrameBased() internally. So if you use Bob() on a TFF source the parity will change to BFF, and then SelectEvery(4,1,2) changes it back to TFF.

KernelBob() does not call AssumeFrameBased() so the parity remains TFF and SelectEvery(4,1,2) will change it to BFF.

My point is that all bobbers should have the same effect on the field order as Bob() to avoid confusion. I should be able to replace any bobber with another one without having to change anything else in my script.

Fortunately it's easy to avoid those field order differences by using AssumeFrameBased() after the bobber. AssumeFrameBased() resets the parity to BFF and then SelectEvery(4,1,2) always results in TFF, while SelectEvery(4,0,3) always results in BFF. So it's not really a big problem.

[Kika]

I assume that's because Bob() always resets the field order to the Avisynth default (BFF) by calling AssumeFrameBased() internally.

I'm not a programmer, but i guess, you are right here.
The Problem: If AssumeFrameBased() really resets the Field order internally to BFF, that's not what i want.
If i have used AssumeTFF i want AVISynth to stay at TFF!

I never used Bob(), but SmoothDeinterlace (doublerate=true) and this Bobber act's like Kernelbob if the correct Field order is given (after AssumeTFF as an example).
If i write my own (dump) Bobber by using AVISynth-Functions, it act's like KernelBob(), not like Bob().
So, from my point of view, Bob() does it wrong, all other Bobbers are doing it correct. :devil:

[erratic]

Well, if Bob() does it wrong then maybe the Avisynth programmer's can explain it to us?

Boulder posted this kernelbob function by scharfis_brain earlier.function kernelbob(clip a, int "th",bool "mask")
{ mask=default(mask,false)
th=default(th,5)
ord = getparity(a) ? 1 : 0
f=a.kerneldeint(order=ord, sharp=true, twoway=false, threshold=th,map=mask)
e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=true, twoway=false, threshold=th,map=mask)
interleave(f,e).assumeframebased
}It also includes AssumeFrameBased. Why, Scharfi? :)

I also tried TDeint (http://forum.doom9.org/showthread.php?&threadid=82264) today and it doesn't reset the field order, so it works like Leak's KernelBob() and not like Bob().
Maybe all those guys who are writing bobbers should get together and make their mind up. ;)

[scharfis_brain]

IMO a bobber MUST read the fieldorder-flag of avisynth.

this is
1) more comfortable to use
2) no need for cracking our brains on zeroes and ones for setting TFF or BFF via a paramter
3) it is flexible. use another source with the same script without editing the order-paramter.

that's why I always check the Fieldorder within my bobbing functions, meaning the only (and correct) way to set up the fieldorder is either AssumeTFF() oder AssumeBFF() directly after loading the video.

setting an order-parameter is bothering.

also I set assumeframebased() at the end of the function is, cause else the video gets assumed as fieldbased stuff, which is NOT the correct assumption, if a video has been bobbed.

bobbed = framebased

[erratic]

I agree that a bobber should read the field order flag of avisynth, but what should a bobber do to the field order flag after bobbing?

I know that after bobbing the video is progressive, but AFAIK there's no progressive flag in avisynth: the parity is always BFF or TFF. Bob() resets the field order to BFF (avisynth default) even if the source was TFF. KernelBob() and TDeint() currently preserve the field order flag. I tend to agree with Kika that preserving the field order flag seems more correct than resetting it. I certainly think that all bobbers should at least do it the same way to avoid confusion.

[Kika]

Imho the default Field order in AVISynth should be changed from BFF to TFF - in any cases.
There's only one kind of source which needs BFF - it's DV-Video. In all other cases, TFF is the standard - even in progressive Video!
If you check some progressive DVDs, you will see that the TFF-Flag is active.
I have never seen a DVD with progressive Video and BFF - so, in most cases (except DV-Video-Users), TFF ist the right setting, not BFF.

[killingspree]

edit: stupid me... was a mistake in the gknot script :)

no cropping before deinterlacing :D

cheers

[scharfis_brain]

back to our selectevery(4,1,2) / (4,0,3) - problem.

KiKa is right. 4,1,2 reverses the FO and 4,0,3 leaves it.

so:

assumeframebased().assumebff().separatefields().selectevery(4,0,3).weave()
returns BFF

assumeframebased().assumebff().separatefields().selectevery(4,1,2).weave()
returns TFF

assumeframebased().assumetff().separatefields().selectevery(4,0,3).weave()
returns TFF

assumeframebased().assumetff().separatefields().selectevery(4,1,2).weave()
returns BFF


this means for me:

whateverbob()
whicheverfilter()

# my new standard for reinterlacing:
assumeframebased()
assumebff()
#maybe: converttoyuy2()
separatefields()
selectevery(4,1,2) #4,0,3
weave()

weird (but somehow correct) world

[Wilbert]

Some useless comments


I know that after bobbing the video is progressive, but AFAIK there's no progressive flag in avisynth:
Yup true, avs v2.5 doesn't have a progressive/interlaced flag.

So, from my point of view, Bob() does it wrong, all other Bobbers are doing it correct.
I agree that Bob() should preserve the field order flag.


There's only one kind of source which needs BFF - it's DV-Video. In all other cases, TFF is the standard - even in progressive Video!
If you check some progressive DVDs, you will see that the TFF-Flag is active.
I have never seen a DVD with progressive Video and BFF - so, in most cases (except DV-Video-Users), TFF ist the right setting, not BFF.

Progressive video has no TFF or BFF, so this comment doesn't make any sense.

Imo, it's too late to change the avs' default field order to TFF. Perhaps it's a good idea to look at this for avs v3.0.

Q) interlaced-XviD is that also TFF?

[scharfis_brain]

Progressive video has no TFF or BFF, so this comment doesn't make any sense.

maybe. maybe not.

encode a progressive movie once using TFF and the other time using BFF
(but both with progressive encoding!)

then burn both to a disc and play them back on your DVD-SAP, which is connected to a TV-Card.

you'll see, that the TFF encoded file looks progressive.
the BFF encoded one is phase shifted! (or was it vice versa ?!?)

but of course. for progressive video, a fieldorder is (mostly) nonsense

[erratic]

Originally posted by scharfis_brain
# my new standard for reinterlacing:
assumeframebased()
assumebff()
#maybe: converttoyuy2()
separatefields()
selectevery(4,1,2) #4,0,3
weave()

weird (but somehow correct) world AssumeBFF() is unnecessary after AssumeFrameBased(). AssumeFrameBased() already resets the parity to bff.

But if the source is tff, why assumebff after bobbing? Why not assumetff. Kika, Wilbert and I would like to preserve the field order after bobbing. If you bob tff video the top field is now the first frame, so the top field still comes first. Why would you change the parity to bff? Or should every bobber behave like the internal Bob() command to avoid confusion? Maybe Bob() should be fixed. I also don't know why assumeframebased resets the parity to bff. If the source is tff, the parity should remain tff after assumeframebased. If you disagree, I'd like to know why.

[scharfis_brain]

jep! preserving the FO-flag is important, cause then we can write bobbing / reinterlacing scripts without caring much about the fieldorder.

[erratic]

Well, if you agree that the field order should be preserved, then AssumeFrameBased() is a buggy command. I hope the avisynth programmer's fix it so that it preserves the TFF flag when appropriate. I guess Bob() would then also preserve the field order.

[Kika]

Progressive video has no TFF or BFF, so this comment doesn't make any sense.

As Scharfi wrote: Encode a progressive Video with BFF-Setting and you will get a Field Shifted Output on an Standalone. Encode it with TFF, which is the native Field Order, and all is OK.

Analyse some progressive DVDs - you will find out: all of them are TFF. Don't forget: DVD-Players have to provide an interlaced Signal for the TVs and they have to decide, which part of the Frame should be the even and which one the odd field.

[scharfis_brain]

imo the FO setting for progressive film can be useful, if you become weird and want to encode interlaced content as progressive.
(I already did so!)

this may be an option, when only the end-credits are interlaced & black/white so the wrong chroma sampling won't matter and the lesser compressibility doesn't IMO matter, too there.

[Piper]

I'm curious, would it ever make sense to use the following script for anything other than PAL -> NTSC conversions? What would the implications be if say it were used on pure NTSC interlaced or Star Trek TNG sources?

AVISource("c:\capture.avi").AssumeTFF()

KernelBob(order=1,threshold=0,sharp=true,twoway=true)
AssumeFrameBased()
ChangeFPS(59.94)
SeparateFields.SelectEvery(4,1,2)
Weave()

KernelDeint(order=1,threshold=0,sharp=true,twoway=true)

EDIT: Rephrased question, removed previous assumptions. ;)

[scharfis_brain]

@Leak: some fundamental questions related to YV12 deinterlacing:

- if an area is detected as non-moving, will the YV12 chroma be weaved, too?
- is the YV12-chroma also kernel-interpolated?

if both marks are right, then could you write some sort of motion adaptive interlaced YV12 -> YUY2 conversion?

this means:

- bob the input stream
- convert its chroma to YUY2
- reinterlace the chroma
- insert this reinterlaced chroma to the unprocessed (still interlaced) luma

I will try to cobble together such a script in AVISynth.

this should make it possible to retain progressive chroma-quality (2x2 Pixels chroma) in static parts and
low resoluted chroma quality (2x4 pixels) in moving parts

[len0x]

I'm using the following two scripts and encode them at constant quant 2:

mpeg2source("test.d2v")
crop(12,8,700,560)
KernelDeInt(order=1,sharp=true)
LanczosResize(640,480)

mpeg2source("test.d2v")
crop(12,8,700,560)
KernelDeInt(order=1,sharp=true)
BicubicResize(640,480,0,0.5)

With version 1.4.0 I am always getting smaller filesize with second one (obviously resizer is much softer), but with version 1.5.1 second encode ends up with 4.5% larger filesize! This is totally wrong or may be I'm missing something here?

[Leak]

Originally posted by len0x
With version 1.4.0 I am always getting smaller filesize with second one (obviously resizer is much softer), but with version 1.5.1 second encode ends up with 4.5% larger filesize! This is totally wrong or may be I'm missing something here?

Well, there was a bug in version 1.4.0 where Don used one wrong pixel value during the calculation when using sharp=true; that probably made the result less sharp, thus yielding a slightly smaller filesize...

Also, the first and last 4 lines of the image weren't really processed in version 1.4.0, but I doubt that's responsible here...

np: Shadow Huntaz - Roar (Corrupt Data)

[len0x]

Originally posted by Leak
Well, there was a bug in version 1.4.0 where Don used one wrong pixel value during the calculation when using sharp=true; that probably made the result less sharp, thus yielding a slightly smaller filesize...


That's understandable, but see I'm not comparing 1.4.0 vs 1.5.1, but rather Neutral (not even sharp!) Bicubic vs Lanvzos with 1.5.1. By definition on the same source bicubic is more compressible than Lanczos (correct me if I'm wrong here), but results I get are the opposite (well, if I don't use KernelDeInt but some other deinterlacer I have normal behaviour). So somehow new KernelDeInt messes up filter that cames right after it may be? (I don't think output is wrong)

[len0x]

If its not KernelDeInt it might be resizer problem. Gonna start different topic on that...

[Leak]

Originally posted by Leak
Well, there was a bug in version 1.4.0 where Don used one wrong pixel value during the calculation when using sharp=true; that probably made the result less sharp, thus yielding a slightly smaller filesize...

And, of course, there *WERE* 2 bugs in 1.5.1... :(

For one, threshold=8 in 1.5.1 would act like threshold=7 in 1.4.0. And also, my motion mask code was doing the motion mask for the field that was copied rather than for the field that was interpolated... :( *slaps himself*

So here is a fixed version:

KernelDeint 1.5.2 (with source) (Old version; see first post for newest version)

This should produce a motion mask for the Y-plane that's exactly the same as in Donald's version, except for the top and bottom 4 lines of course.

np: Gold Chains & Sue Cie - California Nites (When The World Was Our Friend)

[Boulder]

Hi Leak,

did you add AssumeFrameBased() to KernelBob or is it still needed?

Thanks for the new version!

[Leak]

Originally posted by Boulder
Hi Leak,

did you add AssumeFrameBased() to KernelBob or is it still needed?

Thanks for the new version!

It's still needed - since a few people liked it that way, I left it like it was. So what's the general consensus in this matter? :confused:

np: Ricardo Villalobos - Temenarc 1 (Thé Au Harem D'Archimède)

[krieger2005]

Maybe this is not sooo interesting: I tried to build a mask from the Deinterlacing process. For those i set "map=true". I found, that while in KernelDeInt the white lines (which were shown, because "map=true" is set) has the Light-Value 255 they have the Value 235 in KernelBob.

[Leak]

Originally posted by krieger2005
Maybe this is not sooo interesting: I tried to build a mask from the Deinterlacing process. For those i set "map=true". I found, that while in KernelDeInt the white lines (which were shown, because "map=true" is set) has the Light-Value 255 they have the Value 235 in KernelBob.

That's strange - I just tried it with both a YV12 and a YUY2 clip and it was 235 with both KernelBob and KernelDeint according to AviSynth's levels histogram - since KernelBob just calls KernelDeint and the map is getting displayed in KernelDeint I find it hard to believe that there could be any difference...

You wouldn't happen to have a different KernelDeint DLL somewhere in your plugin dir? If you have both an old one and one of my versions, mine might only get used for KernelBob since that function is not in the old DLLs...

np: Gold Chains & Sue Cie - Multifear (When The World Was Our Friend)

[krieger2005]

You're right. I had in the plugin-Dir KernelDeint 1.5.1 and load in the script with "LoadPlugin" your new version. For me is it strage... Which Plugin were be loaded? Since the question is solved this story should end here...

But one question: Why is the Light-Value 235? Why not 255?

Thanks for your reply

[Leak]

Originally posted by krieger2005
But one question: Why is the Light-Value 235? Why not 255?

Mostly because KernelDeint 1.4.0 was using 235 so comparing both versions is easier with both using 235, and I guess 1.4.0 was using 235 because of this (http://www.avisynth.org/Limiter)...

Be warned thought that using map=true to get a mask is probably giving the slowest piece of code in the whole filter a workout it wasn't really made for, as I considered map=true to be just for debugging/tweaking, not for constant use - it's in pure C++... :)

np: Ricardo Villalobos - Serpentin (Thé Au Harem D'Archimède)

[iradic]

LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\decomb.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\KernelDeInt.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\RemoveGrainS.dll")

# SOURCE
mpeg2source("C:\temp\dgindex.d2v", idct=0)

trim(5028,5378)

# CROPPING
# produce green bar on the right
# crop(10,70,696,436)
crop(12,68,-12,-72)

# no green bar
# crop(0,0,-4,-0)
# crop(0,0,-0,-4)
# crop(0,0,-4,-4)
# crop(2,2,-2,-2)
# crop(0,68,-12,-72)
# crop(12,68,-4,-72)
# crop(12,68,-20,-72)

# DEINTERLACING (2)
KernelDeInt(order=1,sharp=true)

--------------------------
isnt this strange?

i thought values must be mod4 - but not all the time it seems :)
all above is without green bar with kerneldeint ver 1.40

my cpu is duron 700, os winme, avisynth 2.55, preview with vdubmod 1.5.4.1
source is 720x576

also i noticed that kdeint doesnt handle horizontal lines very good - they are flickering - much better result i get with fielddeinterlace(blend=true) ... is there any way to get this with kerneldeint?

thanks bye

[Leak]

Originally posted by iradic
isnt this strange?

Uh - what is strange? You mean you're getting a green bar on the right hand side?

I can't test it here currently, but I assume adding a "align=true" (which I always use) to the crop will fix it - still, I guess there's something that should be fixed in my code; I'll have a look at it when I can find the time.

also i noticed that kdeint doesnt handle horizontal lines very good - they are flickering - much better result i get with fielddeinterlace(blend=true) ... is there any way to get this with kerneldeint?

Well, you could scale the kerneldeinterlaced clip to half height and back to get the same blurriness and loss of image information that FieldDeinterlace(blend=true) incurs, but that's up to you... :)

On the other hand, you could try increasing the threshold until the line stops flickering, but that might cause artifacts if the threshold is too high.

[Guest]

Is this filter still called KernelDeint? If so, you've hijacked my development!

I respectfully request that it be renamed so I can continue developing my own filter without massive confusion being created.

How about KernelDeintMMX? Or the earlier suggested FastKernelDeint? Or even LeakDeint?

Thank you.

[Leak]

Originally posted by neuron2
Is this filter still called KernelDeint? If so, you've hijacked my development!

Fine with me, if you want it.

I don't think I'll be doing much further development on it, now that I'm working with Tritical on optimizing his TIVTC filter, but I'll put up a new, renamed compile tomorrow - it's too late here for doing anything like this now... *yawns*

EDIT due to mid-air collision with your edit: I guess LeakKernelDeint would be alright, then?

I respectfully request that it be renamed so I can continue developing my own filter without massive confusion being created.

Will do. What developments do you have in mind for it, if I may ask?

BTW, I never heard anything from you about this even though my email address is available through my forum.

Well, I sent you a PM on your forum, and thought that would be enough. I assume you mean it would've been forwarded to your email address? (As I don't remember seeing that image with your email address on your main site before...)

Of course, now that I check my PM folders there (only ever used PMs there this one time) - that message is still rolling around in my Outbox; does that mean it never got sent? o_O; (But there's no send button to be found there, so is that a draft, or a sent message, or what?)

Sorry 'bout that, but I never had this kind of problem with PMs on this forum, and I really didn't think it could not go through... :(

Anyway, goodnight for now - I'm almost falling asleep at the keyboard. :/

np: Bill Laswell et al - Death Tools (Charged Live)

[Guest]

Originally posted by Leak
Fine with me, if you want it.Yes, I want that. Thank you.

EDIT due to mid-air collision with your edit: I guess LeakKernelDeint would be alright, then? Yes, of course.

Will do. What developments do you have in mind for it, if I may ask?Better kernels and low-level optimization. Also, native bobbing.

I haven't checked my PMs for a while. Sorry about that.

Thank you for your understanding about this. Your work and contributions to the community are valuable and greatly appreciated.

[Leak]

Originally posted by neuron2
Better kernels and low-level optimization. Also, native bobbing.

I haven't checked my PMs for a while. Sorry about that.

Thank you for your understanding about this. Your work and contributions to the community are valuable and greatly appreciated.

Well, you could do me a favour and reuse some of my MMX code - the speedup it incurs was why I did all this in the first place... :D

Also, I assume that this part of your sharp, non-two-way kernel calculation

+ 0.031*((int)prvp4p[x] + (int)prvp4p[x]);

probably should have been

+ 0.031*((int)prvp4p[x] + (int)prvp4n[x]);

as otherwise it'd be a very inefficient way of multiplying by 2...

Okay, I'm really off to bed now - I'll build and upload a new version sometime tomorrow afternoon...

np: Bill Laswell et al - Overloaded Lila (Charged Live)

[Guest]

Hi Leak,

Thank you for your bug report. As Urkle would say, did *I* do that? ;)

I'll be happy to use your low-level code where possible with full attribution of course. Thank you for offering it.

Sleep well.

[Leak]

Ok, here goes:

LeakKernelDeint 1.5.3 (with source) (http://leak.no-ip.org/AviSynth/LeakKernelDeint/LeakKernelDeint_1.5.3.zip)

I've renamed the DLL and the plugin to LeakKernelDeint (and LeakKernelBob, respectively) and added an implicit call to AssumeFrameBased at the end of LeakKernelBob.

np: Pan Sonic - Painovoima / Gravity (Kesto (234.48:4) (Disc 1))

[Guest]

Thank you, Leak, for your quick resolution. Now I know you have class in addition to style.

[Leak]

Originally posted by neuron2
Thank you, Leak, for your quick resolution. Now I know you have class in addition to style.

Hey, no problem - I guess it boils down to a case of mutual miscommunication, or something like that... :)

np: Panasonic - Vapina (Kulma)

[Guest]

Actually, lack of communication, all on my side. You had sent me a PM while I was playing hooky. All that code duplication, do you think that complicates further evolution?

This is the reason I seldom do low-level optimizations. The next generation of faster PCs usually does a much better job anyway. :)

[Leak]

Originally posted by neuron2
All that code duplication, do you think that complicates further evolution?

If I understand your right and you mean the code duplication between the C and MMX code - that's why I broke it up into several functions that can be swapped out individually. That way, unless you throw away the whole concept you still only have to change parts and not the whole thing - and of course you'd only make MMX versions of the parts that use the most CPU time; I had a phase in my high school days once where I'd program everything in assembler (when I was still running DOS), but I got better... ;)

This is the reason I seldom do low-level optimizations. The next generation of faster PCs usually does a much better job anyway. :)

Well, I doubt that PCs will be getting faster by just cranking up the MHz like they did in the past, and multi-core CPUs are still some way off (Hyperthreading is nice, but it hardly makes for a big speed increase) - so using the SIMD instructions current CPUs sport is still the "fastest" way to speed things up.

Also, coding took me maybe 1-2 weeks on and off, while CPU/system manufacturers take years between CPU generations - what good does me a new system do that might be twice as fast as my current one if it's still a year off? :D

The MMX instruction set (or, if Intel and MS are to be believed, at least SSE) will be with us for some time, so if the CPUs still get faster so should the optimized code - which of course will need an update for x64, but that's easy if you don't recode everything to make use of the extra registers and features...

At least that's my .02 € on this matter... :)

np: Panasonic - Moottori (Kulma)

[len0x]

What's the difference between those versions? Only naming?

[Leak]

Originally posted by len0x
What's the difference between those versions? Only naming?

I've renamed the DLL and the plugin to LeakKernelDeint (and LeakKernelBob, respectively) and added an implicit call to AssumeFrameBased at the end of LeakKernelBob.

Nothing earth shattering, though. :)

(I've also added a call to set the cache hints to a range of 1 so AviSynth doesn't cache frames from the input clip like mad, but I doubt that'll have much of a noticeable impact.)

By the way - am I the only one that thinks SetCacheHints could use a bit of documentation from someone who's fully grasped it? I hope I've understood it's purpose right, but I'm still wary about that...

np: Pan Sonic - Vähentajä / Diminisher (Kesto (234.48:4) (Disc 1))

[Boulder]

Leak,

there seems to be something wrong with LeakKernelBob in v1.5.3 performance-wise. I just created a script with the line LeakKernelBob(order=1,sharp=true,threshold=7) in it and it was dead slow. When I set threshold to 0 it was fast again. This doesn't happen with v1.5.2. I didn't try a simple KernelDeint.

I'm using the latest CVS alpha Avisynth, maybe it's the cache hints that causes the issue?

[Leak]

Originally posted by Boulder
I'm using the latest CVS alpha Avisynth, maybe it's the cache hints that causes the issue?

Whoops.

Come to think of it, I've most probably set the cache's range exactly right for the deinterlacing itself, but I guess it's to small for the motion mask, since this needs to go back one extra frame which now always falls out of the cache... *slaps himself*

I'll fix this as soon as I get home and as soon as the cable modem I should get installed today works... :)

Note to self: testing, testing and more testing.

[Leak]

LeakKernelDeint 1.5.4 (with source) (http://leak.no-ip.org/AviSynth/LeakKernelDeint/LeakKernelDeint_1.5.4.zip)

As suspected, the cache range I used in LeakKernelBob was off by one which was slowing things down considerably; now it should be as fast as ever... :)

np: Zorn - The City's Collapsing (But Not Tonight) (The City's Collapsing (But Not Tonight))

[Boulder]

Thanks:)

[Guest]

Originally posted by Leak
LeakKernelDeint 1.5.4 (with source) (http://gast3.ssw.uni-linz.ac.at/~kp/AviSynth/LeakKernelDeint/LeakKernelDeint_1.5.4.zip) The link is dead. How can I get this, please?

[guldukat]

Originally posted by neuron2
The link is dead. How can I get this, please?


http://www-e.uni-magdeburg.de/drobek/LeakKernelDeint_1.5.4.zip

[Guest]

Now that's what I call service. Thank you!

[guldukat]

Originally posted by neuron2
Now that's what I call service. Thank you!

scharfi made me do it ;)

[Guest]

Do you mean scharfis_brain, my hero?

[guldukat]

Originally posted by neuron2
Do you mean scharfis_brain, my hero?

of course! or do you know someone else who also calls himself scharfi? :confused: :D

[scharfis_brain]

Jep. it was me who also trapped into this, too.
So I asked the cardassian leader whether he owns this file.

[Leak]

Originally posted by neuron2
The link is dead. How can I get this, please?

Well, all I can say is "currently works for me" (from work, which isn't at the uni) - if this happens again, try clicking on my WWW-button and see if that works.

Our uni was offline for a few hours on friday, maybe this was another case of it? :confused:

[Guest]

The link works for me now, so it was just "out to lunch" for a while.

[Katie Boundary]

After several months of distractions, I finally got around to giving this a spin. I unfortunately wasn't able to find a combination of parameters that got rid of both shimmering and residual interlacing. Trying to balance the two only resulted in getting a lot of both. YADIF with spatial check gives superior results in all cases.

[romangal]

When Cropping not mod4, just before LeakBob, for example: Crop(8,0,-10,0) a Green border appears in the right of the image. "Align=true" has no effect and does not help. Im wonder if Leak could update LeakKernelBob to remove such a problem. Anyway it could be great! This is the only bug i've noticed.

[StainlessS]

Have you tried forceCPU=1. [C only]

[romangal]

Have you tried forceCPU=1. [C only]
Just Tried. It seems like it is ok now with using only C optimization. Thank you!:cool: