gem_video

[Mark Danks]

  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 at 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 at stormfront.com
= http://www.danks.org/mark
============================