On Fri, Sep 11, 2009 at 4:56 PM, Andy Walls <awalls@xxxxxxxxx> wrote: > + /* FIXME: hard-coded for NTSC support */ > + format->fmt.vbi.sampling_rate = 6750000 * 4 / 2; /* FIXME: ??? */ > > The BT.656 Pixel clock for both 60 Hz and 50 Hz systems is 13.5 > Mpixels/sec. Unless you switch to PAL or NTSC square pixel timing for > some reason, I would expect this particular number to stay the same for > both PAL and NTSC. > > A pixel in BT.656 consists of 1 Y sample and 1 U or V sample. So, in > the VBI active line regions, I would have expected 2 * 13.5 Msamples/sec > for VBI data. I don't know if any app in userland actually pays > attention to this number though.... > > Regards, > Andy Hey Andy, Well, when I said "hard-coded for NTSC support", I was referring to the entire block of code that followed, not just the one on the sampling rate. I expect the line count and start offsets to be different for PAL as well. In reality, the "???" was because I actually didn't know what the proper value needs to be. I copied it from another driver without fully understanding its role, and changing it caused userland to break (zvbi-ntsc-cc in this case). Worth noting that we are actually delivering 8-bit VBI info, as opposed to 16-bit yuyv (there are some USB bandwidth issues I'm actively working and doing 16-bit put me over the limit), so I'm not confident that the generalization for ITU656 applies. As I get the PAL support working, that area will certainly get some cleanup... Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
