First off, I'm glad that you were able to get anything working at all. For most people it takes some fixes and hacks to get it going. There are massive problems getting pix_video to work under Windows. In a nut shell, the Windows system was never designed to get the actual pixel data from a video stream. It assumes that it is either going directly to the screen or to a hard drive...without the program ever modifing the actual data. GEM has to go through a number of hoops and jumps to get anything to work. My machine will often lock up when I use pix_video. I would welcome any suggestions on how to make it work better...

Okay, now for the specific issues.

-----Original Message----- From: umläute [mailto:zmoelnig@iem.mhsg.ac.at] Subject: gem_video

hw-specs: PII - 350MHz guillemot 3d prophet geForce256 DDR-DVI (should be fast enough)

Yep, a geForce is the best card you could use for GEM right now.

Trying pix_video i have a few problems concerning speed; the very maximum i could do is 320 * 240 pixes (but this might be because of the poor TV-card or because i haven't found the correct software to change this)....should it be possible to change the dimen of the captured video from within gem ?

In the SGI version, the video driver will do the actual resizing. Under Windows, it doesn't seem to be the case. The max that pix_video supports is 320x240 because it has to set the size when the object is created. If you try to make it larger, pix_video should complain about "not enough pixels or something". I can look into this, such as detaching from the capture stream and recreating it at a different size. I have noticed that internally running at number other than 320x240 or 640x480 (NTSC resolution) makes the operating system unstable here in the States. I need to finish up the PAL support in the object though...

<snip> > the frame-rate is something very weird, i already did 20-25 frames,and > it only used 80-83% of my cpu; but it wasn't really smooth, and > smoothiness did NOT CHANGE by doing a frame-rate of only 15. Neither > changed the cpu-load (witch was very ok, for everything reacted quite > fast) > > then SUDDENLY, the video came in *quite* smooth, and the cpu-load > exploded to 100%; again now real changes for various frame-sizes > (except, of course, that at 15frm/sec it wasn't smooth any longer, but > load stayed at 100% !). > I don't have any idea, why the behaviour changed; (by the way, > *yesterday* i had a constant cpu-load of 100%)

Not certain what is going on here. Because GEM needs the actual pixel data, there always seems to be a high over head rate, but that is higher than I have seen before.

<snip> > just adding one or two gem-objects) i would highly appreciate any > solution that will cost nothing (you know, watching TV on the pc isn't > very hard work for the cpu too), so is there any possibility to do a

As mentioned above, Windows freaks out if you actually want the pixel data, as opposed to going directly to screen or disk. To say that the Windows media library is poorly designed and buggy is a massive understatement. I got spoiled working with SGI's video library, which worked really well and was extremely stable.

very simple pass-through, or where can I save calculations (p.e. do we really have to copy the captured frame into an internal rgbA-buffer; or is this less important ?)

The copy is needed for a couple of reasons. One, the frame data is invalid after the callback is done. Two, the frame data is BGR, while the rest of GEM is always expecting RGBA or Greyscale. In theory, it would be possible to just blast it to a texture binding (there is an imageInPlace object which does this) One problem though, is that GEM never knows when the callback is occuring because the system triggers it.

I have been meaning to go back and look at this. Sounds like it is about time. There may be some way to do this in DirectX3 or something (shudder)...I'll have to look. Let me know what other problems or sucesses you have.

Later, Mark

============================ = mdanks@stormfront.com = http://www.danks.org/mark ============================