Skip site navigation (1)Skip section navigation (2)
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>