Date: Sun, 25 May 1997 14:26:33 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: van@ee.lbl.gov, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: about vic Message-ID: <199705252126.OAA00516@rah.star-gate.com> In-Reply-To: Your message of "Sun, 25 May 1997 22:19:16 %2B0200." <199705252019.WAA13405@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>From The Desk Of Luigi Rizzo : > > Amancio, > > > > the vic h261 encoder code, like the precept h261 encoder, will > > embed a 320x240 ntsc image in a 352x288 cif rectangle so > > decoders see no change. Almost all the vic grabbers work this > ... > > rather than YUV_422. The combination of this change & the > > single field grab now means the stock meteor works reliably even > > with the broken Natoma PCI chips on Intel's Pentium-Pro > > I think the conclusion of various investigations was that it was > the Philips 7116 (the PCI interface on the meteor), not the Natoma, > which caused problems. We are not sure about that mostly due to Intel and Matrox never explaining the real cause of the problem. I just CC hackers and hopefully one of the Intel CPU or PCI designers will shed some light into this problem. My educated is that Intel is not going to tell us what is the real problem. On the lighter side of things, Philips is supposed to have a new chipset, SAA 7146, which is not supposed to have this nasty dma bug or incur the nasty dma bug in the Natoma chipset. > > motherboards. The grabber was also changed to remove two extra > > memory-memory copies of each frame so it sped up more than a > > speaking of performance, since the Bt848 chip (for which Amancio has > written a driver) is highly programmable, is there a preferred output > format for the grabber to supply data ready for the encoder without > need for copies (or does YUV_PACKED already suffice ?) > We should be able to provide whatever format vic wants and also prepare the buffer to whatever vic wants to eliminate copying buffers altogether. What I am thinking about doing is providing a ring buffers such that when vic wants a buffer all I should do is provide the buffer pointer to the new buffer thus eliminating all buffers on the side of the video grabber. The next stage in way of performance improvement could be to provide MMX support and to provide support to dump YUV on the X server. The latter is a bit more difficult given that it requires X server modifications however many popular cards now days do provide yuv to rgb conversion. And the last phase will be to provide a mechanism to activate WC combining for PCI display card's linear frame buffer which can speed up display rates by a 400 percent or so. For those interested in trying out Van's grabber-meteor.cc and own a Bt848 based card, please download : ftp://rah.star-gate.com/pub/bt848.tar.gz The driver includes Van's grabber-meteor.cc with some slight modifications to detect both a meteor and a Bt848 based card. Enjoy, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705252126.OAA00516>