WO1995026596A1

WO1995026596A1 - Method for preserving the original timebase of a program in a multiplexed communications system

Info

Publication number: WO1995026596A1
Application number: PCT/US1994/007775
Authority: WO
Inventors: Anthony J. Wasilewski; Gary L. Logston
Original assignee: Scientific-Atlanta, Inc.
Priority date: 1994-03-29
Filing date: 1994-07-11
Publication date: 1995-10-05
Also published as: CA2181900A1; AU8009294A; JPH09511368A

Abstract

A method preserving an original timestamp value in a packet (70) of data to be transmitted from a transmission site to a reception site wherein the original timestamp value may require adjustment at the reception site to account for delays experienced by that packet (70) during multiplexing and/or transmission. The method comprises the steps of (a) defining at least first (88) and second (96) fields within the packet (70); (b) inserting, at the transmission site, an original timestamp value in the first field (88) of the packet (70), and thereafter not modifying the value in the first field (88); and (c) adding the value of any multiplexing or transmission delays experienced by that packet (70) to an initial value in the second field (96). At the reception site, the second field (96) will reflect any delays experienced by the packet (70) while the original timestamp value is preserved in the first field (88).

Description

METHOD FOR PRESERVING THE ORIGINAL TIMEBASE OF A PROGRAM IN A MULTIPLEXED COMMUNICATIONS SYSTEM

FIELD OF THE INVENTION

The present invention relates to digital transmission systems, and more particularly, to a method for preserving the original timebase of a digital program in a transmission system that employs an adjustable timestamp technique for performing clock recovery at a reception site.

BACKGROUND OF THE INVENTION

Recently, the International Organization for Standardization (ISO) adopted a standard protocol for combining one or more "elementary streams" of coded video, audio or other data into a single bitstream suitable for transmission. The standard, hereinafter referred to as the "MPEG-2 Systems" standard, is described in detail in the MPEG-2 Systems Committee Draft (ISO/IEC JTC1/SC29/ G11/N0601, November, 1993) [hereinafter "MPEG-2 Systems Committee Draft"] , which is hereby incorporated by reference. An overview of the MPEG-2 Systems standard is provided in Wasilewski, The MPEG-2 Systems Specification : Blueprint for Network Interoperabili ty (January 3, 1994) , which is also hereby incorporated by reference. The MPEG-2 Systems standard provides a syntax and set of semantic rules for the construction of bitstreams containing a multiplexed combination of one or more "programs." A "program" is composed of one or more related elementary streams. An

"elementary stream" is the coded representation of a single video, audio or other data stream that shares the common timebase of the program of which it is a member. For example, in the context of a subscription television system, a "program" may comprise a network television broadcast consisting of two elementary streams: a video stream and an audio stream.

As development of the MPEG-2 Systems standard progressed, a two-level packet-based multiplexing scheme emerged. At the first level, each elementary stream to be transmitted, i.e., the coded data for one video, audio or other data stream, is packetized to form a Packetized Elementary Stream (PES) . Each PES packet in a given Packetized Elementary Stream consists of a PES packet header followed by a variable length payload containing the coded data of that elementary stream. The Packetized Elementary Stream structure provides a means for packaging subparts of a longer elementary stream into consecutive packets along with associated indicators and overhead information used to synchronize the presentation of that elementary stream with other, related elementary streams (e.g., elementary streams of the same program) . Each Packetized Elementary Stream is assigned a unique Packet ID (PID) . For example, the Packetized Elementary Stream containing the coded video data for a network television program may be assigned a PID of "10"; the Packetized Elementary Stream containing the associated audio data for that program may be assigned a PID of "23", and so on.

At the second level, one or more Packetized Elementary Streams may be further segmented or "packetized" to facilitate combining those streams into a single bitstream for transmission over some medium. Ultimately, two different

"second level" protocols for combining one or more Packetized Elementary Streams into a single bitstream emerged: 1) the Program Stream (PS) protocol and 2) the Transport Stream protocol. Both stream protocols are packet-based and fall into the category of "transport layer" entities, ^'as defined by the ISO Open System Interconnection (OSI) reference model. Program Streams utilize variable-length packets and are intended for "error-free" environments in which software parsing is desired. Program Stream packets are generally relatively large (IK to 2K bytes) . Transport Streams utilize fixed length packets and are intended for transmission in noisy or errored environments . Each Transport Stream packet comprises a header portion and a payload portion. Transport Stream packets have a relatively short length of 188 bytes and include features for enhanced error resiliency and packet loss detection. The remaining background discussion will focus primarily on the MPEG-2 Transport Stream protocol.

As finally adopted, the Transport Stream protocol provides a standard format (i.e., syntax and set of semantic rules) for combining one or more Packetized Elementary Streams into a single "Transport Stream" that may then be transmitted over some medium. Figure 1 graphically illustrates the generation of an MPEG-2 Transport Stream from a plurality of Packetized Elementary Streams. As illustrated, the individual packets of each Packetized Elementary Stream are segmented and inserted into the payload sections of successive Transport Packets. For example, as illustrated in Figure 1, one of the PES packets 10 of the Packetized Elementary Stream containing the coded video of elementary stream "Video 1" is segmented and inserted into the payload sections of consecutive Transport Packets, e.g. 12 and 14. Every Transport Packet has a header, e.g., header 16 of Transport Packet 12, and the header of each Transport Packet contains the PID associated with the Packetized Elementary Stream carried in that Transport Packet . In the example illustrated in Figure 1, the Packetized Elementary Stream carrying the coded video of elementary stream "Video

1" has been assigned a PID of '10', and therefore, the header of each Transport Packet 12, 14 carrying data from that Packetized Elementary Stream will contain a PID value of '10' . Similarly, the headers of each Transport Packet 18, 20 carrying Packetized Elementary Stream data for elementary stream "Audio 1" will contain the PID assigned to that elementary stream, which in the example shown is '23' . The Transport Packets formed from each Packetized Elementary Stream are then multiplexed to form a single outgoing bitstream or "Transport Stream." Thus, a Transport Stream comprises a continuous sequence of Transport Packets, each of which may carry data from one of a plurality of Packetized Elementary Streams. At a decoder location, a given Packetized Elementary Stream can be recovered from the incoming Transport Stream by simply extracting every incoming packet whose header contains the PID assigned to that Packetized Elementary Stream. A group of related Packetized Elementary Streams (e.g. audio, video etc.) can be extracted to reproduce a complete "program. "

As the MPEG-2 Systems standard developed, the MPEG- 2 Systems Committee further decided that segmentation of each Packetized Elementary Stream into a respective sequence of Transport Packets is to be carried out by an encoder employing a common system clock that operates at a nominal frequency of 27.0 MHz. Decoders for receiving and presenting a selected program (i.e., a set of related elementary streams) will therefore need a corresponding system clock whose frequency of operation and absolute instantaneous value match those of the encoder. However, in practice, a decoder's free-running system clock frequency will rarely, if ever, match the encoder's system clock frequency exactly, and therefore, some method for synchronizing the decoder system clock with the encoder system clock is required. As the MPEG-2 Systems standard developed, participants of the MPEG-2 Systems Committee suggested that synchronization of a decoder's system clock with the encoder's system clock (sometimes also referred to hereinafter as "clock recovery") be achieved through the use of timestamps, referred to in the MPEG-2 Systems Committee Draft as Program Clock References. A Program Clock Reference (PCR) is an actual "snapshot" of the encoder's system clock. According to the technique adopted, for each program carried in a given Transport

Stream, PCR's must be generated at least once every 100ms and inserted into the Transport Packets carrying one of the elementary streams that make-up that program. For example, as illustrated in Figure 1, PCRs 24 and 26 have been inserted into Transport Packets 12 and 14, which carry Packetized Elementary Stream data for the video elementary stream, "Videol", of "Program 1". Similarly, PCRs, e.g. PCR 28, have been inserted into the Transport Packets, e.g. packet 32, carrying Packetized Elementary Stream data for the video elementary stream, "Video 21", of "Program 21".

As mentioned, for a given program, PCRs must be generated and inserted into the sequence of Transport Packets carrying one of the elementary streams of that program at least once every 100ms. Each PCR is an actual sample of the encoder system clock at the time the PCR was inserted into its respective Transport Packet, and therefore, the original PCRs inserted into the Transport Packets of a given program reflect the true timebase of that program. With such a timestamp approach, each program may have its own independent timebase, and therefore, there is no need to synchronize the timebases of different programs prior to multiplexing. Although the PCRs in the sequence of Transport

Packets carrying Packetized Elementary Stream data for a given program represent the true timebase of the program prior to any multiplexing stages, the MPEG-2 Systems Committee realized that as the Transport Packets for each elementary stream reach the Transport Stream multiplexer 22, certain packets may experience a variable delay during multiplexing since the multiplexer can only "send" one packet at a time. When a PCR bearing Transport Packet experiences a variable delay, the original PCR in that packet is no longer valid. Consequently, the transport stream multiplexer 22 must "adjust" the original PCR to account for any variable delay imposed on that packet by the multiplexer. Note, however, that constant end-to-end delays will not invalidate the PCRs in a series of Transport Packets since each Transport Packet will experience that same constant delay. One way to adjust the PCR value in a packet that experiences a variable delay, and the method ultimately adopted by the ISO, is to determine the amount of variable delay the packet experiences between the input and output of a multiplexer or other device, and then to add that delay time to the original PCR value as the packet leaves the device in the outgoing Transport Stream. As a result of this adjustment, the PCR's of a given program, no matter where they may appear in an outgoing Transport Stream, should reflect the absolute value of the encoder's system clock at the time the packets bearing those PCR's were inserted into the outgoing Transport Stream.

Figure 2 graphically illustrates the need for adjusting PCR values to account for variable delays, such as multiplexing delays. As illustrated in Figure 2, two Transport Packet sequences, each formed from a different Packetized Elementary Stream, are provided to respective inputs of a Transport Stream multiplexer 22. One sequence of Transport Packets, e.g. packets A and B, carries the Packetized Elementary Stream data of an exemplary video elementary stream, "Video 3". The other sequence of Transport Packets, e.g. Packets C and D, carries the

Packetized Elementary Stream data of an exemplary audio elementary stream, "Audio 7". As further illustrated, Transport Packets A and B in the sequence of packets for "Video 3" contain Program Clock Reference values, PCR_A and PCR_B, respectively. As explained above, each of the timestamps is a "snapshot" of the encoder system clock at the time the PCR was inserted into its respective Transport Packet of the sequence. Accordingly, a series of PCRs carried the sequence of Transport Packets formed from a particular Packetized Elementary Stream reflect the actual timebase of the single program of which that Packetized Elementary Stream is a member.

Still referring to Figure 2, assume that Transport Packets A, B and C of the respective Transport Packet sequences for "Video 3" and "Audio 7" exit the Transport

Steam multiplexer in the order A - C - B, as illustrated. In such a case, Transport Packet B has been delayed relative to Transport Packet A by an amount, AT_M. Consequently, the original timestamp, PCR_B, in Transport Packet B will no longer accurately reflect its relation in time to Transport Packet A. To compensate for such multiplexing delays or other variable delays, the MPEG-2 Systems Committee suggested that the PCR of any Transport Packet that experiences such a delay be adjusted to account for the delay. As noted above, however, in situations where all packets experience a same constant delay, no adjustment of the PCRs is necessary. However, it is unlikely in most situations that all packets will experience an exactly constant delay.

The adjustment of a PCR to compensate for a variable delay is illustrated graphically in Figure 2. As shown, the original PCR of Transport Packet B has been replaced with an adjusted value, PCR_B' . The adjusted timestamp value, PCR_B' , is obtained by adding the value of the delay, AT_M, to the original timestamp value, PCR_B. Thus, PCR_B' = PCR_B + AT_M.

It should be noted that delays other than multiplexing delays may occur during transmission of a packet from the encoder to a reception site. For example, packets transmitted through an ATM network may experience delays at various switching nodes in the network. Compensation for these delays can be handled in the same manner. At a reception site, a decoder can be used to select one of the "programs" carried in an incoming Transport Stream for output or presentation at the reception site. The PCR's carried in the Transport Packets of a single selected "program" can be used to "slave" the decoder's system clock to the encoder's system clock for purposes of decoding that program. That is, the PCRs can be used to recreate or re¬ establish the timebase of that single program as the Transport Packets carrying the elementary stream data for that program arrive at the decoder. Stated generally, the PCRs may be used to perform clock recovery in the decoder. Figure 3 illustrates a model decoder for use in selecting a given program for output at a reception site. In accordance with the timestamp technique described above, a clock generation circuit 58 in the decoder processes the PCR values carried in the Transport Packets of a selected program in order to re-establish the timebase of the selected program for decoding purposes. According to the model, an MPEG-2 Transport Stream is received by the decoder 40 and provided to a Transport Stream de-multiplexer/parsing unit 42. A user's program selection is provided to the demultiplexer 42 via line 44. When a user selects a given program for output, the demultiplexer 42 begins extracting every incoming

Transport Packet having a PID that matches one of the PIDs assigned to the elementary streams that make-up the selected program. For example, referring back to Figure 1, a subscriber may select Program 1 which consists of elementary streams "Video 1" and "Audio 1." Transport Packets carrying the Packetized Elementary Stream data for "Video 1" each have a PID of '10', and the Transport Packets carrying the Packetized Elementary Stream data for "Audio 1" each have a PID of '23' . As successive packets of the Transport Stream are received, the demultiplexer 42 will extract every incoming Transport Packet having a PID of '10' or '23' . Extracted Transport Packets will then be parsed in order to reassemble the original Packetized Elementary Streams. Ultimately, the coded video and audio data of each Packetized Elementary Stream will be provided to respective buffers 48, 54, and then to respective decoders 50, 56 which decode the data to produce analog video and audio signals for output to a display device.

Additionally, as each Transport Packet of the selected program is received, the demultiplexer 42 determines whether that Transport Packet contains a PCR. If so, the PCR is extracted from the incoming packet and provided to the clock generation circuit 58 via line 59. As explained above, it is highly unlikely that the frequency of a decoder's system clock will be exactly the same as that of the original encoder, or that the decoder's system clock will be perfectly stable (i.e, will not drift) . In accordance with the timestamp approach described herein, the PCR values, which are sent periodically in the Transport Packets of the selected program, can be used to "reproduce" or "recover" the encoder system clock in the decoder, i.e., the PCRs can be used to re-establish the timebase of the selected program. Recovery of the encoder system clock in the decoder is performed by a clock generation circuit 58. Figure 3 illustrates a model clock generation circuit that may be used in accordance with the timestamp technique described above. The model clock generation circuit 58 of Figure 3 implements a straightforward phase-lock-loop (PLL) except that the reference and feedback terms are numbers (e.g., the values of counter 66 and received PCRs) . Upon initial acquisition of a user selected program, the counter 66 is loaded via line 61 with the first PCR received for that program. Thereafter, the PLL essentially operates as a closed loop. A voltage controlled oscillator (VCO) 64 having a nominal frequency substantially equal to that of the encoder system clock provides the decoder system clock signal. As the decoder system clock runs, the clock signal increments counter 66 which therefore represents the absolute time of the decoder system clock. As shown, the value of counter 66 is continuously fed back to a subtractor unit 60. Subtractor 60 compares the counter value with subsequent PCRs as they arrive in the Transport Stream Packets. Since a PCR, when it arrives, represents the expected value of the decoder system clock at the time that PCR is received, the difference between it and the value of counter 66 may be used to drive the instantaneous frequency of the VCO 64 to either slow down or speed up the decoder clock signal, as appropriate. A low- pass filter and gain stage (LPF) 62 is applied to the difference values from the subtractor 60 to produce a smooth control signal for the VCO 64. As can be appreciated, the continuous feedback provided by counter 66 and the periodic arrival of PCR values in the Transport Stream will ensure that the decoder system clock remains slaved to the encoder system clock. Thus, for the selected program, the encoder system clock has been "reproduced" or "recovered" in the decoder, i.e., the original timebase of the single selected program has been re-established.

Applicants, on behalf of their Assignee, have been actively involved the work of the MPEG-2 Systems Committee in developing the MPEG-2 Systems standard and have contributed to various aspects of the standard. As the MPEG-2 Systems standard developed and it became apparent that the timestamp (i.e., PCR) approach described above would become part of the standard, Applicants realized that although the PCRs of each program must be adjusted during packet multiplexing to compensate for packet delays, some applications may require that the original PCR values of a given program, i.e., those found in an original sequence of Transport Packets generated by an encoder prior to multiplexing, be available at the end of a series of multiplexing stages.

For example, the original PCRs may be used by downstream devices as an absolute time reference in order to trigger other events at precise times in much the same way that SMPTE time codes are used with analog video signals. Also, users of digital VCRs are likely to want to view and record one of the "programs" in an incoming Transport Stream at the same time. It is expected that digital VCRs will store programs retrieved from an incoming Transport Stream in their original Transport Packet sequences. That is, each sequence of Transport Packets carrying one of the Packetized Elementary Streams that "make-up" a single selected program will be stored directly on the storage medium in the original consecutive order they had when first created by an encoder. Because the original sequence of Transport Packets is reestablished when the program is stored, the PCR values that were adjusted during transmission to account for multiplexing delays will no longer be valid since those delays are effectively eliminated when the original sequence of Transport Packets is reestablished. The adjusted PCRs therefore cannot be used to perform clock recovery during playback of a stored program. Rather, the original PCR values (i.e., those originally inserted into each Transport Packet by an encoder prior to any multiplexing stages) are required since the original consecutive sequence of Transport Packets has been restored. Thus, as Applicants have recognized, if multiple programs are to be transmitted to a reception site using the timestamp technique described above, wherein the timestamp values used to establish the timebase of each program are adjusted to compensate for variable packet delays during multiplexing and/or transmission, a method is needed for preserving the original, unadjusted timestamp values for those applications requiring the original values. The present invention provides such a method. Applicants, on behalf of their Assignee, formally proposed the method of the present invention for inclusion in the MPEG-2 Systems standard in a paper presented to the International Standards Organization, entitled "A REVISED Proposal For MPEG-2 Transport and Program Multiplex Syntax", MPEG 93/351 (March 29, 1993) , which is hereby incorporated by reference. A subsequent paper submitted by Applicants on behalf of their

Assignee, entitled "Proposal to Include Delta PCRs in MPEG-2 Transport Stream", MPEG 93/611 (July 1993) , further urged the ISO to adopt the method of the present invention. Ultimately, the present invention, as defined by the appended claims, was substantially adopted as part of the MPEG-2 Systems standard.

SUMMARY OF THE INVENTION

The present invention is particularly well suited for use in systems that transmit packets of information from a transmission site to a reception site wherein timestamp values are inserted into selected packets prior to transmission in order to facilitate clock recovery at a reception site, and wherein the timestamp values in each packet may require adjustment to compensate for delays experienced during multiplexing and/or transmission to the reception site. Applicants have recognized a need for a method that preserves the original timestamp value in a packet to preserve the original timebase of a single program while also providing a means for tracking any delays experienced by the packet during various multiplexing and/or transmission stages.

According to a preferred embodiment of the present invention, the method comprises the steps of (a) defining at least first and second fields within the packet; (b) inserting, at the transmission site, an original timestamp value in the first field of the packet, and thereafter not modifying the value in the first field; and (c) subsequent to performing step (b) , adding the value of any delay experienced by that packet to an initial value in the second field. At the reception site, the second field will reflect any delays experienced by the packet while the original timestamp value is preserved in the first field. In one embodiment, the second field is initialized to a value of zero prior to multiplexing and/or transmission of the packet. In an embodiment wherein the packet has a header, a payload and an adaptation field, step (a) preferably comprises defining the first and second fields in the adaptation field of the packet. According to another aspect of the invention, the adaptation field further contains first and second flags that correspond to the first and second fields, respectively, and step (a) further comprises the step of setting the first and second flags to a value indicative of the presence of the first and second fields within the adaptation field.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of the preferred embodiment, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings an embodiment that is presently preferred, it being understood, however, that the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:

Figure 1 graphically illustrates the generation of a Transport Stream from a plurality of Packetized Elementary Streams in an encoder;

Figure 2 graphically illustrates the concept of timestamp adjustment to account for multiplexing delays in a packet-based communications system;

Figure 3 is a block diagram of an exemplary decoder for recovering a selected program from an incoming Transport Stream;

Figure 4 graphically illustrates the content and arrangement of a Transport Packet in accordance with an embodiment of the present invention; Figure 5 is a flow diagram illustrating one aspect of the method of the present invention;

Figure 6 is a flow diagram illustrating further aspects of the method of the present invention;

Figure 7 is a block diagram of a device that incorporates circuitry for adjusting the PCR or DPCR field of a transport packet in accordance with the method of the present invention; and

Figure 8 is a block diagram illustrating further details of the circuitry of Figure 7.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring to the drawings wherein like numerals indicate like elements throughout, Figure 4 illustrates the general content and arrangement of a Transport Packet 70, and more particularly, illustrates details of the content and arrangement of an "adaptation field" 74 of the Transport Packet 70 in accordance with an embodiment of the present invention. It should be noted that the content and arrangement of an adaptation field of an MPEG-2 Transport Packet, as specified in the aforementioned MPEG-2 Systems Committee Draft, while similar, is not identical to that illustrated in Figure 4. As shown in Figure 4, the Transport Packet 70 comprises a header portion 76, a payload section 72, and the "adaptation field" 74 mentioned above. The Transport Packet header 76 contains a Packet ID (PID) and other transport- related information (not shown) . One field in the header (not shown) is used to indicate whether the packet contains an adaptation field 74. As originally proposed by others and ultimately adopted as part of the MPEG-2 Systems standard, an adaptation field may be "opened" in any Transport Packet to provide a convenience "window" for carrying both MPEG-related and private information of relevance to either the Transport Stream or the elementary stream data carried in the payload section of that Transport Packet. When present, an adaptation field 74 may contain a number of fields and flags. According to the present invention, a first field

88 may be defined within the adaptation field 74 of a Transport Packet 70 to implement a PCR segment for carrying a PCR value within the Transport Packet 70. As explained above, however, not all Transport Packets in a given Transport Stream will contain a PCR value, and therefore, a

PCR flag 82 may be used to indicate the presence or absence of a PCR segment 88 within the adaptation field 74. Although the PCR segment 88 may have any suitable format without deviating from the spirit and scope of the present invention, the MPEG-2 Systems Committee settled on a PCR format comprising a thirty-three bit base component and a nine bit extension component. Accordingly, as illustrated in Figure 4, the PCR segment 88 preferably comprises a thirty-three bit base field 90 and a nine bit extension field 94. As further specified by the MPEG-2 Systems Committee, the nine bits of the PCR extension 94 implement a modulo 300 counter that increments at a rate of 27 MHz. At each modulo 300 "rollover", the count in the thirty-three bit base portion 90 is incremented. The base portion 90 of the PCR segment therefore represents a 90 KHz clock rate. As explained above, a PCR is an actual "snapshot" of the encoder system clock at the time the PCR was inserted into the Transport Packet. In particular, as ultimately defined in the MPEG-2 Systems Committee Draft, a PCR value indicates the value of the encoder system clock at the time the byte containing the last bit of the PCR base portion 90 was inserted into the Transport Packet. Stated otherwise, in an incoming Transport Stream, the value of a PCR represents the intended time of arrival of the byte containing the last bit of the PCR base portion 90.

As explained above, in order to provide accurate timebase recovery during reception of a transmitted program, the PCR values carried in the Transport Packets of that program must be adjusted at every multiplexing stage in the transmission system to compensate for any multiplexing delays imposed by a multiplexer. However, as Applicants have recognized, it may also be necessary in some applications to preserve the original PCR values for use by the decoder. The present invention satisfies this need by providing a mechanism for adjusting PCRs values to account for multiplexing delays while at the same time preserving the original PCR values.

According to the present invention, as illustrated in Figure 4, a second field 96 may be defined within the adaptation field 74 in order to implement a Delta_PCR (DPCR) segment . A DPCR flag 84 may be provided for indicating the presence of a DPCR segment 96 within the adaptation field. According to the present embodiment, the DPCR segment 96 has a structure similar to the PCR segment 88 and comprises a twenty-bit base component 98 and a nine bit extension component 100. The DPCR base 98 represents a 90 KHz clock component, and the DPCR extension 100 represents a 27 MHz clock component. With a 90 KHz clock frequency, the twenty- bit DPCR base field 98 can accumulate approximately 11.5 seconds of delay before rolling-over. If a greater amount of accumulated delay is expected, the DPCR base field 98 can be made larger. For example, the DPCR base field 98 can have the same 33-bit format as the PCR base field 90. Further in accordance wit 'the present invention, the PCR segment 88 in an adaptation field further comprises a PCR modify flag 92. The PCR modify flag 92 is used to inform a multiplexer (e.g., multiplexer 22 of Figures 1 and 2) that the PCR base and extension fields 90, 94 cannot be modified. Although not shown in detail, an adaptation field 74 may also contain other fields. For example, an adaptation field 74 may contain an 8-bit length field 78 for specifying the overall length, in bytes, of the adaptation field 74. Any number of other fields (not shown) may also be defined within the adaptation field 74, and corresponding flags 86 may be used to indicate the presence or absence of these fields in a particular Transport Packet, in much the same way that the PCR and DPCR flags 82, 84 are used to indicate the presence or absence of the PCR and DPCR segments 88, 96 of the present invention.

According to the method of the present invention, when it is desired to preserve the original PCR value in a Transport Packet 70 while also providing a means for tracking any variable delays experienced by the packet during multiplexing or transmission, an encoder sets the PCR and DPCR flags 82, 84 in the adaptation field 74 of the Transport Packet 70 to define a PCR segment 88 (first field) and a DPCR segment 96 (second field) within the adaptation field 74. Prior to multiplexing, the encoder generates an original PCR (i.e., timestamp) from the encoder system clock and inserts the original PCR into the base and extension fields 90, 94 of the PCR segment 88. The PCR modify flag 92 is then set to inform subsequent multiplexing stages or other downstream devices that the PCR base and extension fields 90, 94 may not be modified. As the Transport Packet 70 progresses through various multiplexing stages and other devices in the communications system, the DPCR segment 96 is used to maintain an accumulation of the delays imposed on the packet at such devices. Specifically, whenever a multiplexing stage or other device imposes a variable delay on the Transport Packet 70, a value representing the magnitude of the delay is added to the current value in the DPCR segment 96. Each multiplexing stage or other device will have a local system clock operating at a nominal frequency of 27 MHz, the nominal frequency of the encoder's system clock. The delay, ΔT_M, imposed upon the Transport Packet 70 at a given multiplexing stage or other device may be calculated as follows:

ΔT_M = LSCR(t_out) - LSCR(t_in) - D where,

LSCR(t_out) is the value of the local system clock of the multiplexer when the Transport Packet reaches the output of the multiplexer;

LSCR(t_in) is the value of the local system clock when the Transport Packet enters the multiplexer; and D is a pre-determined constant delay that is imposed on all Transport Packets as they pass through the multiplexer.

Once calculated, the measured delay, ΔT_M, may be added to the current value of the accumulated delay in the DPCR segment 96. Because the accumulated value in the DPCR segment 96 comprises a 20-bit base component representing a 90 KHz clock frequency, and a 9-bit extension component representing a 27

MHz clock frequency, the delay measured at a multiplexer stage, ΔT_M, must be converted to the base/extension format before adding the value to the current accumulation in the

DPCR segment. Conversion can be performed in the following manner:

ΔT_M (base ) = int [Δ T_M/ 3 00 ]

Δ T_M (extension) = Δ T_M - ΔT_M (base) where ,

ΔT_M is the delay value prior to conversion;

ΔT_M(base) is the 20-bit base component of the delay value after conversion; and

ΔT_M(extension) is the 9-bit extension component of the delay value after conversion.

At a decoder, the accumulated delay value in the PPCR segment

96 may be added to the original PCR value in the PCR segment

88 to obtain an adjusted PCR value. In this manner, the original PCR value may be preserved in the PCR segment 88. Figure 5 is a flow diagram illustrating a number of steps to be performed by an encoder during generation of Transport Packets in accordance with the method of the present invention. During generation of a Transport Packet, the encoder will determine whether the Transport Packet is to carry a timestamp (PCR) , as shown at step 110. If so, an adaptation field is established within the Transport Packet at step 111, and control then passes to step 112. The presence of an adaptation field may be established by setting an appropriate bit in the header of the Transport Packet. At step 112, the encoder determines whether the original PCR should be preserved. Whether the original PCR should be preserved depends on the application, and the decision at step 112 will normally be pre-programmed in the encoder. When there is no need to preserve the original PCR, control passes to step 114 where the encoder sets the PCR flag in the adaptation field to establish a PCR segment. At step 116, the encoder generates an appropriate PCR value and inserts the PCR value into the PCR segment. As explained above, a PCR represents an actual sample or "snapshot" of the encoder system clock at the time the PCR is inserted into the PCR segment of the Transport Packet. At step 118, the PCR modify flag in the PCR segment is set to inform subsequent multiplexing stages that the PCR value in the PCR base and extension fields may be modified directly. That is, any delays measured at subsequent multiplexing stages may be added directly to the value in the PCR segment. Consequently, the original PCR value is not preserved in this case. If, however, at step 112 it is determined that the original PCR value should be preserved, control will pass to step 120 where the PCR and DPCR flags in the adaptation field are each set to establish both PCR and DPCR segments. At step 122, the encoder generates an appropriate PCR value and inserts the PCR value into the PCR segment. The PCR modify flag is then set to a value of '0' at step 124 to indicate that the PCR segment may not be modified by any downstream multiplexers or other devices. At step 126, the base and extension fields of the DPCR segment are initialized to a value of zero. Further processing of the Transport Packet may then continue as required. Figure 6 is a flow diagram illustrating the steps that are performed at each multiplexing stage (or other device that imposes variable delays) in accordance with the method of the present invention. As a Transport Packet is received by the multiplexer, the multiplexer examines the Transport Packet header to determine if an adaptation field is present in the packet, as shown at step 130. If an adaptation field is present, then control passes to step 132 where the multiplexer examines the PCR flag to determine whether a PCR segment is present in the adaptation field. If a PCR segment is present, then the multiplexer examines the PCR modify flag at step 134. If the PCR modify flag indicates that the PCR base and extension fields may be modified (i.e., PCR Modify Flag = '1') , then control passes to step 136. At step 136, after inserting the Transport Packet in a position within the outgoing multiplexed data stream, the multiplexer determines the amount of delay, ΔT_M, imposed upon the packet during the multiplexing operation. The delay may be calculated as described above. At step 138, the measured delay is converted to the base/extension format of the PCR segment. At step 140, the current value in the PCR base and extension fields, PCR_current, is adjusted by adding the measured delay value, ΔT_M, to the current value. The Transport Packet then exits the multiplexer in the outgoing multiplexed data stream. In this case, the original PCR value is not preserved.

If at step 134, it is determined that the PCR modify flag is set to '0', indicating that the PCR base and extension fields may not be modified, then control passes to step 142 where the multiplexer determines whether a DPCR segment has been provided in the adaptation layer. If no DPCR segment is provided, then the multiplexer simply allows the Transport Packet to exit the multiplexer without tracking the delay imposed on that packet. Of course, the original PCR value is still present in the PCR segment. This case will only occur in applications in which delay tracking is not required at all, and only the original PCR value is needed.

If a DPCR segment is provided in the adaptation field, then at step 144, after inserting the Transport Packet in a position within the outgoing multiplexed data stream, the multiplexer determines the amount of delay, ΔT_M, imposed upon the packet during the multiplexing operation. At step 146, the measured delay is converted to the base/extension format of the DPCR segment. At step 148, the current accumulated delay value in the DPCR base and extension fields, DPCR_cur--_ent, is adjusted by adding the measured delay value, ΔT_M, to the current value. The Transport Packet then exits the multiplexer in the outgoing multiplexed data stream. In this case, the original PCR value is preserved in the PCR segment while at the same time, an accumulation of the multiplexing delays imposed on the Transport Packet is maintained in the DPCR segment. As explained above, if an adjusted PCR value is ultimately needed, the value in the DPCR segment can always be added to the original PCR value at that time without destroying the original PCR value for other applications.

Figure 7 is a block diagram of a device 150, such as a multiplexing stage, that incorporates circuitry for adjusting the PCR or DPCR field of a transport packet to reflect a variable delay imposed on that packet as it passes through the device 150. In particular, the circuitry described hereinafter may be employed to implement steps 144- 148 and 136-140 of Figure 6. As shown in Figure 7, the circuitry comprises a first PCR/DPCR modifier module 154 connected to the input 152 of the device 150, and a second PCR/DPCR modifier module 154' connected at the output 160 of the device. The circuitry of the particular device 150, which is assumed to impose a variable delay on the Transport Packet as it passes through the device 150, is represented by block 156. A local system clock signal provided on line 164, which operates at a nominal frequency of 27 MHz, drives a local system clock reference counter 162 that increments at each cycle of the system clock signal. Thus, the value in the counter 162 represents the absolute value of the local system clock. The value of the local system clock reference counter 162 is provided on line 166 to both PCR/DPCR modifier modules 154, 154' . In the present embodiment, the value of the system clock reference counter 166 is provided to the

PCR/DPCR modifier modules 154, 154' in the 33-bit base/9-bit extension format described above.

A Transport Packet enters the device 150 at input 152 and passes directly to the input 154a of the first PCR/DPCR modifier module 154. As described hereinafter in greater detail, assuming that PCR/DPCR adjustment is enabled, the PCR/DPCR modifier circuit 154 subtracts the value of the local system clock reference counter 162 from either the PCR segment (when the original program clock reference is not to be preserved) or the DPCR segment (when the original program clock reference is to be preserved) . The result of the subtraction is then inserted in place of the previous value in the appropriate PCR or DPCR segment as the Transport Packet leaves the module 154. The Transport Packet then passes through the internal circuitry (block 156) of the device 150 where the packet is assumed to experience a variable delay. As the Transport Packet is passing through the device 150, the local system clock reference counter 162 is incrementing at each cycle of the local system clock signal.

Before exiting the device 150, the Transport Packet passes through the second PCR/DPCR modifier module 154' . As explained hereinafter in greater detail, the second PCR/DPCR modifier module 154' adds the updated value of the local system clock reference counter 162 to the PCR (original PCR not preserved) or DPCR (original PCR preserved) segment of the Transport Packet under consideration. The result is copied over the value the segment had upon entering the second module 154' . As a result of this addition step, the new value in the particular segment (PCR or DPCR) will be equal to the value the Transport Packet contained upon entering the device 150 plus the value of the variable delay the Transport Packet experienced upon passing through the device.

As an example, assume a Transport Packet enters the device and that the original PCR value is to be preserved and any variable delay is to be accumulated in the DPCR segment of the Transport Packet. Upon entering the device 150, the DPCR segment has an initial value, DPCR_ιn. Upon exiting the first PCR/DPCR module 154, the DPCR segment will have a modified value, DPCR--,-._d, equal to its initial value, DPCR_ιn, minus the value of the local system clock reference,

LSCR(t_ιn) , at the time the packet entered the first module 154. Thus,

DPCR^a = DPCR_ιn - LSCR(t_ιn) . While the transport packet is passing through the device 150, the local system clock reference counter 162 is updating at a rate of 27MHz. Before exiting the device 150, the transport packet .will pass through the second module 154' which will add the updated value of the local system clock reference, LSCR(t_out) , to the modified DPCR value, DPCR,^, to produce an adjusted value, DPCR_ad;ι, that reflects the variable delay imposed on the Transport Packet as it passed through the device 150. That is,

DPCR_ad:) = DPCR^ + LSCR(t_out)

= (DPCR_ιn - LSCR(t_ιn)) + LSCR(t_out) = DPCR_ιn + (LSCR(t_out) - LSCR(t_ιn) ) where, LSCR(t_out) -LSCR(t_ιn) represents the variable delay, ΔT_D, imposed by the device 150. In cases where the original program clock reference does not have to be preserved, the foregoing operations could be performed directly on the PCR segment of the transport packet.

Figure 8 is a block diagram illustrating details of a PCR/DPCR modifier module that may be used to implement both of the modules 154 and 154' of Figure 7. As shown, the module has an input 167a for receiving a Transport Packet of an incoming Transport Stream. Input 167a forms inputs 154a and 154a' of the respective modules 154, 154' of Figure 7. A Transport Packet entering the module 167 via line 167a is provided to a stream parser 168, a PCR/DPCR extraction module 174 and a data pipeline 178. When PCR/DPCR adjustment is to be performed, an appropriate signal is provided via line 170 to enable the stream parser 168. Once enabled, the stream parser 168 parses the header of the incoming Transport Packet to determine first whether the Transport Packet contains an adaptation field (step 130 of Figure 6) . If so, the stream parser examines the PCR flag in the adaptation field (step 132) . If the PCR flag indicates that a PCR segment is present in the adaptation field of the Transport Packet, the stream parser then examines the PCR modify flag in the PCR segment (step 134) . Recall from the description of Figure 6 that if the PCR modify flag is set, then the PCR segment can be adjusted directly, i.e., the original PCR is not preserved. If, however, the PCR modify flag is not set, then the PCR segment cannot be modified, and the stream parser 168 then determines whether a DPCR segment is present. If so, then the DPCR segment is to be modified.

Once the appropriate segment (PCR or DPCR) has been identified for modification, the stream parser 168 provides an appropriate signal to the PCR/DPCR extraction unit 174 which extracts the appropriate segment . The present example assumes that both the PCR and DPCR segments have the 33-bit base/9-bit extension format. As mentioned above, however, the DPCR segment can be smaller if desired. The extracted PCR or DPCR is provided to one input of an adder/subtractor unit 176. The local system clock reference, LCSR, is provided to the other input of the adder/subtractor unit 176. The adder/subtractor unit 176 can be set, via a "mode" input 182, to perform either addition or subtraction. When the module 167 is used to implement the first module 154 of Figure 7, the mode is set for subtraction. When the module 167 is used to implement the second module 154' of Figure 7, the mode is set for addition. The result of the addition or subtraction is provided via line 184 to one input of a multiplexer 180. The other input of the multiplexer receives Transport Packet data from the data pipeline 178 via line 186. The multiplexer output is controlled by the multiplex control signal provided on line 172 from the stream parser 168.

The data pipeline 178 receives the Transport Packet on line 167a and delays the propagation of the Transport Packet, if necessary, for a sufficient amount of time to allow the addition/subtraction to be performed by the adder/subtractor unit 176. Initially, line 186 is selected for output from the multiplexer 180, and therefore, the data of the Transport Packet begins to pass through the multiplexer to output line 188. As the segment to be modified (PCR or DPCR) reaches the input of the multiplexer 180, the output of the multiplexer 180 is switched to line 184 so that the modified value replaces the previous segment value. Once the modified data for the PCR/DPCR segment has passed through the multiplexer, the output of the multiplexer switches back to line 186 in order to output the remainder of the Transport Packet on line 188. Thus, the multiplexer 180 serves as a drop-add multiplexer to replace the value of the PCR or DPCR segment in the received Transport Packet with the result of the addition/subtraction operation. The module 167 operates as described above on each successive Transport Packet of an incoming Transport Stream.

As the foregoing illustrates, the present invention is directed to a method for preserving the original timestamp in a packet of data while maintaining, if desired, an accumulation of any multiplexing delays imposed on the packet at various stages of a multiplexed digital transmission system. In a system that relies on timestamp values to establish the timebase of a digital program in a decoder, the present invention provides a means for preserving the original timebase of that single program. It is understood, however, that changes may be made to the embodiments described above without departing from the broad inventive concepts thereof. For example, while the method of the present invention is particularly well suited for tracking multiplexing delays, the same method may be used at other downstream devices, such as network switching nodes, to accumulate delays imposed by those devices. Accordingly, this invention is not limited to the particular embodiments disclosed, but is intended to cover all modifications that are within the scope and spirit of the invention as defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. In a system for transmitting packets of information from a transmission site to a reception site wherein timestamp values are inserted into selected packets prior to transmission in order to facilitate clock recovery at a reception site, the timestamp values inserted into the selected packets at the transmission site defining original timestamp values, and further wherein the original timestamp value in a given packet may require adjustment at the reception site to account for delays experienced by that packet, a method of preserving the original timestamp value of a packet for use at the reception site, said method comprising the steps of:

(a) defining at least first and second fields within the packet;

(b) inserting, at the transmission site, an original timestamp value in the first field of the packet, and thereafter not modifying the value in the first field; and (c) subsequent to performing step (b) , adding the value of a delay experienced by that packet to an initial value in the second field, whereby the original timestamp value in the first field is preserved for use at the reception site and the value in the second field may be used, if necessary, to compensate for the delay experienced by the packet .

2. The method of claim 1 further comprising the step of initializing the second field of the packet to a value of zero, whereby said initial value is zero.

3. The method of claim 1 wherein the packet has a header, a payload and an adaptation field, and further wherein step (a) comprises defining said first and second fields in the adaptation field of the packet.

4. The method of claim 3 wherein the adaptation field further contains first and second flags corresponding to first and second fields, respectively, and wherein step (a) further comprises the step of setting the first and second flags to a value indicative of the presence of said first and second fields within the adaptation field.

5. In a multiplexed communications system for transmitting packets of information from a transmission site to a reception site wherein timestamp values are inserted into selected packets prior to multiplexing and transmission in order to facilitate clock recovery at a reception site, the timestamp values inserted into the selected packets at the transmission site defining original timestamp values, and further wherein the original timestamp value in a given packet may require adjustment to account for delays experienced by that packet during multiplexing and transmission, a method of preserving the original timestamp value of a packet for use at the reception site, said method comprising the steps of:

(a) defining at least first and second fields within the packet;

(b) inserting, at the transmission site, prior to multiplexing and transmission, an original timestamp value in the first field of the packet, and thereafter not modifying the value in the first field; and

(c) during multiplexing and transmission of the packet to the reception site, adding the value of any delay experienced by the packet to an initial value in the second field, whereby the original timestamp value in the first field is preserved for use at the reception site and the value in the second field may be used, if necessary, to compensate for any delays experienced by the packet during multiplexing and transmission.

6. The method of claim 5 further comprising the step of initializing the second field of the packet to a value of zero, whereby said initial value is zero.

7. The method of claim 5 wherein the packet has a header, a payload and an adaptation field, and further wherein step (a) comprises defining said first and second fields in the adaptation field of the packet.

8. The method of claim 7 wherein the adaptation field further contains first and second flags corresponding to first and second fields, respectively, and wherein step (a) further comprises the step of setting the first and second flags to a value indicative of the presence of said first and second fields within the adaptation field.