Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Dec 1998 15:38:42 +0100 (MET)
From:      Christoph Fleck <fleck@Rcs1.urz.tu-dresden.de>
To:        Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc:        mmt-ref@tu-dresden.de, roger@cs.strath.ac.uk, multimedia@FreeBSD.ORG
Subject:   Re: BT848 adaptive AGC
Message-ID:  <Pine.GSO.3.95.981201124934.3754A-100000@rncmm2.urz.tu-dresden.de>
In-Reply-To: <199812010933.KAA01718@labinfo.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks a lot for your fast answer.

> > Can the BT848 driver enable the adaptive AGC mode?

> > The adaptive AGC could avoid this.
> 
> I doubt it!
> 
> There are two "AGC" in the Bt848 -- one refers to AD overflows,
> the other one to chroma. For the first one (register 0x068, pg.103
> in my manual, "CRUSH" bit) the relevant piece of code is

We have some different manuals. I mean the register 0x68 too.

> The "CRUSH" bit is disabled by default (at least in my copy of the
> sources) because I found out that the adaptation process is one-way:
> it reduces the gain, but never brings it up again. So when you have
> bad signal (usually from the tuner) and the capture chip looks for
> sync pulses in the wrong place, the image turns rapidly black.
> I think you don't want this feature, anyways.

I could not play with this option in the past. Is it even not useful on
very smooth videosignals?
I am need no tuner for videoconferencing. The cameras deliver a very
clear and noiseless signal.

> The other "AGC" i see is in the registers E_SCLOOP and O_SCLOOP
> and it seems to affect the chroma component.  Looking at the code,
> this feature is disabled when opening the device, and enabled in
> the various functions which build the bt848 programs yuvpack_prog(),
> yuv422_prog(), yuv12_prog()  -- i am not sure if this is a mistake
> or it is intentional. You can easily try to disable it yourself by
> commenting out the three pairs of lines in the above functions.

I am not yet looked at the code. A small prog to set the registers
at runtime could help me very much. 
Primary I would absolutly no gain control changes while transmitting. 
This should be done before transmitting. Later it should stay.
But I see no way for this. So I belive some regression to the 
automaic gain control could be enough.

> be sure that the problem does not come from the camera (e.g. most
> Camcorder have AGC and often there is no way to disable it) or
> lighting (especially with neon lamps, when you have a drift between the
> camera and mains frequency).

I am shure the camera is not the reason. (Panasonic SVHS-CAM)
Some other cards (Parallax, SunVideo, SGI Indy: Vino) 
would never change the brightness of background. That increase the
quality rapidly and decrease the bandwith by faktor 2.

If there is no solution by the software to freeze or even limit the restless 
AGC, I probably try to build an external referencevoltage for manual adjusting
of gain control. But this should be the very last.

Rgds,
Christoph Fleck

,------------------------------------------------------------------.
| Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden |
|         Dr. Klaus Koehler, Christoph Fleck                       |
| e-mail: mmt-ref@tu-dresden.de             Tel.: 0351 / 463 5653  |
|    WWW: http://www-mm.urz.tu-dresden.de               (GERMANY)  |
`------------------------------------------------------------------'


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?Pine.GSO.3.95.981201124934.3754A-100000>