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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
