Multi-thread in Virtualdub filter

[jpsdr]

Is there someone here who have succefully be able to internaly multi-thread a filter.
I encounter a behavior i can't explain.
Everything works perfectly fine, while i'm not configuring the filter a second time. After, it's the end of the world.
So, if anyone have been succefull on it, i'm taking any information !

[shekh]

By internally multi-thread you mean create your own threads, and divide "RunProc" between them?
In that case I dont understand why do you need to configure the filter a second time, and what do you mean by that.
I better look at the source code

In the mod I have intent to enable filter multithreading, so far it worked well for "convert format" filter.

[jpsdr]

Basicaly, in StartProc i create a pool of thread, this pool is destroyed in EndProc.
RunProc starts several threads, each one working on a part of image.

You can get the code here (http://jpsdr.free.fr/XBMC/AutoYUY2.7z) if you want to look at it.
When you choose the filter, configure it for the 1rst time, and put it on the filter chain, everything works fine. But, if you go back on the filter chain, and configure it again, it's the end of the world.

As you can see, whole code are commented, because i've made a whole bunch of tests, without succes.

Now, if you want to build the filter, get the whole (because this filter is only a part of a bigger thing) pack on my github page here (https://github.com/jpsdr/Filtres_JPSDR). If you don't have github, i think you can get the source code on the page of the release. Once you have the whole thing, replace the files in the AutoYUY2 directory with the ones from the other link.

[shekh]

That is damn big code but I think the problem is here:
you must implement copy constructor
JPSDR_AutoYUY2(const JPSDR_AutoYUY2& a){...
It is used to make a copy of filter instance.
The problem is when you do not implement it, the default one will simply copy all variables
for example for interlaced_tab_U this will lead to double freeing memory or bad pointer access, same with thread handles etc.

These copy instances are created when you invoke filters dialog (probably for some legacy reason).

Also I would implement destructor and default constructor and do nothing within Init() except maybe check host version.

p.s.
I was able to compile and repeat the bug.
The first error is because MT_Data_Thread.pClass points to wrong (deleted) instance.

[jpsdr]

Thanks for this, it helps me a lot.

[jpsdr]

With both the informations you provided (talking about the copy constructor and fact that pClass was deleted), fix was just to move initialization of pClass in Startproc, at the same times the pool thread is created, instead of Init. Doing, as Phareon said in his SDK how it should be done, meaning all allocating in Startproc (and deallocating in Endproc), make things how, and prevent me the need to create the copy constructor, keeping standard method being enough in that case.
Nevertheless, :thanks: again ! ;)

[shekh]

Great!
The rule of allocating everything in Startproc does not work well if the filter has nontrivial internal state (example: "logo"). And also not optimal, as start/stop is quite frequent. I wish Copyproc was not used at all, freeing from all this cloning hell.