WO1995026596A1 - Procede pour preserver la base de temps d'origine d'un programme dans un systeme de communication multiplexe - Google Patents

Procede pour preserver la base de temps d'origine d'un programme dans un systeme de communication multiplexe Download PDF

Info

Publication number
WO1995026596A1
WO1995026596A1 PCT/US1994/007775 US9407775W WO9526596A1 WO 1995026596 A1 WO1995026596 A1 WO 1995026596A1 US 9407775 W US9407775 W US 9407775W WO 9526596 A1 WO9526596 A1 WO 9526596A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
value
pcr
field
transport
Prior art date
Application number
PCT/US1994/007775
Other languages
English (en)
Inventor
Anthony J. Wasilewski
Gary L. Logston
Original Assignee
Scientific-Atlanta, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Scientific-Atlanta, Inc. filed Critical Scientific-Atlanta, Inc.
Priority to AU80092/94A priority Critical patent/AU8009294A/en
Priority to JP7525141A priority patent/JPH09511368A/ja
Publication of WO1995026596A1 publication Critical patent/WO1995026596A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/062—Synchronisation of signals having the same nominal but fluctuating bit rates, e.g. using buffers
    • H04J3/0632—Synchronisation of packets and cells, e.g. transmission of voice via a packet network, circuit emulation service [CES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64307—ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64784—Data processing by the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478—Provisions for broadband connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5614—User Network Interface
    • H04L2012/5616—Terminal equipment, e.g. codecs, synch.
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
    • H04L2012/5649—Cell delay or jitter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
    • H04L2012/5652—Cell construction, e.g. including header, packetisation, depacketisation, assembly, reassembly

Definitions

  • 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.
  • the International Organization for Standardization 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.
  • “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.
  • a "program” may comprise a network television broadcast consisting of two elementary streams: a video stream and an audio stream.
  • each elementary stream to be transmitted i.e., the coded data for one video, audio or other data stream
  • PES Packetized Elementary Stream
  • 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) .
  • PID Packet ID
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • the Packetized Elementary Stream carrying the coded video of elementary stream "Video
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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".
  • 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".
  • 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.
  • each program may have its own independent timebase, and therefore, there is no need to synchronize the timebases of different programs prior to multiplexing.
  • 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.
  • the transport stream multiplexer 22 must "adjust" the original PCR to account for any variable delay imposed on that packet by the multiplexer.
  • the PCR's of a given program 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.
  • FIG. 2 graphically illustrates the need for adjusting PCR values to account for variable delays, such as multiplexing delays.
  • 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
  • Transport Packets A and B in the sequence of packets for "Video 3" contain Program Clock Reference values, PCR A and PCR B , respectively.
  • 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.
  • 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.
  • PCR B ' PCR B + AT M .
  • delays other than multiplexing delays may occur during transmission of a packet from the encoder to a reception site.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the demultiplexer 42 begins extracting every incoming program
  • 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.
  • 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.
  • 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) .
  • 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) .
  • PLL phase-lock-loop
  • the counter 66 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.
  • 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.
  • LPF low- pass filter and gain stage
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second field will reflect any delays experienced by the packet while the original timestamp value is preserved in the first field.
  • the second field is initialized to a value of zero prior to multiplexing and/or transmission of the packet.
  • step (a) preferably comprises defining the first and second fields in the adaptation field of the packet.
  • 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.
  • 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.
  • Figure 8 is a block diagram illustrating further details of the circuitry of Figure 7.
  • 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) .
  • PID Packet ID
  • One field in the header (not shown) is used to indicate whether the packet contains an adaptation field 74.
  • 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.
  • an adaptation field 74 may contain a number of fields and flags. According to the present invention, a first field
  • a Transport Packet 70 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.
  • 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.
  • 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.
  • a PCR is an actual "snapshot" of the encoder system clock at the time the PCR was inserted into the Transport Packet.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the DPCR base field 98 can be made larger.
  • the DPCR base field 98 can have the same 33-bit format as the PCR base field 90.
  • 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.
  • an adaptation field 74 may also contain other fields.
  • 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 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.
  • an encoder 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.
  • the encoder 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.
  • 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
  • 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.
  • 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
  • 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 is the delay value prior to conversion
  • ⁇ T M (base) is the 20-bit base component of the delay value after conversion
  • ⁇ T M (extension) is the 9-bit extension component of the delay value after conversion.
  • FIG. 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.
  • 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.
  • the encoder determines whether the original PCR should be preserved.
  • step 112 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.
  • control passes to step 114 where the encoder sets the PCR flag in the adaptation field to establish a PCR segment.
  • the encoder generates an appropriate PCR value and inserts the PCR value into the PCR segment.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 126 the base and extension fields of the DPCR segment are initialized to a value of zero.
  • FIG. 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.
  • 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.
  • 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.
  • the measured delay is converted to the base/extension format of the PCR segment.
  • 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.
  • step 134 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.
  • the multiplexer determines the amount of delay, ⁇ T M , imposed upon the packet during the multiplexing operation.
  • the measured delay is converted to the base/extension format of the DPCR segment.
  • 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.
  • 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.
  • 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.
  • the circuitry described hereinafter may be employed to implement steps 144- 148 and 136-140 of Figure 6.
  • 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.
  • 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' .
  • 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.
  • 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.
  • the local system clock reference counter 162 is incrementing at each cycle of the local system clock signal.
  • the Transport Packet passes through the second PCR/DPCR modifier module 154' .
  • 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' .
  • 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.
  • the DPCR segment 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,
  • DPCR ⁇ a DPCR ⁇ n - LSCR(t ⁇ n ) .
  • the local system clock reference counter 162 is updating at a rate of 27MHz.
  • 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,
  • FIG 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.
  • 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.
  • an appropriate signal is provided via line 170 to enable the stream parser 168.
  • 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.
  • 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.
  • the mode is set for subtraction.
  • 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.
  • 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.
  • the segment to be modified PCR or DPCR
  • the output of the multiplexer switches back to line 186 in order to output the remainder of the Transport Packet on line 188.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention concerne un procédé pour conserver l'horodatage d'origine dans un paquet (70) de données transmises d'un point de transmission vers un point de réception, où l'horodatage d'origine peut nécessiter un ajustement au point de réception pour tenir compte des retards subis par ce paquet (70) durant le multiplexage et/ou la transmission. Le procédé consiste à: (a) définir au moins un premier champ (88) et un second champ (96) dans le paquet (70); (b) à insérer, au point de transmission, une valeur d'horodatage d'origine dans le premier champ (88) du paquet (70) et à ne plus modifier ensuite la valeur dans le premier champ (88); et (c) à ajouter la valeur de tout retard de multiplexage ou de transport subi par ce paquet (70) à une valeur initiale dans la second champ (96). Au point de réception, le second champ (96) va inclure tout retard subi par le paquet (70), pendant que la valeur de l'horodatage d'origine est conservée dans le premier champ.
PCT/US1994/007775 1994-03-29 1994-07-11 Procede pour preserver la base de temps d'origine d'un programme dans un systeme de communication multiplexe WO1995026596A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU80092/94A AU8009294A (en) 1994-03-29 1994-07-11 Method for preserving the original timebase of a program in a multiplexed communications system
JP7525141A JPH09511368A (ja) 1994-03-29 1994-07-11 多重化通信システムにおいてプログラムの原タイムベースを保存するための方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US21965294A 1994-03-29 1994-03-29
US219,652 1994-03-29

Publications (1)

Publication Number Publication Date
WO1995026596A1 true WO1995026596A1 (fr) 1995-10-05

Family

ID=22820161

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1994/007775 WO1995026596A1 (fr) 1994-03-29 1994-07-11 Procede pour preserver la base de temps d'origine d'un programme dans un systeme de communication multiplexe

Country Status (4)

Country Link
JP (1) JPH09511368A (fr)
AU (1) AU8009294A (fr)
CA (1) CA2181900A1 (fr)
WO (1) WO1995026596A1 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996025989A2 (fr) * 1995-02-24 1996-08-29 Velocity, Inc. Procede et appareil permettant de reduire au minimum l'impact des retards sur les reseaux informatiques
GB2305080A (en) * 1995-09-11 1997-03-26 Nat Transcommunications Ltd Compensating for delays in a multiplexer
EP0843486A2 (fr) * 1996-11-14 1998-05-20 Robert Bosch Gmbh Méthode de mise à jour de références de temps dans un flux de données numériques et rémultiplexage
EP0912065A2 (fr) * 1997-10-27 1999-04-28 Nds Limited Méthode et dispositif de résynchronisation d'un signal numérique
WO1999045473A1 (fr) * 1998-03-02 1999-09-10 Deutsche Thomson-Brandt Gmbh Procede et dispositif pour traiter des paquets de donnees reçus ou transmis via une voie de donnees
WO2002032116A1 (fr) * 2000-10-11 2002-04-18 Sony Electronics Inc. Mecanisme de synchronisation adaptatif pour decodeur video numerique
EP1223689A1 (fr) * 2000-12-21 2002-07-17 Alcatel Espana, S.A. Méthode de correction de l'horloge de référence dans la liaison descendante d'un système de communication par satellite du type multi-faisceaux et fonctionnant en mode rafale multiplexé
EP1471745A1 (fr) * 2003-03-31 2004-10-27 Sony United Kingdom Limited Synchronisation Video
EP1618396A1 (fr) * 2003-05-01 2006-01-25 Tut Systems, Inc. Procede et appareil permettant de mesurer la qualite des parametres de service de reseaux distribuant des images video mpeg en temps reel
US7123306B1 (en) 1999-09-06 2006-10-17 Matsushita Electric Industrial Co., Ltd. Data transmitter and data receiver
US7251686B1 (en) * 1999-04-16 2007-07-31 Minolta Co., Ltd. Apparatus management unit and system for determining the validity of data/mail based on its expiration date and/or time
US7890048B1 (en) 1997-11-11 2011-02-15 Sony Corporation Transmitter and transmitting method, information editor and editing method, receiver and receiving method, information storage and storing method, and broadcasting system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4894823A (en) * 1986-02-28 1990-01-16 American Telephone And Telegraph Company Time stamping for packet system nodes
US5115431A (en) * 1990-09-28 1992-05-19 Stratacom, Inc. Method and apparatus for packet communications signaling
US5255291A (en) * 1988-11-14 1993-10-19 Stratacom, Inc. Microprocessor based packet isochronous clocking transmission system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4894823A (en) * 1986-02-28 1990-01-16 American Telephone And Telegraph Company Time stamping for packet system nodes
US5255291A (en) * 1988-11-14 1993-10-19 Stratacom, Inc. Microprocessor based packet isochronous clocking transmission system and method
US5115431A (en) * 1990-09-28 1992-05-19 Stratacom, Inc. Method and apparatus for packet communications signaling

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996025989A3 (fr) * 1995-02-24 1996-09-26 Velocity Inc Procede et appareil permettant de reduire au minimum l'impact des retards sur les reseaux informatiques
WO1996025989A2 (fr) * 1995-02-24 1996-08-29 Velocity, Inc. Procede et appareil permettant de reduire au minimum l'impact des retards sur les reseaux informatiques
GB2305080A (en) * 1995-09-11 1997-03-26 Nat Transcommunications Ltd Compensating for delays in a multiplexer
EP0843486A2 (fr) * 1996-11-14 1998-05-20 Robert Bosch Gmbh Méthode de mise à jour de références de temps dans un flux de données numériques et rémultiplexage
EP0843486A3 (fr) * 1996-11-14 2001-05-02 Robert Bosch Gmbh Méthode de mise à jour de références de temps dans un flux de données numériques et rémultiplexage
EP0912065A2 (fr) * 1997-10-27 1999-04-28 Nds Limited Méthode et dispositif de résynchronisation d'un signal numérique
EP0912065A3 (fr) * 1997-10-27 2002-06-12 Tandberg Television ASA Méthode et dispositif de résynchronisation d'un signal numérique
US7890048B1 (en) 1997-11-11 2011-02-15 Sony Corporation Transmitter and transmitting method, information editor and editing method, receiver and receiving method, information storage and storing method, and broadcasting system
US8260275B2 (en) 1997-11-11 2012-09-04 Sony Corporation Data transmitting apparatus and method
US8229348B2 (en) 1997-11-11 2012-07-24 Sony Corporation Data transmitting apparatus and method
US8050299B2 (en) 1997-11-11 2011-11-01 Sony Corporation Data transmitting apparatus and method
US6810045B1 (en) 1998-03-02 2004-10-26 Thomson Licensing S.A. Method and device for processing data packets which have been received or are to be transmitted on a data channel
WO1999045473A1 (fr) * 1998-03-02 1999-09-10 Deutsche Thomson-Brandt Gmbh Procede et dispositif pour traiter des paquets de donnees reçus ou transmis via une voie de donnees
US7251686B1 (en) * 1999-04-16 2007-07-31 Minolta Co., Ltd. Apparatus management unit and system for determining the validity of data/mail based on its expiration date and/or time
US7123306B1 (en) 1999-09-06 2006-10-17 Matsushita Electric Industrial Co., Ltd. Data transmitter and data receiver
WO2002032116A1 (fr) * 2000-10-11 2002-04-18 Sony Electronics Inc. Mecanisme de synchronisation adaptatif pour decodeur video numerique
EP1223689A1 (fr) * 2000-12-21 2002-07-17 Alcatel Espana, S.A. Méthode de correction de l'horloge de référence dans la liaison descendante d'un système de communication par satellite du type multi-faisceaux et fonctionnant en mode rafale multiplexé
CN1297151C (zh) * 2003-03-31 2007-01-24 索尼英国有限公司 视频同步
EP1471745A1 (fr) * 2003-03-31 2004-10-27 Sony United Kingdom Limited Synchronisation Video
US8073060B2 (en) 2003-03-31 2011-12-06 Sony United Kingdom Limited Video synchronization
US8401090B2 (en) 2003-03-31 2013-03-19 Sony United Kingdom Limited Video synchronization
EP1618396A1 (fr) * 2003-05-01 2006-01-25 Tut Systems, Inc. Procede et appareil permettant de mesurer la qualite des parametres de service de reseaux distribuant des images video mpeg en temps reel
EP1618396A4 (fr) * 2003-05-01 2010-09-15 Tut Systems Inc Procede et appareil permettant de mesurer la qualite des parametres de service de reseaux distribuant des images video mpeg en temps reel

Also Published As

Publication number Publication date
AU8009294A (en) 1995-10-17
JPH09511368A (ja) 1997-11-11
CA2181900A1 (fr) 1995-10-05

Similar Documents

Publication Publication Date Title
US5640388A (en) Method and apparatus for removing jitter and correcting timestamps in a packet stream
US5467342A (en) Methods and apparatus for time stamp correction in an asynchronous transfer mode network
JP3053717B2 (ja) 受信機においてタイミングを回復する装置
US6493832B1 (en) Communication apparatus which handles a time stamp
US5828414A (en) Reduction of timing jitter in audio-video transport streams
US5742623A (en) Error detection and recovery for high rate isochronous data in MPEG-2 data streams
US6744782B1 (en) Communications device, method thereof, communications system and recording medium
US5598415A (en) Transmission of high rate isochronous data in MPEG-2 data streams
KR100298963B1 (ko) 패킷화데이터스트림에서의운반된오디오데이터를획득하고그에러로부터극복하기위한방법및장치
JP2001513606A (ja) 符号化ビデオの処理
US20010004366A1 (en) Communication apparatus, communication method and storage medium
US6377588B1 (en) Method and apparatus for reducing jitter of a program clock reference in a transport stream of MPEG over ATM, and MPEG decoder
JP3045715B2 (ja) 伝送システム、送信装置、記録再生装置、および記録装置
WO1995026596A1 (fr) Procede pour preserver la base de temps d'origine d'un programme dans un systeme de communication multiplexe
JP4081936B2 (ja) 通信装置、通信方法、および記録媒体
KR100390138B1 (ko) 등시성데이터의전송방법,등시성데이터의복원방법및장치,정보데이터를복원하기위한디코더
US20030018983A1 (en) Data broadcasting service system of storage type
JP4192766B2 (ja) 受信装置および方法、記録媒体、並びにプログラム
WO2005076634A1 (fr) Introduction d'une gigue dans un systeme de transmission de donnees
EP0806874B1 (fr) Redressement d'erreurs de temps dans la transmission de données isochrone à paquets
JP3888014B2 (ja) 位相同期回路
JP3314700B2 (ja) Ｍｐｅｇデータ転送制御回路
JP3090129B2 (ja) 多重化装置
JP2000187940A (ja) 記録再生装置、および記録装置
KR0181081B1 (ko) 시스템 복호화기의 이에스씨알 재생장치

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2181900

Country of ref document: CA