From owner-freebsd-hackers Mon Dec 18 15:47:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA28808 for hackers-outgoing; Mon, 18 Dec 1995 15:47:05 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA28795 for ; Mon, 18 Dec 1995 15:46:57 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id AAA03399; Tue, 19 Dec 1995 00:43:50 +0100 From: Luigi Rizzo Message-Id: <199512182343.AAA03399@labinfo.iet.unipi.it> Subject: Re: meteor driver bug To: james@miller.cs.uwm.edu (Jim Lowe) Date: Tue, 19 Dec 1995 00:43:50 +0100 (MET) Cc: hackers@freebsd.org, tinguely@plains.nodak.edu In-Reply-To: <199512182159.PAA06086@miller.cs.uwm.edu> from "Jim Lowe" at Dec 18, 95 03:59:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > 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/ ====================================================================