Date: Sun, 15 Mar 1998 13:42:10 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Amancio Hasty <hasty@rah.star-gate.com>, Jim Lowe <james@miller.cs.uwm.edu>, luigi@labinfo.iet.unipi.it Cc: multimedia@FreeBSD.ORG Subject: Re: Video ioctl interface Message-ID: <19980315134210.12544@ct.picker.com> In-Reply-To: <199803020935.BAA09432@rah.star-gate.com>; from Amancio Hasty on Mon, Mar 02, 1998 at 01:35:51AM -0800 References: <199803020935.BAA09432@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <BrookTree 848> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980315134210.12544>