bttv 2.6.16: wrong VBI_OFFSET?
- From: Daniel Glöckner <daniel-gl (at) gmx.net>
- Date: Sat, 6 May 2006 05:51:54 +0200
On Fri, May 05, 2006 at 06:34:48AM +0200, Edgar Toernig wrote:
> Concerning Daniel's diagram, it looks nice but I have some doubts whether
> his calculations are 100% correct - it looks too strange especially the
> completely different pattern when HSFMT is changed.
I took more measurements using /dev/vbi instead of VIDEO_PALETTE_RAW.
The vbi lines are still long enough to capture the next 0H.
According to these my Fusion 878A Rev 11 does the following:
- it 'rounds' {64,48,32,16}[HSFMT] to integer HSCALEd pixels.
- on these it adds 2 or 3 HSCALEd pixels (2 if you used ceil(),
3 if you used floor()).
- after that time has passed it waits for another 60 CLKx1 (59~60.5;
when using VIDEO_PALETTE_RAW ~64)
You get something like this:
CLKx2delay=2*(60+(ceil((64-16*hsfmt)*4096/(hscale+4096))+2)*(hscale+4096)/4096)
The 'rounding' is probably done using a Bresenham like accumulator.
Its fractional value at the beginning of a line can vary. Thus the
beginnings of VBI lines need not be the same in a field. They can have
one of two values, up to 32 CLKx2 samples apart.
I didn't test VBI_HDELAY.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list