By Date: <-- -->
By Thread: <-- -->

bttv 2.6.16: wrong VBI_OFFSET?

On Mon, 2006-04-24 at 23:55 +0200, Edgar Toernig wrote:
> matthieu castet wrote:
> >
> > > in 2.6.16 the code in driver/media/video/bttv-vbi.c was changed
> > > a little bit.  Beside other things, the constant 244 for the vbi
> > > offset was replaced by a #define VBI_OFFSET 128.
> > > 
> > > Afaics, the old value 244 was correct - was the change to 128
> > > intentionally?
> 
> 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.

I'm the moron responsible for this change. I compared video scan lines
captured as VBI and video data. 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.

Presumably 128 slipped in because the spec suggests an offset of 64
fCLKx1 clocks. I think the spec is correct because changing the HSFMT
bit and VBI_HDELAY gives the expected results. They just didn't mention
another delay of 64 clocks. May I suggest the fix below.

> Regarding the 64 bit arithmetic there's this:
> 
> | - V4L2_(S|TRY)_FMT did not expect very large or small VBI start or
> |   count values, returning wrong (but safe) counts due to an overflow.
> 
> Wow, previously the driver produced (safe) garbage when given garbage
> and now it produces more accurate (safe) garbage???  I don't get it.

No it does not produce garbage. When for example an app requests -1U
lines starting at 16 it gets 16-38, the current maximum. Previously it
might have got 15-15. It was safe because the driver didn't allocate
4 GB buffers or something.

> [My suspicion is that it was only inserted to shut up warnings...]

I have another patch adding cropping support and removing all VBI
limits, complicating things quite a bit. My regression tests feed the
driver with zeroes, negative and absurdly large values. It was indeed
inserted to shut up warnings when comparing different driver versions.

Michael

diff -Nurpid v4l-dvb/linux/drivers/media/video/bt8xx/bttv-vbi.c v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-vbi.c
--- v4l-dvb/linux/drivers/media/video/bt8xx/bttv-vbi.c	Fri Apr 21 03:21:06 2006
+++ v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-vbi.c	Tue Apr 25 07:07:59 2006
 (at)  (at)  -32,10 +32,11  (at)  (at) 
 #include "bttvp.h"
 
 /* Offset from line sync pulse leading edge (0H) in 1 / sampling_rate:
-   bt8x8 /HRESET pulse starts at 0H and has length 64 / fCLKx1 (E|O_VTC
-   HSFMT = 0). VBI_HDELAY (always 0) is an offset from the trailing edge
-   of /HRESET in 1 / fCLKx1, and the sampling_rate tvnorm->Fsc is fCLKx2. */
-#define VBI_OFFSET ((64 + 0) * 2)
+   bt8x8 /HRESET pulse starts at 0H and has length 64 / fCLKx1 (E|O_VTC
+   HSFMT = 0) + 64 / fCLKx1 (undocumented). VBI_HDELAY (always 0) is an
+   offset from the trailing edge of /HRESET in 1 / fCLKx1, and the
+   sampling_rate tvnorm->Fsc is fCLKx2. */
+#define VBI_OFFSET ((64 + 64 + 0) * 2)
 
 #define VBI_DEFLINES 16
 #define VBI_MAXLINES 32

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