dya@unccvax.UUCP (York David Anthony @ WKTD, Wilmington, NC) (06/27/89)
In article <367@ctycal.UUCP>, ingoldsb@ctycal.COM (Terry Ingoldsby) writes: > In article <566@axis.fr>, philip@axis.fr (Philip Peake) writes: > First of all, unless I'm very mistaken ordinary VCR's do not separate the > chrominance and luminance info when they store it on the tape. It is all > stored together. Somebody please correct me if I'm wrong about this Wronnnnggggg :-) :-) This point is not often covered here, but basically, you can't record baseband video (with encoded chrominance) on a helical scan video tape recorder. The entire reason is a **mechanical** one, and is basically the fact that you can't obtain a constant linear scanning velocity where the rotating headwheel's head tip contacts the tape. Basically, the headwheel (and the head tip) suffers all kinds of accelerations. These are due to tape pack variations in tension within a reel and as a function of reel position; power supply variations; "stiction" (humidity, fingerprints, emulsion chemistry); dirt build up, the list goes on and on. Your VTR is doing quite well to maintain a fully framed image. Your camcorder is doing an even more remarkable job, due to gyro errors (because you move the camcorder, the headwheel speed to a fixed reference is the same, but relative to the tape, it changed). NTSC and PAL depend on a constant phase sampling clock to encode and extract their colour information. That sampling clock is contained as a colour burst signal; the 8-10 cycles of 3.58 (or 4.43) mHz sinewave right before the start of the line. The presumption is, basically, that the colour information following that burst was encoded with a constant phase clock identical to the signal which made the burst. However, velocity errors will cause frequency modulation of any signals on the tape, and therein lies the problem. Soooo, any FM which occurs as a result of footsteps across the floor, tape pack irregularities, wind velocity, humidity, and not the least of which mechanical wackies from the headwheel servo system itself (which is barely fighting to keep your picture framed vertically...burst phase coherence, you must be joking !!!!!) will cause the relationship between the burst (sampling clock) and the colour (the data) to be lost. A hue stable image probably has less than 6 nS p-p of residual burst to chrominance jitter, if that. Your VCR, on the other hand, doesn't have phase jitter, it has gross frequency jitter. We're talking about microseconds gained and lost during recording and playback! The way 'round this is recording colour in a different band than the luminance on the same tape. There are several different implementations of this, they are all called "colour under" recording. Luminance and chrominance are separated. The luminance goes on its merry way to be recorded as a narrowband FM track at about 4 mHz with a 1 mHz deviation. (Mr. Video will no doubt correct me as to specifications). Chroma, on the other hand, is processed in such a way that it is **heterodyned down** below the luminance track. The signal which does the heterodyning could come from two places: 1) be harmonically related to the colour burst 2) be any old reasonably coherent CW signal of desirable frequency (chosen to minimize artifacts with the original signal) I'm not sure what consumer decks do; in fact, I'm not sure what even our type "C" machine does!!! In either case, the party of the first part (the "heterodyned" signal) and a replica of the party of the second part (the "heterodyning" signal) are both laid down for a total of three video signals on the tape. Now, velocity errors still occur with impunity, but they proportionally affect the heterodyne signal and the heterodyned signal in such a way that when everything is played back, there is no difference in frequency or phase between the two! The receiver sees a burst (directly converted or otherwise reconstituted) and a colour subcarrier which are properly related, even though their absolute values are changing violently from line to line! To the **naked eye** correct colour playback is obtained. There really isn't a better inexpensive way for recording baseband colour signals on MAGNETIC TAPE (<--laserdisc flamers, take note). Now, though, we have component video formats, which record basically Y-I-Q (or Y-U-V), where the chroma is broken down into two signals whose vector component span the colour space. We have even digital videotape recording. But, the mainstay is still colour under. These signals can even be broadcast, with appropriate massaging using a time base corrector (basically, a big fat FIFO which is trying to be kept half full by prompting the VTR headwheel to "slow down" or "speed up" its filling, and whose output is being clocked by precise, stable signals). A question: how is SECAM recorded on a VHS or Beta machine of the appropriate scanning system? It would seem that the two FM subcarriers used could be directly recorded if there were an adequeate C/N ratio on the tape; or they could be filtered out, digitally divided down, recorded under, and digitially multiplied back. Do SECAM consumer decks specifically enjoy the advantages of that system? York David Anthony DataSpan, Inc
ke4zv@kd4nc.UUCP (Gary Coffman) (06/27/89)
In article <1533@unccvax.UUCP> dya@unccvax.UUCP (York David Anthony @ WKTD, Wilmington, NC) writes: > I'm not sure what consumer decks do; in fact, I'm not >sure what even our type "C" machine does!!! In either case, the >party of the first part (the "heterodyned" signal) and a replica >of the party of the second part (the "heterodyning" signal) are >both laid down for a total of three video signals on the tape. Your description of color under or heterodyne color recording is basically correct. However, type C machines DO NOT use color under. The reason for color under is the lack of bandwidth NOT PHASE JITTER. On consumer and industrial equipment such as VHS, Beta, and U-matic; there simply is not a high enough writing speed to record a full bandwidth NTSC composite signal. With type C one inch machines (as with the old two inch quads) there is plenty of writing speed and COLOR UNDER IS NOT USED. In all cases a time base corrector is required for broadcast use. In the old quad machines it was a tapped glass delay line, in modern machines it is digital memory. A analog to digital converter is clocked at four times recovered off tape subcarrier and the resultant 8 bit words are written to memory. A DAC clocked by reference subcarrier from the house master sync generator or an internal crystal reads the video back out of memory with all jitter gone. Gary Coffman Videotape Engineer WXIA-TV
brown@astroatc.UUCP (Vidiot) (06/27/89)
In article <1533@unccvax.UUCP> dya@unccvax.UUCP (York David Anthony @ WKTD, Wilmington, NC) writes:
< This point is not often covered here, but basically, you can't
<record baseband video (with encoded chrominance) on a helical scan
<video tape recorder. The entire reason is a **mechanical** one, and
<is basically the fact that you can't obtain a constant linear scanning
<velocity where the rotating headwheel's head tip contacts the tape.
Since I only have promotional flyers for two different 1"C decks, and since
they don't say exactly what is going on, from what I can gather 1"C decks
are NOT color under helical scan VTRs. Here's why, I remember seeing a
spec on 1"C decks in a series of articles in a trade rag about various
video decks. Also, one of the promotion flyers makes a point of the fact
that you don't have to bother with a "color under" system. Also, there
isn't a sub-carrier input connection on either of the two decks. The
sub-carrier input is used by a TBC to lock up the color sub-carrier for
use by the TBC.
< Luminance and chrominance are separated. The luminance
<goes on its merry way to be recorded as a narrowband FM track
<at about 4 mHz with a 1 mHz deviation. (Mr. Video will no doubt
<correct me as to specifications). Chroma, on the other hand, is
<processed in such a way that it is **heterodyned down** below
<the luminance track. The signal which does the heterodyning could
<come from two places:
VHS numbers are: normal VHS 3.4-4.4 MHz 629KHz SC
SVHS 5.4-7.0 MHz 629KHz SC
3/4" 3.8-5.4 MHz 688KHz SC
< But, the mainstay is still colour under. These signals can
<even be broadcast, with appropriate massaging using a time base
<corrector (basically, a big fat FIFO which is trying to be kept
<half full by prompting the VTR headwheel to "slow down" or
<"speed up" its filling, and whose output is being clocked by
<precise, stable signals).
Actually the TBC doesn't tell the VTR to speed up or slow down the headwheel.
Depending on how big the buffer is in the TBC, a system known as advanced
sync is used, ie, the TBC receives house sync. It sends sync timing to
the VTR that is advanced, whereby the video coming out of the VTR is there
before it is needed. This advanced sync tells the VTR when to put out
the video in relationship to the vertical sync, but the headwheel will only
speed up or slow down due to its trying to keep up with the required sync
because of drag/tension problems. Even then these speed changes are very
small. Besides, even using internal sync, the same thing will happen to
the headwheel. But, by the time it gets out of the TBC, it now matches up
to house sync. The TBC looks at the incoming video line and finds out where
the horizontal sync is and lines up the video line. It also puts away the
color information. When needed, the video is put back out with correctly
shaped horizontal sync pulses, the video signal at the correct reference
levels and the color also sent out, with a new color-burst and any timing
errors that it sees corrected.
One problem with TBCs is that the audio is also advanced. Unless one also
passed the audio through a digital delay unit that matches the advanced
timing of the TBC, every time the video is sent through a TBC or frame-
store unit (like a TBC), the audio will appear to happen before the video.
I have seen that many times with CNN newscasts.
--
harvard\ att!nicmad\
Vidiot ucbvax!uwvax..........!astroatc!brown
rutgers/ decvax!nicmad/
ARPA/INTERNET: brown%astroatc.UUCP@spool.cs.wisc.edu