Archived from groups: rec.video.desktop (
More info?)
"Leonid Makarovsky" <venom@cs.bu.edu> wrote in message
news:cp2079$548$1@news3.bu.edu...
> FLY135 <fly_135(@ hot not not)notmail.com> wrote:
> : Actually sampling in the vertical dimension is discrete and not analog
so
>
> Hold on. Discrete can still be analog. Video - is frame based. There're
finite
> number of frames in the video. So it is discrete. Yet it is analog.
By discrete and not analog I mean that there is a discrete fixed interval
between samples. For example 1 frame every 1/29.97 seconds or 1 scan line
every 64 microsecs is discrete. There is no discrete increments along the
scan line as pixels don't exist in NTSC video.
When a scan line of video is captured, the bandwidth limitation is related
to the pixel sampling clock. Each scan line is captured one after another
and there is no bandwidth limitation in the vertical direction. No matter
how slow or fast your pixel sampling clock is, there is nothing that changes
WRT the vertical resolution. The sampled data doesn't really know if all
the pixels are on one line or 240 lines. It makes no difference. I.E.
there is no way to blur the image (low pass filter) in the vertical
direction by speeding up or slowing down the pixel sampling clock (within
reason).
If you had alternating scan lines of black and white, no matter what
horizontal resolution you capture at, you will still get the same
black/white lines pairs. Of course you can capture only 1 field per frame
and that would cause you to lose the pattern. But.... you would not get a
gray image, you would get either black or white. This is an indication that
you aren't losing bandwidth. You are simply choosing to throw away half the
image. Which is frequently how capturing at 240 in the vertical is done.
>
> : However you need to remember that I previously posted that the NTSC/PAL
> : video decoder probably has a fixed sample of 704 pixels per scan line
plus
> : may do the resampling to 352 internally so a lot of what I'm saying
isn't as
>
> Does it resample to 352 internally even if I capture at 704x...?
I believe that all the NTSC decoders have a fixed pixel sampling clock at
either 704 or 720 pixels per line. Some decoders can resample internally to
352 or 360. but no matter what card you have, it defintely *doesn't*
resample to 352 if you are capturing at 704.
> : Also if you sample that 360 pattern with a 352 pixel clock then you will
see
> : a moire that is refered to as aliasing. Aliasing occurs when the sample
> : freq is not at least twice the highest frequency in the sampled signal.
> : NTSC/PAL video decoders have filtering to deal with this, and the
incoming
> : NTSC/PAL has a known bandwidth.
>
>
> What if I sample 640x... signal with 704x...?
There is no such thing as a 640 NTSC signal. NTSC video is analog and the
pixel resolution comes into play when the NTSC decoder samples the video.
Most decoders sample at 704. I'm not sure if there are many (or any) that
sample at 640, but IIRC the Pinnacle DC10+ captures at 640 so it probably
has a sample clock set to that frequency. If you capture with a standard TV
tuner card at 640, it probably samples at 704 and then resamples to 640.
The decoder chip or associated software will apply the proper filtering with
the resample to eliminate aliasing.
Facebook
Twitter
Instagram