From owner-freebsd-multimedia Fri May 26 20: 0:44 2000 Delivered-To: freebsd-multimedia@freebsd.org Received: from rr.com (rdu25-28-182.nc.rr.com [24.25.28.182]) by hub.freebsd.org (Postfix) with ESMTP id BD7BF37B885 for ; Fri, 26 May 2000 20:00:39 -0700 (PDT) (envelope-from rhh@rr.com) Received: (from rhh@localhost) by rr.com (8.9.3/8.9.3) id XAA25465; Fri, 26 May 2000 23:01:46 -0400 (EDT) (envelope-from rhh) Date: Fri, 26 May 2000 23:01:45 -0400 From: Randall Hopper To: A G F Keahan Cc: multimedia@freebsd.org Subject: Re: TV Users - Let me bounce this off you Message-ID: <20000526230145.A25153@nc.rr.com> References: <20000525210340.A44725@nc.rr.com> <392EBEA7.EFDCE058@freenet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <392EBEA7.EFDCE058@freenet.co.uk>; from ak@freenet.co.uk on Fri, May 26, 2000 at 09:12:55PM +0300 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A G F Keahan: |This sounds like a great idea. I did something similar for my webcam |server/client application using SysV shared memory -- the server part |was continuously capturing (and optionally jpeg-compressing) data into a |shared memory buffer, and web clients (CGI scripts) were reading and |sending that data to the user. Sounds pretty cool. If quite a bit more interest perks up, maybe we should start with yours and see what folks need additionally. |However, you need some locking mechanisms that would tell your daemon |when it's safe to update the buffer -- you don't want a client to read |the first half of one frame, and the second half of another. Good point. So I take it your webcam doesn't do a one-shot capture, grab frame, and repeat. The server tries to keep the buffer filled with the latest constantly, and only stops temporarily when the client is using the buffer? |In my application the solution was trivial -- to use a SysV semaphore to |lock the buffer for writing, so no-one can read while it's being written |into. But since your idea is much more general, you probably have to |think of a more general synchronisation solution. Certainly some handshaking will be needed, if nothing else to tell the client when a request has completed. Maybe semaphores would be the way to go. Did you consider having the client do one-shot captures? Why have the daemon constantly pumping video into the buffer. Multiple clients? -- Randall Hopper aa8vb@nc.rr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message