From owner-freebsd-multimedia Fri Apr 3 09:47:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07896 for freebsd-multimedia-outgoing; Fri, 3 Apr 1998 09:47:47 -0800 (PST) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA07890 for ; Fri, 3 Apr 1998 09:47:43 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA28236; Fri, 3 Apr 1998 18:14:33 +0200 From: Luigi Rizzo Message-Id: <199804031614.SAA28236@labinfo.iet.unipi.it> Subject: advice sought on new ioctl for frame grabber. To: multimedia@FreeBSD.ORG Date: Fri, 3 Apr 1998 18:14:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Looking at the IETF (nice) and INFOCOM (ugly) (*) video multicast these days, I was thinking of what could be a nice feature for the video grabber driver, and thought of one which could well be a very stupid idea... The idea is to add a 'freeze' ioctl which freezes the current frame in the video buffer, but otherwise maintains the same behaviour for the application (e.g. wake up every so often, send signals if so instructed). I'd have one usage for this -- namely, send a still image using vic without having to modify the program -- but rather by simply issueing the ioctl to the driver perhaps with an external program. The reason this is possibly a stupid idea is that a little tweaking with vic might possibly achieve the same result without having to modify the driver, and possibly with improved features (e.g. use better quantization when sending a still image). Opinions ? I will try to implement this either in the driver or in the application when I have made up my mind... cheers luigi (*) why do i think the INFOCOM transmission was ugly ? For the video they used a very rough quantizer (q=15) which coupled with a very bad location of the camera made slides almost impossible to read. I sent a mail asking for better quality of the video and they did try to improve things but probably the wrong way: the next day i saw a few minutes where they zoomed onto the screen, so text was finally readable, except that it was only half of the slide, so they had to move the camera back and forth across the screen.... Audio had similar problems in that they were sending short (probably 20ms) frames instead of the more effective DVI4 (80ms frames, 32KB/s) used for IETF transmissions. -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message