Digital video recorder compatible receiver with trick play image enhancementDigital Video Recorder Abstract Digital Video Recorder Claims 1. A digital video tape recorder (VTR) compatible receiver for receiving a digital video data stream output by a digital VTR, the video data stream including normal play video data output by the digital VTR during normal VTR playback operation, and trick play video data and trick play video data processing commands output by the digital VTR during trick playback operation, each trick play video data processing command including an instruction for processing the trick play video data, the receiver comprising: a digital VTR port adapted for coupling the receiver to the digital VTR and for receiving from the digital VTR the digital video data stream including the trick play video data and the trick play video data processing commands output by the digital VTR during trick playback operation, the received trick play video data including a subset of the normal play video data; and trick play video data processing means coupled to the digital VTR port, for performing video data processing operations on the trick play video data received from the digital VTR as a function of a received trick play video data processing command, the trick play video processing means processing the subset of normal play video data included in the trick play video data to compensate for normal play video data intentionally omitted by the VTR from the subset of normal play video data. 2. The receiver of claim 1, wherein the trick play video data processing means includes a two dimensional spatial filter for performing spatial filtering of the subset of normal play video data in response to a first trick play command. 3. The receiver of claim 1, wherein the trick play video data processing means includes a temporal filter for performing temporal filtering of the subset of normal play video data in response to a second trick play command. 4. The receiver of claim 1, wherein the trick play video data processing means includes a temporal filter for performing temporal filtering on the subset of normal play data in response to a first trick play command and a spatial filter for performing spatial filtering on the subset of normal play video data in response to a second trick play command. 5. The receiver of claim 1, further comprising a transport and priority decoder circuit that receives the video data and trick play video data processing commands, and performs video transport depacketization and priority decoding on the trick play video data received from the digital VTR to generate video codewords, the transport and priority decoder being responsive to the trick play video data processing commands to enable trick play video transport depacketization and priority decoding. 6. The receiver of claim 5, further comprising a video decoder coupled to the transport and priority decoder circuit, the trick play video data processing means, and adapted for coupling to a display circuit, the video decoder circuit receiving video codewords from the transport and priority decoder circuit and decoding the video codewords, the trick play video processing means performing video data processing on the video codewords received by the video decoder in response to the trick play video data processing commands. 7. The receiver of claim 6, wherein trick play video processing means includes a two dimensional spatial filter for performing spatial filtering of the video codewords in response to a first trick play video data processing command. 8. The receiver of claim 6, wherein the trick play video data processing means includes a temporal filter for performing temporal filtering of the video codewords in response to a second trick play video data processing command. 9. The receiver of claim 6, wherein the trick play video data processing means includes a temporal filter and a spatial filter for performing temporal filtering and spatial filtering, respectively, of the trick play video data in response to trick play video data processing commands. 10. The receiver of claim 5, further comprising a tuner module coupled to the digital VTR port and adapted for receiving a radio frequency signal, the tuner module demodulating, trellis decoding and de-interleaving the received radio frequency signal to generate transport data packets. 11. A digital video tape recorder (VTR) compatible receiver for receiving a video data stream output by a digital VTR, the video data stream including normal play video data output by the digital VTR during normal VTR playback operation, and trick play video data and trick play video data processing commands output by the digital VTR during trick playback operation, the receiver comprising: a tuner module adapted for coupling to the digital VTR and for receiving from the digital VTR the trick play video data stream including the trick play video data and the trick play video data processing commands output by the digital VTR during trick playback operation, the trick play video data including a subset of the normal play video data; and trick play video data processing means coupled to the tuner module, for performing video data processing operations on the trick play video data received from the digital VTR as a function of a received trick play video data processing command, the video processing means processing the subset of normal play video data included in the trick play video data to compensate for normal play video data intentionally omitted by the VTR from the subset of normal play video data. 12. The receiver of claim 11, wherein the trick play video data processing means includes a spatial filter for performing spatial filtering of the subset of normal play video data received from the digital VTR in response to a first trick play command. 13. The receiver of claim 12, wherein the trick play video data processing means includes a temporal filter for performing temporal filtering of the subset of normal play video data in response to a second trick play video data processing command. 14. A receiver comprising: a tuner module adapted for coupling to a video tape recorder (VTR) and for receiving a video data stream from the digital VTR, the video data stream including normal play video data output by the digital VTR during normal VTR playback operation, and trick play video data output by the VTR during trick playback operation, the trick play video data including a subset of the normal play video data; and trick play video data processing means coupled to the tuner module, for detecting the receipt of trick play video data from the digital VTR and for performing video data processing operations on the trick play video data received from the digital VTR to compensate for the absence of normal play video data intentionally omitted by the VTR from the subset of normal play video data included in the trick play video data. 15. The receiver of claim 14, wherein the trick play video data processing means includes a spatial filter for performing spatial filtering of the trick play video data received from the VTR. 16. The receiver of claim 15, wherein the trick play video data processing means includes a temporal filter for performing temporal filtering of the video data received from the VTR. 17. A digital video tape recorder (VTR) compatible receiver for receiving a video data stream output by a digital VTR, the video data stream including normal play video data output by the digital VTR during normal VTR playback operation and trick play video data output by the digital VTR during trick playback operation, the trick play video data including a subset of the normal play video data, the receiver comprising: a digital VTR port adapted for coupling the receiver to the digital VTR and for receiving from the digital VTR the video data stream including normal play video data and trick play video data; and a video decoder including a decoder circuit and a trick play video data processing circuit coupled to the digital VTR port, the video decoder circuit decoding the video data received from the VTR, the trick play video data processing circuit detecting the receipt of trick play video data from the VTR, and processing the subset of normal play video data included in the trick play video data to compensate for normal play video data intentionally omitted by the VTR from the subset of normal play video data. 18. The receiver of claim 17, wherein the trick play video data processing circuit includes a spatial filter for performing spatial filtering of the trick play video data when the receipt of trick play video data is detected. 19. The receiver of claim 17, wherein the trick play video data processing circuit includes a temporal filter for performing temporal filtering of the video data when the receipt of trick play video data is detected. 20. A method of receiving and processing video data output by a digital video tape recorder (VTR), the digital VTR outputting a video data stream including normal play video data during normal playback operation, and trick play video data and a trick play video data processing command during trick play operation, the trick play video data including a subset of the normal play video data, the method comprising the steps of: receiving the trick play video data including the subset of normal play video data output by the digital VTR during VTR trick playback operation; receiving the trick play video data processing command output by the digital VTR during VTR trick playback operation; and performing video data processing on the received subset of normal play video data, in response to the received trick play video data processing command to compensate for the intentional omission of normal play video data, by the digital VTR, from the received subset of normal play video data. 21. The method of claim 20, wherein the step of receiving the trick play video data including the subset of normal play video data output by the digital VTR includes the step of coupling a receiver to a digital VTR port. 22. The method of claim 20, wherein the step of receiving the trick play video data including the subset of normal play video data output by the digital VTR includes the steps of: receiving a radio frequency signal output by the digital VTR; and demodulating, trellis decoding and de-interleaving the received radio frequency signal to generate the subset of normal play video data, the subset of normal play video data including transport data packets. 23. A method of receiving and processing video data output by a digital video tape recorder (VTR) during normal VTR playback operation and VTR trick playback operation, the digital VTR outputting normal play video data during normal VTR playback operation and trick play video data including a subset of normal play video data during VTR trick playback operation, the method comprising the steps of: receiving digital video data from a digital VTR; monitoring the received video data to detect the receipt of trick play video data indicative of VTR trick playback operation; and performing, upon the detection of received trick play video data, video data processing operations on the received video data to compensate for normal play video data intentionally omitted by the digital VTR from the subset of normal play video data. 24. The method of claim 23, wherein the step of performing video data processing operations on the received video data includes the step of performing spatial filtering of the received video data. 25. The method of claim 23, wherein the step of performing video data processing operations on the received video data includes the step of performing temporal filtering on the received video data. 26. The method of claim 23, wherein the step of receiving digital video data output by a digital VTR includes the steps of: receiving a radio frequency signal output by the digital VTR; and demodulating, trellis decoding and de-interleaving the received radio frequency signal to generate video data including transport data packets. 27. A receiver, for receiving a video data stream output by a digital video playback device, the video data stream including normal play video data output by the digital playback device during normal playback operation, and trick play video data and trick play video data processing commands output by the digital playback device during trick playback operation, the trick play video data including a subset of normal play video data, each trick play video data processing command including an instruction for processing the trick play video data, the receiver comprising: a digital port adapted for coupling the receiver to the digital video playback device and for receiving from the digital playback device the trick play video data and the trick play video processing commands output by the digital video playback device during trick playback operation, the received trick play video data including a subset of the normal play video data; and trick play video data processing means coupled to the digital port, for performinq video data processing operations on the subset of normal play video data received from the digital video playback device as a function of a received trick play video data processing command, the trick play video data processing means processing the subset of normal play video data included in the trick play video data to compensate for normal play video data intentionally omitted by the digital video playback device from the subset of normal playback video data. Digital Video Recorder Description The present invention relates to video receivers and, more particularly, video receivers that are capable of receiving commands and/or detecting trick play modes of recorder operation and performing, e.g., error concealment operations in response to the received commands or detected mode of trick play recorder operation. BACKGROUND OF THE INVENTION A VTR can receive and store images (and sounds) received as signals from various sources, for example, a television tuner, an antenna or a cable. The VTR stores the received signal information, i.e. the data, by recording the data on a magnetic tape, such as a video cassette tape. The VTR can also reproduce images (and sounds) that are stored on a tape as data by reading the data on the tape and generating a signal from the data which can then be provided to a display device such as a television monitor. To facilitate fast forward, search, and reverse capabilities, VTRs normally provide a limited number of playback speeds in both forward and reverse direction in addition to the VTR's standard playback speed which is used during normal playback operation. VTR systems for recording and reproducing analog video signals are well known in the art. Such systems commonly use rotary head, helical scan recording methods to record data on a tape. In such systems, record/playback heads are mounted on a rotary head cylinder. The rotary head cylinder is inclined relative to the lengthwise portion of a magnetic tape which surrounds the rotary head cylinder for approximately 180.degree.. During normal operation of such video recording devices, the tape moves in a lengthwise direction while the record/playback heads rotate along with the inclined rotary head cylinder in a circular direction. As the record/playback heads rotate with the head cylinder they contact the moving tape in a manner which permits the recording or reading of data from the tape along evenly spaced tracks located diagonally relative to the length of the tape. A servo mechanism is used to control head positioning relative to the tape's position to insure that the heads contact the tape along the diagonals which form each track of data. FIG. 1(a) is a top view of a conventional two head video recording system. As illustrated in FIG. 1(a), first and second record/playback heads HA 2 and HB 3 are mounted opposite each other on a rotary head cylinder 4. To reduce crosstalk between adjacent tracks written by heads HA 2 and HB 3, the heads are of mutually different azimuth angles. A tape 1 surrounds the rotary head cylinder 4 for approximately 180.degree.. The tape moves relative to the rotary head cylinder as indicated by V.sub.T. Similarly, the rotary drum, and thus the record playback heads HA 2 and HB 3, rotates as indicated by V.sub.H. As the rotary head cylinder 4 rotates, the tape moves in a lengthwise direction as illustrated in FIG. 1(a). The rotating record/playback heads HA 2, HB 3 contact the tape in a manner which permits reading or writing, i.e. scanning, of data along diagonal tracks as illustrated in FIG. 1(b). In the two head system of FIG. 1(a), a single head, either HA 2 or HB 3, contacts the tape 1 during each 180.degree. period of head cylinder rotation. During this period of tape contact, during standard operation, each head reads or writes one normal play track of data. Each track comprises a plurality of tape segments. Each tape segment may contain one or more blocks of data. The data on the tape forms a series of parallel tracks as illustrated in FIG. 1(b). The gaps between the tracks are shown only for the purpose of clarity. Accordingly, there are normally no actual gaps between tracks recorded on a tape. The slope of the tracks depends on the speed of the tape when the tracks are recorded. References to data tracks or normal play data tracks are hereinafter to data tracks written with a slope corresponding to the slope of data tracks written during standard record mode, i.e., data tracks written when the tape is moving at a standard speed for normal play operations. In order to aid in the differentiation between tracks, data in each individual track is written at a mutually different azimuth from the preceding track. This results in a series of data tracks containing data written at alternating azimuths which correspond to the mutually different azimuths of the first and second heads HA 2, HB 3. The slanted lines within each data track of FIG. 1b are used to indicate the azimuth at which the data in each track was written. The heads HA 2 and HB 3 can only read data written at an azimuth corresponding to the head's own particular azimuth. Thus, HA 2 and HB 3 are limited to reading data from tracks containing data written at the same azimuth as the particular head HA 2 or HB 3 with neither head being able to read the data contained in the tracks written by the other head since the data is positioned at an azimuth corresponding to the other head's azimuth. Data tracks are normally written on the tape along diagonals which correspond to the diagonals traced by the heads across the width of the tape during normal, i.e., standard record/playback mode. During modes of operation such as playback during reverse or fast forward, referred to as trick play modes, the tape velocity is different than the tape velocity during standard record/playback mode. In trick play modes the tape speed is a function of the selected fast forward or reverse speed. Because the tape moves relative to the record/playback heads at a speed other than the standard tape speed during trick play mode, the heads will trace over the tape along a diagonal path different than the path traced during the standard record/playback mode. In fast forward mode, the heads will trace over the tracks created during standard record/playback mode at a shallower angle than the angle of the data tracks. In reverse mode, the heads will trace across the tracks recorded during standard mode at an angle opposing the angle of the tracks recorded during standard record/playback mode. Accordingly, during VTR operation in trick play mode, the VTR's heads may cross over several different tracks of data during each pass across the width of the tape, e.g., during each 180.degree. period of head cylinder rotation, with the angle at which the tracks are crossed being a function of tape speed. FIG. 1(c) illustrates the paths traced out by the record/playback heads HA 2, HB 3 across the magnetic tape 1 during trick play mode operation at three times (3.times.) the standard playback tape speed (hereinafter referred to as 3.times. playback operation). In FIG. 1c reference numerals 1-A through 12-B are used to indicate tracks on the magnetic tape 1. Odd numbered tracks 1-A through 11-A contain data written at an azimuth corresponding to the azimuth of head HA 2 while even numbered tracks 2-B through 12-B contain data written at an azimuth corresponding to the azimuth of head HB 3. During 3.times. playback operation, heads HA 2, HB 3 trace across the tracks on the tape 1 at a shallower angle than during standard playback operation. As illustrated in FIG. 1(c), head HA 2 traces across paths 13 and 15 while head HB 3 traces across paths 14 and 16. As described above, each head can only read data written at an azimuth corresponding to the head's own azimuth. Thus, during 3.times. playback operation, head HA 2 can only read the portions of data which the head passes over in the odd numbered tracks, i.e. the areas of the odd numbered tracks indicated by the letters a, b, e and f. Similarly, during 3.times. playback operation, head HB 3 can only read the portions of data which it passes over in the even numbered tracks, i.e. the areas of the even numbered tracks indicated by the letters c, d, g, and h. As FIG. 1(c) shows, during fast forward playback and other trick play modes of operation where the tape moves at a speed faster than the standard tape speed, it will not be possible for a two head video tape recorder to read all the data contained in each track because there will be areas of track that the heads do not pass over at all. The amount of track that is covered by the heads when the tape speed exceeds the standard tape speed is only a fraction of the total track area with the track area covered being directly proportional to the ratio of the standard tape speed to the actual tape speed. For example, in a two head VTR system, during 3.times. playback operation, the heads will pass over approximately 1/3 of the tape area comprising the recorded tracks which are used during standard playback operation. At 9.times. playback, the heads will pass over approximately 1/9 of the tape area comprising the recorded tracks. Furthermore, as discussed above, during trick play mode in a two head VTR, the heads pass over track areas where they can not read the recorded data because it was recorded by a head having a different azimuth from the azimuth of the head passing over the track during trick play mode. As illustrated in FIG. 1c, single heads can read only approximately fifty percent of the data which they pass over during trick play mode, thus greatly reducing the amount of data that can be read during trick play modes. To increase the amount of data that can be read during trick play modes additional record/playback heads may be used. There are two approaches for using additional record/playback heads to increase the amount of data that is read during trick play mode. The first approach is to use pairs of co-located heads. The second approach is to add additional pairs of non-collocated heads to the rotary head cylinder, each head in a pair of non-collocated heads being mounted 180.degree. from the other head in the pair. These two approaches may be used independently to increase the amount of data that can be read during trick play mode. Alternatively, they can be combined to provide for maximum data recovery. The first approach which may be used to permit the reading of virtually all data in tracks passed over by a head during trick play mode requires that single heads be replace with co-located heads, i.e. pairs of heads arranged at mutually different azimuths, in such a manner that each track area passed over by the heads is passed over by at least one head of each possible azimuth. Because of the physical proximity of each head in a pair of co-located heads, both heads pass over the same data on the tape. Thus, by using pairs of co-located heads it is possible to read all data passed over by the co-located heads with each head in the pair reading data from each alternating track which has data written at the same azimuth as the head doing the read operation. Since this approach requires the use of pairs of heads as opposed to single read/write heads, this doubles the number of heads required to implement a VTR using co-located heads as opposed to individual heads. For example, instead of having a two head VTR system with two heads spaced 180.degree. apart, a similar VTR with co-located heads would comprise 2 pairs of co-located heads spaced 180.degree. apart resulting in a four head VTR system. FIG. 2(a) illustrates a four head VTR system comprising two pairs of co-located heads. As illustrated, a first and second pair of co-located heads HA-HB 20, 30 are mounted 180.degree. apart on a rotary head cylinder 25. The magnetic tape 1 wraps around the rotary head cylinder 25 for approximately 180.degree. contacting one pair of the co-located heads HA-HB 20, 30 at any given time. FIG. 2(b) illustrates the paths traced out by the pairs of co-located heads HA-HB 20, 30 across the tape 1 during 3.times. playback operation. In FIG. 2(b), as in FIG. 1(c), reference numerals 1-A through 12-B are used to indicate tracks on tape 1. Odd numbered tracks 1-A through 11-A contain data written at an azimuth corresponding to the azimuth of head HA while even numbered tracks 2-B through 12-B contain data written at an azimuth corresponding to the azimuth of head HB. During 3.times. playback operation, the first pair of co-located heads HA-HB 20 traces across paths 33 and 35 while the second pair of co-located heads HA-HB traces across paths 34 and 36. Because co-located heads are used instead of individual heads, the data which is passed over by either pair of co-located heads can be read by one of the heads in the pair regardless of the azimuth at which the data is written. For example, head HA of the first pair of co-located heads HA-HB 20 reads the data in track portions a, b, e, and f of FIG. 2 while head HB of the first pair of co-located heads HA-HB 20 reads the data in track portions i and k. Similarly, head HA of the second pair of co-located heads HA-HB 30 reads the data in track portions j and l while head HB of the second pair of co-located heads HA-HB 30 reads the data in track portions c, d, g, and h. Thus, by using pairs of co-located heads virtually all the data in paths 33, 34, 35, and 36 which are traced by the heads during trick play mode operation can be read. The second approach to increase the amount of data that is read during trick play mode also requires the use of additional heads beyond the two heads used in a basic VTR system. In accordance with this second approach N heads, where N>1, may be arranged so that the N heads are equally distributed over the range of the rotary head cylinder used to read/write a track of data, i.e. a 180.degree. portion of the rotary cylinder head. Accordingly, the total number of heads in such a system is 2N since there are N heads on each 180.degree. portion of the rotary head cylinder. In such a system, there are N heads in contact with the tape at any given time. During standard playback operation, N-1 heads provide redundant information which can be used for error checking or other purposes. However, during trick play modes where the tape moves at a speed faster than the standard speed, each of the N heads will pass over a different portion of the tracks and read some data not read by the other heads. When the tape moves at N times the standard speed, during NX playback operation for example, each one of the N heads will pass over a different 1/N.sup.th of a track written on the magnetic tape so that at least one of the N heads will pass over each section of the track. Thus, by using additional heads in this manner, additional data may be read during trick play operation. Referring now to FIG. 3(a) there is illustrated an 8 head VTR system having four heads distributed evenly over each 180.degree. portion of a rotary head cylinder 40. Thus, in the illustrated system N=4. As illustrated in FIG. 3a, in a system where N=4, there are four heads in contact with the tape 1 at any given time. When the system of FIG. 3(a) is operated in 4.times. playback operation the tape 1 moves at 4 times the standard tape speed. In such a case, during each pass, at least one of four heads will trace over each 1/4 section of a track. Thus, as illustrated in FIG. 3(b), the heads of the 8 head VTR of FIG. 3(a) will trace over all sections of the tape's tracks as the heads trace over one track after another during 4.times. playback operation. Thus, if each head in the VTR system of FIG. 3(a) could read all of the data over which it passes, all the data on the tape could be read during 4.times. playback operation. However, as described above in regard to two head VTR systems, data in alternating tracks in a VTR system using helical scanning methods are written on the tape by heads with different azimuths. Accordingly, each one of the N heads in a system, having N heads on each 180.degree. portion of a rotary head cylinder such as the system of FIG. 3(a), will only be able to read data in tracks written using a head having the same azimuth as the head attempting to read the data. Thus, while all portions of the tracks will be traced over by one of the N heads while operating in NX trick play mode, not all the data, i.e. only about 1/2 of the data, will be read because each head will only be able to read data from every other track written at a standard speed due to the fact that the data in alternating tracks were written by heads having different azimuths. In order to read all the data passed over by the individual heads, pairs of co-located heads can be substituted for each of the N individual heads on each 180.degree. portion of a rotary head cylinder. The use of N pairs of co-located heads equally spaced from each other on each 180.degree. portion of a rotary head cylinder provides a VTR system capable of reading almost all of the data during NX playback operation. Such a system generally requires 4N heads to implement. Thus, for example, in order to read virtually all the data from tracks during 4.times. playback speed requires a sixteen head VCR. While known VTRs are primarily directed to recording of analog signals, current advances in technology enable images to be encoded and decoded in digital form and transmitted as a digital data stream. Accordingly, VTRs must be able to store and retrieve images that can be represented in digital form. The digital representation of images, especially moving images with accompanying sound, requires a high digital data rate. Thus, digital television signals require a high data rate. High Definition Television ("HDTV") which include systems capable of displaying higher resolution images with greater clarity than are possible with the current National Television Systems Committee (NTSC) standard, will require an even higher digital data rate to represent video images than is required to digitally represent images of a similar quality to those transmitted in accordance with the current NTSC standard. In order to provide the high data rate needed to support HDTV recording and playback, VTRs capable of recording two data channels per track may be used. Referring now to FIG. 4(a), there is illustrated a 2 channel, 4 head VTR system. As illustrated, a 2 channel VTR uses a pair of heads to write to or read from each track of data. Each pair of heads HA.sub.1 -HB.sub.1, HA.sub.2 -HB.sub.2, in a 2 channel VTR comprises two heads HA, HB of mutually different azimuths mounted on a rotary head cylinder 4 in such a manner that the heads in each pair of heads are capable of simultaneously writing to, or reading from, the two channels of a track on the tape 1. Thus, in such a system, the data rate that the VTR can support is nearly double the data rate a single channel VTR can support. As illustrated in FIG. 4(b), the tracks, T1 through T6, written by a 2 channel VTR each comprise a first and second data channel, channel A and channel B, respectively. Compression and decompression techniques may be used to reduce the amount of digital data needed to represent images and sound. Accordingly, such techniques are important in reducing the amount of digital data which must be transmitted for television signals and the amount of data which must be recorded by VTRs. However, even with such data compression, HDTV will still require large amounts of digital data to be transmitted at high data rates to achieve HDTV picture and sound quality. For example, one proposed HDTV system requires 24 million bits per second of digital data to be transmitted to achieve HDTV picture and sound quality. The International Standards Organization has set a standard for compression which includes the use of motion compensation principles. The standard is referred to as the ISO-MPEG (International Standards Organization-Moving Picture Experts Group) standard. MPEG compression uses an adaptive motion-compensated Discrete Cosine Transform (DCT) that perceptually optimizes picture encoding on a block-by-block basis. The MPEG motion compression technique has both unidirectional and bidirectional prediction capabilities (both forward and backward in time) to accurately predict frames. This allows more bytes to be used for picture detail. In accordance with the MPEG standard, analog video signals are digitized, matrixed and filtered to produce an internal format used for the compression process. The compression process performs compression using the MPEG compression algorithm. In summary, the MPEG compression operations that are implemented in the compression process include motion compensated predictive coding and adaptive Discrete Cosine Transform (DCT) quantization. MPEG utilizes data structures known as frames. A frame contains picture information and defines one complete video picture. For example, a frame of video can consist of an array of luminance pixels (Y) and two arrays of chrominance pixels (Cr, Cb). According to the MPEG compression algorithm, frames are classified into one of three types: intracoded-frames (I-frames), predictively coded frames (P-frames) and bidirectionally coded frames (B-frames). I-frames use purely spatial compression, and are processed independently of other frames. Thus, I-frames are processed entirely by intra-frame operations. A complete picture can be generated from an I-frame alone. P-frames are coded using the previous I- or P-frames. The compression of P-frames relies on temporal prediction from previous I- or P-frames. Only forward motion estimation/compensation is used in the temporal prediction. While P-frames may contain some intra-coded data, a complete picture, of the same quality as a picture which can be generated from an I-frame, cannot be generated from a P-frame alone because of the use of forward motion estimation/compensation in a P-frame. B-frames are coded by a bidirectional motion compensated predictive encoder using the two adjacent I- or P-frames. B-frames are temporally predicted from two adjacent anchor frames. Both I- frames and P-frames serve as anchor (or reference frames) to the motion compensation of other frames. The B-frame temporal prediction uses motion compensation in forward and/or backward directions. B-frames are never used to predict other frames. Because of the dependence of B-frames on the two adjacent anchor frames, B-frames alone do not contain sufficient data from which to generate a recognizable picture. The above three types of frames differ in their use of motion estimation. Motion estimation refers to the process of computing the spatial displacement of blocks of pixels due to motion. The resultant motion vectors are used in motion-compensated predictive coding. MPEG uses both forward motion estimation (in which the estimation is of the future referenced to the past), and backward motion estimation (in which the estimation is of the past referenced to the future). Forward and backward motion estimation are also combined to produce bidirectional motion estimation. In accordance with the MPEG proposal, frames are arranged in ordered groups. A typical group is a series of frames containing, e.g., in the order of their being displayed, one I-frame, two B-frames, a P-frame, two B-frames, a P-frame and then two B-frames. FIG. 5 illustrates a typical Group of Pictures in the order they are displayed and the temporal prediction relationship between the various frames which comprise the group. A group of pictures is intended to assist random access into the sequence. In the stored bit stream, the first coded frame in the group is normally an I-frame. In accordance with the MPEG proposal, after the analog video signals are digitized, the digital data is organized into macroblocks. A macroblock is the unit of motion compensation and adaptive quantization. A number of macroblocks comprise a frame. Each macroblock defines a predetermined spatial region in a picture, and contains luminance and chrominance information. The MPEG proposal provides for the arrangement of macroblocks into slices. A slice is an integer number of consecutive macroblocks from a raster of macroblocks. A slice represents the boundary within which differential coding of macroblock parameters, e.g. DC coefficients of a DCT, and motion vectors, is performed. Each slice has its own header information and can be independent of other slices. Each slice contains at least one macroblock. Slices do not overlap and there are no gaps between slices. The position of slices may change from picture to picture. The first slice starts with the first macroblock in the picture and the last slice ends with the last macroblock in the picture. The first macroblock in a slice has its macroblock parameters, e.g. DC coefficients of a DCT (if intra-coded) and motion vectors, differentially coded from a constant value. Each subsequent macroblock in a slice has its macroblock parameters measured as an offset from the previous macroblock in the slice. Accordingly, the size of the slice is the minimum size for which a piece of data can be recovered and correctly decoded. If part of a slice is lost, it may not be possible to decode the differences in motion vectors and DC coefficients contained in the remaining part of the slice. FIG. 6 illustrates a macroblock in accordance with the MPEG proposal which may be used, e.g. for HDTV signals. As illustrated in FIG. 7, a macroblock comprises four 8.times.8 luminance blocks (Y0, Y1, Y2, Y3) and two 8.times.8 color difference blocks (Cr and Cb). The four luminance blocks (Y0, Y1, Y2, Y3) and two color difference (Cr, Cb) blocks, which form a single macroblock are used to encode a 16.times.16 picture element array covering the same spatial region in a picture. As described above, a macroblock serves as the unit of motion compensation and adaptive quantization. In accordance with the MPEG proposal, motion-compensated predictive coding is carried out by calculating motion vectors for every macroblock in a P-frame or B-frame. MPEG compression encodes motion vectors on a macroblock basis, but does not specify the technique for computing them. Thus, a variety of different motion estimation techniques can be implemented consistent with the MPEG standard. One technique, for example, is to compute motion vectors from the frame-to-frame correlation of blocks of pixels in the luminance signal, resulting in a motion vector for the luminance component of the macroblock. The best mode for encoding each macroblock is selected. Within a given picture, each macroblock is coded in one of several different modes. The intraframe coding mode refers to macroblock coding in which only spatial information is used. Conversely, the interframe coding modes (forward motion, backward motion and bi-directional motion) refer to macroblock coding in which information from frames other than the current frame is used in the coding, typically for temporal prediction in motion-compensated predictive coding. For I-frame macroblocks, only intraframe coding mode is available. P-frame macroblocks are first checked to determine if interframe coding without motion compensation is appropriate. This decision is made by computing the luminance energy of a forward prediction residual for the macroblock that results from an interframe coding without motion compensation, and comparing it to a threshold value. If the residual energy is below the threshold, then the macroblock will be coded using interframe coding without motion compensation. Otherwise, the residual macroblock from interframe coding with forward motion compensation will be derived and used in the final step of the coding mode selection. B-frame macroblocks are similarly processed to determine whether interframe coding is appropriate. Since B-frames may be bidirectionally coded, interframe coding can be either forward or backward, based on the preceding and following anchor (i.e., I- or P-) frames. It may also be based on the average of those macroblocks from the preceding and the following anchor frames. In interframe coding using motion compensation, there are three possible modes: forward, backward, and bidirectional. The choice of coding mode for B-frame macroblocks is also determined on the basis of luminance prediction residual energy. The final step in the coding mode selection for both P- and B-frame macroblocks is to choose between interframe coding and intraframe coding. Generally, P-frames and B-frames are encoded using interframe encoding. This selection is made by comparing the luminance energy of the original macroblock to the energy of the luminance interframe (with or without motion compensation) prediction residual macroblock. If the original macroblock has less energy than the prediction residual macroblock, the intraframe coding mode is selected. After the motion vectors have been calculated, each macroblock is transform encoded. In summary, the macroblocks are transformed from pixel domain to the DCT coefficient domain. The picture information in each frame (i.e., pixel values for I-frames, and residual error after prediction for B and P-frames) is transformed using the DCT and then adaptively quantized. For the purpose of performing the DCT, a frame picture is divided, for example, into blocks of values (i.e., arrays of DCT coefficients). Each quantized DCT coefficient along with other MPEG-specific data is variable length encoded by the video encoder module to form MPEG codewords. The DCT process generates blocks of DCT coefficients in a zigzag scanned format (i.e., the low-frequency coefficients are followed by the higher frequency coefficients). This zigzag scan arrangement facilitates the subsequent run-length coding process. The DCT coefficient for which the frequency is zero in both dimensions is called the DC coefficient. Next, adaptive quantization is performed on each block of DCT coefficients. After adaptive quantization has been applied to the DCT coefficients, the coefficients undergo further compression involving such known techniques as differential coding, run-length coding and variable length coding. As a result, the video compression encoder module produces encoded data, in the form of variable length codewords, and information concerning the number of header and coded data bits per macroblock. The header provides, inter alia, a mechanism for dynamic specification of the picture size, in terms of pixels per line and a pixel aspect ratio. The video compression encoder module also outputs information that states which frame the encoded data represents and which macroblock and slice the encoded data represents. The codewords are then further encoded by, for example, a transport encoder, to provide reliable delivery of the variable length encoded compressed video. The MPEG compression standard also produces D-pictures, also referred to as D-frames. A D-picture is coded using only intraframe encoding. Of the DCT coefficients in the coded representation of a D-picture, only the DC coefficients are present. Thus, D-pictures comprise the DC coefficient of each DCT block in the frame. D-pictures are not used in sequences containing frame types, such as I-, P-, or B-frames. D-pictures are thus stored separately from the normal MPEG bitstream and must appear in a separate picture sequence that cannot contain any other type of picture. Furthermore, D-pictures must be encoded and transmitted separately. They must also be decoded using a separate algorithm from the algorithm used to decode the other frames, i.e. the I, P & B-frames. Thus, D-pictures cannot be decoded in conjunction with other MPEG data such as I-frames. A proposed standard for HDTV using motion compensation compression techniques is the Advanced Digital Television ("AD HDTV") system developed by the Advanced Television Research Consortium. The proposed AD HDTV system is described in the Advanced Television Research Consortium's "Advanced Digital Television, System Description" of Jan. 20, 1992 and in the Advanced Television Research Consortium's "Advanced Digital Television, Prototype Hardware Description" of Feb. 12, 1992 which are both herein expressly incorporated by reference. The proposed AD HDTV system uses a modified data compression technique based on the ISO-MPEG standard, called MPEG++. MPEG++ compression uses a two-pass encoding system that has the function of adaptively segregating video data produced by the compression processor into a subjectively important high priority ("HP") bit stream and a less important standard priority ("SP") bit stream. The high priority bit stream provides data sufficient to produce a viewable picture and the additional standard priority bit stream provides the additional data need to produce full HDTV quality video. Separation into high and standard-priority data streams is carried out using an adaptive prioritization algorithm which takes into account, inter alia, the MPEG frame type (i.e., I, B or P), and the relative occupancies of HP and SP rate buffers at the output of the MPEG++ encoding system. Highest priority is given to the MPEG headers that indicate the start of video data blocks (e.g., slices and macroblocks), which are needed to initiate the decoding of received video data. I-frame data and P-frame motion vectors are also given relatively high priority, while most B-frame data is transmitted with standard priority. The adaptive prioritization algorithm outputs the data stream of codewords and a signal representing the priority level for each codeword stream. The AD HDTV system uses a Prioritized Data Transport (PDT) format to provide reliable delivery of variable length encoded compressed video data. The PDT format supports flexible multiplexing of video, audio and data services without requiring preselection of operating bit rates. The AD HDTV system accordingly formats all data into a sequence of fixed length packets, each with appropriate headers for identification and error recovery. These packets are called transport cells. The data stream of codewords and the priority level for each code word, i.e. HP or SP, is received and the transport cells are filled with the data as appropriate to its priority. Each transport cell is tagged with an Adaption Header which includes information necessary to restart video decoding if synchronization is lost prior to the current transport cell. This information might include macroblock number, block position within the macroblock, frame number, field or frame coding, quantization level, priority of the data, and a pointer to a data boundary within the cell. Cells at different priority levels, i.e. HP or SP, may have different header information as appropriate to decode data of the given priority level. As described above, the proposed priority encoder of the AD HDTV system separates a single encoded video codeword stream from the compression processor into two data streams corresponding to two priority levels: the high priority (HP) and the standard priority (SP) data streams. The goal of the priority encoder is to produce a HP codeword stream that represents a viewable picture. This HP codeword stream can be transmitted at a higher power and in a separate frequency range to increase the area of reception for at least the basic video picture. The proposed AD HDTV system allows different approaches and criteria to be employed in the construction of the HP and SP codeword streams. An allocation process takes place once at the beginning of every frame to determine the fraction of data for that frame that should be transmitted on the high priority channel. This decision is based on the type of frame being transmitted (I-, P- or B-frame), the number of bits generated for that frame (available from the compression processor) and the state of HP and SP buffers. In general, I-frame information tends to be the most important, and is generally transmitted on the high priority channel. There are two reasons for this. First, the effect of transmission error on I-frame data lasts longer than that on a P- or a B-frame because it is the basis of prediction for both P- and B-frames. Second, since there is no temporal prediction for I-frames, errors on DCT coefficients may result in complete loss of picture information for a macroblock. P- and B-frames, on the other hand, can rely on partial motion information to produce reasonable images, even in the event of complete loss of the DCT coefficients due to transmissions errors. Hence, the general objective is to transmit as large a fraction of the I-frame data as possible on the high priority channel. For P-frames, most if not all motion vector data, and possibly some DCT coefficients are transmitted on the HP channel. More DCT coefficients are transmitted on the HP channel if additional capacity is available. It is important to at least transmit motion information for these frames on the HP channel since the effect of losses tends to propagate until the next I-frame. Finally, B-frames are considered the least important because they are not used for prediction purposes. Therefore, B-frame errors are constrained to a single frame and do not propagate to other frames. In general, the amount of B-frame data that are transmitted on the high priority channel is the smallest among the three types of frames. While the AD HDTV priority assignment process does not specify exactly what must appear in the HP data stream, the AD HDTV proposal provides general guidelines of priority assignments that can be used for each frame type. The AD HDTV proposal states that for all frame types, the three most important types of information are frame headers, slice headers and macroblock information (addresses, types and quantitization). For I-frames, next in priority are (in order) DC DCT coefficients, low frequency DCT coefficients and finally high frequency DCT coefficients. For B- and P-frames, next in priority are (in order) motion vectors, DC DCT coefficients, low frequency DCT coefficients and finally high frequency DCT coefficients. As stated above, the codewords are prioritized into DCT coefficients of increasingly higher spatial frequency. In the proposed AD HDTV system, the HP data rate is one fourth the SP data rate. Accordingly, the ratio of HP to SP data is 1:4. FIG. 7 illustrates the structure of a transport cell in accordance with the AD HDTV system proposal. Each cell contains an error correction layer and a prioritized data transport (PDT) format layer. As illustrated in FIG. 7, there are three sublayers within the PDT format layer. They are a data link layer, an MPEG++ adaption layer and the service data layer. The data link layer comprises a service type byte which carries the priority level indicator (HP or SP) and a frame check sequence for error detection. Accordingly, the service type byte allows immediate identification of a transport cell to be either high or standard priority. The service type byte also identifies the data type for video, audio, and auxiliary data and contains a 4-bit continuity counter (CC) component. This counter increments by one for each cell transmitted. The continuity counter allows the receiver buffers to detect cell discontinuity (due to uncorrectable cell errors) for a particular transport service. The MPEG++ adaption layer allows a decoder to synchronize to variable length codes within the MPEG compressed video service. The first usable entry-point in each cell is identified and stored in an Adaptation Header (AH) of the MPEG++ adaption layer. For high priority data, the AH contains slice entry point information (i.e., a pointer to the first bit of the entry point of the slice in the transport data), frame type information, the frame number and the slice numbers within frame. For low priority data, the AH contains a pointer to the start of a macroblock, frame type information, the frame number and the macroblock number within the frame. The video service layer of each transport cell contains transport data which may include video, audio and/or control data. The transport data includes video-specific parameters that can be used for resynchronization after a long burst of errors. A record header (RH) appears at the beginning of each slice, and is sent in the high priority transport cells only. Any number of record headers may appear in a cell, but only the first is used as an entry-point in the AH. The entry-point feature in the AH for a HP cell, as stated above, contains information regarding the location of the start of data block (which is always a RH), as well as other information such as the frame type and slice number. The RH can include a priority breakpoint (specifying the break between HP and SP information), a vertical position, a quantization scale factor, and a record header extension. To summarize, in accordance with the AD HDTV system proposal, each HP cell contains data arranged in slices. Each SP cell contains data arranged in macroblocks. Entry points allow these data blocks to be segmented across cell boundaries. However, the AH information only contains one pointer to the start of the macroblock or slice. There may, however, be more than one macroblock or slice starting in each cell. Thus, at least one of these blocks will not have an entry point recorded in the AH. Alternatively, a macroblock or slice may take up many cells, and thus there is not an entry point for the block in subsequent cells. In the event of a cell loss, the entry point information can be used for the rapid resynchronization of the transport data. In the event of an error leading to the loss of a cell without an entry point, the receiver will restart decoding at the next block with an entry point. Another proposed standard for HDTV is the DigiCipher system (also referred to as the ATVA-Interlaced system) developed by General Instrument Corporation. This proposed system is described in General Instrument Corporation's "DigiCipher HDTV System Description" of Aug. 22, 1991 which is hereby expressly incorporated by reference. The DigiCipher system uses transform encoding as the technique of data compression. The DigiCipher system does not have complete, temporally coincident frames of intra-coded data. Rather, intra-frame data updates an image on a regular basis in vertical columns on the screen. In the DigiCipher system, a pixel is an 8 bit active video sample (luminance or chrominance) while a block is an image area of 8.times.8 pixels. A superblock is an image area comprising 4 luminance blocks horizontally by 2 luminance blocks vertically and one associated chrominance block each for U and V values derived from that image area. A macroblock is an image area of eleven horizontally arranged superblocks. The DigiCipher system transforms a block of pixels into a new block of transform coefficients using the DCT. The transform is applied to each block until the entire image has been transformed. Next the number of bits required to represent the DCT coefficients is reduced. Accordingly, a coefficient quantization process gives weights to each of the DCT coefficients. Each coefficient is divided by its weighing factor. Then a quantization factor is determined based on scene complexity and perceptual characteristics, and additional scaling takes place by dividing the weighted coefficients by the quantization factor. The quantization method of the DigiCipher method, however, is not applied to the DC coefficient. The most significant bits of the DC coefficient are always selected, independent of the quantization level. Next a statistical coding technique, such as a Huffman coding, is used that does not degrade the image. The DCT coefficients are serialized into a sequence and amplitude/run length coded. A codeword is assigned indicating the amplitude of the coefficient and the number of zeros preceding it (runlength). In addition, the DC coefficient is Huffman coded after it is differentially coded within a superblock. The efficiency of this coding process is heavily dependent on the order in which the coefficients are scanned. By scanning from high amplitude to low amplitude, it is possible to reduce the number of runs of zero coefficients typically to a single long run at the end of the block. The coefficients are zigzag scanned going down first from the DC coefficient. There is a limit to the amount of compression possible by spatial processing alone. An interframe coder, however, can benefit from temporal correlation as well as spatial correlation. A very high degree of temporal correlation exists whenever there is little movement from one frame to the next. In the DigiCipher system, the signal is compressed by first predicting how the next frame will appear and then sending the difference between the prediction and the actual image. A reasonable predictor is the previous frame. This sort of temporal differential encoding will perform very well if little movement occurs or if there is little spatial detail. At other times, it will be less effective and occasionally worse than if the next frame had simply been encoded without prediction. Instead of transform coding an image directly, an estimate of the image is first generated using motion compensation. The difference between this estimate and the actual image is then transform coded and the transform coefficients are then normalized and statistically coded as before. The second of the two frames from which the motion estimates are derived is always the previous frame as it appears after reconstruction by the decoder. Differential processing in general causes a basic problem for the decoder. When a decoder is tuned to a new channel, it has no "previous frame" information. Acquisition would be delayed until at least one pulse code modulation ("PCM") version of every block is received, which results in an unbounded acquisition time. Thus, in the DigiCipher system, during each 0.37 second interval, all blocks are processed once in PCM form on a distributed basis. This technique results in a 0.37 second differential pulse code modulation ("DPCM") based acquisition time component, but spreads the resulting increase in channel bits uniformly over time. The 0.37 second parameter would imply a forced PCM block once every 11 frames, and there is a necessary but nontrivial reduction in the overall compression efficiency. The 0.37 second parameter can be varied to trade off acquisition time versus efficiency. Thus, the DigiCipher system has very little tolerance for errors or missing information in the data stream. The DigiCipher system will repeat a macroblock from the previous frame when an error is detected. Errors are detected by checking whether all the compressed data is used when a macroblock processing is finished. Because of the variable length encoding of data, resynchronization must take place after an error occurs. There is no place for resynchronization, however, except at the start of the next frame using a next frame pointer. The above-described systems do not specify the data formats and compression techniques to make the systems suitable for VTR applications. Requirements peculiar to VTRs include the need for the ability to record for normal speed playback as well as fast forward playback at a variety of speeds, reverse playback at "normal" speed and other speeds, slow motion playback and freeze-frame viewing. A VTR must be able to receive data and arrange it so that it can be stored on a tape in a suitable format to allow playback at different speeds and in different modes. The playback of recorded compressed digital video data is difficult at speeds faster than the normal forward speed and in reverse direction. The reason is that digital compression systems, such as those systems described above (i.e., the AD HDTV system and the DigiCipher system) produce very compact non-redundant descriptions of images. Consequently, the delivery of only a portion of the compressed data (such as occurs at higher than normal playback speeds) results in a playback data stream that is largely incomprehensible to a video decoder. The use of the MPEG standard for supporting fast play modes in a VTR has been suggested by a report titled "Coding of Moving Pictures and Associated Audio for Digital Storage Media at up to about 1.5 Mbit/s", ISO 2-11172 rev 1, Jun. 10, 1992, hereinafter "the MPEG report", which is hereby expressly incorporated by reference. In the MPEG report, at pp. D-52 to D-54, it is suggested that MPEG D-frames and I-frames, both of which contain only intra-coded material, can be used to support fast forward play. As described above, MPEG D-frames, which are an extension of the normal MPEG data stream, contain only the DC coefficients of a DCT transform. Therefore, D-frames contain only information encoded using intra-frame processing. In MPEG, D frames are completely independent of the normal bitstream of I-, B- and P-frames and thus must be encoded, transmitted and stored separately from the normal data stream. Furthermore, D-frames must be decoded by a different algorithm which requires the use of a separate decoder circuit from the decoder circuit used to decode I-, B-, and P-frames. Such requirements of separate encoding, decoding and storage of D-frames adds to the cost and complexity of a VTR which uses D-frames for fast play modes of operation. In addition, the picture quality that can be reproduced using intra-coded D-frames alone is relatively poor compared to pictures which can be reproduced from I-frames, for example. Further, the MPEG report suggests that the MPEG standard can be used to support fast play if I-frames are appropriately spaced in a sequence. As an example, the MPEG report states that if I-frames were spaced regularly every ten frames, then a decoder might be able to play the sequence at ten times the normal speed by decoding and displaying only I-frames. While suggesting the above use of I-frames for fast play, the MPEG report recognizes that this concept places considerable burdens on the media and the decoder. To use I-frames as suggested, the media must be capable of speeding up and delivering ten times the data rate and the decoder must be capable of accepting this higher data rate and decoding the I-frames. While the MPEG report recognizes these problems, it fails to teach how to overcome these burdens on the media and decoder so that a VTR can actually be implemented using the suggested approach. The MPEG report further suggests that the media itself might be used to somehow sort out the I-frames and transmit them to produce a valid MPEG video bitstream during fast play. However, the MPEG report does not suggest how the media might actually implement such a system. In addition to the problems encountered during fast play, there are several problems associated with reverse play by a VTR which stores information in accordance the MPEG standard or other highly compressed data formats. For a VTR to decode an inter-frame encoded bitstream and play in reverse, the VTR's decoder must decode each group of pictures in the forward direction, store the decoded pictures, then display them in reverse order. This places severe storage requirements on the decoder and further complicates the problem of gaining access to the coded bitstream in the correct order. Furthermore, similar problems to the ones discussed above in regard to fast play arise if reverse playback is to be performed at different speeds. Accordingly, there are several problems which need to be addressed when the MPEG or similar standards are used for recording video information on a tape by a VTR. One known VTR which supports high speed playback receives an analog video signal, digitizes the signal, and converts each picture frame in the signal into main information (for rough formation of the whole image during high speed playback) and subinformation (for forming details of the image). The main information and subinformation corresponding to each picture frame are recorded on a single track with each track on a tape storing data corresponding to a different picture frame. Each block of main information, corresponding to a particular frame, is recorded at the center of the recording track which contains all the data corresponding to the particular frame. The subinformation corresponding to the particular frame is recorded on regions on both sides of the center of the track containing the main information belonging to the particular frame. During trick play, the main information is used to generate images which are displayed. The known VTR does not receive data in a compressed format and, to make its conversion to main and subinformation, requires that the received analog video signal be digitized and encoded before the data can be recorded on tape. Furthermore, the encoding and one frame per track recording processes used support only intra-frame encoding of pictures. Such a system has serious drawbacks where the picture information for an intra-coded frame of video, such as in the case of HDTV, may not be able to be stored in a single tape track because of the large amount of data involved. Furthermore, such a system fails to take advantage or address the use of inter-frame coding techniques to reduce the amount of data which must be stored for a series of frames. SUMMARY OF THE INVENTION The present invention provides a digital video recorder compatible receiver. In a representative embodiment, the receiver comprises a digital video tape recorder ("VTR") port and a video decoder including an error concealment circuit. The video decoder receives video data which it decodes and outputs to a display device such as a cathode ray tube or liquid crystal display device. The digital VTR port is adapted for coupling the receiver to a VTR command and data output of a video tape recorder. The digital VTR port receives from the VTR video data and VTR commands. The VTR commands may indicate, e.g., that the VTR is operating in trick play mode or that particular trick play error concealment operations are to be performed. The video data can comprise, for example, digital video/audio data packets. The VTR commands can be received by the receiver via a separate command line coupled to the digital VTR port or as part of the video/audio data packet stream. Alternatively, the error concealment circuit may detect that the VTR is operating in trick play mode by monitoring the received video data and, e.g., detecting that data for fewer inter-coded frames are being received than would be the case during normal VTR playback operation. The video decoder including the error concealment circuit is coupled to the digital VTR port. On receiving a VTR command that indicates that the VTR is operating in trick play mode or upon determining from the received data that the VTR is operating in trick play mode, the error concealment circuit disables normal play error concealment performed on the video data and enables trick play error concealment. While there may be a number of error concealment operations that are the same for both normal play error concealment and trick play error concealment, trick play error concealment includes additional error concealment operations which are not performed during normal playback operation. Thus, trick play error concealment includes error concealment operations which are specifically directed to the concealment of errors resulting from trick play VTR operation such as fast forward or reverse playback operation. The error concealment circuit of the present invention may include a temporal filter and/or a spatial filter for performing temporal filtering and/or spatial filtering, respectively, of the video data when trick play error concealment is enabled. Accordingly, the receiver of the present invention is capable of treating data differently during VTR trick play operation than during normal play operation. This permits a receiver of the present invention to display data supplied from a VTR during trick play mode in a manner that provides higher quality images than would be possible if the receiver operated as if it were receiving normal play data. One embodiment of the receiver of the present invention further comprises a transport and priority decoder circuit coupled to the digital VTR port and the video decoder. The transport and priority decoder circuit receives the video/audio transport data packets and VTR commands and performs depacketization and priority decoding on the video data to generate video codewords which are supplied to the video decoder for additional processing and error concealment operations prior to display of the video data. Additionally, in accordance with another feature of the present invention, the digital VTR port and the transport and priority decoder circuit may be coupled to a tuner module. The tuner module receives a signal from a transmitter or other transmission service and performs demodulating, trellis decoding and de-interleaving on this signal to generate video/audio transport data packets. In addition, via the tuner module, the receiver of the present invention can receive a video signal from a VTR. If the signal is from the VTR, the receiver's error concealment circuit and/or video decoder may receive VTR commands via the tuner module along with other video and/or audio data. Accordingly, the receiver of the present invention can receive data from either a digital VTR port or from radio frequency signals. A signal select device is operated to select either the transport data packets from the tuner module or the transport data packets from the VTR port for transport depacketization and decoding by the transport and priority decoder. Thus, the receiver of the present invention can receive data from a VTR directly or through its tuner module. In either case, if the receiver detects that it is receiving data from a VTR operating in trick play mode or the receiver receives a VTR command indicating that it is receiving data from a VTR operating in trick play mode, trick play error concealment is performed and normal play error concealment is disabled by the receiver in order to provide a series of recognizable images or portions of images to a display device when receiving data from a VTR operating in trick play mode. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1(a) is an illustration of a conventional two head video recording system. FIG. 1(b) illustrates a portion of a tape, including a series of parallel tracks, written on the tape by the video recording system of FIG. 1(a) wherein track separations are shown only for the purpose of clarity. FIG. 1(c) illustrates the paths traced by the record/playback heads of the video recording system of FIG. 1(a), across a portion of the tape during playback operation at three times the standard playback speed. FIG. 2(a) is an illustration of a four head VTR system comprising 2 pairs of co-located heads. FIG. 2(b) illustrates the paths traced across the tape by the pairs of co-located heads of the VTR system of FIG. 2(a) during playback operation at three times the standard playback speed. FIG. 3(a) is an illustration of an 8 head VTR system having four heads distributed evenly over each 180.degree. portion of a rotary head cylinder. FIG. 3(b) illustrates the paths traced out across the tape by the heads of the VTR of FIG. 3(a) during 4.times. playback speed operation. FIG. 4(a) is an illustration of a 2 channel, 4 head VTR system. FIG. 4(b) is an illustration of a portion of a tape including a series of 2 channel tracks recorded on the tape by the VTR system of FIG. 4(a) . FIG. 5 is an illustration of a typical Group of Pictures in the order they are displayed. FIG. 6 illustrates a macroblock in accordance with the MPEG proposal which may be used, e.g., for HDTV signals. FIG. 7 illustrates the structure of a transport cell in accordance with the AD HDTV system proposal. FIG. 8(a) is a block diagram of a video and audio transmission circuit in accordance with one embodiment of the present invention. FIG. 8(b) illustrates a representative video packet header which may be attached by the transport packetizer, illustrated in FIG. 8(a), to the data packets generated in accordance with one embodiment of the present invention. FIG. 9 is a block diagram of a circuit for a digital VTR compatible receiver in accordance with one embodiment of the present invention. FIG. 10(a), is a block diagram of a VTR recording circuit in accordance with one embodiment of the present invention. FIG. 10(b) illustrates a data block which is representative of one possible format for a data block which may be generated by the VTR framing and ECC circuits of the recording circuit of FIG. 10(a). FIG. 11 is a block diagram of a VTR playback circuit in accordance with one embodiment of the present invention. FIG. 12(a) illustrates a portion of a tape containing a plurality of trick play tape segments arranged to form a multi-speed playback track in accordance with the present invention. FIG. 12(b) illustrates a portion of a tape containing a plurality of trick play tape segments arranged to form a multi-speed playback track in accordance with one embodiment of the present invention. FIG. 12(c) illustrates a portion of a tape including a plurality of multi-speed playback tracks in accordance with one embodiment of the present invention. FIG. 12(d) illustrates a portion of a tape including a multi-speed playback track arrangement which is implemented for a VTR system using two data channels per track. FIG. 13(a) illustrates the portions of trick play segments of a fast scan track from which data may not be recovered during trick play operation due to track switching loss. FIG. 13(b) illustrates a portion of a tape with both 7.times. reverse fast scan tracks and 9.times. fast forward fast scan tracks recorded on the tape in accordance with one embodiment of the present invention. FIG. 13(c) illustrates the trick play tape segments of 3.times. fast scan tracks which a 4 head, 2 channel VTR can read during trick play operation. FIG. 13(d) illustrates the trick play tape segments of 3.times. fast scan tracks which an 8 head, 2 channel VTR with co-located heads can read during trick play operation. FIG. 14(a) illustrates the range of areas, of a 2 channel track, the heads of a 2 channel VTR may pass over during trick play operation given expected tracking errors. FIG. 14(b) is an illustration of a tape segment and the various possible regions of the tape segment that may be passed over by a head of a VTR during trick play operation in view of expected tracking errors. FIG. 15 is an illustration of a tape segment including both a 9.times. fast forward fast scan track and a multi-speed playback track. DETAILED DESCRIPTION One embodiment of the present invention is directed to transmitter circuits, which supply video (and audio) signals to digital video recording devices, e.g., VTRs, for recording and later playback during both normal and trick play operation. Various other embodiments of the present invention are directed to circuits, e.g., VTR record and playback circuits, for recording digital video (and audio) signals for playback during trick play operation. In addition, still other embodiments of the present invention are directed to receiver and display circuits which are capable of receiving and displaying transmitted audio and video signals received from, e.g., a transmission service or a VTR. Various circuits and embodiments of the present invention facilitate VTR trick play operation by, e.g., facilitating the selection of data for recording in tape segments, referred to as trick play tape segments, which are then read during VTR trick play operation. In accordance with various embodiments of the present invention, a VTR writes data, which is particularly useful for generating recognizable images during trick play operation into trick play tape segments as will be described below. Because trick play segments are of a limited size, the selection of data that is written into such segments becomes important if recognizable images of reasonable quality are to be generated from the limited data read from the trick play segments during trick play operation. The data contained in each trick play segment comprises what are referred to as trick play data blocks. Accordingly various embodiments of the present invention, described below, are directed to circuits which prioritize and sort video data for recording in trick play segments. Furthermore, several features of the present invention support prioritization and sorting of video data by a VTR without requiring the VTR to fully decode the data packets which comprise the video data stream. The present invention is also directed to circuits which optimize the amount of data that can be read from trick play segments during trick play mode by locating the trick play segments at particular locations on a tape designed to optimize recovery of trick play data during VTR trick play operation. As will be described below, in accordance with one feature of the present invention, trick play segments may be located in a geometric arrangement on a tape so that sufficient trick play data can be recovered at several different trick play speeds and directions of operation to generate an acceptable number of recognizable images or portions of images during trick play operation. As will be described below, the trick play segments in such an embodiment form what is referred to as a "multi-speed" playback track which may run, e.g., parallel to the length of the tape. In another embodiment, trick play segments may be located in such an arrangement that the heads of a VTR pass over an optimum number of trick play segments during operation at a particular trick play speed. In accordance with this embodiment, the trick play segments that are passed over during each pass of a VTR's head across the width of the tape during trick play operation at a particular playback speed and direction of operation, comprise a fast scan track for the particular trick play speed and tape direction. One particular embodiment of the present invention is directed to a video (and audio) transmission circuit which digitizes, encodes, prioritizes and packetizes video (and audio) signals, for subsequent transmission, in a manner that optimizes the format of the resulting digital data for use by a video recording device, e.g., a VTR. The system of the present invention may be used in conjunction with, e.g., various digital HDTV systems. As described above, there are various proposals for digital HDTV systems. However, none of the proposed systems include data formats which are fully optimized for VTR compatibility. One embodiment of the present invention is directed to a circuit that optimizes digital video (and audio) data streams for use with VTRs and other digital video recording devices while maintaining compatibility with the compression techniques normally used to create such data streams, e.g., the compression techniques used by the various proposed HDTV systems. Generally, the circuit of the present invention provides for implementation of (1) a VTR optimized data prioritization scheme, (2) packetization of the data in a manner that is reflective of the implemented VTR optimized prioritization scheme, and (3) headers that describe the contents of the data packets and permit the contents to be identified without full decoding of the data packets. Referring now to the drawings, and initially to FIG. 8(a), there is illustrated a block diagram of a video and audio transmission circuit, according to one embodiment of the present invention, generally indicated by the reference numeral 100. The circuit 100 comprises a video encoder 102, an audio encoder 103, a prioritizer 104, a transport encoder 109, a channel modulator 110 and a transmitter/antenna 112. In one embodiment of the present invention, the video encoder 102 has a video input for receiving an uncompressed analog video signal from a video source such as a video camera. The video encoder 102 digitizes, encodes and compresses the received video signal to produce a stream of encoded video data, e.g., a video codeword data stream. To produce the video codeword data stream, the video encoder 102 may use one or more known encoding and data compression techniques such as motion estimation and/or other MPEG encoding techniques. Accordingly, depending on the encoding technique used, the encoder can output data in the form of codewords corresponding to various types of video data including video frames, superblocks, slices, macroblocks, and various other subsets of video information which the data in the codeword data stream can represent in accordance with various possible data structures and encoding techniques. The video encoder 102 may generate picture headers in addition to codewords, with an individual picture header being associated with the particular codewords that comprise each individual video frame. The codeword data stream output by the encoder 102 comprises, e.g., a stream of codewords wherein each codeword is represented by a variable number of bits. The codewords are normally recognizable by their position relative to one another and therefore are understood in the context of their order in the codeword data stream. The codewords in the data stream may represent, e.g., picture, slice, and macroblock headers. The audio encoder 103 receives an audio signal from, e.g., a microphone which can be attached to a video camera which serves as the source of the video signal supplied to the video encoder 102. The audio signal is digitized, encoded, and packetized by the audio encoder 103. The audio encoder 103 outputs packets of encoded audio data via an audio data packet output that is coupled to a corresponding input of the transport encoder's multiplexer 108. In video transmission systems, such as the proposed AD HDTV system, which transmit portions of the video data over multiple data channels, it is necessary to provide a method of separating the video data stream for transmission over separate data channels based on, e.g. prioritizing the video data. The video data can then be separated according to its relative priority for transmission over the various data channels based on the data's assigned priority level relative to the other data in the data stream. For example, the AD HDTV system proposal requires that the codewords output by the video encoder be divided into two data streams, i.e. a high priority (HP) data stream, which contains data essential for creating viewable images, and a standard priority (SP) data stream which contains the remaining data required to produce images of high definition quality. In the AD HDTV proposal, the HP and SP data streams are transmitted via two separate data channels at a HP to SP data ratio of 1:4. While the proposed HDTV systems provide for data prioritization and transmission over separate data channels, the proposed prioritization schemes fail to optimize data based on the data's utility to VTR applications. The prioritizer 104 of the present invention, illustrated in FIG. 8(a), implements a prioritization scheme that is based on the video data's utility to VTR applications such as trick play operation. Thus, video data utility is determined as a function of how useful the data is for generating a recognizable and scaleable image which is useable during trick play operation. As illustrated in FIG. 8(a), a video codeword data stream output of the video encoder 102 is coupled to a corresponding input of the prioritizer 104. The prioritizer 104 receives the video codeword data stream from the video encoder 102 and prioritizes the codewords in the data stream into different priority levels. As part of the prioritization process, the prioritizer 104 recognizes sub-sets of various types of digital video data, i.e., types of data contained in the video codewords, that are particularly useful to VTRs. The video codewords in the video codeword data stream are prioritized, i.e. assigned differing priority levels, based on the relative utility of the data in each codeword to VTR applications and in particular, to the data's utility in generating an image during trick play operation. The prioritizer 104 has two outputs coupled to inputs of the transport encoder 109. The transport encoder 109 comprises a video transport packetizer 106 and a multiplexer 108. The video transport packetizer 106 is responsible for the packetization of the encoded video data, i.e. the video codewords supplied by the prioritizer 104. The prioritizer 104 of the present invention outputs the video codeword data stream via a video codeword data stream output which is coupled to a corresponding input of the transport encoder's video transport packetizer 106. In addition, a priority level signal output of the prioritizer 104 is coupled to a corresponding input of the transport encoder's video transport packetizer 106. Via this connection, the prioritizer 104 supplies the packetizer 106 with a signal that indicates the assigned priority level of the data in the video codeword data stream. The video transport packetizer 106, of the transport encoder 109, is also supplied with several signals from the video encoder 102. The video encoder 102 supplies information to the packetizer 106 indicating a correspondence between the video codewords in the codeword data stream and which particular frame, superblock, slice, macroblock or other piece of video information the data represents. Accordingly, FIG. 8(a) shows a frame information output, a macroblock information output and a slice information output each being coupled to a corresponding input of the video transport packetizer 106. It is to be understood that the number of video information connections between the video encoder 102 and the packetizer 106 may vary along with the actual information sent via these connections depending on the particular encoding and packetizing algorithms implemented. However, the video encoder 102 will generally supply the packetizer 106 with information for inclusion in packet headers which the packetizer 106 adds to each video packet it creates. The video transport packetizer 106 places the video codewords from the prioritizer 104 into video packets and adds headers to each video packet. The packet headers include information necessary to restart video decoding if data synchronization is lost. The information included in the header added by the transport packetizer 106 may include, e.g., macroblock number, superblock position within the macroblock, frame number, field or frame coding, quantization level, the priority level of the data contained in the packet, and a pointer to a data boundary within the video data packet. Different priority packets may be provided with different headers containing information useful in decoding the data of the given level. Appropriately packetizing and identifying the data type and/or the VTR priority level of the packetized video data, using, e.g., packet headers permits a VTR which receives the transmitted packetized data to sort, record, and retrieve the digital information with a minimum amount of decoding. Referring now to FIG. 8(b), there is illustrated a suitable video packet header 150 which can be attached by the transport packetizer 106 to the data packets generated in accordance with the present invention. As illustrated in FIG. 8(b), the packet header 150 comprises a packet ID data block 151, a priority ID data block 152, an entry point data block 154, an entry ID data block 156 and a block of process variables 158. The packet ID data block 151 comprises information identifying the source of the packet, the packets sequence number, etc. The priority ID data block comprises information indicating the priority of the data contained within the particular video data packet. The entry point data block 154 contains a pointer to the next object in the data packet, e.g. a macroblock or superblock header. The entry ID data block 156 contains the ID of the object pointed to by the entry point ID data block 154. In addition, the header 150 also includes a block of process variables 158 which are necessary for decoding and which might be lost during resynchronization. Such process variables may include variables in the video codeword data stream that are global for an entire frame or image sequence. Video data prioritization and packetization in the above manner facilitates a VTR's identification of data which is important to trick play operation. As will be described below, a VTR in accordance with a feature of the present invention, can selectively record packetized data in particular trick play segments, i.e. geographic areas on a tape from which data can be read during trick play operation. Trick play segments are of a limited size. Thus, a VTR which uses these segments to store data for trick play operation, must be selective in the data that it records in the trick play segments if it is going to be able to generate recognizable images from the limited amount of data recorded therein. In accordance with the present invention, the VTR selects the video data to record in these trick play segments from the video data stream based on how useful the data is for generating a recognizable image during trick play operation. The data is then recorded in the trick play segments on a space available basis with the highest priority data being stored before lower priority data. Prioritization and identification of data particularly useful to trick play mode prior to transmission reduces the burden on a VTR to decode and sort the video data while eliminating the need for the VTR to prioritize the data for trick play operation. Accordingly, prioritizing the video data before transmission permits simpler, cheaper VTRs with trick play capability. The video codeword data stream which is output by the prioritizer 104 can be packetized and divided into two or more data streams for transmission via multiple transmission channels, e.g. a high priority and a standard priority transmission channel. In such an embodiment, the video transport packetizer 106 divides the video packets into different data streams based on the priority level assigned to the data contained in each particular video packet by the prioritizer 104. Alternatively, a transmission priority scheme which is independent of the VTR utility prioritization scheme of the present invention may be implemented by a transport data channel prioritizer 105 contained within the video transport packetizer 106. However, regardless of the transmission priority scheme implemented, each of the video/audio transport data packets output by the transport encoder 109 of the present invention is identified by the use of headers which permit a VTR to identify the type and priority level of the data contained in each of the video/audio transport data packets to facilitate selection of the data for trick play operation. Allocating the data which is the most useful for trick play operation to a particular data channel, e.g., a high priority channel, when multiple data transmission channels are being used facilitates a VTR's selection of data to be recorded in trick play segments because the highest priority data for trick play operation is thus segregated to some extent from lower priority data. In such a case, a VTR can initially look to the HP data stream for the data to record in the trick play segments. Then, only when there is not enough data in the high priority data stream to fill the trick play segments does the VTR have to sort the data in the standard priority channel. In such an embodiment, wherein multiple channels are being used to transmit the video/audio transport data packets, the transport encoder's video transport packetizer 106 performs the operation of separating the video packets into multiple data streams for transmission via separate channels using the transport data channel prioritizer 105. The AD HDTV system proposal requires that the HDTV data transport cells be divided into two data streams, i.e. a high priority (HP) and a standard priority (SP) data stream for transmission via two separate data channels. Furthermore, the proposed AD HDTV system uses I-, P-, and B-frames characteristic of MPEG video encoding. While the published system descriptions only set forth general guidelines for determining the contents of the HP data stream, the video packetizer 106 implements a scheme for determining the video data contents of the HP data stream based on the relative utility of the video data for VTR applications such as trick play operation. The video transport packetizer 106 illustrated in FIG. 8(a) is particularly well suited for use with the proposed AD HDTV system because it packetizes and assigns a portion of data to a HP data channel and a portion to a SP data channel. The relative proportion of HP data to SP data in the AD HDTV system proposal is 1:4. Accordingly, over a preselected fixed time period, determined by the amount of time required to fill-up rate buffers contained within the video transport packetizer 106, which are used for sorting data into HP data and SP data, the video transport packetizer 106 assigns the highest priority codewords received from the prioritizer 104 to the HP data stream. The video transport packetizer 106 assigns the remaining data received during the same time period to the SP data stream. The data is thus divided by the packetizer 106 in as close a ratio as possible to the specified ratio of 1 packet of high priority data to 4 packets of standard priority data. To reduce receiver and VTR data buffering requirements, the video transport packetizer 106 and multiplexer 108 organize the video and audio data packets so that the data contained in each Group of Pictures, output by the encoder 102, will be transmitted in a single time period. The single time period associated with each particular Group of Pictures is of the same or shorter length than the time period required by a receiver to display all the frames in the particular Group of Pictures. While such data synchronization is not required by the MPEG standard, such synchronization has the advantage of reducing receiver and VTR data buffering requirements in certain cases. For example, if the Group of Pictures takes up a fixed maximum amount of time to transmit, and thus comprises a corresponding fixed maximum amount of data, the VTR can be synchronized with another source for dubbing together video sequences at each Group of Pictures' boundary. This allows editing of compressed video data streams while avoiding the possibility of buffer overflow in a video decoder used to edit the data comprising a Group of Pictures. Thus, by transmitting the data contained in each Group of Pictures in a single time period of equal or shorter length than the display time period, data buffers of a predictable maximum size may be used in receivers and VTRs. Thus, by fixing the size of the buffers required to avoid data overflows, large buffers with excess data capacity need not be used to avoid the possibility of a data overflow. As illustrated in FIG. 8(a), the video transport encoder 106 has an HP video packet output and an SP video packet output coupled to corresponding inputs of the multiplexer 108. In this manner, the multiplexer 108 is supplied with the data packets output by the video transport packetizer 106. The multiplexer 108 also receives as inputs the audio data packets output by the audio encoder 103 and the auxiliary data packets. The multiplexer 108 loads the video, audio, and auxiliary data packets into video/audio transport data packets. It also adds headers to each transport data packet indicating the type or types of data packets contained within each particular transport data packet. The size of the transport data packets will vary depending on the particular transmission system being implemented. For example, in the case of an AD HDTV compatible transmission system, each transport data packet, referred to as a data cell in the AD HDTV system proposal, has a fixed length of 148 bytes. Generally, to assist in the identification of the various data types, the header which identifies the data type of each video data packet should be attached by the video transport packetizer 106 directly to each video data packet in a predetermined manner or format. Similarly, headers attached by the multiplexer 108 should be attached directly to each video/audio transport data packet. Alternatively, both the video packets and the transport data packets can have their contents identified solely by their position relative to a reference signal within a sequence of video or transport data packets. In such an embodiment, the header need not be directly attached, by the video transport packetizer 106 or multiplexer 108, to the associated data packet, so long as pre-determined timing of the data streams permits a VTR to locate individual video data packets from among the video/audio transport data packets and to identify the type and priority of the data within each packet, without the need for fully decoding the received data stream. The transport encoder 109 has an HP and an SP video/audio transport data packet output coupled to corresponding inputs of the channel modulator 110. The channel modulator 110 modulates the transport data packets using a modulation method, such as quadrature amplitude modulation, which provides a modulated signal compatible with the selected transmission service, e.g., a cable service or an antenna system. Accordingly, as illustrated in FIG. 8(a), the output of the channel modulator 110 is coupled to the transmission service represented by the transmitter/antenna 112. The prioritizer 104 of the present invention, described above in regard to the transmission circuit 100, is particularly well suited for use in systems using MPEG data compression techniques, such as the proposed AD HDTV system. However, the prioritizer 104 can also be used with other digital video systems, such as the DigiCipher system, which do not use MPEG data encoding or fully intra-coded video frames. The prioritizer 104 implements a prioritization scheme which is optimized to assign data to a series of priority levels based on the data's utility for generating a recognizable image or portion of an image during trick play operation. In one embodiment particularly well suited for use with the proposed AD HDTV system, the prioritization scheme implemented by the prioritizer 104 provides for the recognition and assignment of the following encoded video data, listed in their order of utility to video recorder trick play operation, to different priority levels as indicated below:
It should be noted that the above prioritization scheme is the same as the prioritization scheme implemented by a VTR, in accordance with one feature of the present invention when determining which video data to record in trick play segments for later reading and use during trick play operation. If the prioritization of the encoded video data for VTR applications is done before packetization and transmission, and/or the particular sub-sets of data recognized by the prioritizer 104 are identified by packet headers, then the amount of work the VTR must do to identify the appropriate data for filling trick play storage locations is significantly reduced. On the other hand, without such prioritization and packetization, the VTR may be required to decode the variable length coding of the video data stream and organize the data into the priority levels using a prioritizer of its own. Accordingly, in such an embodiment the VTR must include both a decoder and prioritizer with the VTR's prioritizer being the same as, or similar to, the prioritizer 104 which was described above in regard to the transmitter. While some of the available data, e.g. P-frame data, may not be used for trick play operation, because of the limited storage space available for trick play data, e.g. in VTRs with few heads or in the case of high playback speeds such as 9.times. speed, it is still desirable to assign all the data in the video data stream to a particular priority level during prioritization so that the prioritization scheme remains independent of VTR capability. In accordance with the above prioritization scheme which is implemented before data transmission, the prioritization process is independent of a receiving VTR's capabilities. Prioritization of all the video data in the above manner prior to transmission permits each receiving VTR to allocate data to trick play storage locations depending on each VTR's own particular trick play capability without the need for additional data prioritization. For example, the receiving VTR need only record as much of the highest priority data as it can in the trick play space available on a particular tape. Accordingly, when writing data to be read during trick play operation, the VTR writes all the data from the highest priority level and then each subsequent priority level until it runs out of space on the tape for the trick play data. While the above list describes the sub-sets of data which are recognized and prioritized by the prioritizer 104 using terms which generally relate to the AD HDTV system proposal, it is to be understood that when applying the above prioritization scheme to other systems, the term I-frames can generally be interpreted as referring to intra-frame coded data segments of a video image, P-frames can be interpreted as referring to inter-frame coded data segments of a video image, and DC-coefficients can be interpreted as referring to the average values across a luminance or chrominance block of video data. In even more general terms, the DC-coefficients of a DCT may be interpreted as corresponding to the decimated low frequency values for any block of video image data. For example, in applying the above prioritization scheme to the data stream produced by a video encoder which operates in accordance with the Digital Spectrum Compatible ("DSC") HDTV System, proposed by the Zenith and AT&T corporations, every frame of DSC data could be treated as comprising intra-coded data. The basis for the prioritization order of the above data will be described in greater detail below with regard to a discussion of the data's utility for VTR trick play operation. As described above, for VTR applications, it is useful for the video data to be prioritized prior to data transmission in order to reduce the decoding and prioritization burdens placed on a VTR which selects data to be recorded in specific trick play tape locations. The prioritization scheme implemented by the prioritizer 104, and a VTR in accordance with the present invention when the data is not prioritized prior to transmission, is designed to segregate the encoded video data, i.e., the video codewords, into a series of priority levels. A subset of encoded video data is assigned to each priority level based on the data's usefulness in generating a recognizable image from a minimum amount of data during trick play operation. Use of additional data from the lower priority levels adds incrementally to the image quality during trick play mode. For example, an image formed from the data assigned to priority levels 1, 2, and 3 would be of lower quality than an image formed from the data assigned to priority levels 1, 2, 3 and 4. The video data priority levels are arranged so that the data from each subsequent, i.e., lower priority data level, provides improvement in image quality when data from a subsequent priority level is used with the data from the preceding higher priority levels. Thus, the prioritization scheme seeks to optimize image quality while minimizing the amount of data used to generate the image. The sub-set of video header data listed as being assigned to priority level 1 in the above prioritization list associated with the prioritizer 104, is essential for the decoding of a picture. Accordingly, this data is assigned to the highest possible priority level by the prioritizer 104. The sub-set of video header data listed as being assigned to priority level 2 is necessary for the decoding of large sections of a picture and is therefore assigned to the second highest priority level. However, if the image to be reproduced during trick play operation is cropped, e.g., because of data constraints, some data assigned to priority level 2 would be unnecessary as it corresponds to the cropped regions and should be assigned to a very low priority level. The data assigned to priority level 3, the DC coefficients for I-frames, comprise a set of data from which a recognizable i |