bttv 2.6.16: wrong VBI_OFFSET?

[Edgar Toernig]

Hi,

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?

The reason I ask is because it broke the teletext decoder AleVT.
The teletext standard defines where the clock run-in pulses
have to lie (13th bit at 12us/-1us/+0.4us).  For the complete
16 bits of clock run-in that comes down to 9.2us for the start
of the first bit and 12.9us for the end of the last bit.

Here are two oscilloscope shots showing the difference between
offset 244 and 128 - the red line is the interval 9.2us-12.9us:

	http://goron.de/~froese/vbi-offset244.gif
	http://goron.de/~froese/vbi-offset128.gif

As one can see, offset 244 fits very well.  The clock run-in
lies where it's expected.  With offset 128 it's completely
off - no way to find it at that position.

One can also see that the sampling starts somewhere within
the color burst, not at the trailing edge of hsync as some
comment in the code may imply.

Ciao, ET.


PS: In bttv_vb_try_fmt code was changed from 32 to 64 bit
arithmetic:

|        /* s64 to prevent overflow. */
|        count0 = (s64) f->fmt.vbi.start[0] + f->fmt.vbi.count[0]
|                - tvnorm->vbistart[0];
|        ...

What should that change fix?  These values will never overflow -
they fit into 16 bits each.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/