System and method for processing priority transport stream data in real time in a multi-channel broadcast multimedia system

Abstract

A system for processing data stream content in a multi-channel broadcast multimedia system including a packet processor having an input control having a filter module for detecting at least one priority data stream from an input data stream, and an output control including a format module for displaying the priority data streams in real-time. The system can include an alarm detector for checking a rate of the priority data stream and issuing an alarm in the event of an alarm condition of the priority data stream.

Description

BACKGROUND

Public video distribution systems that allow a delayed display of video or audio such as a pause feature, normally delay all video that is being received. However, in some situations, it is not desirable to pause or delay certain data streams. For example, in the case of ‘local content insertion’ (LCI) for customers using satellite applications in apartments or planes, additional content can be streamed along with the satellite programs to provide movies and camera feeds. Cable systems also can provide special security streams (high priority data streams) as a service that feeds Set Top Box (STB) Personal Video Recorders (PVR). Even video monitors inside an infant's bedroom in a home can stream MPEG video, and such video might comprise high priority data streams that should not be delayed, paused, or made discontinuous. Internet feeds can also provide remote camera feeds which might be important for security purposes and thus would not be desired to get frozen or delayed along with all of the other data in the event a consumer records/delays or pauses their equipment.

For example, a typical airborne pause system would normally pause or stop the local movies on a plane and all satellite content during pilot announcements. After the announcements, the video would begin to be streamed again in either a real-time or delayed state. If security or safety cameras are included in the LCI content or in a priority satellite channel, pausing these streams or stopping the streams might cause a breach of security or a safety issue, since video would either be lost or not be displayed in real-time. That is, applications such as safety or security video that pass through a system that has a “pause” function activated would be seeing delayed video which would/could be misleading or unsafe.

SUMMARY

In one embodiment according to the present principles, a system and method is provided for allowing selected priority data streams to flow in real-time through a system at all times, even if the system is paused or stopped. Any transport stream that is, for example, security data can be labeled as a priority channel and treated as a non-pausable stream in any system that anticipates this feature. For example, normally, a security system and satellite/cable/internet system content are independent systems. However, as systems become more versatile, cost reduced, and full featured, the trend is to try to merge these systems. A system and method according to one embodiment of the present principles provides a solution to allow selected priority signals to flow through the system to be viewed in real-time at all times, even when the main system is paused or stopped (e.g., during announcements). If the priority signals are interrupted, the viewer is notified that the video is discontinuous in time to prevent a false sense of security.

According to another embodiment of the present principles, any priority data stream that is detected is immediately notified to the viewer via, e.g., an icon or other symbol on a screen which can be superimposed over normal or non-priority video content being displayed and watched. In this embodiment, it would not be required or necessary for a pause function to be present in the system. For example, a priority data stream comprising a weather storm warning can be superimposed on video content of a satellite system. The priority data would be indicated by a special packet that ends up as a signal on a display even though another channel is being watched.

One problem found with many security cameras is control of the bit rates. A system cannot simply combine all of the security camera outputs with other video content or the bit rates and packets can overflow or underflow the decoder buffers. The system disclosed herein shows how to time stamp the incoming packets and deliver them in an orderly process that merges very well into the flow of the gateway processing.

Advantageously, the present system shows how send priority real time data immediately through a system, even in systems that use a PVR, delay, or pause function. Accordingly, even when the main system is paused, the priority data is always shown in real-time. The present system also includes an alert notification to the viewer if the priority feed stream is interrupted as a potential tamper warning.

The present system shows how to implement priority MPEG transport signals using local content insertion or a targeted packet identifier (PID) number that are detected and allowed to flow through the system to the video decoders, even in instances where all other signals in the system get either paused or stopped. For example, in the case of security video, this feature assures the viewer that the video from security cameras being monitored is always in real-time. Further, if the priority data (e.g., security camera signal) is disrupted, the viewer is notified immediately that the frozen video might no longer be representative of real time.

In one aspect of the present principles, a system for processing data stream content in a multi-channel broadcast multimedia system is provided, the system comprising a packet processor having an input control having a filter module for detecting at least one priority data stream from an input data stream; and an output control including a format module for displaying the priority data stream in real-time. The packet processor includes an alarm detector for checking a rate of the priority data stream and issuing an alarm in the event of an alarm condition of the priority data stream.

According to another aspect, a method for processing data stream content in a multi-channel broadcast multimedia system is provided, comprising the steps of detecting at least one priority data stream from an input data stream, displaying the priority data streams in real-time, checking a rate of the priority data stream, and issuing an alarm in the event of an alarm condition of the priority data stream.

These, and other aspects, features and advantages of the present principles will be described or become apparent from the following detailed description of the preferred embodiments, which is to be read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, wherein like reference numerals denote similar elements throughout the views:

FIG. 1 is an exemplary illustration of a system having a typical MPEG receiver;

FIG. 2 is an exemplary illustration of a system having a pause packet processor configured for providing a pause function and managing a plurality of normal and priority data stream inputs according to an aspect of the present principles;

FIG. 3 is an exemplary method flow for pause processing at an input side;

FIG. 4 is an exemplary method flow showing how priority data is processed and flows through a pause feature at an input side according to another aspect of the present principles;

FIG. 5 is an exemplary method flow for pause processing at an output side showing how data is read and released to control the bitrate;

FIG. 6 is an exemplary method flow for pause processing at an output side showing how non-priority data is read from the memory;

FIG. 7 is an exemplary method flow for pause processing at an output side showing how priority data is read from the priority inputs according to an aspect of the present principles;

FIG. 8 is an exemplary schematic diagram showing how the priority and non-priority data streams are processed at an output side according to one embodiment of the present principles;

FIG. 9 is an exemplary schematic drawing of a main control functionally connected to a pause packet processor and configured for processing and outputting priority and non-priority data streams and detecting an alarm condition according to an aspect of the present principles; and

FIG. 10 is an exemplary flow diagram of a method for allowing selected priority data streams to flow in real-time through a system that is paused according to an aspect of the present principles.

It should be understood that the drawings are for purposes of illustrating the concepts of the present principles and are not necessarily the only possible configurations for illustrating the present principles.

DETAILED DESCRIPTION

A method, apparatus and system for sending priority data immediately through a system to be displayed in real-time, even in systems that use a video storage device or system such as a PVR for example, delay, or pause function is provided according to various aspects of the present principles, such that even when the main system is paused, any priority data is always displayed in real-time. The present system also includes an alert notification to the viewer if the priority feed stream is interrupted as a potential warning to alert the viewer that the priority data stream can have been tampered with.

Although the present principles will be described primarily within the context of permitting priority data to bypass systems having a pause capability, the specific embodiments of the present principles should not be treated as limiting the scope of the invention. It is appreciated by those skilled in the art and informed by the teachings of the present principles that the concepts of the present principles can be advantageously applied in other environments in which real-time display of priority data is desired, e.g., broadcast television/radio, satellite radio, cable, etc. and in systems which can not have any pause function or capability.

The functions of the various elements shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it is appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the invention. Similarly, it is appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which can be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

In accordance with various embodiments of the present principles, a method, apparatus and system is described for sending high-priority real-time data immediately through a system, even in systems having a pause or delay function, for real-time display to a viewer, for detecting possible tampering of the priority data and for notifying the viewer when the priority data is interrupted, potentially tampered with or otherwise is not being displayed in real time.

“Priority data” can comprise any data stream that is desired to be viewed in real time at all times, e.g., security video, data having time-sensitive information, etc. Data streams can be designated as comprising priority data manually by the user or automatically by the system according to pre-defined criteria. For example, priority data streams can be tagged with packets having a unique Packet Identifier (PID) number to identify them as comprising priority data.

“Non-priority data” can comprise any data stream that can be paused or delayed in the system and thus can be viewed in either real-time or delayed-time. Even in systems having a pause function, the use of a pause delay can be optional.

Referring now to the Figures, FIG. 1 is an exemplary illustration of a system having a typical MPEG receiver 103 configured for receiving data streams from various inputs such as a satellite tuner 101, interne inputs, 105, local camera inputs 107, and cable inputs 109. Receiver 103 can include MPEG decoders, and audio/video processors for processing the data streams for output to TV outputs 111.

A plurality of satellite tuners 101 (e.g., tuners (1 thru n)) can be provided, each tuner being configured to receive and process audio/video signals via, e.g., satellite. In the case of normal packet processor 103, each tuner 101 or a group of tuners (1 thru n) is connected to a network or packet processor 103 configured to process packet data transferred from each tuner 101. Multiple packet processors 103 can be provided. Packet processors 103 can include certain features or architectures to enhance and optimize packet processing, such as pattern matching (the ability to find specific patterns of bits or bytes within packets in a packet stream), data bit field manipulation (the ability to change certain data fields contained in the packet as it is being processed), and queue management (as packets are received, processed and scheduled to be send onwards, they are stored in queues).

FIG. 2 is an exemplary illustration of a system having a pause packet processor 203 configured for providing a pause function and managing a plurality of non-priority and priority data stream inputs according to an aspect of the present principles. Note the provision of a bypass path 223 through the delay/pause controllers 209, 211.

Pause packet processor 203 can be configured for providing a pause function and is connected to a main controller 205. Pause processor 203 can include a capture/input module 201, a memory 213 and an output module 204 each in functional communication with one another. The capture module 201 and output module 204 can include a plurality of buffers 202 (not shown in module 204), which can preferably comprise, e.g., first-in-first-out (FIFO) buffers configured to process data such that the first data to be added to the queue is the first data to be removed, and processing proceeds sequentially in the same order. It is noted that the buffers 202 can also be included in the output control 211 of module 204.

The memory 213 can comprise any memory device, such as a hard disk drive (HDD), and/or preferably a non-volatile, solid-state memory device such as flash memory, which can be a more durable, efficient and suitable storage media. Any amount of memory 213 can be provided as needed to cover the desired amount of data to be paused in a system.

Incoming data transport streams (which can include both priority and non-priority data streams) are input from tuners 101, as well as internet inputs 105, local camera inputs 107 and cable inputs 109 to the buffers 202 for processing by the input module 201. The input module 201 can include an input controller 209, which itself can comprise at least a system control 311, an incoming timestamp counter 313, and an outgoing timestamp counter 315 (shown in FIGS. 3-4). The incoming timestamp counter 313 adds marker values/timestamps to incoming packets to register and acknowledge when packets are received and to improve data flow. For example, the incoming timestamp counter 313 is configured for marking when each incoming packet arrives from the tuner (e.g., by applying a time-based marker value to each incoming packet) and the outgoing timestamp counter 315 provides time-based marker values for each outgoing packet.

According to one aspect of the present principles, the input controller 209 includes a filter module 409 for detecting priority packets and handling them accordingly to bypass their storage in memory 213.

FIG. 3 is an exemplary method flow for pause processing at an input side. FIG. 3 shows the details of the non-priority data flow through the pause feature and how the timestamps are added to keep track of the incoming data and a paused output. Note how the incoming data is time stamped with the IN_timestamp value and then the data is stored in memory.

To describe the method flow of FIG. 3, for example, in the case where non-priority data 301 is being received, the data is byte aligned (step 303), and if it is determined that there is a new packet start, a timestamp is added (step 309), preferably to the packet header (step 305). In addition, step 309 can include flagging the packet with an extra ‘start bit’ to show when a packet begins. An exemplary timestamp can comprise, e.g., a 16 bit counter with a known clock reference that can be reset, programmed, or pre-loaded by the system controller. For example, a time reference about equal to ½ of the minimum single packet delivery time (˜16 to 18 μs) can be used as the time stamp clock reference.

For example: Consider a 27 MHz clock reference that takes 1/27,000,000=37 ns per bit. Packets of 130 bytes*8 bits/byte=1040 bits. 37 ns*1040=38.5 μs per packet.

It is desirable to mark packets at least within one packet time so let's pick ½ of a packet time which is ˜19 us so the frequency would be 1/19us=˜53 KHz. As an estimate, we use 2̂10=1024 bits and took half of this as 512 which is 2̂9. Therefore:

Clock reference/(bits/packet)/2=27MHz/130*8/2=27MHz/520=˜52KHz

Note that the addition of timestamps can result in the addition of extra data to each packet. For example, whenever a start bit is found, two bytes of timestamp data can be added to the packet header. The time-stamped packets are then sent to the buffer 202 (step 307) and on to the memory 213 for storage. As an example, an unstamped packet can comprise 130 bytes versus a time-stamped packet at 132 bytes.

Preferably, the software (e.g., processor 203) can build and store a navigation table/register using set intervals of time to contemporaneously record the IN_timestamp and the memory address in memory 213 where this data starts. This register can be used to keep track of where data is found in memory 213 with respect to its timestamp. Advantageously, this would enable very quick access to the desired data once a known delay or pause period is defined.

The outgoing timestamp counter 315 provides the output timestamps. Note that the OUT_timestamp counter 315 can be analogous in configuration and operation to the IN_timestamp counter 313. The outgoing timestamp counter 315 can use the same type of counter and same clock reference as the input timestamp counter 313 but the specific outgoing timestamp value will typically be equal or less than the incoming timestamp counter. This is because the outgoing counter 315 provides the timestamp for the memory access that represents the time that the viewer is watching. When a pause occurs (pause mode/period begins), the outgoing counter 315 is stopped until the pause period is ended. This pause in the counting means the outgoing count/marker value normally is lower than the incoming count value. The outgoing counter reference with a lower value than the input counter reference indicates that the value is further back in time, which tracks the location of the start of the pause feature in the time domain.

The outgoing counter 315 is configured to be able to be reset, programmed, and/or pre-loaded by the system controller 311. Both counters 313, 315 are cleared at the start of the video service and begin counting, e.g., by setting both count enables high. The IN_timestamp counter 313 is constantly counting/marking incoming packets independent of any pause mode (i.e., regardless of whether the system is in a pause mode or non-pause mode) since it provides the timestamp/marker value for incoming data. The OUT_timestamp counter 315 also counts and follows the IN_timestamp counter 313, but stops incrementing/counting whenever a pause mode is enabled.

The pause processor 203 is configured to constantly watch and check for activation/triggering of a pause signal 310. If a pause signal 310 occurs, thus enabling a pause mode, the input system control 311 stops the OUT_timestamp counter 315 from ‘incrementing’ (e.g., marking with further successive time-based marker values) for the duration of the global pause period/mode. One primary difference between the use of the counters 313, 315 is the offset in the OUT_timestamp counter 315 that is used to provide a real time output reference for the stored data. That is, when a pause period is over, the output timestamp counter 315 is referenced by an output program in the output controller 211 to find the corresponding input timestamp bytes that were captured when the packets arrived from the input counter 313. This output counter reference can comprise, e.g., the input timestamp counter minus the number of counts that represent the equivalent delay of the pause period. In one exemplary embodiment, the number of counts of the pause period can be programmed into the output counter 315 by the input system control 311.

By stopping the output counter 315 from incrementing during the pause period, the dataflow operation becomes automatic without requiring controller intervention. The system controller 311 could also read the output counter and then could add or subtract values from the OUT_timestamp counter 315 if repeated data or skipped data is desired. The output will then start counting again to provide the appropriate output timestamp reference until the next pause mode occurs. Note that if the output counter stops incrementing, the output data also stops since all of the incoming data timestamps are greater than the value being examined.

For example, in the timeline shown below (Example 1) depicting an exemplary period of 20 minutes of streaming data content, a 5 minute pause period occurs starting from minute 10 to minute 15. While the data input continues to be written throughout the entire 20 minutes, at 10 minutes, the data output (reading) is stopped and the outgoing timestamp counter/marker value is noted. When the pause period is over at minute 15, the output counter searches for the output timestamp counter value (minute 10) in the input time-stamped data to resume playback starting from minute 10. Note that after the pause, the next packet of data output would be the one following the last packet sent before the pause. The primary purpose of the timestamp counters is to ensure that the original transmission bitrate is maintained to avoid MPEG buffer overflows or underflows.

Example 1

		10 min	15 min
	0 min . . .	(pause start)	(pause end) . . .	20 min.
In count:	0 . . .	10 . . .	15 . . .	20 . . .
Out count:	0 . . .	10 . . .	11 12 13 . . .	15 . . . 20

The input controller 209 is configured for both writing and reading the non-priority streaming data to or from memory 213. Details of the read and write operations and signals of the memory controller and interfaces are well known in the art and are not shown in the Figures.

Note that according to an aspect of the present principles, the controller 209 is configured to continuously write only non-priority incoming data streams to the memory 213. During a pause period, although the system would not be reading (outputting) the non-priority data from the memory 213, incoming data would still need to be written. When the pause period is over and playback is resumed, both reading of the playback data and writing of the incoming data are simultaneously performed.

FIG. 4 is an exemplary method flow showing how priority data 401 is processed and flows through a pause feature at an input side according to another aspect of the present principles. Namely, FIG. 4 shows how the details of how priority (e.g., security) data flows through a pause feature and how timestamps are added to keep track of the incoming data. In FIG. 4, for example, in the case where at least one priority data stream 401 is being received, initially they are byte aligned (step 303). A filter module 409 is provided for assessing the packets and detecting priority packets (security packets). Priority packets can be provided in priority data streams having a special, unique PID number to enable their recognition. That is, special packets can be filtered to become priority packets from the satellite by monitoring the packet header of the incoming data. The filter module 409 can comprise a control that checks for a new packet start and at the same time, searches for a specific priority packet, and then sends it to the security processor for the timestamp and processing. This would allow selection of, e.g., any one channel or transponder to have a non-paused video in a normally paused system. If it is determined that there is a new packet start, a timestamp is added (step 305). In 409, the packet can be flagged with an extra ‘start bit’ to show when a packet begins.

It is noted that the filter 409 can be configured to detect a priority packet under any circumstance, regardless of whether the system includes a pause function or not. A detected priority data stream can accordingly cause an alert (e.g., an icon, symbol or message) to be displayed to the viewer on a screen in addition to any other normal (non-priority) video being watched. Such an alert message can be displayed simultaneously with the normal video being watched. For example, a tornado alert can be designated as a priority data stream, which could be superimposed on the video content of a satellite system. This aspect would not require a pause function to be present but it would still be a special priority packet that ends up as a signal on a display even though another channel is being watched.

As shown in FIG. 4, note that priority data is time stamped with only the OUT_timestamp value 315 (as opposed to non-priority data, which is time stamped with the IN_timestamp). The priority data is then sent to a FIFO buffer that corresponds to a similar FIFO used on the output side of the memory for normal data.

In step 411, the priority packets 413 and their start bits 414 are stored in buffers 202 for being sent out directly to the output control 211 via multiplexer 223 to be multiplexed with non-priority output from the memory 213.

FIG. 5 shows the normal output side of the pause processing. Note how the stored IN_timestamp and the OUT_timestamp are compared and processed. The output module 204 can include at least an output controller 211 which can comprise at least an output system control 513, state machine 515, a buffer 505. The output system control 513 can include a comparator module configured to check the incoming timestamps 517 of the data coming from memory 213 versus the desired timestamp to ensure that the bit buffers downstream do not overflow during the MPEG processing. As described above, for example, an additional bit in the FIFO can be used to flag the beginning of every packet to help count bytes as well as flag the timestamp in each packet.

The incoming non-priority data 501 is streamed from the memory 213, and each new packet is marked with a start flag (step 507). That is, each start of packet can be marked on an additional bit (step 503) and sent to the “Show-ahead” FIFO (505). For example, in the case of a 16 bit packet, one additional bit (bit 17) can be added. A “show ahead” type of FIFO places the data for the next read on the output bus so that only a read is required to latch the FIFO data value. In addition, this ensures that the timestamp can be found whenever the start bit (bit 17 in this example) is equal to ‘1’.

The system will not read the next packet of data from the FIFO until the system controller/comparator 513 compares the OUT-timestamp 319 with the IN-timestamp 517. In this example, when the start flag is equal to ‘1’ and the OUT and IN-timestamps are equal values, the next packet is read. Advantageously, this re-creates the original bit-rates found when the data was initially received, which avoids overflow of the MPEG buffers downstream. Once the values are equal, the state machine 515 will enable the read for an entire packet. The state machine 515 will stop the data flow again until the IN_timestamp 517 (e.g., found in the header data stored in the flash memory) is less than or equal to the OUT_timestamp 319.

Playing back content that is regulated by the timestamps/marker values ensures that the original transport bit rates are being reconstructed on the output data from the memory 213. These original bit rates were carefully constructed at the transmitters to be sure that the MPEG bit buffers will not overflow or underflow during the decoding of the transport streams.

FIG. 6 is an exemplary method flow for pause processing at an output side showing how non-priority data is read from the memory. FIG. 7 is an exemplary method flow for pause processing at an output side showing how priority data is read from the priority inputs according to an aspect of the present principles.

FIG. 6 is very similar to FIG. 5 but the system control block 513 is being merged with the blocks shown on FIG. 7. The output 601 comprises non-priority data to be sent to output control 211 for processing. FIG. 7 shows the difference from FIG. 6 in the way the security packets are handled, namely that the incoming data 701 comes from the priority data input 413 and priority packet start bits 414 and not from the memory 213. The priority data is stored in buffers (703) awaiting output to output control 211.

FIG. 8 is an exemplary schematic illustration showing the output controller 211 in a combined system wherein both the priority and the normal (non-priority) data are merged to show how the timestamps of the non-priority data 601 and the priority data 703 are compared to provide an orderly streaming of the video content with both, with the normal data capable of being paused and the priority data not capable of being paused. The available non-priority video data and available priority data are multiplexed (step 801) and output to the decoders (step 803).

As shown in FIG. 8, note that the bitrates are still maintained with proper timing to prevent either overflow or underflow of a receiver downstream. The state machine 515 also includes an alarm data compiler 805 that includes rate information for the priority packets. For example, the alarm information reports the bit rate and any deviations from the bit rate for one priority data stream. In more complex systems, the alarm data output 805 can be configured to track all the priority data streams and extract some information from the MPEG packets. Other embodiments can be contemplated in which the priority packets can also be encrypted, so decryption keys and processing can accordingly be included in the system.

FIG. 9 is an exemplary schematic drawing of a main control 205 configured for processing and outputting priority data streams 903 and non-priority data streams 901 from MPEG outputs 803, and detecting an alarm condition in response to alarm data 805 according to an aspect of the present principles. The main control 205 includes a video formatter 907 and an alarm detector 905. The alarm detector 905 in an alarm state would send a signal to the video processor 907 to inform the viewer not to trust the security data or to carefully monitor the data. The alarm detector 905 monitors the priority packets being processed. If the data stops or is interrupted for a time period, a special message packet ('alarm packet') is preferably displayed on the screen (TV/monitor) to indicate to the viewer that an alarm condition exists, e.g., that the data flow has stopped or has been interrupted.

The video format module 907 is configured to display the priority video data along with the non-priority video data. For example, the priority video can be displayed contemporaneously with the non-priority data on a split screen, picture-in-picture (PIP), etc., to display the priority data on screen at all times, in addition to the normal, non-priority video.

An alarm feature according to an aspect of the present principles is advantageous, since a disrupted MPEG can freeze a picture on the display and in the case of a security video, can make a security camera look as if everything is static while some activity that is actually occurring is being masked. A criminal could damage the camera to stop the flow and the hope to freeze the picture to look normal to the guard. By monitoring the packet flow and generating an alarm message, an alarm can be sent out to be displayed on the screen to make the guard aware of the situation.

FIG. 10 is an exemplary flow diagram of a method for allowing selected priority data streams to flow in real-time through a system that is paused according to an aspect of the present principles. In step 1001, a transport data stream is received and processed. If priority data streams are detected in decision step 1003, the priority streams are filtered out and sent directly for processing and display to the viewer, while any non-priority data streams are stored to memory (step 1007). If there are no priority streams detected, the ‘normal’ data streams are stored to memory and processed normally (step 1005). For example, the non-priority data streams can be displayed in real-time or at a paused/delayed time.

In step 1009, the non-priority data streams and priority data streams are mixed and output to the decoders. In addition, alarm data (e.g., rate information for the priority packets) is compiled and sent to an alarm detector for processing. For example, the alarm data comprises the bit rate and any deviations from the bit rate for the priority data stream.

In step 1011, the normal and priority streams are processed for display to a viewer and formatted if desired, to be displayed, e.g., simultaneously on a screen. In decision step 1013, it is determined whether an alarm condition is detected (e.g., a discontinuous packet stream). If no, the method returns back to step 1011. If yes, an alert message is created and displayed to the viewer (step 1015) and the method returns to step 1011.

Although the embodiment which incorporates the teachings of the present principles has been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments for a system and method for allowing selected priority data streams to be displayed in real-time in a broadcast program multimedia system (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes can be made in the particular embodiments of the principles disclosed which are within the scope and spirit of the inventive principles as outlined by the appended claims. Having thus described the invention with the details and particularity required by the patent laws.

Claims

1. A system for processing an input data stream content in a multi-channel broadcast multimedia system, the system comprising:

a packet processor having an input control for detecting at least one priority data stream in the input data stream; and an output control including: a format module for formatting the priority data stream for display in real-time; and an alarm detector for checking a rate of the priority data stream and issuing an alarm in the event of a discontinuous packet stream of the priority data stream.

2. The system of claim 1, wherein the at least one priority data stream is representative of data which is designated as being desired to be displayed in real time at all times in the multimedia system.

3. The system of claim 1, wherein the output control includes a buffer for storing the detected at least one priority data stream.

4. The system of claim 1, wherein the output control includes a multiplexer for mixing the at least one priority data stream with non-priority data streams.

5. The system of claim 1, wherein the input control includes an outgoing timestamp counter configured for time-stamping the priority data with an outgoing timestamp value.

6. The system of claim 1, wherein the input control includes an incoming timestamp counter configured for time-stamping non-priority data with an incoming timestamp value.

7. The system of claim 1, wherein the input data stream includes non-priority data streams.

8. The system of claim 6, wherein the format module is configured for displaying the at least one priority data stream in real-time contemporaneously with the non-priority data streams.

9. The system of claim 1, wherein the output control includes an alarm data compiler for collecting alarm data comprising data rate information of the priority data stream and outputting the alarm data to the alarm detector.

10. The system of claim 1, wherein the packet processor is configured for receiving data streams from a plurality of data sources including satellite tuners, internet inputs, local camera inputs, and cable tuners.

11. The system of claim 7, wherein the packet processor includes a memory for storing said non-priority data streams.

12. A method for processing data stream content in a multi-channel broadcast multimedia system, comprising the steps of:

detecting at least one priority data stream from an input data stream;

displaying the priority data streams in real-time;

checking a rate of the priority data stream; and

issuing an alarm in the event of a discontinuous packet stream of the priority data stream.

13. The method of claim 12, wherein the at least one priority data stream is representative of data which is designated as being desired to be displayed in real time at all times in the multimedia system.

14. The method of claim 12, further comprising the step of storing the detected at least one priority data stream in a buffer.

15. The method of claim 12, further comprising the step of mixing the at least one priority data stream with non-priority data streams.

16. The method of claim 12, further comprising the step of time-stamping the priority data with an outgoing timestamp value.

17. The method of claim 12, further comprising the step of time-stamping non-priority data with an incoming timestamp value.

18. The method of claim 12, wherein the input data stream includes non-priority data streams.

19. The method of claim 16, further comprising the step of displaying the at least one priority data stream in real-time contemporaneously with the non-priority data streams.

20. The method of claim 12, further comprising the step of collecting alarm data comprising data rate information of the priority data stream.

21. The method of claim 18, further comprising the step of storing said non-priority data streams in a memory.