determining capturing area (long post) [Archive]

Arachnotron

7th November 2003, 15:46

I tried to test a number of capture cards to determine the active area each of them captures. Since I lately saw a lot of postings about resizing I post the results here. It’s a long post, with some off-topic DVD info, but I hope someone is interested in it :D

Capture cards do not detect the active area in a video signal. A capture window is programmed by the driver into the capture chip, and whatever part of the signal falls in this area is converted to the number of pixels/lines chosen by the user. Knowing which picture area is actually captured is important to determine how to crop /resize to get the aspect ratio correct.

I got the idea to use my DVD player as an analogue test source to see what exactly the area is some capture cards capture. A DVD player works at 27 MHz, so each pixel in the original picture will take up 1/13.5 microsecond in the resulting analogue signal. My player, a Pioneer DV-535 can deliver a PAL, PAL-60 and a NTSC signal. Also, my employer recently bought a 100 MHz storage oscilloscope which enabled me to exactly map out the composite signal generated by the DVD player and to find out in which video lines the pixels end up.

I used an NTSC and PAL test DVD with a test clip made from a BMP file using Avisynths imagereader command. (You get the best results using a white on 50% grey test picture)

Some info on the analogue signal from my DVD player:

In PAL mode, (720x576), horizontally 8 pixels are cropped of before playback. Only 712 pixels (3-714) are in the signal, an active area of 52.74 microseconds. Pixel 3 starts 9.79 microseconds after the horizontal sync. A 1.5 Microsecond front porch at the end of the line brings the total to 64 microseconds.
Vertically, the first 3 lines are cropped. In the output signal, line 23 contains the WSS (wide screen signal) signal, a digital code which shows up as an alternating grey /black line at the top of some captures. Testpic line 4 is first line of the original picture, in line 336 of field 2. The last testpic line, 576, ends up F2, 622.
Pioneer decided to include 10 more pixels in the signal then the 702 (52 microseconds) needed. More then 712 pixels would make the active area to wide and interfere with synchronisation.

In NTSC and PAL-60 (720x480), also 8 pixels are cropped. Only 712 pixels (3-714) are in the signal, an active area of 52.74 microseconds. Now Pixel 3 starts 9.34 microseconds after the horizontal sync.
Vertically, no lines are cropped. The first field is in line 23-262, the last field in 286-525
The WSS signal is in lines 20 and 283, well above the capture area of most cards.

Unfortunately, this is not standard for all DVD players. While a pixel will always be 1/13.5 microseconds, the exact crops will vary. Also, for PAL the frame will start with the WSS signal in line 23, but what comes next varies.

A Sony DVP-NS300 in PAL displays only pixels 13-714 horizontally, exactly the PAL standard 702 pixel/52 microseconds active area. It crops only the first testpic line and replaces it by the WSS signal, output in F1, line 23.
Now line 2 of the testpic is the first displayed line, in F2, 336. The bottom 4 testpic lines are cropped , making testpic 572 the last line output in F2, 622.

By the way, by cropping I mean replacing with something else, either a black line or a synchronisation signal. So the aspect ratio doesn’t change.

Armed with this info I could calibrate some capture cards by capturing the DVD players s-vhs signal and looking how many of the original pixels showed up in the capture.

I begged/borrowed/bought some capture devices:
Terratec Cameo Grabster 200 (SAA7113)
TerraTec Cinergy 400 (SAA7134)
Hauppauge WinTV Radio model 662 (BT878)
Hauppauge WinTV PCI FM model 747 (CX23881)

Since with most chips the capture area is programmable, it is the combination of capture chip AND driver version which determines the capture area. (with the BT878 / Bttweaker combination you can even change it on the fly), so for the BT878 I also tested two alternative drivers , BTWincap and IULabs.

The results are in the post below.

Arachnotron

7th November 2003, 15:47

edit dec 6th 2003
I found some inaccuracies in these numbers. Some are 1 or 2 pixels off.
for example:
25, 9-712, 704, 10.2, 52.15, BT878, BTWincap v5.3.6.1
this should be 702 ITU pixels, 52 µs.

I will re-check them and be back later with corrections if needed in this thread:
http://forum.doom9.org/showthread.php?s=&threadid=66191

Columns:

1.First videoline captured
2.pixels from the test DVD showing up in the capture
3. active area length in ITU 13.5 MHz pixels
4. Horizontal delay in microseconds (time from hor. sync to start active area)
5. active area in microseconds
6. capture chip
7. Driver version used

PAL:

25, 9-712, 704, 10.2, 52.15, BT878, BTWincap v5.3.6.1
23, 15-710, 696, 10.7, 51.56, BT878, Hauppauge WDM v3.35 b 21125
23, 15-710, 696, 10.7, 51.56, BT878, Iulabs universal WDM v3.1.28.36
23, 13-708, 696, 10.5, 51.56,CX23881, Hauppauge WDM v2.75.21070
23, 3-722, 720, 9.8, 53.33, SAA7113, Terratec Cameo Grabster 200 USB v3.05
22, 10-713, 704, 10.3, 52.15, SAA7134, Terratec Cinergy TV 400 WDM v1.2.0.5

NTSC:

23, 2-713, 712, 9.3, 52.74, BT878, BTWincap v5.3.6.1
23, 17-704, 688, 10.4, 50.96, BT878, Hauppauge WDM v3.35 b 21125
23, 17-704, 688, 10.4, 50.96, BT878, Iulabs universal WDM v3.1.28.36
24, 16-703, 688, 10.3, 50.96, CX23881, Hauppauge WDM v2.75.21070
22, 0-719, 720, 9.1, 53.33, SAA7113, Terratec Cameo Grabster 200 USB v3.05
22, 8-711, 704, 9.7, 52.15, SAA7134, Terratec Cinergy TV 400 WDM v1.2.0.5

PAL-60:

290?, 16-714, 699, 10.3, 51.78, BT878, BTWincap v5.3.6.1
22, 8-711, 704, 9.71, 52.15, SAA7134, Terratec Cinergy TV 400 WDM v1.2.0.5

- For all cards/drivers I captured at different resolutions (640, 704, 712,720 and 768)
but this dit not change the capture area.
- there is an possible error of ca. 1 pixel
- some cards started capturing before the active area of my dvd player. The starting pixel numbers
given are extrapolated in this case.
- the Cameo grabster can only capture at 720 pixels horizontally
- The BTWincap driver in PAL-60 mode for some reason shifts down 9 lines into the next frame??
Swaps fields? Bug?

Standardisation is a beautifull thing !!!

scharfis_brain

7th November 2003, 16:15

when using Bt-8x8-Tweaker, you can manually change the timings (captured area and image shift)

Arachnotron

7th November 2003, 17:08

Yep, I know. Unfortunatly, Vdub doesn't work with all wdm drivers :(

scharfis_brain

8th November 2003, 01:09

would be cool, if someone could enhance this tweaker to show the number of captured (active) pixels per line.

THAT would avoid every confusion about AR...

trevlac

8th November 2003, 02:10

Excellent Info. :D

I am new to understanding this. I thought, based upon the BT878/9 doc that the chip gave back a fixed active pixel count. Now I understand that the drivers set the registers as explained on page 29 of the doc.

So, if I tell my WDM app (iuVCR) to cap NTSC at 720 using the iuLab driver, I am getting a picture that is streatched by about 4.6% (720*100/688) = 104.6 ?

Arachnotron

8th November 2003, 12:47

@sharfis_brain:

I don't know if it is possible to read the chip registers back after they have been set. Woudl be a cool option considering the number of BT878 drivers out there.

A generic util would be even nicer, but this would have to be familiar with all the different capture chips.

In the meantime, using a DVD player to calibrate seems the best option. And of course, you have to do it only once...
...until the next driver release that is.

@trevlac:

Correct.

I read on the IUlabs page their driver can be configured through the registry, but I could not find any info on this.

Wilbert

8th November 2003, 16:57

Something I don't understand:

In PAL mode, (720x576), horizontally 8 pixels are cropped of before playback.
By the way, by cropping I mean replacing with something else, either a black line or a synchronisation signal. So the aspect ratio doesn’t change.
So, 8 pixels of your dvd are replaced with 8 black lines. How do you know this? Because they don't show up in your captures?

PAL:
23, 3-722, 720, 9.8, 53.33, SAA7113, Terratec Cameo Grabster 200 USB v3.05

Where the third column is "active area length in ITU 13.5 MHz pixels".

Shouldn't that be 712, or does it contain those 8 black pixels?

Arachnotron

8th November 2003, 18:03

So, 8 pixels of your dvd are replaced with 8 black lines. How do you know this? Because they don't show up in your captures?

No, because they don't show up in the signal coming out of my DVD player when I looked at it using an oscilloscope.

At my work there is an electronics depertment which owns a 100 MHz storage oscilloscope which understands TV signals. When you connect a dvd player to it you can 'walk' through the signal line by line. Great stuff! :cool: :cool: :cool:

By making a test dvd with a picture with an easy recognisable pattern I could exactly determine which pixels of the original DVD mpeg file made it in the outgoing signal.
I simply took a 720x576 bmp picture, and made the background black.
I then made a 2 pixel wide, 20 pixel long vertical line on the left and a one pixel wide on the right.
beneath that I added a 3 pixel wide line on the left and a 2 pixel wide line on the right. etc. etc., untill I reached the bottom of the picture and the line was 30 pixels wideleft and 29 right.
At the top and bottom I added a 4 pixel horizontal line.
In the middle I added a 2 pixel wide vertical line
The BPM I converted to an AVI with avisynth, encoded with tmpgenc and wrote to a DVD.

( I can mail you the test pictures if you want)

The signal in field 1 on a scope shows this:

line 1-6 sync
line 7-21 black
line 22 non-WSS digital signal
line 23 WSS signal
line 24 white
line 25-31 single spike in the middle (so the sides are missing!!)
line 32-81 line with spike on the left and in the middle
line 82-307 line with spike on the right and middle and left
line 308-309 white line
line 310 black
311-313 sync

so, line 21 of the MPG ends up in line 32 of the TV signal. At this point there are 3 white pixels on the left. The lines above that, with two pixels on the left show no white at the beginning of the signal. Pixel 3 is the first pixel actually ending up in the TV signal.

Remember, ITU-R BT.601 only specifies which pixels MUST be in the signal (9-710 inclusive for PAL), not that ALL must be in them.
In that sence, my Sony (displays 13-714) is not compliant, but my Pioneer DVD player (displays 3-714) is. Of course, what gets lost in the overscan area of the TV is a separate issue.

Because of the nature of an analogue signal, which is difficult to describe without pictures, a 52 microsecond active area has some disturbance on either side before the signal is back to stable black level. ( it takes time for an analogue signal to go from black to white level, and there can be some oscillations) Putting all 720 pixels in the signal would result in al extra 1.33 microseconds of signal, but the total area would be even wider then 53.333. This could interfere with either the colorburst on the left or the horizontal sync on the right. Older analogue TV sets might lose sync because of this. So all DVD manufacturers will crop of some pixels before generating a signal, but exactly which ones will vary.

Where the third column is "active area length in ITU 13.5 MHz pixels" Shouldn't that be 712, or does it contain those 8 black pixels?.

yes. As I wrote at the bottom: - some cards started capturing before the active area of my dvd player. The starting pixel numbers given are extrapolated in this case
The missing pixels would show up as black in the capture

trevlac

9th November 2003, 04:18

I found a tool "BTtool" that reads all of the registers of a BT8x8.
http://moretv342pl.republika.pl/bttool.zip

You of course have to open your cap app and set the cap size & preview.

Given this, you can (i assume) calculate your readings for a driver.(BT8x8 only) I only did testing on the iuLabs and BTwincap drivers.

To calculate active pixels/microsec (your col 3 & 5), I do the following calc:

(HScale / 4096 + 1) * HActive / CLKx1 = microsec * 13.5 = Pixels

Where:
HScale and HActive are register values given by BTtool
CLKx1 is 14.31818 for NTSC or 17.73 for PAL (BT sample rate)

For Example: I set the iuLabs driver to 720x480 NTSC. BTTool gives HActive = 720 (0xD0) and HScale = 56 (0x38)

[56/4096 + 1] * 720 / 14.31818 = 50.973 microsec * 13.5 = 688 Pixels

I only tested with the 2 drivers on my Aver BT878 card. Mainly NTSC.

Edit: I also tested with the BTwincap 5.3.5 driver. It's active, scale, and delay values are the same as the newer driver. The nice thing about this driver is that it lets you cap NTSC at 754, which seems to give back the original samples of the active. No scaling, more info, ect.

Arachnotron

9th November 2003, 15:04

Great! So we now have independent conformation my measurements are correct.

For BTWincap 5.3.6.1, NTsC, 720x480 I get:
HActive = 0xD0 = 720
HScale= 0x38 = 204

[204/4096+1] * 720 /14.31818 = 52.79 = 712.7 pixels

By the way, v 5.3.6.1 is marked 5.3.5 internally.

The nice thing about this driver is that it lets you cap NTSC at 754, which seems to give back the original samples of the active.

I am not so sure about this one.
I think capturing directly at the target resolution is better then capturing as high as possible and scaling down afterwards.

Lets take the case of a composite NTSC signal. Only one of the two 8 bits ADC's is used in this case. Assume 712x480 capture resolution.
The BT878 now samples at 28.63636 MHz. (Not 14.31 !! with an 8 bits ADC, you need a minimum of 2 8 bit samples to get one 16 bit pixel.)

This gives 1822 8 bit composite signal samples per line. The Hscale and Hactive register values determine which part of the samples are in the active region. 1512x8 bit samples in this case.
These samples go in to the combfilter/scaler digital filter calculations, which from these 1512x8 bit samples interpolate the desired 712x16 bits YUY 4:2:2 pixels.
YUY4:2:2 means that you have 8 bits luminance per pixel, but 16 bits (or 2x8 ) chroma info shared between 2 pixels. So, color resolution is now down to 356x480!

However, each color value is 'placed' with 28.6 MHz accuracy and based on 4.2 raw samples/value. The boundary between two color values is detemined within 1 raw sample accuracy, or 62.79/1512 = 0.035 microsecons

If I sample at 754x480, I get the same calculation. I now have 376 color valuse, based on 4.0 composite samples per value. The result is a 376 color valuse/active line grid. This is used as the input for resizing to 712 pixels.
color accuracy is now down to 52.79/376 = 0.14 microseconds.

These are very crude calculations, and the actual process and math will be much more complex. But I hope you see the point I am trying to make. By using an intermediate step, you throw away a lot of information which was there in the original sample. So, more blurring

I think the reason you don't notice this so much is that in most analogue sources, there is not so much 'color resolution' to begein with.

I am currently looking for a good stable test source to see if I am right in this. Unfortunatly, I dont think a DVD player is good for this.

Arachnotron

9th November 2003, 16:35

This gives 1822 8 bit composite signal samples per line.

Oops! I just realised a mistake. chroma and luma are intermingled in a composite signal. So some 8 bit samples cary luma info, some chroma and some both; the comb filter sorts them out afterwards and produces the desired number of pixels.

The calculations for this make my head hurt :rolleyes:

In any case, I still think it is better to stay close to the original samples and avoid an extra round of resizing.

trevlac

10th November 2003, 03:15

I can also confirm (using BTtool) your col #2 readings. Active picture position on a 720 pixel line.

The formula I used is: 13.5/CLKx1 * HDelay * [HScale / 4096 + 1] - DigBlank = Start Pixel (offset from start of 53.333 line)

Where:
CLKx1 = 14.31818 NTSC or 17.73 PAL
HDelay and HScale are read from BTtool
DigBlank = 122 NTSC or 132 PAL (I'm not 100% sure of this, but it works. These numbers came from this: http://www.intersil.com/data/tb/tb368.pdf

For Example (BTwincap @720x480):
13.5/14.31818 * 126 * [204/4096 + 1] - 122 = 2 (whole pixels)

The most interesting thing I got from this is that the NTSC samples I looked at from BTwincap and iuLabs where not exactly from the center of the 720 line. BTwincap was 2 to the left, and iuLabs was 1 to the right. At 704x480, iuLabs was 2 to the right, or 18-705 not 17-704(NTSC). Also, from your results, it seems Hauppauge decided to center "better" with thier CX driver.

Originally posted by Arachnotron
In any case, I still think it is better to stay close to the original samples and avoid an extra round of resizing.

First I must say, I am really a novice. I'm not trying to dispute anything, just match it to what I've read, and understand. :) You've really contributed to my understanding. I would not had any idea of how to calculate the above numbers without the insites from your tests.

http://www.conexant.com/servlets/DownloadServlet/100600B.pdf?FileId=443

From the fusion 878A doc pg 2-1 (link above)
The Fusion 878A requires an 8 × Fsc (28.63636 MHz for NTSC and 35.46895 MHz for PAL) reference time source. The 8 × Fsc clock signal, or CLK x 2, is divided down to CLK x 1 internally (14.31818 MHz for NTSC and 17.73 MHz for PAL). CLK x 2 and CLK x 1 are internal signals and are not made available to the system. UltraLock operates at CLK x 1 although the input waveform is sampled at CLK x 2 then low-pass filtered and decimated to CLK x 1 sample rate.
At a 4 × Fsc (CLK x 1) sample rate there are 910 pixels for NTSC and 1,135 pixels for PAL/SECAM within a nominal line time interval (63.5 µs for NTSC and 64 µs for PAL/SECAM). For square pixel NTSC and PAL/SECAM formats, there should only be 780 and 944 pixels per video line, respectively. This is because the square pixel clock rates are slower than a 4 × Fsc clock rate; for example, 12.27 MHz for NTSC and 14.75 MHz for PAL.

This means they sample at 28.6 and get 910 pixels (NTSC) ? It does sound like there is only 1 sample rate. For NTSC you always get 910. I take it this means 754 is the unscaled original active picture sample. Or as close as there is using a driver.

So I'd think 754 was not scaled by the chip. 712 is. 754 gives you more info from the chip. Some would suggest more accurate post capture filters at 754 than 712.

For practical purposes, most of this stuff is splitting hairs. :D :D

Wilbert

10th November 2003, 10:46

@Arachnotron,

They mention the value 754 on page 25 of Bt878-879 doc:

An alternative method for determining the HSCALE value uses the ratio of the scaled active region to the unscaled active region [1] as shown below:
NTSC: HSCALE = (754/HACTIVE - 1)*4096

HACTIVE = desired number of pixels per line of video, not included sync or blanking.

[1] I guess this should be the other way around: unscaled divided by scaled.

Arachnotron

10th November 2003, 22:39

Hi Wilbert!

(O dear, another too-long post :o )

Yes, I saw it. 754 is the number of pixels you get at 14.63636 MHz when you assume an active NTSC area of 51.5 microseconds.

Using this number is merely a convenient method of explaining the formula. You can read this as HScale gives the ratio between unscaled and scaled.
But as Trevlac pointed out, equally valid would be this: native sample rate / desired sample rate.

for ITU-R BT.601, you would get [(14.31818/13.5)-1]*4096 = 248 = 0x0F8

At 712x480, using btwincap, Hscale is set at 0xFD = 253

so the sample rate becomes 14.31818/[(253/4096)+1]

This equals 13.485. Close enough I guess :)

As a result, Hscale determines how many pixels per complete line should be generated from the raw samples. This cannot be a 1:1 relation, otherwise Ultralock wouldn't work. There must be some form of interpolation for this to function.

HActive sets how many of the resulting pixels should be in the active area, and is set directly by the chosen horizontal capture resolution.

Hdelay sets at which point the active area starts, and simply gives the number of scaled pixels between Horizontal ref and start of active area.

If you want to go full ITU with these chips:

for NTSC 720x480
Hscale=0xF8
HActive=720 = 0x2D0
HDelay=122 = 0x7A

(Now if someone could hack this in the BTwincap drivers(and fix PAL-60 while they were about it. ;) You could capture directly at ITU 720x480 and dump the whole thing to DVD without any resizing. :D )

What my little (perhaps somewhat incoherent) rant was about is this:
I don't think those 754 actually ever exist as an intermediate step in the chip to be resized to the final resolution.
The chip takes 8 bit samples at 28.6 MHz, and from this generates in one step a set of 16 bits pixels at the sampling rate set by HScale, with number of pixels chosen in HActive and skipping the number of blanking pixels set in HDelay.

If this is true, capturing at high resolution (754) and sizing down later (712) gives worse results then capturing directly at 712.

As a final argument: the CX23881 has a new register calles "Y/C Separation Notch Filter Selection and Total Pixel count"
This register allows you to set a different comb filter combination depending on the OUTPUT frequency. (page 6-66)
Now, if you would first generate pixels at 14.318 MHz and resize them afterwards, what would be the point to this. You would only need one comb filter setting, optimised for 14.318 or 910 pixels/total line...

@trevlac: Yes, I am definitly splitting hairs here :D :D :D :D

trevlac

11th November 2003, 04:54

Originally posted by Arachnotron

#1
As a result, Hscale determines how many pixels per complete line should be generated from the raw samples. This cannot be a 1:1 relation, otherwise Ultralock wouldn't work. There must be some form of interpolation for this to function.

.....

#2

If this is true, capturing at high resolution (754) and sizing down later (712) gives worse results then capturing directly at 712.

#1 - I'm not sure what you mean by cannot be 1:1. Hscale can not be zero? You can set it to zero in vdub tweaker. (And check it with BTtool. :) 132 Delay + 720 Active + FP "what's left" = 910

#2 - So to follow this logic, then to make an SVCD, one should cap at 474 not at 712? Direct at 474 would yield better results than 712 --> filter --> resize to 474. :(

Arachnotron

11th November 2003, 13:17

#1

No, I mean that since you capture analogue, the exact number of samples varies somewhat per line, and can be lower than 2x910.
Ultralock will from the actual number of samples interpolate the desired number of pixels (and combfilter them in the same step)

Of course, this will break down if the line length has become so short, the number of samples per line/2 < desired number of pixels set in HScale. It actually says so somewhere in the BT878 doc's. (Don't know where, I'm at work right now)

What happens in this case I don't know. My guess would be you get 14.318 pixels padded with junk on the right. (Try capturing 768x480 in NTSC and see what happens, I think it will look something like that)

#2 You mean capturing at 474 and padding to 480? I'm not so sure what happens here. On the one side you avoid the extra round of resizing but on the other hand you provide less info for the filters. My guess is the filters are more important here, so you would be better of capturing at max resolution, so 754 > filter > 474

With the 754 > filter > 712 resize I definitly think you lose more in the resize than you gain with the extra info for the filters.

But, as I said before, the math of this is way beyond me :(

And of course, especially at the higher resolutions the difference becomes theoretical since VHS does not have that much detail anyway.

But I'm a purist, and this bugs me ;)

Wilbert

11th November 2003, 13:45

Three small questions (if you don't mind):

No, I mean that since you capture analogue, the exact number of samples varies somewhat per line, and can be lower than 2x910.

1) Why are you talking about _twice_ times 910?

2) How do you know that the exact number of samples varies per line? How much percent?

3) What is the number of samples per lines roughly (why is it not 910)?

Arachnotron

11th November 2003, 14:09

@ Wilbert

All answers below are for NTSC and BT878:

@1
samples per line = 8 bits /28.6 MHz
pixels per line = 16 bits /14.3 MHz

@2
It says so in the BT878 manual on the pages about Ultralock; because of head movements, tape artefacts and whatnot the actual line may take a little longer or shorter to finish. A VCR is a mechanical device after all, and 63.5555 is the ideal line length around which the actual value will fluctuate a bit. How much? I don't know. Should be in the VCR specs somewhere.

But because the sample rate is fixed by a crystal /PLL combination that generates the needed Clk, the number of samples/second is fixed, so if the time a line takes to finish is a bit shorter than usuall, you get less samples on it.

@3
the numer of 8 bits samples is line length x sample rate
= 63.5555 x 28.6363636 = 1820 8 bit samples
So under ideal conditions, if your signal is exactly according to spec, you can get a maximum of 910 unscaled 16 bit pixels out of it.

trevlac

11th November 2003, 14:38

@Arachnotron

I think I understand what you mean. Going from samples to pixels is not the same as going from pixels to pixels. I'm still tyring to reconcile that with the 878/9 doc.

It's good to see you think you get more out of the extra pixels for SVCD. If you did not, this would really shift my understanding. I did mean 474 and pad. Perhaps 712 + pad to 720 --> 480 is better/ more clear.

I have captured at 768x480. The image is left justified, with the xtra on the right looking like an initialized buffer (zeros). Like the background of your avatar. :p

Purist or not, this kind of understanding lets one make the right decisions in practice. For example, if the ultra clock sample->pixel process intoduces less error than 754->712 post, then what's the point of doing 754? 754 also takes a bit more disk space. :D

@Wilbert

Here would be my reading based upon my recent increased (hopefully) understanding.

1) pg 13: "the input waveform is sampled at CLKx2 then low pass filtered and decimated to CLKx1 sample rate."

You get 28.6363 (CLKx2 NTSC) samples which are reduced to max 910 pixels. CLKx1 is 14.31818 for NTSC.

2) It says in the description/example of ultralock, the line length may vary.(pg 13-14) The purpose of Ultralock is to get you back to 910. How much variation would depend upon your source. Any variation means that 910 (754) is not as good as the smallest number (the shortest line). Assuming the smallest sample number is greater than your desired length, untra lock is interpolating down. 858 (712) should be good. 910 (754) requires interpolation up. Up is not good.

3) This depends on the line length. 63.555 is expected. I don't know what the variation could be. If you ask for 712, you should get interpolation down as long as the line length is > 60 microseconds. 60 * 14.31818 = 859.

trevlac

11th November 2003, 15:07

@Arachnotron

I didn't read your reply before I replied. I think I'm getting closer. :)

One thing I still don't get is this 16 bit pixel thing. My understanding of ADC is (for 601 spec), the sample is 8 bit or 10 bit. The difference is basically the granulatity of the sample on the waveform. 10 bit gives you a bigger scale, hence a more accurate sample. I've seen this (I think) by looking at a resolution pattern (from avia) on my BT878 and my CX2881 (I just got it). The BT gives about 360 TVLh, and the CX does about 450.

Now how do we get from that to 16 bit pixel? I actually don't know what a pixel is to the BT878, before it goes to YCrCb.

Arachnotron

11th November 2003, 15:17

@ trevlac

Understand the purpose of specsheets like this. It is the purpose to let someone program the chip, and to give formula's in such a form programmers can understand them. Programmers understand pixels, but things like pixelclocks are a bit much in formula's ;)

Explaining exactly how it works would only help the competition, so many details are (over)simplified.

But there are some clues. Did you notice that the graphs describing the comb filters are all given with a target pixel clock? This to me suggest that resizing and comb filtering are done in the same step, not in separate steps as some of the logical diagrams suggest.

So, 8 bits signal measurements go in (an ADC is just a digital volt meter after all) at 28.6 MHz intervals, and are routed through a digital filter (comb/scaler/pixelengine) chain which outputs pixels at the desired pixel clock at the other end. The manual calls this decimation, but why would you trow away half of your samples?

The horizonal ref signal indicates when a new line starts.
So you take all the samples between two horizontal reference signals and generate from those samples the number of pixels needed for a theoretical perfect 63.555 line.

If the real line is shorter than this, you still generate(interpolate) this number if pixels. This is what ultralock actually does.
No matter how many samples it gets between horizontal ref signals, it allways interpolates the number of pixels per line set by HScale.
You then crop off hdelay pixels on the left and output Hactive pixels from the remaining pixels.

Arachnotron

11th November 2003, 15:29

Now how do we get from that to 16 bit pixel? I actually don't know what a pixel is to the BT878, before it goes to YCrCb.

At the start what you have is a 8 bit / 10 bit 28.6 MHz digital representation of the actual waveform. No pixels.

The digital comb/scaler/pixelengine chain calculates Y Cr and Cb values for this. If you have set Hscale to 13.5 MHz, you get an
13.5 MHz Y and a 6.75 Cr and Cb 'signal'

In a device like this grabster, which is locked at 27 MHz with a 9 bits ADC and has no scaler, you would get a one-on-one relation like this:

9 9 9 9 ADC 4 samples
gets YUY 4:2:2 4 pixels
8 8 8 8 Y (8 bit per pixel)
8 8 Cr
8 8 Cb (8 bit shared between 2 pixel)

The BT878 and CX sample at a higher rate and do have a scaler, so the actual pixels may be 'out of sync' with the samples and will have to be interpolates.

By the way, the CX can generate both 8 and 10 bit YUY 4:2:2

trevlac

11th November 2003, 17:21

On pixels (trying to figure it out):

4 8 bit samples (4 at the CLKx2 rate for what is a 1/13.5 pixel) go to 32 bits of pixels (2 16 bit pixels). 4x8 samples --> 2x16 pixels

If we have 4 9 bit composite samples (27mHz) from a 1/13.5 microsecond signal, we must turn them into 2 16 bit pixels YUY2?
Y0 U0 Y1 V0 is 32 bits where of the original 36 bits of samples, you get 8 bits of luma, 4 bits of U chroma, and 4 bits of V chroma.
I'll work on thinking about this when HScale is involved.

From your yanyan link, the CX appears to have 2 ADCs that come into play when you use s-video. 1 does luma, the other chroma. (I've only gotten to page iii) :D

So in this case, one gets 8 10 bit samples (4 chroma / 4 luma) over (lets call it 27mHz) a 1/13.5 microsecond signal. From this, I'm sure I only get 2 16 bit YUY2 pixels.

I assume 80 bits of samples to 32 bits of pixels is better than 32 sample bits (8 bit chip) to 32 pixel bits.

Of course, the optional part of (8 vs 10 on the CX) may be at the start and not the end. However, it seems working at 10bits until you get pixels makes more sense than working at both thru the process.

I can say from s-video, there is a bunch more horz. resolution on the CX vs the BT.

Edit: removed dumb comments on 10bit YUV2. :o

Arachnotron

11th November 2003, 17:58

one pixel has either 8 bits or 10 bits luma (y)
one pixel shares an 8 bit (or 10 bit) Cr value with its neighbour
one pixel shares an 8 bit (or 10 bit) Cb value with its neighbour

So total is 8 + 4 + 4 = 16 per pixel
(or 10-5-5 =20)

So if resolution is 720, it actually is only the resolution for luma.
The colour difference valuse /chroma resolution is only 360 !!

this is the 4:2:2 in yuy 4:2:2.

this is why I suspect resizing after the pixels are formed is a bad idea.

The CX2399x works internally 10 bits, and you can choose of it generates 10 bit or 8 bit YUY 4:2:2 (and dumps 2 bits)

Most Phillips chips are 9 bits internally

for all cards (not just the cx23881) there are 2 ADC's

If composite or TV you use only one and comb filter afterwards, the second ADC is used for radio etc.

If s-vhs, you use one ADC for luma, one for chroma so theoretically you should be able to increase the bit depth. Not the resolution! You now have 2x8 bits (2x10 bits) of info, but they are taken at the same time, so sample rate is still 28.6 MHz!!

Most cards keep the combfilter running even when the source is s-video. Try running in s-video with only Y attached. You will find there is still some color left.

Arachnotron

11th November 2003, 18:21

@trevlac

I really should take the time to read something befor I jump in, :o

As far as I can see we agree on this.

I can say from s-video, there is a bunch more horz. resolution on the CX vs the BT.

I did not really notice this (I have both.) How did you compare this?

The CX23881 comb filter is much better, but for s-VHS this is not an issue. Sample rates and thus horizaontal resolution are the same, but color precision might be better.

trevlac

11th November 2003, 18:24

Originally posted by Arachnotron
If s-vhs, you use one ADC for luma, one for chroma so theoretically you should be able to increase the bit depth. Not the resolution! You now have 2x8 bits (2x10 bits) of info, but they are taken at the same time, so sample rate is still 28.6 MHz!!

But doesn't an increased bit depth, improve resolution also? If I measure a wave in (whole) cm vs mm (vertically down the wave), am I not getting less error? I see why increasing the sample rate would give me a better (digital) picture, but I thought a better depth would also imporve resolution.

If this is not the case, I can't understand my test results. Maybe they improved their calculations from samples to pixels.

I wanted to thank you for all of this information. I'm going to stop asking questions and read/test more to imporve my understanding. If I don't, I might have to pay for the full seminar. :D Do you accept paypal ? :D :D

trevlac

11th November 2003, 18:31

Originally posted by Arachnotron
How did you compare this?

I ran the 200 TVL chart from the AVIA video test DVD. From my cheap shinco DVD player thru a monster s-video cable to the s-video on the cards. I then eyeballed the horz res pattern. Vertical is about the same. Not quite 480. The pattern probably does have color signal. I can see 'rainbow' on some parts of the pattern. I'll post a clip of each horz chart if you want. Can't do it right now.

Arachnotron

11th November 2003, 18:44

If I don't, I might have to pay for the full seminar.

Hey, I just started with this stuff. Just making it up & learning as I go along. I really am an absolute beginner, no kidding! Don't accept anything I tell you at face value, I could very well be totally off the mark!! :D

As to resolution, I suppose that depends on the definition of resolution you use.
Here, the number of samples stays the same, but the samples themselves are more accurate.
To put it in annother way, the number of samples in time determine the shortest 'event' you can detect. There is something called Nyquists formula, which I cannot reproduce or understand :) , which states that in order to catch something that happens at a certain frequency, you should at a minimum sample at double that frequency.

So at a sample rate of 27 MHz, only changes at 13.5 MHz can be observerd.
actually, since higher frequency events can mess up measurements, they are filtered out before sampling (this is called anti-aliassing)

The sample rate stays the same even with 2 ADC's, since they are clocked by the same source. So at 27 MHz, the best you can see is a 1/13.5 microsecond event. Anything smaller then a 1 ITU pixel wide event will be missed. But if a measurement takes place, it is more precise.

Be carefull you have optimised hue/contrast settings with a histogram filter/plugin before comparing anything. Otherwise you might not be using the full bithdepth. I allways found the default settings of my Hauppauge CX based cards a bit dark.

trevlac

11th November 2003, 21:31

As far as Nyquist goes, I believe 13.5 is already double what is needed for NTSC and PAL. PAL frequency is 5.5, NTSC is 4.5MHz. Here are some references:

http://www.quantel.com/domisphere/infopool.nsf/HTML/dfb135MHz?OpenDocument

http://cnyack.homestead.com/files/modulation/ntsc_sig.htm

I don't fully understand this, but I'm getting closer. BTW: 14.636 seems to be the rate to sample composite analog to composite digital. 13.5 is a reference to component digital. The Video Decoder stuff seems to be a conversion from composite digital to component digital.

Link I would like to full read given the time:
http://www.tektronix.com/Measurement/cgi-bin/framed.pl?Document=/Measurement/App_Notes/DigitalTV/glossary2.html&FrameSet=television

Edit: What this means to me is that a 13.5 chip (phillips) does the comb first then samples. Brooktree samples and combs in digital. Haven't read the philips doc. *** This is wrong. Reading the doc, the SAA7134 does take a composite signal and combs in digital. It also scales.

Arachnotron

12th November 2003, 11:14

As far as Nyquist goes, I believe 13.5 is already double what is needed for NTSC and PAL. PAL frequency is 5.5, NTSC is 4.5MHz. Here are some references:

I wondered about that one, but I believe these are the limitations for the broadcast signal. When I capture from a DVD by s-video, I can capture single pixel events, al least B&W (single pixel white horizontal lines on 50% grey background)

Another thing is (but again the math is beyond me :) ) that if you have a 4.5 and a 5.5 signal superimposed on each other, the interference patterns can have double this frequency, which leaves you with a minimum sample rate of 2x5.5x2 = 22 MHz. But I am shooting from the hip here.

What this means to me is that a 13.5 chip (phillips) does the comb first then samples. Brooktree samples and combs in digital. Haven't read the philips doc

All chips comb digital. The Philips saa713x and CX comb filters are only more advanced (adaotive). Comb filtering in analogue before sampling would look horrible (There are some links about this inthe capture guide)

13.5 is a reference to component digital

No, it is a reference to ITU-R BT601.5, which gives a standardised pixelclock for digital to analogue and vice-versa conversions.

I think Philips decided to sample at exactly 27 MHz to make conversions easier and to be able to tack on a hardware MPG encoder.
The saa7113 was probably designed for such an application originally.
For conexant chips, you need a separate scaler to do this (In fact, the CX has such a scaler(2.6.4.1)

Also consumer level equipment often works on this clock (a DVD player has a 27 MHz crystal, videocards a 13.5 MHz for the TV out chip)

There are capture chips sampling at other rates than 28.6 or 27 MHz
Nyquist gives a lower limit, you can go higher.

trevlac

12th November 2003, 13:55

I'm not making this component/composite stuff up. I am "quoting" a reliable source: Tektronix. Maybe I'm unclear on what I am reading... but I have read in multiple places that:

- 601 is for Digital Component Video
- SMPTE 244M is Digital Composite Video
- There are 2 analog domains (component/composite)
- You can convert from/to each

Rec. 601. Recommendation ITU-R BT.601 (formerly CCIR Recommendation 601) is not a video interface standard, but a sampling standard. Rec. 601 evolved out of a joint SMPTE/EBU task force to determine the parameters for digital component video for the 525/59.94 and 625/50 television systems. This work culminated in a series of tests sponsored by SMPTE in 1981, and resulted in the well known CCIR Recommendation 601.

The composite video signal is sampled at four times the (NTSC or PAL) subcarrier frequency, giving nominal sampling rates of 14.3 MHz for NTSC and 17.7 MHz for PAL. The interface is standardized for NTSC as SMPTE 244M and, at the time of writing, EBU documentation is in process for PAL.

See my tektronix link above for the source.

Edit: Here is another good source...
The SMPTE 244M standard sets the sampling frequency at four times the subcarrier frequency, or 14.3181 MHz (14.3 MHz nominal). The sampling clock is derived from the analog signal's color burst.

http://broadcastengineering.com/ar/broadcasting_understanding_composite_digital/

3.58 is the NTSC color subcarrier. 3.58*4=14.318 :) Conincidence ?

I don't have the **full picture :D . But in this item, I think you are totally off the mark!!

** Full picture is a reference to the original topic :D

Arachnotron

12th November 2003, 14:27

We've been covering so much ground, I'm beginning to loose track on what it is I'm off the mark about.

I think we may be using different terms for the same thing.

[QUOTE]See my tektronix link above for the source.

I will do that (I already downloaded them a while back for info about using an oscilloscope on video signals, but never got around to actally reading the stuff)

I'll be back! (O dear, I believe that's now a political statement :D )

Arachnotron

12th November 2003, 16:09

Still havent found time for reading, but realised something else:

There probably are two ways to look at sampling rate, and that is where the difference comes from :

Documents dealing with digital streams look from the pixel side.
I have an analogue signal in which one line is represented by 910 digital pixels. Therefore my sample rate is 14.3. Most documents dealing with digital conversions will look at it from this side.

If I look at it from the analogue side, my argument goes a bit different; given the minimal width of a single peak in in the analogue signal, how many voltage measurements must I take in time to accurately reproduce this digitally. Now my sample rate becomes 28.63636 MHz.

The sample rate for the ADC's is 28.63636 MHz, but the sample rate of the whole chain going from analogue signal up untill the final digital representation is 14.318

It is the last version of sample rate which is used in most documents dealing with digital video.

What do you think? Doe shis make sense?