From owner-freebsd-hackers Wed Feb 21 12:57:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA27236 for hackers-outgoing; Wed, 21 Feb 1996 12:57:05 -0800 (PST) Received: from Glock.COM (root@glock.com [198.82.228.165]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA27224 for ; Wed, 21 Feb 1996 12:56:57 -0800 (PST) Received: (from mmead@localhost) by Glock.COM (8.7.3/8.7.3) id PAA05373; Wed, 21 Feb 1996 15:56:19 -0500 (EST) From: "matthew c. mead" Message-Id: <199602212056.PAA05373@Glock.COM> Subject: Re: frameserv and clients To: james@miller.cs.uwm.edu (Jim Lowe) Date: Wed, 21 Feb 1996 15:56:19 -0500 (EST) Cc: multimedia@star-gate.com, hackers@freebsd.org In-Reply-To: <199602211920.NAA21889@miller.cs.uwm.edu> from "Jim Lowe" at Feb 21, 96 01:20:45 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk Jim Lowe writes: > > From: "matthew c. mead" > > I'm currently working on a framserver for the Connectix > > QuickCam. Basically, it's a unix domain sockets server that > > waits for connections and upon getting them grabs a frame from > > the camera using the libqcam.a (from qcam-0.3) routines and > > shoves the frame down sockets to the client applications. This > > implementation could easily be change/extended to use tcp/ip > > connections so that you could have a machine grabbing frames and > > clients elsewhere snagging them from across the network. > > [...] > I started to think about this also, but this is what vic already does. > The missing piece of this is the abilty to remote control the server, > but I beleive this is being handled by the conference bus that is > planned for the vic/vat applications. Hmm. I have vic on my system, but have not been able to get its quickcam patches to actually take pictures from my quickcam. Unfortunately, Virginia Tech won't pipe MBONE out to the BEV Ethernet routers, so I can't get MBONE without someone tunnelling, and the closest person is, you guessed it, Virginia Tech. > Vic reads video data from a capture board, compress the data, > and send it out to the network. It is also a receiver and a user > interface, but part of it is a video frame grabber for the network. > The user API is really RTP so application can recieve unicast or > multicast packets and decode the RTP frames. A neat interface > to this would be to grab RTP frames from a session and plop > them into a web page somewhere. Sort of the the mbone vcr for > single frames. Hmm. Ok, so when vic runs it is actually two parts? It's a grabber program that knows how to snag frames, and a client program which knows how to get them from the grabber program? > If you would like more details on vic, you might want to check > out Steve McCanne's home page: http://www-nrg.ee.lbl.gov/mccanne Let me explain the main reasoning behind my development of frameserv and friends. It's pretty simple actually - I want to have fast access to frames off the quickcam (or other capture devices), while also allowing *multiple* programs to get those frames at the same time. Does vic's setup allow this or does it require exclusive use of the device you're grabbing video from? -matt -- Matthew C. Mead mmead@Glock.COM http://www.Glock.COM/~mmead/