On Sun, 2008-10-12 at 12:56 +0200, Hans Verkuil wrote: > On Sunday 12 October 2008 04:24:04 Andy Walls wrote:
> > 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. Ah, I found the source for the numbers. It's related to the Horizontal refresh rate and the BT.656 13.5 MHz pixel rate and 27 MHz sample rate. (I scrounged up a copy of the VESA VIP 2 spec and the reference material in the back helped me figure it out.) For NTSC: (286/4.5 MHz) * 27 MHz = 1716 samples or clocks per horizontal line 1716 = 1440 Y & UV samples + 4 EAV bytes + 4 bytes SAV + 268 HBI clocks Those 268 horizontal blanking interval clocks are used for ancillary data insertion. For PAL: (1/15.625 kHz) * 27 MHz = 1728 samples or clocks per horizontal line 1728 = 1440 Y & UV samples + 4 EAV bytes + 4 bytes SAV + 280 HBI clocks Again the 280 horizontal blanking interval clocks are used for ancillary data insertion. So the CX25843 really does provide every byte of data it can for raw VBI and Ancillary data (sliced VBI). It's also safe to assume that these numbers will be different for square pixel modes (which we don't use). I also bet there may be side effects with hardware scaling and cropping in the AV core (which I don't think we do in ivtv and cx18). > 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. Yup. I'm climbing the learning curve before I do any experimentation though. > 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. I haven't done any research on this. Given the codes that get injected into the VIP ancillary data, I wonder if it's just a matter of not having the right codes being handed over to the MPEG encoder. Regards, Andy > Regards, > > Hans > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
