Date: Wed, 12 Feb 1997 13:01:15 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: dgy@rtd.com, multimedia@freebsd.org Subject: Re: broadcast video Message-ID: <199702122001.NAA09277@seagull.rtd.com> In-Reply-To: <199702120827.AAA28321@rah.star-gate.com> from "Amancio Hasty" at Feb 12, 97 00:27:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Amancio Hasty said: > On a fast network lets say 1mbit or more you can get 20 to 30 frames > per second with h.261 using 352x288 frames. You will need a fast cpu > P166 or higher. It helps to have fast memory such as SDRAM for > video datacompression and in the win95/winnt MMX instruction set. > Well, the MMX is more of an issue of native compiler support > rather than OS . OK, let's back out a second... Am I correct in assuming that the flow of data in a "typical" application is video source to coder (which may be in software) then onto the network as "broadcast" message (though it could also be directed at a specific IP address, right?). The receiving nodes suck it off the network, push it through a decoder (which can also be software) and then copy the bits into the display (assuming the decoder isn't hardwired to the display)? If the video is *canned*, then this would eliminate the need for the coder and "video digitizer", correct? What is the quality of 352x288 fields (I thought it was 352x240)? How does it compare with "regular" video (e.g., off of a VCR). > In an embedded system you may be able to get away with ultra > fast video capture by not having to go thru the PCI bus. > There are other hardware issues such a Trimedia chipset with > 2 billion instructions/sec vs a PC specially for video data > compression. This will be proprietary hardware for a dedicated application. As such, I can use a hardware codec and hardwire it to the display (on the receiving end) and the video source (on the transmitting end). I don't think I'd want to hardwire the NIC to the codec so would probably wire a DMA channel to move bytes from the codec to/from the network chip. > So yes, the mbone audio/video stuff is real if you have the > bandwith. With h323 that is h.263 video codec plus G.723 > low bandwith or more reasonable data rate requirements is > a reality. For instance, it is possible to send a qcif size > picture at 30 frames per second with less than 64kb or > you can actually send acceptable frame rate and audio > with 28.8 kb. I'd be dedicating a 10Base2 network for use exclusively by the video stream (with some low bandwidth control information flowing alongside). So, bandwidth doesn't appear to be the problem I had imagined. The CPU bottleneck may be a kicker, though. If the codec is NOT implemented in hardware, how much overhead is there to just move bytes into the codec (assuming it is hardwired to the display)? > The best way to learn about this stuff is to equip a PC with > the appropiate gear and play with it to see if it can meet > your requirements think about it as a "model" . The PC should > have win95 and freebsd installed . FreeBSD because it can > show the optimal performance and win95 so you can play with > the audio/video apps which are not available for freebsd. While I think that would give me a feel for the quality of the images possible (since it seems bandwidth isn't an issue, etc.), I think the platform is far enough away (technologically) from what I'd be implementing that it wouldn't give me a good feel for just how much horsepower it *does* take to achieve the goals I'm after. Though any authoring tools might be a WIN. > o video Matrox Meteor or Intel Smart Video Recorder III Is this capable of single field/frame recording? > o sound GUS PnP because it is a *true* full duplex audio card. Don't need full duplex and don't even need the capability to "digitize" audio within the application -- since the audio will be canned, too. > o S3 968 based card because it has VRAM and it fast enough for > video display > > o CPU P166 try to avoid PPRO 200Mhz till the PCI chipset gets > debugged Hmmm... I imagine this still wouldn't let me see full screen video, etc. Can you recommend a video codec vendor? How sophisticated are the DEcoding algorithms?? (since I'll only be dealing with canned video) i.e. is it possible implement in an FPGA, etc.? > Well I am well over my .25 cent limit, have fun Thanks! I'd send you your "change" but all i've got is a $10 bill ;-) --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702122001.NAA09277>