HK1008289A - System and method for updating a system time constant (stc) counter following a discontinuity in an mpeg-2 transport data stream - Google Patents

Description

Digital video decoder for processing non-continuous program data

no marking

The present invention relates to data reception, processing and transmission according to data encoded in the MPEG-2 standard, and in particular to the operation and interface of a transport decoder for processing MPEG-2 formatted data streams.

High Definition Television (HDTV) continues to advance in an attempt to replace traditional television sets. Companies and associations are working to develop standards to supply the global market for HDTV to pave the way for this development.

One group of companies, also known as the digital high definition television alliance, includes AT & T, David Sarnoff research center, the institute of labor and technology, and others. Robert hopkins published a new reference in "consumer electronics IEEE trading in summer 1994" north american digital terrestrial high definition television: the grand alliance high definition television system "is a famous article that outlines the great strides of this group. The teaching of this article regarding background and basic knowledge of HDTV systems, including the use of programs and transport packet streams, is incorporated herein by reference.

The large consortium encodes video and audio information using the Motion Picture Experts Group (MPEG) 2 standard developed by the MPEG under the International Standards Organization (ISO). Accepted standards are regularly published in the following publications: general coding of moving pictures and related audio ISO/IEC 13818-2 (1995): the video part of the information engineering (hereinafter simply referred to as "video part"), the system part of the information engineering (hereinafter simply referred to as "system part") of the moving picture and related audio ISO/IEC 13818-1 (11 months 1994). Both teachings regarding established standards and formats are incorporated herein by reference.

The syntax of the MPEG-2 standard defines several data recording layers for transporting audio and video data. For example, to transmit information, a digital data stream representing a multi-video sequence is divided into a plurality of smaller units. Each unit is encapsulated into a plurality of Packetized Elementary Stream (PES) packets, respectively. For transmission, each packetized elementary stream packet is sequentially divided into a plurality of fixed-length transmission packets. Each transport packet contains data related to only one packetized elementary stream packet. The transport packet also includes a header with control information and sometimes adaptation field sub-segments for decoding the transport packet. However, the packetized elementary stream data may also include a plurality of elementary streams.

As described in the system section, synchronization between the various elementary streams is achieved by periodically providing time stamps in the data streams. For example, rather than adjusting the decoding of one stream to accommodate the decoding of another stream, the decoding of the N base streams is accomplished by correcting the decoding of the streams to a common master time base. The master time base may be the clock signal of one of the N decoders, or the time signal of the data source, or may be an externally supplied clock signal.

To facilitate this synchronization process, a discontinuity indicator bit is also included in the transport header of the MPEG-2 standard. The system part provides a syntactic representation to show the location of a typical "discontinuity indicator bit" in the transport header. This syntax is described in detail in table 1 below.

TABLE 1

Transport stream adaptation field syntax digit mnemonic code adaptation _ field () { adaptation _ field length 8 imsbf if (adaptation _ field _ length > 0) { discontinuity _ indicator 1 bslbf      random_access_indicator               1     bslbf　　        elementary_stream_priority_indicator  1     bslbf　　        PCR_flag                              1     bslbf　　        OPCR_flag                             1     bslbf　　        splicing_point_flag                   1     bslbf　　        transport_private_data_flag           1     bslbf　　        adaptation_field_extension_flag       1     bslbf　　        if(PCR_flag＝＝‘1’){　　           program_clock_reference_base       33    uimsbf<dp n="d2"/>　　   reserved                                          6     bslbf　　   program_clock_reference_extension                 9     uimsbf　　}　　if(OPCR_flag＝‘1’){　　   original_program_clock_reference_base             33    uimsbf　　   reserved                                          6     bslbf　　   original_program_clock_reference_extension        9     uimsbf　　}　　if(splicing_point_flag＝‘1’){　　   splice_countdown                                  8     tcimsbf　　}　　if(transport_private_data_flag＝‘1’){　　   transport_private_data_length                     8     uimsbf　　   for(i＝0；i＜transport_private_data_length；i++){　　                    private_data_byte                8     bslbf　　   }　　}　　if(adaptation_field_extension_flag＝‘1’){　　   adaptation_field_extension_length                 8     uimsbf　　   ltW_flag                                          1     bslbf　　   piecewise_ate_flag                                1     bslbf　　   seamless_splice_flag                              1     bslbf　　   reserved                                          5     bslbf　　   if(ltw_flag＝‘1’){　　                  ltw_valid_flag                     1     bslbf　　                  ltw_offset                         15    uimsbf　　      }　　   if(piecewise_rate_flag＝‘1’){　　                  reserved                           2     bslbf　　                  piecewise_rate                     22    uimsbf　　      }　　      if(seamless_splice_flag＝‘1’){　　                   splice_type                       4     bslbf　　                   DTS_next_au[32..30]               3     bslbf　　                   marker_bit                        1     bslbf　　                   DTS_next_au[29..15]               15    bslbf<dp n="d3"/>  　　                     marker_bit             1     bslbf　　                       DTS_next_au[14..0]     15    bslbf　　                       marker_bit             1     bslbf　　      }    　　      for(i＝0；i＜N；i++){　　                      reserved                8     bslbf　　      }　　}　　for(i＝0)；i＜N；i++){　　      stuffing_byte                           8     bslbf　　}      } }

As described in the system section, the discontinuity indicator is located in an adaptation field within the transport header. The discontinuity indication bit is a 1-bit field, and when set to a logical value of "1", it indicates that the discontinuity state of the current transport stream packet is true. The discontinuity state is false when the discontinuity indication bit is set to a logical value of "0" or absent. The discontinuity indicator bits are used to represent the following two discontinuity states: system time base discontinuity and continuity counter discontinuity.

Discontinuity in the system time base can be indicated by using a discontinuity indicator bit in the transport stream Program Identification (PID) designated as Program Clock Reference (PCR) Program identification (see 2.4.4.9 on page 50 of the system section). Next, a Program Clock Reference (PCR) value (i.e., the so-called master clock signal) may be received.

For example, when program material recorded using one time base is inserted into a data stream recorded using another time base, a discontinuity indication bit is set. The difference in time bases appears as an agnostic Program Clock Reference (PCR) value.

When the discontinuity status of a program-identified transport stream packet designated as a PCR program identifier is true, the next PCR in the same program-identified transport stream packet is used to represent the new system time clock sample for the associated program. The system time base discontinuity is defined as the time when the first byte of a packet of a PCR, which includes a new system time base, arrives at the input of the System Target Decoder (STD).

It is worth noting that: system target decoders are well known in the prior art and, in short, represent a hypothetical decoder conceptually coupled to the output of a transport encoder. The requirement is that the data stream conforming to the MPEG-2 standard does not cause data overflow problems (including buffer overflow) for the system target decoder. Additional discussion of the system target decoder is given in the system section.

Subsequently, the discontinuity indicator bit may also be set to "1" in the transport stream packets. These transport packets all belong to the previous program clock reference program identification of the packet containing the new system time base PCR. In this case, once the discontinuity indication bit is set to "1", it is set to "1" in all the transport stream packets identified by the same program PCR that identifies the transport stream packet that conforms to and includes the first PCR containing the new system time base. When a discontinuity in the system time base occurs, no less than two PCRs of the new system time base are received before another system time base discontinuity occurs. Further, unless the trick mode state is true, data from no more than two system time bases will appear in the system target decoder buffer of a program at any time.

When the timing discontinuity requires an update of the multisystem time constant (STC) values (i.e. in the clock manager of the transport decoder and in the external video and audio decoders), in particular when latency may exist between data being decoded by the external decoder and data being received and stored in the buffer of the transport decoder. In other words, it is typically the case that a transport decoder is coupled to external video and audio decoders, each of which holds an STC or equivalent value. Therefore, when the system time base changes, correcting all STC values at the same time may cause synchronization problems for the system.

In view of this, an important issue to be solved by the present invention is how effectively the transport decoder can handle the system time base discontinuity between the buffer and the decoder.

The present invention includes a system for receiving a transport stream comprising transport packets having a header with discontinuity indicator bits and active content. The system includes at least a buffer memory for temporarily storing the received transport stream and an outer decoder for decoding the data output from the buffer for display. The method is used for processing the reception of the discontinuity indication bit, and comprises the steps of carrying out syntax analysis on the head of the transmission packet after the discontinuity indication bit is received, and storing the effective content of the transmission packet into a memory. Upon receiving the next program counter reference value, a counter is loaded with the received program counter reference value. The stored data is then searched for a time stamp, which is retrieved once found. Finally, a timer interrupt is set at a point in time based on the retrieved time stamp, and when the timer interrupt occurs, the program counter reference value is sent to the decoder, while insufficient time is provided to the decoder for the new time stamp value to enable processing of data containing the new time base without interfering with the processing of data containing the previous time base.

Fig. 1A shows a high-level functional block diagram of a typical digital transport decoder and its various interfaces.

FIG. 1B depicts a high-level flow chart that describes steps taken by an aspect of the present invention when the embodiment depicted in FIG. 1A is employed.

Fig. 2A shows a high-level functional block diagram of a typical implementation of the transport decoder shown in fig. 1A.

Fig. 2B shows a high-level data/control flow diagram of a typical implementation of the transport decoder shown in fig. 1A.

Fig. 3 shows a functional block diagram of a memory controller used in the transport decoder shown in fig. 2.

FIG. 4 illustrates an exemplary flow chart describing how a memory controller handles pointer FIFO entries.

Fig. 5A shows an exemplary flow chart of the steps performed in the video decoder interface portion of the present invention.

Fig. 5B shows an exemplary flow chart of the steps performed at the audio decoder interface portion of the present invention.

SUMMARY

As described above, an important aspect of the present invention is to solve the problem of how efficiently a transport decoder processes discontinuity indicator bits. Another important aspect of the invention is the problem of handling the interface between the transport decoder and the video decoder which can only handle elementary stream data. In addition, a further aspect of the invention relates to the problem of the interface between the transport decoder and the bit-rate limiting audio decoder. For a complete description of the various aspects above, the present invention includes a specially designed MPEG-2 transport decoder.

If a program is broadcast using MPEG-2 format via satellite to multiple receiving stations nationwide, an instance of a time base discontinuity occurs. This is the particular environment provided for the introduction of the discontinuity portion of the present invention. However, during the program broadcast, each receiving station will add its own commercial. In this case a discontinuity bit should be set to indicate a blank or discontinuity in the program time base to facilitate the insertion of commercials that own local time base.

However, the transmission of the program from the satellite is not interrupted when the respective receiving station inserts the respective program. It can be seen that the internal timing of a transport decoder receiving a program with inserted advertising content from a local receiving station tracks the appropriate time base when a discontinuity indicator bit is encountered.

Turning to the drawings, FIG. 1A illustrates a high-level functional block diagram of a typical digital transport decoder 110 along with various interfaces. As shown in fig. 1A, transport decoder 110 includes connections to: a physical layer channel interface (also called a channel interface) 112, a buffer memory 114, a host microprocessor 116, external video and audio decoders 118 and 120, and a clock signal circuit (e.g., VCXO) 122. In an exemplary embodiment of the present invention, transport decoder 110 supports one video interface and up to two audio interfaces (e.g., audio interfaces a and B).

A host microprocessor 116, external to transport decoder 110, is also coupled to video and audio decoders 118 and 120 via micro-bus 24. Such connections may use parallel or serial data paths and vary according to the requirements of the single outer decoder selected for use. In any event, the method of connecting the host microprocessor 116 to the external decoder is well known and understood by those of ordinary skill in the art.

In general, the transport decoder 110 and each of the external video and audio decoders 118 and 120 include a System Time Constant (STC) value (not shown). This value is stored in a register or counter for synchronizing the decoding and display of the received data stream.

As described above, a problem may occur when a base discontinuity occurs in the data stream, and such discontinuity requires that the STC value be updated simultaneously in the transport decoder 110 and the video and audio decoders 118 and 120. A particularly problematic time is when latency may exist between data being decoded by the outer decoder and data being received and stored in transport processor 110.

In the present invention, the microprocessor 116 plays an important role in controlling the synchronization of the data streams and the operation of the video and audio decoders 118 and 120. In the present invention, microprocessor 116 has direct memory-mapped access to the various chip registers in transport decoder 110. The microprocessor 116 is also able to access buffers within the external memory 114 and an on-chip 32-bit read-write FIFO (as shown in FIG. 3) via read, write, and watermark fingers. The microprocessor 116 is coupled to a plurality of internal functional blocks via an internal micro-bus 223 (shown in FIG. 2B) to allow various events and error conditions to be signaled via the maskable interrupt.

In general, as shown in the flow diagram of FIG. 1B, one aspect of the present invention performs the following steps by the specially designed transport decoder 110 upon receiving the discontinuity indicator bits (step 150):

1) since the discontinuity indicator bit does not have to be in the same packet as the next program clock reference value (PCR), the next program clock reference value (PCR) will be loaded into a counter located within the clock management circuitry (as shown in fig. 2A) in transport decoder 110 (step 152) after the next program clock reference value is received;

3) searching for a timestamp in subsequent packets parsed and stored in memory, and once one is found, retrieving the timestamp value (step 154);

4) setting, by the microprocessor 116, a timer interrupt at a point in time that is less than one frame ahead of the retrieved timestamp value (step 156); and also

5) When a timer interrupt occurs, the current STC value is sent to the external video and audio decoders 118 and 120 (step 158), thereby giving the external decoders enough time to preempt the timestamp value in the data stream in comparison to the counter value stored in the video or audio decoder 118 or 120 to process the data.

The execution of these high-level steps will be described in detail below.

Fig. 2A and 2B illustrate high-level functional block diagrams of a typical implementation of the transport decoder 110 shown in fig. 1A. The overall data flow in transport decoder 110 is described below with reference to fig. 2A and 2B.

As shown, the channel interface 112 of FIG. 1A is coupled to a Channel Data Processor (CDP) 210. The channel interface 112 also provides data to the NRSS interface 212 for encryption with the NRSS smart card 230. Reference is made to the NRSS smart card in conjunction with the NRSS committee (4/95) discussion of conditional access EIA standard version 2.6.

The channel data processor 210 is provided for preprocessing (e.g., detecting, synchronizing, acknowledging, etc.) packets in the received data stream. After processing, the channel data processor 210 sends the output data to a Transport Processor (TPROC)214 for further processing. The transmission processor 214 performs various processes such as syntax analysis and the like according to a program identification table described in detail below.

Transport processor 214 interacts with a number of functional blocks in transport decoder 110. These functional blocks include: memory controller 216, clock manager 218, personal data processor 220, and high speed data port 222. As described above, the microprocessor 116 has direct access to a plurality of chip registers. This access is obtained through the micro-interface 217 and the internal micro-bus 223 (shown in FIG. 2B). The memory controller 216 is connected to the external memory 114 and the video and audio decoders (224, 226 and 228) in addition to the transport processor 214.

The details of the processing of the digital data stream in relation to the individual functional blocks will now be described. Channel Data Processor (CDP)210

It is worth noting that the data stream from the channel interface 112 is sent to the channel data processor 210 after possible buffering (not shown).

The channel data processor 210 performs various pre-processing steps on the received data stream. Specifically, the channel data processor 210 determines the boundaries of bytes and frames in the data stream and converts the received data stream into an 8-bit parallel format. In an exemplary embodiment of the present invention, operations performed in the transport decoder 110 after the channel data processor 210 are performed using a byte format.

To determine the boundaries of bytes and frames, the channel data processor 210 synchronizes with the frame pattern contained in the transport packet header. Specifically, this synchronization is accomplished by searching the transport stream sync byte (sync byte) (e.g., 47H) of MPEG-2 and acknowledging that it occurs at the beginning of a programmable number of consecutive transport packets.

During this process, the channel data processor (210) checks the sync byte, locks the data stream and continues to acknowledge the packet. When a Search for the synchronization bit is in progress, a Search status bit (Search State) (not shown) is set in the CDP status register. Once the Sync byte is found and acknowledgements of consecutive occurrences are in progress, the synchronization status bit (Sync State) is set. Finally, when a predetermined search criterion is met, a Lock status bit (Lock _ State) is set. In an exemplary embodiment of the present invention, the search criteria are three consecutive acknowledged packets. Also, a synchronization hysteresis value indicating the number of packets with corrupted synchronization bits is set. The channel data processor 210 is programmed to pass these synchronization bits before declaring a loss of lock condition. When this hysteresis value is exceeded, a loss of lock is declared. The channel data processor 210 then issues a loss of lock interrupt and transitions from the locked state back to the search state.

Alternatively, if the channel interface 112 (shown in FIG. 1A) provides a CHPSTRT signal, the transport decoder 110 may be configured to use this signal as a means to synchronize with the data stream by setting the frame Mode bit (Framing Mode) in the channel data processor frame and synchronization control registers to a logical value of "1". In this case, when the CHPSTRT is determined, synchronization can be obtained within one transmission packet time.

Alternatively, if the ignore sync bit in the channel data processor frame and sync control register is set to a logical value of "0," the channel data processor 210 checks the integrity of the sync bit at a predetermined byte (the first byte) relative to the CHPSTRT signal transition and declares a lock status when the check fails. If Ignore Sync (Ignore-Sync) is set to "1", the channel data processor 210 does not check the integrity of the Sync.

Having obtained the lock state, the output of the channel data processor 210 is transmitted to and processed by the transport processor 214, which processes (e.g., filters, parses, formats, etc.) the data in byte format. Transmit Processor (TPROC)214

The signals generated by transport processor 214 control the flow of data to: memory controller 216, micro-interface 217, clock manager 218, personal data processor 220, and high speed data port 220.

In an exemplary embodiment of the present invention, transport processor 214 processes the data stream under control of a program identification table. As described in the system part, a program identifier is a 13-bit field in the transport stream header that indicates the type of data stored in the packet payload. Some program identification values are assigned and others are reserved. Further details of the program identification table are given in section 3.3 of the system part of the MPEG-2 specification mentioned above.

Based on the program identification table, transport processor 214 can simultaneously process up to 32 user-selectable program identifications. The program identifiers processed by transport decoder 110 are specified in a program identifier table. Bit fields in the program identification table specify various data processing options.

During operation, the program identification is extracted by the transport processor 214 from the header of the just-arriving transport packet and compared simultaneously to all entries in the program identification table. Once a match occurs, the data in the packet is processed according to the options set in the matching program identification table entry. If the program identifies that the entries do not match, the packet is discarded.

Each address in the program identification table for which the valid portion format bit is not set to abort (000) is associated with a channel number. The memory controller 216 is coupled to the transport processor 214 and is responsible for transferring data to specific buffers (channels) in the RAM. The operational issues with the memory controller 216 are discussed in more detail below in connection with fig. 2, 3, and 4.

In an exemplary embodiment of the present invention, the program identification table stored in transport processor 214 is set by microprocessor 116 during initialization using software via micro-bus 223.

Regarding the format of the program identification entry, a program identification entry includes, among other information: 1) a 13-bit program identification, and 2) a 1-bit PCR program identification field. The latter, once set, indicates that for the program being decoded, the program identifier carries a PCR. A typical program identification entry also includes a 1-bit packetized elementary stream HDR bit that, once set, causes the RAM buffer address corresponding to the "stream id" in the packetized elementary stream header to be stored in the pointer FIFO. When the memory controller 216 writes data into the pointer FIFO, it issues an interrupt. This interrupt, also referred to as a DMA _ MARK signal, is used to alert the microprocessor 116 to send a Stream identification (streamID) byte. In an exemplary embodiment of the present invention, the program identification entry is assigned a channel number in numerical order based on the position in the table. For example, DMA channel 0 is assigned to the first entry, DMA channel 1 is assigned to the next entry, and so on.

Transport processor 214 indicates that transport packets with program clock reference program identification should be processed by clock manager 218 by placing the PCR _ PID signal in the program identification entry. The clock manager (218) monitors the adaptation field of the packet with the PCR _ flag and extracts the PCR.

The transport processor 214 separates the packets according to their program identifications, then removes the headers of the transport packets, and stores the valid portions of the program identification packets (e.g., portions of the packetized elementary stream packets) in the external memory 114 in association with the memory controller 216, respectively, in the sequentially arranged memory area fields of the designated channels. The data in the memory 114 represents packetized elementary stream packets.

The transport processor 214 also handles write operations from the host microprocessor 116 to external memory. Memory controller 216

The memory controller 216 stores the parsed valid portion of the transport packets in the external memory 114 and provides video, audio, PSI and other data (e.g., personal data) to the video processor 224, up to two audio processors 226 and 228, and the host microprocessor 116 or microcontroller as needed.

Fig. 3 shows an exemplary functional block diagram of a memory controller suitable for use in the transport decoder 110 shown in fig. 2A and 2B. As shown in fig. 3, the memory controller 216 obtains data from the transport processor 214 through the FIFO 310. The memory controller 216 retrieves and transfers data from the microprocessor 116 through a micro interface 217 comprised of a micro-input FIFO314 and a micro-output FIFO 316. It is worth noting that the micro-interface 217 external to the memory controller 216 of fig. 2A and 2B is also shown in fig. 3 to clearly illustrate its interrelationship with the FIFOs 314 and 316.

The memory controller 216 also includes a flow control unit 318 that includes chip memory, a DMA controller 320, data path (Datapath) logic 322, and logic for sending data to the video and audio decoders (224, 226, and 228), respectively.

The memory controller 216 writes data to the external memory from two sources: one is the transport processor 214 (via the transport port in the FIFO 310) and the other is the microprocessor 116 (via the micro-port in the FIFO 314).

The memory controller 216 reads data from the external memory and supplies it to the following four components: 1) video interface (via video FIFO324), 2) audio interface a (via FIFO326 for audio interface a), 3) audio interface B (via FIFO328 for audio interface B), 4) microcontroller 116 (via micro-output FIFO 316).

The external memory space is divided into a plurality of separate, non-overlapping buffers. Each for use by one DMA channel. As many as 32 channels can be used. The lane number is associated with writing data to two FIFO sources or reading data from four target FIFOs.

Data provided by transport processor 214 and written into port FIFO310 is marked with a lane number. The lane number of each of the other FIFOs is defined in the DMA interface registers by the microprocessor 116. The microprocessor 116 sets a 128-bit DMA channel configuration register (channel register) for each channel used. This channel register contains information such as the buffer space defined by the start and end addresses, whether the buffer is set as a FIFO (intertwined read and write pointers, sometimes called a circular Queue) or a Queue (Queue) (read and write pointers do not wrap together), etc.

If the channel register allows, DMA controller 320 can obtain a new buffer when the currently used buffer is full. This feature is typically only applicable to buffers, such as PSI section fields, that store data used by the host microprocessor 116. The start and end addresses of these new buffers are stored in the new buffer FIFOs. Only the microprocessor 116 can write a new buffer into this FIFO. Buffer pointers and other types of pointers that have been used are written into the pointer FIFO by the DMA controller 320. In an exemplary embodiment of the present invention, only the microprocessor 116 can read the pointer FIFO. These pointers are used by the microprocessor 116 to manage the reading of buffer data and to return used buffers to the new buffer FIFO. The pointer FIFO entry flow diagram in fig. 4 shows the entry of the pointer FIFO under all possible signal conditions, channel register settings and buffer conditions.

In the following FIG. 3, DMA controller 320 and data path 322 provide all interface signals for external memory. The flow control unit 318 services one of the six specific interface FIFOs by providing appropriate control signals to the DMA controller 320. These signals include:

1. DMA controller start signal:

the present signal instructs the DMA controller 320 to begin servicing a particular FIFO using commands such as DMA controller operations, DMA input FIFO selects, and DMA output FIFO selects. At the same time, the flow control unit 318 reads out the contents of the 128-bit specific channel register and makes it available on the data bus of the channel register (internal memory). The DMA controller 320 reads this 128-bit word into its internal registers and the flow control unit 318 is then freed to perform other read/write operations as required by the internal memory.

2. DMA controller operation signal (1 bit):

this bit signals a read or write, executed by the DMA controller on the interface FIFO.

3. DMA input FIFO select signal (1 bit):

signals the selection of one of the two input FIFOs (310 or 314) to be serviced.

4. DMA output FIFO select signal (2 bits):

signals a selection of one of the four output FIFOs (316, 324, 326 or 328) to be serviced.

5. Channel data stall in request/channel data/channel number/DMA controller:

in general, the DMA controller 320 continues to service the FIFO until service cannot be continued for reasons such as the interface FIFO being full or no data in the external memory. Once this occurs, DMA controller 320 assigns the requested channel data to flow control unit 318 and provides the channel register data and channel number data to flow control unit 318. Unless a particular FIFO requires a first aid action (e.g., because it is approaching a full or empty state), the flow control unit 318 updates the channel register memory with the channel data (e.g., the updated information includes read and write pointers, etc.) and instructs the DMA controller 320 to service the next FIFO in the loop.

Sometimes, the flow control unit 318 may need to send a DMA controller stall command to the DMA controller 320 in response to a need to service another FIFO. The FIFO may be an input FIFO with a higher priority. This command directs the DMA controller 320 to stop servicing the FIFO currently being serviced by it and to write the channel data to the flow control unit 318.

DMA controller 320 updates the channel registers with the following information: the read pointer, write pointer, and other information where DMA controller 320 stopped servicing the FIFO. Since the flow control unit 318 writes this information to the internal channel register memory, the DMA controller 320 can resume servicing the interrupted FIFO starting at the point of interruption.

Considering that the DMA controller is involved in the overall operation of the discontinuous status portion of the present invention, flow control unit 318 causes the DMA MARK signal to go high when the next PES packet including bytes of a stream identification is written to memory controller 216 by TPROC 214. The transition of the DMA MARK signal triggers an interrupt at the microprocessor 116 and the address of the packetized elementary stream packet header is stored in the input pointer FIFO which the microprocessor has access to. Since this packetized elementary stream header may have a time stamp, the microprocessor 116, which is responsive to the flag bit generated by the discontinuity indicator bit, searches for the time stamp in the stored packetized elementary stream header. Once found, this time stamp value is retrieved. The microprocessor 116 sets a timer interrupt based on the retrieved time stamp value.

Referring again to FIG. 3, in an exemplary embodiment of the present invention, the internal memory of the flow controller unit 318 includes four 64 x 32 bit blocks, each allocated to a channel register, a new buffer FIFO, and a pointer FIFO.

In an exemplary embodiment of the invention, each lane register has 128 bits and a maximum of 32 lanes. There are up to 128 x 32 bits allocated to the channel registers in a multiple 128-bit format.

A 32-bit word is written to or read from the new buffer and pointer FIFO. At least 128 x 32 bits of memory (i.e., 128 words) may be used in the new buffer and pointer FIFO. In addition, if fewer than 32 lanes are used, unused space in the lane registers is allocated to new buffers and pointer FIFOs.

The following is an example of memory allocation for 32 DMA channels and 16 DMA channels.

1) Memory allocation of 32 used channels

New buffer FIFO of 64 × 32 bits

Pointer FIFO is 64X 32 bit

Channel register 128 x 32 bit

2) Memory allocation of 16 used channels

New buffer FIFO of 64 × 32 bits

Pointer FIFO is 128 x 32 bits

128 x 16 bit clock manager 218 for channel registers

The clock manager 218 in the transport decoder 110 shown in fig. 2A and 2B synchronizes the local 27MHz signal (generated by the clock signal circuit 122) using consecutive PCR values. The counter value in the clock manager 218 is referred to as the System Time Constant (STC) value. In an exemplary embodiment of the present invention, the microprocessor 116 accesses the STC value in the counter via the internal micro-bus 223.

The counters in the clock manager 218 are periodically synchronized with the PCRs in the transport data stream. When the first PCR in the data stream is encountered, that PCR is "bumped" into the counter and becomes the initial STC value. When subsequent PCR values are received, they are compared to the STC value to correct the frequency of the clock signal circuit 122 (e.g., VCXO). In the present invention, this process is implemented using a digital-to-analog converter (DAC) as described in detail below. Once phase error correction is performed, a new PCR value is typically loaded as the STC value.

PCR values are typically generated once per frame. In the MPEG-2 standard, PCR values are generated at least once every three frames (approximately one tenth of a second).

Typically, the external video and audio decoders (118 and 120) remain synchronized with the transport decoder 110 by updating the STC value in the external decoder, which is implemented based on the STC value stored in the clock manager 218. The video and audio decoders (118 and 120) use the stored values to determine when to decode or display the data by comparing the data with time stamps in the received packetized elementary stream data stream. It is noted that in the exemplary embodiment of the present invention, transport decoder 110, video decoder 118, and audio decoder 120 all receive the same 27MHz clock signal generated by clock manager (218).

Transport decoder 218 includes hardware support for generating local clock signals. The signal is locked to the system clock signal for a selected program. As described above, the PCR values received on a particular PCR _ PID are available to other devices on the serial interface.

The Clock manager (218) includes a System Time Counter (STC) (not shown), a system time Clock register (not shown), a Program Clock Reference (PCR-Program Clock Reference) register (not shown), a current STC register (not shown), an alarm Clock interrupt register (not shown), and logic (not shown) to latch PCR values extracted from headers associated with selected Program Identifications (PIDs). It also includes a serial PCR interface and DAC registers for controlling the external system clock signal control loop.

In an exemplary embodiment of the invention, the STC is a 42-bit counter consisting of a 9-bit base and a 33-bit extension.

The STC base divides the nominal 27MHz system clock input signal into 300 parts. The resulting 90KHz signal drives STC expansion. At any time, the STC can be written to or read from by software running on the microprocessor 116. When a discontinuity indicator bit is encountered, the received PCR value may be automatically loaded into the STC.

As described above, the PCR can be automatically extracted from the just-arrived bit stream by setting the PCR _ PID bit in the program identification entry. Processing the received PCR depends on the options set by the software and whether a discontinuous state of the current transmitted packet exists when the PCR is received.

When a transport packet containing a PCR _ PID is received, and the discontinuity indication bit in the transport header is a logical value of 1, it can be confirmed that it is a discontinuous state. This discontinuity state will continue until the discontinuity indication bit is a logical value of 0 when a transport packet containing a PCR _ PID is received, or when the next PCR is found in a PCR _ PID packet.

If set to valid, the clock manager 218 automatically loads the received PCR into the STC when the PCR is received and a discontinuous state exists. At this point, an interrupt is sent to the host microprocessor 116.

The clock manager 218 includes an initialization bit. When this bit is set to 1 by the software, the next received PCR will be loaded into the STC, regardless of the presence or absence of discontinuity. The initialization bit is then automatically cleared by the clock manager 218. The initialization bit is set only when the STC does not contain a valid PCR (i.e., when a new program identification is selected).

If no discontinuity exists or the automatic STC load function is disabled, the received PCR is stored in the PCR register and an interrupt is optionally issued to the host microprocessor 116. The current state of the STC is saved in the STC register while the PCR is obtained. The stored PCR and STC values are used to calculate an error signal to control the clock signal (XOCLK) of the external system.

When the received transport packet includes a PID (program identification) equivalent to the PCR _ PID and a PCR, the PCR is latched in the PCR register. The current contents of the STC counter are also latched in the STC register at this time and an interrupt is issued to the host microprocessor 116. Latching both values eliminates the ambiguity that arises due to the varying latency in the interrupt service routine. In an exemplary embodiment of the invention, both registers include a 9-bit base and a 33-bit extension. The base is represented in binary in module 300, and the extension is represented in binary. The contents of the registers may be converted to binary numbers before they are used for any calculations. The conversion method is to multiply the extension by 300 and then add it to the base.

The current STC register is a read-only register that allows the microprocessor 116 to obtain the current contents of the STC at any time. The microprocessor 116 can use this value to initialize the STC of the video decoder or the audio decoder via the external micro-bus 124.

As described above, transport decoder 110 includes a 10-bit digital-to-analog converter (DAC)230, which is used in the clock correction control loop of clock manager 218. The DAC230 is read-only, that is, the software has a copy of the value that was last loaded into the DAC in memory. In operation, the DAC230 is used to generate a control voltage for the external resonant crystal voltage controlled oscillator VCXO 122. The latter is the source of the system clock frequency (nominally 27 MHz). By comparing the latched PCR and STC values, the software can determine whether the local clock signal needs to be corrected. For example, software can take the difference between the PCR and the STC and add this error condition to the current contents of the input register of the DAC 230.

In general, the discontinuities of the present invention include the following:

1) the Channel Data Processor (CDP)210 checks the sync byte in the received transport packet to validate the packet. The Transport Processor (TPROC)214 parses the transport header and passes the payload of the packet to the appropriate location in memory. The data is sent to different FIFO buffers (lanes) in memory according to the program identification value in the transfer header.

2) Because the received discontinuity indication bit does not have to be in the same packet as the next PCR value, the TPROC (214) will "push" the counter in the clock manager (218) when the next PCR value is received.

3) The DMA MARK signal goes high when the next packetized elementary stream packet including one stream identification byte is written by the transport processor 214 into the memory controller 216. This causes the memory controller 216 to issue an interrupt to the microprocessor 116 and store the address of the packetized elementary stream packet header in an input pointer FIFO. The packetized elementary stream header may have a time stamp (possibly a decoding time stamp or a presentation time stamp). The microprocessor 116, which is responsive to an interrupt from the memory controller 216, searches for the timestamp in the packed elementary stream header and, once found, retrieves the timestamp value.

4) The microprocessor 116 then sets a timer interrupt slightly less than one frame before the timestamp value.

5) When this timer interrupt occurs, the microprocessor 116 sends new PCR values to the video and audio decoders via the external micro-bus 124, giving the decoders sufficient time to process the data. This processing occurs before the time stamp is compared to the counter value in the video or audio decoder and does not interfere with the processing of the data referenced to the previous PCR value. Video/audio decoders 224, 226, 228

As described above, once the transport packets are received, processed and stored, the memory controller 216 reads the packetized elementary stream packets from the memory 114 and sends them to the external video and audio decoder. However, before the packetized elementary stream packets reach the outer decoders (118 and 120), they are processed by the inner video and audio processors (224, 226 and 228).

An important function of these internal processors is to ensure that the data stream leaving the transport decoder is compatible with the external decoder. That is, different outer decoders have different data requirements.

For example, some external video decoders currently available on the market can accept packetized elementary stream packets streams including a header and a valid portion. The form of these streams is mainly the same as when it was read out of the memory. On the other hand, some outer decoders can only accept processing requirements for elementary streams (e.g., valid portions of packetized elementary stream packets rather than header portions). In addition, the latter type of decoder requires, in addition to the data stream, associated control information such as time stamps and byte counts. CL9100 manufactured by C-Cube is such a video decoder. It is described herein with particular reference to its specification, the CL9100 multimode video decoder user manual (10 months 94). Thus, video processor 224 may be configured by microprocessor 116 to format the output data stream to be compatible with the requirements of the selected outer decoder.

In processing the interface of an external video decoder such as C-Cube CL9100, the video processor 224 processes the streams of the packetized elementary stream packet to remove the header of the packetized elementary stream and to take out the time stamp information from the packetized elementary stream header. In addition, the video processor 224 maintains a byte count for the packetized elementary stream packets sent to the outer decoder by using a counter (not shown). Then the video processor 224 contains the time stamp information, keeps the byte count and transmits the active part of the packetized elementary stream packets to the external video decoder. To obtain the timestamp and byte count information passed to the outer decoder, the video processor 224 issues an interrupt to the microprocessor 116. The latter, in response, reads the timestamp and byte count information from the video processor 224 via the internal micro-bus 223 and sends this control information to the external video decoder via the external micro-bus 124.

However, sometimes another packetized elementary stream header with time stamp information arrives before the microprocessor 116 can respond to an interrupt from the video processor 224. This may occur, for example, when the microprocessor 116 is occupied with a higher priority task for a long period of time. In this case, the video processor 224 stores the time stamp information along with the state. In particular, the video processor 224 may maintain a status register indicating whether the microprocessor "lost" the timestamp. In an exemplary embodiment of the invention, the microprocessor 116 will not begin reading the timestamp information until it loses one or more timestamps as represented in the state, and it will only be able to recover the most recent timestamp.

In addition, since the timestamp information and byte count information are to be provided to the outer decoder, when the microprocessor 116 loses a timestamp, the video processor 224 maintains an accumulated byte count because many data tags may arrive before the microprocessor 116 reads the information. The microprocessor 116 then reads the latest timestamp and accumulated byte count and sends this information to the external video decoder. Next, the status register and byte counter may be reset.

As shown in the flow diagram of FIG. 5A, the header of the received data is separated and parsed (step 510). The time stamp information is stored and the byte count is saved (step 510), and an interrupt is issued by the video processor 224 to the microprocessor 116 alerting it that the time stamp information is available for reading (step 514). If additional time stamp information is received before the microprocessor reads the previous time stamp information, the new time stamp information is stored, the byte counter continues to accumulate (step 516), the video processor 224 issues another interrupt to the microprocessor 116, otherwise, the microprocessor reads the status register, time stamp information, and byte count information and sends it to the external video decoder (step 518).

Another example of adjusting some outer decoder is to use a bit rate limited audio decoder, such as a Zoran ZR38500 AC3 audio decoder. The specification (10 months 1994) is hereby expressly incorporated by reference. Generally speaking, most audio decoders provide a request for data indicating that they can accept audio data, and transport decoder 110 then provides the audio data through the audio processor (226/228) until the external audio processor cancels the request. In other words, there is a handshake mechanism.

However, bit rate limiting decoders, such as the Zoran AC3 audio decoder, require that audio AC3 data be transmitted as frames of audio data, each frame including a frame time and bit rate in the header. Sending data at a bit rate higher than a predetermined bit rate may cause an internal buffer to overflow, resulting in data loss. Further, these bit-rate limiting decoders do not provide a data ready signal to indicate that they are ready to receive additional audio data.

Therefore, as with the video decoder 224, the audio processors 226 and 228 may be configured to adjust the selected external audio decoder. It is worth pointing out that: in an exemplary embodiment of the invention, the audio processor (226/228) is essentially identical except for addresses that are accessible to the microprocessor 116.

Thus, when audio processors (226/228) are programmed to interface with this type of audio decoder, they assume that the decoder is always sending data request signals. However, when the packetized elementary stream packet audio data is supplied from the memory controller 216 to the audio processor (226/228), the packetized elementary stream header of the received data is parsed by the audio processor. The frame size and bit rate of the audio data are contained in the analyzed header. Based on the frame size and bit rate, the audio processor (226/228) can determine the frame boundaries (i.e., frame time). With the frame time information, the audio processor (226/228) sets a frame timer so that when audio data is available, the timer is set and a frame of data is triggered into the external audio decoder and audio processor (226/228) and then pauses until the frame timer expires. When the timer expires, the loop continues, one audio frame at a time, and additional frames are available for delivery of additional frames to the external audio decoder. Control information, such as time stamps, are recovered by the microprocessor and sent out over the external micro-bus.

As shown in the flow chart of fig. 5B, the packetized elementary stream packets are restored from memory (step 542), the headers of the received data are removed and parsed (step 530), a frame time is determined (step 532), the timer starts (step 534), the audio processor (226/228) triggers a frame of data (step 536), the audio processor (226/228) pauses until the timer expires (step 538), although as shown in the figure, steps 542, 530 and 532 can be performed during the pause. Then, this process continues.

Although in the specific embodiments described above, a method and apparatus for updating a system time constant that tracks discontinuities in an MPEG-2 transport stream has been described. The invention is not intended to be limited to the details shown. In addition, many variations in detail may be effected without departing from the scope of the claims and the spirit of the invention.

Claims (7)

1. A method for use in a transport decoder system for decoding a transport stream comprising transport packets having a header portion and a payload portion, the header portion including discontinuity indicator bits, said system comprising at least one buffer for temporarily storing a received transport stream and at least one decoder for decoding a data output from the buffer for display, each of said transport decoder and decoder having a respective counter, the method for processing the reception of a Program Counter Reference (PCR) after a discontinuity state has been set, comprising the steps of:

carrying out syntax analysis on the received transmission packet, and storing data into a memory;

loading the received program counter reference value into the transport decoder counter upon receiving the next PCR value;

performing a data tag search on data received after the PCR value and stored in memory and retrieving the data tag value;

setting a timer interrupt based on the retrieved timestamp value; and transmitting the PCR value to a counter of the decoder when the timer interrupt occurs, thereby providing the decoder with sufficient time to process the data.

2. The method of claim 1, wherein the timer interrupt is set at a time less than one frame before the timestamp value.

3. The method of claim 1, wherein the step of searching comprises:

upon receipt of a transmission packet containing a timestamp value, interrupting a master microcontroller to issue master microcontroller address information associated with the stored transmission packet; and then searching for the timestamp value at the appropriate address location of the stored transport packet.

4. The method of claim 1, further comprising the steps of:

before parsing, the received transport packets are validated by determining whether their boundaries coincide with predetermined packet boundaries, and only the validated packets are parsed.

5. The method of claim 4, wherein validating the received transport packet comprises checking synchronization bits in the received transport packet.

6. In a system for receiving a transport stream including transport packets comprised of a header and a payload, the header including discontinuity indication bits, said system including at least one buffer for temporarily storing the received transport stream and at least one decoder for decoding data output from the buffer for display, an apparatus for handling the reception of discontinuity indication bits, each transport decoder and decoder having a separate counter, said apparatus comprising:

means for receiving and detecting discontinuity indicator bits;

means for parsing the transport packets and storing the data in a memory;

upon receiving the next program counter reference value, the received program counter is referenced

Means for loading values into a transport decoder counter;

means for searching the data stored in the memory for the time stamp and retrieving the time stamp value after discovery;

means for setting a timer interrupt based on the timestamp value; and means for sending a program counter reference value to the counter when a timer interrupt occurs.

7. In a transport decoder system for decoding a transport stream comprising transport packets comprised of a header and a payload, the header including discontinuity indicator bits, said transport decoder cooperating with at least one outer decoder to decode data output from the transport decoder, each of said transport decoder and outer decoder having a separate counter to maintain synchronization with the stream, a method of processing the reception of discontinuity indicator bits comprising the steps of:

receiving discontinuity indication bits;

parsing the transport packet and storing the data in a memory;

loading the received program counter reference value into a transport decoder counter upon receiving a next program counter reference value;

searching the data stored in the memory for the time stamp and retrieving the time stamp value after discovery;

setting a timer interrupt at a time approximately one frame before the timestamp value; and sending the program counter reference value to the counter of the decoder when the timer interrupt occurs, thereby providing the decoder with sufficient time for data processing.