On Monday 22 December 2003 11:40, 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 pixel line is normally achieved with a scanning line > period of 52.15 microseconds and is considered an exact scan. At > least in the NTSC realm, I think that if you ask the BT878 for more > than 704 pixels, your mileage may vary, perhaps including black > borders. This seems 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. > And also beyond the end of the line as defined from the leading edge of synch to the leading edge of the next synch pulse. For never twice the same color, that is 63.333333333333 microseconds IIRC and I'm a broadcast engineer. From that 63.33333etc microseconds, we are allowed to use 1.5 microseconds as the front porch of the synch, 4.7 microseconds as the synch itself, plus enough back porch to contain at least 8 full cycles of the reference color burst at 3.57954545454545 hz, that usually being determined by referenceing the whole thing to a 5mhz rhubidium standard, typically accurate to about 13 digits if its running at all. Thats a close as you can get the dividers for a 3.58000000000 subcarrier, or .45hz off. Commission tolerance is 10hz, but most systems will fall apart somewhere long before we're that far off. Generally speaking, the space/time occupied by the various pieces of a synch pulse are assumed to occupy between 10.7 to 11.1 microseconds maximum, which leaves 52.2 microseconds of active video per line. That said, the typical system is often under 52 microseconds due to timing miss-matches from point a to point b, which may cause a very small edge clip on one side or the other in the real world. >Thus, I think if you ask for more than 768 active PAL square pixels > or 720 CCIR601 pixels, you're likely to see black borders. > Similarly, for NTSC, asking for more than 640 square pixels or 720 > CCIR601 pixels is likely to produce black borders. > >Tuukka Toivonen wrote: >>On Fri, 19 Dec 2003, Trent Piepho wrote: >>>>>resolution do you have to capture in with a BT8x8 to ensure no >>>>> hardware down scaling is done? >>>> >>>>With my BT878: 768x576. I live in PALland, I don't know about >>>> others. >>> >>>No, that's wrong. For NTSC it is 754, for PAL it's 922. See page >>> 26 in the datasheet. >> >>I don't care about the datasheet, I care what happens in reality. >> If I tell xawtv or other V4L programs to capture in more than >> 768x576 all I get is a 768x576 picture with black borders. If I >> ask only 768x576 capture, the black borders are gone but the >> actual image is still the same. And even that is still much more >> than what a real TV would display. >> >> >>-- >>video4linux-list mailing list >>Unsubscribe >> mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe >> https://www.redhat.com/mailman/listinfo/video4linux-list > >-- >video4linux-list mailing list >Unsubscribe > mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
