Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Feb 1996 15:56:19 -0500 (EST)
From:      "matthew c. mead" <mmead@Glock.COM>
To:        james@miller.cs.uwm.edu (Jim Lowe)
Cc:        multimedia@star-gate.com, hackers@freebsd.org
Subject:   Re: frameserv and clients
Message-ID:  <199602212056.PAA05373@Glock.COM>
In-Reply-To: <199602211920.NAA21889@miller.cs.uwm.edu> from "Jim Lowe" at Feb 21, 96 01:20:45 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Jim Lowe writes:

> > From: "matthew c. mead" <mmead@Glock.COM>

> > 	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/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602212056.PAA05373>