Method and apparatus for demultiplexing, merging, and duplicating packetized elementary stream/program stream/elementary stream data

Presented herein are method(s) and apparatus for demultiplexing, merging, and duplicating packetized elementary stream/program stream/elementary stream data. In one embodiment, there is presented a method for processing data. The method comprises receiving a bitstream wherein said bitstream comprises a plurality of streams; mapping the plurality of streams to a plurality of identifiers; packetizing the plurality of streams, thereby resulting in a plurality of packets, and wherein each packet further comprises: a portion of only one of the plurality of streams; and a particular one of the identifiers, wherein the particular one of the identifiers is mapped to the only one of the plurality of streams.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

BACKGROUND OF THE INVENTION

A transport stream can comprise multiplexed data from a variety of channels, and a variety of transponders. The data can then be provided to decoders for decoding and eventual presentation. The increasing number of channels and potential destinations place considerable demultiplexing demands on media systems.

The increasing number of input formats which must be supported also poses considerable demultiplexing and routing challenges. In particular, the presence of formats such as raw PES, ES, program stream, DVD, and others (including arbitrarily formatted non-transport data) do not lend themselves well to being multiplexed, demultiplexed and routed in combination with transport based formats.

BRIEF SUMMARY OF THE INVENTION

A system and/or method is provided for, method and apparatus for demultiplexing, merging, and duplicating packetized elementary stream/program stream/elementary stream/DVD data, and other non-transport based formats substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.

These and other features and advantages of the present invention may be appreciated from a review of the following detailed description of the present invention, along with the accompanying figures in which like reference numerals refer to like parts throughout.

DETAILED DESCRIPTION OF THE INVENTION

Certain embodiments of the present invention relate to demultiplexing and routing video and audio signals. More specifically, certain embodiments of the invention relate to a method and system for demultiplexing and routing non-Transport based data when it arrives as part of a multiplexed stream together with Transport data.

In video/audio and PVR systems, it may be desirable for the transport demultiplexer to receive streams in a variety of different input formats, and to route them to many different destinations. For example, stream1from tuner1may be encapsulated in transport format1, while stream2from tuner2may be encapsulated in transport format2, and stream3from a non tuner source (say memory) may be encapsulated in a non-transport based format. These streams may be merged together into a single multiplexed stream and passed to a single transport demultiplexer, to route each stream to a separate final destination (e.g. video/audio decoder, or memory for access by software). Hereafter, the transport demultiplexer shall be referred to as RAVE (Record Audio Video Engine).

Since the RAVE splits its time between the different streams in order to service them all in a timely manner, the streams are structured as fixed length chunks of data (herein referred to as packets) which can be serviced as units. This makes it possible to service a small portion of stream1(say packet1) followed by a small portion of stream2(say packet2), etc, so that all streams are serviced at the required rates. Transport based formats lend themselves well to this demultiplexing because:

1) They are already split into packets

2) The information to route them to their final destination is embedded inside each packet.

With the preponderance of new formats and requirements, it may be desirable to process some non-transport based formats (e.g. PES/ES/Program stream/DVD, or arbitrarily formatted data) while simultaneously processing the transport data. However, there are multiple challenges associated with demultiplexing and routing non-Transport data when it coexists with transport data in the same stream. One problem is that the non-transport streams either do not have packet boundaries (in the case of ES or some generic formats), or the packet boundaries are so large and uncertain that multiplexing with other streams is made very difficult (e.g. PES). If the packet size of the non-transport data is infinite (i.e. no packet boundaries), or very large, the non-transport data will utilize excessive amounts of the bandwidth of the aggregate stream for long periods, precluding the interleaving of packets from transport based streams. This makes it difficult to process all the streams within the multiplexed aggregate in a timely manner.

For this reason, when non-transport data is multiplexed with other stream types, it is broken up into fixed length “chunks” of data which are not native to the data layer. However, this presents another problem. Within an individual non-transport stream, a special pattern may be seen which has the function of splitting the stream into two separate destinations. For example, in data which is input as raw PES, a PES header with a different stream ID may occur anywhere within the newly created packet. This results in a situation where part of the packet must be routed to one destination while another part must be routed to a second destination. This poses challenges for routing the final data, since it is desirable for data from any particular packet to go to only one destination. In addition to the above challenges, there is also the problem that unlike transport based formats, the non-transport data does not carry the routing information for every chunk of data within the packet. Thus, when individual packets of non-transport data are demultiplexed from the aggregate stream, there is no way to know where they are to be routed.

Transport data may normally be assigned to a logical PID channel. Logical PID channels are the result of decoding both the routing information inside the packet (e.g. PID for MPEG transport packets), plus the individual stream number. Whereas PIDS from multiple streams may be duplicated, when using both PID and stream number, the result is a logical PID channel which is unique in the system (since individual streams may not have duplicate PIDs).

Streams which have been assigned to individual PID channels can be merged with other streams, duplicated to multiple destinations, or sent to an individual destination. In addition, entire collections of streams (called bands) may be duplicated, merged, or sent to a destination in the same manner as individual streams.

In an embodiment of the invention, the non-transport data is packetized into standard MPEG transport packets with 188 byte length and all the usual syntax of MPEG packets. In addition, the individual non-transport streams may be given a PID and assigned a logical PID channel, just as with the transport data.

In another embodiment of the invention, the problem of having a pattern which splits the data routing (context) and occurs in the middle of the packet is solved for the case where the input stream type is raw PES, because the PES header will be aligned to the packet boundary, as it is for standard MPEG-2 packets.

In another embodiment of the invention, the problem of having a pattern which splits the data routing (context) and occurs in the middle of the packet is also solved for the case where the input stream type is an arbitrarily formatted stream. The solution to this problem for streams of arbitrary format comes from the routing choices that are now made available due to the mapping of the non-transport data to logical PID channels. Because of these routing choices, arbitrarily formatted streams which must be routed to different destinations based on patterns within the data may be duplicated to two (or more) contexts within the RAVE. In each context, data which belongs to one pattern may be dropped from the stream, whereas data from the other pattern is kept. This results in data from a single stream going to multiple destinations without having to split a single packet into multiple contexts.

Referring now toFIG. 1, there is illustrated block diagram of an exemplary circuit for processing data in accordance with an embodiment of the present invention. The circuit comprises a transport demultiplexing engine105. The transport demultiplexing engine105receives a bitstream110.

Portions110′ of the bitstream110can include data from a number of different streams1150,1151,1152, . . . ,115n. A stream115can include, for example, data from a file, video data from a program, or audio data from a particular channel for a program, to name a few.

The portions110′ of the streams115can include a stream header120. The stream header120can include an identifier122that identifies the particular one of the streams to which the portion110′ belongs. Generally, portions110′ of the bitstream110are associated with the same stream115and the immediately preceding portion110′ if the portion110′ does not include stream header120. The number of consecutive bytes in the bitstream110that can be associated with a particular stream115is not necessarily constant and may be varied.

Non-transport data is converted to MPEG-2 transport packets upstream of the RAVE. Once this has been done, the transport demultiplexing engine will take105in a wide variety of formats, including for example, original transport data, packetized elementary stream, program streams, and elementary stream data, to name a few. However, all of the non-transport data has been converted to transport packets, so that the aggregate stream seen by RAVE consists of transport packets, each with its own logical PID channel. This data may arrive together in the bitstream110. The transport demultiplexing engine105can split the incoming data into separate downstream destinations, hereafter referred to as “contexts”.

Because the number of consecutive bytes in the bistream110that can be associated with a particular stream115can be varied, the stream headers120can occur at any place within the bitstream110. The transport demultiplexing engine105receives the bitstream110comprising the plurality of streams115and maps the plurality of streams115to identifiers and115packets125comprise data130from only one of the plurality of streams115and an identifier135that is mapped to the streams.

In certain embodiments, the identifiers135can be a field in a header140. In certain embodiments of the present invention, the packets125can be fixed length.

In certain embodiments of the invention, individual non-transport streams which must be split to multiple contexts based on patterns within the data may be first duplicated to multiple contexts using the PID channel. Then, each individual RAVE context may drop selected data so that only data before the pattern may be sent to buffer A, whereas only data after the pattern may be sent to buffer B. This has the effect of splitting the stream based on patterns within the data, without splitting individual packets.

In certain embodiments of the present invention, the transport demultiplexing engine105can determine the stream associated with portions110, by examining the portion110′ for a stream header120. If the portion110′ includes a stream header120, all successive portions110′ are associated with the stream identified by the stream identifier122in the stream header, until another portion110′ is encountered with another stream header120. That portion110′ and all successive portions110′ of the bitstream are associated with the stream identified by the stream identifier122.

Referring now toFIG. 2, there is illustrated a flow diagram for processing data in accordance with an embodiment of the present invention. At205, the transport demultiplexing engine105receives a portion110′ of a bitstream110. The bitstream110comprises data from a plurality of streams115.

At210, the demultiplexing engine105determines the particular stream115associated with the portion110′ and maps the stream115to an identifier. At215, the transport demultiplexing engine105places the portion110′ in the payload125aof a new packet125, with the identifier mapped to the stream.

At220, the demultiplexing engine105receives another portion110′ of the bitstream110and determines if the stream associated with the portion110′ is the same as the stream associated with the previous portion at225.

In certain embodiments of the present invention, the transport demultiplexing engine105can determine if the portion110′ is associated with the particular stream115by examining the portion110′ for a stream header120. If the portion110′ does not include a stream header120, the transport demultiplexing engine105determines the portion is associated with the stream. If the portion110′ includes a stream header120, the transport demultiplexing engine105examines the stream identifier122to determine whether the portion110′ is associated with the particular stream or another stream.

If at225, the portion110′ is associated with the particular stream, the transport demultiplexing engine105places the portion110′ into the payload125aof the packet125. Successive portions110′ that are associated with the particular stream115are placed in the payload of the packet125auntil the packet payload125adoes not have enough capacity to store the portion110′ (230). When the packet payload125adoes not have the capacity to store the portion110′, that amount of the portion110′ that can be placed into the packet payload125ais placed into the packet payload125a, and the transport demultiplexing engine105returns to215.

If at225, the portion110′ is associated with another stream, the transport demultiplexing engine105stuffs the remaining portion of any partially filled payload125a(at235) and returns to210.

The present invention can be used to process a variety of data. For example, certain embodiments of the present invention can be used to demultiplex multimedia data that is received on a shared channel.

Referring now toFIG. 3, there is illustrated a block diagram of an exemplary circuit for processing video data in accordance with an embodiment of the present invention. The circuit comprises a Record Audio Video Engine (RAVE)305receiving multiplexed multimedia data on a data pipe.

The data pipe provides a bitstream310that includes unpacketized data, as well as transport packets306. Portions310′ of the unpacketized data in the bitstream310can include data from a number of different streams3150,3151,3152, . . . ,315n. A stream315can include, for example, a Packetized Elementary Stream (PES), a Program Stream, or an Elementary Stream, to name a few.

The unpacketized portions310′ of the bitstreams310can include a PES header320. The PES header320can include a field, StreamID322that identifies the particular one of the streams to which the unpacketized portion310′ belongs. Generally, unpacketized portions310′ of the bitstream310are associated with the same stream315as the immediately preceding unpacketized portion310′ if the unpacketized portion310′ does not include PES header320. The number of consecutive unpacketized bytes in the bitstream310that can be associated with a particular stream315is not necessarily constant and may be varied.

The RAVE305routes the data received on the data pipe to any number of decoders. The decoders can comprise, for example, audio decoder or video decoders for presenting data. The RAVE305can split the incoming data into separate downstream destinations, hereafter referred to as “contexts”.

The transport packets306include a transport payload306aand a transport header306b. The transport header306aincludes a number of fields, including a program identifier (PID) channel that maps the data in the transport packet payload306bto a particular program.

However, because the number of consecutive bytes in the unpacketized portions310′ that can be associated with a particular stream315can be varied, the PES headers320can occur at any place within the bitstream310. The RAVE305receives the bitstream310comprising the plurality of streams315and maps the plurality of streams315to PID channels, and packetizes the plurality of streams115into additional transport packets325. The transport packets325comprise data330from only one of the plurality of streams315and the PID channel field that is mapped to the streams.

According to certain embodiments of the present invention, the RAVE305packetizes the streams315by determining the particular stream315that is associated with an unpacketized portion310′ of the bitstream310and places the unpacketized portion of the bitstream310′ in the payload325aof a one of the packets. The RAVE305places each successive portion310′ of the bitstream110that is associated with the same stream315is placed in the payload325aof the packet325, until the payload325aof the packet is filled to capacity. At this point, the portions310′ are placed in the payload325aof another packet325.

When the RAVE305encounters a portion310′ that is associated with another stream315, the RAVE305places the portion310′ in a payload of another packet325with an PID channel identifying the stream associated with the portion310′. In certain embodiments of the invention, the RAVE305can stuff the remaining capacity of the first packet with dummy bytes.

In certain embodiments of the present invention, the RAVE305can determine the stream associated with unpacketized portions310′ by examining the unpacketized portion310′ for a PES header320. If the unpacketized portion310′ includes a PES header320, all successive unpacketized portions310′ are associated with the stream identified by the streamID322PES header320, until another unpacketized portion310′ is encountered with another PES header320. That portion310′ and all successive portions310′ of the bitstream are associated with the stream identified by the streamID322.

The transport packets306and the transport packets325(packetizing the originally unpacketized portions310′) can be routed to different destinations. The RAVE305uses a memory340to maps the transport packets306and transport packets325to different contexts. The decoders333can use the different contexts.

In certain embodiments of the present invention, the RAVE305can map the transport packets306and transport packets325as described in “METHOD AND APPARATUS FOR DEMULTIPLEXING, MERGING, AND DUPLICATING PACKETIZED ELEMENTARY STREAM/PROGRAM STREAM/ELEMENTARY STREAM DATA”, Ser. No. 11/273,102, filed Nov. 11, 2005, by Rodgers, et. al., which is incorporate by reference herein in its entirety for all purposes.

FIG. 4illustrates a block diagram of exemplary architecture of the RAVE400, in accordance with an embodiment of the present invention. The RAVE400may comprise a hardware assist block405, a firmware block410, and a RAVE buffer460.

The hardware assist block405may perform some processes and pass processed data to firmware block410via the RAVE buffer460. A portion of the processed data may be passed from the hardware assist block405via data path440to the RAVE buffer460, which may then be accessed by the firmware block410via data path445.

Several schemes may be utilized for interfacing the hardware assist block405with the firmware block410. To increase flexibility and allow for subsequent algorithmic changes, and to maintain high throughput, one or more schemes may be utilized within a RAVE. Using the combination of hardware assist and firmware, the RAVE may provide the flexibility associated with programmability of firmware, and the speed associated with hardware. The hardware assist405and the firmware410may be interfaced such that speed and programmability may be maintained simultaneously.

In one embodiment of the present invention, one approach may be to have incoming transport packets examined by both the hardware assist405and the firmware410. The hardware assist405may provide signals comprising information regarding each byte of the incoming transport packets as they are received. The information may indicate, for example, the type of byte or the location of the byte, such as, for example, the start of the code, etc. The firmware410may then read the signals provided by the hardware assist405and based on the received signals make a decision as to whether the received byte is to be processed using functions available in the firmware410or other algorithms.

For example, as a transport packet comes in, the hardware assist405may examine the data, and may look for a data pattern. When the hardware assist405sees the pattern it may send a trigger signal to the firmware410. The trigger signal may be, for example, an interrupt. The firmware410may then use the interrupt to begin a process associated with the identified pattern.

In one embodiment of the present invention, another approach may be for the hardware assist405to perform major functions, and allow for certain functions to be performed by the firmware410. The hardware assist405may process a portion of the incoming transport packets and the firmware410may process the remaining portion of the incoming transport packets.

In one embodiment of the present invention, the hardware assist405may perform major functions, or portions thereof. The functions associated with incoming transport packets may be broken down into sub-functions. The hardware assist405may perform major functions and/or sub-functions. The firmware410may perform a remaining portion of the functions and/or sub-functions.

In one embodiment of the present invention, the hardware assist405may operate on an incoming transport packet, and may output data regarding the processed transport data to a particular portion of the RAVE buffer460a.During the next packet time, i.e., when the next incoming transport packet is being processed by the hardware assist405, the firmware410may retrieve and process the previous transport packet and associated data from the portion of the RAVE buffer460a.

In another embodiment of the present invention, the hardware assist405may process functions that may be less likely to change such as, for example, MPEG parsing, and the firmware410may make most or all of the final decisions of the RAVE400. Functions that may change as a result of, for example, a new data format may be processed mainly by the firmware410with some processing that may be done by the hardware assist405.

The hardware assist405may perform a portion of the functions associated with the processing of the transport packet A, and may retrieve information associated with the transport packet A as well. The hardware assist405may then set up the hardware assist fields and may write retrieved information to a portion of the RAVE buffer460a.

The hardware assist field may comprise, for example, address of compare pattern, compare patterns, start/end of PES headers, number of ES bytes in the packet, number of payload bytes in the packet, start of payload, presence of packet errors, type of packet (record or audio/video), etc. These fields and their uses are explored further in “METHOD AND SYSTEM FOR SHARING AV/RECORD RESOURCES IN A PROGRAMMABLE TRANSPORT/DEMULTIPLEXER AND PVR ENGINE” U.S. patent application Ser. No. 11/385,468 filed Mar. 21, 2006 and “SYSTEM AND METHOD FOR PROVIDING DATA COMMONALITY IN A PROGRAMMABLE TRANSPORT DEMULTIPLEXER ENGINE” U.S. patent application Ser. No. 11/328,877 filed Jan. 10, 2006, each of which are incorporated herein by reference in its entirety.

After the hardware assist405performs the portion of the functions assisted with the first transport packet A, the firmware410may then access and begin processing the data associated with the first transport packet A from the portion of the RAVE buffer460a, and write the processed data to the portion of the RAVE buffer460a. Meanwhile, while the firmware410is processing the previously received first transport packet A, the hardware assist405may process transport packet B (a second transport packet) and write the associated retrieved data another portion of the RAVE buffer460such as, for example, a portion460b. The firmware410may then begin processing the transport packet B from the portion460bof the RAVE buffer460, and the hardware assist405may process the next transport packet C (a third transport packet) and write the associated information in portion of RAVE buffer460a, overwriting the data associated with the transport packet A previously processed by the firmware410.

In certain embodiments of the present invention, for unpacketized portions310′, the hardware assist405may packetized the unpacketized portion310′ into transport packets with a PID channel and data from only one of the streams315.

FIG. 5illustrates a block diagram of an exemplary RAVE, in accordance with an embodiment of the present invention. The RAVE may comprise hardware assist505and firmware510. The hardware assist505may preprocess incoming data packets, to provide them in a common format to the firmware510. The hardware assist505may comprise transport parsing such as, for example, MPEG transport parsing515, DirecTV transport parsing520, and DVD/program stream parsing525.

Incoming transport packets may be input into the associated transport parsing unit. For example, if the incoming transport packet comprises MPEG data, then the transport packet is handled by the MPEG transport parsing515.

The parsing unit that handles the incoming transport packet may then output the information for further parsing according to the type of information such as, for example, error, adaptation field, PES, PTS/DTS, ES byte location, and stream pattern comparison.

Therefore, the output from the initial parsing units (the MPEG transport parsing515, the DirecTV transport parsing520, and the DVD/program transport parsing525) may be input into one or more of error parsing540, adaptation field parsing545, PES parsing/PTS-DTS extraction550, ES byte location555, and Stream Pattern Comparison560.

The resulting parsed information may then be sent to a hardware assist memory manager530, where the information may be organized and saved to the data/hardware assist memory535. The parsed information may comprise, for example, errors, PES Start/End, PTS/DTS, PES Extension Start, Adaptation Num Bytes, Payload Start, Compare Pattern Value, Compare Pattern Location, ES Packet Byte Offset, ES Num Bytes, and ES Format. The parsed information may then be retrieved by the firmware510, from the memory535. The information retrieved by the firmware510may have a common format, and therefore, the firmware510may process the packets the same way regardless of their original format.

The embodiments described herein may be implemented as a board level product, as a single chip, application specific integrated circuit (ASIC), or with varying levels of the system integrated with other portions of the system as separate components. Alternatively, if the processor is available as an ASIC core or logic block, then the commercially available processor can be implemented as part of an ASIC device wherein certain aspects of the present invention are implemented as firmware.

The degree of integration may primarily be determined by the speed and cost considerations. Because of the sophisticated nature of modern processors, it is possible to utilized a commercially available processor, which may be implemented external to an ASIC implementation.