Capture Resolution - Are you sure? [Archive] - Page 2

trevlac

3rd January 2004, 03:03

Originally posted by Arachnotron

The 2.7 MHz strip comes trough clearly, the 3.4 MHz strip very very faintly. It is hard to see because of color interference patterns (the same that were in your caps in the 3 MHz circle)
I'll do some extra strips between 2.7 and 3.4 to narrow it down.
VCR pic (http://www.arachnotron.nl/temp/vcr_cutout.bmp)

Of course, my VCR is PAL, so it sounds about right, 354 lines.
The question is, where is the limit? During recording, in the tape format or during playback.

Well, I don't know much about VCRs, but your comments made me do some research. It looks like the manual for a HRS7950 says it does 250TVL for VHS. So I'm guessing when you say 354 you mean the full width of 4:3 pixels, not TVL. 354 would still be about 265 TVL, so you seem high. What do the wedges tell you in the Avia resolution pic?

Also, the tape does not limit the resolution. My machine seems to be able to record SVHS on a VHS tape. It's called JVC Extended Technology or something like that. After some searches, it seems people have been turning VHS tapes into fake SVHS tapes for some time, so, I'd say there is not much to the JVC ET thing.

Some other things to note: (I can't really confirm, but this is generalized from info I've read)

- VHS is a seperate thing from PAL and NTSC. It does not have the color and luma mixed. It's called 'color-under' format. Frame rate seems to be the only real difference.

- Different VCRs have better resolution. A low number given for luma resolution is 2.5MHz. This was in a video engineering book. I could not find a high VHS number, but 3.4 may be it. 5MHz is almost always given for SVHS.

- As I mentioned above, you can record SVHS on a VHS tape. Also it's interesting to note that a PAL tape moves slower (due to the frame rate difference).

FredThompson

3rd January 2004, 04:26

Originally posted by trevlac Sampling Theory says "A signal can be reconstructed from its samples without loss of information, if the original signal has no frequencies above 1/2 the sampling frequency. (Nyquist)". Without loss of information. The converse of this is that a higher sampling frequency gets you nothing. In practice there are a number of problems. 1st is that if you do have frequencies above 1/2 the sampling frequency, you introduce aliasing or digital noise. This is where a higher frequency blends with a lower frequency at a given place in the picture.

The MHz bandwidth limits of a number of formats are as follows: vhs=3, NTSC broadcast=4.2, SVSH=5, PAL broadcast=5 to 6, DVD/DV=6.75In a word, no.

Nyquist is so incorrect an assumption that it's amazing anyone who has ever drawn a sine wave would consider it valid. Properly sampling an analog wave requires samples of at least 4x the sampled frequency. Even 2x is insufficient.

Draw a simple sine wave and put a dot at one of the places where it crosses the Y axis. Congratulations, you just simulated sampling at 1x to yield a value of 0. Acording to Nyquist, this is an accurate representation of the wave. Now put a second dot at the other place where the wave croses the Y axis. Now you've simulated sampling at 2x to yield an "accurate" representation with a value of 0.

That's all irrelevant for video capture unless you're doing the capture in the frequency domain. Your Brooktree chip doesn't allow you get get that type of data.

Also, analog recordings are not segmented into pixel-friendly clocked segments. They are continuous analog signals. All those statements about the X resolution of some form of analog recording are "best-fit" approximations. Television is not a giant X-Y graph like a computer monitor, it is a stacked set of analog signals. Specs which describe how a particular analog recording type should behave are representations of general behavior in the X-dimension. It follows, therefore, that the X dimension is best sampled with as many values as possible.

Throwing out the incorrect assumptions about fitting analog information into a digital domain, your real question is the performance characteristics of a particular Brooktree device. To minimize distortion, you should capture in such a way that you are using the actual summary values from the sampling hardware with a 1:1 sampling in the Y axis corresponding to the recorder's output, not something extrapolated from them. THAT is your real question.

Ivo can give you exhaustive information wrt the performance of Brooktree devices. Look for him at Everwicked or neuron2's site. IIRC, he's working on an article about capture with Wilbert. He's got tech specs for Brooktree devices.

Arachnotron

3rd January 2004, 12:25

@ trevlac: the number is for the whole 52 µs. And the result is very faint, so the cut-off is probably somewhere lower.

@FredThompson

I have wondering about this for some time too. I am new to this, so please be gentle :)

I have been trying to replicate some test patterns for DVD by mapping the value of a sinus as an 8 bit greyscale in a 720x480 grid, at various frequencies and been failing miserably whenever I came above about 3.4 MHz.

Look here ( http://www.arachnotron.nl/temp/vcr_test.rar) for a RAR file with a BMP with strips at 6.75, 6.33, 5.92 .. 0.92 MHz (6.75-0.92 in 15 steps) and the interference patterns you get when you get near 6.75 MHz. 6.33 looks like a 6.75 signal with (6.75-6.33) MHz superimposed.

Nyquist is so incorrect an assumption that it's amazing anyone who has ever drawn a sine wave would consider it valid. Properly sampling an analog wave requires samples of at least 4x the sampled frequency. Even 2x is insufficient.

I went back to some articles (the math is still beyond me :( ) and came up with this:

Nyquist is correct, but only under very strict circumstances AND only for a whole analogue-digital-analogue cycle, so including the reconstruction of the analogue signal before playback:

1. You must filter out anything above the sampling frequency /2 (avoid Pre-aliassing);
2. The samples must be 'spikes', so no averaging the signal over a short time interval;
3. when you reconstruct the signal, you must use a perfect low pass filter/sinc function(?), (avoid post-aliassing).

In the real world, none of those conditions are ever met, so you must go much higher in sampling rate. When determining the sample rate, you must also consider the mechanism used to reconstruct the signal on playback.

My test pic may result in a correct analogue signal when played back on a DVD player, provided it reconstructs it right. (It uses something that looks line a sinc function. I still have to try this, I'm not completely sure).
But when you zoom in on a computer screen, you are effectually breaking the chain and stay in the digital domain. You could say you are reconstructing using a square pulse, and all sorts of horrible interferences result (even apart from wat the screens pixel grid does). A software DVD player will probably filter for things like this to some extend.

Interesting question: does this mean the sampling rate requirements for devices that will play back to TV (i.e. reconstruct the analogue signal first) are lower than for files that you will watch directly on a PC?

In any case, from your comments the optimum sampling resolution for my 27 MHz SAA7134 will be 712x480 since at that res the sampling clock is 'in sync' with the generated pixels.

edit
On monday I have access to an oscilloscope once more. I'll burn my testpic to DVD and see what kind of signal I get back and where it stops being a perfect sinus. I'll post the resulting screendumps here.

Wilbert

3rd January 2004, 14:53

Ivo can give you exhaustive information wrt the performance of Brooktree devices. Look for him at Everwicked or neuron2's site. IIRC, he's working on an article about capture with Wilbert. He's got tech specs for Brooktree devices.
No, I'm not working on an article with Ivo. I'm working on an article with the people participating in this thread. So, feel free to jump in ...

Btw, I'm working on a smoother comparison (noisy sources) with Ivo. This project is delayed quite a bit due to AVSEdit.

trevlac

3rd January 2004, 21:49

Fred,

Thanks for your post, and your invite to neuron2.net. I'm not a programmer, but have been having some fun with the vdub filter tutorial. I truely want to learn digital signal processing, and what better way than by writing some filters?

You must forgive me, I am just learning the sampling topic. Unfortunately, I do not follow your arguments. You have left gaps I can not jump. I will try to read posts at neuron. I am also trying to tackel EE books. Maybe they are too much theory. :)

Originally posted by FredThompson

Premis
Nyquist is so incorrect an assumption that it's amazing anyone who has ever drawn a sine wave would consider it valid.

Conclusion
Properly sampling an analog wave requires samples of at least 4x the sampled frequency. Even 2x is insufficient.

Support?
Draw a simple sine wave and put a dot at one of the places where it crosses the X axis. Congratulations, you just simulated sampling at 1x to yield a value of 0. Acording to Nyquist, this is an accurate representation of the wave. Now put a second dot at the other place where the wave croses the X axis. Now you've simulated sampling at 2x to yield an "accurate" representation with a value of 0.

Support?
That's all irrelevant for video capture unless you're doing the capture in the frequency domain. Your Brooktree chip doesn't allow you get get that type of data.

I don't see or follow your support for your premis or conclusion.
Here (http://www.broadcastpapers.com/testmeasurement/TektonixDTSystems&Meas202.htm) is a link to what seems to be a reasonable source that talks as if Nyquist is valid. As I tried to state, Nyquist seems to 'fail' (if you want to call it that), because one generally needs to filter the signal to go from A to D and D to A. Easier filters seem to be the reason for higher rates. The BT878 does not filter 1st, but super samples (28MHz NTSC) so it does not have to filter 1st. It then uses a digital filter and decimation to get to 4fc (14.32 NTSC). It is really the filters that 'fail' because they are not sharp enough. Nyquist is valid. Super samples have nothing to do with more information, but with less aliasing.

Also, analog recordings are not segmented into pixel-friendly clocked segments. They are continuous analog signals. All those statements about the X resolution of some form of analog recording are "best-fit" approximations. Television is not a giant X-Y graph like a computer monitor, it is a stacked set of analog signals. Specs which describe how a particular analog recording type should behave are representations of general behavior in the X-dimension. Conclusion It follows, therefore, that the X dimension is best sampled with as many values as possible.

Well, you make many statements but I'm not clear what's valid and how they fit your conclusion. Here I'd like to adjust the discussion a bit and talk about the mighty analog signal. An analog signal represents life already sampled along the y(height) and z(time) axis. There are a discrete number of scan lines and a discrete frame rate. Appearently these are good enough and where picked as a trade off of bandwith and the value you get from higher sampling rates. There are limits to what your eye can see, and what your brain preceives. These limits were considered when a 59.97 field rate and 480 scan lines were selected. So I don't yet understand the 'as many as possible' conclusion. Y and Z are limited from 'real life'. We are just talking about x which has a limited bandwidth of information anyway.

your real question is the performance characteristics of a particular Brooktree device. To minimize distortion, you should capture in such a way that you are using the actual summary values from the sampling hardware with a 1:1 sampling in the Y axis corresponding to the recorder's output, not something extrapolated from them. THAT is your real question.

I'd like to generalize, but I would say one should know their equipment. There is no doubt that differences can be vast. As far as a 1:1 sampling, I don't see how this is practical. A BT878 samples at 14.32MHz for NTSC. This must be decimated to reach any sort of display standard. If you mean interpolation by the chip is better than on pixels, I'd say yes for the BT and no for an ATI, from some simple tests, but why is then my question.

I'm sticking with my conclusions, but am trying to learn more every day.

Cap > 640x480 gets nothing xtra for NTSC on a BT878. Except maybe a nice size for DVD.

No analog source even gets close to 720x. The best is about 640x576 for China, Uk is about 590x, most of West Europe is 540x (about SVHS), and US is 450x480

VHS is a rotten 320x

Resolution results very much depend upon knowing your equipment

Again, thanks for telling me I am wrong. It will force me to better understand the topic, I may have been getting lazy but Arachnotron generally keeps me on my toes. I don't expect you to teach me, but I hope a newbie such as myself is welcome at neuron2. :)

FredThompson

3rd January 2004, 23:04

I thought this would happen. It can be difficult to discuss things like this without pictures. I'll try to keep this brief. If you want more explanation, let me know and I'll work on something more comprehensive.

wrt Nyquist:

my comments have to do with sample rates. Let's walk through the example and I'll try to explain. First, some background.

Schmidt triggers are the building block of digital storage. When data is read from a drive, it is actually an analog signal determined by the magnetic charateristics of the area being read, right? Those signals, in a time-regulated manner, go through an electrical filter (Schmidt trigger) which decides if they represent a 0 or a 1. There's a dedicated amount of time from which the sample is to be interpreted but multiple ways to make the decision. It could be based on the lead-edge, tail edge, some form of average or another manner. Hope I didn't just lose you. The point is there are many ways to make a time-sliced evaluation of an analog signal.

OK, let's take a look at a basic sine wave with the first part being the positive "hump." Suppose this sine wave perfectly matches the length of the time slice. (Sample time is based on highest source frequency.) There are 3 points in time where the value fo the wave is 0. The average value is also 0. If the evaluation of the wave is taken at any of those points or as an average, the result will be 0 which is obviously a false evaluation. Likewise, if we take a single instananeous value at any time within the time slice we will get a false evaluation. However, if we take 4 instantaneous samples at equidistant timing within the time slice we get four values which show an actual representation of the curve. (How that data is interpreted is another matter; square-wave, triangle-wave, etc.)

There's another discussion of this concept here: http://www.digitalprosound.com/Htm/SoapBox/soap2_Apogee.htm

OK, back to your video capture. There most certainly is a sync used to establish when a particular scan line starts. That's a hard signal coming from the playback device. Your capture card's hardware must recognize that signal. However, at that point, the length and position of the time slices which repesent horizontal travel of the analog signal is determined by the capture card. The playback device is not clocked in such a way, it sends a continuous analog signal. For a tape-based device, the content of that horizontal signal will vary based on the signal on the tape, how accurately it is retrieved and the instantaneous position of the tape as it moves through the playback device. Take a good look at a non-TBC non-digitally-stabilized analog playback. Stationary vertical elements move around the screen and they do this variably by scan line. The result is your digital capture device generates a time-based valuation of a temporaly-variable data source.

I hope you understand what I just tried to explain.

You are correct that the amount of information available per scan line can vary depending on the source. However, remember, it is an analog signal. Finite evalution of "pixels" per scan line is only a guidline representation, especially given the lack of horizontal sync.

OK, so back to how the capture hardware works. IIRC, the Brooktree does a 2x horizontal oversampling. However, that data is not available. Please check with Ivo on this: I think the Brooktree ALWAYS samples with the same resolution and feeds data back after doing internal resizing. Therefore, you would be far better off to retrieve the resolution which matches the actual capture, do your processing, and do whatever resizing you want as a last step. (Some people do resizing then process a little more to reduce visible artifacting from resizing.

640x480 is indeed 4:3 for square pixels. Analog video doesn't use square pixels. It doesn't really use "pixels" anyhow but that's another issue. It uses rectangular elements. The digital video resolutions are based on their analog predecessors. 720x480 more accurately represents the analog signal. The benefit of horizontal capture resolution of 720 or 704 (720 minus overscan) is not that the source can provide that resolution, it is the added benefit of more samples of an analog signal for a given timeframe and accurately reflecting the samples your hardware is actually making.

wrt ATi: I'm not sure which chipsets they are using. The early All-in-Wonder devices had Brooktree components which ATi modified because they said there was a hardware bug in the Brooktree device. OmegaDrive creates modified versions of the ATi drivers. Maybe those would give better results. His drivers do allow video resolutions like 720x480 which are better mapped to analog out.

edit: OK, I just read the beginning of the link you posted. It says 2x highest frequency. That's a very common misconception. Only sampling at 2x could yield the case where both reading catch the wave crossing the 0 point. It depends on how the sampling is done. Frankly, I'm not sure which trigger timing the Brooktree uses. Ask Ivo. My comments about Nyquist were more general, not specific to the Brooktree digitizing process.

Arachnotron

4th January 2004, 01:14

Brooktree devices (BT878 and CX2388x) sync on the midpoints of the falling edges of the horizontal sync pulse.

FredThompson

4th January 2004, 01:29

So it's triggered at some point during the later half of the time dedicated to take a sample, does that twice horizontally and yields a combined result from the 2, correct?

Didn't Ivo (or was it you) mention there is stretching happening if you try to get 720x480 from the Brooktree devices? It's not actually taking the 8 on either side, correct?

Arachnotron

4th January 2004, 02:02

So it's triggered at some point during the later half of the time dedicated to take a sample, does that twice horizontally and yields a combined result from the 2, correct?

I'm not sure if I understand your question. I just quoted from the spec sheets.

According to SMPTE 170M, the rise time for sync is 140 ns. In this time, a BT878 sampling at 28.63636 takes about 4 samples. ( actually about 5 since rise time is from 10% to 90%). I'm not sure why two samples would be needed for triggering. It should be able to trigger with 35 ns variation. Or is this total nonsense ? :)

Didn't Ivo (or was it you) mention there is stretching happening if you try to get 720x480 from the Brooktree devices? It's not actually taking the 8 on either side, correct?

Correct. Both me and Trevlac did. I did a small page on how to determine this window,here (http://www.arachnotron.nl/videocap/site/capture_area2.html)

The exact window is set by the driver. It looks like drivers that are derived from the conexant reference drivers use a window of about 51 µs for NTSC, but the BTWincap driver uses about 52.7 µs. Any resolution you request is a scaling from this window. The same goes for Philips and ATI devices (but with other window sizes), from tests done by other forum members it looks like a standard capture device issue.

edit I thought a BT simply triggers on the first sample below 50% of Hsync ?

trevlac

4th January 2004, 03:05

@FredThompson,

I don't mean to be rude, but you seem to jump around a bit. It may however, be my lack of knowledge. :) It seems you have 3 main points:

Nyquist is invalid, a sine wave requires 4 samples to recreate.
Variable line length is a problem for capture
"Therefore, you would be far better off to retrieve the resolution which matches the actual capture, do your processing, and do whatever resizing you want as a last step. "

I'd like to try to address these.

#1- Nyquist is invalid, a sine wave requires 4 samples to recreate.

Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples. These samples correspond to only one analog signal, and therefore the analog signal can be exactly resconstucted. AKA, you need to sample at 2x the highest frequency.

A very clear explination of this starts on page 39 of this document. The Scientist & Engineer's Guide to Digital Signal Processing (http://www.analog.com/Analog_Root/static/technology/dsp/training/materials/pdf/dsp_book_Ch3.pdf) You can also get an updated version from amazon. "Digital Signal Processing: A Practical Guide for Engineers and Scientists". Here (http://www.amazon.com/gp/reader/075067444X/ref=sib_dp_srch/103-1528009-6849462?v=search-inside&keywords=proper+sampling) is a link to page 39 on amazon.

With respect to your link.

1st

I believe aliasing in audio is a big problem. The frequency of an audio wave is what is important. Since aliasing misplaces and overlaps frequency components, it directly destroys information encoded in the frequency domain (audio). For video, the shape of the wave is important. A picture can and does withstand aliasing artifacts. So, drawing conclusions from audio may not be valid for video.

2nd

Your link seemed to think Nyquist was valid. It's two points seem to be that 'oversampling' was done so filters would work (as I suggested), and so that frequencies higher than audible range could be mixed to an audible range. Therefore, it would be nice to capture them for post processing.

#2 - Variable line length is a problem for capture
I would completely agree. I havn't really pondered this, but Brooktree seems to do something they call 'Ultralock' to address this problem. You can read about it on page 13 of this (http://www.conexant.com/servlets/DownloadServlet/100119a.pdf?FileId=542) conexant document. They seem to guarantee that you will get synced lines if you ask for pixels that correspond to the shortest line length.

#3 - "Therefore, you would be far better off to retrieve the resolution which matches the actual capture, do your processing, and do whatever resizing you want as a last step. "

Ironically, Arachnotron convinced me otherwise, based upon #2 above. The active line length for NTSC would be 14.32MHz*52.66usec=754 pixels. Using the BTwincap driver, one can actually cap NTSC at 754. However, if there is an active line shorter than 52.66usec, you may be in trouble.

In addition, testing (in this thread) clearly shows that for VHS source a capture size of 368 is overkill. This makes sense because of the bandwidth limits I've mentioned.

Another interesting point is that for the BT878, a 368 capture keeps quite a bit more resolution than a 720 capture and a last step resize. I'm waiting for Wilbert to tell me why. :)

---------------------------------

Anyhow, it appears we don't sync up on this stuff. That's ok, because sampling may be a minor item compared to post capture filtering. I'd say, getting the brightness, contrast, and color saturation correct has a much bigger effect on PQ than our differences on capture. :D

Feel free to correct me on any of the above. Maybe I'll 'get it', or it will help someone else.

trevlac

4th January 2004, 03:13

Originally posted by FredThompson
Didn't Ivo (or was it you) mention there is stretching happening if you try to get 720x480 from the Brooktree devices? It's not actually taking the 8 on either side, correct?

Actually, due to the open source drivers of the BT, there are some nifty ways to read the registers of the chip and see exactly what it is doing. I found it to be quite cool, but I'm a bit of a geek. :D

Arachnotron is being too modest about his 'little page'. It's a great piece of work. I didn't know it was done. :)

Arachnotron

4th January 2004, 03:49

@trevlac and Fred

I think I am beginning to see where Fred is driving at. Please correct me if I am wrong.

Note my previous post in this thread about the conditions which have to be fulfilled for Nyquist to apply.

The two samples per sinus breaks down if your sample is no longer a sampling point, but instead has a time window which approaches the wavelength of the signal you are sampling. If this is the case, it depends on what happens in this time window. If the voltage is followed in this window, and the final value is stored there is no problem.

But if either the highest value in the window is stored or the average value is stored you run into problems since you in effect introduce a second wave function over the one you are sampling (= sampling function ?).

So, what does the sampling function of real world ADC's look like?

Please note I am writing this without any knowledge about the actual workings of ADC's :)

As to hitting zero crossings and Nyquist: This happens only if the samplingrate is exactly 2 * source frequency.

But is this frequency the last frequency to work or the first to fail? I.E. are we dealing with a limit approaching sampling rate/2 ?

trevlac

4th January 2004, 04:20

Originally posted by Arachnotron
The two samples per sinus breaks down if your sample is no longer a sampling point, but instead has a time window which approaches the wavelength of the signal you are sampling.
One day I hope to be able to say something like that and think everyone will understand what the heck I'm talking about...:D You're going to get that EE degree someday. The hell with Fourier transforms.

Anyway, so you mean "2. The samples must be 'spikes', so no averaging the signal over a short time interval;" and what happens when we don't/can't use spikes?

Well I'll have to hit the books to understand this. You keep distracting me from my projects. ;)

As for #1 and #3, I'd say the aliasing we may encounter is not as bad as we think. After all, the cards oversample and filter no matter what you do. The question is, do you get more info from a bigger size for your VHS? Do you damage the picture due to aliasing if you do 1/2D1 vs D1? For both of these, I'm guessing no. I'm also trying to back my guess with tests. You keep getting in the way. :D

Funny thing is that I wanted to grab 754 pixels a few months ago. You got me straight on that. Have I gone too far the other way? ;)

Arachnotron

4th January 2004, 04:39

Anyway, so you mean "2. The samples must be 'spikes', so no averaging the signal over a short time interval;" and what happens when we don't/can't use spikes?

Yep, that's it. Its 4:30 am over here, so my communication skill's have died on me a few hours back :D

#3 is only an issue on (incorrect) playback, but may be mistaken for the result of incorrect sampling.

Tomorrow (monday) Ill play back some of my 6.xx MHz teststrips and see if the resulting signal is indeed a perfect sinus on the scope. Should settle the issue if it is, but doesn't prove it if it isn't.

North2Polaris

4th January 2004, 05:20

Originally posted by trevlac
Funny thing is that I wanted to grab 754 pixels a few months ago. You got me straight on that. Have I gone too far the other way? ;)

@trevlac,@Arachnotron,and Wilbert,

I thank you for the quality of the discussion in this thread. I suspect that we may see more of the senior members adding their perspectives to this discussion.

@trevlac,

As for as going too far the other way, some of your conclusions are starting to sound like some of the advice given at:

http://www.triuneweb.com/sites/lordsmurf-com/capture/software-resolution.htm

On this site, 352x480 is the recommended capture resolution for VHS,"if your software and hardware will give good results at that resolution".

Note the comment about the BT8x8 chipset on this site, "you're pretty much forced to use the maximum resolution of the cards, typically 720x480, if you want to maintain decent quality".

Capturing VHS at 368x480 is a bit heretical.

What next steps are needed to keep this discussion moving forward?

FredThompson

4th January 2004, 06:15

It's midnight and I'm having a little trouble following all the twists and turns of this thread. I think I might be coming down with the flu. Please keep that in mind.

yes, I know what I've typed seems jumpy. This would be so much easier to discuss if we were sitting togehter with paper and pen.

Yes, the example showing a null sample value from a 1x or 2x sampling frequency was an extreme example. Yes, also, to the bit about the characteristics of how the samples are generated is very important. When you boil it down, the capture hardware is measuring an analog voltage in a discreet amount of time, right? ok. Any time analog is converted to digital, there is an aspect of how a sample value is calculated for a given sample period but also how small those sample periods are.

Take a step back from the text or numbers of the theorems and draw a picture of a waveform. Mark some periodic sample points on the drawing then draw horizontal lines to represent that sampled value over time until the next sample is taken. That's what the hardware is doing, right? It's basically taking a sample and holding that value for a period of time. The collection of these samples is to represent the analog waveform. The more frequent the samples, the smaller the time they represent, the more accurately the samples as a set will represent the analog waveform.
Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples. These samples correspond to only one analog signal, and therefore the analog signal can be exactly resconstucted. AKA, you need to sample at 2x the highest frequency.Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples. These samples correspond to only one analog signal, and therefore the analog signal can be exactly resconstucted. AKA, you need to sample at 2x the highest frequency.No. Think of how active noise cancellation works by generating an opposite wave. Thus, there are multiple combinations to reach any value with a common sampling method if you have multiple concurrent waves. For single waves, you could identify commonality similarly to what you suggest here but not recreate unless you are working with pure frequency modulation. If amplitute is different, 2 unique waves could return the same instantaneous samples but be very different.

Think about how NTSC composite comb filters work. Because of domain overlap, it's impossible to separate the signals properly, right?

wrt, variable length lines. I was trying to communicate the lack of enforced horizontal clock creates a slight randomization of the analog stream as it relates to the actual subject it is supposed to represent. If you shoot VHS footage with a tripod of a perfect vertical edge then capture it via analog playback, the samples within each scanline which are supposed to line up exactly, won't. The same thing can happen with pure digital video depending on the resolution of sampling but it's not as pronounced. Think of high-end audio cassette decks like the Nakamichi Dragon. It's got all kinds of controls to normalize the position and movement of the tape because distortion is introduced by every analog aspect of the information transfer. The same thing happens with video tape. Maybe the tape is a little off-position, maybe a spindle binds just slightly for a second, maybe some of the carrier fell off the tape, maybe there's a kink in the tape, etc.

All this discussion is interesting but irrelevant if the Brooktree's really do only capture at one resolution and scale everything after that. Frankly, that would be the smart way to create the circuitry. It would be less expensive. If that is indeed the case, the least lossy way to do your capture would be to use that resolution, ensuring the drivers don't modify it.

trevlac

4th January 2004, 15:06

@North2Polaris

I've had some discussions with LordSmurf. He writes well, but seldom backsup what he has to say with any reference. He almost exclusively uses ATI cards and software for DVD. His comments on the BT8x8 are not based on in depth knowledge. So, I might agree with some of his conclusions, his basis is unknown. He generally just says 'he knows'. I am trying to match a basis to test results. :)

As far as 352 vs 368, the BTwincap driver turns on a filter when you drop the resolution below 362. This can be observed with some tools that read the registers of the chip. This filter effects the vertical resolution even though you are not changing that. So, LS is correct that 352 is 'worse' than 720 even for VHS. This is because VHS has the full 480 resolution and the BT with the filter on does not. Horizontal resolution for the BT with the filter on is still better than VHS. :)

368 is no more 'odd' than 712. 712 is a good number to use for the BTwincap because is matches the captured line length. 368 cropped to 352 will give a bit of a stretched picture, but you don't have to resize after (which oddly enough seems to give less resolution). The stretch is not as much as you might think. 712/2=356, so it's 12 pixels not really 16.

As far as moving forward, my inital intent was to see where I am wrong. My proposition seems very reasonable. I intend to take a good look at Fred's comments. From a quick read, his latest post might be what I was looking for. :)

Thanks

@FredThompson

I can relate to the not feeling well. I had a terrible headache most of yesterday. I appreciate you sticking with me. I need to think about your latest post a bit. I will do some reading to make sure I am following you, before I respond to your latest.

An interesting point about what 'the cards' do is that most all probably capture a 1 resolution and scale to what you ask. Probably for the economic reason you pointed out. :D

I'd guess this is the case for new ATI chip cards, BT8x8, CX cards, and (consumer) Philips based cards and DV devices. I'd have to read more about Philips specs to comment on them. I don't own one of them.

Arachnotron

4th January 2004, 18:18

As far as 352 vs 368, the BTwincap driver turns on a filter when you drop the resolution below 362. This can be observed with some tools that read the registers of the chip. This filter effects the vertical resolution even though you are not changing that. So, LS is correct that 352 is 'worse' than 720 even for VHS.

As I understand it, teh BT878, fusion878 and the CX23881 all have this feature. It is controlled by the SCLOOP register in the 878's and the HFILT register in the CX23881. It is not a smooth transition, but changes at certain resolutions.

00(1) = Auto Format. If you select auto format when horizontally
scaling between full resolution and half resolution, select
no filtering. When scaling between one-half and
one-quarter resolution, use the CIF filter. When scaling
between one-quarter and one-eighth resolution, use the
QCIF filter; and at less than one-eight resolution, use the
ICON filter.
01 = CIF
10 = QCIF (Required for SECAM)
11 = ICON

The Philips SAA71xx do something similar (at least those with a scaler) controlled by the AAF register.

The
filter depth of the anti-alias filter adapts to the scaling ratio,
from 10 taps horizontally for scaling ratios close to 1 : 1, to
up to 74 taps for an icon sized video picture.

Unfortunately, the description of the AAF register is in the User manual (not the Data Sheet) which I have been unable to find. So I have no idea if this filter works continuosly as a function of resolution or swithches at certain fixed resolutions as the BT878 seems to do.

Anyone, please ??? :D

trevlac

4th January 2004, 21:04

@Arachnotron

Interesting quote from the manual. As I understand it, CIF and QCIF are 1/2 and 1/4 in both directions. It suggests turning the filter on regardless if you are doing vertical.

As far as the time of the impulse used to sample (#2 in your prior post), the best as I can tell is that the length does effect the signal, possibly by changing the phase. This seems to be taken care of when the DAC takes place. Can you give a link to where this is pointed out as a problem? Most of the sources I can find gloss over this. I'm assuming with current electronics this is not a problem. I was looking at the BT spec to see what they do about it.

@Fred

It seems we have a fundamental difference. My statement "Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples." Was basically a quote from the source I posted. You seem to disagree with this source, saying that streight lines are used to recreate a signal from samples (not sine curves). If streight lines were used, I'd suppose that the more samples the better. However, It is my understanding that based on work by Fourier, sampling theroy continues that most waves can be modeled as the summation of sine waves. And that given 2 samples per wave, only 1 wave fits this pattern.

However, It does seem we have gotten off track a bit. :D I'd like to restate my premise and reasoning.

Analog video signals have limited information/bandwidth/resolution.

Few signals contain more information than a 640 frame size can contain.

BT chips don't capture any information above a 640 frame size

Reasons

Analog signals have a (generally known) limited bandwidth. This can be directly equated to TVLines which is a measure of resolution. TVL can be directly related to pixel frame size.
BT specs say it filters frequencies above 6MHz
Nyquist is an interseting way to look at this. If you believe pixels are samples, and that reducing the number of pixels reduces the effective sample rate, then you can also talk about required frame sizes from maximum frequencies using nyquist. I fully admit that this ignores the problems of syncing vertical lines and filtering high frequencies. However, the effect of these problems maybe outside of anything we can do, because the cards and drivers either take care of them or don't.

I have posted quite a few sources and will organize them if anyone wants. If you could give sources that I could read that would be great. The one you posted didn't seem to back what you were saying. It is however, difficult to go into much depth in a forum.

line timing
Arachnotron understand this better than me. But this is what the BT doc says:

UltraLock accommodates line length variations from nominal in the incoming video by always acquiring more samples, at an effective 4 × Fsc rate, than are required by the particular video format and outputting the correct number of pixels per line. UltraLock then interpolates the required number of pixels in a way that maintains the stability of the original image despite variation in the line
length of the incoming analog waveform.

So maybe we are just talking about Nyquist for different purposes. I'm interested in what happens after ultralock. Namely, asking for a smaller frame size, because there is no more information in 720 pixels than in 368 pixels for a VHS tape. This is in effect asking for a lower sample rate after nasty things like syncing lines and filtering high frequencies.

As anyone can see, the practical implications is much more interesting than the theory. :D Hopefully the discussion I center around a BT878 can be applied to other chips and cards.

@Arachnotron / @Fred,

I really want to thank you for your feedback. I do tend to try to simplify. You've forced me to read some really good references quite a few times. Each read removes the clouds about Digital Signal Processing. On my next read I may fully understand convolution. (And filter) :D

I do want to print quite a few pdfs to make for easier reading. Here is a great pub you can get for free:
http://www.dspguide.com/pdfbook.htm

That's the full chapter list of the one I mentioned you can get from amazon for about $50 IIRC.

FredThompson

4th January 2004, 22:58

@trevlac, I'm really quite sick right now and can't think through your last post. However, I think I now see what's happening.

Your comment about 2 points representing a sine wave relates to plugging those values into a function, doesn't it? Your capture card doesn't derive or return functions. There's no f(x) return from the card, you get a set of values.

Arachnotron

5th January 2004, 00:28

@everyone: long post alert, sorry! :eek:

@Fred,
Get well soon :) The fact that you are even bothering to post is greatly appreciated.

@Trevlac,

I could not find the site again. They were PPT slides from some sort of university course. But this this (http://www.usna.edu/Users/ee/cameronc/EE462/ExtractsOnADConversionForLecture.pdf) link gives a nice summary of things that can go wrong with ADC's.

@Trev, Wilbert and Fred,

I don't know the first thing about filters. The comments below are based only on my limited experience with curve fitting. Is what I propose technical possible? Or my use of the terms phase and taps? :confused:

In the course of this discussion I have gained more understanding of the operations of capturing devices. I want to have a final stab at painting a simplyfied picture of how I think a BT878 works and the concequences for capturing. Some of it is pure speculation though.
To do that, I first have to explain a bit about how I think interpolation works. I will try to keep the math to a minimum.
To quote Trevlac: this is what I believe today :)

Interpolation
-------------
As an example I'll try to explain polynomial curve fitting, the most simple case (and the only one I have ever used :D )

suppose you have a set of 7 luma values plotted against time,( sampled at 7 MHz). You want to resize them to 4 values (4 MHz). These 4 values would fall somewhere between the original 7 values, on different times. But at these timepoints you have no samples.

The simplest way to do this would be to drop three samples, but this would cause everything to shift horizontally and ruin aspect ratio.

The next thing to try would be to connect the points using straight lines and look up the luma values in the resulting graph for the 4 timepoints we are interested in. As long as you are resizing in small steps, this would work but for big re-sizes you would base an interpolated luma value only on it's two neighbours in the original samples and ignore some of the other samples. Also, if one luma sample were to have an extreme value compared to the rest, it would be over represented in the scaled luma points. Try plotting this to see what I mean.

The third option would be to use something like polynomial regression.
Suppose you have a function A +Bx +Cx^2 +DX^3 + EX^4 +FX^5 (= 6th order polynomial)
x is the time in this equation, A-F are constants that you can calculate by curve fitting this equation to the 7 datapoints. Once you have done this (how is not important for this story), you have values for A-F. Fill in the values in the equation and you have a function which describes a smooth line that touches all points and generates a luma value for each timepoint between the original samples. By filling in this equation you can calculate a luma value for every timepoint you want.
Also, this function will be smooth and have no sudden changes in direction but is flexible enough to be able to touch all 5 points.
Now take away the last component, FX^5, and fit again to the 7 points. The resulting function is less flexible, and will follow the trend of the 7 points and even touch some of them but if one of the 7 points has a really different value from the others it will not be able to reach it.

The more components you take away, the more rigid the line becomes untill finally it is a staight line. See this link (http://www.availableengineers.com/id38.html) for a calculator with plotting you can play arount with. n is the number of components on this page.

What is the netto effect of this?
1. it allows you to calculate luma values for timepoints you have no samples for
2. it allows you to filter out single extreme luma values. In effect, you create a band-pass filter! The less components you put in the equation, the more inflexible the line becomes and the more it follows only the general trend of the luma values while ignoring fine detail.
3. it allows you to base a single interpolated point on many different samples. This becomes important when you are downscaling extremely, say to icon size. You could take 40 samples, fit an extremely inflexible low order polinomial to it and use it to calculate only a single pixel.

A real world capture device will not use polynomial regression ( to much calculations, prone to oscillations), but some other algorithm (= calculating method). But the basic principle is the same: use a function which is a summary of components (polyphase?). By decreasing the number of components (phases?) it becomes more rigid and will not be able to change rapidly enough to follow certain frequencies (low pass filter). It will be fitted to a window containing a certain number of samples (Taps?) and can be used to calculate interpolated samples (re-sizing!)

Back to the BT878
-----------------
The BT878 samples at 28.6 MHz. This gives on average 28.656 MHz *63.555 µs = 1820 samples per scanline. It has 4 filter algorithms to use at different frequencies. The basic one for high frequencies is a fairly flexible one and will accommodate changes up to 5 MHz. When the resolution drops below CIF, a second one is used. this one is less flexible, and cannot follow luma changes faster then 4 MHz. Etc. etc. The number of taps has to go up as the frequency goes down. At icon size, an extremely inflexble curve is fitted to a large number of sample points (50-100?).

So when you request 712x480 with BTwincap, the following happens: the resolution is above CIF, so the most flexible interpolation filter is used. 712 pixels per active window means 856 pixels per complete line. (this is set by the HSCALE register) so using this filter, and moving along the line TAP number of pixels per calculation, 856 pixels are interpolated from the original 1820. Any luma fluctuations above 5 MHz ale lost at this point.
HDELAY gives the number of pixels that have to be cropped from the left, and HACTIVE=712 gives the number of pixels after that that. Those are send to the PCI bus.

This is an oversimplification of the reality; in the real world, combfiltering also takes place in this step.

Ultralock
----------
Ultralock keeps track of the number of samples between to successive Horizontal sync pulses. Because of mechanical variations, this number will vary slightly with line length from line to line. If the number of samples is lower or higher then 1820, the interpolation is adjusted in such a way the 856 pixels are interpolated from however many samples are there.
There is a catch however: the number of requested pixels per line MUST be lower than the number of samples/2, or ultralock will fail.

The result of this is that you can never aligh your pixels with the original samples, since this number varies from line to line!

Final conclusions
-----------------
- capping slighly above CIF resolution will give more detail than slightly below, because below CIF, higher frequencies are no longer taken into account by the filter when interpolating. Some of this detail may be noise or aliassing, I am not sure about that.

- since the pixels are always created by interpolation, capping near the original sampling rate does not offer any special advantages.

-Capping directly at 356 will be more accurate than capping at 712 and resizing. At 356, each pixel is based upon TAP * the original luma samples surrounding it (and also upon some of the neighbouring scanlines because of the comb filter). If you cap at 712 and re-size, you have already reduced the amount of information available to 712 pixels.
Once again, this is not considering the resolution needs of post-processing filters.

Philips chips
-------------
I believe the basic operation is the same, only at 27 MHz. I have no documentation about the actual implementation of the filters used, apart from the fact that the number of TAPS for horizontal scaling varies from 10 at high res to 74 at icon size.

The algorithms used are probably different, since at least the SAA7134 will re-size above sampling rate/2.

Some conexant trivia
--------------------
the Luminance horizontal scaling filter of the BT878 is 6 tap, 32 phase interpolation , for the CX23881 it is ? tap, 64 phase.

Phew! Got that off my chest :D

Wilbert

5th January 2004, 01:19

The third option would be to use something like polynomial regression.
Suppose you have a function A +Bx +Cx^2 +DX^3 + EX^4 +FX^5 (= 6th order polynomial)
x is the time in this equation, A-F are constants that you can calculate by curve fitting this equation to the 7 datapoints. Once you have done this (how is not important for this story), you have values for A-F. Fill in the values in the equation and you have a function which describes a smooth line that touches all points and generates a luma value for each timepoint between the original samples. By filling in this equation you can calculate a luma value for every timepoint you want.
Ok. But I still don't understand how this works. In the specs they talk about a 6 tap, 32 phase interpolation filter. I don't know what the number of tabs stands for.

If you look at:
http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

They define L to be the exponent of the filter H, or

L = downsampling / upsampling ratio (which is apperently 5 for the luma component here)

and then

H(z) = A + Bz^(-1) + Cz^(-2) + Dz^(-3) + Ez^(-4) + Fz^(-5)

If I understand it correctly you can define a m-phase decomposition as:

H(z) = H0(z) + z^(-1)*H1(z) + ... + z^(-(m-1))*H(m-1)(z)

Note that m=6 at maximum here (in that case Hj(z)=constant). As for the name phase: applying a delay, alters the phase of your process. Thus z^(-0), z^(-1), ..., z^(-(m-1)) gives m different phases, hence the name polyphase filter. But, I'm just guessing here.

What I don't understand is, how you can have a 32-phase interpolation filter here? Or does the m=6 indicates the maximal number of taps.

It's late, I have to go to bed :(

trevlac

5th January 2004, 06:31

@Arachnotron, Wilbert

You people make me stay up too late and think too hard. How can I sleep with so many questions in my head? :)

Here is my take. Forgive me if this is too basic. I am really just tackling the subject of Digital Signal Processing.

Background

FIR filters - Are a general class of 'filters' that basically are a matrix of fractions (coefficients) whose sum is generally 1. For example, a 1 dimensional mean filter would be 1/4,1/4,1/4,1/4. A 1 dimensional Gaussian filter would be 1/4,1/2,1/4. Both are FIR filters.

TAPs are the number of coefficients used , OR the 'order' of the filter + 1, OR the number of pixels/samples needed where some are 'delayed' (aka, to work on pixel #3 with 3 taps, we need pixel #3, #4, & #5). For example, the above mean filter uses 4 taps, and the Gaussian uses 3 taps. I quote "more taps means more stopband attenuation, less ripple, narrower filters" this (http://www.dspguru.com/info/faqs/fir/basics.htm) great description.

Convolution is the process of `multiplying together' two arrays of numbers. When you convlute a FIR filter with a set of pixels, you are in effect adjusting the pixels by a weighted average of themselves and their neighbors. The weights are the coefficients (taps) of the filter.

The above filtering can be lowpass, highpass, ect., based upon the coefficients. You look in the frequency domain with a DFT to get the filter response, but I'm not to clear on that. :) The Gausian and mean filters are low pass.

Here (http://www.dai.ed.ac.uk/HIPR2/convolve.htm) is a good link on this stuff. Also, the vdub filter sdk tutorial gives a nice example and some more detail.

Polyphase decimation

-- Now, here I'm guessing a bit -- :D

Since a FIR filter it's self is a wave form, it can be decomposed into multiple parts or phases. What this looks like I'm not sure. It may be the full 6 taps of the base filter, or just 1 tap.

For say 1/3 decimation, every third sample is then feed into 3 of the avaliable 32 phases. I assume the other phases do not contain any parts of the filter, and the 3 used phases have filters. I'm not sure if these are different filters that act on different frequencies or what. After convolution, the values are summed to get the resulting 1 sample.

For say 2x interpolation, 2 of the possible 32 filter banks are used. One is feed the known sample values, and the other is feed zeros. The results are again summed.

For non integer decimation, say 2/3, the samples are 1st interpolated at 2x and then decimated as 1/3. From this I'd say that 32 phases gets you the flexibility to do non integer sizes that 'fit' into 32 up and down sample phases.

------------------
Now I need some sleep.......:)

Edit
I cleaned up a few things.

I want to make it clear. I don't fully comprehend Arachnotron and Wilberts posts. It seems we have different prespectives and are circling the same subject 'how the heck does a resize of samples work, and what does it mean?'

More edits, fixed the def of Taps abit.

Arachnotron

5th January 2004, 13:45

@Trevlac and Wilbert:

I feel a general principle emerging: DSP is detrimental for your beautysleep :)

Thanks for the replies! The math is, as usual way beyond me but your links enabled me to verify if at least some of my conclusions were correct. I love this forum :)

First, low pass /anti alias filtering and interpolation/decimation are indeed sides of the same coin. If or how the number of Taps and Phases control this is beyond me, but nevertheless the basic conclusion is correct. The BT878 aparently ads a notch to the low-pass filter every time the resolution drops below the Nyquist limit i.e. is reduced by two. the divisions would be 28/14/7/3.5MHz but to avoid problems around the switchpoint the first filter has a lower cut-off, 5 MHz instead of 7.

Second, since all pixels are filtered, even when you choose a resolution which is in phase with the original unfiltered samples, there is indeed no point in trying to match this resolution as Fred suggested.

Third, the ultralock process is also connected to this interpolation step. When I re-read the BT878 datasheet, I found the following line hidden on page 18:
Horizontal scaler: A + BZ^-1 + CZ^-2 + DZ^-3 + EZ^-4 + FZ^-5 with the note: Z-1 refers to pixel delay in the horizontal direction, and a line delay in vertical direction. The coefficients are determined by Ultralock and the scaling algorithm.

According to Trevlac's link, this is a 6-tap FIR filter (point 2.2.1) and ultralock does also infuence it.

As to the integer/non-integer decimation: Both the SAA7114 and the BT878 datasheets mention a two step approach with prefiltering for anti-alias reduction. The Phillips datasheet however does both an integer resize and an anti-aliassing in the prefilter step and a second fine resize if needed afterwards. Both steps are 6 bit phase = 64. If the BT878 does the same is not clear.

About Trevlacs remark about how the number of phased determines how accurately you can position your interpolated sample (= pixel jitter): A roundup of datasheets produces this:

BT878, 6 tap 23 phase, jitter < 6ns (p19)
CX23881, 6 tap 64 phase, jitter < 4 ns (p2-96)
SAA7134, "the phase accuracy of the re-sampling process is 1/64 of the original sampling distance or less than 1 ns"
SAA7114, which is very similar, mentions a 6 bit phase accuracy and 1 ns jitter, and 10 tap 64 phase elsewhere in the sheet

If so, the number of phases alone does not determine jitter. Perhaps it is phases and taps both?
Why the SAA7134 mentiones a variable number of taps between 10 and 74 while the others seem to have a fixed number of taps (even the saa7114) is also something I dont get. Maybe they intended phases?

In any case, I can recommend the datasheet of the SAA7114 here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf) for a blow-by-blow description of the SAA scaling process. I don't understand a word of it, but it looks impressive :D. No other SAA71xx datasheet contains this info. See page 37-49.

From it I get the impression that the Philips can be programmed to use a sliding approach to anti-aliassing, in contrast to the stepped approach used by conexxant. This may account for the smooth look reported by some SAA users.

trevlac

5th January 2004, 17:57

Here is some more info.. Maybe someone else can put it together.

Originally posted by Arachnotron
When I re-read the BT878 datasheet, I found the following line hidden on page 18:
Horizontal scaler: A + BZ^-1 + CZ^-2 + DZ^-3 + EZ^-4 + FZ^-5 with the note: Z-1 refers to pixel delay in the horizontal direction, and a line delay in vertical direction. The coefficients are determined by Ultralock and the scaling algorithm.
....
In any case, I can recommend the datasheet of the SAA7114 here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf) for a blow-by-blow description of the SAA scaling process. I don't understand a word of it, but it looks impressive :D. No other SAA71xx datasheet contains this info. See page 37-49.

The equation is the 'transfer function' of the filter.

A, B, C, etc are the coeffiecients. For example, for the Gausian filter 1/4,1/2,1/4 ABC = 1,2,1 with no gain (they add to 1). I believe coeffiecients are given in the Philips spec you posted on page 43.

Z^-1 is a reference to the pixel/sample 1 before the current pixel.

See This (http://www.dsptutor.freeuk.com/digfilt.pdf) excellent guide.

About Trevlacs remark about how the number of phased determines how accurately you can position your interpolated sample (= pixel jitter): A roundup of datasheets produces this:

BT878, 6 tap 23 phase, jitter < 6ns (p19)
CX23881, 6 tap 64 phase, jitter < 4 ns (p2-96)
SAA7134, "the phase accuracy of the re-sampling process is 1/64 of the original sampling distance or less than 1 ns"
SAA7114, which is very similar, mentions a 6 bit phase accuracy and 1 ns jitter, and 10 tap 64 phase elsewhere in the sheet

If so, the number of phases alone does not determine jitter. Perhaps it is phases and taps both?

I'm not sure about jitter. Maybe I should try to figure this out :)

Why the SAA7134 mentiones a variable number of taps between 10 and 74 while the others seem to have a fixed number of taps (even the saa7114) is also something I dont get. Maybe they intended phases?
....
From it I get the impression that the Philips can be programmed to use a sliding approach to anti-aliassing, in contrast to the stepped approach used by conexxant. This may account for the smooth look reported by some SAA users.

Here is an interesting quote I found.

For linear phase filters under a fixed impulse response length equal to N, it is only possible to realize (N-1)/2 different cutoff frequencies.

N is the order of the filter, or Taps - 1 , or # of coefficients - 1.

The above basically says you get steps of frequencies based on taps. I assume using different coefficients gets you different frequency steps.

Perhaps Philips uses a non-linear filter, or changes the coefficients.

----------------------------

@All

For any humans out there trying to follow this (such as myself), I found an great short summary of Digital Signal Processing. It contains very little math and is almost in english. :D

http://www.bores.com/courses/intro/index.htm

Arachnotron

5th January 2004, 19:17

.... and dsp does terrible things to your printer too.. :)

@Trevlac,

Thanks for yet another set of great links.

I have been studying them, but I think I have gone as far as I can go in understanding this without actually doing the math, programming a filter and looking at the responses. which I fully intend to do, once I can find the time for it :(

For now at least these discussions have given me a good general idea about how capture devices operate. And made me apreciate the SAA7134 more (this forum tends to be a bit biased towards the BT878 :D )

I'll post my oscilloscope pics in this thread as soon as I have them to add some empirical data to the theoretical one about Nyquist limits.

FredThompson

5th January 2004, 19:33

Time for me to bow out. Haven't done this kind of math in 15 years.

jggimi

5th January 2004, 20:43

Well, I've been follow these math and electronics threads, with interest but without any comprehension whatsoever.:scared:

I'm hoping when all of you finally figure it out, you make it simplistic and easy-to-understand for the ordinary capture card owner.
:thanks:

Wilbert

5th January 2004, 21:05

Time for me to bow out. Haven't done this kind of math in 15 years.

Fred, it's not about the math. But about the meaning of the filters and other things. Understanding the math makes it just a tiny bit easier for me :)

I want to make it clear. I don't fully comprehend Arachnotron and Wilberts posts. It seems we have different prespectives and are circling the same subject 'how the heck does a resize of samples work, and what does it mean?'
Yeah. I also don't comprehend our posts fully :)

In this link you posted:

Tap - A FIR "tap" is simply a coefficient/delay pair. The number of FIR taps, (often designated as "N") is an indication of 1) the amount of memory required to implement the filter, 2) the number of calculations required, and 3) the amount of "filtering" the filter can do; in effect, more taps means more stopband attenuation, less ripple, narrower filters, etc.)
IOW, indeed the number of coefficients.

Ok, let's consider decimating:

For say 1/3 decimation, every third sample is then feed into 3 of the avaliable 32 phases. I assume the other phases do not contain any parts of the filter, and the 3 used phases have filters. I'm not sure if these are different filters that act on different frequencies or what. After convolution, the values are summed to get the resulting 1 sample.
Part of my problem is that I don't understand the meaning of those 32 phases.

You are probably correct, but I'm trying to connect it to the stuff they say in the links. On page 4 of the link above

http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

"So in the i-th branch, the input signal is delayed by z^(-i), downsampled by L, and filtered using Hi(z)."

Those Hi(z) are convoluted, as illustrated in the diagram on page 5:

-->

H0(z^3) --> H0(z) ------------->
z^(-1) --> H1(z^3) --> H1(z) -->
z^(-2) --> H2(z^3) --> H2(z) -->

--> convolution -->

I hope the diagram is clear. Note L=3, and i=0,1,2 in this example. Note that they use the word "branches" instead of "phases".

Are you saying that there are 32 of those brances (thus 32 coefficients Hj(z^3))? In that case your have at least 32 constant coefficients instead of 6. Unless the six coefficients: A,B,C,D,E,F are not constant and depend on z (as in the diagram)?

On page 1 they give the advantage of the polyphase interpolating/decimating stuff:

"(...), the idea in the polyphase structures is to splite the related filtering into L parallel stages operating at the _lower_ sampling rate."

"In the traditional approached, the decimating/interpolation filters operate at the _higher_ sampling rate, i.e., before down-sampling or after up-sampling."

So, I guess the use of _polyphase_ decimators/interpolators is only a speed issue.

Back to a comment of Arachnotron:

-Capping directly at 356 will be more accurate than capping at 712 and resizing. At 356, each pixel is based upon TAP * the original luma samples surrounding it (and also upon some of the neighbouring scanlines because of the comb filter).
I also don't understand this. You are saying that no information is lost here? I thought you are also decimating in this case, i.e. throwing away half of the samples?

[QUOTE]If you cap at 712 and re-size, you have already reduced the amount of information available to 712 pixels.
True, of course.

Arachnotron

5th January 2004, 21:27

@Wilbert:

I posted:

-Capping directly at 356 will be more accurate than capping at 712 and resizing. At 356, each pixel is based upon TAP * the original luma samples surrounding it (and also upon some of the neighbouring scanlines because of the comb filter).

You replied:
I also don't understand this. You are saying that no information is lost here? I thought you are also decimating in this case, i.e. throwing away half of the samples?

I posted:
If you cap at 712 and re-size, you have already reduced the amount of information available to 712 pixels.

I am not sure my use of the term TAP was correct in this case. I suspect it was not :)

I think decimating through interpolation is not throwing away information. I't more condensing of information. It differs from simply dropping every second sample.

But - and this is 'gut feeling' without any mathematical basis - once you have locked the original information in 712 samples, you loose some information (freedom?). Also, there is always an uncertainty, an error in interpolation which is added to those 712 samples. So you enter the second round, the re-size to 356, with some extra errors and somewhat less information then you would have if you scaled the 356 samples directly from the original samples.

All in all a rather confused story, but then I don't understand the math :(

Edit I'm not sure if I am replying to a comment made by Wilbert or Wilberts comment on somebody else's comment.:confused:

trevlac

5th January 2004, 22:59

@Wilbert

I think you understand the math better than me. But as this continues, I think I 'get' a little more every day. I'm glad you brought some life back into this, because I too am a little burned out. :)

Please understand, I am trying to put the pieces together. A lot of what I say are guesses. Here are some items to make my guesses clear. They my however be incorrect guesses. :D Note that some of this may be a futher stretch of what I said before.

Originally posted by Wilbert
Ok, let's consider decimating:

Part of my problem is that I don't understand the meaning of those 32 phases.

You are probably correct, but I'm trying to connect it to the stuff they say in the links. On page 4 of the link above

http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

"So in the i-th branch, the input signal is delayed by z^(-i), downsampled by L, and filtered using Hi(z)."

Those Hi(z) are convoluted, as illustrated in the diagram on page 5:

I hope the diagram is clear. Note L=3, and i=0,1,2 in this example. Note that they use the word "branches" instead of "phases".

Are you saying that there are 32 of those brances (thus 32 coefficients Hj(z^3))? In that case your have at least 32 constant coefficients instead of 6. Unless the six coefficients: A,B,C,D,E,F are not constant and depend on z (as in the diagram)?

I'm saying that given a 720 sample line you 1st 'decimate' it by seperating out every 3rd sample. So now you have 3 240 sample lines. Next you take your great filter and seperate it into 3 parts. If it had 6 taps, you now have 3 2 tap filters. Next convolute the 'lower sampling rate' lines with the parts of the filter. Finally, sum the 'filtered' sample lines to get your 720 sample line decimated and filtered to 240.

So, in this case you only use 3 of your 32 phases/banks. If you want to use all 32 phases/banks because you have a strange ratio 'like going from 754 to 368', AND you only have 6 taps to your filter, you use zero as the coefficients in the xtra 'taps'. This of course implies that you don't actually calculate anything for more than 6 banks.

Now this is a bit of guessing on my part, but it is based on the idea that a FIR filter is finite because the 'ends' past the given coefficients are assumed to be zero.

On page 1 they give the advantage of the polyphase interpolating/decimating stuff:

"(...), the idea in the polyphase structures is to splite the related filtering into L parallel stages operating at the _lower_ sampling rate."

"In the traditional approached, the decimating/interpolation filters operate at the _higher_ sampling rate, i.e., before down-sampling or after up-sampling."

So, I guess the use of _polyphase_ decimators/interpolators is only a speed issue.

It is clear that it is a speed thing, but does this allow for a better filter to start? Also, do the coefficients change base upon the size you are going for? They seem to hint that there are other advantages, but I can't really fathom them.

I wish I could just whip up a vdub/avisynth resize filter and do some tests. :D But this tread keeps pulling me away from C++.

On Arachnotron's comment

It does seem like a resize from 'all of the samples' to say 368 DOES use the info in all of the samples, vs what a resize from 712 does. Also, the cutoff of the coefficients may be higher than that of a bi-linear resize. Aliasing may infact be taking place.

What do you think ?

Wilbert

6th January 2004, 00:30

I'm saying that given a 720 sample line you 1st 'decimate' it by seperating out every 3rd sample. So now you have 3 240 sample lines. Next you take your great filter and seperate it into 3 parts. If it had 6 taps, you now have 3 2 tap filters. Next convolute the 'lower sampling rate' lines with the parts of the filter. Finally, sum the 'filtered' sample lines to get your 720 sample line decimated and filtered to 240.

I think this is correct. Depends how those 32 phases come into play though.

A few small comments:

So, in this case you only use 3 of your 32 phases/banks. If you want to use all 32 phases/banks because you have a strange ratio 'like going from 754 to 368', AND you only have 6 taps to your filter, you use zero as the coefficients in the xtra 'taps'. This of course implies that you don't actually calculate anything for more than 6 banks.
What do you mean with banks here? What I called "branches" in the previous post?

Let's consider these two questions:

Also, do the coefficients change base upon the size you are going for?

I think so.

Given a size, do the coefficients change base upon the pixel you consider.
Both you and Arachnotron think that they are constant. I'm not totally convinced however. The answer is trivial if we know what "6 tap, 32-phase interpolation" means (especially the latter part).

Let me ask a simple question, which is easier to answer:

What is the maximal decimate ratio you think the filter can use. Is it 6, because of the 6-tap filter? What would be the corresponding capture size? If not, how could the filter decimate by 10 for example?

Arachnotron

6th January 2004, 00:57

What is the maximal decimate ratio you think the filter can use. Is it 6, because of the 6-tap filter? What would be the corresponding capture size? If not, how could the filter decimate by 10 for example?

Maybe I am interfering in a discussion I no longer understand, but what the hell..

Since icon is a valid resolution (32x32), more than 6 must be possible.

What do you mean with banks here? What I called "branches" in the previous post?

Could this simply be related to Fifo space? I remember reading in the SAA7114 sheet that the scaler has a "FIFO, 32 bit wide, with 64 pixel capacity in YUV formats". This scaler is 64 phase. Coincidence?

Wilbert

6th January 2004, 10:25

Since icon is a valid resolution (32x32), more than 6 must be possible.
Yeah. Decimating with 10 for example, can be obtained by decimating twice: first by two (6-tap and 4 coefficients zero) and then by five (6-tap and 1 coefficient zero). I guess decimating by 7 is impossible for example.

Could this simply be related to Fifo space? I remember reading in the SAA7114 sheet that the scaler has a "FIFO, 32 bit wide, with 64 pixel capacity in YUV formats". This scaler is 64 phase. Coincidence?
What's fifo space? I'm at work now, so I can't look it up. What does the bt 8x8 say about this? I didn't realise it, but they call it "32 phase interpolation". So, it has something to do with interpolation :)

@trevlac,

I changed my mind. The coefficients are always constants. Doesn't depend on the size you are going for, i.e. indepedent of the decimator factor.

What changes however, are the coefficients of:
If it had 6 taps, you now have 3 2 tap filters.
the 2 tap filters. Decimating with 2 gives you for example 2 3 tap filters, with (obviously) different coefficients as the 2 tap filters.

Arachnotron

6th January 2004, 14:55

What's fifo space? I'm at work now, so I can't look it up. What does the bt 8x8 say about this? I didn't realise it, but they call it "32 phase interpolation". So, it has something to do with interpolation

First-in-first-out. Sort of an intermediate storage space for things that "flow' continuously.

a chip like the BT878 has several of them for different purposes. They limit the amount of data that can be stored at one operation. There are other ones to buffer between the chip and the PCI bus; those must be able to hold one line (or one frame?) at max resolution.

Apparently, the scaler of the 7114 is able to store a maximum of 64 pixels per calculation pass.

trevlac

6th January 2004, 22:53

@Wilbert

I'm limited on time, so I will post some more info later.

There might be 2 Things mixed in the statement "32 poly phase interpolation", and our discussion.

Phases==Banks<>Branches:

Are these just holding places/registers on the chip/memory? I'm not sure what the 32 means right now. I'll look at the BT spec. (Again :) )

Maybe the process works like this:

If you resize by a non-integer, you must interpolate up 1st and then decimate down. Going from 16 to 5/8 of 16 would require you to go up to 16*5=80 and then convolute down to 80/8=10. For 16*5 you get 1 real value followed by 4 zeros: ie 128,0,0,0,0,134,0,0,0,0 ... Then when you decimate using a 6 tap convolution, you seperate out every 8th pixel into 8 rows of 10. Now if you only have 6 taps, you only calculate the new pixel value using the 1st 6 rows. This implies you have to hold 48 values at a given time. If you use 4 taps, I guess you only need 32 values at once. The problem with this is that unless maybe you convolved the interpolation step, I'd think you'd get zero values for some pixels.

Maybe for big ratios, it happens multiple times as you mentioned.

For simple decimation, I have worked out a few samples and they work the way I think.

Convolution:

I would like to go over this so everyone can follow, because you can manually calculate what the card is probably doing. Below is a link to a convolution calculator.

http://www.softintegration.com/chhtml/lang/lib/libch/numeric/CGI_Conv.html

For now, it looks like using .25,.5,.25 taps on a 12 pixel line of say (0.1,0.2,0.3,0.4 ... 1.2) gives you the same results if you convolute 1st and then decimate OR if you break the coefficients and lines up as (0.1,.5,.9)*.25 + (.2,.6,1.0)*.5 + (.3,.7,1.1) * .25. This example is a decimation by 1/4. 12-->3 samples. Notice, that we just ignore the 4th row or 3 samples.

I will post a clear explination so that @Anyone can follow. :D

trevlac

6th January 2004, 22:55

Originally posted by Arachnotron
Maybe I am interfering in a discussion I no longer understand, but what the hell..

Please don't stop the comments. You add tremendously to what I am beginning to understand.

Convolution 1st, then DFT. :confused:

Arachnotron

7th January 2004, 01:16

To go back to an earlier part of this discussion about Nyquist:

I just finished some tests with my DVD player and an oscilloscope.

I slapped together a Basic prog to produce strips of grayscale values from a sin function at certain frequencies and sampled at 13.5 MHz.source (http://www.arachnotron.nl/temp/wedge.bas) which produced this (http://www.arachnotron.nl/temp/MHz.png) picture

I made a DVD out of it and played it back in my DVD player, hooked up to an oscilloscope. This pic shows the signal from alternating black and white pixels. A 6.75 MHz sinus. No surprise there.
6.75 MHz (http://www.arachnotron.nl/temp/675_sin.jpg)
6.75 MHz part line (http://www.arachnotron.nl/temp/675_full.jpg)
This is what you get from 6.46 MHz:
6.46 MHz (http://www.arachnotron.nl/temp/646.jpg)

The large oscillation has a Frequency of 6.75 - 6.46 = 0.29 MHz
near the zero crossings the frequency is 6.46 MHz
near the peaks, the frequency is 6.75 MHz

This is the situation you get from a reconstruction function that does not do low pass filtering at 6.75 MHz. Post-aliassing.
Look at here (http://www.bores.com/courses/intro/basics/1_antia.htm) for an explanation.

As the frequency increases, the oscillation in amplitude slowly decreases and the frequency approaches the sampled frequency untill at around 6.75/2 you get a normal sinus again.

3.23 MHz (http://www.arachnotron.nl/temp/323_sin.jpg)

Originally, I wanted to grab this signal at 704x576 and 352x576, encode to DVD en analyze those on the scope. But since the source is already aliassed this became difficult. I have to re-do those sometimes.

But I noticed an interesting side effect: at 352x576, the 3 MHz sample became aliassed (amplitude oscillation as above). If this is the reconstruction filter, or the effect of the SAA7134 anti-alias filter still being at 6.75 MHz I do not know.

Tentative conclusion:

Nyquist is correct BUT you need a perfect reconstruction filter.

The part of the re-construction filter is played in this experiment by the DVD encoder + DVD player;
if you look at the dvd on the PC you also see interference patterns. You could say the filter now is
DVD encoder + PowerDVD + screendriver + graphics card

And neither of those (or any other real world playback system I suspect) is a perfect low bandpass filter limited reconstruction filter according to Nyquist!

So:

To get back your original signal on a real world system without aliassing, you must sample at 4 x the frequency!! Fred was right!

This does not mean you cannot go higher. Only, aliassing at playback will increase as you go up. If this is a problem depends. There is a trade-off between aliassing and detail. I suspect Manga and cartoons and sequences with lots of texture are better of at higher cap resolutions, even if the source is VCR.

So to stay the closest to the original VCR signal, I should sample at 704x576, do my filtering and STAY at 704!

By the way: I also discovered PowerDVD contains some sort of anti-alias filter.

trevlac

7th January 2004, 05:03

@Arachnotron

Interesting post. I must say, I can't completely follow. I do have some questions though..

This is the situation you get from a reconstruction function that does not do low pass filtering at 6.75 MHz.

But doesn't a dvd player do a low pass filter? I thought that was what DAC was about?

But I noticed an interesting side effect: at 352x576, the 3 MHz sample became aliassed (amplitude oscillation as above). If this is the reconstruction filter, or the effect of the SAA7134 anti-alias filter still being at 6.75 MHz I do not know.

I can't follow this. :)

Nyquist is correct BUT you need a perfect reconstruction filter.

The part of the re-construction filter is played in this experiment by the DVD encoder + DVD player;
if you look at the dvd on the PC you also see interference patterns. You could say the filter now is
DVD encoder + PowerDVD + screendriver + graphics card

And neither of those (or any other real world playback system I suspect) is a perfect low bandpass filter limited reconstruction filter according to Nyquist!

What I don't get here is 1) Isn't your 6.46MHz cap example supposed to look like that? Isn't that what your link said? 2) Isn't the DAC supposed to fix that? Why did it not?

To get back your original signal on a real world system without aliassing, you must sample at 4 x the frequency!! Fred was right!

You know, I can't really dispute this, because I can't really say why Nyquist is correct. :) I don't understand enough yet.

Also, I don't follow your logic. What is in your sample is not aliasing correct? The DAC is supposed to remove it correct?

This does not mean you cannot go higher. Only, aliassing at playback will increase as you go up.

You get more aliasing with a higher sample rate? I'm lost. Typo?

Good stuff though. I assume I should see the same thing in the Avia ramp. Can you post the 'raw' file. I couldn't get Basic to work.

Edit
Another question... If you should cap VHS at 704 to avoid the problem you describe, what do you have to cap a DVD at, and how do you keep it that size? AKA, can you cap a DVD if you must keep it at 4x 6.75? This does not make sense to me.

trevlac

7th January 2004, 06:44

I wanted to sum up a bit:

1) I said that you can cap at 2x the frequency of the source.

2) I did some tests, and it seemed like the BT878 did a better resize than a post cap resize. This got us side tracked as to why.

3) Arachnotron seems to have shown that if you cap at 2x your source, some frequencies between x and 1/2x get messed up. He concludes you need to cap at 4x and keep it at 4x.

I'd like to give some more info on #2, but it's time may have passed due to #3. :D

The story goes like this (I think):

1) I did some tests and It looks like a BT cap at 368 is better than cap at 720 and resize to 368. The direct cap has more resolution.

2) WHY?

The BT spec says: "The Bt879 implements horizontal scaling through poly-phase interpolation. The Bt879 uses 32 different phases to accurately interpolate the value of a pixel. This provides an effective pixel jitter of less than 6 ns. In simple pixel- and line-dropping algorithms, non-integer scaling ratios introduce a step function in the video signal that effectively introduces high-frequency spectral components. Poly-phase interpolation accurately interpolates to the correct pixel and line position providing more accurate information. This results in aesthetically pleasing video as well as higher compression ratios in bandwidth limited applications. ... Horizontal scaling is implemented with a 6-tap interpolation filter"

3) We tried to figure this out. Wilbert gave a link to a paper that talks about polyphase structures for decimation. Here is my current take.

6-tap filter means something like this: "1/14, 2/14, 4/14, 4/14, 2/14, 1/14". That is the kernel to a filter. A filter is a signal. To filter 1 signal with another signal you convolute them together.

32-phase interpolation means given 2 sample points, you create 31 points in between them. Then you 'run a filter' over them. This give you a bigger picture. To get a smaller picture, you throw away samples. To do an odd resize like 2/3 vs 1/2, you first go up, then down. Arachnotron gave a link to a nice paper on polyphase stuff. Here (http://www.snellwilcox.com/knowledgecenter/whitepapers/papers/digital_arc.pdf). Unfortunately, I got lost in the last two paragraphs (which seem important).

Banks/Branches/Phases ... These are the same. When you do this polyphase stuff for decimating, you can break up your filter and your samples and work on them as seperate sets, and then add them together.

I don't think 32 has to do with limited memory 'banks'. On page #122 of the BT spec it talks about memory limits. Here it is talking about the number of full lines you are limited to for a vertical scale. It appears to support about 2 1135 pixel lines. For horizontal, we are probably never talking about more than 200 pixels involved in any 1 calculation. These would all be from the same line.

Some conclusions
The BT does not really do a 'better' resize because of the polyphase stuff. That just makes it faster? It is all about the filter it uses. When it filters, it uses a different kernel than say a vdub resize. The BT's kernel seems to have a cutoff at a higher frequency. This may be a bad thing. There may be interferance in the resulting picture.

Convolution as promised

I'm just picking this up myself. I'd thought I'd review how I think this works so maybe somone would have some insights. :)

Convolution is a math operation like addition. Addition takes 2 numbers and produces a third. Convolution takes 2 signals and produces a third. For filters, you simply convolve your input picture with the filter kernel. This gives you a 'filtered' output. Basically, the process weights pixels with its neighbors.

The kernel for a simple Gausain blur is (.25, .5, .25). This is a low pass filter that (a big guess on my part) reduces the highest frequency to half.

To convolve a row of white, black, white, black pixels (1,0,1,0,1,0,1,0) together with the above filter, you:

1) front pad the pixels with zeros for filter coefficients -1. In this case 2 zeros -->> 0,0, 1,0,1,0,1,0,1,0

2) align the 2 signals like this:

0, 0, 1 ,0,1,0,1,0,1,0
.25,.5,.25

3) Multiply down and add across. This give you the answer for the 1st filtered pixel. In this case .25

4) Move the filter over by 1 like this:

0, 0, 1 ,0 ,1,0,1,0,1,0
.25,.5,.25

5) Repeat until you get all of your new pixels.

In this example the in and out lines are the same length due to how we padded and started. I think you are also supposed to pad the end a bit and keep going, then chop off some from the front and end. Due to the way the calculator link I gave seems to work, for it, you need to chop off 1 from the end and filter kernel lenght -2 from the front.

The whole reason for this chopping/padding is because the pixel line is a finite length, and signals are not. So you pad with dummy value and chop because the ends are not really meaningful because dummy values come into play.

An interesting note about how this works is say you have a black border around your source, and you bilinear resize down. The border will 'bleed' into the picture, and the edges of the picture will be a little off, because they are not really a valid signal.

-------------
If anyone wants to know how to use the calculator I posted, let me know. I ran some simple sample cases thru and found that doing a polyphase decimation (decimate then convolute) seems to give the same results as convolute then decimate. Basics on the calculator are: use real values; order = line/filter size -1. Enter your values and the filter kernel.

I just think the BT resize uses a different kernel than bilinear in avisynth.

Edit
I wanted to point out that the Philips spec that Arachnotron pointed out here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf) lays out all of their filter details (about page #45). The implementation is as always up to the driver. :) . Note that the way they do it is provide the coeffieients as whole numbers, which has the effect of increasing the 'gain' (brightness) of the signal. Then they 'normalize' the gain back down by dividing everything by the sum of all the coefficients. They can normalize back down by at most 128. AKA, coeeffieients can be as small as 1/128.

Also, it seems they can use up to 64+7 coefficients for their filter. Notice that they keep saying things like "The user can therewith decide between signal bandwidth (= sharpness impression) and alias." The user is the driver, and it decides the coefficients used in the filter.

I think I understand about 1 out of every 20 words in these docs now. :D

Arachnotron

7th January 2004, 18:05

@Trevlac

The source is in powerbasic, I just posted it as an illustration of how I made the teststrips. The raw strips are here (www.arachnotron.nl/temp/vcr_test.zip)

Another attemp to explain what I think:

There are two processes which result in aliassing in the final signal or picture.

The first is pre-aliassing. This is caused by sampling a signal which contains frequencies above half your sampling speed. For my Phiilips chip, this would be 13.5 MHz/2 = 6.75 MHz. This is prevented by adding a low pass filter before sampling. Since with pre aliassing the resulting low res signal will be in your samples, it is difficult to filter out afterwards.

The second is post-aliasing. To reconstruct the original sample the reconstruction function must not contain any frequency above sample rate /2. Again, in this case,6.75 MHz. But if the reconstruction filter DOES contain frequencies above this, you get aliassing again.
It will show up as moiree effects or rainbowing.

A good way to illustrate this is to look at my sample BMP file. It contains strips of greyscale lines at 6.75, 6.46, 6.16, 5.87, 5.58, 5.28, 4.99, 4.7, 4.4, 4.11, 3.82, 3.52, 3.23, 2.94, 2.64, 2.35, 2.06, 1.76, 1.47, 1.18 and 0.88 MHz.

If you open it in paint, you see the interference patterns clearly. If you zoom in, a single samplepoint is represented by a square; this is NOT a perfect reconstruction filter. Now open it in the Windows print and fax viewer. Zoom in. This program uses a re-size filter to zoom; different reconstruction filter, the interference pattern is different. Now make an MPG2 out of it and open in powerdvd. Play both in a window and ful screen. Again, different interference patterns!

Played back on my player (Pioneer DV535,not high end, but not cheap either) you again see interference patterns in the analogue signal.
But doesn't a dvd player do a low pass filter? I thought that was what DAC was about? Yes, The DAC should fix that. But for some reason didn't. There might have been a problem with my program (that is why I posted the source) but I don't think so since your avia test shows similar banding.

Now, the banding patterns differ depending on the reconstruction method used. But the result is the same: only the last 10 teststrips, 3.5 MHz to 0.88 MHz, are free of interference.

So, all these reconstruction methods are not perfect??

Back to my saa7134:

The highest frequency I can capture without pre-aliassing is 6.75 MHz
But the highest frequency in this capture I can play back without post-aliassing is 3.4 MHz. Any frequency in the cap beyond that will be increasingly distorted by aliassing on playback.

What happens if I cap at 352x576?
I suspect this chip at this point is still using the higher resolution low pass filter. So I have samples up to 6.75 MHz, which are being scaled down to 352 samples without low pass filtering. Probably, if I go a bit lower, the CIF filter kicks in and the banding disappears. This is pre-aliassing by the way.

Now suppose the cap at 352 was low pass filtered correctly, and the samples contain nothing beyond 3.4 MHz. If played back on the DVD player, the signal might be ok. I am not sure of that, still depends on the reconstruction filter.
But on an PC screen, when blown up to square pixels without any filtering, again you will get aliassing and interference patterns. Only now, going down to 1.7 MHz. If your software VCD player has filters, and the screen resolution is high enough for them to operate the post aliassing may be avoided.

What does al this mean:
With a 13.5 MHz sample rate
The lowest frequency you can sample without pre-aliassing is 6.75
The lowest frequency that will display without post aliassing is 3.4 MHz
Between 3.4 Mhz and 6.75, frequency (detail) increases and will display, but at the cost of post-aliassing.

Is this a problem? Depens on the scene. With a normal movie, the increased resolution is probably more valuable than the increase in aliassing.
But with stuff like stripes, patterns, etc. you see the aliassing. By using single frequency strips the effect becomes very visible. But real world film rarely contains stuff like that.

Real world example:
video with a striped shirt in it, sampled at 13.5 MHz and put on DVD

3.4 MHz shirt stripes: visible, no moire / rainbow
5 MHz shirt stripes: clearly visible, but some moire/rainbow
6.7 MHz stripes: just visible, heavy moire/rainbow.

3 MHz shirt on tape, capped at 704: visible, no moire
3 MHz shirt on tape, vapped at 352: visible, but moire??

Try it with the BT878 and my testpic. My prediction:
at 368 : more detail, but aliassing
at 354: less detail, but less or no aliassing

All in all, everything you do in digital video is a compromise between aliassing and detail. I really would like to look at different DVD players to see if some models have better reconstruction filters. But that might be a bit difficult. I'll try askin in a shop and see what answer I get :)

trevlac

7th January 2004, 19:26

@Arachnotron

Great explaination! I will try to test on my DVD player with your pic (your capture). The 2nd line of your capture clearly shows the larger wave that matches what you show on the scope (and what that bores link shows).

I'm not sure why the problem is between X and 1/2X (aka not at 6.75). I'd have to think about this an test. I remember reading something about how a TV works also comes into play for the reconsturction. Wont that be strange. If you watch on PC do A. If you watch on TV do B. :D

"Trade off between aliasing and sharpness" That's exactly what the Philips spec says also.

@Wilbert

There is a good short discussion of the filter kernels used in Avisynth Here (http://forum.doom9.org/showthread.php?s=&threadid=46648). I'm not sure what all of the flavors mean. The kernels don't seem to be as long as the 6taps used by the BT (or 64+ taps on a philips).

It does look like you could do a horizontal resize and mimic what a chip does by doing:

GeneralConvolution(...)
Levels(....)
PointResize(...)

GConv applies the filter out to 5 taps
Levels reduces the gain (Brightness) because the GC sounds like it does not work correctly and you can't get it to not boost gain. This might not work because the gain might go off the scale before you can fix it.
PointResize just decimates.

This is an educated guess, but if you talk avisynth, that is what a BT resize is doing. :). The BT may of course use a longer filter, and it also probably uses a different filter for chroma and luma (which may or may not matter because GC is RGB).

Do I make any sense? :confused:

edit
The best part of that thread is 'steady'. See this "All the others will interpolate by simultating a curve connecting the points." Does the perfect filter simulate the perfect curve, and reconstruct the signal? "The Lanczos resize is a 6-tap windowed sin c".

Arachnotron

7th January 2004, 19:47

The Lanczos resize is a 6-tap windowed sin c

I wonder: can you up-size with these filters too?

If so, a re-size of my 6.46 MHz strip to say 7200x XXX should yield a perfect sinus.

Wilbert

7th January 2004, 23:47

For now, it looks like using .25,.5,.25 taps on a 12 pixel line of say (0.1,0.2,0.3,0.4 ... 1.2) gives you the same results if you convolute 1st and then decimate OR if you break the coefficients and lines up as (0.1,.5,.9)*.25 + (.2,.6,1.0)*.5 + (.3,.7,1.1) * .25. This example is a decimation by 1/4. 12-->3 samples. Notice, that we just ignore the 4th row or 3 samples.
Sorry, I'm very low on time and didn't read the last couple of posts. This will be a math post, I hope it doesn't scare you away :)

I bet that your observation has something to do with the following:

from: http://www.dspguru.com/info/faqs/fir/props.htm

2.2.1 What is the Z transform of a FIR filter?
For an (N+1)-tap FIR filter with coefficients h(k), whose output is described by:

y(n) = h(0)x(n) + h(1)x(n-1) + h(2)x(n-2) + ... h(N)x(n-N),

the filter's Z transform is:

H(z) = h(0)z^(-0) + h(1)z^(-1) + ... h(N)z^(-N)

A very nice thing is that the Z-transform of a convolution of y and w is the product of the Z-transform of y and the Z-transform of w. Note that the convolution of y and w is given by

w(n) = g(0)x(n) + g(1)x(n-1) + g(2)x(n-2) + ... g(N)x(n-N)

(w*y)(n) = g(0)h(n) + g(1)h(n-1) + ... + g(n)h(0) = sum_s g(s)h(n-s)
where s runs from 0 to n, and * denoted the convolution (sometimes a cross with a circle around it, can't do that with ascii :) ).

Multiplying the Z-transform of y and Z-transform of w gives:

Z(y).Z(w) = (h(0) + h(1)z^(-1) + ... + h(N)z^(-N)).(g(0) + g(1)z^(-1) + ... + g(N)z^(-N)) = h(0)g(0) + (h(1)g(0)+h(0)g(1))z^(-1) + ... + h(N)g(N)z^(-2N)

Z-transform of y*w gives:
Z(y*w) = (y*w)(0) + (y*w)(1)z^(-1) + ... + (y*w)(N)z^(-N)
= g(0)h(0) + (g(0)h(1)+g(1)h(0))z^(-1) + ...

Iow, they are equal.

I'm sure your example fits into this somehow.

Arachnotron

8th January 2004, 01:03

I wonder: can you up-size with these filters too?

To answer my own question: yes, you can and no, you cannot recover the original sinus function using them.

Stands to reason: a filter that can do this must have an option somewhere to set the cut-off frequency. At least the included filters in Vdub cannot do this, and a quick scan of Warpenterprises and neuron2 did not uncover anything. (but I may have missed it of course)

Does anyone know if such a beast exists?

a re-size/interpolation filter that let's you set the cut-off frequency that is.

trevlac

8th January 2004, 04:38

@wilbert

[about math]
I'm not particularly scared of math. I simply view it as a symbolic language where the symbols have complex definitions. Unfortunately, like my German, I am quite weak at math. :(
[htam tuoba]

I however have been able to put together that
Z^(-N) is a reference to a time delay (an appearent property of Z transforms.

h(0) is a reference to a given coefficient of a filter.

And I do know that a z transform is (possibly) a special case of a Fourier transform, so that is why convolution of two signals = multiplication then z transform of 2 signals, because convolution in the frequency domain = multiplication in the time domain.

But unfortunately I 'don't quite speak the language'. I am really just learning, the DSP definitions help me understand the math more than the other way around.

So, because I don't really know what a Fourier transform is, I don't really follow, and I can't compare back to my sample as proof.

You on the other hand seem to speak many languages.... :D

Edit

Here is the intro to a chapter. I believe it describes how a chip uses a long kernel to filter, and is also what Wilbert is showing in math.

This chapter presents two important DSP techniques, the overlap-add method, and FFT convolution. The overlap-add method is used to break long signals into smaller segments for easier processing. FFT convolution uses the overlap-add method together with the Fast Fourier Transform, allowing signals to be convolved by multiplying their frequency spectra. For filter kernels longer than about 64 points, FFT convolution is faster than standard convolution, while producing exactly the same result.

http://www.spectrumsdi.com/ch18.pdf

Edit again Well I fully read that and can say it has nothing to do with what Wilbert posted nor the topic at hand. Not a bad read for 9 pages. Sorry for the confusion (on my part) :confused: .

@Arachnotron

Unhelpful answer
See this (http://www.dspguru.com/info/faqs/fir/props.htm)

2.2.3 Can I calculate the frequency response of a FIR using the Discrete Fourier Transform (DFT)?
Yes. For an N-tap FIR, you can get N evenly-spaced points of the frequency response by doing a DFT on the filter coefficients. However, to get the frequency response of the filter at any arbitrary frequency (that is, at frequencies between the DFT outputs), you will need to use the formula above.

:D :D

Maybe useful info
http://www.spectrumsdi.com/ch16.pdf

Discusses windowed sinc filters. I am also interested in this and here is what I think today. ;)

Filters in programs are limited to a very small number of coefficients (due to speed)
A sinc filter is simply a plot of the sinc wave the trick is you have to plot this using very few coeffieients (-5,40,128,40,-5) would be an example I just made up.
Filter cutoffs are measured as a % of the sample rate
A sharp cut off would probably have the center point go near the max on the scale (0-255) and might cutoff at .4 of the sample rate
You could probalby find a filter calculator. I have not seen one that lets you put the coefficients in. But the seem to allow input of cutoff

I believe the parameters for the Bicubic resize effect blur and ringing. Ringing occurs when the sinc is too high and is truncated at it's ends. This is in effect due to not enough taps (points in the graph). For example not using the -5s in my example. The blur makes the sinc wider and ineffect moves the cutoff to a lower frequency. I have no doubt that there is a calculation for the coefficients given a value for b and c.

GeneralConvolution directly accepts a kernel. Bicubic in effect also does.

Here is an idea That philips doc you posted had kernels defined and had graphs of their cutoffs. You could look at that and maybe use the GeneralConvolution.

trevlac

8th January 2004, 16:09

@Arachnotron,

What are your conclusions to the question "Capture Resolution - Are you sure?"

Also, I found a good way to show what these 'coeffieients' are doing.

Go to the philips doc Here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf). Page #46. Look for prescale ratio 1/2 at the top of the table. Go to 'High Bandwidth' side of table. If you set the registers as mentioned 'XCAL=1' 'XC2_1=0' you get a kernel like (1 1)x1/2 which is .5, .5. For lowbandwith the kernel is (1 2 1) or .25,.5,.25. 'XCAL=2' 'XC2_1=1'. Go to page #45 and look at the graph. Line (1) is the highbandwidth kernel. Line (2) is the lowbandwidth kernel.

How to read the graph (for others reading this post). If your sample rate is 13.5MHz, the filter's effect can be calculated by multiplying 13.5 by the numbers along the bottom. For 13.5MHz, a filter effects bandwidths between 1.35MHz (13.5 * .1) and 6.75MHz(13.5 * .5). The vertical scale is exponential effect. The standard way to give 1 number for the filter is to say what the value is at -3. This graph shows the effects down to -42.

The high bandwidth line hits -3 at about 1/2 the scale (3.375MHz). This makes sense because we are talking about a 1/2 decimation.

NOW

Go to this (http://www.digitalfilter.com/fircalwav/fircalwav.html) calculator. Go to the top of the coefficient list and change the values to .5, .5 and zero for all others. Change Fs= to 13.5. Change GainRng= to 42. Hit 'Read Coeffs'. The graph should match what is in the Philips doc. Change the 42 to 3 to get a better idea where the filter hits -3db.

After having done all of that, you could actually calculate what the chip is doing using the convolution calculator I linked, and a row of 1010101010 pixels.

Now if I could only understand page #42.

Anybody follow this ramble? It's my attempt to decipher what a philips chip is doing to resize from 720 samples to say 352 samples.

conclusion
If you capture at 352 AND your driver choose a 'low bandwidth' resize, then, even VHS will loose resolution. VHS ~ 3MHz. Low bandwidth filter ~ 2.5MHz. If your driver picks 'high bandwidth', you will not loose resolution.

I'm not clear what happens if you go from 720 to say 368. That seems to be on page #42