WO1995026595A1 - Procede et appareil pour aligner des paquets dans le but de simplifier l'analyse par un decodeur, dans un systeme de communication base sur des paquets - Google Patents

Procede et appareil pour aligner des paquets dans le but de simplifier l'analyse par un decodeur, dans un systeme de communication base sur des paquets Download PDF

Info

Publication number
WO1995026595A1
WO1995026595A1 PCT/US1994/007864 US9407864W WO9526595A1 WO 1995026595 A1 WO1995026595 A1 WO 1995026595A1 US 9407864 W US9407864 W US 9407864W WO 9526595 A1 WO9526595 A1 WO 9526595A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
program
transport
header
transport packet
Prior art date
Application number
PCT/US1994/007864
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 AU73318/94A priority Critical patent/AU7331894A/en
Publication of WO1995026595A1 publication Critical patent/WO1995026595A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • 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/2365—Multiplexing of several video streams
    • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347—Demultiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • H04N7/52—Systems for transmission of a pulse code modulated video signal with one or more other pulse code modulated signals, e.g. an audio signal or a synchronizing signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Definitions

  • the present invention relates a method and apparatus for packetizing a data stream for transmission to a decoder, and more particularly, to a packet alignment method and apparatus for simplifying the parsing of a transport stream in a packet-based multiplexed communications system.
  • MPEG-2 Systems Committee Draft JTC1/SC29/WG11/N0601, November, 1993
  • MPEG-2 Systems Committee Draft An overview of the MPEG-2 Systems standard is provided in asilewski, 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.
  • the two-level multiplex approach proposed by Applicants comprises a first "program” level in which each elementary stream (i.e., the coded representation of one video, audio or other digital data signal) is segmented and inserted into the payload sections of a respective sequence of "program packets" to form a "program stream” for that elementary stream, and a second "transport” level in which the program packets of each program stream are further segmented and inserted into the payload sections of smaller, fixed-length "transport packets".
  • the transport packets containing the program stream data of each elementary stream may then be multiplexed in a time division manner to generate a single outgoing bitstream referred to herein as a "transport stream".
  • a transport stream comprises a continuous sequence of transport packets, each of which may carry data from one of a plurality of different program streams.
  • Such a multiplexing approach can be used in a wide variety of applications. For example, such a multiplexing approach is particularly well suited for the transmission of audio and video programming in a subscription television system, such as a CATV or Direct Broadcast Satellite (DBS) system.
  • a subscription television system such as a CATV or Direct Broadcast Satellite (DBS) system.
  • DBS Direct Broadcast Satellite
  • the present invention is directed to a packet alignment method for simplifying the parsing of a transport stream in a packet-based multiplexed communications system, and to an apparatus for carrying out the method.
  • successive segments of a data stream to be transmitted are inserted into a plurality of successive program packets.
  • Each program packet has a header followed by a payload section.
  • the payload sections of each program packet preferably have variable lengths.
  • a first one of the successive program packets is then received for further packetization.
  • Successive segments of the first program packet are then inserted into the payload sections of a sequence of smaller, fixed length transport packets.
  • the header of the program packet is aligned with the beginning of the payload section of a first transport packet of the respective sequence.
  • Subsequent segments of the program packet are then inserted into subsequent transport packets until the end of the current program packet is reached. If the last segment of the current program packet does not fill the entire payload section of a last transport packet in the sequence, stuffing bytes are inserted in the last transport packet along with the last segment of the current program packet in order to "fill-out" the entire payload section of that transport packet .
  • a next subsequent program packet is then packetized in a similar manner beginning with a new transport packet. In this manner, the beginning of each program packet is always aligned with (i.e., always occupies) the first byte of a respective transport packet payload.
  • every transport packet has a header and a bit is set in the header of every transport packet that carries the header of a particular program packet.
  • a decoder can parse the headers in a sequence of transport packets to locate the boundaries between successive program packets carried in the payload sections of those transport packets.
  • stuffing bytes are inserted in transport packets in the form of an adaptation field.
  • An apparatus comprises means for segmenting a data stream to be transmitted and for inserting successive segments of the data stream into a plurality of successive program packets, each program packet having a header followed by a payload section; means for receiving one of the successive program packets- means for inserting successive segments of the program packet into the payload sections of a sequence of transport packets such that the header of the program packet is aligned with the beginning of the payload section of a first transport packet of the sequence; and means for inserting stuffing bytes in a last transport packet of the sequence if a last segment of the program packet does not fill the entire payload section of the last transport packet .
  • the apparatus further comprises means for generating an adaptation field for insertion in the payload section of a transport packet.
  • the means for inserting stuffing bytes is preferably adapted to insert the stuffing bytes in an adaptation field of the last transport packet.
  • every transport packet has a header and the apparatus further comprises means for setting a bit in the header of the first transport packet to indicate that the first transport packet carries the header of a program packet.
  • FIG. 2 is a block diagram of an encoder apparatus for generating a transport stream in accordance with the method of the present invention
  • Figure 3 graphically illustrates the packet alignment method of the present invention
  • Figure 4 shows additional details of the general content and arrangement of a program packet in accordance with the present invention
  • Figure 5 shows additional details of the general content and arrangement of a transport packet in accordance with the present invention
  • Figure 6 shows the general content and arrangement of a transport packet containing an adaptation field in accordance with an aspect of the present invention
  • Figure 7 is a flow diagram illustrating further details of the operation of the encoder of Figure 2 and a preferred embodiment of the method of the present invention
  • Figure 8 illustrates further details of the transport level packetizer of Figure 2 and, in particular, illustrates an apparatus for carrying out the method of Figure 7,*
  • Figure 9 is a block diagram of a decoder apparatus for parsing an incoming transport stream to extract one or more elementary streams from the transport stream.
  • Figure 1 illustrates an application of the present invention to a direct broadcast satellite (DBS) subscription television system 10. It is understood, however, that the present invention is by no means limited thereto. Rather, the present invention may be employed in any packet-based multiplexed communications system wherein it is desirable to simplify the parsing of a transport stream (as defined herein) by a decoder at a reception site in the system.
  • DBS direct broadcast satellite
  • the exemplary DBS system 10 comprises an uplink site 12 for generating a transport stream containing a multiplexed combination of audio and video signals and for transmitting the transport stream to one or more subscriber locations, e.g. location 33.
  • the audio and video signals (e.g., Video 1, Audio 1 ... Video N) are input to an encoder 14 via respective input lines 16, 18..24.
  • the encoder 14 operates in accordance with the method of the present invention to generate a continuous transport stream comprising a time-division multiplexed combination of transport packets, each of which may contain data comprising a coded representation of one of the video or audio signals input on lines 16, 18..24.
  • As the transport stream is generated it is supplied via line 26 to a transmitter 28 and then to a satellite uplink 30 for transmission via satellite 32 to the subscriber location 33.
  • the transport stream is typically transmitted over a particular transponder frequency.
  • a receiver 36 is tuned to the particular transponder frequency for receiving the transport stream via a satellite down-link 34.
  • the incoming transport stream is then provided to a decoder 40 via line 38.
  • a subscriber can employ the decoder 40 to retrieve the audio and video signals of a particular program from the incoming transport stream for output to a television set 42 or audio output device 44 at the subscriber location 33.
  • FIG 2 is a block diagram illustrating further details of the encoder 14 of Figure 1.
  • the video and audio signals e.g., "Video 1", “Audio 1” ... “Video N”
  • the video and audio signals are provided on respective lines 16, 18..24 to respective coders 46, 48..50 that produce coded representations of the respective signals.
  • the video and audio coders may operate in accordance with any well known data compression technique to produce digital compressed representations of the respective video and audio signals.
  • the coded representation of one video, audio or other data signal is referred to herein, as well as in the MPEG-2 Systems Committee Draft, as an "elementary stream”.
  • each elementary stream is provided to a program level packetizer 51.
  • the elementary stream for Video 1 is provided to the packetizer 51 via line 16'
  • the elementary stream for Audio 1 is provided to the packetizer 51 via line 18'
  • the program level packetizer 51 implements the first level of Applicant's two-level multiplexing scheme.
  • the program level packetizer 51 segments and inserts each elementary stream into a respective sequence of program packets referred to herein as a program stream.
  • Each program packet in a given program stream consists of a program packet header followed by a variable length payload containing the coded data of the elementary stream carried in that program stream.
  • Each elementary stream, in its program stream format, is assigned a unique "Packet ID” (PID) .
  • PID Packet ID
  • the elementary stream “Video 1” may be assigned a PID of "10”
  • the elementary stream “Audio 1” may be assigned a PID of "23”
  • the program streams are provided to a transport level packetizer 53 via respective lines 52, 54..56.
  • the transport level packetizer 53 implements the second level of Applicant's two-level multiplexing scheme.
  • the transport level packetizer 53 segments the individual program packets of each program stream and inserts successive segments of each program packet into the payload sections of a respective sequence of smaller, fixed-length transport packets.
  • each program stream is carried in a respective sequence of transport packets.
  • Each transport packet in a given sequence has a header that contains the PID associated with the program stream carried in that sequence of transport packets .
  • the sequences of transport packets formed from each program stream are provided to a transport stream multiplexer 64.
  • the sequence of transport packets carrying the program stream data for elementary stream "Video 1" are provided to the multiplexer 64 via line 58
  • the sequence of transport packets carrying the program stream data for elementary stream "Audio 1" are provided to the multiplexer 64 via line 60, and so on.
  • the multiplexer 64 operates in accordance with a time- division multiplexing technique to multiplex the individual transport packets of each sequence to form a single outgoing bitstream referred to herein as a transport stream.
  • the transport stream is output on line 26 for transmission (see Figure 1) .
  • a system clock generator 68 generates a common system clock that governs audio and video coding, the program level and transport level packetizers, and the transport stream multiplexer.
  • a control computer 70 controls the overall function of each component of the encoder 14 via control lines 72, 74..76. Additionally, the control computer 70 may generate a number of other transport packets that contain system related information, such as encryption related information used to control access to the elementary stream data carried in the transport stream. These system related transport packets are provided to the transport stream multiplexer 64 via line 63.
  • a transport stream therefore comprises a continuous sequence of transport packets, each of which may either carry system related information or data from one of the plurality of program streams .
  • FIG. 3 graphically illustrates the two-level packet-based multiplexing scheme implemented by the encoder 14 of Figure 2, and more particularly, illustrates the packet alignment method of the present invention.
  • an elementary stream 80 which may comprise a stream of coded video or audio data, is segmented and inserted into the payload sections of a plurality of successive program packets, e.g. program packets 82 and 84, to form a program stream.
  • Each successive program packet 82, 84 comprises a program packet header (PH) followed by a variable length payload comprising a successive portion of the coded data of the elementary stream 80.
  • Generation of the program stream is performed by the program level packetizer 51 of Figure 2.
  • each program packet 82, 84 of the program stream is further packetized into a sequence of transport packets 90, 92..100.
  • Each transport packet 90, 92..100 comprises a header (H) followed by a payload portion that carries the program stream data.
  • the program packets 82, 84 of the program stream are inserted into the transport packet payloads such that the first byte of the header of each program packet 82, 84 always occupies the first byte of a respective transport packet payload.
  • a first portion of program packet 82 which begins with a program packet header (PH) , is inserted in the first transport packet 90 of the sequence of transport packets 90, 92..100.
  • a second successive portion of the program packet 82 is inserted into the next consecutive transport packet 92.
  • the third or remaining portion of the program packet 82 is not long enough to occupy the entire payload section of the next consecutive transport packet 94.
  • One way to handle such a situation is to simply fill as much of the payload section of the transport packet 94 as the remaining portion of the program packet 82 will occupy, and then begin filling the remainder of the transport packet 94 payload with the beginning of the next program packet 84.
  • a decoder that receives this sequence of transport packets 90, 92..100 would have to parse through the payload sections of each incoming transport packet to determine the boundaries between successive program packets. This would unduly increase the cost and complexity of the decoder.
  • the packet alignment method of the present invention provides a simple mechanism for determining the boundaries between successive program packets as they are recovered from their respective sequence of transport packets without the need for complex parsing capabilities.
  • the packet alignment method of the present invention ensures that the first byte of each program packet is always aligned with (i.e., always occupies) the first byte of the payload section of a transport packet.
  • a program packet header indicator flag is provided in the header (H) of each transport packet 90, 92..98 to inform a decoder whether a given transport packet contains the beginning (i.e., the header) of a particular program packet.
  • a decoder can use the program packet header indicator flags in each transport packet to determined the boundaries between successive program packets recovered from those transport packets .
  • the decoder need only parse the transport packet headers, thereby avoiding the need to parse the transport packet payload data to find the program packet boundaries. As a result, decoder complexity and cost is reduced.
  • FIG. 1 illustrates the transport level packetizer 53 of Figure 2.
  • Figure 3 illustrates the packetization of a single program stream, it is understood that the transport level packetizer 53 of Figure 2 separately packetizes each of the program streams input on lines 52, 54..56 in the manner illustrated in Figure 3 to produce a respective sequence of transport packets for each program stream.
  • Figure 4 illustrates the general content and arrangement of a program packet 102 in accordance the present invention. As shown, the program packet 102 comprises a fixed length program packet header 104 followed by a variable length payload section 106 that comprises the coded video or audio of a respective elementary stream.
  • the program packet header 104 begins with a program packet start code 108 which, in the present embodiment, comprises a 24 bit pattern that is the same for every program packet. Hardware operating upon a program stream can use the program packet start code 108 to identify the start of each program packet.
  • the start code 108 is followed by a program packet prefix 110 that may contain information related to the elementary stream data carried in the payload section 106. For example the prefix 110 may contain information concerning the transmission priority or encryption status of the elementary stream data in the payload section 106.
  • the program packet prefix 110 is followed by a program packet length field 112 which specifies the total number of bytes in the program packet. As mentioned above, program packets may be of variable length.
  • Figure 5 illustrates the general content and arrangement of a transport packet 114 in accordance with a preferred embodiment of the present invention.
  • the transport packet 114 begins with a header section that comprises a transport packet start code 116 and a transport packet prefix 118.
  • the transport packet start code 116 is an 8 bit pattern that is the same for all transport packets. Because transport packets are fixed-length packets and are arranged consecutively in a transport stream, the packet start codes will appear repetitively in an incoming transport stream at a constant rate. Accordingly, the packet start codes can be used for synchronization purposes at a decoder.
  • the transport packet prefix 118 may contain a number of control indicators 121, such as packet priority, error status and encryption mode indicators, relevant to the data carried in the payload section 120 of the transport packet.
  • the transport packet prefix 118 also contains a Packet_ID (PID) field 126, which in the present embodiment comprises a 13 bit field.
  • PID Packet_ID
  • a unique Packet_ID (PID) is assigned to each program stream. The PID assigned to a given program stream is inserted into the PID field 126 of each transport packet that carries a portion of that program stream.
  • a given program stream, and ultimately the elementary stream data carried in that program stream can be recovered from an incoming transport stream by simply extracting every incoming transport packet that carries the PID associated with that program stream.
  • a group of related elementary streams e.g. audio, video etc.
  • the transport packet prefix 118 further comprises a transport adaptation field flag 122 and a program packet header indicator flag 124, each of which comprise a single bit in the present embodiment.
  • the transport adaptation field flag 122 is used to indicate the presence or absence of an adaptation field within the payload section 120 of the transport packet 114.
  • An adaptation field may be "opened” in any transport packet to provide a convenience "window" for carrying information of relevance to either the transport stream or the program stream data carried in the payload section of that transport packet.
  • an adaptation field can be used to carry timing information, encryption related information, etc.
  • an adaptation field can also be used for byte-stuffing purposes in order to "fill out" the payload section of a transport packet.
  • the program packet header indicator flag 124 is used to indicate whether the payload section 120 of the transport packet 114 begins with the header of a program packet. As explained above, in accordance with the present invention, the first byte of the header of any program packet always occupies the first byte of the payload section of a transport packet .
  • a decoder can parse the header of each incoming transport packet and use the program packet header flag 124 to identify program packet boundaries as it extracts program stream data from the payload sections of the incoming transport packets.
  • Figure 6 illustrates the general content and arrangement of a transport packet 130 that contains an adaptation field.
  • an adaptation field comprises an adaptation field header 132 and an adaptation field data region 134.
  • the adaptation field header 132 comprises a one- byte adaptation field type specifier 136 and a one-byte adaptation field length specifier 138.
  • the type specifier 136 specifies what type of data follows in the data region 134 of the adaptation field.
  • an adaptation field can be "opened" in a transport packet to carry information related to the transport stream or the particular program stream data carried in the payload section of that transport packet, such as timing or encryption related information.
  • a number of different adaptation field types may be defined.
  • the data region 134 of an adaptation field may also be used for byte-stuffing purposes in order to "fill- out" the payload section of a transport packet with stuffing- bytes whenever the last segment of a program packet does not fill the entire payload section.
  • Stuffing-bytes can be appended to the data region 134 of an adaptation field that already contains other transport or program stream related information, or if stuffing-bytes are needed in a transport packet that otherwise would not contain an adaptation field, a "stuffing bytes only" adaptation field type may be defined in which the data region 134 carries only stuffing bytes.
  • an adaptation field type value of 00 (hex) is used to indicate the presence of a "stuffing bytes only" adaptation field.
  • a stuffing-byte is a byte having a pre-determined pattern. For example, the bit pattern '1111 1111' can be used for each stuffing byte.
  • the adaptation field length specifier 138 is used to specify the overall length of the adaptation field.
  • the length of the adaptation field reflects the number of stuffing bytes added to the data region 134 in order to "fill out" the payload section of the transport packet.
  • Figure 7 is a flow diagram illustrating further details of the operation of the encoder of Figure 2 and a preferred embodiment of the method of the present invention.
  • the flow diagram illustrates the operation of the transport level packetizer 53 in generating a sequence of transport packets from a given program stream. It is understood, however, that the transport level packetizer 53 will perform the following steps separately for each program stream received on lines 52, 54..56 in order to produce a respective sequence of transport packets for each program stream.
  • a program packet of the program stream under consideration is received by the transport level packetizer 53.
  • the header of a first transport packet is generated. Because the first packet will carry the first byte of the program packet header in its payload, the program packet header flag (PPH) in the transport packet header is set to a value indicative of the presence of a program packet header. In the present embodiment, a PPH flag value of ' 1' indicates that a program packet header is carried in the payload section of the transport packet.
  • PPH program packet header flag
  • the packetizer 53 begins constructing the payload section of the transport packet from the data of the current program packet.
  • the first byte of the program packet will therefore be aligned with (i.e., will occupy) the first byte position of the transport packet payload.
  • the transport packet payload is constructed from the program packet data one byte at a time.
  • the packetizer 53 determines whether the end of the current program packet has been reached. As described below in greater detail, in the present embodiment, the packetizer 53 identifies the end of a current program packet by detecting the beginning (i.e., the program packet start code pattern) of the next subsequent program packet in the program stream.
  • step 160 If so, processing of the current program packet is complete, and control passes back to step 140 where the next program packet of the program stream is received for processing in a similar manner. If, however, it is determined at step 156 that the last segment or portion of the current program packet will not occupy the entire payload section of the current transport packet, control passes to step 160.
  • the packetizer 53 calculates the number of stuffing bytes that will be required in a suitable adaptation field in order to "fill-out" the entire payload section of the current transport packet.
  • an adaptation field may already have been created to carry other transport or program stream related information.
  • the packetizer 53 determines the number of stuffing bytes that, along with the already existing data of the adaptation field, are needed to "fill out” the entire payload section of the current transport packet .
  • Those stuffing bytes are then appended to the other adaptation field data at step 162 and the adaptation field length (AF ) specifier in the adaptation field header is adjusted accordingly. If the current transport packet would not otherwise have carried an adaptation field, then a "stuffing bytes only" adaptation field is generated at step 162.
  • a "stuffing bytes only" adaptation field has a type value of '00' (hex) .
  • the packetizer 53 inserts the header and data region of the adaptation field in the payload section of the current transport packet.
  • the adaptation field precedes the remainder of the program packet in the payload section of the transport packet. In other embodiments, however, the remainder of the program packet could follow immediately after the transport packet header and the adaptation field could then follow the program packet data to form the end of the transport packet.
  • the transport adaptation field flag in the header of the current transport packet is set to a value indicative of the presence of the adaptation field. Processing of the current program packet is now complete, and control passes back to step 140 for receiving the next program packet.
  • transport packets that carry the header of a program packet may also contain adaptation fields.
  • the first byte of the program packet header follows immediately after the adaptation field and therefore occupies the first byte of the remaining portion of the transport packet payload.
  • Figure 8 illustrates further details of the transport level packetizer 53 of Figure 2 and, in particular, illustrates an apparatus 200 (i.e., circuit) for carrying out the method of the present invention, as illustrated in Figure 7.
  • the circuit 200 illustrated in Figure 8 packetizes a single program stream into a respective sequence of transport packets.
  • the transport level packetizer 53 can either packetize each of the program streams received on lines 52, 54..56 one at a time or on a time-share basis using a single circuit 200, or alternatively, multiple implementations of the circuit 200 may be provided in the transport level packetizer 53 for packetizing the program streams in parallel.
  • a program stream comprising a continuous succession of program packets, is received at an input 202 of the circuit 200 and provided directly to both a program packet header detection circuit 204 and a first-in- first-out (FIFO) data buffer 206.
  • the output of the data buffer 206 is coupled to the input of a transport packet multiplexer 228 via line 220.
  • the program packet header detection circuit 204 detects the program packet start code pattern (PPSC) at the beginning of the header of each successive program packet and provides a "header detection" signal to a transport packet generation controller 210 via line 208.
  • PPSC program packet start code pattern
  • the transport packet generation controller 210 controls the overall construction of each successive transport packet in the sequence to be generated for the program stream received on line 202.
  • the transport packet generation controller 210 initiates the construction of a transport packet to carry a first portion of the current program packet.
  • the first byte of the current program packet will be aligned with (i.e., will occupy) the first byte of the payload portion of this first transport packet .
  • a transport packet header generator 212 Under the control of the transport packet generation controller 210, a transport packet header generator 212 generates a transport packet header for the first transport packet.
  • the Packet_ID associated with the program stream received on line 202 is inserted in the PID field of the transport packet header. Additionally, since this first transport packet will carry the header of the current program packet, the program packet header indicator flag (PPH) in the transport packet header is set to a value of ' 1 ' .
  • the data forming the transport packet header is then provided, in sequence, to the input of a transport packet multiplexer via line 216.
  • the transport packet generation controller 210 selects line 216 for output on line 232 using the data selection multiplex control lines 230. Thus, the header of the transport packet is output on line 232.
  • the controller 210 loads a transport packet payload size counter 222 with a value equal to the total fixed length, in bytes, of the transport packet payload section.
  • transport packets have a fixed length.
  • the transport packet generation controller enables the output of the data buffer 206 and switches the output 232 of the multiplexer 228 to line 220 using selection control lines 230.
  • the transport packet generation controller 210 decrements the payload length byte count in counter 222. When the counter 222 reaches zero, assuming that the end of the current program packet has not been detected, the transport packet controller 210 disables the output of the buffer 206 and switches the output of the multiplexer 228 back to line 216. The controller 210 then initiates the generation of a next subsequent transport packet. As before, the transport packet header generator 212 generates the transport packet header and outputs the header, bit-by-bit, on line 216. Because this next subsequent transport packet will contain a remaining portion of the current program packet, and will not contain a program packet header, the program packet header indicator flag (PPH) will be set to a value of ' 0' .
  • PPH program packet header indicator flag
  • an adaptation field generator 214 begins generating the header and data region of the adaptation field and provides the adaptation field data to a third input of the transport packet multiplexer 228 via line 218.
  • a respective one of a plurality of counters 226 is loaded with a value indicative of the length of the adaptation field being generated.
  • the transport packet generation controller 210 loads the transport packet payload size counter 222 with a value equal to the total length of the transport packet payload minus the length of the adaptation field; that is, the counter 222 is loaded with a value equal to the remaining length of the payload portion that will follow the adaptation field.
  • the controller 210 then enables the output of the data buffer 206 and switches the output of the transport packet multiplexer 228 to line 220. Successive bytes of the remaining portion of the current program packet are output on line 220 until the counter 222 again reaches zero.
  • the first transport packet that carries the program packet header may also contain an adaptation field, in which case, the first byte of the program packet header follows immediately after the adaptation field and therefore occupies the first byte of the remaining portion of the transport packet payload.
  • the circuit 200 continues to function as described above, generating successive transport packets that carry successive portions of the current program packet, until the PPSC of a next subsequent program packet in the program stream is detected, i.e., until the end of the current program packet is detected.
  • the buffer 206 is of sufficient size to provide the controller 210 with sufficient time to calculate the number of stuffing bytes, if any, that will be needed to fill-out the payload section of the last transport packet to be generated for the current program packet .
  • the adaptation field generator loads a value equal to the required number of stuffing bytes into a respective counter 224 and begins generating the adaptation field as described above.
  • the controller switches the output of the multiplexer 228 to line 220 to output the last segment or portion of the current program packet .
  • the circuit 200 repeats the process for the next program packet in the program stream.
  • the first byte of each program packet will always be aligned with, i.e., will always occupy, the first byte of the payload section of a respective transport packet.
  • Figure 9 is a block diagram of a decoder apparatus 170 for parsing an incoming transport stream to extract one or more elementary streams from the transport stream.
  • the decoder 170 may be employed to select a particular program, i.e., related group of elementary streams, for output at a subscriber location.
  • the decoder 170 of Figure 9 may be used to implement the decoder 40 of Figure 1.
  • an incoming transport stream is provided via line 172 to a transport stream demultiplexer 176.
  • a user's program selection is provided to the demultiplexer 176 via line 174.
  • each transport packet carries the Packet_ID (PID) associated with the program stream data carried in that transport packet .
  • PID Packet_ID
  • a different PID is associated with each of the different program streams carried in the transport stream.
  • a mapping table may be provided in the decoder that identifies, for each user selectable program, the PIDs associated with the program streams that carry the elementary streams that "make ⁇ up" that program.
  • the demultiplexer 176 can access this mapping information to identify the PIDs of the transport packets that carry the program stream data for each of the elementary streams (e.g., video, audio, etc.) that "make-up" the selected program.
  • the elementary streams e.g., video, audio, etc.
  • Such a program mapping technique is incorporated in the MPEG-2 System standard (ISO 13818) as described in the aforementioned MPEG-2 Systems Committee Draft .
  • the demultiplexer 176 begins extracting every incoming transport packet having a PID that matches one of those listed for the selected program.
  • a subscriber may select a program that consists of elementary streams "Video 1" and "Audio 1.” Assuming that the transport packets carrying the program stream data for "Video 1" each have a PID of '10', and that the transport packets carrying the program stream data for "Audio 1" each have a PID of '12', the demultiplexer 176 will extract every incoming Transport Packet having a PID of '10' or '12' .
  • transport packets that contain the program stream data for each elementary stream of the selected program are retrieved from the incoming transport stream, they are provided, in sequence, to a transport level parsing unit 182.
  • the transport packets carrying program stream data for a video elementary stream are provided to the transport level parsing unit 182 via line 178.
  • Transport packets carrying program stream data for a related audio elementary stream are provided to the parsing unit 182 via line 180.
  • the transport level parser 182 operates to retrieve the respective program streams from the respective transport packet sequences. Essentially, the transport level parser 182 extracts the data carried in the payload sections of each transport packet and then reconstructs the program packets of each program stream.
  • the transport level parsing unit 182 does not have to parse the payload sections of each transport packet to identify program packet boundaries. Rather, the parsing unit 182 can simply employ the program packet header indicators (PPH) in the headers of each successive transport packet to identify the program packet boundaries. This greatly simplifies the implementation of the transport level parsing unit 182 and reduces the overall cost of the decoder.
  • PPH program packet header indicators
  • the program packets of the respective program streams are reconstructed, they are provide via respective lines 184 and 186 to a program level parser 188.
  • the program level parser 188 operates to recover the raw elementary stream data from the respective program packets of each program stream.
  • the audio and video elementary stream data recovered from the respective program streams are provided to respective buffers 190, 192 and then to respective decoders 194, 196 which decode the elementary stream data to produce analog video and audio signals for output to a display device (not shown) .
  • the present invention is directed to a method and apparatus for packetizing a program stream into a sequence of transport packets such that the beginning of a program packet is always aligned with the beginning of a transport packet payload.
  • the packet alignment method and apparatus of the present invention are not limited to the particular two-level multiplexing scheme described above, including the particular packet structures and encoder and decoder implementations. Rather, the present invention may be employed in any two-level multiplexing scheme in which a first level packet stream is packetized or encapsulated within smaller, fixed-length packets of a second level packet stream.
  • program packet and "transport packet” are not intended to be limited to the particular packet structures described above, but are intended to encompass the respective packets of the first and second levels of any two-level packet based multiplexing scheme.
  • the method of the present invention has been substantially incorporated as part of the two-level multiplexing scheme of the MPEG-2 Systems standard in which the packets of the first multiplexing level are referred to as Program Elementary Stream (PES) packets.
  • PES Program Elementary Stream
  • program packets as used in the appended claims, is intended to encompass the Program Elementary Stream packets of the MPEG-2 Systems standard. It is understood therefore that changes may be made to the embodiments described above without departing from the broad inventive concepts thereof. 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)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Le procédé de mise en paquets d'un flux de données (80) en vue de leur transmission consiste: (a) à découper le flux de données (80) en segments et à insérer la pluralité de segments successifs du flux de données dans une pluralité de paquets successifs (82) du programme, chaque paquet du programme ayant une en-tête suivie par une section de transport de l'information; (b) pour chacun des paquets successifs du programme, (i) à insérer des segments successifs du paquet du programme dans la section de transport de l'information d'une séquence consécutive de paquets de transport (90-98) pour que l'en-tête du paquet du programme soit alignée sur le commencement de la section de transport de l'information d'un premier paquet de transport dans la séquence, et (ii) à répéter l'étape (b) (i) jusqu'à ce que le dernier segment du paquet du programme soit atteint. Lorsque le dernier segment du paquet du programme ne remplit pas toute la section de transport de l'information du dernier paquet de transport dans la séquence, on ajoute des bits de bourrage au dernier paquet de transport pour remplir le restant de la section de transport de l'information de ce paquet de transport. De cette manière, l'en-tête de chaque paquet du programme est toujours alignée sur le commencement de la section de transport de l'information du paquet de transport.
PCT/US1994/007864 1994-03-29 1994-07-11 Procede et appareil pour aligner des paquets dans le but de simplifier l'analyse par un decodeur, dans un systeme de communication base sur des paquets WO1995026595A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU73318/94A AU7331894A (en) 1994-03-29 1994-07-11 Packet alignment method and apparatus for simplifying parsing at a decoder in a packet-based communications system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US21966594A 1994-03-29 1994-03-29
US219,665 1994-03-29

Publications (1)

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

Family

ID=22820216

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1994/007864 WO1995026595A1 (fr) 1994-03-29 1994-07-11 Procede et appareil pour aligner des paquets dans le but de simplifier l'analyse par un decodeur, dans un systeme de communication base sur des paquets

Country Status (2)

Country Link
AU (1) AU7331894A (fr)
WO (1) WO1995026595A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0781051A2 (fr) * 1995-12-20 1997-06-25 Deutsche Thomson-Brandt Gmbh Transmission hiérarchique de signaux numériques d'images
WO1998023093A1 (fr) * 1996-11-19 1998-05-28 Nds Limited Procede et dispositif servant a modifier des tables de donnees
WO1998053614A1 (fr) * 1997-05-23 1998-11-26 Thomson Consumer Electronics, Inc. Systeme pour conversion numerique de formats de donnees et production d'un train binaire
EP0932307A2 (fr) * 1998-01-27 1999-07-28 Tektronix, Inc. Multiplexeur de flux de transport pour données vidéo et audio comprimées
EP0987854A1 (fr) * 1997-12-26 2000-03-22 Matsushita Electric Industrial Co., Ltd. Appareil pour la reproduction d'un signal code
WO2000056005A2 (fr) * 1999-03-12 2000-09-21 Lok Lombardkasse Ag Procede pour rendre anonymes des donnees sensibles
US6807585B2 (en) * 2001-02-22 2004-10-19 Ati Technologies, Inc. Method and system for parsing section data
US7602801B2 (en) * 2003-06-16 2009-10-13 Panasonic Corporation Packet processing device and method
KR20120079209A (ko) * 2011-01-04 2012-07-12 삼성전자주식회사 비디오 및 오디오 통신 시스템에서 가변 길이의 전송 패킷 지원 방법 및 장치
CN113141520A (zh) * 2020-01-17 2021-07-20 北京达佳互联信息技术有限公司 视频流传输方法、装置、电子设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5237569A (en) * 1990-10-18 1993-08-17 Fujitsu Limited Method and system for transmitting HDLC data via ATM network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5237569A (en) * 1990-10-18 1993-08-17 Fujitsu Limited Method and system for transmitting HDLC data via ATM network

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0781051A3 (fr) * 1995-12-20 1999-06-02 Deutsche Thomson-Brandt Gmbh Transmission hiérarchique de signaux numériques d'images
EP0781051A2 (fr) * 1995-12-20 1997-06-25 Deutsche Thomson-Brandt Gmbh Transmission hiérarchique de signaux numériques d'images
WO1998023093A1 (fr) * 1996-11-19 1998-05-28 Nds Limited Procede et dispositif servant a modifier des tables de donnees
US6233253B1 (en) 1997-05-23 2001-05-15 Thomson Licensing S.A. System for digital data format conversion and bit stream generation
WO1998053614A1 (fr) * 1997-05-23 1998-11-26 Thomson Consumer Electronics, Inc. Systeme pour conversion numerique de formats de donnees et production d'un train binaire
US8649662B2 (en) 1997-12-26 2014-02-11 Panasonic Corporation Coded signal reproduction apparatus
US7809246B1 (en) 1997-12-26 2010-10-05 Panasonic Corporation Apparatus for reproduction of encoded signal
EP0987854A1 (fr) * 1997-12-26 2000-03-22 Matsushita Electric Industrial Co., Ltd. Appareil pour la reproduction d'un signal code
EP0987854A4 (fr) * 1997-12-26 2005-01-05 Matsushita Electric Ind Co Ltd Appareil pour la reproduction d'un signal code
EP1630997A2 (fr) * 1997-12-26 2006-03-01 Matsushita Electric Industrial Co., Ltd. Appareil pour la reproduction d'un signal codé
EP1630997A3 (fr) * 1997-12-26 2006-04-19 Matsushita Electric Industrial Co., Ltd. Appareil pour la reproduction d'un signal codé
EP0932307A3 (fr) * 1998-01-27 2000-12-13 Tektronix, Inc. Multiplexeur de flux de transport pour données vidéo et audio comprimées
EP0932307A2 (fr) * 1998-01-27 1999-07-28 Tektronix, Inc. Multiplexeur de flux de transport pour données vidéo et audio comprimées
WO2000056005A3 (fr) * 1999-03-12 2000-12-28 Lok Lombardkasse Ag Procede pour rendre anonymes des donnees sensibles
WO2000056005A2 (fr) * 1999-03-12 2000-09-21 Lok Lombardkasse Ag Procede pour rendre anonymes des donnees sensibles
US6807585B2 (en) * 2001-02-22 2004-10-19 Ati Technologies, Inc. Method and system for parsing section data
US7602801B2 (en) * 2003-06-16 2009-10-13 Panasonic Corporation Packet processing device and method
KR20120079209A (ko) * 2011-01-04 2012-07-12 삼성전자주식회사 비디오 및 오디오 통신 시스템에서 가변 길이의 전송 패킷 지원 방법 및 장치
EP2661848A2 (fr) * 2011-01-04 2013-11-13 Samsung Electronics Co., Ltd Appareil et procédé permettant de prendre en charge une longueur variable d'un paquet de transport dans un système de communication audio et vidéo
EP2661848A4 (fr) * 2011-01-04 2014-07-23 Samsung Electronics Co Ltd Appareil et procédé permettant de prendre en charge une longueur variable d'un paquet de transport dans un système de communication audio et vidéo
US9100671B2 (en) 2011-01-04 2015-08-04 Samsung Electronics Co., Ltd Apparatus and method for supporting variable length of transport packet in video and audio communication system
KR101670723B1 (ko) 2011-01-04 2016-11-01 삼성전자주식회사 비디오 및 오디오 통신 시스템에서 가변 길이의 전송 패킷 지원 방법 및 장치
CN113141520A (zh) * 2020-01-17 2021-07-20 北京达佳互联信息技术有限公司 视频流传输方法、装置、电子设备及存储介质
CN113141520B (zh) * 2020-01-17 2022-04-01 北京达佳互联信息技术有限公司 视频流传输方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
AU7331894A (en) 1995-10-17

Similar Documents

Publication Publication Date Title
EP0805598B1 (fr) Procédé et appareil pour le remplacement de bits de bourrage avec des données supplémentaires dans un train de données vidéo MPEG
US5856973A (en) Data multiplexing in MPEG server to decoder systems
US5467342A (en) Methods and apparatus for time stamp correction in an asynchronous transfer mode network
US5598415A (en) Transmission of high rate isochronous data in MPEG-2 data streams
JP4240545B2 (ja) デジタルデータフォーマット変換及びビットストリーム生成のためのシステム
US5333135A (en) Identification of a data stream transmitted as a sequence of packets
US6584120B1 (en) Data multiplexing apparatus and method
CZ20001821A3 (cs) Způsob filtrování paketového datového toku a přijímač/dekodér
JP4332267B2 (ja) エンコーダ及びデコーダ
KR100306686B1 (ko) 리얼타임오디오패킷레이어인코더
WO1995026595A1 (fr) Procede et appareil pour aligner des paquets dans le but de simplifier l'analyse par un decodeur, dans un systeme de communication base sur des paquets
US20010015985A1 (en) Transmission system with flexible frame structure
US6546013B1 (en) Method and apparatus for delivering reference signal information within a specified time interval
US5909468A (en) Method and apparatus for encoding PCR data on a frequency reference carrier
KR100480186B1 (ko) 전송시스템,전송방법,수신방법,전송기및수신기
AU8009294A (en) Method for preserving the original timebase of a program in a multiplexed communications system
KR100390138B1 (ko) 등시성데이터의전송방법,등시성데이터의복원방법및장치,정보데이터를복원하기위한디코더
KR100973835B1 (ko) 디지털 스트림의 프로세싱 방법
KR100791234B1 (ko) 다중화 신호를 처리하기 위한 방법, 송신기 및, 송신 시스템
JPH09298748A (ja) Ｍｐｅｇビットストリームにおいてスタッフィングビットの代わりにプライベートデータを送る方法および装置
KR100202019B1 (ko) 시스템 부호화기에서의 피시알(pcr) 신호 발생 장치
KR0181084B1 (ko) 엠펙 시스템의 디티에스 부호화장치
JPH11340935A (ja) データ多重化装置及び方法
JP2000278230A (ja) ディジタル信号多重装置およびディジタル信号受信装置
WO2000057647A1 (fr) Procede et appareil de generation d'informations d'horodatage

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP

WA Withdrawal of international application
NENP Non-entry into the national phase

Ref country code: CA