Hello,
I am working on a patch, in which I use a webcam as a motiondetector, to drive another video (AVI, DV). (Every detected motion forwards a frame of the movie playing in pix_movie). I want this patch to be playing fullscreen in an exhibition for two months, non-stop. The problem is that I am worried about the CPU load - it hovers above 90% in Task Manager. (OS=WinXP) My concern is that the computer will not hold out on that load for that long.
I had hoped to solve this by buying a new graphics card, which I thought would have taken over the processing load. I have been experimenting with the Asus n6200 256 MB (a Nvidia Geforce 6200 card) and the Hercules ati Radeon 9000 128 MB. I'm aware that my Mobo does not support 8X AGP bus speed, but since I am mainly looking for 2d acceleration I hoped it would be ok.
CPU utilization is still high. My questions:
- was I wrong in supposing that the GPU would take over processing tasks of
the CPU?
- what would be a realistic cpu load for 24 hours a day, 2 months?
- Does anyone on the list have experience with running fullscreen
gem-patches with specs such as pentium III, 800Mhz, 384 Mb, and do they have any pointers on how to optimize (such as using a different size video, codec, etc..?)
I am also working on another computer (faster pIV, 512MB etc, etc...). I noticed that playing a video in mediaplayer requires less than half the cpu load of playing it in pix-movie or pix-film.
- Can anyone explain why this is?
Looking forward to hear from you.
Klaas
windows XP, pIII 800Mhz, 384 MB, Abit VL 6 Mobo, Hercules ATI Radeon 9000 128Mb
Klaas,
I suspect that it will be the motion detection part of your patch that will be eating the CPU most. If the video input is only being used to detect motion and the live video is not being displayed then setting the camera to it's lowest resolution will be more than adequate and will drastically reduce the load on the CPU. Also decrease the number of frames per second being analysed for movement. The speed of the GPU will certainly not help you in this instance.
My "mution" project used motion detection with PD/PDP/PiDiP from 160x120 resolution webcam input at 15fps which gave very reliable results and produced a load of only 20-30% on a 600mhz machine (running Linux).
Of course, the codec of the file you are playing will also hit the CPU (again, not the GPU) but I am not the best person to advise about that.
Good luck,
Andrew.
On 6/8/06, klaas de Baas kdebaas@hotmail.com wrote:
Hello,
I am working on a patch, in which I use a webcam as a motiondetector, to drive another video (AVI, DV). (Every detected motion forwards a frame of the movie playing in pix_movie). I want this patch to be playing fullscreen in an exhibition for two months, non-stop. The problem is that I am worried about the CPU load - it hovers above 90% in Task Manager. (OS=WinXP) My concern is that the computer will not hold out on that load for that long.
I had hoped to solve this by buying a new graphics card, which I thought would have taken over the processing load. I have been experimenting with the Asus n6200 256 MB (a Nvidia Geforce 6200 card) and the Hercules ati Radeon 9000 128 MB. I'm aware that my Mobo does not support 8X AGP bus speed, but since I am mainly looking for 2d acceleration I hoped it would be ok.
CPU utilization is still high. My questions:
- was I wrong in supposing that the GPU would take over processing tasks of
the CPU?
- what would be a realistic cpu load for 24 hours a day, 2 months?
- Does anyone on the list have experience with running fullscreen
gem-patches with specs such as pentium III, 800Mhz, 384 Mb, and do they have any pointers on how to optimize (such as using a different size video, codec, etc..?)
I am also working on another computer (faster pIV, 512MB etc, etc...). I noticed that playing a video in mediaplayer requires less than half the cpu load of playing it in pix-movie or pix-film.
- Can anyone explain why this is?
Looking forward to hear from you.
Klaas
windows XP, pIII 800Mhz, 384 MB, Abit VL 6 Mobo, Hercules ATI Radeon 9000 128Mb
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks for your answers.
It is probably true that I could make a more efficient patch in which my usb webcam functions as a motion detector. (I use pix_movement followed by pix_blob to check for movement, and there might be a way of using just one pix object instead. I just didn't figure that out yet. Suggestions?) ((Note that I am not texturing the gemlist of the webcaminput into the gemwin. I just want it to supply me with 1 or 0 each cycle))
However, my main problem of cpu overload lies with pix_movie / pix_film (i.e. I experience the same when I just make a simple play movie patch). The cpu-load commences when I create a Gem window of course. And that is why I was puzzled, I thought that creating a texture on a rectangle in a gemwin was handled by the graphics card, if powerful enough.
Any further ideas?
Thanks again Andrew and jjbarrows
Klaas
From: "Andrew Cavers" andrew.cavers@gmail.com To: "klaas de Baas" kdebaas@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] Gem - CPU usage 98% Date: Thu, 8 Jun 2006 13:05:00 +0100
Klaas,
I suspect that it will be the motion detection part of your patch that will be eating the CPU most. If the video input is only being used to detect motion and the live video is not being displayed then setting the camera to it's lowest resolution will be more than adequate and will drastically reduce the load on the CPU. Also decrease the number of frames per second being analysed for movement. The speed of the GPU will certainly not help you in this instance.
My "mution" project used motion detection with PD/PDP/PiDiP from 160x120 resolution webcam input at 15fps which gave very reliable results and produced a load of only 20-30% on a 600mhz machine (running Linux).
Of course, the codec of the file you are playing will also hit the CPU (again, not the GPU) but I am not the best person to advise about that.
Good luck,
Andrew.
Hi, the problem is probably the web cam input i have had a lot of CPU load with USB cameras jjbarrow
On 6/8/06, klaas de Baas kdebaas@hotmail.com wrote:
Hello,
I am working on a patch, in which I use a webcam as a motiondetector, to drive another video (AVI, DV). (Every detected motion forwards a frame of the movie playing in pix_movie). I want this patch to be playing fullscreen in an exhibition for two months, non-stop. The problem is that I am worried about the CPU load - it hovers above 90% in Task Manager. (OS=WinXP) My concern is that the computer will not hold out on that load for that long.
I had hoped to solve this by buying a new graphics card, which I thought would have taken over the processing load. I have been experimenting with the Asus n6200 256 MB (a Nvidia Geforce 6200 card) and the Hercules ati Radeon 9000 128 MB. I'm aware that my Mobo does not support 8X AGP bus speed, but since I am mainly looking for 2d acceleration I hoped it would be ok.
CPU utilization is still high. My questions:
- was I wrong in supposing that the GPU would take over processing tasks
of the CPU?
- what would be a realistic cpu load for 24 hours a day, 2 months?
- Does anyone on the list have experience with running fullscreen
gem-patches with specs such as pentium III, 800Mhz, 384 Mb, and do they have any pointers on how to optimize (such as using a different size video, codec, etc..?)
I am also working on another computer (faster pIV, 512MB etc, etc...). I noticed that playing a video in mediaplayer requires less than half the cpu load of playing it in pix-movie or pix-film.
- Can anyone explain why this is?
Looking forward to hear from you.
Klaas
windows XP, pIII 800Mhz, 384 MB, Abit VL 6 Mobo, Hercules ATI Radeon 9000 128Mb
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
Andrew Cavers andy@mution.com www.mution.com
klaas de Baas wrote:
Thanks for your answers.
It is probably true that I could make a more efficient patch in which my usb webcam functions as a motion detector. (I use pix_movement followed by pix_blob to check for movement, and there might be a way of using just one pix object instead. I just didn't figure that out yet. Suggestions?) ((Note that I am not texturing the gemlist of the webcaminput into the gemwin. I just want it to supply me with 1 or 0 each cycle))
just to make sure: you only detect whether there is some movement in the image or not? then go with the smallest possible pix-size make sure to do the blob-tracking only on 1 channel; don't do rgb->grey conversion within blob; if the capture card drivers support output as greyscale you might want to try that; converting the image to greyscale in gem _might_ be a penalty (but as well not; try it) if the camera can output greyscale (even if the driver supplies them as rgb(a)) use this and let the pix_blob just work on any one of the channels.
However, my main problem of cpu overload lies with pix_movie / pix_film (i.e. I experience the same when I just make a simple play movie patch). The cpu-load commences when I create a Gem window of course. And that is why I was puzzled, I thought that creating a texture on a rectangle in a gemwin was handled by the graphics card, if powerful enough.
well, as soon as the pixeldata is on the gfx-card's ram you are done and the rest will be handled on the gpu. however, displaying a movie means decoding it, which is costy, depending on the codec (the better the compression the more cpu you will need; the worse the compression the more hd-access you need)
downloading the pixels onto the gfx-cards memory might also take some time. [pix_movie] should perform better here.
mfg.asdr IOhannes
Hello IOhannes,
<snip>
klaas de Baas wrote:
Thanks for your answers.
It is probably true that I could make a more efficient patch in which my usb webcam functions as a motion detector. (I use pix_movement followed by pix_blob to check for movement, and there might be a way of using just one pix object instead. I just didn't figure that out yet. Suggestions?) ((Note that I am not texturing the gemlist of the webcaminput into the gemwin. I just want it to supply me with 1 or 0 each cycle))
just to make sure: you only detect whether there is some movement in the image or not? then go with the smallest possible pix-size make sure to do the blob-tracking only on 1 channel; don't do rgb->grey conversion within blob; if the capture card drivers support output as greyscale you might want to try that; converting the image to greyscale in gem _might_ be a penalty (but as well not; try it) if the camera can output greyscale (even if the driver supplies them as rgb(a)) use this and let the pix_blob just work on any one of the channels.
I had been using pix_blob but only half understanding it. And I'm still a little uncertain:
- I presume that by "the smallest pix-size" you mean I should let the webcam
capture as small a framesize as possible and a low framerate?
- What do you mean by doing rgb->grey conversion in the blob?
- In my understanding of pix_movement, it stores the movement in the alpha
channel, and so that is the channel I let pix_blob listen to (my webcam outputs "RGB 24"). Why would grey be better?
And on another note - concerning pix_video:
- I know I can send the message [dialog( to the pix to call up a window for
the webcam settings. But how do I incorporate my settings in the message itself? Is that possible?
Thanks for your time, Ciao Klaas
On 6/8/06, klaas de Baas kdebaas@hotmail.com wrote:
CPU utilization is still high. My questions:
- was I wrong in supposing that the GPU would take over processing tasks
of the CPU?
Only the 3D OpenGL parts of GEM (Geos, Manips, Particles) are accelerated by the GPU. You can do image processing using the GPU and objects like fragment_program though. Any pix_ object is handled by the CPU.
- what would be a realistic cpu load for 24 hours a day, 2 months?
As long as the CPU and other components are properly cooled and stay within the rated specs any CPU load should be tolerated. CPUs are usually tested using a 'thermal virus' code that is at an extremely high level of efficiency, which GEM (or any real world program) will never reach.
- Does anyone on the list have experience with running fullscreen
gem-patches with specs such as pentium III, 800Mhz, 384 Mb, and do they have any pointers on how to optimize (such as using a different size video, codec, etc..?)
That is fairly old hardware so don't expect a lot out of it. It should do 320x240 video with some processing though. I would recommend a PCI cpature card with efficient DirectShow drivers that do things like scaling, color space conversion (overlay), deinterlacing and other functions in hardware on the card. I suspect the device you are using relies on inefficient software to do those things, hence the high CPU load.
Also, use a spigot object to gate the path going to the motion detection objects. You usually don't need 30fps for motion detection and int your case you could probably play several frames per detection with similar effect to full rate.
I am also working on another computer (faster pIV, 512MB etc, etc...). I
noticed that playing a video in mediaplayer requires less than half the cpu load of playing it in pix-movie or pix-film.
- Can anyone explain why this is?
GEM uses old VideoForWindows code to play AVI files which is slower than DirectShow. Mediaplayer uses a full DirectShow path and there are a number of efficient paths when you can do that. GEM has a full OpenGL rendering engine so we cannot use things like the DirectShow hardware mixer and scaler, and once you get off the narrow predetermined DS path things slow down qite a bit. There are plans to use Directshow for loading AVI files in the future, but it will still not be as efficient as MediaPlayer (hopefully it will be close though).
cgc
Thanks Chris,
Only the 3D OpenGL parts of GEM (Geos, Manips, Particles) are accelerated by the GPU. You can do image processing using the GPU and objects like fragment_program though. Any pix_ object is handled by the CPU.
My Gemlist ends in a rectangle, which is a Geo, as far as I understand. So I went and put your statement to the test, with a spigot before the pix-film, and another one before the rectangle. CPU-load did not drop significantly when switching off the rectangle, but it did when switching off gemhead->pix-film. So I guess I was looking in the wrong place, and it is more of a codec decoding load as IOhannes suggests in his later post.
I'm not sure what you refer to with "fragment_program". My guess is it is from another library (i.e. not from Gem)?
GEM uses old VideoForWindows code to play AVI files which is slower than DirectShow. Mediaplayer uses a full DirectShow path and there are a number of efficient paths when you can do that. GEM has a full OpenGL rendering engine so we cannot use things like the DirectShow hardware mixer and scaler, and once you get off the narrow predetermined DS path things slow down qite a bit. There are plans to use Directshow for loading AVI files in the future, but it will still not be as efficient as MediaPlayer (hopefully it will be close though).
cgc
There's quite a few things I understand now. After using my patch for a project the next two months, I am planning to switch to Linux from Windows. How does that OS environment compare with regards to Gem's handling of high resolution 2d video?
Ciao Klaas
Hello,
I have a gem 0.87 patch running on a PIII 700Mhz machine (256MB RAM) that uses about 100% CPU, the machine still renders fine after years of service. The only issue has been power-failures.
The patch mixed two videos (via alpha) at a time out of a bank of 4 that were all loaded, but only two playing at a time. Each was a 256x256 photojpeg mov. This runs on an old geforce2 mx.
Also it loaded still images (jpegs) on the fly from the HDD.
This was on linux... (suse 8)
Oh and the patch used so much CPU that it could not even render properly without the -rt flag. I think it was doing 30fps...
.b.
klaas de Baas wrote:
Hello,
I am working on a patch, in which I use a webcam as a motiondetector, to drive another video (AVI, DV). (Every detected motion forwards a frame of the movie playing in pix_movie). I want this patch to be playing fullscreen in an exhibition for two months, non-stop. The problem is that I am worried about the CPU load - it hovers above 90% in Task Manager. (OS=WinXP) My concern is that the computer will not hold out on that load for that long.
I had hoped to solve this by buying a new graphics card, which I thought would have taken over the processing load. I have been experimenting with the Asus n6200 256 MB (a Nvidia Geforce 6200 card) and the Hercules ati Radeon 9000 128 MB. I'm aware that my Mobo does not support 8X AGP bus speed, but since I am mainly looking for 2d acceleration I hoped it would be ok.
CPU utilization is still high. My questions:
- was I wrong in supposing that the GPU would take over processing tasks
of the CPU?
- what would be a realistic cpu load for 24 hours a day, 2 months?
- Does anyone on the list have experience with running fullscreen
gem-patches with specs such as pentium III, 800Mhz, 384 Mb, and do they have any pointers on how to optimize (such as using a different size video, codec, etc..?)
I am also working on another computer (faster pIV, 512MB etc, etc...). I noticed that playing a video in mediaplayer requires less than half the cpu load of playing it in pix-movie or pix-film.
- Can anyone explain why this is?
Looking forward to hear from you.
Klaas
windows XP, pIII 800Mhz, 384 MB, Abit VL 6 Mobo, Hercules ATI Radeon 9000 128Mb
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andrew Cavers -
B. Bogart -
chris clepper -
IOhannes m zmoelnig -
klaas de Baas