bttv 2.6.16: wrong VBI_OFFSET?
- From: Edgar Toernig <froese (at) gmx.de>
- Date: Wed, 3 May 2006 20:25:06 +0200
Sorry for the late reply. I'm not subscribed to the video4linux list
and just found your message by luck.
Michael Schimek wrote:
>
> Edgar Toernig wrote:
> >
> > I remember that I tried to figure out how to calculate the VBI offset
> > from the Bt8xx specs a couple years ago but resigned - somehow the
> > specs are wrong. But given a teletext signal and the teletext specs
> > you can measure its value[1] and 244 is pretty accurate for PAL.
> Amazingly in NTSC mode the data aligns perfectly. In PAL mode VBI gives
> some 120 pixels more on the left side. Video capturing uses an offset
> of 128 clocks in NTSC-M mode, 186 in PAL-BGHI mode and the spec says
> this is 0H relative. So I think the actual VBI offset (at fCLKx2) is 256.
Hmm... I remember that I was tempted to use 256 as well but testing the
teletext data of a couple of stations I came to the conclusion that it
is not correct - for nearly all stations the teletext sync was off by
about 12 samples. Hence the magic 244. It seems vbi capture start is
related to video HDELAY somehow.
I found an old posting:
|
| Subject: Re: v4l2 vbi for bttv
| From: Edgar Toernig <froese (at) gmx.de>
| To: AleVT <alevt (at) listbot.com>
| Message-ID: <39FB0ED4.A130CF10 (at) gmx.de>
| Date: Sat, 28 Oct 2000 19:37:24 +0200
|...
| > > > OK - it seems the Bt848 starts VBI capture immediately after the
| > > > horizontal sync pulse.
| > >
| > > At least the bttv driver does not start at hsync. The first data
| > > I get is the last part of the color burst. That is an offset of
| > > about 244.
| >
| > Strange. The Bt848 manual says capture starts immediatly after the
| > rising edge of \HSYNC... I will have to play around with this some
| > more.
|
| The rising edge of \HSYNC is the trailing one and 64 Clk1 cycles after
| the leading edge. And, sampling starts VBI_HDELAY Clk1 cycles after
| the trailing edge. So, offset _should_ be (64+VBI_HDELAY)*2. As bttv
| has VBI_HDELAY=0 offset is 128.
|
| But somehow this does not fit. The base for VBI_HDELAY must be some-
| thing else. The documentation is wrong or I'm stupid. But if you for
| example compare BDELAY and the VBI samples with VBI_HDELAY=0 you'll see
| that there's something wrong.
|
| I got the offset value of 244 by simply taking the reference time
| for teletext (13th bit is 12us after leading hsync), looked at where
| it is most of the time in the samples and then calculated the offset
| that would give.
|
| Hmm... played around with this. It seems, the real offset is dependent
| on hscale. Samples start earlier/later when capture window is resized.
| Strange... Good luck you driver writers ;)
|...
| Btw, (186-64)*2 = 244 (186 = recommended hdelay for PAL).
Unfortunately, analog tv has been terminated in my area and my last
analog sat receiver broke some months ago. I can't test anything any
more :-/
Ciao, ET.
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list