HK1036172B - Video program bearing transport stream remultiplexer - Google Patents

Description

Transport stream remultiplexer with video program

Technical Field

The present invention belongs to a communication system. In particular, the invention pertains to selectively multiplexing bitstreams containing one or more programs, such as real-time audio-video programs. The program specific information and information about other programs are adjusted so that the programs can be identified, extracted and reproduced in real time at the receiving end of the bitstream.

Background

Recently, techniques have been proposed to efficiently compress audio-video programs for storage and transmission. See, for example, ISO \ IEC IS 13818-1, 2, 3: information technology-generic coding of moving pictures and related audio information: system, video and audio ("MPEG-2"); ISO \ IEC IS 11172-1, 2, 3: information technology-universal coding of moving pictures and related video for digital storage media up to about 1.5 megabits/second: system, video and audio ("MPEG-1"); dolby AC-3; motion JPEG, and the like. Here, the term program refers to a collection of related audio-video signals having a common time reference and intended for synchronous presentation, in accordance with the MPEG-2 parlance.

MPEG-1 and MPEG-2 are provided for layered streams. That is, an audio-video program is made up of one or more encoded bitstreams or "stream elements" (ES), such as an encoded video ES and an encoded audio ES, an audio ES encoded in a second language, a closed caption text (closed caption) ES, and so forth. Each ES, and in particular each audio and video ES, is encoded separately. The encoded ESs are then combined into a system layer stream such as a program stream "PS" or a transport stream "TS". The purpose of the PS or TS is to make it possible to extract encoded ESs from a program, separate and decode each ES separately, and present the encoded ESs synchronously. The TS or PS may be encapsulated in a higher channel layer or in a memory format provided for forward error correction.

Stream element

The audio ES is typically encoded at a constant bit rate of, for example, 384 kbps. On the other hand, video ES is encoded according to MPEG-1 or MPEG-2 at a variable bit rate. This means that the number of bits per compressed/encoded image varies from image to image (these images are presented or displayed at a constant rate). Video encoding comprises the step of encoding video images both spatially and temporally. Spatial coding includes discrete cosine transformation, quantization, (zig-zag) scanning, run-length coding and variable length coding blocks of luminance and chrominance pixel data. Temporal coding involves estimating the motion of a macroblock (e.g., a 4 x 4 array formed by a luminance block and each chrominance block overlaid thereon) to identify a motion vector, motion compensating the macroblock to form a prediction error macroblock, spatial coding the prediction error macroblock, and variable length coding the motion vector. Only some pictures, called I-pictures, are spatially coded, while other pictures, such as P and B pictures, are spatially and motion compensated coded (i.e. temporally predicted from other pictures). An encoded I picture typically has more bits than an encoded P picture, and an encoded P picture typically has more bits than an encoded B picture. In either case, even the same type of encoded image may have a different number of bits.

MPEG-2 defines the buffer size constraint for the encoded video ES. In particular, it is assumed that the buffer of the decoder has a predetermined maximum storage capacity. The encoded video ES must not overflow (and in some cases underflow) the decoder's buffer. To enable decoding of predicted pictures (from reference pictures that predict these), MPEG-2 specifically defines the constraints of time, picture display rate and some picture reordering for removing the compressed data of each picture from the decoder's buffer with respect to the bit rate of the video ES. Given these constraints, the number of bits generated when compressing an image may be adjusted (as often as the macroblocks are adjusted on a macroblock basis) to ensure that the video ES does not cause buffer underflow or overflow of the video ES encoder.

Transport stream

The invention is shown here in TS. For brevity, a discussion of the PS is omitted. However, those skilled in the art will appreciate the applicability of certain aspects of the present invention to PS.

The data of each ES forms a variable-length program stream element or "PES" packet. The PES packet contains data of a single ES, but may also contain data of more than one decoding unit (e.g., may contain more than one compressed picture, more than one compressed audio frame, etc.). In the case of TS, the PES packet is first divided into a number of payload (payload) units and inserted into fixed-length (188 bytes long) transport packets. Each transport packet may carry a single type of payload data, such as PES packet data of a single ES. Each TS is provided with a four byte header that includes a packet identifier or "PID". This PID is similar to a tag (tag) that uniquely indicates the content of the transport packet. Thus, one PID is assigned to a video ES of a specific program, another different PID is assigned to an audio ES of the specific program, and so on.

The ES for each program is encoded relative to the timing clock of the single encoder system. Likewise, the decoding and synchronized presentation of these ESs are synchronized in turn with respect to the same encoder system timing clock. Thus, the decoder must be able to recover the original encoder system timing clock in order to be able to decode and render each decoded ES in a time-and mutually synchronized manner. To this end, the timestamp of the system timing clock (called the program clock reference or "PCR") is inserted into the payload of the selected transport packet (specifically, in the adaptation field). The decoder extracts the PCR from the transport packet and uses the PCR to recover the encoder system timing clock. The PES packets may include decoding time stamps or "DTSs" and/or presentation time stamps or "PTSs". The DTS indicates the time at which the next decoding unit (i.e., compressed audio frame, compressed video image, etc.) should be decoded relative to the recovered encoder system timing clock. The PTS indicates a time at which the next presentation unit (i.e., decompressed audio frame, decompressed image, etc.) should be presented or displayed relative to the recovered encoder system timing clock.

Unlike PS, TS may have transport packets carrying program data for more than one program. Each program has been encoded at a different encoder relative to a different encoder system timing clock. The TS allows the decoder to recover a dedicated system timing clock for the program that the decoder wants to decode. To do this, the TS must carry a different set of PCRs, i.e., one set of PCRs therein, for recovering the encoder system timing clock of each program.

The TS also carries program specific information or (PSI) in the transport packets. The PSI is used to identify data intended for the program or other information that facilitates decoding of the program. There is provided a program association table or "PAT" which is carried in transport packets having a PID of 0x 0000. The PAT associates each program number with the PID of the program definition transport packet carrying the program. Program definition: (1) indicating which ESs make up the program to which the program definition corresponds, (2) identifying the PID of each of these ESs, (3) indicating the PID of the transport packets carrying the PCR of the program, (4) identifying the transport packets carrying the ES-specific naming control messages (e.g., descrambling or decryption keys) and other information. In general, all program definitions of a TS are called Program Map Table (PMT). Thus, the decoder can extract PAT data from the transport packets and use PAT to identify the PID of the transport packets carrying the program definition of the desired program. Then, the decoder may extract program definition data of a desired program from the transport packets, and identify the PID of the transport packet carrying the ES data constituting the desired program and the PID of the transport packet carrying the PCR. Then, using these identified PIDs, the decoder can extract ES data of an ES of a desired program and a PCR of the program from transport packets of the TS. The decoder recovers the encoder system timing clock from the PCR of the desired program and decodes and renders the ES data at a time relative to the recovered encoder system timing clock.

Other types of information optionally provided in the TS include name control messages (ECM), name management messages (EMM), conditional access (access) tables (CAT) and Network Information Tables (NIT) (CAT and NIT are also PSI-type). ECMs are ES-specific messages that are used to control the ability of a decoder to translate the ES to which the ECM belongs. For example, the ES may be scrambled and the descrambling key or control word may be an ECM. ECMs associated with a particular ES are placed in their own transport packets and are labeled with unique PIDs. EMMs, on the other hand, are system-wide messages that control the ability of a group of decoders (located in a system called a "conditional access system") to translate a portion of a TS. The EMMs are placed in their own transport packets and are labeled with PIDs unique to the conditional access system to which the EMMs belong. In order for a decoder to locate EMMs for a conditional access system of which the decoder is a part, i.e. a member of the group of decoders, a CAT is set whenever an EMM is present. The NIT stores various network parameters. For example, if multiple TSs are modulated on different carrier frequencies to which the decoder receiver can tune, the NIT may indicate at which carrier frequency (carrying the TS) each program is modulated.

Similar to video ES, MPEG-2 requires that the TS be decoded by a decoder having a TS buffer of a predetermined size to store program ES and PSI data. MPEG-2 also defines the rate at which data flows into and out of such buffers. Most importantly, MPEG-2 requires that the TS cannot overflow or underflow the TS buffer.

To further prevent buffer overflow or underflow, MPEG-2 requires that the data transmitted from the encoder to the decoder experience a constant end-to-end delay and maintain the proper program and ES bit rate. Furthermore, to ensure timely decoding and presentation of the ES, the relative arrival times of the PCRs in the TS should not change too much from the relative times indicated by such PCRs. In other words, each PCR indicates the time that the system timing clock (recovered at the decoder) should have when the last byte containing a part of the PCR was received. Thus, the time of receipt of the next PCR should be correlated to the time indicated by each PCR.

Remultiplexing

Usually, it is desirable to "sub-multiplex" the TSs. Remultiplexing involves selectively modifying the content of the TS, such as adding transport packets to the TS, deleting transport packets from the TS, rearranging the order of transport packets in the TS, and/or modifying the data contained in the transport packets. For example, it is sometimes desirable to add a transport packet containing a first program to a TS containing other programs. This operation involves more steps than simply adding transport packets for the first program. At a minimum, PSI, such as PAT and PMT, must be modified so that it can correctly reference (reference) the contents of the TS. However, the TS must be further modified to maintain the end-to-end delay of each program carried therein. In particular, the bit rate of each program may not be changed to prevent buffer underflow and overflow of the TS and video decoders. Furthermore, any temporal misalignment of the PC introducing the TS, which is a result of varying the relative reception interval/rate of successive transport packets with the PCR of the same procedure (bearing), must be removed.

The prior art has proposed a remultiplexer for MPEG-2 TS. The proposed remultiplexer is a complex piece of dedicated hardware that provides complete synchronization between the point of receiving each incoming TS to be multiplexed to the point of outputting the last remultiplexed output TS-a single system timing clock controls the reception, buffering, modification, transmission, reassembly and output of transport packets and synchronizes these operations. While such remultiplexers can remultiplexe TSs, the remultiplexer architecture is complex and requires a uniformly synchronized dedicated platform.

It is an object of the present invention to provide a flexible remultiplexing architecture, which may exist, for example, on any platform that may be asynchronous.

Program encoders that compress video and audio of a single program and generate a TS with the single program are well known. As mentioned above, MPEG-2 imposes a very strong constraint on the bit rate and the number of bits of a TS that can be present in the video decoder buffer at any time. It is difficult to encode ES, especially video ES, and to ensure that the bit rate remains fairly constant at all times. Furthermore, some overhead bandwidth must be allocated to each program to ensure that the ES data is not omitted because the ES encoder produces unexpected excess encoding information. On the other hand, occasionally, the program encoder does not output any encoded program data in a particular transmission packet slot. This may occur because the program encoder reduces the number of bits to be output at that time in order to prevent overflow of the decoder buffer. Alternatively, this may occur because the program encoder did not expect to take a long time to encode the ES and thus there is no data available at that instant. To maintain the bit rate of the TS and prevent underflow of the TS decoder buffer, empty transport packets are inserted into the transport packet slots.

The presence of empty transport packets in the TS to be sub-multiplexed is often a constraint that must be simply accepted. It is an object of the present invention to optimize the bandwidth of a TS containing null transport packets.

Sometimes, TS or ES data is transmitted via an asynchronous communication link. It is an object of the present invention to "retime" this untimed or asynchronously transferred data. It is a further object of the present invention to minimize jitter (jitter) of transport packets transmitted from asynchronous communication links by timing the transmission of the transport packets.

It is still another object of the present invention to allow a user to dynamically (i.e., in real time) change the remultiplexed content into a remultiplexed TS without stopping the flow of transport packets in the output remultiplexed TS.

It is another object of the present invention to distribute the remultiplexing function over a network. For example, it is an object to place one or more TS or ES sources at any node of a possibly asynchronous communication network (such as an ethernet LAN) and a remultiplexer at another node of such a network.

Disclosure of Invention

These and other objects are achieved in accordance with the present invention. One example application of the invention is the remultiplexing of one or more Transport Streams (TSs) compliant with MPEG-2. A TS is a bitstream containing data of one or more compressed/encoded audio-video programs. Each TS forms a sequence of fixed-length transport packets. Each compressed transmission includes data such as one or more compressed stream Elements (ES) of a digital video signal and/or a digital audio signal. The transport packets also carry the Program Clock References (PCRs) for each program, which are time stamps that enable the decoding and rendering of the respective programs to be synchronized to the encoder system timing clock. Each program has a predetermined bit rate and is to be decoded at a decoder having a predetermined size of a TS buffer and a predetermined decoder buffer. Each program is encoded in this way, preventing overflow and underflow of these buffers. Illustratively, Program Specific Information (PSI) that facilitates decoding of the TS is also carried in selected transport packets of the TS.

According to one embodiment, a remultiplexer node is provided with one or more adapters, each adapter including a cache memory, data link control circuitry coupled to the cache memory, and direct memory access circuitry coupled to the cache memory. An adapter is a synchronous interface with special characteristics. The data link control circuit has an input port for receiving a transport stream and an output port for transmitting the transport stream. The direct memory access circuit may be connected to an asynchronous communication link (such as a bus of a remultiplexer node) having a variable end-to-end communication delay. The direct memory access circuit may access the memory of the remultiplexer node using an asynchronous communication link. The memory may store queues of one or more descriptor storage units (storagelocations), such as one queue assigned to an input port and one queue assigned to an output port. The memory may also store transport packets in transport packet storage locations for which descriptors are stored in descriptor storage locations for each queue point. Illustratively, the remultiplexer node includes a processor coupled to the bus for processing transport packets and descriptors.

When a transport stream is input using an adapter, a data link control circuit assigns an unused descriptor in one of the sequences of descriptor storage units in the queues assigned to the input ports to each received transport packet to be retained. The allocated descriptors are located in a descriptor storage location from which the cache has gained control. The data link control circuit stores each reserved transport packet at a transport packet storage location from which the cache memory has gained control and which is pointed to by the assigned descriptor. The direct memory access circuit gains control of one or more unused descriptor storage locations (located after the last descriptor storage location from which the cache has gained control) of the queue in memory. The direct memory access circuitry also obtains control of the transport packet units in memory pointed to by the descriptors in the one or more descriptor storage locations.

When the adapter is used to output a transport packet, the data link control circuitry retrieves (retrieve) from the cache each descriptor in the sequence of descriptor storage locations assigned to the queue of the output port. The descriptors are retrieved in sequence from the beginning of the sequence. The data link control circuit also retrieves from the cache memory the transport packet stored in the transport packet storage unit pointed to by the retrieved descriptor. The data link control circuit outputs each of the retrieved transport packets at a unique time slot of the transport stream output from the output port (i.e., one transport packet per time slot). The direct memory access circuit obtains from memory a descriptor of a queue assigned to an output port of a memory location (located after the descriptor memory location in which the last cache descriptor of the sequence is stored) for storage in the cache memory. The direct memory access circuit also obtains each transport packet stored in the transport packet unit to which the obtained descriptor points.

According to another embodiment, each descriptor is also used to record a receive timestamp indicating when a transport packet was received at the input port, or a dispatch timestamp indicating the time that the initial packet will be sent from the output port. In the case where a transmission packet is received at an input port, the data link control circuit records a reception time stamp in a descriptor assigned to each received and reserved transmission packet to indicate the time at which the transmission packet is received. The descriptors are stored in the receive queue in the order received. In the case of outputting a transport packet from the output port, the data link control circuit sequentially retrieves each descriptor from the transmission queue and the transport packet to which each retrieved descriptor points. At a time corresponding to the dispatch time recorded in each retrieved descriptor, the data link control circuit transmits the retrieved transport packets pointed to by each retrieved descriptor in a time slot of the output transport stream corresponding to the dispatch time recorded in the retrieved descriptor.

Illustratively, the remultiplexer node processor examines each descriptor in the receive queue and other queues that contain descriptors pointing to the transport packets to be output. The processor allocates descriptors of the transmit queue associated with the output port from which the transport packet pointed to by each examined descriptor (if any) will be transmitted. The processor assigns dispatch times to the descriptors assigned to the transmit queues based on, for example, the time of receipt of the transport packet pointed to by the descriptor and the internal buffer delay between receipt and output of the transport packet. The processor also orders the descriptors of the send queue in ascending order of dispatch time.

Unique PCR normalization processing is also provided. The processor schedules each transport packet to be output at a certain time slot at a particular dispatch time corresponding to a predetermined delay in the remultiplexer node. If the scheduled transport packet contains a PCR, the PCR is adjusted according to the offset (drift), if any, of the local reference clock relative to the program of the system timing clock from which the PCR originated. The data link control circuit (which sends the transport packet with this adjusted PCR) further adjusts each adjusted PCR timestamp based on the difference between the scheduled dispatch time of the transport packet and the actual time that the slot occurred relative to the external clock.

Illustratively, if more than one transport packet is to be output in the same time slot, each such transport packet is output in separate consecutive time slots. The processor calculates an estimated adjustment for each PCR in a transport packet scheduled to be output at a different time slot than the time slot determined using the predetermined delay. The estimated adjustment is based on an output time difference between a time slot in which the processor actually schedules a transmission packet with a PCR to be output and a time slot determined by a predetermined delay. The processor adjusts the PCR based on this estimated adjustment.

According to one embodiment, the descriptor is also used to control scrambling or descrambling of the transport packet. In the case of descrambling, the processor defines a sequence of one or more processing steps to be performed on each transport packet and orders the descrambling processing within the sequence. The processor stores control word information related to the contents of the transport packet in the control word information storage unit of the assigned descriptor. The data link control circuit assigns descriptors to each received and retained transport packet, each such descriptor including one or more memory locations for processing indication and control word information. The data link control circuitry sets one or more processing indications of the assigned descriptors to indicate a next processing step of the sequence that can be performed on each assigned descriptor. A descrambler is provided that accesses each assigned descriptor in turn. If the processing instruction of the accessed descriptor is set to indicate that the accessed descriptor (and the transport packet pointed to by the accessed descriptor) can be descrambled, the descrambler processes the descriptor and the transport packet pointed to by the descriptor. Specifically, if the descriptor points to a transport packet to be descrambled, the descrambler descrambles the transport packet using control word information in the accessed descriptor.

The descrambler may be located on the (receiving) adapter, in which case the processing of the descrambler occurs after processing by the data link control circuitry (e.g., descriptor assignment, receive time recording, etc.), but before processing by the direct memory access circuitry (e.g., transfer to memory). Alternatively, the descrambler may be a separate device connected to the asynchronous communication interface, in which case the processing of the descrambler occurs after the processing of the direct memory access circuit but before the processing of the processor (e.g., estimated time-of-departure calculation, PID remapping, etc.). In either case, the control word information is the base address of the PID indexable control word table maintained by the processor.

In the case of scrambling, the processor defines a sequence of one or more processing steps to be performed on each transport packet and orders the scrambling process within the sequence. The processor assigns a transmission descriptor of the transmission queue to each transmission packet to be transmitted, and stores control word information related to the transmission packet in a control word information storage unit of a selected descriptor among the assigned descriptors. The processor then sets one or more processing indications of the descriptors to indicate the next processing step in the sequence that can be performed on each assigned descriptor. A scrambler is provided that accesses each assigned descriptor in turn. The scrambler processes each accessed descriptor and the accessed transport packet pointed to by the descriptor, but this process is only performed when the processing indication of the accessed descriptor is set to indicate that the accessed descriptor (and the accessed transport packet pointed to by the descriptor) can be scrambled. Specifically, if the accessed descriptor points to the transport packet to be scrambled, the scrambler scrambles the transport packet pointed to by the accessed descriptor using the control word information in the accessed descriptor.

The scrambler may be located on the (transmit) adapter, in which case the processing of the scrambler occurs after processing by the direct memory access circuitry (e.g., transfer from memory to cache, etc.), but before processing by the data link control circuitry (e.g., output in the correct time slot, last PCR correction, etc.). Alternatively, the scrambler may be a separate device connected to the asynchronous communication interface, in which case the processing of the descrambler occurs after the processing of the processor (e.g., transmit queue descriptor allocation, dispatch time assignment, PCR correction, etc.), but before the processing of the direct memory access circuitry. As with descrambling, the control word information may be the base address of a PID indexable control word table maintained by the processor. However, the control word information is preferably the control word itself used to scramble the transport packet.

Further, in accordance with one embodiment, a method is provided for retiming a video program with data received via an asynchronous communication link. An asynchronous communication interface (e.g., an ethernet interface, ATM interface, etc.) is connected to the remultiplexer node processor (e.g., via a bus) to receive the bitstream with the video program from the communication link with varying end-to-end transmission delays. The processor determines, from a plurality of timestamps of a program carried in a received bitstream, a time at which each of one or more received packets carrying data of the same program of the received bitstream should appear in an output TS. A synchronization interface, such as a transmit adapter, selectively transmits selected transport packets carrying received data in an outgoing TS (with constant end-to-end delay) at times dependent on the determined times.

Illustratively, the remultiplexer node memory stores packets containing data received from a bitstream received in a receive queue. The processor identifies each packet containing data for a program stored in the receive queue between first and second particular packets containing successive time stamps for the program. The processor determines the (transport) packet rate for the process based on the difference between the first and second timestamps. The processor assigns to each identified packet the sum of the transmission time assigned to the first particular packet and the product of the (transmission) packet rate and the deviation of the identified packet from the first packet as the transmission time.

According to another embodiment, a method is provided for dynamically and seamlessly changing the remultiplexing in accordance with changing user specifications. An interface, such as a first adapter, selectively extracts only certain transport packets from the TS in accordance with an initial user specification of the remultiplexed TS content. A second interface, such as a second adapter, reassembles selected ones of the extracted transport packets and transport packets containing the PSI, if any, into an output remultiplexed TS in accordance with an initial user specification of the contents of the remultiplexed TS. Further, the second adapter outputs the reassembled remultiplexed TS as a continuous bit stream. The processor dynamically receives one or more new user designations of the remultiplexed TS content that designate one or more of the following: (I) different transport packets to be extracted and/or (II) different transport packets to be reassembled, while the first and second adapters extract the transport packets for reassembly and output the remultiplexed TS. In response thereto, the processor causes the first and second adapters to dynamically cease extracting or reassembling transport packets in accordance with the initial user designation and to dynamically begin extracting or reassembling transport packets in accordance with the new user designation without introducing discontinuities in the output remultiplexed transport stream. For example, the processor may generate an alternate PSI referencing a different transport packet for reassembly by the second adapter, per new user specifications.

Illustratively, this seamless remultiplexing change technique may be used to automatically ensure that the correct ES information for each selected program is always output at the remultiplexed TS, despite any changes that may be possible in the ESs that make up the program. A controller may be provided that generates a user specification indicating one or more programs of the input TS to be output in the output TS. The first adapter continuously captures-the program definition of the input TS. The processor makes successive determinations from the captured program definitions (these stream elements make up each program). The second adaptor outputs transport packets each containing ES data of each ES determined to constitute each program specified by the user to be output, in the output TS without introducing discontinuity in the output TS. Thus, even if the PIDs of the ESs constituting each program change (number or value), correct complete ES data for each program is always output in the output TS.

According to still another embodiment, there is provided a method of optimizing a port of a TS into which a null transport packet is inserted. The first interface (adapter) receives a TS at a predetermined bit rate, which includes transport packets with variable compression program data and one or more null transport packets. When a transport packet with compressed program data inserted in a TS received at each transport packet slot is not available, each empty transport packet is inserted in one slot of the received TS. The processor replaces one or more null transport packets with other transport packets with data to be re-multiplexed. Transport packets with such replacement data may contain PSI data or even burst (burst) transaction (transactional) data that has no bit rate or transmit latency requirements for presenting information in a continuous manner.

Illustratively, the processor extracts selected ones of the transport packets from the received TS and discards each of the unselected transport packets (including each of the null transport packets). The selected transport packet is stored in memory by the processor and the first adapter. As described above, the processor schedules each stored transport packet to be output in the output transport stream at a time that is based on the time at which each stored transport packet was received. The second interface (adapter) outputs each stored transport packet in a time slot corresponding to this schedule. The second adapter outputs a null transport packet if there is no transport packet to be scheduled for output at one of the time slots of the output TS. However, empty transport packets occupy less bandwidth in the outgoing TS than each incoming TS.

In accordance with additional embodiments, a method is provided for timely outputting a bitstream with compressed program data over an asynchronous communication link. The synchronization interface (adapter) provides a bit stream containing transport packets. The processor assigns a dispatch time to each of one or more selected transport packets to maintain a predetermined bit stream of a program (each of which carries data for the program) and to cause an average latency for each selected transport packet. At times based on each dispatch time, the asynchronous communication interface receives one or more commands and responds by sending corresponding selected transport packets at times approximating the dispatch times, thereby minimizing jitter of the selected transport packets.

Illustratively, the command is generated as follows. The processor queues the send descriptor including the above dispatch time as a send queue. The processor assigns the adapter of the remultiplexer node to service the transmit queue on behalf of the asynchronous interface. When the dispatch time of the descriptor equals the time of the reference clock at the adapter, the data link control circuitry of the assigned adapter causes each command to be issued.

Various ones of these techniques may be used to enable network distributed remultiplexing. The network is provided with one or more communication links and a plurality of nodes interconnected by the communication links into a communication network. The destination node receives a first bit stream containing data for one or more programs via one of the communication links, portions of the first bit stream having one or more predetermined bit rates. The destination node may be a remultiplexer node as described above, which in any case comprises a processor. The processor selects at least a portion of the received first bit stream for transmission and schedules transmission of a selected portion of the first bit stream to output the selected portion of the first bit stream in the TS at a rate dependent on the predetermined rate of the selected portion of the first bit stream.

Alternatively, the communication links collectively form a shared communication medium. The nodes are partitioned into a first set of one or more nodes for transmitting one or more bit streams onto the shared communication medium and a second set of one or more nodes for receiving bit streams transmitted from the shared communication medium. The second group of nodes selects portions of the transmitted bit stream and transmits one or more remultiplexed TSs as the bit stream containing the selected portions. Each transmitted remultiplexed TS is different from the received bit stream in the transmitted bit stream. It is arranged to select the first and second groups of nodes and to cause the selected nodes to transmit the bit stream via the shared communication medium in accordance with one of a plurality of different signal stream patterns including at least one signal stream pattern different from the topological connection of the nodes to the shared communication medium.

Finally, a method of synchronizing a reference clock at each of a plurality of circuits that receive or transmit transport packets in a remultiplexer system is also provided. The reference clock at each circuit receiving a transmitted packet indicates the time at which each transmitted packet was received. The reference clock at each circuit from which the transport packets are sent indicates when each transport packet is sent from there. A master reference clock for synchronizing the reference clocks with each other is specified. The current time of the master reference clock is periodically obtained. The reference clocks are mutually adjusted according to the difference between the respective times at the other reference clocks and the current time of the main reference clock, so that the times of the respective reference clocks match the corresponding times of the main reference clock.

Thus, according to the present invention, a more flexible remultiplexing system is provided. This increased flexibility enhances the remultiplexing and also reduces the overall system cost.

Brief description of the drawings

FIG. 1 illustrates a remultiplexing environment in accordance with one embodiment of the present invention.

Fig. 2 illustrates a remultiplexer node that uses an asynchronous platform in accordance with one embodiment of the present invention.

Fig. 3 shows a flow diagram schematically illustrating how transport packets are processed according to their PIDs in a remultiplexing node according to one embodiment of the present invention.

Fig. 4 illustrates a network distributed remultiplexer in accordance with one embodiment of the present invention.

Preferred embodiments of the invention

The description of the invention has been divided into sections for clarity.

Remultiplexer environment and overview

Fig. 1 illustrates a basic remultiplexing environment 10 in accordance with one embodiment of the present invention. Controller 20 provides instructions to remultiplexer 30 using, for example, any Remote Procedure Call (RPC) protocol. Examples of RPCs that may be used include the digital distributed computing environment protocol (DEC) and the open network computing protocol (ONC). DEC and ONC are network protocols that utilize protocol stacks that enable a client process (client process) to execute subroutines located on the same platform (e.g., controller 20) or another remote platform (e.g., in remultiplexer 30). In other words, the client process can issue control instructions through simple subroutine calls. The DCE or ONC process issues appropriate signals and commands to the remultiplexer 30 to effect the desired control.

The controller 20 may be in the form of a computer such as a PC compatible computer. The controller 20 includes a bus 24 such as one or more Intels^TM Pentium II^TMA processor 21 such as an integrated circuit, a main memory 23, a disk memory 25, a monitor and keyboard/mouse 27, and one or more I/O devices 29. I/O device 29 is any suitable I/O device 29 in communication with remultiplexer 30 depending on how remultiplexer 30 is implemented. Examples of such I/O devices 29 include RS-422 interfaces, Ethernet interfaces, modems, and USB interfaces.

Remultiplexer 30 is implemented as one or more network-connected "black boxes". In the example remultiplexer architecture described below, the black boxes of remultiplexer 30 may be individual PC-compatible computers interconnected by communication links such as ethernet, ATM, or DS3 communication links. For example, remultiplexer 30 includes one or more black boxes, each of which is a stand-alone PC compatible computer interconnected by an Ethernet network (10BASE-T, 100BASE-T, or 1000BASE-T, etc.).

As shown, one or more TSs to be remultiplexed, TS1, TS2, and TS3, are received at remultiplexer 30. As a result of the remultiplexing operation by remultiplexer 30, one or more TSs, i.e., TS4 and TS5, are output from remultiplexer 30. The remultiplexed TSs (exemplary TS4 and TS5) include at least some information (at least one transport packet) from the input TSs (TS1, TS2, and TS 3). At least one storage device 40, such as a disk storage or server, is also provided. The memory device 40 may generate a TS of information to be remultiplexed or data as an input to be remultiplexed into an output TS (TS4 or TS5) via the remultiplexer 30. Likewise, memory device 40 may store TS information or data generated by remultiplexer 30, such as transport packets extracted or copied from an incoming TS (TS1, TS2, or TS3), other information received at remultiplexer 30, or information generated by remultiplexer 30.

Also shown are one or more data injection sources 50 and one or more data extraction destinations 60. These sources 50 and destinations 60 may themselves be implemented as PC compatible computers. However, the source 50 may also be a device such as a video camera, video tape player, communication demodulator/receiver, etc., and the destination 60 may be a display receiver, video tape recorder, communication modulator/transmitter, etc. The data injection source 50 provides the TS, ES or other data to the remultiplexer 30 for remultiplexing them into the output TS, TS4 and/or TS5, for example. Likewise, data extraction destination 60 receives TS, ES, or other data from remultiplexer 30, such as extracted from input TS (TS1, TS2, and/or TS 3). For example, a data injection source 50 for generating each of the input TS to be remultiplexed (TS1, TS2, and TS3) may be provided, and a data extraction destination 60 for receiving each of the output remultiplexed TS (TS4 and TS5) may be provided.

Environment 10 may be considered a network. In this case, each "black box of the network" of controller 20, each data injection source 50, storage device 40, data extraction destination 60, and remultiplexer 30 in environment 10 may be considered a node of the communication network. Each node may be connected by synchronous or asynchronous communication links. Furthermore, the separation of devices 20, 40, 50, and 60 from remultiplexer 30 is for convenience only. In another embodiment, devices 20, 40, 50, and 60 are part of a remultiplexer 30.

Remultiplexer architecture

Fig. 2 shows the basic architecture of one of the network black boxes or nodes 100 of the remultiplexer 30 (hereinafter "remultiplexer node" 100). The particular remultiplexer node 100 shown in fig. 2 may be used as the entire remultiplexer 30. Alternatively, as will be apparent from the following discussion, the different parts of the remultiplexer node 100 may be distributed among separate nodes that are interconnected by synchronous or asynchronous communication links. In yet another embodiment, a plurality of remultiplexer nodes 100 having the same architecture as shown in fig. 2 are interconnected to one another via synchronous or asynchronous communication links, and may be programmed to act in concert. The latter two embodiments are referred to herein as network distributed remultiplexers.

Illustratively, remultiplexer node 100 is Windows NT^TMCompatible PC computer platforms. Remultiplexer node 100 includes one or more adapters 110. Each adapter 110 is coupled to a bus 130, which is illustratively a PCI compatible bus. Main memory 120 is also coupled to bus 130. Such as Intel^TMPentium II^TMA processor such as an integrated circuit is also coupled to bus 130. It should be noted that the single bus architecture shown in FIG. 2 may be a simplified representation of a more complex multi-bus architecture. Further, there may be more than one processor 160, which is described belowCooperate with each other in processing functions.

Illustratively, two interfaces 140 and 150 are provided. These two interfaces 140 and 150 are coupled to bus 130, although in fact they could also be coupled directly to an I/O expansion bus (not shown), which in turn is coupled to bus 130 via an I/O bridge (not shown). Illustratively, the interface 140 is an asynchronous interface such as an Ethernet interface. This means that there is no guarantee that the data sent via the interface 140 occurs exactly at any time, which may experience variable end-to-end delays. Interface 150, on the other hand, is an asynchronous interface such as a T1 interface. Such that communications over the communication link to interface 150 are synchronized with the clock signal maintained at interface 150. Data is sent via the interface 150 at a particular time, which data experiences a constant end-to-end delay.

Fig. 2 also shows that the remultiplexer node 100 may have an optional scrambler/descrambler (which may be implemented as an encryptor/decryptor) 170 and/or a Global Positioning Satellite (GPS) receiver 180. The scrambler/descrambler 170 is used to scramble or descramble data in the transport packets. GPS receiver 180 is used to receive a universal clock signal to synchronize the remultiplexer node 100. The purpose and operation of these devices are described in more detail below.

Each adapter 110 is a specialized type of synchronous interface. Each adapter 110 has one or more data link control circuits 112, a reference clock generator 113, one or more descriptor and transport packet caches 114, an optional scrambler/descrambler 115, and one or more DMA control circuits 116. These circuits may be part of one or more processors. Preferably, they are implemented using finite state automata, i.e., in one or more ASICs or gate arrays (PGAs, FPGAs, etc.). The purpose of each of these circuits will be described below.

Illustratively, the reference clock generator 113 is a 32-bit rollover counter that counts at 27 MHz. The system time generated by the reference clock generator 113 may be received at the data link control circuit 112. Further, the processor 160 may directly access the reference clock generator 113 as follows. Processor 160 may read the current system time from the I/O register of reference clock generator 113. Processor 160 may load a particular value into the same I/O register of reference clock generator 113. Finally, the processor 160 may set the count frequency of the reference clock generator in the adjustment register so that the reference clock generator 113 counts at a frequency within a particular range.

The purpose of the cache memory 114 is to temporarily store the next one or more pending outgoing transport packets from the adapter 110 to be output or the last one or more transport packets recently received at the adapter 110. The use of cache memory 114 allows transport packets to be received and stored or retrieved and output with minimal latency, most notably no transfer latency occurs across bus 130. The cache memory 114 also stores descriptor data for each transport packet. The purpose and structure of these descriptors are described in more detail below. In addition, cache 114 stores a filter map (filter map) that may be downloaded and modified by processor 160 under normal operation. Illustratively, the cache memory 114 may also store control word information for scrambling or descrambling as described in more detail below. In addition to the processor 160, the cache memory 114 is accessed by the data link control circuit 112, the DMA control circuit 116, and the optional scrambler/descrambler 115.

As is well known, cache memory 114 may hold an all-true or modified copy of the data in main memory 120. Also, cache memory 114 should obtain a modified copy of any data in main memory rather than the old copy it owns, if desired. As is main memory 120. An "ownership protocol" is utilized such that only a single device (such as cache memory 114 or main memory 120) has permission to modify the contents of a data storage unit at any one time. Here, cache 114 is said to gain control of the data storage units when the cache has exclusive control over modifying the contents of these storage units. In general, the cache memory 114 takes control of the location and the truthful duplicate copy of the data stored therein, modifies its copy, but defers writing the modification of the data to the main memory until a later time. This means that when the cache memory writes data to a memory location in main memory, the cache memory 114 relinquishes control of the main memory 120.

The DMA control circuit 116 is used to transfer packet data and descriptors between the main memory 120 and the cache memory 114. The DMA control circuit 116 may store a sufficient number of transport packets (and their descriptors) in the cache memory 114 to cause the data link control circuit 12 to output transport packets in the output TS sequentially (i.e., in sequential time slots). The DMA control circuit 116 may also gain control over a sufficient number of descriptor storage locations in the cache 114 and the packet storage locations it points to. The DMA control circuit 116 gains control over these descriptors and the transport packet storage location of the cache memory 114. This allows incoming transport packets to be successively assigned to the descriptor and transport packet storage unit as they are received (i.e., from successive time slots).

The data link control circuit 112 is used to receive transport packets from incoming TSs or to send transport packets on outgoing TSs. Upon receipt of the transport packets, the data link control circuitry 112 filters out and retains only selected transport packets received from the incoming TS that are specified in the downloadable filter map (provided by the processor 160). Data link control circuitry 112 discards each other transport packet. The data link control circuit 112 assigns the next unused descriptor to the received transport packet and stores the received transport packet in the cache memory 114 for transfer to the transport packet storage location pointed to by the assigned descriptor. Further, the data link control circuit 112 obtains a reference time corresponding to the reception time of the transmission packet from the reference clock generator 113. The data link control circuit 112 records this time as a reception time stamp in a descriptor pointing to a transmission packet storage unit in which the transmission packet is stored.

When sending a packet, the data link control circuit 112 retrieves the descriptors of the outgoing transport packets from the cache memory 114 and sends the corresponding transport packets in the time slots of the outgoing TS that occur when the reference clock generator 113 is approximately equal to the dispatch time indicated in each descriptor. In addition, the data link control circuitry 112 makes any final PCR corrections in the outgoing transport packets as necessary so that the PCRs indicated in the transport packets are synchronized with the exact alignment of the transport packets in the outgoing TS.

Processor 160 is configured to receive control instructions from external controller 20 (fig. 1) and send commands to adapter 110 and interfaces 140 and 150 to control them. In response, processor 160 generates a PID filter map and downloads it to cache memory 114 for these instructions, or modifies a PID filter already present in cache memory 114 for use by data link control circuitry 112 in selectively retrieving the desired transport packets. In addition, processor 160 generates an interrupt receive handler for processing each received transport packet (according to its PID). The receive interrupt handler may cause the processor 160 to remap the PID of the transport packet, estimate the departure time of the transport packet, extract the information in the transport packet for further processing, and so forth. In addition, processor 160 formulates and executes a send interrupt routine that causes the processor to appropriately sequence transport packets for output, generate a departure time for each transport packet, coarsely correct PCRs in the transport packets, and insert PSI into the outgoing TS. Processor 160 may also facilitate scrambling and descrambling as described in more detail below.

The main memory 120 is used for storing transport packets and descriptors associated therewith. The memory cells of main memory 120 are organized as follows. A buffer 122 is provided that contains a plurality of reusable transport packet storage locations that serve as a pool of transport packets. The descriptor storage unit 129 is organized into a plurality of rings 124. Each ring 124 is a sequence of descriptor storage locations 129, from a starting memory address or top 124-1 of the ring to an ending memory address or bottom 124-2 of the ring. One ring 124 is provided for each outgoing TS sent from the remultiplexer node 100 and one ring 124 is provided for each incoming TS received at the remultiplexer node 100. Other rings 124 may be provided as described in more detail below.

A queue is implemented in each ring 124 by assigning a pointer 124-3 to the head of the queue or to the first used/allocated descriptor storage location 129 in the queue and a pointer 124-4 to the tail of the queue or to the last used/allocated descriptor storage location 129 in the queue. The descriptor storage location 129 is assigned to incoming transport packets starting with the unused/unassigned descriptor storage location 129 immediately after the tail 124-4. The descriptor store 129 for the outgoing transport packet is retrieved starting from the descriptor store 129 pointed to by the head 124-3 and proceeding sequentially into the queue at the tail 124-4. Each time the descriptor of descriptor store 129 at the end of ring 124-2 is reached, the descriptor continues to be allocated or retrieved from descriptor store 129 with the descriptor of descriptor store 129 at the top of ring 124-1.

As shown, each descriptor stored in each descriptor storage location 129 includes a number of fields 129-1, 129-2, 129-3, 129-4, 129-5, 129-6, 129-7, 129-8, 129-9, and 129-10. In short, the purpose of each of these fields is as follows. Field 129-1 is used to store command attributes. The bits of the command attribute field may be used by the processor 160 to control transport packet transmission and descriptor data retrieval by the adapter 110. For example, processor 160 may preset a bit in field 129-1 of the descriptor in descriptor store 129 pointed to by the bottom 124-2 of ring 124 to indicate that the descriptor store 129 pointed to by top pointer 124-1 is subsequent to the descriptor store 129 pointed to by bottom pointer 124-2.

Field 129-2 is used to store software status bits. These bits are neither accessible to nor modifiable by adapter 110, and may be used by processor 160 for any purpose not related to adapter 110.

The field 129-3 is used to store the number of bytes of the outgoing transport packet to be output (typically 188 bytes for MPEG-2 transport packets, but the number of bytes can be set to a greater or lesser number when the descriptor points to the packet in accordance with different transport protocols or "centralized" and "decentralized" support (dividing the packet into multiple memory cell slices or assembling from slices stored in multiple packet memory cells).

The field 129-4 is used to store a pointer to the location of the transport packet corresponding to the descriptor. This is illustrated in fig. 2 by an arrow from the descriptor in descriptor storage location 129 of ring 124 to the designated storage location of transport packet pool 122.

Field 129-5 is used to store the time of reception of a received incoming transport packet or to store the time of dispatch of an outgoing transport packet to be sent.

The field 129-6 is used to store various exceptions/errors that may occur. The bits of this field may be used to indicate errors of bus 130, data link errors on the communication link to which data link control circuit 112 is connected, receipt of short or long packets (less than or in excess of 188 bytes), and so on.

The field 129-7 is used to store status bits indicating different status aspects of the descriptor, such as whether the descriptor is valid, invalid to point to an error packet, etc. For example, assume that multiple devices must process the descriptor and/or the packet it points to in succession. In this case, preferably four status bits are provided. The first two bits may be set to values 0, 1, 2, or 3. A value of 0 indicates that the descriptor is invalid. A value of 1 indicates that the descriptor is valid and can be processed by the last device that must process the descriptor and/or the packet it points to. A value of 2 indicates that the descriptor is valid and can be processed by the next to last device that must process the descriptor and/or the packet it points to. A value of 3 indicates that the descriptor is valid and can be processed by the third last device, which must process the descriptor and/or the packet it points to. The last two bits indicate whether a descriptor has been fetched from main memory 120 into cache memory 114 and whether processing of the descriptor has been completed at adapter 10 and stored in main memory 120. Other status bits may be set as described in more detail below.

Field 129-8 contains a transfer count indicating the number of bytes of the received incoming transport packet.

The field 129-9 is used to store a scrambling/descrambling control word or other information for scrambling or descrambling. For example, processor 160 may store a control word (encryption/decryption key) or the base address of a table of control words stored in cache 114 in this field 129-9.

The field 129-10 is used to store a scheduled estimated departure time, an actual departure time, or an actual reception time. As described in more detail below, processor 160 uses this field to order received incoming transport packets to output or record the time of receipt of the incoming transport packets.

Illustratively, in order to receive a transmission packet at a single input, a data link control circuit 112, a DMA control circuit 116, and a ring 124 are required, and in order to transmit a transmission packet from a single output, a data link control circuit 112, a DMA control circuit 116, and a ring 124 are required. The descriptors stored in the queue associated with the input are called receive descriptors and the descriptors stored in the queue associated with the output are called transmit descriptors. The above-mentioned inputs and outputs may be inputs or outputs of a communication link to which the data link control circuit 112 is connected or inputs or outputs of a communication link of another interface 140 or 150 in the remultiplexer node 100, as described below. Adapter 110 is shown as having only a single data link control circuit 112 and a single DMA control circuit 116. This is for illustration only-multiple data link control circuits 112 and DMA control circuits 116 may be provided on the same adapter 110. Alternatively, or in addition, a plurality of adapters 110 may be provided in the remultiplexer node 100.

Basic transport packet reception, remultiplexing and transmission

Consider now the operation of remultiplexer node 100. The operator is provided with a number of options on how to operate the remultiplexer node 100. In a first mode of operation of the remultiplexer node 100, it is assumed that an operator wishes to selectively combine the program information of two TSs (i.e., TS1 and TS2) into a third TS, TS 3. In this case, it is assumed that the operator does not initially know what programs, ES or PID, are contained in the two TSs (TS1 and TS2) to be remultiplexed. Further, illustratively, the TS1 is received at the first adapter 110, the TS2 is received at the second adapter 110, and the TS3 is sent from a third adapter 110 of the same remultiplexer node 100. As will be appreciated from the description below, each of TS1 and TS2 may instead be received via a synchronous or asynchronous interface at the same node or at a different node, and selected portions of TS1 and TS2 may be communicated to a third node via a network of any architecture to be selectively combined at the third node to form TS 3.

The operation according to this manner can be summarized as (1) acquiring content information (programs, ES, PAT, PMT, CAT, NIT, etc. and PID thereof) of the input TS (TS1 and TS2) to be sub-multiplexed; (2) reporting the content information to an operator so that the operator can formulate a user specification; and (3) receiving a user specification for constructing the output remultiplexed TS (TS3) and dynamically constructing the remultiplexed TS (TS3) from the content of the input TSs (TS1 and TS2) in accordance with the user specification.

To enable the retrieval of content information, the transport processor 160 assigns a receive queue to each of the first and second adapters 110 that receive the TS (TS1 and TS2), respectively. To obtain the content of the TSs (TS1 and TS2), transport packets are not initially dropped at the adapter 110 of TS1 or TS 2. Thus, the processor 160 loads a filter map into the cache memory 114 of each of the first and second adapters 110 receiving TSs (TS1 and TS2) so that each transport packet may be retained and transferred to the main memory 120. As each transport packet of a TS (e.g., TS1) is received at a respective adapter 110, the data link control circuitry 112 assigns the next unused descriptor (following the descriptor in the descriptor storage location stored at the tail 124-4 of the receive queue) to the received incoming transport packet. The data link control circuit 112 stores each received transport packet in a transport packet storage location in the cache memory 114 to which the assigned descriptor points.

The DMA control circuit 116 writes each transfer packet to a corresponding memory location of the pool 122 in the main memory 120 and writes descriptor data of descriptors assigned to the transfer packets to descriptor memory locations of the receive queue. In addition, DMA control circuit 116 may gain control of the next several unassigned descriptor storage locations 129 in the receive queue (following the storage location of the descriptor 129 sequence that DMA control circuit 116 has previously gained control), the copies of the descriptors stored therein, and the transport packet storage locations to which those descriptors point. Control of these unused, unassigned descriptors and transport packet storage locations is provided to the cache memory 114 for use by the data link control circuit 112 (i.e., for assignment to future received transport packets from the TS 1).

After the DMA control circuit 116 writes i ≧ 1 transfer packet and the data assigned to their descriptors to the pool 122 and the receive queue, the DMA control circuit 116 generates an interrupt. Illustratively, an operator may use the controller 20 to select the number i and set it via the processor 160. The interrupt causes the processor 160 to execute the appropriate receive "PID" processor subroutine (handlersubroutine) for each received transport packet. Alternatively, another technique, such as polling or timer-based procedures, may be used to initiate the execution of the receive PID processor subroutine by the processor 160 for each received transport packet. For clarity, the invention is illustrated herein using the interrupt example. Referring to fig. 3, the processor 160 illustratively has a set of PID processor subroutines for each adapter 110 (or other device) that receives or transmits TSs during a remultiplex session (session). FIG. 3 shows two types of sets of PID processor subroutines, namely a receiving PID processor subroutine set and a transmitting PID processor subroutine set. Each DMA control circuit 116 generates a distinct interrupt that is recognizable to cause the processor 160 to determine which set of PID processor subroutines to use. In response to the interrupt of the DMA control circuit 116, the processor 160 executes step S2, according to which the processor 160 checks the PID of each transport packet pointed to by the descriptor stored most recently in the receive queue of the interrupt adapter 110. For each PID, the processor 160 consults a pointer table of the receiving PID processor subroutine 402 that is specific to the adapter 110 (or other device) of the interrupt handler 160.

Assume that the first adapter 110 receiving the TS1 interrupts the processor 160, in which case the processor 160 determines to consult a pointer table of the receiving PID processor subroutine 402 dedicated to the adapter 110 receiving the TS (TS 1). The pointer table of the receiving PID processor subroutine consists of 8192 entries, including one indexed (index) by each permissible PID (these PIDs have 13 bits according to MPEG-2). Each indexed entry contains a pointer or address RIV0, RIV1, …, RIV8191 of a subroutine to be executed by processor 160. Using the PID for each transport packet, processor 160 may index an entry in the pointer table of the receiving PID processor subroutine 402 to identify the pointer of the subroutine to be performed for that particular transport packet.

Each subroutine pointed to by the pointers and executed by processor 160 is specifically mapped to each PID using pointer table 402 to achieve the user specifications. Advantageously, each subroutine is predetermined by the pointer table 402 and mapped simply according to user specifications. Each subroutine consists of a set of one or more basic building block processes. Some examples of basic building block processing include:

(1) PAT acquisition: initially, this processing is contained in the received PID processor subroutine for PID 0x0000, the subroutine pointed to by RIV 0. In performing this processing, the processor 160 extracts a PAT portion (section) carried in the transport packet currently being processed, and loads this PAT portion into a PAT held in the memory, for example. Note that multiple versions of PAT may be used, as the programs carried in the TS may change over time. The processor 160 can identify the different versions of the PAT and separately aggregate and maintain in the main memory 120 a copy of each version of the PAT. The processor 160 can identify which version of the PAT is currently being used at any time based on information contained in the various PAT portions. The processor 160 also uses the information carried in each updated PAT portion to identify the program number of the program carried in the TS at that time and the PID or program definition of the PMT portion of such program number. Using these program numbers, the processor 160 may modify the pointer table 402 of the receiving PID processor subroutine to insert the pointers of the appropriate PIDs (tag the transport packets with PMT portions) to execute the subroutine containing the processing for obtaining PMT portions/program definitions.

(2) PMT part/program definition acquisition: in this process, the processor 160 extracts a PMT portion or program definition included in the transport packet currently processed, and updates each portion of the PMT with the extracted program definition or PMT portion data. As with the PAT, multiple versions of the PMT may be utilized, and the processor 160 may determine in which PMT to store the extracted PMT portion or program definition data. The processor 160 may use the PMT information to update the PID filter map (used to discard transport packets of programs not contained in the remultiplexed TS), identify the control words used to descramble the ESs and select subroutines for processing the PCRs contained in the transport packets (with the PIDs identified in the PMT).

(3) PID remapping: this causes the processor 160 to overwrite the PID of the corresponding packet with a different PID. This is required to ensure uniqueness of PID assignments. That is, if transport packets carrying different contents (e.g., data of different ESs, data of different PSI streams, etc.) are to be remultiplexed into (and carried by) a remultiplexed TS of the same output, MPEG-2 requires that these transport packets carrying different contents be labeled with PIDs different from each other. Otherwise, the decoder or other device cannot distinguish the transport packets carrying different types of data for extraction, decoding, etc. It is possible to label transport packets with a first type of data in TS1 using a certain PID and transport packets with a second type of data in TS2 using the same PID. If the first and second types of transport packets are to be included in the output remultiplexed TS (TS3), at least one of the two types of transport packets should be re-labeled with a new PID to ensure uniqueness.

(4) And (3) discarding the transmission packet: as the name implies, processor 160 simply discards these transport packets. To do so, the processor 160 de-allocates descriptors pointing to dropped transport packets. De-allocation of descriptors may be accomplished by the processor 160 adjusting the order of descriptors present in the queue's descriptor storage location 129 to remove descriptors of the deleted transport packet (e.g., the processor identifies all allocated descriptors following the descriptor of the transport packet to be deleted in the ring 124 and moves each to the descriptor storage space of the immediately preceding descriptor). The de-allocation of descriptors creates descriptor storage space 129 in the receive queue for re-allocation.

(5) PCR flag (flag) setting: the PMT indicates the PID of the transport packet carrying the PCR for each program. However, only some of these transport packets carry PCRs. This may be determined simply by the processor 160 determining whether the appropriate indication (adaptation _ field _ control bit in the transport packet header and PCR _ flag bit in the adaptation field) is set in the transport packet. If processor 160 determines that a PCR exists, processor 160 sets a PCR flag bit in attribute field 129-1 of descriptor 129 for each packet. The purpose of this attribute flag is described in more detail below.

Further, processor 160 illustratively calculates the current offset of reference clock generator 113 relative to the encoder system timing clock of the program (whose PCR is a sample). The offset may be determined by the following equation:

offset Δ RTS12- Δ PCR12 Δ

Δ RTS12 ═ RTS2-RTS 1; and

ΔPCR12＝PCR1-PCR2

here: Δ PCR12 is the difference between each successive PCR of the procedure,

PCRs 2 are the PCRs in the transport packet currently being processed,

PCR1 is the PCR of the program previously received,

Δ RTS12 is the difference between successive receive timestamps;

RTS2 is the recorded time of receipt for the currently processed transmission packet containing the PCR2, an

RTS1 is a previously received timestamp of a transmission packet containing PCR 1.

After the offsets are calculated, PCR1 and PTS1 are set equal to PCR2 and PTS2, respectively. This offset is used to adjust PCR delta (if necessary) as described below.

(6) Estimated time-of-departure calculation: upon processing in accordance therewith, processor 160 estimates the (ideal) departure time of the transmitted packet. This processing is illustratively included in a receive interrupt handler to sub-multiplex each received incoming transport packet into an outgoing TS. The estimated departure time may be estimated from the time of receipt of the transmission packet (in field 129-5) and the known internal buffering delay at the remultiplexer node 100. Processor 160 writes the expected departure time to field 129-10.

(7) Scrambling/descrambling control word information insertion: typically, in scrambling or descrambling techniques, a dynamically changing control word (such as an encryption or decryption key) is actually required to scramble or descramble the data in the transport packet. Common scrambling and descrambling techniques rely on the use of odd and even keys accordingly, one key for encrypting ES data, with the next key to be used subsequently being transmitted contemporaneously in the TS. Then, a signal is sent indicating that the most recently transmitted key should now be used. The scrambling/descrambling control word may be ES specific or may be used for a group of ESs (on the entire "conditional access system"). The descrambling or scrambling control word may be maintained in a PID indexable table at the remultiplexer node 100. As described in more detail below, processor 160 may insert the base address of the table of control words or the control words themselves into field 129-9 of the descriptor when performing this process.

Initially, the processor 160 selects the PID handler for taking the PAT for each received TS (TS1 and TS2) and thereafter discarding each processed transport packet. During reception of the PAT, transport packets with PIDs of other PSI, such as program definition/PMT section, NIT and CAT, and PIDs of other streams, such as ES stream, ECM stream, EMM stream, and the like, are obtained. Illustratively, the receive PID processor subroutine for the PID of the PAT selects the receive PID processor subroutine for acquiring the PMT, NIT, CAT, etc. This can be easily accomplished by making these subroutines available and simply changing the pointers to the entries in the table 402 of these PID processor subroutines, which can be indexed by the appropriate identifying PID. Note that such a simple PID processor subroutine selection process can be dynamically carried out even when transport packets of TS1 and TS2 are received and processed. The advantages of which are described in more detail below.

Finally, a sufficient number of PSIs are obtained for each TS (TS1 and TS2) to enable an operator to generate user specifications for information to be output in the remultiplexed TS (TS 3). Illustratively, the processor 160 sends the acquired PSI information to the controller 20, for example, using the asynchronous interface 140. Sufficient information for selecting the user specification is sent to the controller 20. This information may be optional, for example, just showing the channel map and different types of ESs (described in terms of, for example, video, audio, secondary audio presentation, closed caption text, etc.) for each TS of the program number contained therein. Alternatively, the information may be exhaustive, such as the ECM that includes the PID of each program, its ES, etc., and the controller 20 simply displays the information to the operator in a coherent and useful manner.

Using the information provided, the operator generates user specifications to output into the TS to be sub-multiplexed (TS 3). This user specification may specify:

(1) a program number in each of the TSs (TS1 and TS2) to be reserved and output in the remultiplexed TS (TS3),

(2) the ES of the reservation program to be reserved or discarded,

(3) an ES, group of ES, program or group of programs to be descrambled and/or scrambled and a source of a control word to be used in scrambling each ES, group of ES, program or group of programs,

(4) any new ECMs or EMMs to be injected or contained in the output remultiplexed TS (TS3), an

(5) Any new PSI information not automatically implied from the above selections, such as NITs or CAT to be placed in the outgoing TS (TS3), the particular PIDs to be remapped and their new PIDs that should be remapped, PIDs assigned to other information generated at the remultiplexer node and carried in the TS (TS3), e.g., burst data as described below, etc.

The user specification is then sent from controller 20 to remultiplexer node 100, for example, via asynchronous interface 140.

The processor 160 receives this user specification and responds by selecting the appropriate receiving PID processor subroutine for the appropriate PID of each received TS (TS1 and TS2) to be sub-multiplexed. For example, for each PID that labels a transport packet containing data to be retained, processor 160 selects a subroutine in which processor 160 inserts a process to estimate the departure time. For each PID that labels a transport packet containing scrambled data, processor 160 selects a subroutine that contains a procedure for selecting the appropriate control word and inserting that control word into the descriptor associated with that transport packet. For each PID that labels transport packets containing a PCR, processor 160 may select a subroutine that contains procedures for setting the PCR flag and calculating the offset, etc. Dynamic adjustment of the user specification and/or PSI data is described in more detail below.

The processor 160 assigns a transmit queue to each device that transmits the remultiplexed TS, i.e., the third adapter 110 that outputs the TS (TS 3). In addition, the processor 160 loads the PID filter map into each cache memory 114 of the first and second adapters 110 receiving TSs (TS1 and TS2), which TSs (TS1 and TS2) have appropriate values for retaining those transport packets to be output in the remultiplexed TS (TS3), for retaining other transport packets containing the PSI, for retaining a trace (track) of the contents of TS1 and TS2, and for discarding each other transport packet.

In addition to selecting a receiving PID processor subroutine, allocating transmit queues, and loading appropriate PID filter mapping modifications, processor 160 illustratively selects a set of transmit PID processor subroutines for each adapter (or other device) that outputs the remultiplexed TS. This is shown in figure 3. The transmit PID processor subroutine is selected based on PID and transmit TS. As described above, in response to receiving a recognizable interrupt (e.g., from the data link control circuit 112 of the adapter 110 sending an output TS, such as TS3), the processor 160 performs step S4. At step S4, the processor 160 examines the descriptors from the receive queue (and/or other possible queues containing descriptors for transport packets that have not yet been scheduled for output) and identifies up to j ≧ 1 descriptor pointing to the transport packet to be output from the interrupt adapter 110. Illustratively, the number j may be programmable and advantageously may be set equal to the number k of transport packets sent from a particular adapter 110 (each time an outgoing TS is sent from that particular adapter 110 between interrupt handlers 160 in that particular adapter 110).

In executing step S4, the processor 160 checks each reception queue for descriptors pointing to transport packets intended for a particular output TS. Processor 160 determines which transport packet pointers output the TS by consulting the pointer table of send PID processor subroutine 404. Like table 402, table 404 includes one entry for each PID and indexes each PID with 0x0000 to 0x1 FFF. Each indexed entry contains a pointer or address of the TIV0, TIV 1. Processor 160 formulates a finger table for transmit PID processor subroutine 404 in accordance with user specifications received from controller 20, modifying this finger table as described below.

The following is an example process that may be combined to send a PID processor subroutine:

(1) nothing (nothing): if the current transport packet is not output in the remultiplexed TS (or other stream) of the device issuing the send interrupt to processor 160, then the PID for this transport packet maps to a subroutine that contains only this process. According to this process, the processor 160 simply skips the transport packet and its descriptor. The examined descriptor is not counted as one of the j transport packets to be output from the particular adapter 110 of the interrupt handler 160.

(2) Sequence descriptor for transmission: if the current transport packet is to be output in a remultiplexed TS (or other stream) of devices that issue a send interrupt to the processor, the PID of this transport packet maps to a subroutine that contains this process (and possibly other processes). According to this process, the processor 160 assigns a transmit descriptor to the transport packet. Processor 160 then copies the relevant information in the receive descriptor pointing to the transport packet into this newly assigned transmit descriptor. The assigned transmit descriptors are then sorted for transmission in the appropriate order in the transmit queue relative to the device requesting the interrupt. In particular, the processor 160 compares the estimated departure time of a packet pointed to by the newly assigned descriptor with the actual dispatch time (the actual time at which the transmitted packet will be sent) recorded in the other descriptors in the send queue. If possible, this descriptor is placed in the send queue before and after each descriptor whose actual dispatch time is later than the estimated departure time of this descriptor. This insertion may be accomplished by copying each transmit descriptor in the sequence of transmit descriptors whose actual dispatch time is later than the estimated departure time of the descriptor to be inserted to each subsequent next descriptor storage location 129 in the queue. Then, the data of the assigned transmission descriptor can be stored in the descriptor storage unit 129 that can be obtained by copying the sequence.

(3) Actual dispatch time determination: processor 160 may determine the actual dispatch time of the transport packet pointed to by the assigned descriptor, which is determined from the estimated departure time of the transport packet. The actual dispatch time is set by determining the transport packet time slot for the outgoing remultiplexed TS (TS3) that is used to send the transport packet to which the newly allocated and inserted send descriptor points. That is, the transport packet time slot of the output TS (TS3) that is closest in time to the estimated departure time is selected. It is assumed that the transport packet will be output at the time of the selected transport packet slot (relative to the internal reference time established by the reference clock generator 113 of the adapters 110 (which are synchronized with each other as described below)). The time associated with each transmission packet slot is assigned as the actual dispatch time. This actual dispatch time is then stored in the field 129-5 of the send descriptor. As described below, the actual dispatch time is actually the approximate time that the data link control circuit 112 of the third adapter 110 (which outputs the remultiplexed TS, i.e., TS3) submits the corresponding transport packet for output. The actual output time of the transport packet is related to the alignment of the transport packet slots established by an external clock that is not known to processor 160. Additional steps may be implemented as described below to eliminate jitter (dejitter) of the PCR caused by this misalignment.

It is contemplated that the bit rate of the TS from which the packet is received (i.e., TS1 or TS2) may be different than the bit rate of the output TS (i.e., TS 3). In addition, packets will be transmitted from the internal buffer to a predetermined delay (related to the length of the receive and transmit queues). However, assuming there is no contention between transport packets of different TSs received in the same transport packet slot of the output remultiplexed TS (TS3), all the transport packets will cause approximately the same latency in the multiplexer hypothesis 100. Since the average latency is the same, no jitter is introduced in the transport packets.

Now, consider a case where two transport packets are received from different TSs (i.e., TS1 and TS2) at almost the same time and are output in a remultiplexed TS (TS 3). The two transport packets may have different estimated departure times, although as such, this estimated departure time corresponds to (closest in time to) the same transport packet time slot of the output remultiplexed TS (TS 3). The transmission packet with the earliest estimated departure time (or receive time) is assigned to this time slot and the actual dispatch time for this time slot. Another transport packet is assigned the next transport packet slot of the outgoing remultiplexed TS (TS3) and its actual dispatch time. Note that the latency incurred by the transmission packet assigned to the next slot is different from the average latency incurred by other transmission packets of the procedure. Thus, processor 160 illustratively seeks to eliminate the latency incurred by this transport packet, including adjusting the PCR of this transport packet (if PCR is included).

(4) PCR offset and latency adjustment: illustratively, this process is contained in the subroutine pointed to by the pointer of table 404 indexed by the PID of the transport packet containing the PCR. Processor 160 determines that PCR latency adjustment is only required when a transport packet is not assigned to the transport packet timeslot of the output remultiplexer TS (TS3) that is closest in time to the estimated departure time of the transport packet (as is the case for other transport packets of the program) and when the PCR flag is set in each receive descriptor. Time offsets in the PCRs due to assignments to non-ideal time slots are corrected. This adjustment is equal to the number of slots that the slot of the transmitted packet deviates from the ideal slot times the time of the slot.

The offset of all PCRs is adjusted as described below unless the input and output TSs are precisely aligned in time or the PCR is received from an asynchronous communication link. In the former case, the offset of the internal clock does not affect the timing of the output PCR. In the latter case, different offset adjustments are used as described below. In all other cases, the time at which the received PCR is output is affected by the offset of the reference clock generator 113 of the adapter 110 receiving the transport packet and the adapter 110 sending this transport packet with respect to the program clock of the PCR. That is, the transmission packet containing the PCR is marked with the reception time stamp obtained from the reference clock generator 113. This receive timestamp is used to determine the estimated departure time and the actual dispatch. As described in detail below, the transport packets are dispatched in accordance with their actual dispatch times with respect to the reference clock generator 113 on the adapter 110 sending the TS (TS3) and all reference clock generators 113 of all adapters 110 that remain synchronized. However, although the reference clock generators 113 are all synchronized with each other, the reference clock generators 113 still experience an offset with respect to the encoder system timing clock that generated the transport packets and their PCRs. This offset may affect the time of each PCR in an output remultiplexer TS (such as TS3) output from remultiplexer node 100.

In accordance with the present invention, remultiplexer node 100 corrects for these offsets. As described above, the portion of the receive processor subroutine for each program's PCR will maintain the current measurement of the offset. The offset of the reference clock generator 113 with respect to the encoder system timing clock of each program is kept measured. For each PCR, the current offset of the program for the PCR (i.e., the offset between the reference clock generator 113 and the encoder system timing clock for the program) is subtracted from the PCR.

By allocating queues, selecting PID processor subroutines, and modifying the PID filter mapping as described above, the remultiplexing can be performed as follows. The transport packets of the TS1 are received at the data link control circuit 112 of the first adapter 110. Likewise, the transport packets of the TS2 are received at the data link control circuit 112 of the second adapter 110. The data link control circuit 112 in each of the first and second adapters 110 consults a local PID filter map stored in a local cache 114 and selectively discards each transport packet with a PID indicating that no transport packet is to be retained. Each data link control circuit 112 retrieves the next unused/unassigned descriptor from the cache memory 114 and determines the transport packet storage location associated with that descriptor. (As described above and below, DMA control circuit 116 continuously obtains control of the sequence of one or more subsequent unused/unallocated descriptors assigned to the receive queue of data link control circuit 112 and the transmit packet storage location to which those descriptors point.) these subsequent unused, unallocated descriptors succeed the descriptor stored in descriptor storage location 129 pointed to by tail pointer 129-4, which data link control circuit 112 may obtain this tail pointer 129-4. (As described above, if tail pointer 129-4 equals the bottom 129-2 of the ring address, then the descriptor pointed to by tail pointer 129-4 will have the end of the descriptor ring command bit set by processor 160 in field 129-7. this will cause data link control circuit 112 to use wrap around addressing techniques to allocate the descriptor stored at the top 129-1 of the ring address in descriptor store.) data link control circuit 112 obtains the time of reference clock generator 113 corresponding to the time at which the first byte of the transmitted packet was received and stores this value as the receive time stamp in field 129-5 of the allocated descriptor. Data link control circuitry 112 stores the number of bytes of the received transport packet in field 129-8. Furthermore, if any errors occur in receiving the transport packets (e.g., missing data link carrier (carrier) of TS1, short packets, long packets, errored packets, etc.), data link control circuitry 112 indicates these errors by setting the appropriate exception bit of 129-6. Data link control circuit 112 then sets a bit in status field 129-7 indicating processed descriptor 129 or an error in processed descriptor 129 and stores the transport packet in the transport packet storage location in cache memory 114 pointed to by the pointer in field 129-4. (Note that in the case of long packets, more than one subsequent sequence of unused unassigned descriptors can be assigned to a received transport packet, and the excess data can be stored in the packet storage location associated with those descriptors.A suitable gather/scatter bit can be set in the attribute field 129-1 of the first of the descriptors to indicate that the data for this packet exceeds the single transport packet storage space associated with the first of the descriptors.A corresponding bit can also be set in the attribute field 129-1 of the last of the descriptors to indicate that it is the last descriptor in a multiple descriptor transfer

The DMA control circuit 116 writes the transfer packet into its corresponding transfer packet storage location in the transfer packet pool 122 of the main memory 120. The DMA control circuit 116 also writes data pointing to the descriptors of the written transfer packet to the descriptor storage units 129 assigned to the receive queues of the adapters 110. Note that the DMA control circuit 116 may identify which transfer packets are to be written to main memory 120 and the transfer packet storage location to which these descriptors point by determining which descriptors have their process complete status bits set in field 129-7. Note that the DMA control circuit 116 may write the descriptor and the data of the transport packet one by one each time the write is completed. Alternatively, the DMA control circuitry 116 may allow for the accumulation of some threshold number of transport packets and descriptors. Then, the DMA control circuit 116 writes data of a sequence of i ≧ 1 multiple completion descriptors and transport packets.

In one embodiment, the scrambler/descrambler circuit 115 is placed on the adapter 110. In this case, the scrambler/descrambler circuit 115 descrambles each transport packet that must be descrambled before the DMA control circuit 116 writes the data of the transport packet to the main memory 120. This is described in more detail below.

When the DMA control circuit 116 writes the descriptor data and the transfer packet to the main memory 130, the DMA control circuit 116 interrupts the processor 160. These interrupts may be initiated by the DMA control circuit 116 when writing data for ≧ 1 descriptor per i to the main memory 130. The interrupt causes the processor 160 to execute one of the received PID processor subroutines for each transport packet (PID and incoming TS specific). As described above, the receiving PID processor subroutine is selected by appropriate modification of the pointers in table 402 so that processor 160 discards, among other things, transport packets that will not be output in the remultiplexed TS, writes the estimated departure time in the descriptor pointing to the outgoing transport packet and sets the PCR flag bit in the descriptor pointing to the transport packet containing the PCR. In addition, the selected receiving PID processor subroutine preferably causes the processor 160 to continuously acquire and update PSI tables, adjust PID filter mappings, and select additional receiving PID processor subroutines as needed to carry out certain user specifications. For example, the user specification may specify a particular program number to be output consecutively in a remultiplexed TS (TS 3). However, the ESs constituting the program undergoes a change due to reaching the event boundary. Preferably, the processor 160 will detect these changes in ES composition by monitoring changes in PAT and PMT, and will change the PID filter mapping and select the receiving PID processor subroutine as needed to output the selected program's ES continuously in the remultiplexed TS (TS3), regardless of the composition of the program.

While performing the above functions related to receiving transport packets, the DMA control circuit 116 and the data link control circuit 112 on the third adapter 110 also perform some functions related to sending transport packets in the TS 3. The data link control circuit 112 of the third adapter 110 generates a transmission interrupt whenever k ≧ 1 transport packet is output by the data link control circuit 112. Illustratively, k may be selected by the processor 160. This send interrupt is received at the processor 160 which executes the appropriate send PID processor subroutine on the output remultiplexed TS (TS 3). In particular, the processor 160 examines the descriptors at the head of each queue containing descriptors pointing to transport packets to be output in the TS 3. As described above, the two receive queues contain descriptors pointing to transport packets to be output in the TS3, including a receive queue associated with the first adapter 110 (receive TS1) and a receive queue associated with the second adapter 110 (receive TS 2). As described below, the processor 160 may allocate an additional queue containing descriptors pointing to transport packets to be output in the TS 3. The processor 160 identifies descriptors pointing to the next j transport packets to be output in the TS 3. This is accomplished by executing the set of transmit PID processor subroutines associated with the third adapter 110 and indexed by the PID of the transport packet in the receive queue header. As described above, if a transport packet corresponding to a descriptor in the queue examined by processor 160 is not to be output from third adapter 110 (generating an interrupt), then the PID of this transport packet will index the sending PID processor subroutine of third adapter 110 which does nothing. If a transport packet is to be output from the third adapter 110 (generating an interrupt) that corresponds to a descriptor in the queue examined by the processor 160, the PID of this transport packet will index the pointer of a sending PID processor subroutine that will: (1) assigning a send descriptor to the transport packet, (2) ordering the send descriptors in the send queue for the third adapter 110 in the correct send order, (3) assigning an actual dispatch time to the assigned descriptors and the transport packet, and (4) performing coarse PCR correction of the offset and latency of the transport packet if necessary. Illustratively, the processor 160 examines (receives) the descriptors in the queue until j descriptors are identified that point to transport packets to be output in the TS3 or from the third adapter 110. These descriptors are examined sequentially from head 124-3 to tail 124-4. If multiple queues with candidate descriptors are available for inspection, processor 160 may inspect these queues in a round-robin fashion in the order of estimated departure times or some other suitable order that may take into account the contents of the transport packets to which the descriptors point (as described below).

The DM control circuit 116 retrieves from main memory 120 data pertaining to a sequence of j ≧ 1 descriptor of the TS3 or the queue of the third adapter 110. These descriptors are retrieved from the queue's descriptor storage location 129 in order from the head pointer 124-3 to the tail pointer 124-4. The DMA control circuit 116 also retrieves from main memory 120 the transport packets from the transport packet storage location of the pool 122 pointed to by each descriptor so retrieved. The DMA control circuit 116 stores the descriptor and the transfer packet thus retrieved into the cache memory 114.

The data link control circuit 112 successively retrieves from the cache memory 114 each descriptor in the transmission queue and the transport packet in the transport packet storage unit to which the descriptor points, in order from the head pointer 124-3. When the time of the reference clock generator 113 of the third adapter 110 equals the time indicated in the dispatch time field 129-5 of the retrieved descriptor, the data link control circuit 112 sends the transport packet pointed to by the descriptor (located in the memory location pointed to by the head pointer 124-3) in TS 3. This dispatch time is only approximately the send time since each transport packet must be sent aligned with the transport packet slot boundary of TS 3. Such boundaries are set with reference to an external clock not known to processor 160. Note that for some reason, the PCR of each transport packet may be slightly jittery. Accordingly, the data link control circuit 112 also finally corrects the PCR according to the precise transmission time of the transmission packet containing the PCR. Specifically, this precise transmission time is less than the estimated transport packet departure time. Data link control circuitry 112 uses the transmit slot boundary clock previously locked to the slot boundary of TS3 to fine tune the estimated PCR (i.e., by adding the difference between the dispatch time and the actual transmit time to the PCR of the transport packet). Note that data link control circuitry 112 may use the PCR flag bit of this descriptor to determine whether a PCR is present in the transport packet (and then whether to correct it).

After sending a transport packet, data link control circuitry 112 sets the appropriate status information in field 129-7 that points to the descriptor of the transmitted transport packet and de-allocates the descriptor. DMA control circuit 116 then writes this status information into the appropriate descriptor storage location of the transmit queue.

In another mode of operation, the operator has full knowledge of the contents of the input TS to be sub-multiplexed. In this case, the operator simply prepares a user specification and sends this user specification from the controller 20 to the remultiplexer node 100 (or to the remultiplexer nodes 100 when multiple nodes are operating in the network distributed remultiplexer 100). Nevertheless, it is preferable to continuously acquire different types of information about the contents (such as PAT, PMT, etc.) of the input TS to be remultiplexed. This allows this content to be immediately reported to the operator (via processor 160 and controller 20), for example, allowing a modified user specification to be generated and the remultiplexing to be dynamically adjusted in accordance with this modified user specification without having to stop inputting the TS to be remultiplexed, outputting the remultiplexed TS, or the remultiplexing process of remultiplexer 100 described above.

In addition to the basic remultiplexer function above, remultiplexer node 100 may perform more advanced functions. These functions are described separately below.

Dynamic remultiplexing and program specific information insertion

As described above, the operator may use the controller 20 to generate user-specified specifications specifying the retained or discarded program and the ES, the scrambled or unscrambled (or both) of the program or ES, remapping of PIDs, and the like. Further, processor 160 preferably continuously acquires content information (e.g., data for PAT, PMT, CAT, NIT, ECM tables, etc.). This allows dynamic real-time or "on the fly" modification of the user specifications and seamless changes to the remultiplexing depending on the new user specifications. Specifically, the operator may change the user specifications and cause remultiplexer 30 to seamlessly switch to remultiplexing in accordance with the new user specifications. In any event, remultiplexer 30 ensures that each output remultiplexed TS is always a continuous bit stream containing an uninterrupted sequence or string of transport packets. Thus, the content of the output remultiplexed TS is modified in such a way that no discontinuities are introduced in the output remultiplexed TS, i.e. no interruptions occur in the output transport packet train or no pauses occur in the output bit stream.

The above seamless modification may be effected by using a programmable processor 160 that controls the flow of transport packets between the input and output adapter 110 or interfaces 140 and 150 and other circuitry such as descrambler/descrambler 170. The choice of considering retaining or discarding different groups of ESs may simply be influenced by the processor 160 adjusting the appropriate PID filter mapping and PID processor subroutines selected by the processor 160 for each PID. The processor 160 may enable the selection of whether certain ESs or programs are scrambled or descrambled by altering the PID processor subroutines executed in response to the PIDs assigned to those ESs or programs so that they include the appropriate scrambling or descrambling process (as described above and below). Processor 160 may implement a different selection of output ports to output different combinations of the output remultiplexed TSs by assigning a transmit descriptor queue to a new output port, de-assigning the transmit descriptor queue to an unneeded output port, generating a pointer table 404 for each new output port's transmit PID processor subroutine, and discarding each pointer table 404 for each de-assigned transmit queue's transmit PID processor subroutine. In the same manner, processor 160 may implement different selections of input ports by allocating and deallocating receive queues and generating pointer table 402 for the receive PID handlers for the allocated receive queues and discarding the pointer table 402 for the handlers for the receive PIDs of the deallocated receive queues.

In addition to selecting the correct transport packet for output, the remultiplexer node 100 illustratively provides the correct PSI for each output remultiplexed TS. This is achieved as follows. The processor 20 (fig. 2) generates a user-specified description of the output TS. Consider the above example in which the remultiplexer node 100 remultiplexes two TSs (i.e., TS1 and TS2) to produce a third TS (i.e., TS 3). Illustratively, table 1 gives the contents of each of TS1 and TS 2.

TABLE 1

Procedure for measuring the movement of a moving object	ES	PID	Procedure for measuring the movement of a moving object	ES	PID
						A	Video A	PID(VA)	E	Video E	PID(VE)
A	Audio A	PID(AA)	E	Audio E	PID(AE)
						A	Data A	PID(DA)	PMT	Prog.Def.E	PID(e)
PMT	Prog.Def.A	PID(a)	F	Video F	PID(VF)
						B	Video B	PID(VB)	F	Audio F	PID(AF)
B	Audio B	PID(AB)	F	Data F	PID(DF)
						PMT	Prog.Def.B	PID(b)	PMT	Prog.Def.F	PID(f)
C	Video C	PID(VC)	G	Video G	PID(VG)
						C	Audio C	PID(AC)	G	Audio frequency 1G	PID(A1G)
C	Decryption C	PID(ECMC)	G	Audio 2G	PID(A2G)
						PMT	Prog.Def.C	PID(c)	G	Data G	PID(DG)
D	Video D	PID(VC)	G	Decryption G	PID(ECMG)
						D	Audio 1D	PID(A1D)	PMT	Prog.Def.G	PID(g)
D	Audio 2D	PID(A2D)	PAT	PAT2	0x0000
						D	Data D	PID(DD)
PMT	Prog.Def.D	PID(d)
						PMT	PAT 1	0x0000

Preferably, the controller 20 programs the processor 160 to extract the information shown in Table 1 using the acquisition process of the received PID processor subroutine described above.

Assume that the user-specified specification specifies that only programs A, B, F and G are to be retained and output in a remultiplexed output TS (TS 3). The user indicates this at the controller 20 (FIG. 1), for example using the keyboard/mouse 27 (FIG. 1). The controller 20 determines whether this user specification is valid. In particular, the controller 20 determines whether each output sub-multiplexed TS (such as TS3) has sufficient bandwidth to output all of the designated programs A, B, F and G and associated PSI (i.e., program definitions a, b, f, G and a new alternate PAT3 as described below). If such bit rate information is not known, it may be obtained from processor 160. For example, the processor may execute a PID processor subroutine to determine the bit rate (or transport packet rate) for each program from the received timestamp assigned to each transport packet with the PCR for each program. As described above, processor 160 obtains this information for the purpose of performing PCR adjustments in general. If the user specification is not valid, the processor 20 does not download the user specification. If the specification is valid, controller 20 downloads the user specification to processor 160.

It is assumed that the bandwidth of the TS3 may meet user specifications. If the PAT and PMT of the incoming TS (TS1 and TS2) have not been acquired, the processor 160 acquires its PAT and PMT. Based on the information in PAT1 and PAT2, processor 160 constitutes an alternate PAT3 that includes only the entries of PAT1 and PAT2 that indicate the PIDs of program definitions a, b, f, and G for programs A, B, F and G. Again, this may be accomplished using the appropriate PID processor subroutines for the PIDs of PAT1 and PAT2, and is preferably performed continuously to ensure that any changes to the program reflected in PAT1 and PAT2 are incorporated into the alternate PAT 3. The processor 160 generates a sequence of transport packets containing this new substitute PAT3 and stores them in the packet buffer 122. The processor 160 also generates a PAT queue, preferably implemented as a ring 124, of descriptors pointing to these transport packets with PAT 3. Advantageously, the PAT descriptor queue of the PAT3 transport packet is dedicated to storing only the substitute PAT information. In addition, the processor 160 generates estimated departure times and stores them in a descriptor of the PAT queue pointing to the PAT3 transport packet.

The PAT3 descriptor queue can now be serviced by the processor 160 in response to sending an interrupt in the same manner as any receive queue. That is, when the data link control circuit 112 sends k ≧ 1 packet and interrupts the processor 160, the processor 160 will extract descriptors from the PAT3 queue as well as the receive queue. Here, all queues containing a transmission descriptor pointing to a transmission packet to be output (the transmission descriptor in the transmission queue has not been assigned) are collectively called "connection queue".

The processor 160 then constructs the appropriate filter mappings and passes one filter mapping to the first adapter 110 receiving the TS1 and a second filter mapping to the second adapter 110 receiving the TS 2. For example, a first filter map may indicate that extracts and retains a filter having a PID: PID (va), PID (da), PID (a), PID (vb), PID (ab) and PID (b) (and possibly other PIDs corresponding to PSI in TS 1). Likewise, the second filter map may indicate that the extract and reserve has a PID of: PID: transport packets for PID (vf), PID (af), PID (df), PID (f), PID (vg), PID (A1G), PID (A2G), PID (dg), PID (ecmg) and PID (g) (and possibly other PIDs corresponding to PSI in TS 2). In response thereto, the first and second data link control circuits 112 receiving TS1 and TS2 extract only these transport packets from TS1 and TS2 in accordance with the filter mapping provided by the processor 160. As described above, the first and second data link control circuits 112 store these extracted packets in the cache memory 114 and assign descriptors thereto. The first and second DMA control circuits 116 periodically write the data of the extracted transfer packet and its descriptor to the main memory 120. The data of the descriptor written by the first DMA control circuit 116 is stored in each descriptor storage unit 129 of the first receive queue of the first data link control circuit 112, and the data of the descriptor written by the second DMA control circuit 116 is stored in the descriptor storage unit of the second receive queue of the second data link control circuit 112.

In addition, the third DMA control circuit 116 retrieves descriptors and their corresponding transport packets from the transmit queue for TS3 and stores them in the cache memory 114. The third data link control circuit 112 retrieves each descriptor from the cache memory 114 and sends them in TS 3. The third data link control circuit 112 generates an interrupt after k ≧ 1 transport packet is transmitted. This allows the processor 160 to access a pointer table for the transmit PID processor subroutine for the transmit queue associated with the third data link control circuit 112. Upon execution of the appropriate send PID processor subroutine, the processor 160 assigns unused send descriptors in TS3 to descriptors in the available connection queues (i.e., the first receive queue, the second receive queue, and the PAT3 queue) and copies information about the descriptors so assigned from these connection queues. The send descriptors are allocated in the TS3 send queue in order of estimated dispatch time with respect to the receive descriptors.

Note that any type of PSI may be dynamically inserted, including new program definitions, EMMs, ECMs, CAT, or NITs.

Now consider the case where a new user specification description is generated while remultiplexing occurs in accordance with the previous user specification. As described above, the controller 20 begins to verify whether there is sufficient bandwidth to meet the new user specifications. If so, the new user specification is downloaded to the processor 160. The new user specification may require processor 160 to extract different programs and ESs, map PIDs differently, or generate: (a) a new PSI, (b) a transport packet with the new PSI, and (c) a descriptor pointing to the transport packet with the new PSI. In the case of modifying the program or ES contained in the TS3, the processor 160 modifies the PID filter mapping in accordance with the new user specification to retain the transport packets to be retained and to discard the transport packets to be discarded. These new filter mappings are transferred to the caches 114 and the caches 114 immediately and dynamically switch to fetch the transport packets according to the new user specifications. Processor 160 also selects the appropriate receive PID processor subroutine for the new transport packet to be reserved by modifying the pointer of receive PID processor subroutine pointer table 402 associated with the PID of the new transport packet to be reserved. The pointers of the receiving PID processor subroutine pointer table 402, indexed by the PID of the transport packets that are now to be discarded, may also be modified. In the case of a new PID remapping, the processor 160 selects the appropriate subroutine to perform the new PID remapping.

Such a change may require the generation of a new PSI, such as a new PAT. The processor 160 selects the appropriate PID processor subroutine to generate the new PSI. For example, in the case of a new PAT, the PID processor subroutine may be triggered by the PIDs of the PATs of TS1 and TS 2. The processor 160 generates a new PSI and inserts the new PSI into the transport packet. The descriptors in the PSI queues are assigned to these new PSI transport packets. The processor 160 stops servicing (i.e., refreshes and transmits) any PSI descriptor queue directed to transport packets containing the old PSI, but instead services the new PSI descriptor queue.

Upon each change, i.e., each newly selected PID processor subroutine is available (each PSI insertion modification or each new PID filter mapping), the appropriate data link control circuit 112 or processor 160 seamlessly changes its operation. Until such changes are made, the data link control circuit 112 or processor 160 continues to operate under the previous user specifications. Care must be taken in the ordering as each change occurs so that the output remultiplexed TS always conforms to MPEG-2. For example, any changes made to the PID mapping, PID filtering, programs, ES, ECMs, etc. in the TS (which affect the PMT or PAT) are preferably delayed until such time as a new version of the PMT (or its particular program definition) and/or PAT may be output in the TS and an indication to switch to a new PMT, program definition, or PAT is indicated in the TS. Similarly, if an EMM of a conditional access system is included or lost, the introduction of this EMM is delayed until a new version of the CAT can be sent in the TS. The internal process management of the resource wants to additionally deliberately order changes, such as a receiving PID processor subroutine that stores a pointer into the appropriate receiving PID processor subroutine pointer table of the PID index of the transport packet to be retained (which was previously discarded) before changing the PID filter mapping for each adapter 110 that retains the transport packet with this PID.

The following is an example of modifying the remultiplexing according to new user specifications. Assume that the user provides a new user specification indicating that programs B and F should be discarded and programs C and D should be retained. In response, the controller 20, upon modifying the remultiplexed TS (TS3) in accordance with the new user specifications, first determines whether there is sufficient bandwidth in the output remultiplexed TS (TS3) to accommodate all of the new program data and the new PSI that must be generated therefor. If so, the new user specification is downloaded to remultiplexer node 100. Processor 160 modifies the PID filter mapping in the first adapter 110 to discard transport packets having PIDs (PID), (VB), PID (AB), PID (b)), and retains transport packets having PIDs (PID), (VC), PID (AC), PID (ECMC), PID (c), PID (VD), PID (A1D), PID (A2D), PID (DD), and PID (d). similarly, processor 160 modifies the PID filter mapping in the second adapter 110 to discard transport packets having PIDs (PID), (VF), PID (AF), PID (DF), and PID (f). processor 160 selects the PID processor subroutines including the PID definitions for each of PID (PID VC), PID (AC), PID (ECMC), PID (c), PID (VD), PID (A1D), PID (A2D), PID (DD), and PID (d), including the new PID definitions for each of PID (C) and PID (d), A control word update process for pid (ecmc), a descrambling control word information insertion process for each scrambled ES (e.g., pid (vc)) of the program C. The processor 160 also generates a different alternative PAT3 including program definitions a, b, c, d, and g, for example, during execution of a PID processor subroutine for PID (0) for each of the first and second adapters 110.

Now consider the case where another new user specification is provided indicating that the VA video ES of program a should be scrambled. Further, the controller 20 first determines whether there is sufficient bandwidth in the TS3 to accommodate the ECM with VA transport packets and the new program definition for program a. If so, the new user specification is downloaded to remultiplexer node 100. The processor 160 allocates a queue for storing descriptors of transmission packets pointing to ECMs containing the VA. Processor 160 selects the appropriate PID processor subroutine for PID (VA), including inserting scrambling control words into descriptors pointing to transport packets containing VA. The processor 160 also generates transport packets containing control words of ECMs as VA and assigns descriptors pointing to these transport packets. This may be accomplished using a timer driven interrupt handler subroutine. Alternatively, additional hardware (not shown) or software executed by the processor 160 periodically generates control words and interrupts the processor 160 when those control words are ready. Processor 160 responds to these interrupts by placing an available control word in one or more transport packets, assigning ECM descriptors of an ECM queue to these transport packets, and loading the new control word into the appropriate control word table. In addition, processor 160 also selects a receiving PID processor subroutine for PID (a), including extracting the information in program definition a and adding information about ECMA (e.g., PID (ECMA), its encrypted ES, etc.).

Scrambling/descrambling control

One problem associated with scrambling and descrambling is the selection of the correct control word or key for each transmitted packet. That is, the scrambled transport packet data may be scrambled with a PID-specific control word or a control word specific to a set of PIDs. A rotating control word scheme may be used when the control word changes from time to time. In short, there may be a large number of control words (e.g., keys) associated with each TS and these control words are changed periodically. In the case of descrambling, it is necessary to provide a mechanism for successively receiving control words for each ES or ES group to be descrambled and selecting an appropriate control word at each time. In the case of scrambling, a mechanism must be provided for selecting the correct control word for ES or ES group scrambling and inserting this into the output remultiplexed TS sufficiently ahead of any scrambled ES data so formed.

These descriptors and their ordering in the receive and transmit queues may be used to simplify scrambling and descrambling of the TS. In particular, each receive descriptor has a field 129-9 in which information about scrambling or descrambling may be stored, such as a pointer to a control word or table of appropriate control words (containing control words for scrambling or descrambling of the transport packet) used when scrambling the transport packet.

First consider the steps performed in descrambling a transport packet. The TS containing the transport packets to be descrambled contains transport packets with ECMs (ES-specific conditional access) and EMMs (conditional access specific to the entire ES group). The EMM is carried in a transport packet labeled with a PID unique to an ES group to which the EMM corresponds, and the ECM is carried in a transport packet labeled with a PID unique to a specific ES to which each ECM corresponds. The PID of the EMM may be correlated with the particular ES group to which the EMM corresponds with reference to the CAT. The PID of the ECM may be associated with each particular ES to which the ECM corresponds with reference to the PMT. The processor 160 selects a PID processor subroutine to:

(1) recovers each CAT and PMT sent in the TS and identifies the version of the CAT or PMT currently in use,

(2) referring to the PMT, the ECM table indexed by the PID of the transport packet carrying the ES corresponding to the ECM is restored.

Processor 160 then defines a series of processing steps to be performed on each transport packet and descriptor. That is, the processor 160 defines a particular order in which the data link control circuit 112 of the receive adapter 110, the descrambler 115 of the (optional) receive adapter 110, the DMA control circuit 116 of the receive adapter 110, the (optional) descrambler 170, and the processor 160 may process a receive descriptor or a packet pointed to by a receive descriptor. To this end, the processor 160 may communicate appropriate control information to each of the devices 112, 115, and 116 to cause them to process the transport packet and the descriptor pointing to the transport packet in a particular order of a series of processing steps defined as described below.

If the descrambler 115 of the adaptor 110 is used, the order of processing in the sequence is defined as follows. The data link control circuit 112 of the adapter 110 receives the transport packets and assigns a receive descriptor to selected ones of those transport packets that were not discarded according to the PID filter mapping described above. After each reserved transport packet is stored in cache memory 114, data link control circuit 112 sets status bit 129-7 in the descriptor pointing to the transport packet, illustratively, to indicate that the transport packet is now available for processing by the next device in the order of the defined sequence of processing steps.

Descrambler 115 periodically checks cache 114 for the next descriptor or descriptors whose status bit 129-7 is set to indicate that descrambler 115 has been granted permission to modify the transmitted packet. Illustratively, descrambler 115 accesses cache 114 after m ≧ 1 descriptor has been processed. The descrambler 115 accesses each descriptor of the cache 114 in turn, starting with the descriptor previously accessed by the descrambler 115, until m ≧ 1 descriptors have been accessed or until such descriptor is reached, whose status bit 129-7 is set to indicate that the previous step of processing has been performed on the descriptor and the transport packet to which it points, in the order of the defined sequence of processing steps.

In processing the descriptors and transport packets, descrambler 115 uses the PID of the transport packet pointed to by the currently examined descriptor to index the descrambling map located in cache memory 114. Illustratively, the processor 160 periodically updates the descrambling map in the cache memory 114 as described below. The location of the descrambling map is provided by the base address located in the descriptor up to 129-9. Illustratively, processor 160 loads the base address of the descrambling map into up to 129-9 of each descriptor when allocating the receive descriptor queue. The indexed entry of the descrambling map indicates whether the transport packet is scrambled and one or more control words that descramble the transport packet may be used when scrambled. The indexed entry of the descrambling map may contain a control word corresponding to the PID of the transport packet or a pointer to a storage location in which each control word is stored. If the indexed entry of the descrambling map indicates that the transport packet pointed to by the accessed descriptor is not to be descrambled, descrambler 115 simply sets status bit 129-7 of the descriptor to indicate that the next processing step may be performed on the descriptor and its pointed to transport packet in the order of the defined sequence of processing steps.

If the indexed entry of the descrambling map indicates that the transport packet is to be descrambled, the descrambler 115 obtains a control word corresponding to the PID of the transport packet and descrambles the transport packet data using the control word. Note that typical descrambling schemes use rotating (i.e., odd and even) control words as described above. The correct odd or even control word used in descrambling a transport packet is indicated by a control bit in the transport packet, such as the Transmit _ Scramble _ control bit. Descrambler 115 uses these bits along with the PID of the transport packet in indexing the correct control word. That is, the mapping made up and maintained by the processor 160 is indexed by the PID and odd/even indicators. Then, the descrambler 115 stores the descrambled transmission packet data in the transmission packet storage unit pointed to by the currently checked descriptor, thereby overwriting the pre-descrambled data of the transmission packet. Descrambler 115 then sets status bit 129-7 of the descriptor to indicate that the next processing step can be performed on the descriptor and the transport packet it points to in the order of the defined sequence of processing steps.

The DMA control circuit 116 periodically writes the transfer packet data and data of the descriptor pointing to the transfer packet from the cache memory 114 to the respective memory units 122 and 129 of the main memory 130. In doing so, the DMA control circuit 116 periodically checks the cache memory 114 for a sequence of one or more descriptors that follow (in the order of the receive queue) the last descriptor processed by the DMA control circuit 116. If the status bit 129-7 of the examined descriptor indicates that the processing of the DMA control circuit 116 can be performed on the examined descriptor, then the DMA control circuit 116 sets the appropriate status bit 129-7 in the descriptor to indicate that the next processing step can be performed on this descriptor and the transport packet it points to in the order of the defined sequence of processing steps. The DMA control circuit 116 then writes the data of the descriptor and the data of the transfer packet to which it points to the main memory 130. However, if status bit 129-7 is set to indicate a processing step before the processing performed by DMA control circuit 116 is still to be performed on the descriptor, then DMA control circuit 116 avoids processing the descriptor and the transport packet to which it points. Illustratively, when enabled, the DMA control circuit 116 checks the descriptors until the DMA control circuit 116 writes a sequence of i ≧ 1 descriptor and the data of the transport packet to which those descriptors point, or until such a descriptor is encountered whose status bit 129-7 indicates that the previous processing step is still to be performed on that descriptor in the order of the defined sequence of processing steps. Each time the DMA control circuit 116 transfers i ≧ 1 transfer packet, the DMA control circuit issues an interrupt.

Processor 160 responds to interrupts issued by, for example, DMA control circuit 116 by executing the appropriate receiving PID processor subroutine. Processor 160 checks for one or more descriptors in the receive queue corresponding to adapter 110 from which the interrupt was received, starting with the last descriptor processed by processor 160. Illustratively, the processor 160 only executes the appropriate receiving PID processor subroutines on descriptors whose status bits 129-7 are set to indicate that the processing of the processor 160 can be performed on the descriptors. Each time the processor 160 is interrupted, the processor 160 processes the descriptor and the transport packet it points to, illustratively, until a PID processor subroutine is performed for i ≧ 1 transport packet or until such a descriptor is encountered whose appropriate status bit 129-7 is set to indicate processing that the previous processing step (in the order of the defined sequence of processing steps) is still being performed on that descriptor. .

During execution of the appropriate receive PID processor subroutine, processor 160 recovers all control words of all ESs and updates the descrambling and control word table or mapping used by descrambler 115 (or 170 as described below). In the rotating control word scheme, processor 160 maintains multiple (i.e., odd and even) keys for each PID in a control word table or map. Processor 160 may also perform processing to enable subsequent scrambling of the descrambled transport packet (as described below). After processing the received descriptors, processor 160 deallocates the descriptors by setting status bits 129-7 of the descriptors to indicate that the descriptors are invalid (and thus that data link control circuitry 112 is the next device to process the descriptors), erasing or resetting selected fields of the descriptors, and advancing head pointer 123-3 to next descriptor storage location 129.

Now consider the case where descrambler 115 is not provided or used on adapter 110. Instead, a descrambler 170 located on bus 130 is used. A very similar procedure as before is performed. In this case, however, the order of the processing steps of the defined sequence is changed such that the DMA control circuit 116 processes the descriptors (and their corresponding transport packets) after the data link control circuit and before the descrambler, and the descrambler 170 processes the descriptors (and their corresponding transport packets) after the DMA control circuit 116 but before the processor 160. The DMA control circuit 116 then processes the descriptor and the transport packet to which it points after the data link control circuit 112 assigns the descriptor to the transport packet and sets the appropriate status bit 129-7 to enable the next processing step to be performed on them. As described above, DMA control circuit 116 sets status bit 129-7 to indicate that the next processing step can be performed on the descriptor, and writes the transfer packet and descriptor to main memory 130.

Descrambler 170 periodically checks the descriptors in the receive queue to identify the descriptor whose status bit 129-7 is set to indicate that the descriptor and the transport packet it points to can be descrambled (in the order of the defined sequence of processing steps). Descrambler 170 processes these identified transport packets in a manner similar to that discussed above for descrambler 115. After processing these transport packets, descrambler 170 sets one or more status bits 129-7 to indicate that the next processing step (in the order of the defined sequence of processing steps) can now be performed on the descriptor and the transport packet it points to.

Processor 160 performs the processing described above, including executing the appropriate receive PID processor subroutines, in response to interrupts issued by DMA control circuit 116. Preferably, the queue length of the receive queue associated with the adapter 110 of the interrupt handler 160 is long enough relative to the processing time of the descrambler 170 to allow the processor 160 to check and process descriptors for which the descrambler 170 has completed processing. In other words, processor 160 and descrambler 170 preferably do not attempt to access the same descriptors at the same time. Again, the processor 160 begins processing descriptors at a different point in the receive queue than the descrambler 170.

Now consider the processing related to scrambling. As with the descrambling process, the processing steps performed by each descriptor and the transport packets to which the descriptors point are ordered in the order of the defined sequence of processing steps using status bits 129-7 in the descriptors. Scrambling, as opposed to descrambling, is preferably performed after processor 160 has assigned a transmit descriptor to the transport packet to be scrambled. Thus, the control word field 129-9 may be used in one of two ways. As with descrambling, the base address of the scrambling map may be placed in the control word descriptor field 129-9. However, since scrambling occurs after the descriptors in the transmit queue are processed by processor 160, the correct control word itself is preferably placed in the control word descriptor field 129-9.

First, a scrambling process of scrambling by the scrambler 115 of the transmission adapter 110 is considered. Processor 160 obtains ECM transmission packets containing control words (preferably encrypted). These ECM transmission packets are queued in respective connection queues and scheduled to be output at the correct time. That is, the ECM transport packets are scheduled to be inserted into the outgoing TS sufficiently ahead of their descrambled transport packets so that the decoder recovers the control word before receiving its descrambled transport packets.

At an appropriate time after the transmission of the ECM transmission packet containing the control word, the processor 160 changes the table of control words to encrypt the data using the new key corresponding to the most recently transmitted control word. When a transport packet is sent from the output adapter, processor 160 executes a send PID processor subroutine associated with the PID of the transport packet pointed to by the descriptor in the examined connection queue. For each of these transport packets to be scrambled, the transmit PID processor subroutine includes a process for inserting control word information into the descriptor associated with that transport packet. The control word information may simply be the base address of the scrambling map to be used in identifying the control word for scrambling the transport packet. However, the control word information may also be the correct control word to be used in the transport packet scrambling. Processor 160 may also toggle (toggle) bits such as the Transmit _ ScrambleCONTROL bit etc. in the transport packet to indicate which of the most recently transmitted control words should be used to decrypt or descramble the transport packet at the decoder. Further, processor 160 illustratively sets one or more status bits 129-7 of the newly assigned transmit descriptor to indicate that the next processing step (in the order of the defined sequence of processing steps) should be performed for this transmit descriptor and the transport packet it points to.

The DMA control circuit 116 of the transmit adapter 110 periodically retrieves the descriptor data and the transport packets to which the descriptors point from the transmit queue. In doing so, the DMA control circuit 116 checks for a descriptor in the transmit queue following the last descriptor that the DMA control circuit 116 transferred the descriptor data to the cache 114. The DMA control circuit 116 transfers only the data of these send descriptors whose status bits 129-7 are set to indicate that the processing of the DMA control circuit 116 (in the order of the defined sequence of processing steps) can now be performed. For example, the DMA control circuit 116 may check the send descriptor until a certain number k ≧ 1 send descriptor has been identified that the DMA control circuit 116 is permitted to process, or until a descriptor is identified whose status bit 129-7 is set to indicate that the previous processing step is still being performed on the send descriptor and the transport packet to which it points. After transferring the data for these send descriptors and the transport packets to which these send descriptors point to the cache memory 114, the DMA control circuit 116 sets the status bit 129-7 for these transferred send descriptors to indicate that the next processing step (in the order of the defined sequence of processing steps) can be performed on these send descriptors and the transport packets to which they point.

The scrambler 115 then periodically checks the descriptors in the cache memory 114 for a sequence of one or more descriptors to be processed and the transport packets it points to. The scrambler 115 processes only those accessed descriptors that have one or more states 129-7 set to indicate that scrambling processing steps (in the order of the defined sequence of processing steps) may be performed on those descriptors. The scrambler 115 accesses the control word information field 129-9 and uses the information therein to scramble each transport packet to be scrambled. As described above, the control word information may be used in one of two ways. If the control word information is the base address of a scrambling map, the scrambler 115 indexes the scrambling map using the base address and the PID information for this transport packet. The indexed entry of the scrambling map indicates whether the transport packet is to be scrambled and a control word for scrambling the transport packet when scrambling is to be performed. Alternatively, the control word information itself in field 129-9 indicates whether the transport packet is to be scrambled and the control word used to scramble the transport packet when scrambling is to be performed. If the transport packet for which the descriptor is being processed is not to be scrambled, the scrambler 115 simply sets the appropriate status bit 129-7 to indicate that the next processing step (in the order of the defined sequence of processing steps) can now be performed on the transmit descriptor and the transport packet to which it points. If the transport packet of the descriptor being processed is to be scrambled, the scrambler first scrambles the transport packet data, stores the transport packet in cache memory in place of the unscrambled transport packet, and then sets the appropriate status bit 129-7.

Data link control circuitry 112 periodically checks for transmit descriptors in cache memory 114 that have one or more status bits 129-7 set to indicate that processing by data link control circuitry 112 may be performed on these descriptors. For these transmit descriptors, the data link control circuit 112 transmits the transport packets to which these descriptors point at the actual dispatch times indicated in these descriptors. Data link control circuitry 112 then de-allocates these descriptors (and sets status bits 129-7 to inactive). Illustratively, data link control circuitry 112 generates a transmission interrupt that is received by processor 160 whenever data link control circuitry 112 transmits a sequence of k ≧ 1 descriptor.

In the case where the scrambler 115 is not present or used, illustratively, the scrambler 170 is used instead. The sequence of processing steps is altered such that the scrambler 170 processes each transmit descriptor and its pointed to transport packet after the processor 160 but before the DMA control circuit 116, and the DMA control circuit 116 processes each transmit descriptor and its pointed to transport packet after the scrambler 170 but before the data link control circuit 110.

Bandwidth optimization

As described above, the null transport packet is generally inserted in the TS with the program. These null transport packets exist because the program encoder typically must allocate excess bandwidth to each program. This is because the amount of encoded data generated per ES generated at a time can be controlled only so much. Without this "overhead bandwidth," the encoded ES data would frequently exceed the amount of bandwidth allocated to it, leaving the encoded ES data missing in the TS. Alternatively, an ES encoder (particularly a video ES encoder) may not always obtain the data that is output when a transmission packet slot occurs. For example, the encoding of a particular graphic may take an unexpectedly longer time than previously expected, causing a delay in the generation of encoded video ES data. These time slots are filled with empty transport packets.

Although the presence of null transport packets must be tolerated in remultiplexer node 100, it is desirable to reduce the number of these bandwidth-wasting null transport packets. In doing so, however, the bit rate of each program should not be changed and the end-to-end delay of these programs should be kept constant. According to one embodiment, a technique is utilized to replace null transport packets with other transport packet data to be re-multiplexed if such other transport packet data is available. This is achieved as follows.

Consider first that processor 160 has multiple connection queues existing, which contain descriptors of packets to be scheduled for transmission, i.e., descriptors in receive queues, PSI queues, other data queues, etc. that have not yet been transferred to transmit queues. As described above, these descriptors may point to transport packets related to the received incoming TS or streams of other related programs generated by the processor 160, such as PAT streams, PMT streams, EMM streams, ECM streams, NIT streams, CAT streams, and the like. However, other types of transport packets to be scheduled and their descriptors 129 exist, such as transport packets with unique data that is not time sensitive "bursty" or "best effort". For example, these additional transport packets may contain transactional computer data, such as data transmitted between a Web browser and a Web server. (remultiplexer node 100 may be a server, a terminal, or simply an intermediate node in a communication system connected to the "internet". this connection to the internet may be accomplished using a modem, adapter 140 or 150, etc..) these data do not have the requirement of constant end-to-end latency. Instead, the data may be sent in bursts (bursts) as long as bandwidth is available.

Processor 160 first causes each empty transport packet to be discarded. This may be accomplished by the processor 160 using a receive PID processor subroutine that discards all null transport packets. Illustratively, this technique is used when a null transfer packet is received from a device external to the adapter 110 (such as the interface 140 or 150). Alternatively, if null transport packets are received from adapter 110, processor 160 may provide a PID filter map to data link control circuitry 112 to discard each null transport packet. Each incoming transport packet to be output in the TS is then assigned an estimated departure time as a function of the time of receipt of the transport packet (recorded in its descriptor) and an internal buffering delay within remultiplexer node 100, pursuant to a receive PID processor subroutine. In each connection queue containing transport packets to be scheduled, the assigned departure time cannot be a continuous transport packet transmission time (corresponding to an adjacent time slot) of the outgoing TS. Furthermore, the estimated departure times of two consecutive descriptors of transport packets to be output in a unified output TS may separate one or more transport packet transmission times (or time slots) of an output remultiplexed TS in which these transport packets are to be transmitted.

Preferably, descriptors pointing to transmission packets with program data, descriptors pointing to transmission packets with PSI, ECM or EMM, and descriptors pointing to burst data are held in separate connection queues. In an implementation, each connection queue is assigned a priority of service that is related to the type of data in the transport packet pointed to by the descriptor queued therein. Preferably, program data received from outside the multiplexer node (e.g., via receive adapter 110 or interface 140 or 150) is assigned the highest priority. The connection queues storing streams of PSI, ECM or EMM generated by the remultiplexer node 100 may also be assigned the same priority. Finally, the connection queue with descriptors pointing to such transmission packets (containing bursty data without specific continuity, propagation delay or bit rate requirements) is assigned the lowest priority. Further, unlike the program, PSI, ECM, and EMM data, an estimated departure time is not assigned to a descriptor of a transmission packet with burst data or recorded therein.

During execution of the transmit PID processor subroutine, the processor 160 transfers descriptors relating to transport packets to be scheduled from their respective connection queues to a transmit queue. In doing so, processor 160 preferably services each connection queue of a given priority (i.e., examines the descriptors therein) before committing to service the connection queue of a lower priority. In examining the descriptors, processor 160 determines whether any examined descriptors of the connection queue with high priority (i.e., descriptors containing transport packets with program PSI, ECM, or EMM data) point to transport packets that must be sent at the next actual dispatch time, based on the estimated departure times assigned to these transport packets. If so, processor 160 assigns a send descriptor to each such transport packet, copies the relevant information in the connection queue descriptor into the assigned send queue descriptor, and assigns an appropriate dispatch time to each transport packet assigned by the send descriptor. As described above, occasionally two or more transport packets compete for the same actual departure time (i.e., the same transport packet slot of the output remultiplexed TS), in which case a sequence of transport packets is assigned to consecutive slots and actual departure times. PCR adjustments are made to these transport packets as necessary.

At other times, when the processor 160 services a connection queue, the estimated departure time of a transport packet of the higher priority connection queue does not cause the processor 160 to assign the transport packet to the next available slot and actual dispatch time in the outgoing remultiplexed TS. Typically, this will result in empty time slots in the output remultiplexed TS. In this case, however, processor 160 preferably services a lower priority connection queue. Processor 160 examines the lower priority connection queue (in order from head pointer 124-3), selectively assigns transmit descriptors to each of the sequence of one or more transport packets to which the examined descriptors point, and copies information about the examined descriptors onto the assigned transmit descriptors. Processor 160 selectively allocates (additional) empty time slots to each of the transport packets pointed to by these examined descriptors and stores the actual dispatch time for the assigned time slots in the allocated corresponding transmit descriptors.

Occasionally, a transport packet not indicated by a descriptor in a connection queue of higher or lower priority may be allocated to a time slot of an outgoing remultiplexed TS. This may occur because neither the estimated departure time of a high priority transmission packet corresponds to the actual dispatch time of a time slot nor the transmission packet with bursty data is buffered awaiting transmission at the remultiplexer node 100. Alternatively, the transmission packets with bursty data are buffered, but processor 160 chooses not to assign a send descriptor to it at this particular time for reasons discussed below. In this case, the descriptors in the transmit queue will have an actual transmit time corresponding to the output sequence of discontinuous transport packet slots of the remultiplexed TS. When the data link control circuit 112 of the transmit adapter 110 encounters such a discontinuity, the data link control circuit 112 transmits an empty transport packet (using the transmit descriptor actual dispatch time) in each empty time slot that is not assigned a transport packet. For example, assume that the dispatch times of two consecutive descriptors in the transmit queue relating to the first and second transport packets indicate that the first transport packet will be transmitted at the first transport packet slot and the second transport packet will be transmitted at the sixth transport packet slot. Data link control circuitry 112 transmits the first transport packet in the first transport packet slot. At each of the second, third, fourth and fifth transmission packet slots, data link control circuit 112 automatically transmits a null transmission packet. At the sixth transport packet slot, the data link control circuit 112 transmits the second transport packet.

Note that bursty or exhaustive data typically does not have strict receive buffer constraints. That is, most bursty or exhaustive data receivers and receiver applications do not specify a maximum buffer size, data fill rate, or the like. Instead, a transport protocol such as the Transmission Control Protocol (TCP) may be utilized so that when the receiver buffer fills, the receiver simply drops the subsequently received data. The receiver does not acknowledge receipt of the dropped packet and the source retransmits the packet with data that was not acknowledged as received. This effectively throttles the effective data transmission rate to the receiver. While this throttling technique can effectively achieve accurate data transmission rates to the receiver, it has two problems. First, the network must support two-way communication. There is only a portion of all cable television networks and no direct broadcast satellite network to support two-way communication between the transmitter and receiver (there is no telephone return path). In any case where bi-directional communication is supported, the return path from the receiver to the sender has a substantially smaller bandwidth than the forward path from the sender to the receiver, and this return path must typically be shared by multiple receivers. Thus, the aggressive use of TCP as a throttling mechanism takes advantage of a large portion of the return path (which must also be used for other receiver-to-sender communications). Furthermore, bandwidth of the forward path that sends the dropped transport packets is undesirably wasted.

Preferably, the insertion of bursts or best effort data should not cause these buffers to overflow. Illustratively, assuming the occupancy of a certain (or typical) receiver buffer and the pendency of the data therein, the PID processor subroutine may control the rate at which bursts of data are inserted to achieve a certain average rate so as not to exceed a certain peak rate or even simply to prevent receiver buffer overflow. Thus, even when the processor 160 has access to bursts or otherwise exhausted data (no other data inserted therein) that are inserted into one or more empty transmission packet slots, the processor 160 may choose to insert bursts only into some empty transmission packet slots, choose to insert bursts into alternate or spaced transmission packet slots, or choose not to insert bursts into any empty transmission packet slots, thereby adjusting data transmission to an assumed receiver burst data buffer, or preventing overflow of the buffer. Furthermore, transport packets intended for multiple different receivers may themselves be interleaved (interleaved) regardless of when they are generated to maintain a certain data transmission rate for the receiver.

In any case, the remultiplexer node 100 provides a simple method of optimizing the bandwidth of the TS. All null transport packets in the incoming TS are discarded. If transport packets are available, they are inserted into the time slots that would normally be allocated to the null transport packets that are discarded. If no transmission packets are available, these slots are left with gaps by the normal dispatch time assignment process. If none of the dispatch times for a transport packet indicates that the transport packet should be sent at the next available time slot of the output remultiplexer TS, data link control circuit 112 automatically inserts an empty transport packet into this time slot.

The advantages of this bandwidth optimization scheme are twofold. First, a bandwidth gain is achieved in terms of the output remultiplexed TS. The bandwidth that is normally wasted on empty transport packets is now used to transmit information. Second, best effort or bursty data can be output in the TS without specifically allocating bandwidth (or allocating much less bandwidth) thereto. For example, assume that the bandwidth of an output remultiplexed TS is 20 Mbits/sec. TS with four programs (5 Mbits/sec each) is to be remultiplexed and output to a remultiplexed TS of 20 Mbits/sec. However, approximately 5% of the bandwidth of each of the TSs with these four programs can be allocated to empty packets. In this way, transmitting transport packets with best effort or bursty data can achieve (nominally) up to 1Mbit/sec, however there is no guarantee or limitation on the constancy of the end-to-end delay.

Retiming untimed data

As described above, program data to be remultiplexed may be received via the asynchronous interface 140. Problems arise because the interface 140 and the communication link to which it is connected are not designed to send data at any particular time and will introduce variable end-to-end delays in the data being communicated. In the comparison, an assumption may be made on program data received at remultiplexer node 100 via an asynchronous communication link (such as to receive adapter 110) that all of its received transport packets are to be output without jitter. This is because all of these packets cause the same delay at the remultiplexer node 100 (i.e., an internal buffering delay), or if they do not cause the same delay (as a result of the slot contention described above), then it is known to be an additional delay, and these PCRs are adjusted to remove any jitter introduced by these additional delays. In addition, the offset of the internal clock mechanism of the PCR with respect to the system timing clock of each program is further corrected, as well as the misalignment between the scheduled output time and the actual output time of the PCR with respect to the slot boundary of the output TS. However, in the case of transmission packets received from interface 140, these transmission packets are received at the remultiplexer node 100 at a variable bit rate and at a jitter time that is not constant. Thus, if the actual time of reception of a transmission packet is used as a basis for estimating the departure of the transmission packet, jitter will remain. Not only do jittered PCRs cause decoding and presentation discontinuities at the decoder, they also cause buffer overflow and underflow. This is because the bit rate of each program is carefully adjusted (assuming that the data will be removed from the decoder buffer for decoding and presentation relative to the program's system timing clock).

According to one embodiment, these problems are overcome as follows. The processor 160 identifies the PCR of each program of the received TS. Using these PCRs, processor 160 determines the segmented transport packet rate for the transport packets for each program between the PCR pairs. Given the transmission packet rate of each (staggered) transmission packet sequence for each program, processor 160 may assign an estimated departure time based on the time at which each transmission packet should be received.

Illustratively, when the interface 140 receives program data, the received program data is transferred from the interface 140 to the packet buffer 122 of the main memory 120. Specifically, interface 140 stores received program data in some form of receive queue. Preferably, the received program data is in the form of transport packets.

The interface 140 periodically interrupts the processor 160 when data is received. The interface 140 may interrupt the processor 160 whenever any amount of data is received, or may interrupt the processor 160 after a certain amount of data is received. Such as adapter 100, is specifically designed for interface 140 to receive PID processor subroutine pointer table 402. The subroutines pointed to by these pointers are similar in many respects to the subroutines pointed to by pointers in the pointer table of the receiving PID processor subroutine associated with the receiving adapter 110. However, these subroutines differ in at least the following respects. First, the asynchronous interface 140 does not have to allocate a descriptor having the format shown in fig. 2, and also does not have to receive program data in the form of a transmission packet. For example, the program data may be PES packet data or PS packet data. In this case, the subroutine executed by the processor 160 for the PID of the reserved transport packet illustratively includes a process for inserting program data into the transport packet. Further, it may be set that a reception descriptor assigned to the queue of the adapter 140 is allocated to each received transmission packet. Processor 160 stores a pointer to the memory location of the corresponding transport packet in the pointer field 129-4 of each assigned descriptor. Illustratively, initially, the actual receive time field 129-5 is blanked.

Further, each transmission packet containing a PCR further includes the following processing. The first time a transport packet with any program's PCR is received, the processor 160 obtains a timestamp from any adapter's 110 reference clock generator 113 (or any other reference clock generator 113 that is synchronously locked to the adapter's 110 reference clock generator 113). The reference clock 113 is synchronously locked as described below. The obtained time stamp is assigned to the first once received transmission packet with a PCR of a program as the reception time of the transmission packet. Note that this first received PCR-bearing transport packet may have previously received other transport packets to be remultiplexed. The known internal buffering delay at remultiplexer node 100 may be added to this receive timestamp to generate an estimated departure time assigned to the transmitted packet, including the first once received PCR of a particular procedure.

Upon receiving a second subsequent transport packet with a PCR for a particular program, processor 160 may estimate the transport packet rate between PCRs having that program received by asynchronous interface 140. This is achieved as follows. Processor 160 forms the difference between two successive PCRs of the procedure. The processor then divides this difference by the number of transport packets in the same program between the transport packet containing the first PCR and the transport packet containing the second PCR for that program. This results in a transmission packet rate for the program. Processor 160 estimates the departure time of each transport packet of a program between the PCRs of the program by multiplying the transport packet rate of the program by the offset or deviation of each such transport packet from the transport packet containing the first PCR. The offset is determined by subtracting the transmit packet queue position of the transmit packet with the first PCR from the transmit packet queue position at which the estimated departure time is calculated. (note that the queue position of a transmission packet is relative to all received transmission packets of all received streams.) then, processor 160 adds the estimated departure time assigned to the transmission packet containing the first PCR to the product so generated. Illustratively, the processor 160 stores the estimated departure time of each such transmission packet in the field 129-10 of the descriptor pointing to them.

After assigning an estimated departure timestamp to a program's transport packets, processor 160 may discard transport packets that are not intended for output in the TS (according to user specifications). The above process is then repeated successively for each pair of successive PCRs for each program carried in the TS. The data with the descriptors of estimated departure times may then be transferred to the appropriate transmit queue during execution of the transmit PID processor subroutine by processor 160. Note that some of the initial transport packets for the program may be received before the first PCR for the program is received. For these transport packets, the transport packet rate is estimated only as the transport packet rate between the first and second PCRs of the program (even if these packets are not between the transport packets of the first and second PCRs). An estimated departure time is then determined as described above.

As with the reception of PCRs from a synchronous interface such as the adapter 110, the offset between each program clock and the local reference clock 113 used to assign estimated receive timestamps and output transport packets is corrected for PCRs received via the asynchronous interface 140. Unlike the transport packets received from the adapter 110, the transport packets received from the interface 140 do not have actual receive timestamps recorded for them. Thus, there is no reference clock for each transmitted packet from which the offset can be accurately measured. Instead, processor 160 uses a measurement of the length of the transmit queue in remultiplexer node 100 or the current delay therein to estimate the offset. Ideally, the transmit queue length should not change from a predetermined known delay in remultiplexer node 100. Any change in the length of the send queue is an indication of the offset of the reference clock generator 113 of the adapter 110 relative to the program clock of the program. Thus, processor 160 adjusts the offset measurement up or down depending on the difference between the current transmit queue length and the desired ideal transmit queue length. For example, each time a transmit descriptor is assigned to a transport packet, processor 160 measures the current transmit queue length and subtracts it from the ideal transmit queue length in remultiplexer node 100. This difference is the offset. The offsets thus calculated are used to adjust the PCRs and the estimated departure times of the transport packets carrying these PCRs. That is, the offset thus calculated is subtracted from the PCR of a transport packet received via the asynchronous interface placed in a time slot subsequent to the time slot corresponding to the estimated departure time of the transport packet. Again, this offset may be subtracted from the estimated departure time of the PCR-bearing transport packet before the actual dispatch time is assigned. Note that this estimated offset is only used for transport packets received from the asynchronous interface 140 and not for other transport packets received via the synchronous interface, such as the adapter 110.

Now consider the problem of competition. When two (or more) received transport packets compete for the same transport packet time slot (and actual dispatch time) to be assigned to the output remultiplexer TS, one transport packet is assigned to that time slot and another transport packet is assigned to the next time slot. If another transmission packet contains a PCR, the PCR is adjusted by the number of time slots that the PCR deviates from its ideal time slot to reflect the assignment to a subsequent time slot.

Auxiliary output timing

As described above, the interface 140 does not receive the transmission packet at any particular time. Likewise, interface 140 does not send a transport packet at any particular time. However, even if neither the interface 140 nor the connected communication link provides a constant end-to-end delay, it is desirable to reduce the variation of the end-to-end delay as much as possible. Remultiplexer node 100 provides a way to minimize this variation.

According to one embodiment, processor 160 allocates one transmit descriptor assigned to the transmit queue of interface 140 for each transport packet to be output via interface 140. This may use an appropriate set of transmit PID processor subroutines in a transmit queue assigned to the output port of interface 140. In addition, processor 160 assigns an adapter 110 for managing the output of data from this interface 140. Although technically the send queue is "assigned" to the interface 140, in practice, control of the descriptors of the descriptor queue assigned to the interface 140 is obtained by the DMA control circuitry 116 of the adapter 110 assigned to manage the output from the interface 140. Data link control circuitry 112 accesses these descriptors, which may be stored in cache memory 114 as described below. Thus, in effect, the set of transmit PID processor subroutines assigned to this queue and executed by processor 160 is triggered by an interrupt generated by data link control circuitry 112 examining the queue.

As described above, in response to this interrupt, processor 160 examines the descriptors to be scheduled, i.e., in the connection queue, selects one or more descriptors from those connection queues to be output from the output port of interface 140 and assigns a transmit descriptor to the selected descriptor of the connection queue located at the tail of the transmit queue for the output port of the relevant interface 140. Instead of outputting transport packets as described above, processor 160 may also collect transport packets for selected descriptors associated with a connection queue and, in effect, organize them into queue-like buffers (if such buffers are necessary for interface 140).

As described above, the DMA control circuit 116 obtains control over the sequence of one or more descriptors following the last descriptor that the DMA control circuit 116 obtained control, the sequence being associated with an output port of the interface 140. (Note that it does not matter whether transport packets corresponding to these descriptors are retrieved. since the data link control circuit 112 controls the transport packet output at the interface 140, no transport packets are output from the output interface connected to that data link interface 112. alternatively, the data link control circuit 112 may operate entirely as described above, producing a mirror (mirror) copy of the output TS. in this case, a second copy of each transport packet must also be provided that is accessible by the adapter 110). As described above, data link control circuit 112 retrieves each descriptor in cache memory 114 and determines from the indicated dispatch time recorded in field 129-5 when the corresponding transport packet is to be sent relative to the time indicated by reference clock generator 113. Approximately when the reference clock generator 113 times equal to the dispatch time, the data link control circuit 112 generates an interrupt to the processor 160 to indicate that a transmission packet should now be sent. This may be the same interrupt that data link control circuitry 112 generates when k ≧ 1 transport packet is transmitted. However, the interrupt is preferably generated every k ═ 1 transmission packet. In response, processor 160 checks the appropriate pointer table for the send PID processor subroutine and executes the correct send PID processor subroutine. When executing the send PID processor subroutine, the processor 160 issues a command or interrupt that causes the interface 140 to send a transport packet. This causes the immediately next transport packet to be sent from the output port of the interface 140 approximately when the current time of the reference clock generator 113 matches the dispatch time written in the descriptor corresponding to the transport packet. Note that some bus and interrupt latency will occur between the issuance of an interrupt by time link control circuit 112 and the output of a transport packet by interface 140. Furthermore, some latency may occur on the communication link connected to interface 140 (as it becomes busy due to collisions or the like). The average amount of latency can be accommodated to some extent by careful selection of the dispatch time of the transport packets by the processor 160. In any event, the output of the transport packet may be quite close to the correct time, even though this proximity is less than what may be achieved using the adapter 110 or the interface 150. Processor 160 also transfers one or more descriptors to a transmit queue assigned to an output port of interface 140 as described above.

Inter-adapter reference clock locking

A particular problem with any synchronous system using multiple clock generators is that the time or count of each generator is not exactly the same as the other clock generators. Even further, the count of each clock generator may deviate (e.g., as a result of manufacturing tolerances, temperature, power variations, etc.). This concern also exists in environment 10. Each remultiplexer node 100, data injector (injector)50, data extractor 60, controller 20, etc. may have a reference clock generator, such as reference clock generator 113 of adapter 110 in remultiplexer node 100. It is desirable to lock the reference clock generator of at least each node 50, 60 or 100 in the same TS signal flow path so that they have the same time.

In a broadcast environment, it is useful to synchronize all devices that generate, edit, or transmit program information. In analog broadcasting, this may use a black burst (black burst) generator or an SMPTE temporal code generator. This synchronization enables seamless splicing of real-time video feeds and reduces noise associated with coupling asynchronous video feeds together.

In the remultiplexer node 100, the need for synchronization is more important. This is because the departure of a received transport packet is scheduled according to one reference clock and the dispatch of the received transport packet is actually retrieved according to a second reference clock. It is assumed that any latency introduced by the transmission of packets in remultiplexer node 100 is the same. However, this assumption is valid only if there is only a negligible offset between the reference clock on which the estimated packet departs and the reference clock on which the transmitted packet is actually dispatched.

According to one embodiment, various techniques are provided for locking, i.e., synchronizing, the reference clock generator 113. In each technique, the time of each "slave" reference clock generator is periodically adjusted relative to the "master" reference clock generator.

According to a first technique, one reference clock generator 113 of an adapter 110 is designated as the master reference clock generator. Each other reference clock generator 113 of each other adapter 110 is designated as a slave reference clock generator. Processor 160 periodically obtains the current system time for each reference clock generator 113 (including the master reference clock generator and the slave reference clock generator). Illustratively, this is accomplished using a process of "sleeping" (i.e., idling), waking up, and having the processor 160 obtain the current time of each reference clock generator 113 for a particular period of time. The processor 160 compares the current time of each slave reference clock generator 113 with the current time of the master reference clock generator 113. Based on these comparisons, processor 160 adjusts each slave reference clock generator 113 to synchronize them with respect to the master reference clock generator 113. This adjustment may be achieved simply by reloading the reference clock generator 113, adding an adjusted time value to the system time of the reference clock generator 113, or (filtering) up or down pulses of a voltage controlled oscillator that supplies clock pulses to the counter of the reference clock generator 113. The last form of regulation is similar to the phase-locked loop feedback regulation described in the MPEG-2 system specification.

Now consider the case where the master reference clock generator and the slave reference clock generator are not in the same node but are connected by a communication link. For example, the master reference clock generator may be located in a first remultiplexer node 100 and the slave reference clock generator may be located in a second remultiplexer node 100, wherein the first and second remultiplexer nodes are connected by a communication link extending between adapters 110 of the first and second remultiplexer nodes 100. Periodically, in response to the timer process, the processor 160 issues a command to obtain the current time of the master reference clock generator 113. The adapter 100 responds by providing this current time to the processor 160. Processor 160 then transmits the current time to each of the other slave reference clocks via the communication link. The slave reference clock is then adjusted, for example, as described above.

It should be noted that any time source or time server may be used as the master reference clock generator. The time of the master reference clock generator is transmitted to each of the other nodes containing the slave reference clock via a dedicated communication link with constant end-to-end delay.

If two or more nodes 20, 40, 50, 60 or 100 of a re-branching multiplexer 30 are geographically separated by a large distance, it is not possible to synchronize the reference clock generator of each node with the reference clock generator of any other node. This is because any signal transmitted over a communication link may experience some finite propagation delay. This delay causes latency in the transmission of transport packets, particularly transport packets with synchronization timestamps. Instead, it is possible to use a reference clock source equidistant from each node of the remultiplexer 30. It is well known that the united states government maintains terrestrial and satellite reference clock generators. These sources reliably transmit time on a well-known carrier signal. Each node, such as remultiplexer node 100, may be provided with a receiver, such as GPS receiver 180, which is capable of receiving a broadcasted reference clock. The processor 160 (or other circuitry) at each node 20, 40, 50, 60 or 100 periodically obtains a reference clock from the receiver 180. The processor 160 may transfer the obtained time to the adapter 110 to be loaded into the reference clock generator 113. Preferably, however, the processor 160 issues a command to the adapter 110 to obtain the current time of the reference clock generator 113. Processor 160 then issues a command to adjust (e.g., speed up or slow down) the voltage controlled oscillator of reference clock generator 113 based on the difference between the time obtained from receiver 180 and the current time of reference clock generator 113.

Networked remultiplexing

Given the operations described above, the various functions of the remultiplexing may be distributed over a network. For example, multiple remultiplexer nodes 100 may be interconnected by various communication links, adapters 110, and interfaces 140 and 150. Each of these remultiplexer nodes 100 may be controlled by controller 20 (fig. 1) to collectively function as a single remultiplexer 30.

Such a network distributed remultiplexer 30 may be desirable for convenience or flexibility. For example, a redistribution multiplexer node 100 may be coupled to a plurality of file servers or storage devices 40 (FIG. 1). The second remultiplexer node 100 may be connected to a plurality of other input sources, such as cameras or demodulators/receivers. Each of the other remultiplexer nodes 100 may be connected to one or more transmitters/modulators or recorders. Alternatively, remultiplexer node 100 may be connected in such a way as to provide redundancy functionality and subsequent fault tolerance in the event that a remultiplexer node 100 fails or is purposefully taken out of service.

Consider the first network remultiplexer 30' shown in fig. 3. In this case, the plurality of remultiplexer nodes 100 ', 100 ", 100'" are interconnected via an asynchronous network, such as 100BASE-TX ethernet. Each of the first two remultiplexer nodes 100', 100 "receives four TSs (TS10-TS13 or TS14-TS17) and produces a single remultiplexed output TS (TS18 or TS 19). The third remultiplexer node 100' "receives the TSs (TS18 and TS19) and generates an output remultiplexed TS (TS 20). In the example shown in fig. 3, the remultiplexer node 100' "receives via its adapter 100 (fig. 2) the TSs (TS10-TS13) sent in real time from the demodulator/receiver. On the other hand, remultiplexer 100 ″ receives pre-stored TS (TS14-TS17) from a storage device via synchronization interface 150 (FIG. 2). Each of the remultiplexer nodes 100 ' and 100 "sends its respective output remultiplexer TS, TS18 or TS19, to remultiplexer node 100 '", via asynchronous (100BASE-TX ethernet) interface 140 (fig. 2) to asynchronous (100BASE-TX ethernet) interface 140 (fig. 2) of remultiplexer node 100 ' ". Advantageously, each of the remultiplexer nodes 100' and 100 "uses the auxiliary output timing techniques described above to reduce to at least the variation in end-to-end delay caused by such communications. In any case, the remultiplexer node 100' "uses the above described technique of retiming the uncorrupted data to estimate the bit rate for each of the TS18 and TS19 and to de-jitter (dejitter) the TS18 and TS 19.

Optionally, burst device 200 may also be included on at least one communication link of system 30'. For example, as in the LAN, the communication medium can be shared with other terminals for ordinary data processing. However, burst device 200 is also provided for injecting data into and/or extracting data from a TS (e.g., TS 20). For example, the burst device 200 may be a server, Web terminal, etc. that provides internet access.

Of course, this is merely one example of a network distributed remultiplexer. Other configurations are also possible. For example, the communication protocol of the network to which these nodes are connected may be TAM, DS3, or the like.

Two important properties of the network distributed remultiplexer 30' should be noted. First, in the particular network shown, any input port may receive data, such as burst data or TS data, from any output port. That is, remultiplexer node 100 'may receive data from remultiplexer node 100 "or 100'" or burst device 200, remultiplexer node 100 "may receive data from remultiplexer node 100 'or 100'" or burst device 200, remultiplexer node 100 '"may receive data from either remultiplexer 100' or 100" or burst device 200, and burst device 200 may receive data from either remultiplexer node 100 ', 100 "or 100'". Second, the remultiplexer node that performs the data extraction and discarding, i.e., remultiplexer node 100 '", may receive data from more than one source, i.e., remultiplexer 100' or 100" or burst device 200, over the same communication link.

Due to these two properties, the "signal flow pattern" of a transmission packet from a source node to a destination node within the remultiplexer is independent of the network topology to which the nodes are connected. In other words, the nodes and communication link paths traversed by the transport packets in the network distributed remultiplexer 30' are independent of the precise physical connection of the nodes through the communication links. Thus, the remultiplexer nodes 100 can be connected using a very common network topology-essentially any topology (bus, ring, chain, tree, star, etc.) that can still remultiplex TSs to achieve virtually any type of node-node signal flow pattern. For example, nodes 100 ', 100 ", 100'" and 200 are connected in a bus topology. Any of the following signal flow patterns for the transmitted data may also be implemented: from node 100 'to node 100 "and then to node 100'"; node 200 is reached in parallel from each of nodes 100 'and 100'; arriving in parallel at node 100 "from nodes 200 and 100 ', then from node 100" to node 100' ", and so on. In this type of transmission, time division multiplexing may be required to interleave signal streams between different sets of communication nodes. For example, in the signal stream shown in fig. 3, TS18 and TS19 are time-division multiplexed on a shared communication medium.

The above discussion is intended to be illustrative of the present invention. Numerous alternative embodiments may be devised by those skilled in the art without departing from the spirit and scope of the following claims.

Claims (10)

1. A method for dynamically remultiplexing at least one transport stream of transport packets, each transport packet having the same length, each transport packet having payload carrying information or system information for only a particular stream, the method comprising the steps of:

(a) extracting selected transport packets from at least one received transport stream,

(b) generating a new transport packet containing new system information not carried by the received at least one transport stream,

(c) assembling at least one of said extracted transport packets with said new transport packet containing system information into an output transport stream and outputting said output transport stream, said assembling being in accordance with a first specification of a stream to be carried in said output transport stream,

(d) receiving a request to enforce a second specification, the second specification being different from the first specification of the output transport stream, the second specification indicating a change in streams carried in the output transport stream relative to the first specification,

(e) determining whether the second specification is suitable for generating a valid output transport stream,

(f) if it is determined that the second specification is suitable for generating a valid output transport stream:

(1) selectively changing the extracted specific transport packet according to a second specification,

(2) selectively changing generation of a new transport packet to carry out the second specification, an

(3) Selectively changing the assembly of the extracted transport packet with a new transport packet from an assembly according to a first specification to an assembly according to a second specification,

thereby ensuring that the continuity of the output transport stream is seamlessly maintained when changing from extraction, generation and assembly according to the first specification to extraction, generation and assembly according to the second specification and ensuring that system information carried in the output transport stream when extracting, generating and assembly according to the first or second specification effectively references other streams carried in the output transport stream.

2. The method of claim 1, wherein the generating and assembling is performed such that when the transport packets extracted according to the first specification with the meta-information are assembled into the output transport stream according to the first specification, new system information generated according to the second specification and assembled into the output transport stream does not indicate that the output transport stream currently carries meta-information according to the second specification.

3. The method of claim 1, further comprising the step of determining that the second specification cannot be applied if it is determined that the bitrate required to transmit the output transport stream assembled in accordance with the second specification exceeds the maximum bitrate of the output transport stream.

4. The method of claim 1, further comprising:

(g) at least a portion of new system information to be generated in accordance with the second specification is determined from the system information carried in one or more of the extracted transport packets.

5. The method of claim 4, wherein the transport packet carrying at least one program definition of a program map table is extracted, and the new system information comprises at least one program definition including a new program definition derived from the at least one program definition.

6. A remultiplexer for dynamically remultiplexing at least one transport stream of transport packets, each transport packet having the same length, each transport packet having payload carrying information or system information for only a particular stream, the remultiplexer comprising:

(a) at least one adapter capable of extracting selected transport packets from at least one received transport stream,

(b) a processor capable of generating a new transport packet containing new system information not carried by the received at least one transport stream,

said at least one adapter further being capable of assembling at least one of said extracted transport packets with said new transport packet containing system information into an output transport stream and outputting said output transport stream, said assembling being in accordance with a first specification of a stream to be carried in said output transport stream,

(c) a controller capable of receiving a request to effect a second specification, the second specification being different from the first specification of the output transport stream, the second specification indicating a change in the stream carried in the output transport stream relative to the first specification, the controller further capable of determining whether the second specification is appropriate for generating a valid output transport stream,

wherein if it is determined that the second specification is suitable for producing a valid output transport stream: (1) in accordance with a second specification, the at least one adapter is further capable of selectively altering the extracted particular transport packet (2) the processor is further capable of selectively altering the generation of a new transport packet to effect the second specification; and (3) the at least one adapter is further capable of selectively changing the assembly of the extracted transport packets with new transport packets from assembly according to the first specification to assembly according to the second specification, thereby ensuring that the continuity of the output transport stream is seamlessly maintained when changing from extraction, generation and assembly according to the first specification to extraction, generation and assembly according to the second specification, and ensuring that system information carried in the output transport stream at the time of extraction, generation and assembly according to the first or second specification effectively references other streams carried in the output transport stream.

7. The remultiplexer of claim 6 wherein the generating and assembling is performed such that when transport packets extracted in accordance with a first specification with meta-information are assembled into an output transport stream in accordance with the first specification, new system information generated in accordance with a second specification and assembled into the output transport stream does not indicate that the output transport stream currently carries meta-information in accordance with the second specification.

8. The remultiplexer of claim 6 wherein the controller is further capable of determining that the second specification cannot be applied when it is determined that the bitrate required to transmit output transport streams assembled in accordance with the second specification exceeds the maximum bitrate for the output transport streams.

9. The remultiplexer of claim 6 wherein the processor is further capable of determining at least a portion of new system information to be generated in accordance with a second specification from system information carried in one or more of the extracted transport packets.

10. The remultiplexer of claim 9 wherein said at least one adapter is further capable of extracting transport packets carrying at least one program definition for a program map table, said new system information including at least one program definition, said program definition including a new program definition derived from said at least one program definition.