Patent Application
20100333164
Providing a pause function in a real time digital streaming environment with hundreds of channels available, such as in an airplane satellite system, presents a challenging problem. This is especially so since the viewer is normally not in control of the video/audio program other than selecting what is available. If a video service is offered on a closed system, such as an airplane, etc., it is desirable to vary program viewing schedules according to the actual times of departure of the transportation service. However, the program times of multimedia content delivery services do not change in most circumstances. By using a pause function, programs can be offered that actually start at the time a closed system such as a plane or bus leaves, in order to give the passengers optimal viewing time of the programs during the time spent in transport. Passengers might even have an option to use a paused or a real-time (not paused) program. However, the complication with such a system is that the clocks, the program guides, and the control system must be able to respond to delays that can not be determined until the vehicle or flight departs. Furthermore, while a large memory and a global pause function can provide a time delay to adjust a presentation time of a program, the length of each program is still fixed.
Normally one cannot simply change the presentation speed without going into trick modes or re-encoding the content after dropping frames in the content. The broadcasters time adjust their movies by dropping frames in the original movie and then modulating or encoding the result for transmission. All of the clocks in this type of system remain per standards due to FCC requirements. During trick modes, the audio is typically disabled, and any closed-captioned content is not able to be viewed as well. Accordingly, a system and method for adjusting a total playback time and rate for a desired program while preventing overflow or underflow errors in media content and allowing audio data to be delivered concurrently on a multi-channel, satellite system, is highly desirable.
In one embodiment according to the present principles, a system and method is provided for controlling and adjusting total playback times/presentation rates of broadcast multimedia content, for example, satellite program content on, e.g., an aircraft, bus, train, theater, etc.
Advantageously, the actual playback times of programs provided by program service providers can accordingly be modified to be accelerated or reduced to accommodate the schedules and/or databases of systems provided by travel service industries, such as airlines.
A system and method according to the present principles is particularly applicable to systems in which a global pause feature is provided to store all delivered streams in a memory for delivery of the streamed content to viewers at, e.g., delayed start times. Such global pause-enabled systems can be configured to store all of the desired program content from all sources up to a limit of the system's bandwidth and to enable each program to be played back from the beginning at pre-determined start times. Thus, a viewer can select a desired start time of a desired program.
Such a global pause system can be simplified, e.g., by providing all of the pause functionality close to the tuner outputs. This eliminates requiring each passenger's set top box to include local storage to provide a pause function. In addition, the passengers do not have to worry about handling and implementing the control functions since the saving and resuming procedures would be automatically performed for all of the programming content. In addition, the data rate for incoming signals can be handled efficiently as one entire system versus handling each channel independently, further simplifying the system's operation and increasing efficiency.
In one aspect of the present principles, a system for controlling playback time for stored transport stream data content in a multi-channel broadcast multimedia system having a plurality of system components is provided, the system comprising a pause packet processor having a memory for storing said stored transport stream data; and at least one receiver is connected to the pause packet processor for receiving the stored data; wherein at least one of the pause packet processor and the receiver includes a command module configured for enabling an oscillator frequency change in the system components for altering the playback time for the stored data at the receiver.
According to another aspect, a method for controlling playback time for stored transport stream data content in a multi-channel broadcast multimedia system having a plurality of system components is provided, the method comprising the steps of storing said stored transport stream data content; controlling a clock reference in the system components to alter a playback time of the stored data content; and receiving the stored data content at an altered playback time.
These and other aspects, features and advantages of the present principles will he described or become apparent from the following detailed description of the preferred embodiments, which is to he read in connection with the accompanying drawings.
In the drawings, wherein like reference numerals denote similar elements throughout the views:
It should he 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 controlling playback time for stored transport stream data for broadcast programming is advantageously provided according to various aspects of the present principles. Although the present principles will be described primarily within the context of an aircraft (in-flight) programming and program guide pause system and method, 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 playback time control is desired, e.g., broadcast television/radio, satellite radio, cable, etc., in environments having contained, limited audiences such as theaters, and in transportation means such as buses, trains, etc.
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 controlling playback time of stored program data on, e.g., a personal video recorder (PVR) by controlling and applying a main clock reference from the pause processor down to the passenger's video monitor.
While the present principles can be applicable to any broadcast multimedia content system, the examples herein are described in relation to, e.g., aircraft satellite multimedia content environments in which multimedia content is displayed to passengers either individually, e.g., in seat-back displays, or in groups, e.g., via a plurality of displays distributed throughout the passenger cabin. Generally, most system providers provide systems with individual controls since people generally desire independence in controlling programming content. However, passengers on trains, buses, theaters, and especially airplanes, tend to be captive audiences. In addition, transportation vehicles typically have varying departure times and schedules, which do not necessarily match broadcast program schedules. Moreover, in certain situations accelerated or slowed-down playback of content is desirable.
Thus, a system-wide program playback control feature in accordance with the present principles is especially desirable and useful.
A system and method according to the present principles is particularly applicable to systems which can implement a ‘global’ pause function to store the data and control the playback of the data. It is to be noted that each receiver (set top box) can be configured for local storage and allows individual user-enabled ‘local’ pause functions (e.g., to allow each user to activate a pause mode to pause content at a user-desired time). However, a ‘global’ or universal pause feature does not require user activation and minimizes storage requirements for each set top box receiver. Note also that a global pause function (e.g., a pause function next to the tuners) advantageously allows users/viewers to change content or channels or customize viewing schedules during, e.g., a flight without encountering problems such as loss of data created with previous pauses. For example, a local pause function at each viewer's set top box would typically cause the loss of data whenever a channel change occurs after a pause has been implemented. The loss of data would be the time equal to the sum all of the pauses up to the point of channel change.
A system and method according to the present principles shows how to control and alter playback time for stored transport stream data on a PVR by controlling a main clock reference which is applied from the PVR all the way through to each viewer's video monitor. Adjustment of the playback time is useful to accelerate or reduce the actual play time of each program to accommodate the schedules and/or databases of systems in travel service industries such as airlines.
While program service providers want to provide live video services on a plane, the plane schedules do not always correspond to the typical 30 minute intervals found in most programming. A large memory can provide a time delay to adjust a presentation time but the length of each program is still fixed.
Normally a set top box (STB) and a TV have their own time references that are used to accept outside signals. According to the present principles, in a self contained system such as, for example, an airplane, programs can be placed in memory and then played back using a controlled clock. This clock can also be provided to the STB and the viewer's monitor to allow deviations from a typical standard clock reference, such as National Television System Committee (NTSC) specifications, including those adopted by the Advanced Television Standards Commission (ATSC). Advantageously, a system and method according to the present principles can adjust the video and audio streams to play content either faster or slower by varying the reference clock, i.e., providing a ‘controlled clock’.
An airplane multimedia content system, for example, is typically a self-contained large number of set top boxes. In such as system, it has been found that modulating the clock can help adjust the length of each program's presentation time. The speedup of the clock can vary from 1.0× to 1.5× with a typical advance being 1.2×. The 1.2× processing is very watchable, comprehendible, and is the simplest to process. Advantageously, during either a speedup or slowdown of a presentation, the audio is still output and the video is provided in a format which is clearly discernible to the viewer.
Using a controlled clock reference as a source to change the length of each program's presentation time is extremely useful. A feature of the system is that everything in the system such as the audio decoders, video decoders, bit rates, buffers, and display will all track the controlled clock reference, thus avoiding buffer overflows, beats, or discontinuous sound or pictures.
According to one aspect, this technique could be varied based on the type of content, for example, the news could be watched at a much faster clock since it is primarily a transfer of information, while a movie is much slower and thus attention to detail in motion and sound is more common. Movie credits could be displayed at a much faster rate than the movie as is often the case with programs on TV.
A plane can have, e.g., three receivers per row so the clock references to all three receivers are controlled separately. This is possible by sending data packets over Internet Protocol (IP) that are unique to clock reference commands to control each set top box individually. The streams coming out of memory are released based on the timestamps of the controlled clocks. If 10 different clock domains are desired, 10 different bit rate output first-in-first-outs (FIFOs) would be needed to control the data rates for all ten sources. The different rates would be found on the IP line but each receiver ingests the data using the same clock frequency that was used for the output from memory. This prevents over or underflow errors from occurring.
Referring now to the Figures,
A plurality of tuners 101 (e.g., tuners (l through 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 102, each tuner 101 or a group of tuners (1 through n) is connected to a network or packet processor 102 configured to process packet data transferred from each tuner 101. Multiple packet processors 102 can be provided. Packet processors 102 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).
Each packet processor 102 is connected to a main controller 205, which itself is connected to and controlled by a switch 207. The switch 207 can comprise, e.g., an 8 port 1000 base T switch and can be configured for controlling signal output to a receiver 209 which can be connected to any number or grouping of seats (e.g., receiver 209 can be connected to a plurality of seats or seating ‘zones’). For example, switch 107 can be configured for distributing signals to a plurality of zones, each zone including a set top box (STB) receiver 209 which can be functionally connected to a plurality of seat monitors. Any number of seats per STB receiver can be contemplated. For example, each STB can be is connected to each other via a ‘daisy chain’ wiring scheme (electrical bus) configuration.
Pause packet processor 103 can he configured for providing a global pause function e.g., in an aircraft satellite multimedia system. The processor 103 can include a capture/input module 203, a memory 211 and an output module 204 each in functional communication with one another. The capture module 203 and output module 204 can include a plurality of buffers 213 (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 213 can also be included in the output control 217 of module 204.
The memory 211 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, especially in high-altitude environments where air pressure might fluctuate, such as in airplane cabins. Since the majority of interruption periods, e.g., during a flight, can comprise announcements lasting only a minute or two, a minimum amount of memory is needed to cover a minimal system. Preferably, the memory 211 has storage capacity of, e.g., at least about 45 Mb/s for each transponder (an exemplary system setup can comprise, e.g., 32 tuners tracking 32 transponders).
Incoming data transport streams are input from tuners 101 to the buffers 213 for processing by the input module 203. The input module 203 can include an input controller 215, which itself can comprise at least a system control 311, an incoming timestamp counter 313, and an outgoing timestamp counter 315 (shown in
In
The actual frequency of oscillator 210 is a reference that is used to derive a system clock that is needed for the transfer of data depending on the word size, frame rate, picture size, etc. According to one aspect of the present invention, the oscillator 210 can be altered to accordingly alter the playback time of a video. For example, by changing oscillator 210 by +20%, the controlled byte clock 410 will also change by +20% to keep the system working at the +20% change.
According to another aspect, described further below with reference to
To describe a 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/9 us=˜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/(hits/packet)/2=27 MHz/130*8/2=27 MHz/520=˜52 KHz
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 213 (step 307) and on to the memory 211 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 103) 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 211 where this data starts. This register can be used to keep track of where data is found in memory 211 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 global 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 global pause mode is enabled.
A system and method according to the present principles provides a processor 103 configured to constantly watch and check for activation/triggering of a global pause signal 310. If a global pause signal 310 occurs, thus enabling a global 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 217 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 looked for.
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 timestamped 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 215 is configured for both writing and reading the streaming data to or from memory 211. 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 output module 204 can include at least an output controller 217 which can comprise at least an output system control 513, state machine 515, a buffer 505, and an output circuit 219. The output system control 513 can include a comparator module 513 configured to check the incoming timestamps 517 of the data coming from memory 211 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.
In one exemplary embodiment, as shown in
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.
An exemplary method for providing a global system pause function in a broadcast multimedia content system can be described as follows. While the system is waiting to be enabled (e.g., for the multimedia content service to be activated or on), the packet processor sets both incoming and outgoing timestamp counters equal and watches for a pause or interruption period to occur.
If a pause occurs, a pause mode is enabled and the outgoing timestamps (OT) are stored. During the pause mode a reference table is preferably created showing, e.g., incoming (IT) timestamps, tuner data, and start and end flash/HDD storage locations. The incoming data stream is preferably stored in the memory 211. In one exemplary embodiment, each user set top box (STB) can receive a message to indicate a pause mode, e.g., each STB can receive another data stream with a still picture, on-screen display (OSD), or a picture freeze with overlay to indicate a pause mode. During the pause mode, the system constantly checks to see whether the pause has ended. If the pause is stopped/ended, the timecodes (e.g., counter/marker value) and end address corresponding to the pause stop time are stored.
At a ‘pause end’, the OT counter is programmed with the pause_start location and data is streamed from the memory 211 to each set top box (receiver). That is, the navigation table is referenced to find the starting address for the IT timecode/marker value equal to the pause_start location, and the data is then read from the memory 211 between the start and end addresses. For example, if the pause has ended, the processor looks up pause_start=OT location in the stored IT table to get memory address location for data beginning at the pause_start. The next HDD read is found as the next table entry, and so on.
The streaming is continued using the OT as the timestamp reference while the incoming data is marked with the IT counter. If another pause occurs, the OT register value at pause_start is stored and a pause mode is entered again until the pause mode ends. The above steps will continue until a pause is encountered again or the TV service is ended.
Advantageously, 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 211. 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. This is also why the use of solid state flash can be advantageous over HDD magnetic disc drives in the present application since the HDDs can have large variations in the access times for reading and writing data while flash drives do not.
When all of the control oscillators 210 are being used, the packets being sent from the set top box controller 607 is released at the appropriate time and with the appropriate time stamps since none of the time stamps have to change. The controlled oscillators 210 track each other to handle all rate problems, time stamp issues, and decoding buffer issues.
The controlled oscillators 210 could be configured in multiple ways in the system. For example, according to one embodiment as shown in
A second configuration could be used which provides the ability to directly send the desired frequency or change of frequency desired by using a command from the IP connection (e.g., implemented at command module 608) to all of the controlled oscillators 210.
Referring to
The viewer's requested program content (MPEG buffers) as well as the outgoing time stamp counter value from 319 is sent to the STB controller 607 for decoding. Clock sync 613 regulates the packets going into the decoder at the correct bit rate. The audio/video is output to audio/video processor 615 for video display to the viewer on monitor 617 and audio output 619. In the case of a speeded-up clock, some issues that can result are related to the motion occurring a bit faster than real life and the audio pitch shifting to a higher frequency and pitch. Accordingly, the controlled clock 210 data is fed to the audio/video processor 615, so that the audio processor can see both the local clock 110 and the controlled clock 410. This enables a frequency shift to be performed as needed to keep the voices sounding natural even at higher play rates.
In step 903, a clock reference, such as an oscillator, is controlled or modified to alter a playback time of the stored data content to a user. As described above, the command to initiate a playback time change can be initiated by a viewer or by the system (e.g., the system can provide an accelerated program in its program guide, which would automatically initiate the altered playback). The playback time can be controlled to slow down or speed up playback of the data content by changing the oscillator frequency in the system components. The controlling of the clock references can include switching from a normal playback mode to an altered playback mode, and vice versa.
In step 905, the user receives the stored data content at an altered playback time in accordance with the communicated command. For example, if the command to initiate a playback time change was to increase the total playback time, the playback of the data content would be slowed down, whereas if the command was to decrease the total playback time, the playback of the data content would be speeded up.
Advantageously, the ability to provide a command communication would provide a frequency or a change of frequency to an oscillator synthesis IC to generate the desired controlled oscillators 210. When every part of the system uses the same variable control oscillator frequency, the MPEG and other types of transport streams will track with all of its time codes for both the Presentation Time Stamp and the Decode Time Stamp. In contrast, in most systems found today, the oscillators are fixed in the design. This creates a major burden on the processors, as they are required to modify the time stamps for all of the packets in order to alter the playback time of the video. This is especially difficult in an encrypted system since the video would first have to decrypted, analyzed, time stamped altered, and then re-encrypted before being delivered to the audio/video processor 615. In a content server system, all of these steps would be required for all of the hundreds of video streams on an individual basis in order to enable a playback time change, which would present an extremely complicated system.
Thus, one significant advantage of the present system is that the change in playback time/speed change is accomplished without ever decrypting the content within the server packet processor. Thus, there is no compromising of the encrypted content since it is not decrypted in the first place, nor would the server ever have to possess the decryption keys. Accordingly, a system and method according to the present principles solves many of the complications of speeding up or slowing down encrypted video on a server with hundreds of video streams.
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 altering playback time for stored data in a broadcast program multimedia system (which are intended to he illustrative and not limiting), it is noted that modifications and variations can he 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, what is claimed and desired protected by Letters Patent is set forth in the appended claims.
This application claims priority to provisional application entitled “STREAMING DATA PAUSE FUNCTIONS” with Ser. No. 61/070074 filed on Mar. 20, 2008, incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2008/013273 | 12/2/2008 | WO | 00 | 9/2/2010 |
| Number | Date | Country | |
|---|---|---|---|
| 61070074 | Mar 2008 | US |
