home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / multimed / 3380 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.4 KB
  1. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!cs.tu-berlin.de!elwood!limu.prz.tu-berlin.de!edgar
  2. From: edgar@limu.prz.tu-berlin.de (Edgar Ostrowski)
  3. Newsgroups: comp.multimedia
  4. Subject: Re: frame grabber for Sparc
  5. Message-ID: <4240@elwood.prz.tu-berlin.de>
  6. Date: 16 Nov 92 19:13:14 GMT
  7. References: <1992Nov12.150556.25771@mintaka.lcs.mit.edu>
  8. Sender: news@elwood.prz.tu-berlin.de
  9. Organization: TU-Berlin TUBKOM, Germany
  10. Lines: 40
  11.  
  12. In article <1992Nov12.150556.25771@mintaka.lcs.mit.edu> duda@brokaw.lcs.mit.edu (Andrzej Duda) writes:
  13. >We are looking for a frame grabber card for live TV input. We want to
  14. >digitize it in real-time without compression with the resolution from
  15. >320x240x16 to 160x120x16 at 10fps and store to disk. The card should
  16. >be for Sparc (or for PC eventually). According to my information neither
  17. >VideoPix, RasterOps nor Parallax can do it. Any suggestions?
  18. >
  19.  
  20. For my experience both the Parallax XVideo and the RasterOps SparcCard TC
  21. can be used for your tasks. I've run a small program on our Sparc2 equipped
  22. with a Parallax XVideo board to see what's possible (to get good performance
  23. values the framebuffer was mapped into memory which allows direct read access).
  24.  
  25. An image of 240x180 pixels (24 bit/pixel) can be read from the card, converted
  26. to 16 bit (5/5/5 RGB) and written to disk in 65-71 msec. This was measured with
  27. the tmp filesystem in the swap partition. With the normal filesystem one can't
  28. get similiar values, there's too much overhead from the flesystem (from six
  29. successive frames three were grabbed, converted, and written in 67-70 msec each;
  30. one needed 150-170 msec and the other two needed 200-240 msec). This results
  31. in a mean value of about 130 msec /frame. I'd call this worst case.
  32.  
  33. We experienced similiar access rates for reading from the framebuffer of
  34. the RasterOps card. Therefore I think that the performance of both cards
  35. will not be significantly different. The greatest performance bottleneck for
  36. storing uncompressed video is be the filesystem - if you use it; you might
  37. try using a raw partition instead. The UNIX filesystem probably has it's
  38. advantages, but there is anything else but support for continuous media. 
  39.  
  40.  
  41. -edgar-
  42.  
  43. ________________________________________________________________
  44.  
  45. Edgar Ostrowski
  46.  
  47. phone:  +49 30 314-25985
  48. e-mail: ostrowski@prz.tu-berlin.dbp.de
  49. X.400:  s=ostrowski; ou=tubkom; ou=prz; p=tu-berlin; a=dbp; c=de
  50. ________________________________________________________________
  51.  
  52.