On Wed, 29 Dec 2004, Steven M. Schultz wrote:
> > bt848 datasheet. 52.15 is used by VCDs, DVDs in 704x480 mode, and 640x480
> > square pixel captures.
>
> Hmmm, for square pixel sampling the frequency is not 13.5MHz - it's
> 12.2727 (actually 12 + 3/11) MHz.
Yep, and if you divided 640 pixels by 12 3/11 MHz you get 52.15 microseconds,
the same things you get if you divide 704 pixels by 13.5 MHz.
> TV stations when they are broadcasting a digital stream use 704x480.
> That's also what they use internally (well, they use 486 lines
Are you sure about that? D1 video is 720 pixels at 13.5 MHz, as specified in
the ITU-R.601 standard. I know that if you check most (all?) DVDs, you will
find that they do in fact have 720 pixels (@ 13.5MHz) of information. The 8
pixel border on each side is not just black.
> analog processing. It doesn't make sense to get 720 samples where
> only 704 were broadcast. Does it?
There are reasons to get 720 samples when you only care about the inner 704,
which is why R.601 specified 720 samples and not 704. Many scaling and other
image processing algorithms have edge effects. The extra border provides a
safe area for processing artifacts that keeps the important part of the image
clear. Another reason is that while a digital image has no trouble putting a
0 value black pixel next to a full value white pixel, such a singal cannot be
created by analog systems as it would require too much (as in infinite)
bandwidth. Starting the picture early provides a safe border for ringing
effects caused by the change from the blanking interval to active pixels.
> It might also be possible to dig around in the bttv-driver.c module
> in the kernel and combine that with the Bt8x8 datasheets (which I had
At which point you would find...
.v4l2_id = V4L2_STD_NTSC_M,
.name = "NTSC",
.swidth = 768,
.totalwidth = 910,
.scaledtwidth = 910,
xsf = (width*scaledtwidth)/swidth;
geo->hscale = ((totalwidth*4096UL)/xsf-4096);
HSCALE is the register of interest, it controls the effective sampling rate.
So for NTSC, after some algebra:
HSCALE = (768 / width - 1) * 4096
And with a little math and the datasheet:
Effective Sampling Rate = 14.32 MHz / (HSCALE/4096 + 1)
Combine the two...
Effective Sampling Rate = 14.32 * (width / 768)
and
Width = Effective Sampling Rate/14.32 * 768
So, 13.5 Mhz you would want to request a width of 13.5/14.32 * 768 or 724
pixels! If you ask for 720, you're getting a sample rate of 13.425 MHz.
I think the driver is wrong to set swidth to 768, which gives a capture length
of 54.63 us. Better would be 764, for a capture length of 53.33 us, the R.601
standard. I'm guessing 768 was chosen because it's divisible by 16, but
I can't see any reason why this value needs to be divisible by 16.
> All in all it's an area I'm glad I moved out of :)
But do you know what sample rate your canopus is using? It's supposed to use
13.5 since it's DV, but does it? Without datasheets and a driver to dig
through, how can you know?
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
