By default the Indy has basic video input capability via the VINO.
There are three video options for the Indy
- Cosmo Compress - GIO32 card
- Indy Video - GIO32 card
- Indy Video 601 - External device, connects to Indy Video
According to SGI, there are three possible configurations
* IndyVideo+CosmoCompress for Indy
* IndyVideo+CosmoCompress for Indy+IndyVideo-601
However, there are reports of being able to use the following
* CosmoCompress for Indy
Just Cosmo board.
* 2 RCA analog composite inputs
* 1 svideo analog (Y/C) input
* 1 RCA analog composite output
* 1 svideo analog (Y/C) output
* a ribbon cable connector to mate with the Cosmo Compress for
Cosmo Compress for Indy
* Provides realtime hardware MJPEG compression and decompression.
* has a ribbon cable connector to mate with the Indy Video card
* has LFH-60 "Indycam connector" that can mate with a DBOB (Indy
Video 601), cannot be connected to a Indycam, however.
* Contains two digital channels, either SDI or parallel.
* IN 1 is always input
* IN 2/OUTPUT is bidirectional and can be confired as
either input or output, but not both at the same time.
(If used as an input, you can monitor IN 2 by connecting
a display to OUTPUT).
* An analog component output mirroring OUTPUT.
CosmoCompress works only with interlaced JPEG images. To be
played through the Cosmo, the file must have one of the following
four sets of characterstics (see dmconvert(1)).
width height interlacing frame rate
----- ------ ----------- ----------
NTSC 640 480 or 496 odd 29.97
CCIR601-525 720 480 or 496 odd 29.97
PAL 768 576 even 25
CCIR601-625 720 576 even 25
Cosmo uses a very primitive compression sceheme, MJPEG. Literally,
each frame is run through a jpeg compressor, and that is it.
By using Cosmo the compressor will allow you to operate well under
the disk speed limitation of the Indy (10MB/sec). The quality will
be relatively high, since it doesn't exhibit any of the artifacts
common to more advanced compression schemes (like MPEG2 for DVDs,
etc.) However, leaving movies in a format that can be used by cosmo
involves a lot of space. For instance, I record 25 minutes of an
animated TV show with Cosmo (but with uncompressed audio).
$ dmrecord -pvideo,device=ev1, engine=cosmo,quality=$QUALITY
-p audio -t1500
Hit the Enter key to begin recording...
Hit -c to stop recording...
Recording was done in real time successfully.
Quality Bitrate Total Size (with uncompressed audio)
60 15.347 Mbps 2,744MB
80 20.536 Mbps 3,672MB
Basically, Cosmo is pretty good for capture, but if you want to keep
a lot movies around, it is going to take a lot space.
All that is required is cosmo_6.5.tar.gz which is freely available on
# gzip -d cosmo_6.5.tar.gz | tar xf -
# inst -Ia -f .
CosmoCompress is not perfectly supported by the suite of media tools
in Irix 6.5. The software compression library can read and write
the files created by CosmoCompress, but a limited number of pieces
of software support realtime decompression via CosmoCompress. The
major frustration is that moviemaker(1) cannot utilize Cosmo to
give realtime playback/editing, even if all the clips are ones that
can be decompressed by Cosmo.
dmplay(1) Hardware ?
dmrecord(1) Hardware ?
compview(1) Hardware ?
moviemaker(1) Software Software
makemovie(1) Software Software
movieplayer(1) Software Software
mediarecorder(1) Hardware ?
mediaplayer(1) Hardware ?
dmconvert(1) Software ?
 While it does not communicate with the CosmoCompress
board, it is perfectly capable of converting movies it can read
into movies that can be played with dmplay(1) or mediaplayer(1)
and use the Cosmo
Capture via Cosmo
Edit in moviemaker(1)
Can this be played back by Cosmo?
From a modern machine/file to Cosmo playback
Refresh rate and resolution. Since Indy Video mates with directly
with the pixel bus (hence the requirement that it only be installed
in the slot closest to the RAM) there are strict requirements for
the resolution and refresh rate. Indy Video will display only at
1280x1024. I've successfully tested refresh rates of 50Hz, 60Hz and
72Hz. Notably, 76Hz does *not* work. videoin will display nothing, but,
intresteingly the video confidence test *will* display frames at
76Hz, but it will peg the CPU. I guess that confidence test doesn't
relay on the pixel bus injection.