Date: Sat, 27 May 2000 20:36:07 +0300 From: A G F Keahan <ak@freenet.co.uk> To: Randall Hopper <aa8vb@nc.rr.com> Cc: multimedia@freebsd.org Subject: Re: TV Users - Let me bounce this off you Message-ID: <39300787.AC2BF3C8@freenet.co.uk> References: <20000525210340.A44725@nc.rr.com> <392EBEA7.EFDCE058@freenet.co.uk> <20000526230145.A25153@nc.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Randall Hopper wrote: > > 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. Sure -- I don't have access to the sources right now, but will do in a couple of weeks time. > |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? Yes. The server also stops when there are no clients connected (each client increments a counter in the shared memory location). The clients were using Netscape's server-push technology to display real-time streaming video in a browser window. Server-push video looks really good, and the best thing is that no special tools or plugins are required. If your network connection is good enough, you can even watch TV in a browser window -- all you have to do is change the input from METEOR_INPUT_DEV0 to whatever TV input is called these days. Unfortunately, only Netscape can do server-push, so MSIE clients had to do a one-shot capture every couple of seconds and then refresh. The server also jpeg-compressed the data -- to make it scale well to hundreds of clients -- all a client had to do was lock the buffer, memcpy the data, unlock the buffer, and then send the data across the network. This also guaranteed that clients always got the latest available frame, regardless of their network bandwidth. The big question is how often should the server jpeg-compress the data? I had a dedicated machine (P200 MMX), which was doing it continuously, as fast as it could manage, but other people might want to do it less frequently, maybe every 2 seconds or so. > |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? Yes, multiple clients, a few hundred of them. Server-side compression can be CPU-intensive, but then you can basically have as many clients as you like (each client was taking about 0.001% CPU on my P200). The funny thing is that the CPU load actually drops as the number of clients goes up: more clients increase lock contention, causing the server to update the buffer less often. As for one-shot captures, this is exactly what I did for MS Explorer clients. I was thinking of making the server "smarter", so that any client can request single shots of different sizes, brightness, contrast, etc -- this would require reprogramming of the bktr device on the fly -- but it shouldn't be too hard. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39300787.AC2BF3C8>