Vertical Interval Timecode (
VITC, pronounced "vitsee") is a form of
SMPTE timecode encoded on one scan line in a video signal. These lines are typically inserted into the
vertical blanking interval of the video signal.
With one exception, VITC contains the same payload as SMPTE
linear timecode
(LTC), embedded in a new frame structure with extra synchronization
bits and an error-detection checksum. The exception is that VITC is
encoded twice per
interlaced video frame, once in each field, and one additional bit (the "field flag") is used to distinguish the two fields.
A video frame may contain more than one VITC code if necessary,
recorded on different lines. This is often used in production, where
different entities may want to encode different sets of time-code
metadata on the same tape.
As a practical matter, VITC can be more 'frame-accurate' than
LTC, particularly at very slow tape speeds on analog formats. LTC
readers can lose track of code at slow jog speeds whereas VITC can be
read frame-by-frame if need be. Conversely, at high speeds (FF/rew.),
the VITC is often unreadable due to image distortions, so the LTC is
often used instead. Some VCRs have an auto selection between the two
formats to provide the highest accuracy.
VITC is 90 bits long: 32 bits of time code, 32 bits of user data,
18 synchronization bits, and 8 bits of checksum. It is transmitted
using
non-return-to-zero encoding at a bit rate of 115 times the line rate. (The unused 25 bit times are to leave room for the
horizontal blanking interval.)
SMPTE vertical interval timecode
(compliant with SMPTE 12M)[1][2]
|
|
Sync
|
Timecode
|
User bits
|
| Bit
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
| 0
|
1 |
0
|
1 |
2 |
4 |
8
|
User bits
|
Frame number
(0–23, 24, or 29)
|
| 10
|
1 |
0
|
| 10 |
20 |
D |
C
|
| 20
|
1 |
0
|
1 |
2 |
4 |
8
|
Seconds
(0–59)
|
| 30
|
1 |
0
|
| 10 |
20 |
40 |
F
|
| 40
|
1 |
0
|
1 |
2 |
4 |
8
|
Minutes
(0–59)
|
| 50
|
1 |
0
|
| 10 |
20 |
40 |
F
|
| 60
|
1 |
0
|
1 |
2 |
4 |
8
|
Hours
(0–23)
|
| 70
|
1 |
0
|
| 10 |
20 |
S |
F
|
| 80
|
1 |
0
|
CRC bits (g(x) = x8 + 1)
|
- Bit 14 is set to 1 if drop frame
numbering is in use; frame numbers 0 and 1 are skipped during the first
second of every minute, except multiples of 10 minutes. This converts
30 frame/second time code to the 29.97 frame/second NTSC standard.
- Bit 15, the color framing bit, is set to 1 if the time code is synchronized to a (color) video signal. The frame number modulo 2 (for NTSC and SECAM) or modulo 4 (for PAL) should be preserved across cuts in order to avoid phase jumps in the chrominance subcarrier.
- Bits 35, 55, and 75 differ between 25 frame/s time code, and 30/29.97 frame/s.[1]:20[3] The bits are:
- Field flag (bit 35 for 29.97/30 frame/s, bit 75 for 25 frame/s):
This is an additional least-significant bit for the frame number,
distinguishing the two interlaced fields in one video frame. It is set
to 0 during the first field of a frame, and to 1 during the second.
This bit replaces the "polarity correction" bit in linear timecode.
- "Binary group flag" bits BGF0 and BGF2 (bits 55 and 75 for 29.97/30
frame/s, bits 35 and 55 for 25 frame/s): These indicate the format of
the user bits. Both bits zero indicates no (or unspecified) format.
Only BGF0 set indicates four 8-bit characters (transmitted little-endian). The combinations with BGF2 set are reserved.[1]:7–8
- Bit 74 ("Binary group flag 1") was previously unassigned, but is
used to indicate that the time code is synchronized to an external
clock. If zero, the timecode start time is arbitrary.
- The checksum in bits 82–89 is a simple bytewise XOR of the previous 82 bits (including the sync bits, so bit 82 is the XOR of bits 74, 66, ..., 2), which can be described as a CRC with generator polynomial x8+1. (Preset to zero, no inversion.)
The exact nature of the color frame sequence depends on the video
standard being used. In the case of the three main composite video
standards, PAL video has an 8-field (4 frame) color frame sequence, and
NTSC and SECAM both have 4-field (2 frame) color frame sequences.
Preserving the color framing sequence of video across edits and
between channels in video effects was an important issue in early analog
composite videotape editing systems, as cuts between different color
sequences would cause jumps in subcarrier phase, and mixing two signals
of different field dominance would result in color artifacts on the part
of the signal that was not in sync with the output color frame
sequence.
To help prevent these problems, SMPTE time code contains a color
framing bit, which can be used to indicate that the video material the
timecode refers to follows a standard convention regarding the
synchronization of video time code and the color framing sequence. If
the color framing bit was set in both types of material, the editing
system could then always ensure that color framing was preserved by
constraining edit decisions between input sources to keep the correct
relationship between the timecode sequences, and hence the color framing
sequences.
See also
Коментарі
Дописати коментар