On Sunday 12 October 2008 04:24:04 Andy Walls wrote:
> I'm trying to puzzle out the VBI stuff with the CX18-AV-Core
> implementation. After staring at the CX25843 dtatsheet for longer
> than I would have liked, I think I've figured out where a few of the
> magic numbers come from:
>
>
> cx->vbi.raw_decoder_line_size = 1444; /* 2 * 720 + 4 byte frame hdr
> */
>
> 720 active VBI line samples at the 13.5 MHz pixel clock or 1440
> samples at twice the pixel clock (27 MHz).
>
>
> cx->vbi.raw_size = 1456; /* 1456 % 16 == 0. Real size is 1444 */
>
> 1444 rounded up to a multiple of 16.
>
>
>
> But where do these come from (aside from me culling them out of
> ivtv)?:
>
> cx->vbi.sliced_decoder_line_size = 272; /* 60 Hz: 272, 50 Hz: 284 */
> cx->vbi.sliced_size = 288; /* 288 % 16 == 0. Real max size is 284?
> */
>
> I can't quite figure these out. Looking at line 5 of figure 3-16 of
> the CX25843 data sheet and columns D,E,F of table 3-27, I assume the
> 272 is related to the amount of ancillary data that can be sent in a
> frame. Maybe for the busiest 60Hz VBI service (the little used NTSC
> TeleText)? I can't quite figure out the relationship. I'm also
> stumped on the 284 number and it's relationship to 50Hz standards.
It's all trial and error. What happens is that the cx2584x slices the
VBI data and outputs it to the cx2341x. And the cx2341x stores it in
memory in the format described in the source. Unfortunately the
documentation for the cx2584x is not terribly good and it isn't
documented at all for the cx2341x. It's best to consider it to be a
black box and just try to interpret the format from hexdumps.
In the case of the cx23418 sliced VBI capture is also quite different
from ivtv since it has it's own stream. That should actually make life
easier. I am also wondering whether it is possible to let the cx23418
insert the sliced VBI directly in the MPEG stream. This never worked
right with the cx23415/6 so ivtv needs to splice the VBI directly into
the MPEG stream, which makes for a complicated driver.
It would be nice if the cx23418 firmware could do this by itself.
> BTW, I figured these out by actually reading the CX25843 datasheet
> and assuming they apply:
>
> /*
> * AV Digitizer SAV/EAV codes in VIP 1.x mode
> * Task Field VerticalBlank HorizontalBlank 0 0 0 0
> *
> * Task: 0 in VBI and raw data, 1 otherwise
> * Field: 0 odd field, 1 even field
> * VerticalBlank: 0 in start of non-reset VBI, 1 at end of vertical
> active * HorizontalBlank: 0 not in h blank, 1 in h blank
> */
> cx->vbi.raw_decoder_sav_odd_field = 0x20; /* V */
> cx->vbi.raw_decoder_sav_even_field = 0x60; /* FV */
> cx->vbi.sliced_decoder_sav_odd_field = 0xB0; /* T VH */
> cx->vbi.sliced_decoder_sav_even_field = 0xF0; /* TFVH */
>
> Given that the av digitizer is fixed in the CX23418, I think these
> can be turned into defined constants for the cx18 driver. Also I
> can't ever see using BT.656 mode over VIP, given that the MPEG
> encoder is fixed too.
Correct.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
