Posted by Dave Martindale on 12/20/07 02:49

Mark <makolber@yahoo.com> writes:

>Yes the frame buffer used during encoding is my point. The input video
>sync is used to digitize the input video and clock it into the
>buffer... and the buffer is emptied and encoded at the correct AVERAGE
>rate to keep it 1/2 full. That is the same function as a TBC.

Not really.

First, the input video does not have a pixel clock at all, and the
horizontal and vertical sync pulses are derived from the mechanical
motion of the tape past the spinning drum and control head. The motor
servos in the VCR maintain the correct *average* speed for these motors,
but they actually speed up and slow down a small amount during playback,
and that makes the sync unstable. To provide a stable digitizing clock,
the video digitizer has its own local oscillator which locks to the
*average* position of the H and V sync pulses. This will give you an
image, but individual scan lines will end up in the frame buffer either
left or right of their correct alignment as the video for that scan line
is either earlier or later than average. So vertical lines will end up
"jittered" horizontally along their length.

A TBC also digitizes the input, but it tries to re-lock the pixel
sampling clock *every line*. It can at least use at the leading edge
of sync to reset the column counter, which should reduce the timing
variation to under one pixel width. But a more sophisticated circuit
should try to phase-lock to the colour burst, which is of known phase
every scanline. That should providing timing precision of a small
fraction of a pixel. Either way, the effect of the H sync timing
jitter *on the picture content* is greatly reduced.

Both methods of encoding produce a digital data file that will be played
back with absolutely stable sync. But using a TBC (or equivalent
function in the digitizer) cleans up timing errors within the picture.
Without that, the jitter remains in the image on playback.

Dave

[Back to original message]