jim@baroque.Stanford.EDU (James Helman) (11/14/90)
I had a similar thought about using a NeXTDimension as an animation slave to our SGI. My inquiries on this subject both to the net and to our NeXT rep have gone unanswered. I'd be happy even with 10-15 frames/sec and minor decompression degradation (most things go out on VHS anyway). I suspect the lack of response means that a) NeXT is keeping the specs secret, b) the bandwidth just isn't there, or c) both. I hope I'm wrong. From my perspective, it's one of the more intriguing aspects of the product. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127
jack@dali.gatech.edu (Tom Rodriguez) (11/14/90)
I've seen demos of the video capabilities of the Next Dimension machines and they are very impressive. The captured video is 640 by 480 32 bit RGBA. It can record and play back in realtime from the harddisk, doing JPEG video compression along the way. You can do video editing in software without any loss of video quality due to copying and recopying the video signal. As far as the quality of the video out, i haven't seen anything produced by it. It does have S-vhs video out in addition to a normal composite signal. I doubt that the quality is poor, mainly because my general impression of the machine is that the hardware that supports the video is excellent. Anyway, if anyone get's the chance to see a demo of the Next Dimension machine, check it out. It really rocks. tom ----------------------------------------------------------------------------- Tom Rodriguez jack@cc.gatech.edu SERC Multimedia Computing Group Georgia Institute of Technology Atlanta Georgia 30332-0280
talent@spanky.sps.mot.com (Steve Talent) (11/14/90)
In article <JIM.90Nov13163758@baroque.Stanford.EDU> jim@baroque.Stanford.EDU (James Helman) writes: >I had a similar thought about using a NeXTDimension as an animation >slave to our SGI. My inquiries on this subject both to the net and to >our NeXT rep have gone unanswered. I'd be happy even with 10-15 >frames/sec and minor decompression degradation (most things go out on >VHS anyway). I suspect the lack of response means that a) NeXT is >keeping the specs secret, b) the bandwidth just isn't there, or c) >both. I hope I'm wrong. From my perspective, it's one of the more >intriguing aspects of the product. > >Jim Helman >Department of Applied Physics Durand 012 >Stanford University FAX: (415) 725-3377 >(jim@KAOS.stanford.edu) Work: (415) 723-9127 I have a copy of the NeXT brochure that lists some specs for the new machines, including the NeXTdimension Board. Of course you need the NeXTcube for this board. Image compression and decompression is done using a dedicated JPEG Image Compression Processor from C-Cube. The brochure states that you can do real-time video compression and decompression and store up to 60 minutes of live video on a high capacity hard disk (probably 1.4GB drive). The compression factor is user selectable. The brochure doesn't state any details about how these numbers were calculated. I think the sales rep. stated a compression range of 50X to 200X. It seems that image degradation for animation would be less noticible that for still images. Steve Talent, Motorola Semiconductor Products Sector CAD Tempe, AZ 602-897-5440, talent@dover.sps.mot.com
olson@sax.cs.uiuc.edu (Bob Olson) (11/14/90)
I asked around and got the following replies to the query... >Couldn't you just created rendered graphics, get >it into compressed format and then dump, 20 seconds or so. You wouldn't >need an Abekas or special single step video recorder. Am I right? am >I wrong? Thanks to those who replied. ********************************************************************** From: Kim_Orumchian@NeXT.COM Here are some of my thoughts related to animation on NeXTdimension: I think what the discussion below hinges on what is meant by "broadcast quality". Images that are compressed and played back by a NeXTdimension are not going to look as good as those produced frame by frame on a dedicated video production system. This is not to say that images produced in this way will look bad, just that they won't be exactly what you would expect from a dedicated machine costing hundreds of thousands of dollars. This brings up several issues. The first is that NeXTdimension is fully capable of generating very high quality still frame images in much the same way that the SUN workstations are bring used (as described below). The speed of NeXTdimension for manipulating 32 bit graphic images makes it quite desirable for this kind of operation, (the i860 is one fast chip). Another issue is that even though the NeXTdimension's JPEG compressed images may not be as high resolution as what production houses have today, an important question is who would use low cost, easy to use animation, video editing and production products. I think there is an analogy to desktop publishing: in the early days only large very specialized production houses used computers to aid in layout and production. When Pagemaker came out on the Mac, many people scoffed at the solution because it did not offer them the same kind of quality as the high end systems. The point is a new audience was found because the lowered price point/simplified ease of use appealed to a different, much broader set of people. I think the same is going to be true in the case of software products that sit on NeXTdimension. In summary, yes NeXTdimension is a great stand-alone animation computer (among other things) and even though it does not offer "broadcast quality" output in the strict sence, the video it generates by playing back compressed images is pretty high resolution (better than most VCR's). Also, there are coming high-end consumer-grade single frame VCR's that would let you image frames with full resolution (640X480, 32 bits per pixel), and then output them one frame at a time without doing any compression whatsoever. ********************************************************************** From: Eddy Wong <ewong@gpu.utcs.utoronto.ca> In order to output production quality video suitable for broadcasting, the video signal has to strictly conform to RA170A standard. In another word, the timing of the video signal has to be very accurate. Although there are many video boards for different computer platforms capable of producing good enough video signal to be recorded to commercial video equipments, they are not good enough for professional quality video recording. I don't have enough information to tell whether NeXTDimension is good enough for professional quality video. Hope this help. ********************************************************************** From: jasmerb@ohsu.EDU (Bryce Jasmer) >Does anyone know more precisely what he is talking about? My gut >feeling is that he is underestimating the NeXTdimension, but I'm not >sure... No, I think he is hitting the nail right on the head. Remember what the NeXTDimension is actually doing when it does compression. It is taking an image and doing 37 times compression on it. This isn't easy to do, it must remove some things for the picture and do its best to get a close approximation. The data going into the compression is not the same as the data coming out of the compression. This is fine if you plan on doing a quick recording of CNN but if you plan on doing animation with "photorealistic" quality, the NeXTDimension and C-Cube (the chip that does the JPEG compression) just don't cut the mustard. The animation frames take a long time to generate and need to be exact. If you compress them to the hard disk you will lose some of the sharpness of the frames. Now don't get me wrong, the NeXTDimension and compression chips are really sweet but they just don't cut it for what this guy is thinking about doing.
velasco@beowulf.ucsd.edu (Gabriel Velasco) (11/14/90)
From: Kim_Orumchian@NeXT.COM >I think what the discussion below hinges on what is meant by >"broadcast quality". Images that are compressed and played back by a >NeXTdimension are not going to look as good as those produced frame by >frame on a dedicated video production system. Why? This is not a flame. I am really wondering where the deficiency is. Is it in the hardware? The software? The compression algorithm? The original poster was talking about producing the sequences frame by frame. >Another issue is that even though the NeXTdimension's JPEG compressed >images may not be as high resolution as what production houses have >today, I am not at all familiar with NeXTdimension's JPEG compressed images. What type of algorithm do they use? Is it delta modulation? Run length encoding? Send only changes from one frame to the next? Selective color mapping? If NeXTdimension is using 32 bit color (mentioned later in the article) then isn't that *better* than what production houses are using? HDTV is only 24 bit color. How are the 32 bits divided into the three colors? >When Pagemaker came out on the Mac, many people scoffed at >the solution because it did not offer them the same kind of quality as >the high end systems. The point is a new audience was found because >the lowered price point/simplified ease of use appealed to a >different, much broader set of people. I think the same is going to be >true in the case of software products that sit on NeXTdimension. Let's not forget its use in multimedia. I don't think that the "production" quality video systems give much thought to compression because they don't have a bandwidth problem. To transmit these frames over something like the ethernet (We're doing it right now over 10Mbps ethernet in "real-time" with UVC compression boards.) you need compression. A real-time 24 (or 32) bit color video channel would take up a good chunk of an FDDI network too. It seems like the NeXT system may make video e-mail possible. >Also, there are coming high-end consumer-grade >single frame VCR's that would let you image frames with full >resolution (640X480, 32 bits per pixel), and then output them one >frame at a time without doing any compression whatsoever. The author is treating the "compression" like a dirty word. Compression need not decrease the quality of the image any. It depends on the type of compression. What is the resolution of the NeXTdimension video? From: jasmerb@ohsu.EDU (Bryce Jasmer) >Remember what >the NeXTDimension is actually doing when it does compression. It is >taking an image and doing 37 times compression on it. This isn't easy >to do, it must remove some things for the picture and do its best to >get a close approximation. The data going into the compression is not >the same as the data coming out of the compression. This is not necessarily true for all forms of compression. Straight run length encoding preserves every bit of detail in the original image. Delta modulation can come pretty close at a high enough sampling rate. Is it the type of compression that they are using that causes them to lose resolution? Are they mapping the colors into a color map or something similar to what is done for gif images? I may be wrong here, but it seems to me that people are producing "broadcast quality" images with Amiga's outfitted with genlock cards. There are some relatively expensive supposedly professional systems available for the Amiga right now. I've seen pictures of stuff created by the the Amiga that had supposedly been done for KTLA tv station and others. -- ________________________________________________ <>___, / / | ... and he called out and said, "Gabriel, give | /___/ __ / _ __ ' _ / | this man an understanding of the vision." | /\__/\(_/\/__)\/ (_/_(/_/|_ |_______________________________________Dan_8:16_|
kenb@amc-gw.amc.com (Ken Birdwell) (11/15/90)
>talent@spanky.sps.mot.com (Steve Talent) >The brochure states that you can do real-time video compression and >decompression and store up to 60 minutes of live video on a high >capacity hard disk (probably 1.4GB drive). The compression factor >is user selectable. The brochure doesn't state any details about >how these numbers were calculated. I too was confused by these numbers. But if you figure the a 24 bit image (640*480*3) takes a little under a meg (921600 bytes) then youre talking about (1400000000/921600) 1500 frames or about 50 seconds at uncompressed rates. Since the compression rate in configurable, (but I heard that you have to go to 30:1 if you want to do realtime, something about bandwidth), you should be able to get about 25 minutes of fairly good quality images (synthetic images will show a greater degradation than captured video) and about 60 minutes at 72:1 , which I assume to be fairly low quality. --
jim@baroque.Stanford.EDU (James Helman) (11/15/90)
I have the same brochure. But the wording, "lets you take live video,
compress it, and store it on a hard disk," isn't totally explicit
about the frame rate or resolution of the images. If it means 30 full
NTSC resolution frames per second, that's good.
talent@spanky.sps.mot.com writes:
I think the sales rep. stated a compression range of 50X to 200X.
It seems that image degradation for animation would be less noticible
that for still images.
Someone from C-Cube gave a talk here last year. I think 50:1 to 200:1
might be pushing it a little bit. I remember approximately 20:1
compression of an NTSC frame without perceptible degradataion. That
could probably be pushed up to 50:1 without it looking too bad. 200:1
is the absolute max I've heard. The higher compression ratios were
claimed to be most useful on print images, e.g. mostly white with some
black.
Of course, JPEG is a *still image* compression technique (it doesn't
use any of the correlations between frames). CCITT/ISO is supposed to
(soon?) announce the MPEG (motion video compression) standard. Once
this gets into silicon, compression ratios should jump substantially.
I'd like to hear more numbers: the storage per frame required,
sustainable data rates to and from disk, as well as compression
ratios.
One concern I have is trying to do a quasi-realtime (i.e. 30Hz)
operation on a Unix (ok, really Mach underneath) machine. Is there
enough headroom so that as long as system is pretty quiescent you
don't need to kill all the daemons or reboot in single user mode?
The same issue applies to disk access. Do you need to use a raw
partition in order to get (barring bad block/cylinder forwarding)
contiguous storage? Or is there enough headroom so that the normal
filesystem is usually adequate?
Jim Helmanmadler@piglet.caltech.edu (Mark Adler) (11/15/90)
kenb@d9.amc.com (Ken Birdwell) figures: >> But if you figure the a 24 bit image (640*480*3) takes a little under >> a meg (921600 bytes) ... >> ... about 60 minutes at 72:1, which I assume to be fairly low quality. The compression ratios apply to the YUV image, which averages 16 bits per pixel instead of 24 (since the U and V are actually 320x480). This gives 614400 bytes. Even so, this would require a compression ratio of 44:1 to get 60 minutes on a 1.4G drive. The C-Cube chip shows some degradation at 50:1, but one could argue that it's still better than you'd get on a normal analog TV. On another note, the standard for digital TV (used by digital VTR's) is 720x243 (before interlacing, giving about 720x484 since there are two empty lines). I wonder why NeXT is using 640x480? I hope they weren't influenced by (shudder) Mac's or PC's. Mark Adler madler@piglet.caltech.edu
dtynan@unix386.Convergent.COM (Dermot Tynan) (11/17/90)
In article <1990Nov15.115234.4438@nntp-server.caltech.edu>, madler@piglet.caltech.edu (Mark Adler) writes: > > The compression ratios apply to the YUV image, which averages 16 bits > per pixel instead of 24 (since the U and V are actually 320x480). > On another note, the standard for digital TV (used by digital VTR's) is > 720x243 (before interlacing, giving about 720x484 since there are two > empty lines). I wonder why NeXT is using 640x480? I hope they weren't > influenced by (shudder) Mac's or PC's. Actually, referring to the American Cinematographers Manual (which I *don't* have in front of me, so forgive any roundoff (?) errors), not only is the definition for "broadcast quality" defined as 720x484, it also requires "from 8 to 12 bits" per color! Seeing as they only used approximately 5 bits per color, they probably figured they had compromised anyway, and might as well use 640x480, which seems to be deep-rooted in ancient mysticism, along with 80-characters per line, and 24 lines per screen (monitor bandwidth and P31 resolution black-magic incantations heard in the background). - Der -- Dermot Tynan dtynan@zorba.Tynan.COM {altos,apple,mips,pyramid}!zorba!dtynan "Five to one, baby, one in five. No-one here gets out alive."
dave@imax.com (Dave Martindale) (11/17/90)
In article <1990Nov15.115234.4438@nntp-server.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: > >On another note, the standard for digital TV (used by digital VTR's) is >720x243 (before interlacing, giving about 720x484 since there are two >empty lines). I wonder why NeXT is using 640x480? I hope they weren't >influenced by (shudder) Mac's or PC's. There are two types of digital VTR's, D-1 and D-2. D-1 uses a 13.5 MHz sampling frequency, while D-2 uses 4 times the subcarrier frequency. Both of these frequencies were chosen for convenience in digitizing and reconstructing an analog signal without regard to the actual horizontal pixel count - 720 in one case, something else in the other. The vertical pixel count is fixed by the number of active scan lines in the picture. Both of these standards give non-square pixels. On the other hand, most frame buffers that work with video signals want to provide square pixels, so they use whatever pixel clock rate is necessary to give square pixels given the fixed vertical resolution. The difference between 480 and 484 is a few lines at the very top and bottom of the screen that are never visible to an ordinary viewer anyway. The digital VTR's, of course, are expected to record all of the relevant parts of the video signal (more than 484, perhaps all 525 lines) while the frame buffer need provide only the visible portion.
madler@piglet.caltech.edu (Mark Adler) (11/18/90)
Dermot Tynan (dtynan@zorba.Tynan.COM) notices: >> Actually, referring to the American Cinematographers Manual (which I >> *don't* have in front of me, so forgive any roundoff (?) errors), not >> only is the definition for "broadcast quality" defined as 720x484, it >> also requires "from 8 to 12 bits" per color! Seeing as they only used >> approximately 5 bits per color, they probably figured they had >> compromised anyway, and might as well use 640x480, which seems to be >> deep-rooted in ancient mysticism, along with 80-characters per line, >> and 24 lines per screen (monitor bandwidth and P31 resolution black- >> magic incantations heard in the background). Well, sort of. Computing 5.3 bits per color is misleading. There are still 8 bits each for Y, U, and V---it's just that there are half as many U's and V's. I said there was an average of 16 bits per pixel, but really there are 32 bits per two pixels. The YUV gets converted to RGB in a way that gives a full eight bits of resolution to R, G, and B for each pixel, except that there is a subtle correlation between adjacent even and odd pixels. As someone else pointed out, U and V combined get the same bandwidth that Y does on an NTSC broadcast, which is how this elementary compression of RGB by 3:2 retains broadcast quality. However, one might consider "broadcast quality" to be an oxymoron. The numbers 480 and 640 do seem to have Kabbalistic origins, along with 24 and 80. Mark Adler madler@piglet.caltech.edu
clp@wjh12.harvard.edu (Charles L. Perkins) (11/19/90)
It was stated that the "real" standard for broadcast quality requires 8-12 bits per color...unless I misunderstand what was meant, the NeXTdimension could in theory meet this (with 8 bits per color) as long as it was allowed to output only a few minutes at a time (some compression without loss is still possible even with full color)... or with even better frame-at-a-time VCRs on their way, it could do full resolution on all frames. Charles
peb@Autodesk.COM (Paul Baclaski) (11/27/90)
I missed the beginning of this thread, so please bear with me if this was already mentioned... Does the NTSC output of a NeXT machine do overscan? This is a must for "broadcast quality" more than N bits per pixel is. Paul