United States Patent [191
`Hoogenboom et a].
`
`llllllllllllllllllllllllllllllllllllllllll|l||l||l||lllllllllllllllllllllll
`5,517,250
`May 14, 1996
`
`US005517250A
`[11] Patent Number:
`[45] Date of Patent:
`
`[54] ACQUISITION OF DESIRED DATA FROM A
`PACKETIZED DATA STREAM AND
`SYNCHRONIZATION THERETO
`
`[75] Inventors: Chris Hoogenboom, Calabasas; Paul
`Moroney, Olivenhain, both of Calif.
`
`[73] Assignee: General Instrument Corporation of
`Delaware, Chicago, Ill.
`
`[21] Appl. No.: 392,421
`[22] Filed:
`Feb. 28, 1995
`
`[51] Int. Cl.6 ..................................................... .. H04N 7/12
`[52] U.S. Cl. ............ ..
`. 348/467; 348/466; 348/390
`[58] Field of Search
`.................... .. 348/390, 466,
`348/467, 461, 403, 423; H04N 7/ 12
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,111,292
`
`5/1992 Kuriacose ............................. .. 348/461
`
`5,159,452 10/1992 Kinoshita . . . . . .
`
`. . . .. 348/466
`
`348/461
`5,365,272 11/1994 Siracusa
`5,376,969 12/1994 Zdepski ................................. .. 348/466
`
`OTHER PUBLICATIONS
`
`Processor,”
`Decompression
`“MPEG-Z/DCH Video
`©Motorola Microprocessor and Memory Technologies
`Group, 1994, Document MC68VDP/D.
`
`Primary Examiner—-Victor R. Kostak
`Attorney, Agent, or Firm—Barry R. Lipsitz; Ralph F. Hoppin
`
`[57]
`
`ABSTRACT
`
`A video decompression processor acquires video data for a
`desired service from a packetized data stream. The data
`stream includes transport packets carrying different compo
`nents of the desired service. Each component is identi?ed by
`a unique packet identi?er (PID). One of the components
`includes a program clock reference (PCR) providing timing
`information for the desired service. The PIDs of the trans
`port packets are monitored to recover video packets. Header
`information from the recovered packets is processed to
`recover packetized elementary stream (PES) packets having
`a PBS header and picture infonnation. Time stamp infor
`mation obtained from the PES header is appended to the
`picture information for storage in a video memory. Picture
`information can subsequently be read from the memory and
`decoded using the appended time stamp information without
`having to reaccess the PES header. Various schemes for
`detecting, masking and recovering from transmission errors
`are disclosed.
`
`16 Claims, 3 Drawing Sheets
`
`I
`
`XPT : PAYLOAD A1
`HDR, ,
`82/
`
`l
`
`XPT : PAYLOAD A2
`HDR‘ ,
`82/
`
`l
`
`XPT : PAYLOAD A3
`HDR, ,
`82
`
`/72
`SE3 1
`
`1
`
`PES PAYLOAD
`
`74
`
`PICTURE i
`HDR
`E
`\1OO
`
`PICTURE DATA
`\1o2
`
`r102
`
`ID.
`PICTURE IT]
`HDR
`IS I
`'\
`104
`
`’
`‘I00
`
`PICTURE DATA
`
`TO DRAM
`
`LG Ex. 1009, pg 1
`
`

`
`U.S. Patent
`
`May 14, 1996
`
`Sheet 1 of 3
`
`5,517,250
`
`5&8
`
`89>
`
`an
`
`~_oBm>~_E<._8._<omopémzmomucosaFu_<:.Zmmm.._..=ommmm8<
`
`
`
`
`
`rEmm<n_ .x<.—z>m
`
`zo_B_B~Euzo_5_R._mn_omF.59..zocoz
`momma
`
`522;I'll
`oz<zoEms8<
`
`50%:55:I2IIE:
`89>onI.xfizam¢ommwwmwmwm
`
`
`
`Eon_mz<EA
`
`NMN_.
`
`.x._o
`
`_.:n_z_BE.
`
`Ejomzzoozo:<N:z<:oz<:.._..5:~m:._oEz8.mo<.._mm=z_
`
`
`
`
`
`05....Bemm~_m>z_»zu_oEmooNmum:IQ53
`
`mmaoomo.1
`
`LG Ex. 1009, pg 2
`
`LG Ex. 1009, pg 2
`
`
`
`

`
`U.S. Patent
`
`a
`
`%H
`
`ON.OE
`
`M.88
`
`mEH
`
`._KE
`
`¢n
`
`n_<o._><n_mun.
`
`n_<O._><n_mun.
`
` “.1.pm.9...2m3525m:m<_m<>V»\mmom.em.
`
`o.m_.._Eo<o._><n_"E9;Ex
`
`xw~\omo_n_.
`
`
`
`
`
`$823Hm<_m<>V55$mun.E
`
`5
`
`05297O.
`.9.’NO_u._
`
`
`
`5528.oa:<.
`
`oH._n__>.
`
`LG Ex. 1009, pg 3
`
`LG Ex. 1009, pg 3
`
`
`
`
`

`
`US. Patent
`
`May 14, 1996
`
`Sheet 3 of 3
`
`5,517,250
`
`W OI 3% E
`
`\/ \ /
`
`8; 0E
`
`__ - ‘I
`
`_ m_ mo:
`
`$3 $565 _
`
`81 A S) 02/
`
`53 $565 $565
`
`
`
`_ _ ~51
`
`u @205
`
`< i n. ma _
`
`a o < n ma
`
`
`
`_ ~51
`
`\ \ \
`
`$ 8\ $ 8\ E 8\
`2 2221 _ Ex N< Eoié " Ex 2 052E " Ex
`n #51 m _51 " ya:
`
`‘ _\ S
`
`LG Ex. 1009, pg 4
`
`

`
`5,517,250
`
`1
`ACQUISITION OF DESIRED DATA FROM A
`PACKETIZED DATA STREAM AND
`SYNCHRONIZATION THERETO
`
`BACKGROUND OF THE INVENTION
`
`2
`structed at a decoder by sending the difference between the
`corresponding block pairs, together with the motion vectors
`that are required to identify the corresponding pairs. Often,
`the amount of transmitted data is further reduced by com
`pressing both the displaced block differences and the motion
`vector signals. Block matching motion estimating algo
`rithms are particularly e?fective when combined with block
`based spatial compression techniques such as the discrete
`cosine transform (DCT).
`One way to transmit the compressed video data to a
`receiver is in the form of packets contained a pack
`etized data stream. Typically, the packets carrying the com
`pressed video data will be multiplexed with other packets,
`e.g., carrying corresponding audio data and control infor
`mation necessary to reconstruct a television signal. One
`standard for transporting digital television signals in this
`manner is the MPEG-2 standard, details of which can found
`in document AVC-49l, version 1, April, 1993 published by
`the Telecorrununications Standardization Sector, Study
`Group 15, Experts Group 4ATM-Video Coding of the Inter
`national Organization for Standardization, ISO-IEC/JTCl/
`SC29/WG11 entitled “Coded Representation of Picture and
`Audio Information,” incorporated herein by reference. Fur
`ther details of the video syntax and semantics for MPEG-2
`video can be found in International Organization for Stan
`dardization document ISO/IEC 13818-2 international stan
`dard, 1995, entitled “Generic Coding of Moving Pictures
`and Associated Audio Information: Video,” also incorpo
`rated herein by reference. Also of interest, and incorporated
`herein by reference, is document MC68VDP/D, a prelimi
`nary data sheet entitled “MPEG-2/DCH Video Decompres
`sion Processor,” ©Motorola Microprocessor and Memory
`Technologies Group, 1994 which describes a video decom
`pression processor using the MPEG-2 and DigiCipher®l1
`standards.
`In the MPEG-2 system (and the similar DigiCipher® II
`system proprietary to General Instrument Corporation, the
`assignee hereof) a transport stream, or transport multiplex is
`made up of a contiguous set of ?xed length packets. Each
`packet is 188 total bytes in length, with the ?rst four of those
`bytes being de?ned as the packet header. The payload
`portion of each packet is thus normally 184 bytes. However,
`a variable length adaptation ?eld may be provided to extend
`the header, when required. When an adaptation ?eld is
`present, the payload portion of the packet will be corre
`spondingly shorter.
`Various timing and identi?cation information is provided
`in different portions of the transport stream. These include a
`packet identi?er (PID) found in the transport header of each
`transport packet to provide a reference number for identi
`fying the transport packets carrying a speci?c service com
`ponent. This number is included in a service de?nition or
`“service map” used by the receiver to identify those trans
`port packets required to reconstruct a television program
`signal. The PID may also be referenced for various groom
`ing and remultiplexing functions. In the case of video, audio
`or isochronous data, the stream of packets labeled with a
`single PID represents a single video, audio or isochronous
`data service elementary stream, respectively.
`Timing information carried by the transport stream
`includes a program clock reference (PCR) which effectively
`represents a sample of the system time clock (STC) time
`base that underlies the service composed of the PIDs refer
`enced in the service map. The PID carrying the packet with
`the PCR is also referenced in the service map. The video,
`audio and isochronous data components of a service are
`locked through a de?ned relationship to the system time
`
`The present invention relates to a video decompression
`processor, and more particularly to an e?icient scheme for
`acquiring desired data, such as video data to be decoded,
`from a packetized data stream.
`Digital transmission of television signals can deliver
`video and audio services of much higher quality than analog
`techniques. Digital transmission schemes are particularly
`advantageous for signals that are broadcast via a cable
`television network or by satellite to cable television a?iliates
`and/or directly to home satellite television receivers. It is
`expected that digital television transmitter and receiver
`systems will replace existing analog systems just as digital
`compact discs have replaced analog phonograph records in
`the audio industry.
`A substantial amount of digital data must be transmitted
`in any digital television system. In a digital television
`system, a subscriber receives the digital data stream via a
`receiver/descrambler that provides video, audio and data to
`the subscriber. In order to most e?iciently use the available
`radio frequency spectrum, it is advantageous to compress
`the digital television signals to minimize the amount of data
`that must be transmitted.
`The video portion of a television signal comprises a
`sequence of video “frames” that together provide a moving
`picture. In digital television systems, each line of a video
`frame is de?ned by a sequence of digital data bits referred
`to as “pixels.” A large amount of data is required to de?ne
`each video frame of a television signal. For example, 7.4
`megabits of data is required to provide one video frame at
`NTSC (National Television System Committee) resolution.
`This assumes a 640 pixel by 480 line-display is used with
`eight bits of intensity value for each of the primary colors
`red, green and blue. At PAL (phase alternating line) resolu
`tion, 9.7 megabits of data is required to provide one video
`frame. In this instance, a 704 pixel by 576 line display is
`used with eight bits of intensity value for each of the primary
`colors red, green and blue. In order to manage this amount
`of information, the data must be compressed.
`Video compression techniques enable the e?icient trans
`mission of digital video signals over conventional commu
`nication channels. Such techniques use compression algo
`rithms that take advantage of the correlation among adjacent
`pixels in order to derive a more e?icient representation of the
`important information in a video signal. The most powerful
`compression systems not only take advantage of spatial
`correlation, but can also utilize similarities among adjacent
`frames to further compact the data. In such systems, differ
`ential encoding is usually used to transmit only the diifer
`ence between an actual frame and a prediction of the actual
`frame. The prediction is based on information derived from
`a previous frame of the same video sequence.
`Examples of video compression systems using motion
`compensation can be found in Krause, et al. US. Pat. Nos.
`5,057,916; 5,068,724; 5,091,782; 5,093,720; and 5,235,419.
`Generally, such motion compensation systems take advan
`tage of a block-matching motion estimation algorithm. In
`this case, a motion vector is determined for each block in a
`current frame of an image by identifying a block in a
`previous frame which most closely resembles the particular
`current block. The entire current frame can then be recon
`
`10
`
`15
`
`20
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`LG Ex. 1009, pg 5
`
`

`
`5,517,250
`
`3
`clock. The PCR serves to de?ne the transport rate, in the
`sense that between any two successive PCRs in one PID, the
`transport rate is constant and nominally equal to the system
`time clock rate times the ratio of the total number of
`transport bits between the PCRs divided by the difference in
`the PCRs in units of system time clock ticks.
`The timing information carried by the transport stream
`also includes time stamps for the commencement of decod
`ing and presentation of data for display. The presentation
`time stamp (PTS) is used for service component acquisition
`also for evaluating whether timing and buffer control are
`operating properly at the decoder. The decoder time stamp
`(DTS) is used to indicate when the decoder should start to
`decode the ?rst access unit (e.g., video frame) that starts
`somewhere in the payload of a packetized elementary stream
`(PES) packet whose header includes the DTS. A packetized
`elementary stream is a data stream composed of end-to-end
`PES packets which have variable length and are typically far
`longer than a ?xed length transport packet. Thus, a PBS
`packet is typically composed of data from a plurality of
`transport packets with a single PID.
`The DTS is required by a video decompression processor
`in order to properly time the commencement of video
`decoding. Since the DTS is packaged in a PBS header, it has
`been difficult and complicated for a video decompression
`processor at the receiver to obtain the DTS at the same time
`it is receiving the associated video data to be parsed. Prior
`to parsing, the video data is retrieved from a video memory
`that temporarily stores the data after having been retrieved
`from the transport stream. The video data will not be ready
`for decoding by the video decompression processor until
`sometime after the PES header containing the necessary
`DTS has been discarded.
`It would be advantageous to provide a method for pro
`viding the DTS to the video decompression processor when
`needed without any need to reaccess the PES header which
`originally carried the DTS and without carrying the rest of
`the PES header as overhead. It would be further advanta
`geous to provide a method for detecting a receipt of two time
`stamps without a full set of intervening video data to be
`decompressed, to enable the rapid recovery of the decoder in
`the event picture information is lost. It would be still further
`advantageous to provide a method for insuring that no data
`is lost when a memory map is initialized for storing the
`video data retrieved from the transport stream.
`It would also be advantageous to provide a method for
`detecting the occurrence of a missing picture header in
`picture data carried by the transport stream, and for recov
`ering from such missing information. Methods for selec
`tively decoding and displaying still images from a transport
`stream would also be advantageous. Also desirable would be
`the provision of methods for muting a video output of a
`processor if a new image is not irrunediately available, or for
`displaying a previous picture until a new image is available.
`The present invention provides methods for tracking and
`acquiring video data from a transport stream, and for detect
`ing, masking and recovering from errors in the acquired
`stream. The methods of the present invention enjoy the
`aforementioned and other advantages.
`
`55
`
`SUMMARY OF THE INVENTION
`
`In accordance with the present invention, a method is
`provided for acquiring video data for a desired service from
`a packetized data stream. The data stream includes transport
`packets carrying different components of the service, such as
`
`65
`
`10
`
`25
`
`35
`
`45
`
`50
`
`4
`a video component, audio component and control compo
`nent. The component carried by a particular transport packet
`is identi?ed by a packet identi?er (PID) for that component.
`One of the components includes a program clock reference
`(PCR) that provides timing information for the desired
`service. The method comprises the step of detecting the PCR
`for the desired service from the component carrying the PCR
`in the data stream. The recovered PCRs are used to acquire
`and track a decoder time clock that corresponds to the
`encoder timing. The PIDs of the transport packets are then
`monitored to recover those packets carrying a video com
`ponent of the desired service. Header information from the
`recovered transport packets is processed to recover pack—
`etized elementary stream (PES) packets having a PBS
`header and picture information. Time stamp information is
`obtained from the PES header of at least one of the PES
`packets. The time stamp information is buffered and then is
`appended to the related picture information for storage in a
`memory. In this manner, the picture information can be read
`from the memory and decoded using the time stamp infor
`mation appended thereto without having to reaccess the PES
`header for the time stamp information.
`The picture information will typically include a picture
`header at boundaries between successive video images to be
`decoded. The time stamp information obtained from the PES
`header can be inserted into the next picture header that
`follows the PES header in the packetized data stream. More
`speci?cally, the time stamp information can be inserted after
`a picture start code contained in the next picture header.
`Time stamp information can be provided for each suc
`cessive video image to be decoded. In this instance, the PES
`packets are monitored to detect any receipt of two PES
`headers having time stamps without an intervening picture
`start code, a condition that indicates an error has occurred.
`In the event that the receipt of two such PES headers without
`an intervening picture start code is detected, the second of
`the time stamps is inserted after the next picture start code
`while the ?rst of the two time stamps is ignored. A control
`bit is associated with (e.g., appended to) the second time
`stamp ?eld by the decoder to indicate to subsequent pro
`cessing sections that an error has occurred.
`In addition to the processing of time stamp information in
`an efficient manner, acquisition may require the recon?gu
`ration of memory. In an implementation where the picture
`information includes pixel data and a video sequence header
`that provides information as to how the pixel data is to be
`decoded, the memory which stores picture information
`can be recon?gured upon acquisition with a particular
`mapping in response to information from the sequence
`header. During the time that the memory is being recon?g
`ured, requests for access to data stored in the memory are
`denied in order to ensure that no data is lost during memory
`map initialization.
`The acquisition, selection and display of desired still
`pictures is also supported. More speci?cally, where the
`picture information includes picture headers at boundaries
`between successive video images, each picture header can
`include a reference number for the following video image.
`Speci?c video images can then be selected for decoding by
`referring to the reference number associated therewith. The
`selected image is then decoded and displayed as a still
`image, until another image with the same reference number
`is selected, received and displayed.
`The picture information carried by the transport stream
`can include a sequence end code indicative of the end of a
`video image to be decoded by a video processor for display.
`
`LG Ex. 1009, pg 6
`
`

`
`5,517,250
`
`5
`The sequence end code is detected, and a determination is
`made as to whether a subsequent video image is currently
`available for decoding and display following the sequence
`end code. If no such subsequent video image is available, a
`video output of the video processor is muted until a new
`video image is available. Alternatively, the output of the
`video processor can be provided with the last video image
`processed until a new video image is available.
`In order to recover from lost picture headers, the picture
`information received from the transport stream is monitored
`to detect the occurrence of a missing picture header. Upon
`such detection, the display of the most recently displayed
`full frame of picture information still contained in the
`memory is repeated until a new full frame of video data
`received after a subsequent picture header is available for
`display.
`Although not caused by an error, skipped pictures (i.e.,
`pictures which are skipped at the encoder) are handled in a
`similar manner. In order to recover from skipped pictures,
`the memory can be monitored to detect whether the data for
`a full video frame is present in the memory when the
`decoding of that frame is to commence. Upon detecting that
`the full video frame is not present, the display of the most
`recently displayed full frame of decoded picture information
`still contained in the memory is repeated.
`Recovery from stale time stamp information is also pro
`vided. In particular, once the decoding process is started in
`response to a valid DTS, the decoder continues to decode the
`incoming frames one at a time. Between DTS’s, the frames
`are decoded at times implied from the past decode times.
`When a new DTS is received, the time designated by that
`DTS is compared to the value of the decoder time clock at
`the decode time. If the time designated by the DTS precedes
`the value of the decoder time clock (i.e., the DTS time has
`already passed), it is assumed that synchronization has
`slipped and that the video decompression processor (V DP)
`is behind in the decoding process. Thus, the picture infor
`mation associated with that time stamp information is dis
`carded and the VDP will not decode that picture.
`
`25
`
`30
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram of a video decompression
`processor of the type that can utilize the methods of the
`present invention;
`FIGS. 2a to 20 are diagrammatic illustrations showing
`how variable length PES packets are reorganized into ?xed
`length transport packets for use in providing a transport
`multiplex for transmission; and
`FIG. 3 is a diagrammatic illustration showing how the
`received transport packets are processed at a decoder to
`recover picture information and time stamp information for
`storage in the dynamic random access memory (DRAM) of
`FIG. 1.
`
`45
`
`50
`
`55
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`FIG. 1 is a block diagram of a video decompression
`processor incorporating a memory manager 30 that
`addresses an external DRAM 22 to store and retrieve video
`data necessary to reconstruct a television program at a
`receiver. The processor, generally designated 20, is a pipe
`lined processor designed to decode both the transport layer
`(i.e., control and other non-video information) and the video
`layer of the compressed bitstream input via terminal 10,
`
`60
`
`65
`
`6
`sometimes referred to as the “transport packet interface” of
`the video processor.
`A user processor interface is provided at terminal 14 for
`control of the video data processor via an M-bus controller
`50 that con?gures various registers in processor 20. The
`M-bus is a two-wire, bidirectional serial bus which provides
`a simple and e?icient means of data exchange between
`devices, and is fully compatible with the 12C bus standard.
`An interface to the DRAM 22 is provided via address
`lines 24 and data lines 26. In the example illustrated in FIG.
`1, DRAM 22 has a nine bit address port and a thirty-two bit
`data port.
`A video output interface 38 is provided for the decom
`pressed, reconstructed video which may, for example, be
`output as a standard CCIR (International Radio Consultive
`Committee) 656, eight bit, twenty-seventy MHz multiplexed
`luminance (Y) and chrominance (Cr, Cb) signal.
`A test interface can be provided via terminal 62 to a
`conventional JTAG (Joint Test Action Group) controller 60.
`JTAG is a standardized boundary scan methodology used for
`board-level testing to detect faults in package and board
`connections, as well as internal circuitry.
`The video decompression processor 20 receives a clock
`signal via terminal 12. The clock provides timing informa
`tion that is used, e.g., to enable a transport syntax parser 32
`to recover timing information and video information from
`transport packets contained in a packetized data
`input
`via terminal 10. An acquisition and error management
`circuit 34 utilizes a program clock reference (PCR) and
`decode time stamp (DTS) detected by a video syntax parser
`40 to synchronize the start of picture decoding. This circuit
`sets vertical synchronization and provides global synchro
`nization for all video decode and display functions.
`The video layer is buffered in an input buffer (FIFO)
`con?gured in the external DRAM 22 by memory manager
`30. The video syntax parser 40 receivers the compressed
`video data output from the DRAM FIFO via memory
`manager 30, and separates the motion vector information
`from the coe?icients describing the video information. The
`coe?icients are processed by a Hulfman decoder 52, inverse
`quantizer 54, and inverse discrete cosine transform (IDCT)
`processor 56.
`Motion vectors are recovered and used to address previ
`ously decoded video frames required for reconstructing a
`current video frame. In particular, a motion vector decoder
`42 decodes the motion vectors received from video syntax
`parser 40 and passes them to a prediction address generator
`44. The prediction address generator provides address infor
`mation necessary to retrieve, via memory manager 30, the
`necessary anchor frame (i.e., intraframe (I) or prediction (P)
`frame) data to enable prediction calculator 46 to provide a
`prediction signal necessary to reconstruct a current frame
`block. Differential decoder 48 combines the prediction data
`with the decoded coe?icient data to provide decompressed
`video data. The decompressed data is stored in appropriate
`buffers of DRAM 22 via memory manager 30. It should be
`appreciated that the video decompression processes carried
`out by motion vector decoder 42, prediction address gen
`erator 44, prediction calculator 46, differential decoder 48,
`Huffman decoder 52, inverse quantizer 54 and IDCT 56 are
`generally conventional and well understood by those skilled
`in the art.
`Memory manager 30 schedules all activity on the external
`DRAM address and data buses 24, 26 and e?iciently
`addresses DRAM 22. The memory manager insures that the
`data transfer requirements of the input FIFO portion of
`
`LG Ex. 1009, pg 7
`
`

`
`5,517,250
`
`10
`
`25
`
`30
`
`7
`DRAM 22, the video syntax parser 40 and the video
`reconstruction circuit 36 (as well as prediction calculator 46
`and differential decoder 48) are all met. The video recon
`struction circuit 36 builds a current picture and inserts closed
`captions, a vertical interval test signal (VITS) and/or test
`pattern data for output on video output line 38. The decode
`process for a compressed frame of video data is synchro
`nized by comparing the time speci?ed by the decoder time
`clock to a decode time stamp (DTS), which indicates when
`the video frame is to be decoded. The display process for the
`decompressed frame is synchronized by comparing the time
`speci?ed by the decoder time clock to a presentation time
`stamp (PTS), which indicates when the video frame is to be
`presented for display.
`The memory manager also provides a variable size for the
`FIFO portion of DRAM 22 depending on the decoding
`mode, which can be, for example, NTSC or PAL with or
`without bidirectional prediction frames (B-frames). The
`video buffer control ensures that the FIFO provided by
`DRAM 22 does not over?ow or under?ow. Buffer control is
`a function of system timing parameters including the PCR
`and DTS.
`DRAM 22 is illustrated as an external memory and may
`be provided by a plurality of DRAM chips, such as two, four
`Mbit (megabit, i.e., 220 bits) DRAMs for an eight Mbit
`implementation or four, four Mbit DRAMs for a sixteen
`Mbit implementation. It should be appreciated that in future
`implementations, and as memory technology advances,
`DRAM 22 may be provided as internal memory within the
`video decompression processor. The DRAM is mapped to
`provide various decode and output video bu?ers as well as
`a circular FIFO buffer for the compressed input video
`bitstream. The DRAM may also be used to provide a test
`pattern buffer, a VITS buffer and a closed captioning display
`reordering buffer as well as to store various picture structure
`data necessary to properly display the decoded video frames.
`The DRAM can be reinitialized via memory manager 30 to
`provide different memory maps as required when variables
`are modi?ed such as PAL or NTSC video, eight or sixteen
`Mbit memory con?guration, and whether B-frames are
`present.
`As indicated above, the memory manager 30 schedules all
`of the activity on the external DRAM buses including the
`data transfer requirements of the input FIFO, the video
`parser and the video reconstruction circuit. The memory
`manager also performs the required DRAM refresh in a
`conventional manner. For example, the same row in each of
`two or four external DRAMs can be refreshed simulta
`neously.
`When a packetized bitstream containing compressed
`video data is input to terminal 10 of video decompression
`processor 20, video frames represented by the compressed
`data are reconstructed one at a time. Initially, a full frame of
`video data will have to be received and stored in DRAM 22.
`Information for subsequent video frames can comprise a
`subset of the full video frame which, when added to pre
`diction data from the prior video frame (stored in DRAM 22)
`will result in the reconstruction of a full frame.
`FIG. 2a illustrates a portion of a packetized elementary
`stream carrying successive PES packets, each having a
`header (PES-HDR) 72 and a PBS payload 74. The PES
`packets 70 are of variable length.
`PES packets are typically several thousand bytes in
`length. They are required to be aligned in such a manner that,
`when divided into transport packet payloads, the ?rst byte of
`every PES header is located in the ?rst payload position of
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`some transport packet. For any transport packet carrying the
`aligned PES header, a “payload unit start indicator” will be
`set in the transport header for the transport packet. In the
`MPEG-2 and DigiCipher® II systems, the PES format is
`used for all service components that are inherently synchro
`nous. More particularly, video, audio and isochronous data
`components are carried as packetized elementary streams,
`and the PES headers 72 will carry various information
`necessary to de?ne the payload, including a packet start code
`pre?x, a stream identi?cation, and a PBS packet length. The
`header may also contain a presentation time stamp (PTS) or
`both a PTS and a decode time stamp (DTS). When the
`header only carries a PTS, the DTS is inferred to be the same
`as the PTS. The PTS is a ?eld which indicates the value that
`corresponding bytes of the decoder system time clock ref
`erence should have when the ?rst presentation unit (i.e.,
`video frame, audio sync frame, isochronous data access unit)
`whose access unit starts
`in the payload of this
`PES packet is presented. For video, an access unit starts if
`the ?rst byte of the picture start code is present in the
`payload of the PES packet. For audio, an access unit starts
`if the ?rst byte of the audio sync word is present in the
`payload of this PES packet. For isochronous data, an access
`unit starts with the ?rst byte of the PES packet payload. The
`PTS ?eld is used for service component acquisition, and also
`for evaluating whether timing and buffer control are oper
`ating properly at the decoder.
`The DTS is a ?eld indicating what value corresponding
`bits of the reconstructed decoder time clock reference should
`have when the decoder starts to decode the ?rst access unit
`that starts somewhere in the payload of this PES packet. The
`PTS and DTS differ only for video, and only in the case of
`the I-frame and the P-frames transmitted with B-frames.
`The PES payload contains the information data that is
`desired to be transmitted to a receiver. Thus, for example, the
`payloads together include all of the video or audio informa
`tion necessary for the receiver to decode and reconstruct a
`digital television signal.
`In order to meet the requirements of robustness and
`simplicity, a ?xed packet length approach is preferred to the
`variable length PES packets. Thus, as illustrated in FIG. 2b,
`the packetized elementary stream containing the PES pack
`ets 70 is formatted into a stream of ?xed length transport
`packets 80. The transport packets illustrated in FIG. 2b all
`correspond to the same service component, such as the video
`component of a digital television transmission. In the
`MPEG-2 and DigiCipher® II embodiments, each packet is
`188 total bytes in length, with the ?rst four bytes comprising
`a transport packet header (XPT HDR) 82. The payload
`portion 84 of each packet 80 is thus normally 184 bytes.
`However, an adaptation ?eld mechanism is present, as
`illustrated by transport packet 80‘, to extend the header when
`required. The adaptation ?eld 86 provides additional infor
`mation which is not required for every transport packet. The
`adaptation ?eld (ADPT FIELD) 86 extends the regular
`transport header 82 at the expense of payload 84, which will
`be less than 184 bytes