> > I'm writing a post plugin for xine.. It's a picture in picture
> > plugin. It takes two video input and merge them single frames..
> > But.. i'm having problems coding it.. i think that they are related
> > to multithreading.. can someone try it and tell me if i'm right ?
> problem related to multithreading fixed! i hope.. Second version is
> online.. it's quite slow on my system(k7 550) but this is a
Just looked through your code briefly and I would like to make two
comments. Maybe these thoughts are wrong, because I didn't look close
enough, but maybe some of it is helpful:
* line 54f: do not use static global variables in xine plugins!
xine plugins can be instantiated multiple times, so any data which
is private to each individual instance must be dynamically allocated.
It would be best to include these variables in post_mosaico_out_t.
* You have two video inputs, but you use only one set of intercept
functions. While this might work, I think it does not in your case.
What happens is that the frames from both video inputs will reach
the same mosaico_draw() function. There you determine, from which
input the frame actually came by looking at the stream pointer that
was handed in, comparing it with the global streams list in xine_t.
You cannot do this, because you cannot assume, that the first stream
in your local post plugin context is also the first stream in the
global list. In fact, you cannot even assume that the stream whose
pointer has been handed in actually created the frame you got.
(The frame might have been generated by another post plugin.)
The correct solution here would be to use two intercept functions
for mosaico_get_frame(), one for each input, to be able to assign
different draw() functions to the frames of each input.
* The locking you require for your multistream problems is right.
When your plugin has more than one input, different streams can
be connected to each input and therefore different threads are
involved. When you use the above approach of separate draw() functions
for each input, you have a very clear border of the thread contexts:
Both draw() functions can be called simultaneously, but neither one
can be re-entered. So you only have to lock the common data they work
on, which is I guess the target frame.
Nice work of you so far. Thanks for the contribution.
panic("bad_user_access_length executed (not cool, dude)");