As much as I wanted you to be wrong about the horizontal scaling, this
is now making sense, and you seem to be correct. I wanted to stay in my
comfortable world of capturing in yuv4mpeg format with a nice 720 or 704
pixel line, although I wondered why the color seemed to be off. Thank
you for your patience.
Now I have to find quality software to downscale from a crazy number of
pixels and downsample the chroma from yuy2 to yuv12 for mpeg encoding.
Anybody have any recommendations? Are such tools available yet? Am I
reading the spec correctly that yuy2 (packed 4:2:2) is the native format
for the bttv?
By the way, is the swidth value the current number of active pixels
without scaling? This seems to agree with the calculations in
bttv_calc_geo. If so, it's 768 in the 0.9.11 driver:
.v4l2_id = V4L2_STD_NTSC_M,
.name = "NTSC",
.Fsc = 28636363,
.swidth = 768,
.sheight = 480,
.totalwidth = 910,
.adelay = 0x68,
.bdelay = 0x5d,
.iform = (BT848_IFORM_NTSC|BT848_IFORM_XT0),
.scaledtwidth = 910,
.hdelayx1 = 128,
.hactivex1 = 910,
.vdelay = 0x1a,
.vbipack = 144,
.sram = 1,
Trent Piepho wrote:
On Mon, 22 Dec 2003, Robert W. Fuller wrote:
I've been thinking about this and reading specs on NTSC and the BT878.
A 720 wide pixel line is typically achieved using a scanning line period
of 53.33 microseconds. This is considered an overscan. A 704 wide
Yes, CCIR601 specifies a sampling rate of 13.5 MHz. 720 pixels / 13.5 MHz =
53.33 us. An entire line is 63.55 us long, but some of that is blanking and
sync pulse. 53.33 us cuts out the blanking and sync, but there is still
more of the line captured than would normally be displayed on a TV. You
will be capturing some black space and/or garbage on the edges. Cut off that,
and you get 704 pixels or 52.15 us.
For NTSC, the bt8x8 captures at 14.32 MHz (and only 14.32 MHz), more than the
13.5 MHz specified in ccir601. A full NTSC line will have 63.55 us * 14.32
MHz ~= 910 pixels. Of course, some of that is blanking. If you captured the
equilivent of a ccir601 720 pixel line, that is 53.33 us, you would have 764
pixels. A 704 pixel line (52.15 us), with overscan cropped, would be 746
pixels at the bt848's sampling frequency.
The datasheet gives a value of 754 active pixels, which gives a captured
length of 754 samples / 14.32 MHz = 52.65 us. That's halfway between CCIR601's
"720 pixel" line length of 53.33 us and the "704 pixel" length of 52.15 us.
In other words, the bt8x8 datasheet's idea of NTSC active line length captures
less overscan than CCIR601, but more overscan than CCIR601 does when cropped
to 704 pixels.
When you request a certain horizontally sized image from the bt8x8 V4L driver,
the driver must decide how to scale AND crop the image.
The length of the image you capture could be 53.33 us, or 52.15 us, or 52.65
us, depending on how much overscan you want to capture. The length of the
captured portion of a line, in microseconds, is hard coded into the driver.
And historically, different versions of the driver have changed this around.
But none of this changes the fact that when you request an image width of 720
pixels, that image is getting scaled by the bt8x8. The HSCALE register is not
getting loaded with a value of 0, it's as simple as that.
consistent with page 26 of the spec which talks about the BT878 using a
63.8 microsecond scan to read 913 pixels. Surely with a 63.8
microsecond scan period, you will be outside the normal picture borders.
The 63.8 us scan of 913 pixels was an example of a longer than nominal line
length, caused by the poor signals typical of a VCR or other low-quality
source.
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
