Messages in this thread | | | Date | Mon, 24 Apr 2006 19:02:00 +0200 | From | Edgar Toernig <> | Subject | bttv 2.6.16: wrong VBI_OFFSET? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |