amDCT "adaptive multifunction DCT", deblock, smooth, sharpen, range expansion filter.

[jconklin]

Treaties Of Warp. I agree the "Horrible anomalies" really are are horrible.
Selur. Thanks for the side note about 'brightStart=205' making the artifacts disappear.

The problem is that I assumed that the video to be processed would be in the range of 16-235.
Given that I have thought about using amDCT() to clean and modify masks, the 16-235 range assumption is really embarrassing.
A quick workaround until I fix the code is to do the following

temp = orig.levels(0,1,255,16,235)
outTemp = temp.amDCT(...)
out = outTemp.levels(16,1,235,0,255)

This workaround is not as "accurate" as the fix will be.


Treaties Of Warp. I will start testing long runs on a 1920x1080 source and with luck reproduce your error.
It sounds like a memory leak.

[jconklin]

Bug Fix update.

Spent 2 weeks fixing a bad case of software rot.
The build system "Visual Studio" would not build.
I proved to myself that it was Visual Studio by trying several different versions of my shipped code which contained the build system for that version. None of them still worked.
Almost certainly some update to Visual Studio was to blame.

Rebuilt the build system.

Spent 1 week to find the cause and Fix the Horrible anomalies.

It turns out that in 1 place the data returned from the DctLoop routines was stored into an 8 bit value.

If you are just doing smoothing this works fine since the brightest and darkest pixels move toward the mean.
On the other hand range expansion and sharpening can move pixel values toward the extreme.
It never showed up in my testing since I had only tested sources with a range of 16 to 235.
It turns out that provided just enough headroom so the pixel values did not overflow.

Treaties Of Warp. Thank You for reporting the HORRIBLE anomalies and for providing a clip that would produce the problem. I would not have discovered the bug just using my testing.

Selur Thanks for noting that the artifacts disappear when removing 'brightStart=205'. It helped me get to the answer quicker.

Fixed the Horrible anomalies. Download the new version amDCT_v1.2Testing.zip from http://sites.google.com/site/amdctfilter

Now I begin on the memory problems. amDCT() is a memory hog as you can see from the following numbers.
A 1080p source frame is 1920x1080 pixels. Internally the frame has an 8 byte border surrounding the source frame.
Internally a 1080p frame uses 2,121,855 bytes or around 2 megabytes.
Depending on the number of cpus, specified by the ncpu argument, there are up to 4, 16 bit per pixel frames that are used to store the intermediate results of the DCT processing done on the frame.

There are currently 14 frame buffers allocated for things like the smooth buffer, the range expand buffer, the destination buffer, buffers for finding boundaries etc.
By the time you add it all up, amDCT mallocs and frees around 30 million bytes of data for each frame processed. Some of those buffers are used to try out ideas for improving amDCT.


I will try using loop() to feed the same clip to amDCT() forever.
If I can't get loop() to work I will build a very small front end that continually calls amDCT with the same frame.
This will give me a testbed to find any memory leaks.

When version 2.0 is done any frame buffers not used will be removed from the code.

[ChaosKing]

My 16gb ram is laughing at 28mb.

And thank you for the update :-)

[Lirk]

Is there x64 version?

[jconklin]

Other, Treaties Of Warp, and anyone else having memory problems or crashes using amDCT
I have posted a new version of amDCT at https://sites.google.com/site/amdctfilter/
The new file is amDCT_v1.3_Testing.zip

The problem sounds like a memory leak. Lets stress test it.
The problem sounds like a memory leak. Lets stress test it.

I ran a 1080P .avi video in a loop where each frame was processed 700 times.
Version1.2_Testing ran for 7 days with no errors. The max memory usage was stable around 1,120 MB. Reported by Task Manager for VirtualDub.

While this was running I dug into my memory management code, in Memory.c, carefully matching every malloc with its free.
It is NOT the first time I have done this exercise and almost certainly won't be the last.

What I discovered was a buffer was being freed in one section of code and then also being freed in the calling routine.
I don't know why this did not always crash.

I fixed the code and am currently running another 7 day test.
Then a series of long tests at different resolutions.

There is a new version amDCT_v1.3_Testing.zip that fixes freeing the same memory twice.

Please try it with a script that broke the v1.2 version of amDCT with version v1.3

If the new version doesn't fix the crashes please let me know.

[Selur]

I like the filter, any plans for a Vapoursynth version?

[jlpsvk]

is there 64bit version?