From owner-freebsd-multimedia Sun Mar 15 10:44:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14456 for freebsd-multimedia-outgoing; Sun, 15 Mar 1998 10:44:34 -0800 (PST) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA14451 for ; Sun, 15 Mar 1998 10:44:31 -0800 (PST) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 15 Mar 1998 13:42:24 -0500 (EST) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA04952; Sun, 15 Mar 98 13:42:22 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id NAA29903; Sun, 15 Mar 1998 13:42:10 -0500 Message-Id: <19980315134210.12544@ct.picker.com> Date: Sun, 15 Mar 1998 13:42:10 -0500 From: Randall Hopper To: Amancio Hasty , Jim Lowe , luigi@labinfo.iet.unipi.it Cc: multimedia@FreeBSD.ORG Subject: Re: Video ioctl interface Mail-Followup-To: Amancio Hasty , Jim Lowe , luigi@labinfo.iet.unipi.it, multimedia@freebsd.org References: <199803020935.BAA09432@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199803020935.BAA09432@rah.star-gate.com>; from Amancio Hasty on Mon, Mar 02, 1998 at 01:35:51AM -0800 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I thought I should mail out the notes I've jotted down on this before too many weeks go by. Bullet form for easy browsing. 1) Are we sure it's really worth the effort at this point? Assuming it is: 2) I'd like us convert to this model: Applications -> Capture Library -> Capture Devices Applications -> Tuner Library -> Tuner Devices All device I/F abstracted through a common userland library/libraries. Libraries would be C, but if generically written, it's easy enough to cook C++ wrappers for this model. 3) Generic, extensible interface. No interfaces to explicitly open specific devices or set/get specific parameters (e.g. contrast, brightness, hue, etc.) on a device. Have a generic interface to query which capture/tuner devices are available, which parameters for each device are supported, and for each, what their valid value ranges are. E.g.: TUNERLIB_DEV *TunerLib_GetInstalledTunerDevByIndex( i ); TUNERLIB_DEV *TunerLib_OpenTunerDev( dev, i ); TUNERLIB_PARAM *TunerLib_GetParamByIndex( dev, i ); TUNERLIB_PARAM *TunerLib_GetParamByName( dev, "CONTRAST" ); TUNERLIB_PRANGE *TunerLib_GetParamRange( dev, param ); TUNERLIB_PRANGE *TunerLib_SetParam( param, double value ); ... So all this stuff: #define BT848_SBRIG _IOW('x', 38, int) /* set brightness */ #define BT848_GBRIG _IOR('x', 38, int) /* get brightness */ #define BT848_BRIGHTMIN (-50) #define BT848_BRIGHTMAX 50 #define BT848_BRIGHTCENTER 0 #define BT848_BRIGHTRANGE 99.6 #define BT848_BRIGHTREGMIN (-128) #define BT848_BRIGHTREGMAX 127 #define BT848_BRIGHTSTEPS 256 ... if it doesn't go away completely, is only dealt with by the capture/tuner libraries and made available to application clients through the abstracted, extensible APIs that the libraries export. 4) Support query of all valid values for discrete value parameters from the driver. E.g.: SIGNAL_FMT = { NTSCM, NTSCJ, PALBDGHI, PALM, PALN, SECAM, PALNCOMB } 5) Support getting valid ranges and quantization intervals from the driver for all continuous driver parameters. E.g. for bt848 brightness: BRIGHTNESS: min,max,step = { -50.0, +49.6, 0.4 } 6) Either: a) talk to capture lib in terms of the real-world values (e.g. "brightness %"), or b) support APIs to query the mapping between virtual values and real-world values. E.g.: BRIGHTNESS: VIRTUAL [ min,max,step,type = { -128 , +127, 1, int32 }] ACTUAL [ min,max,step,type = { -50.0, +49.6, 0.4, double }] Type can be eliminated by always talking doubles to the driver. I'd prefer to see a) 7) Move freq<->channel mappings totally out of the driver and into a userland tuner library; always talk to the driver in frequencies. AFAIK channel numbers don't even make sense for PAL. They're an artifact of starting with NTSC. They can be abstracted into the I/F libs by always dealing with station strings: struct TUNERLIB_STATION { int index; char name[80]; double freq; } st; TUNERLIB_STATION *TunerLib_GetStationByName ( dev, char [] ); TUNERLIB_STATION *TunerLib_GetStationByIndex( dev, char [] ); void TunerLib_SetFreq( dev, double freq ); E.g.: st = TunerLib_GetStationByName( dev, "N21" ); /* PAL */ st = TunerLib_GetStationByName( dev, "3" ); /* NTSC */ TunerLib_SetFreq( dev, st->freq ); station.name would be a locale-specific string, another good reason to have this in a userland library. Kernel shouldn't deal with I18N issues. 8) Provide generic driver I/F to query all relevent card info needed for debugging (e.g. for bt848 cards, eeprom + i2c + etcetc -- one big card specific- format string). This can be used by an app. Shouldn't have to "know" something about the card to get this information (is an EEPROM installed; what capacity EEPROM is installed, etc.). 9) API to query a string that briefly identifies the card (e.g. card name + chipset + tuner name). I.e. a way to display this in an app bktr0: rev 0x11 int a irq 9 on pci0.11.0 Hauppauge WinCast/TV, Philips NTSC tuner, dbx stereo. without grepping dmesg. 10) Capture Format Query API Generic enough to return sufficient parameters for each supported format for a program (and thus the user) to choose a format dynamically via application user interface, AND for the app to be able to process the captured data byte-for-byte if necessary. E.g. for RGB & YUV, something along these lines: typedef enum { FRAME_PLANAR, /* E.g. YYYYY..UUUUU...VVVVV */ FRAME_PACKED /* E.g. YVUVYVUV... */ } FRAME_PACKING; typedef struct { int index; /* Drvr hdlr for pix fmt */ PIXELTYPE type; /* RGB, YUV */ /* RGB-only attributes */ u_int Bpp; /* Bytes per pixel */ u_int mask[3]; /* Pixel masks */ u_int swap_bytes :1; /* Bytes in shorts swapped */ u_int swap_shorts :1; /* Shorts in longs swapped */ /* YUV-only attributes */ u_int samp_size[3]; /* [YUV] Bits per sample */ u_int samp_int_h[3]; /* [YUV] Horiz samp interval */ u_int samp_int_v[3]; /* [YUV] Vert samp interval */ FRAME_PACKING frame_packing; /* Order YUV data is stored */ char comp_order[30]; /* "YUYV", "YVU", etc. */ u_int order_t_to_b :1; /* Scanline order TtoB;BtoT */ u_int order_l_to_r :1; /* Column order RtoL;LtoR */ u_int y_trans :1; /* LSb Y = transparency? */ } FRAME_GEOM; (from fxtv::tvcapture.h. I cooked this after digesting the FOURCC YUV formats: http://www.webartz.com/fourcc). E.g.: FRAME_GEOM IYUV = YUV_h422_v422_planar = { -1,PIXELTYPE_YUV,0,{},0,0, {8,8,8},{1,2,2},{1,2,2},FRAME_PLANAR,"YUV",1,1,0 }, YUY2 = YUV_h422_v111_packed = { -1,PIXELTYPE_YUV,0,{},0,0, {8,8,8},{1,2,2},{1,1,1},FRAME_PACKED,"YUYV",1,1,0 }, YUY2L = YUV_h422_v111_planar = { -1,PIXELTYPE_YUV,0,{},0,0, {8,8,8},{1,2,2},{1,1,1},FRAME_PLANAR,"YUV",1,1,0 }; 11) Remove any arbitrary ordering requirements for setting up parameters before capture (as much as possible) - Parm set calls just test whether parm is valid for its own range - Start capture determines whether the entire parameter set is valid together to start capture (i.e. inter-parameter checks), and if so, configures the card and starts capture 12) API to parse Teletext and Intercast data, and to attribute the data nicely so all apps don't know how to parse this stuff. Use generic attribute and attribute value lists. This is just for starters. This message is getting long, so I'll wrap it up there for now. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message