topix@gpu.utcs.utoronto.ca (R. Munroe) (04/23/91)
I'm sure this has probably been discussed in this group before so excuse me if I'm being redundant if I'm being redundant. I'd like to hear from anyone who has used or is currently using either the Video Framer or Video Creator products from SGI. The most important issue is the quality of video output. We are Wavefront users currently outputting our animation through 1) a minivas controlling a BVH 2000 (for encoded output) and 2) a minivas controlling a BVW 75 for component output. For the BVH 2000, our signal is encoded through a Cox encoder. Will the Framer or Creator give us worse, equal, or better quality than we currently have? Thanks for any and all responses Bob Munroe Internet: topix@utcs.utoronto.ca AppleLink: CDA0695 CompuServe: 71160,3455 Voice: 416.971.7711
wes@uh.msc.umn.edu (Wes Barris) (04/25/91)
In article <1991Apr23.032930.5814@gpu.utcs.utoronto.ca>, topix@gpu.utcs.utoronto.ca (R. Munroe) writes: > > I'm sure this has probably been discussed in this group before so excuse me > if I'm being redundant if I'm being redundant. I'd like to hear from > anyone who has used or is currently using either the Video Framer or Video > Creator products from SGI. The most important issue is the quality of > video output. We are Wavefront users currently outputting our animation We have the Video Framer thing. We also use Wavefront on a 4D/320, send the image data to an Abekas A60, and dump it from there to a Betacam BVW-75. The animation controller portion of the Video Framer works very well. I am not using the NTSC output on the Video Framer. Currently, we rcp Wavefront-generated quantel files to the Abekas. Video Framer gives us an alternative to this. I can output the image out the D1 port on the Video Framer. The Abekas can record D1 in real time. The Video Framer frame buffer display is only a little faster than rcp'ing the file. Right now the D1 signal is poor. I am assuming it is because we are using a "plain" ribbon cable for the D1 signal. I have on order an actual D1 cable (twisted pair I believe). o o o o o o o . . . ________________________________ _____=======_T___ o _____ ||Wes Barris | | wes@msc.edu | .][__n_n_|DD[ ====_____ |Minnesota Supercomputer Center| |(612) 626-8090 | >(________|__|_[_________]_|University of Minnesota_______|_|_FAX: 626-1596_|_ _/oo OOOOO oo` ooo ooo 'o^o^o o^o^o` 'o^o o^o` -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The important thing is not to stop questioning.
gianulis@phoenix.Princeton.EDU (Brad Gianulis) (04/30/91)
In article <1991Apr23.032930.5814@gpu.utcs.utoronto.ca> topix@gpu.utcs.utoronto.ca (R. Munroe) writes: > >I'm sure this has probably been discussed in this group before so excuse me >if I'm being redundant if I'm being redundant. I'd like to hear from >anyone who has used or is currently using either the Video Framer or Video >Creator products from SGI. The most important issue is the quality of >video output. We are Wavefront users currently outputting our animation >through 1) a minivas controlling a BVH 2000 (for encoded output) and >2) a minivas controlling a BVW 75 for component output. For the BVH 2000, >our signal is encoded through a Cox encoder. Will the Framer or Creator give >us worse, equal, or better quality than we currently have? > >Thanks for any and all responses > >Bob Munroe >Internet: topix@utcs.utoronto.ca >AppleLink: CDA0695 >CompuServe: 71160,3455 >Voice: 416.971.7711 We've got a VideoCreator and have been getting poor quality ever since we turned it on. What is poor quality? That's the main problem. There doesn't seem to be a language out there (at least not in the computer graphicist's world) for describing video artifacts. I'm sure videographer's can describe it all very well. We've been getting this "ghosting" or "echoing" or "looping" or whatever you call it, where it looks like there is a duplication of the video signal shifted to the right about 10 pixels and fainter. We've also had about three weeks of hotline trouble-shooting with no luck. This resulted in an FE replacing the whole unit as a test with no luck, yet. Is this the expected quality? Does anyone out there have a VC that gives better quality than this? As far as the full screen capability goes, that's great (of course you have to count on your 1-pixel-wide lines to fade because of the scan conversion - boost it up to 2 pixels, and its fine). The one problem we did not anticipate is the slowness of sending images thru the SCSI port. Because we are now able to record the full screen in real-time, we HAVE to record the FULL screen in real-time. You cannot set the screen to an uncompressed format (not-scan converted, 640x486 NTSC size) the way we could before with our old Lyon Lamb setup. This means you have to send NTSC size images through the SCSI, which takes a few seconds longer for each frame. No big deal, right? It is when you're sending thousands of frames for an animation. We don't have the V-lan interface yet, its on order. We're still using our Lyon Lamb to do the tape controlling. Brad Gianulis, Interactive Computer Graphics Lab Princeton University
tttron@escher.lerc.nasa.gov (William Krauss) (04/30/91)
In article <8848@idunno.Princeton.EDU> gianulis@phoenix.Princeton.EDU (Brad Gianulis) writes: > >We've been getting this "ghosting" or "echoing" or "looping" >or whatever you call it, where it looks like there is a duplication of the >video signal shifted to the right about 10 pixels and fainter. This is a "hunch" but you might want to check the termination of your signal. >Brad Gianulis, Interactive Computer Graphics Lab >Princeton University -- >>>> William D. Krauss NASA Lewis Research Center <<<< >>>> Graphics Visualization Lab Cleveland, OH 44135 USA <<<< >>>> tttron@escher.lerc.nasa.gov(128.156.1.94) (216) 433-8720 <<<<
gianulis@phoenix.Princeton.EDU (Brad Gianulis) (05/02/91)
In article <1991Apr29.203750.8792@eagle.lerc.nasa.gov> tttron@escher.lerc.nasa.gov (William Krauss) writes: >In article <8848@idunno.Princeton.EDU> gianulis@phoenix.Princeton.EDU (Brad Gianulis) writes: >> >>We've been getting this "ghosting" or "echoing" or "looping" >>or whatever you call it, where it looks like there is a duplication of the >>video signal shifted to the right about 10 pixels and fainter. > >This is a "hunch" but you might want to check the termination of your signal. > >>Brad Gianulis, Interactive Computer Graphics Lab >>Princeton University > > > >-- >>>>> William D. Krauss NASA Lewis Research Center <<<< >>>>> Graphics Visualization Lab Cleveland, OH 44135 USA <<<< >>>>> tttron@escher.lerc.nasa.gov(128.156.1.94) (216) 433-8720 <<<< Yes. That's the first thing we thought of, because we've seen this thing before by using T-connectors to share the video signals coming from the CPU to the monitor. All our testing with the VC has been: CPU RGB output to VC VC RGB output to monitor VC NTSC output to composite video monitor and that's it. 75 ohm terminations on both monitors. I even tried disconnecting everything, except the SCSI connection and the NTSC output, and sent an image to the frame buffer. No difference. ---------- NEWS FLASH ----------- Just in. The local SGI FE set up a VC in their office, saw the same "ghosting" effects and said "that's as good as it gets", but they are going to try out yet another VC box. I just have the feeling that there is some poor engineering going on inside the VC box regarding the video signals being brought in and being sent out. - Brad Gianulis, ICGL Princeton U.
xxjgh@dali.lerc.nasa.gov (Jay G. Horowitz) (05/02/91)
>>In article <8848@idunno.Princeton.EDU> gianulis@phoenix.Princeton.EDU (Brad Gianulis) writes: >>> >>>We've been getting this "ghosting" or "echoing" or "looping" >>>or whatever you call it, where it looks like there is a duplication of the >>>video signal shifted to the right about 10 pixels and fainter. >> > >---------- NEWS FLASH ----------- > >Just in. The local SGI FE set up a VC in their office, saw the same "ghosting" >effects and said "that's as good as it gets", but they are going to try out yet >another VC box. > >- Brad Gianulis, ICGL > Princeton U. Our Video Creator apparently is not haunted by the same ghosts as yours and SGI's so don't settle for 'That's as good as it gets'. While the VC may not be the best scan-converter, its really not as bad as your experience would lead you to judge it. Like my colleague (William Krauss) said in a previous response to your problem, I would suggest you keep searching for mismatched terminations or bad shielding both *INSIDE* and outside your SGI. We had several problems associated with improperly terminated connections on the SYNC line that genlocks all our computer/video equipment. That was a tough one because the mismatch was not near the SGI and only the VC had problems. With respect to the quality of the VC image, we have an SGI (120 GTX) with the 'little-window-in-the-left-&-can't-watch-video-and-use-your- monitor-at-the-same-time' genlock board, an SGI (320 VGX) with the VC, and an outboard Lyon-Lamb RTC-7 converter which intercepts and converts the video from both Iri. While we haven't had a chance to do a complete set of quantitative tests, the video from the VC is superior to the GENLOCK board and not as good as that from the Lyon-Lamb (which costs quite a bit more). P.S. - We have had previous problems with the VC and have had the board replaced at least once. Maybe you should insist on testing a replacement just to be sure the problem is not on that particular board. P.P.S - Don't use that SGI FE's board. -- .......................................................................... Jay G. Horowitz "For the finest in kosher pixels!" NASA Lewis Research Center (216) 433-5194 xxjgh@dali.lerc.nasa.gov (128.156.1.48)