Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Dec 1995 00:43:50 +0100 (MET)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        james@miller.cs.uwm.edu (Jim Lowe)
Cc:        hackers@freebsd.org, tinguely@plains.nodak.edu
Subject:   Re: meteor driver bug
Message-ID:  <199512182343.AAA03399@labinfo.iet.unipi.it>
In-Reply-To: <199512182159.PAA06086@miller.cs.uwm.edu> from "Jim Lowe" at Dec 18, 95 03:59:15 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > BUG: around line 1072 of the driver, the following code:
> 
> Hmmm... By my count there are 38 4 byte registers and we want to offset to

the comments in the code say 37, not 38. And another piece of code is
consistent with the count of 37. Unfortunately I don't have the manuals
at the moment.

> > FEATURE: at offset 0x3c in the 7116, it would be preferable to
> >     set the "Field Toggle" bit. This enables the 7116 to simulate the
> >     presence of an interlaced image even with non-interlaced images. It
> >     should help with VTRs and should not harm otherwise. Thus I would
> >     change the init value from
> > 
> > 	/* 0x3c */      0x00000103,     /*  9:8   *RW   Reserved (0x0)
> > 
> >     to
> > 
> > 	/* 0x3c */      0x00000107,     /*  9:8   *RW   Reserved (0x0)
> 
> I am not sure what this does exactly, maybe Mark can comment.  I don't
> think there would be any problem with this.
> > 
> > FEATURE: the 'correct' values for regs 01-05 of the 7196,
> >     according to the data sheets, should be the following:
> > 
> > /* 01 */        0x30,   /* 7:0  Horizontal Sync Begin for 50hz */
> > /* 02 */        0x00,   /* 7:0  Horizontal Sync Stop for 50hz */
> > /* 03 */        0xe8,   /* 7:0  Horizontal Sync Clamp Start for 50hz */
> > /* 04 */        0xb6,   /* 7:0  Horizontal Sync Clamp Stop for 50hz */
> > /* 05 */        0xf4,   /* 7:0  Horizontal Sync Start after PH1 for 50hz */
> > 
> >     I tried them with a 50Hz PAL camera, and they seem to work fine.
> >     They could replace my previous suggestion.
> 
> I am not sure what you mean by correct.  If you go by CCIR-601, then the
> values that are in the driver are correct (see pp 2-18 of the Desktop
> Video Data Handbook by Phillips).  I know this is what the default values
> for these are for the 7196, but I don't beleive these are CCIR-601 values.

the values in 1.0.8 (those for 50Hz, regs 01-05 of the 7196) did
not work for me. I first blindly replaced them with those for 60Hz,
which seemed to work. I then got a copy of the specs of the 7191,
which give the values I propose. They work as well, and look to me a
better choice than my previous guess (at least somebody must have
thought about them, not simply make a blind copy like I did :) ).

> > PROPOSAL: whith moving images, mixing samples from two frames produces
> >     a very unpleasant visual effect (basically, one frame is shifted
> >     with respect to the previous one). Moreover, this mix produces
> >     (spatial) high frequency components which make the compression
> >     algorithms work less efficiently. My proposal is to acquire
> >     single frames by default, and use both frames only in the case
> >     of the highest resolution images (e.g. 640x480 or 768x576).
> >     This can be done without loss of resolution. It requires some
> >     simple changes to the METEORSETGEO ioctl, and possibly to
> >     the interrupt handling routine.
> > 
> 
> I always thought it took two Fields before one had a complete Frame.
> The card should be able to capture 60 fields/sec or 30 frames/sec in ntsc
> or 50 fields/sec or 25 frames/sec in pal.
> 
> I beleive the driver captures two fields for each frame.  I am not
> sure what you are proposing here -- but maybe it is a terminology
> issue that I am missing...

Sorry, it's my problem with the terminology. I rephrase it:

with moving subjects, the two FIELDS which make up a FRAME are slightly
shifted from one another (obviously, as the subject is moving). When we
sample a FRAME, we get these two shifted FIELDS, interlaced. This gives
an unpleasant visual effect, especially when sampling single FRAMES,
*and* produces high frequency components which reduce the efficiency of
the compression algorithms. To improve both the visual effect and the
compression, I propose to make the driver acquire every other FIELD by
default, except when there is an explicit request from the user or
we want more lines than there are in a single FIELD (240 for NTSC, 288
for PAL).

	Luigi
====================================================================
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/
====================================================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512182343.AAA03399>