Convolution3D

[Sigmatador]

Tested on matrix:
MAM(Convolution3d(1,4,8,4,8,3,0),Convolution3d(0,8,8,8,8,3,0))
Very good results, very detailled (just the faces have little smoothing, very little) and more compressible

But tested on the planet of the apes --> very very ugly with the skin face of the apes (smoothissimo ^^ specialy the slaves' seller)
i used MAM(Convolution3d(1,2,4,2,4,3,0),Convolution3d(0,8,8,8,8,3,0))
then it seems good but less compressible

[vlad59]

@Matter, ohliuv and TheReal

I'm afraid I've none of this hard to compress DVD to make test.
I'll watch some DVD tomorrow but not for the story, only looking for noise or grain ;) ;)

I think I'll release the v1.0 of Convolution3d tomorrow : the biggest change will be some buffering so you can gain some speed or even more speed if don't care about some ghosting. Dividee's bug report will also be solved.

Let's sleep now .... :)

[MaTTeR]

vlad59,

Speed isn't an issue at all for me, quality comes first. Would it be possible to turn the buffer off/on with a C3D argument? I'm not a coder so just thought I'd ask;)

My SPR testing is just starting so I expect to post my thoughts and results later this weekend. Thx again for the nice work.

Edit: Sleep? Whats that?:)

[vlad59]

Originally posted by MaTTeR
vlad59,

Speed isn't an issue at all for me, quality comes first. Would it be possible to turn the buffer off/on with a C3D argument? I'm not a coder so just thought I'd ask;)

Edit: Sleep? Whats that?:)

Don't be afraid I have the bad (or good) habit to make everything tweakable so you'll be able to use/not use the buffering.

Sleep, Huuuum, Sleep, don't tell me I'll remember ;) ;)

[iago]

Originally posted by vlad59
I think I'll release the v1.0 of Convolution3d tomorrow : the biggest change will be some buffering so you can gain some speed or even more speed if don't care about some ghosting.Good news vlad59, looking forward to try it ;).

kindest regards,
iago

[Shayne]

Great filter play with it constantly. Maybe you could also update the readme a little in the next release with a little more detail on what the arguments do, max min .................

Not pushn do as u will

Thankz for the toy

[vlad59]

@Shayne

Yes, I'll try to update the readme (it's already done for some part like tresholds).

@all

Sorry but next version of C3d will be a little late. I found a new way to use my buffers to gain even more speed so you will have to wait ;)
I'll also look for some docs about pthread lib to maybe add SMP support (it will take some time (I can be dumb sometimes) so please don't rush me).

[MaTTeR]

Originally posted by vlad59

I'll also look for some docs about pthread lib to maybe add SMP support (it will take some time (I can be dumb sometimes) so please don't rush me).

SMP support...oh that would be so sweeeeet:) I'll be more than happy to help test it for ya.

[drizztcanrender]

Guys first of all i would like to say i'm sorry to the guys testing this filter and vlad59.I had promised to make whole movie encoding tests with conv3d but unfortunately my pc failed on me.After struggling with it for about two weeks now it's going to the shop for a total fix :(
That damn power supply screwd everything up then.
I just tested conv3d on my sister's pc and i found that these values give very good results inm an animation(not anime) movie i've been trying to encode for so long(applied before resizing):

convolution3d(1,4,6,3,5,2.8,0)

No artifacts whatsoever and better looking picture i could say.
Sorry again and thanks for the great filter vlad59 :)

[WarpEnterprises]

I have made a test on interlaced video captured from Hi8 and the results are REALLY IMPRESSING (using parameters 0, 8,10, 8,10, 3,0).
Is it correct to use

SeparateFields()
Convolution3d(0, 8,10, 8,10, 3,0)
Weave()

on Interlaced material? (I'm thinking of the temporal direction of the convolution matrix).

[vlad59]

@WarpEnterprises

Yes I think it's correct.
I remember a month ago, I proposed the same script to someone (I don't remember who). But his source had problem because of displacement between odd and even fields (frames) : odd frames were one line higher than even frames. So he was obliged to use :

SeparateFields()
SelectOdd.Convolution3d(..)
SelectEven.Convolution3d(..)


But with pure interlaced material, your script should work without any problem (of course if your field order is good).

[iago]

@vlad59

First of all, recently I've been trying convolution3d(0,4,4,4,4,3,0) to increase compressibility in some of my test encodes, with pretty good results for regular/normal movies, where ColorYUY2(Levels="TV->PC") is also used.
(Please take a look at XviD forum, "lumi masking" thread.)

Second, I have a question: I'm considering to use convolution3d(0,4,4,4,4,3,0) with a hybrid source (Baraka - NTSC1) using the following script:

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decomb.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\convolution3d.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\colorYUY2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\SimpleResize.dll")
mpeg2source("C:\BARAKA\BARAKA.d2v")
crop(4,4,704,472)
Telecide()
Decimate(mode=1,threshold=50)
convolution3d(0,4,4,4,4,3,0)
ColorYUY2(Levels="TV->PC")
SimpleResize(512,384)

What's your opinion please? Considering the long encoding time it will take, I just would like to learn beforehand if convolution3d with decomb using the above parameters for a hybrid source would cause any problems ;).

Thanks a lot,
iago

(P.S.: -Off/Topic- Regarding the lanczos3 resize tests; it's no problem man, glad they've provided some help to you! ;))

[Dark-Cracker]

it's perhaps a silly comments but i am not sure your filters are in the right order, it seems to me :

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decomb.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\convolution3d.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\colorYUY2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\SimpleResize.dll")
mpeg2source("C:\BARAKA\BARAKA.d2v")
Telecide()
Decimate(mode=1,threshold=50)
crop(4,4,704,472)
SimpleResize(512,384)
ColorYUY2(Levels="TV->PC")
convolution3d(0,4,4,4,4,3,0)

will be better because decomb need the order of the field to deinterlace or ivtc a frame. and i think putting the color and convolution after the resize will speed the encode because less the frame size (height & width) was important and more speed were the color & convolution processing.
i think i was right but perhaps can confirm this ?

PS :u could use
Telecide(blend=false)
Decimate(guide=1,threshold=50)
to have a better result with decomb

PS2: sorry my english sux.

[iago]

@Dark-Cracker

Thanks a lot for your reply. Since I've mostly dealed with progressive PAL sources so far, IVTC still seems a mystery to me ;).

best regards,
iago

[vlad59]

@iago

Unfortunately IVTC is also a mystery for me (thanks to PAL).
But in theory your settings must be correct.
The most important thing is to use Convolution3d after Telecide and Decimate to avoid blurring the fields.

I don't know what ColorYUY2 exactly do ???
Is it only usefull to cap luma between 16 and 240 (IIRC) ??

Another thing you should try is to lower a little the temporal influence to 2.8 or 2.6 : this will lower a little (only a little) the compressibility but you'll gain speed.

I had a look (very fast) to the Xvid thread : lumi masking. You found some interesting results. I'll have a closer look this afternoon.

@Dark Cracker

I don't think cropping before using telecide is a bad thing.
In addition Iago is using even numbers so there shouldn't be any problem when cropping first (and he'll gain some speed).

I got your PM. I'll check that this weekend.

[iago]

@vlad59

Thanks a lot for your reply. If cropping before telecide (with the correct numbers) wouldn't cause a problem, I'd prefer that.

ColorYUY2 is being discussed for a while in lumi masking thread in detail, which is offered mainly as a solution for blocks in dark/black areas, though also darkens the movie in general considerably.

And OK, I'll try 2.8 and 2.6 for temporal influence too ;).

kindest regards,
iago


Also, regarding dark-cracker's reply:

Telecide()
Decimate(mode=1,threshold=50) - for hybrid sources

or

Telecide(blend=false)
Decimate(guide=1,threshold=50) - as Dark-Cracker suggested ???

(Vdub gives the error message that "decimate" does not have a named argument "guide")

Thanks,
iago

[meleth]

Telecide(guide=1) is where it belongs :P

[iago]

Well, thanks again ;).

As a result of all these, now I'm going with:

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decomb.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\convolution3d.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\colorYUY2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\SimpleResize.dll")
mpeg2source("C:\BARAKA\BARAKA.d2v")
crop(4,4,704,472)
Telecide()
Decimate(mode=1,threshold=50)
convolution3d(0,4,4,4,4,2.8,0)
ColorYUY2(Levels="TV->PC")
SimpleResize(512,384)

which is almost non-modified, except trying 2.8 instead of 3 for temporal influence in convolution3d ;)...

best regards,
iago

[vlad59]

@all

Sorry for being late but sometimes life is not fair (or I'm not m
smart enought ;) ) :

- I had added some buffering to Convolution3D (it took me 2 or 3 hours of coding + 1 hour to test) -> the results are disapointing : yes I gain 2 or 3 fps but it produce little artefacts at scene change. As I'm looking for quality first, this version goes directly to bin.

- I was trying to add some threading in C3D : it spend 2 hours trying to link until I think about reading the manual......

I must be too tired or too dumb this weekend. :( :(


sorry for this off-topic post, but I feel better now.

[Metalazzo]

ganbate vlad59 ;)

[jarthel]

has anyone tried this filter with anime DVDs? both noisy and good sources? feedback please. :)

Thanks :)

Jayel

[iago]

@vlad59 (and all),

A small test on the *possibility* of using convolution3d(0,4,4,4,4,3,0) with normal movies (a compressibility and visuals test):

* Matrix Chapter 3 (very dark content) / 640*272
* Encoding parameters (for all tests):
XviD 2-pass / Koepi's 04092002-1 build and Statsreader 1.7 / externalCC / 6.UltraHigh / MPEG-MPEG / No Lumi / target size: 13650kb ~ 625 kBit/s
* ColorYUY2 filter is also applied in all tests

Compressibility (first pass sizes):
-----------------------------------
Lanczos3Resize -> 29 mb
SimpleResize -> 27 mb
BilinearResize -> 24 mb
Lanczos3Resize with Convolution3d(0,4,4,4,4,3,0) -> 21 mb

Visuals:
--------
PNG images (zipped in pairs) are attached for visual comparison, but unfortunately in two posts due to filesize restriction. Sorry.

regards,
iago

[iago]

BilinearResize and Lanczos3Resize with convolution3d(0,4,4,4,4,3,0) images:

[iago]

Lanczos3Resize and SimpleResize images:

[Metalazzo]

it looks good :devil:

damn i must try with the game :)

[MaTTeR]

iago and vlad,

So sorry for the delay on my testing. Unfortunately I've not got any hard evidence on very noise sources such as SPR yet due to a lack of time. I'm still looking for a generic setting that works for most DVD films. Right now I'm starting to like Convolution3D(1,4,5,3,4,2.7,0) for general films with moderate mosquito noise. Movies with heavy noise(eg. SPR or Inferno) seem to respond well to (1,5,8,8,8,3,0) though I still need to do more tests to be conclusive. Compressibility has increased about 10-13% on average using C3D:D

At the moment, I'm averaging about 12-15FPS with Lanczos reszing at 640 resolution. If multi-threading is added this will be great news. Keep up the good work Vlad!

Dual AMD XP 1600s @ 138FSB
512MB DDR RAM (agressively tweaked)
WinXP (SP1)

[vlad59]

@MaTTer

SMP is less easy than I first thought (my first test was 12 times slower !!!!!!).
But anyway it's a good challenge. I'll carry on.

When I encoded Excalibur I found that using Matrix 1 produce too much blurring (at least for my eyes) so I used :
Convolution3D(0,4,4,4,4,2.5,0)
But I used BilinearResize so maybe
Little Blur + Little Blur = Too much blur

I really need to test Lanczos3 more seriously.

[MaTTeR]

Vlad,

In regards to the multi-threaded coding, I believe fu2k is pretty knowledgable in this field. He is the author of FairUse and might be able to offer some guidance here if his time allows. A few months ago I had a look at the OpenMP docs but not being a coder, I was completely overwhelmed:D

For your testing, Bilinear might have been the blurry culprit. I only use it for encoding credits personally. Perhaps using SimpleResize or Lanczos would have kept it a little sharper.

[meleth]

Well the best thing would be if avisynth supported smp and handled all that transparently to the filter.

Infact what would be even better is distributed encoding. Most rendering programs support this and being able to distribute the encoding over a network would just rock. Ofcourse this would have to be done on the nandub side and not avisynth.

[int 21h]

Originally posted by meleth
Well the best thing would be if avisynth supported smp and handled all that transparently to the filter.

Infact what would be even better is distributed encoding. Most rendering programs support this and being able to distribute the encoding over a network would just rock. Ofcourse this would have to be done on the nandub side and not avisynth.

No.. this would have to be done on the codec side, not the encoder side. Since the codec is doing all of the calculations, not the encoder.

[MaTTeR]

Int 21h is right which is all the more reason for me to use XviD besides it's other obvious benefits;)

Is AVS multithreaded? I assume it is but how much I'm not sure. Multi-threaded filters should help speed a bit. Right now running C3D, my CPU usage is averaging 60% where as when running without filters both CPUs will average around 90-95%. Use to be only about 3 of us dualie users on this board a few years ago but now I see several people...this is a good thing.

[trbarry]

I could be very wrong here but I think Avisynth is not multi-threaded but Virtualdub splits off the encoding and decoding into 2 threads. So Avisynth would be in the decoding thread and Xvid the encoding. But if this is true and they are fairly balanced then it still gives a 2 processor advantage.

- Tom

[kilg0r3]

i understand that there is no download page for this filter so i humbly ask permission to test this great software. :)

[Swede]

WarpEnterprises does host one version (as found by using a search ;)) : http://hellninjacommando.com/con3d/

[vlad59]

Originally posted by kilg0r3
i understand that there is no download page for this filter so i humbly ask permission to test this great software. :)


False ;) ;)

There is one (since Defiler kindly offered me some webspace) :
http://hellninjacommando.com/con3d/

EDIT : Swede was faster. But I confirm Defiler host me

[kilg0r3]

o.k. it shows :stupid:

anyway, thank you very much.

[meleth]

Originally posted by int 21h


No.. this would have to be done on the codec side, not the encoder side. Since the codec is doing all of the calculations, not the encoder.

Actually you are wrong, distributed renedering works by you having a master computer and a couple of rendering slaves. The master feeds the slaves with frames which they encode and then return the result which the master puts back where they belong.



Doing this in the codec, even if it might be possible would be highly ineffectual. Not to mention it would only work for just that codec. Frankly i don't even think it is possible to incorporate this into any codec and even if it was, it would be stupid.

[kilg0r3]

vidomi does that afaik

[Koepi]

In this dispatcher scenario you won't get any speed improvements in encoding (the case where one computer sends out the frames and collects the compressed images).

Usually you'll find 100mbit topologies as LANs.

So the disatcher sends out the uncompressed images for compression:

640x272x2 (16 bits for YUV colour space = 2 byte) = 348160 bytes per frame.

let's say, ideally you have no collisions etc, so you can use 7MB of bandwidth for encoding:

7340032 / 348160 ~= 21 fps.

This scenario doesn't include the stream backwards, delays, congestions,...

So with a single fast computer you achieve more speed than that.

I hope this helps,

regards,
Koepi

[meleth]

Well I do get around 20-25fps when i'm not using any filters. But when you are using heavy filtering the fps drops to around 5 so in those cases that would help speed up the encoding alot.

This is also how commercial rendering programs like lightwave etc. works. Unless they've changed it since the last time i used it. Had 1 alpha 500 and 2 alpha 533mhz as rendering slaves.

Ofcourse this was like hrm 4-5 years ago.

[ronnylov]

What you can do is to copy your source files to a secondary harddrive mounted in a HD-casette and put that one in your second computer (or copy it over the LAN if your'e encoding from a DVD rip that is not that big in filesize compared to raw capture) and encode the first half of the movie in one computer and the second half in the other computer from the local harddrives. After the encodings are completed you merge the 2 encoded parts into one file. But if you are doing 2-pass encoding and let's say the first half is low motion and the second part has action scenes then you would miss the bitrate allocation from the part of the movie encoded in the other computer.

It's better to encode one movie in the first computer and another one in the second computer at the same time.

Well I think this is starting to be off-topic now. Isn't this thread about the Convolution3D filter?

[bb]

Originally posted by meleth


Actually you are wrong, distributed renedering works by you having a master computer and a couple of rendering slaves. The master feeds the slaves with frames which they encode and then return the result which the master puts back where they belong.



Doing this in the codec, even if it might be possible would be highly ineffectual. Not to mention it would only work for just that codec. Frankly i don't even think it is possible to incorporate this into any codec and even if it was, it would be stupid.
You have to distinguish SMP (symmetric multiprocessing) on a single computer and distributed computing in a rendering farm. int 21h's statement is correct regarding SMP.

bb

[meleth]

Originally posted by bb

You have to distinguish SMP (symmetric multiprocessing) on a single computer and distributed computing in a rendering farm. int 21h's statement is correct regarding SMP.

bb

Yes but I were talking about distributed computing and not SMP. Sinc e he quoted me one can only assume that his answer was in response to distributed computing. So if anyone has to distinguish SMP and distributed computing it's him, not me.

[bb]

@meleth:
I just wanted to point out the difference in order to avoid confusion. I did not want to accuse anybody of anything. The "You" in my post was meant to be impersonal.

In fact your post referred to both, SMP and distributed computing. I guess that caused a misunderstanding, as I believe that int 21h knows very well what he's talking about.

bb

[meleth]

Originally posted by bb
@meleth:
I just wanted to point out the difference in order to avoid confusion. I did not want to accuse anybody of anything. The "You" in my post was meant to be impersonal.

In fact your post referred to both, SMP and distributed computing. I guess that caused a misunderstanding, as I believe that int 21h knows very well what he's talking about.

bb
True, but in order to fully use SMP it would have to be supported by both the codec and avisynth, since avisynth and not the codec handles all the filtering. Of course if either could do load balancing it would only be neccesary to fix one of them. And then it would be better if it was avisynth that handled it, as it would be codec independent.

[MaTTeR]

@meleth

Maybe you missed my post above but XviD is multi-threaded for SMP. The SMP build can be found on uManiac's page-
http://xvid.hopto.org/

I only know of a few people who have tested it as of yet so your more than welcome to help us;) It is alpha state software, so now your warned.

It certainly would be great to parallelize AVS for better effeciency on multi-CPU systems. I wish I could offer some suggestions but from a basic standpoint I've been told that ICL and/or M$VS offers very basic parallel compiling options. Has anyone attempted this yet? I might try to squeeze a few minutes in this weekend to see what happens.

[meleth]

@Matter:

Unfourtunally i don't own a dual cpu machine myself and the only multi threaded program i've ever done was in perl so that don't help much.

You must however think about ALOT more stuff when doing multithreaded stuff, you get race conditions really really easy.

[sh0dan]

SMP is not something that can be achieved by changing compiler options. It would have to be coded into AviSynth.

On the other hand it should be possible, by making Avisynth process several frames in parallel. So when the client requests frame x, CPU 0 generates frame x, and CPU 1 begins to generate x+1 (and so on).

The cache would have to be modified, so frames could be marked "in progress", when another CPU is already working on this frame. Not sure how this completely should be implemented. The cache will be the only thing linking the threads together.

But all filters would have to be thread-safe, which I don't think they all are by now.

[int 21h]

Originally posted by meleth


Actually you are wrong, distributed renedering works by you having a master computer and a couple of rendering slaves. The master feeds the slaves with frames which they encode and then return the result which the master puts back where they belong.



Doing this in the codec, even if it might be possible would be highly ineffectual. Not to mention it would only work for just that codec. Frankly i don't even think it is possible to incorporate this into any codec and even if it was, it would be stupid.

In Lightwave, with distributed rendering, you setup computational slaves that render raw scenes, they don't compress anything, then depending on your destination format (i.e. AVI, Graphics, etc) the rendered frame is sent back to the master computer to be stored in whatever format you choose. Rendering frames is somewhat less complex than compressing video (on the task-list side, not the pure mathematical computation side). When you're compressing video with a codec, there's always reference to previous frames (i.e. delta frames are calculated off of each other, even this is a rather simplistic view), however, when you're rendering video in a program such as Lightwave, only the current frame needs to be taken into account since the environment has already computated everything from the previous and future frames (motion vectors, etc.). So when you render a scene of animation on Lightwave or Cinema4d or any other distributed rendering environment, the data is generated in the rendering farm (the frames are rendered, objects are drawn, lights are mapped, etc), sent back to the master, which then takes that data and does whatever you specified with it. If you specified a XviD AVI for instance, the master would do all of the generation of the AVI from the frames already generated on the 'slave' machines.

In our application however, our frames aren't rendered. They are decompressed. This takes a fraction of the computational power that rendering a scene takes. So if you wanted to model an encoder this way, all of your 'slave' computers would be decoding Mpeg2, applying filtering (Decomb, C3D) and sending frames back to the 'master' computer for compression. It becomes quite apparent, that this would be inefficient towards our application, because if your specific filter needs to look ahead or behind in the queue of frames, the amount of data you begin to sling around becomes gargantuan.

The faux distributed encoding you are talking about, is already implemented in a program called Vidomi (http://www.vidomi.com). Vidomi can split up the encoding of two CD compression instances (the last time I inquired, it did not function on 1 CD encodes), encoding one CD on one machine, and another CD on the other machine. However, as ronnylov pointed out, its impossible to accurately distribute bits in a situation as this because the renderer or compressor in our case, is totally unaware of bits being used on one half of the movie. Therefore, to be a truly 'distributed' application, the codec itself has to be aware of all encoding taking place, so that it can include all bits used and unused in the bitrate curve scaling and allocation.

With all of this in mind...as Koepi pointed out, currently we are at the wall of diminished returns. To make a truly distributed environment, the codec and the decoding and rendering mechanism (Avisynth, and all its filters in this case) would have to be aware of other instances on your 'slave' machines, unless of course you meant 'decoding and rendering' and not 'encoding' in your original post, and wanted your master machine to do all of the actual compression.

SMP of course is a totally different animal, but some of the same principles apply. All of the basic groundwork for that is already done in XviD, it currently just needs to be refined and tested. SMP doesn't play a major role for most users currently, but with the release of 'Hyper-threading', multiple CPU emulation, whatever you want to call it (and whoever's marketing bullcrap you're listening to), that may change.

[meleth]

When you're compressing video with a codec, there's always reference to previous frames (i.e. delta frames are calculated off of each other, even this is a rather simplistic view)


You're right totally forgot about this.



The faux distributed encoding you are talking about, is already implemented in a program called Vidomi (http://www.vidomi.com). Vidomi can split up the encoding of two CD compression instances (the last time I inquired, it did not function on 1 CD encodes), encoding one CD on one machine, and another CD on the other machine.


This is nothing like what I am talking about. I am talking about blocks of frames being distributed to slaves that compress them and then send the compressed frames back to the master server. (I thought Vidomi was a player:P)