Patent Application
20110023079
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.
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.
In the drawings, wherein like reference numerals denote similar elements throughout the views:
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.
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,
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).
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
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.
To describe the method flow of
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.
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.
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
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.
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.
As shown in
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.
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.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2008/012454 | 11/4/2008 | WO | 00 | 9/9/2010 |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 61070074 | Mar 2008 | US |
| Child | 12736096 | US |
