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
hmm, i guess you are on linux (since lluis is involved ;-))
yes
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.
so.. everything seems ok. perhaps our problem is not pthread related then..
if you have more spare time i can try to describe our scenario:
we have here a dual xeon HT workstation with an smp kernel. for linux that means 2 cpus disabling hyperthreading.
in practice when we create a new pix_film object, the system increase its cpu load a little, and for each new pix_film, a little more even to reach the 100% load for all cpus.
our problem is that, when we move to use pix_video with two firewire cards, only one cpu is used for both dv captures, so the total system load is 50% (about 25% for each dv capture in gem x 2), what means that only one cpu is working.
in this situation, all new separators we create to multiply each dv signal to map new primitives, makes the patch to run more and more slow, as all the dependent process fo the dv capture remains in the first cpu that is loaded at 100% while the second is at 0%.
it seems it would be good, if each dv capure main process could run in a different cpu, as we could have 50% of each cpu free to multiply videos and process other things..
thanks in advance gem runs really good ;)
good to hear.
mf.dar IOhannes