[GEM-dev] Re: threads in pix_video in GEM

[IOhannes m zmoelnig]

chaser wrote:
> hi iohannes

hi sergio.
i am sending this email to gem-dev too, so if you want to answer please
exclude gem-dev from the recipients or subscribe to this list (better, imho)

anyhow

> here sergio. i'm working with lluis gomez building a big patch using GEM
> for a dance spectacle that combines in real time 4 live streaming videos
> from different places in a virtual 3d environment.
> 
> we have a little question about the pix_video object:
> 
> for testing our patches we have been using mov files through the
> pix_film object. pix_film creates a new thread for each new video, so we
> get advantages of our multi processor workstation. (20 video sources
> mapped in about 300 faces with the SMP kernel at about 80%) :)
> 
> then we changed to pix_video to capture analog video sources and we
> realize, that the pthreads is not available for this object, so all
> capture process is done by the same processor..
> 
> we would like to know if you think there is any reason for not
> implementing pthreads in pix_video.
> i'm not a programmer at all and maybe i'm talking about out of order
> things :/,...
> but if there's not specific problem to implement pthreads in this object
> we could try to find someone to write some code for that.

hmm, i guess you are on linux (since lluis is involved ;-))

so: both [pix_film] and [pix_video] are using threads (if available),
though in a somewhat different manner.
pix_film: creates a thread in the main object and uses the thread to
grab the images from the decoder-classes.
pix_video: each decoder class handles autonomously whether it uses
threads or not. the main object does know nothing about threads.

why: i don't know, most likely historical reasons;
[pix_videoLinux] has used threads for a long time, when it was converted
to [pix_video] + videoV4L the threading code went into the videoV4L
class (to make migration simplest for all platforms)
[pix_film] has not used threads for a very long time; i added it last
year since a project was depending on the performance gain we got from
threads; since i was not sure which decoder class i was actually going
to use, i decided to write the code only once and put it into the
[pix_film] class (instead of filmQT4L and filmAVIPLAY and ...)


so as a conclusion:
[pix_video] should use threads with all grabber-classes on linux (v4l,
v4l2, dv4l); these classes won't even compile without pthreads (as
opposed to [pix_film] where the pthread-code is really optional)
i wonder what makes you think it doesn't.


> 
> thanks in advance
> gem runs really good ;)


good to hear.

mf.dar
IOhannes