bttv 2.6.16: wrong VBI_OFFSET?

[Michael Schimek <mschimek (at) users.sourceforge.net>]

On Wed, 2006-04-26 at 15:21 -0700, Trent Piepho wrote:
> The datasheet says that VBI_HDELAY starts at the trailing edge of /HRESET.
> What your saying is that there is an undocumented extra delay of 64 pixels at
> fCLK*1 after the tailing edge of /HRESET before VBI_HDELAY starts, correct?
> It's surprising that the datasheet would totally miss the extra delay in
> several places, bot in the text and in the figures.  It's also seems strange
> that it's even there.  What is timing it?  Why have the delay at all?

Well I *think* the leading edge of the /HRESET pulse coincides with the
leading edge of the horizontal sync pulse (0H). The datasheet isn't clear
about that. Perhaps it's 64 clocks late, or the /HRESET seen by the VBI
circuit is? Maybe the /HRESET pulse is longer than the datasheet says?
Although HSFMT changes give the expected results. VBI_HDELAY has only six
bits. Perhaps some register contains an undocumented msb, or it's
hardwired to 1? Video HDELAYs below 64 produce garbage, a coincidence?

> What if there is an undocumented minimum value for VBI_HDELAY?

It works as documented. Here are some pictures of the suspects:
http://zapping.sf.net/bttv/

Note the difference between video and VBI images. The datasheet says video
HDELAY is 0H relative. The /HRESET pulse and the VBI_HDELAY account for 64
clock cycles but it looks more like 128.

> Maybe the chip does some kind of back porch black level or color burst sampling,
> and can't capture vbi until it's done?

In image 6 it captured the back porch just fine.

Michael

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list