Date: Fri, 26 May 2000 21:12:55 +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: <392EBEA7.EFDCE058@freenet.co.uk> References: <20000525210340.A44725@nc.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Randall, 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. 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. 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. Alex Randall Hopper wrote: > > Been thinking about a way to make writing TV apps easier (not just > easy; trivial!). An API that would allow folks to literally write their > own in Python or Tcl TV app with 5-10 lines of code. > > If you like the idea, read on. My thought is to embed all the > "configure, capture, convert, and blast" needed for a TV client of any sort > into a daemon. An app wanting video data in some format would simply say: > > tv.Connect() > tv.Configure() > tv.Start() > tv.Stop() > tv.Close() > > something along those lines. > > Does this kind of interface interest anyone? > > Potential clients would be, for example, GUI applications, one-shot > frame grabbers, webcams, on-the-fly MPEG encoders, etc. > > Potential destinations for the video data would be: any X Window > (created by Tk, wxWindows, Motif, ...whatever!), the frame buffer, a > socket, named pipe, file(s), memory buffer (user, XImage, XvShmImage), raw > device, ... > > Possible video sources are, of course, the TV cards (either directly > though the driver API or indirectly via the new Xv extension). > > BTW, GUI apps would simply say "here; take this X Window", and the > daemon would take care of all the rest (determine src and dest pixel > format, configure and fire up the TV driver, handle any format conversions > necessary [and FAST! -- using MMX if available], possibly changing between > XImage and DGA transfer automagically, using Shared memory, YUV images, or > whatever capture/convert/transfer path supported is fastest on your box, ...) > > Basically, the idea is to bury all the low-level nastiness in the > daemon so users don't have to care about driver capture formats, pixel > format conversions, available X protocols, throttling, etc. > > Hermes or SDL might be good libraries to use under-the-hood to do the > the pixel format conversion (Hermes already has MMX support; been testing > it recently with bktr TV and it looks promising). > > Anyway, thanks for reading. Please fire off any opinions, for or > against. No sense in spending time on this if desire for it is just > lukewarm. > > -- > Randall Hopper > aa8vb@nc.rr.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-multimedia" in the body of the message 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?392EBEA7.EFDCE058>