Patent Application
20100017532
The present invention relates to transport stream migration mechanisms for streaming TV content over IP networks.
Internet protocol-television (IPTV) is a distribution system for TV content over IP-based networks. Previously, this content has been carried over other mediums (e.g. satellite, cable) and standards exist describing the transportation of content (in “transport streams”). In IPTV, the content is carried over an IP-based network, for example, using user datagram protocol (UDP) and possibly multicast (for efficiency purposes). IPTV management systems known in the art are used to configure and monitor the servers and server workgroups delivering content to users. They are also used to create and maintain the network channels over which the incoming streams are played out. Other tasks may include the generation and modification of conditional access (CA) criteria to be applied to incoming streams and adding individual CA events to channel schedules. Such systems are generally physically comprised of hardware and software installed on a server. The hardware fitted varies from system to system according to the interfaces and features required by each content provider. An exemplary system, known in the art, is StreamShaper™ (commercially available from NDS Limited, 1 Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex UB7 0DQ, UK).
Such IPTV delivery systems may be used for translation, for example, of MPEG-2, MPEG-4 and AC3 elementary streams contained in an MPEG-2 transport stream from a broadcast environment (e.g. where the content is already made available to satellite delivery equipment) to an IP environment. (MPEG-2 is an industry standard for video and audio source coding that is also known as ISO/IEC 13818[1]. MPEG-4 is also known as ISO 14496-2. AC3 is an industry standard for audio encoding defined by the advanced television systems committee.) In an exemplary preferred embodiment, translation from a broadcast environment to an IP environment comprises receiving an MPEG-2 transport stream from a DVB-ASI (digital video broadcasting-asynchronous serial interface) source, decrypting and/or encrypting selected services (where content protection is used), and then streaming them over an IP network to set-top boxes where the services can be viewed. In an alternative preferred embodiment, such IPTV delivery systems may act as a gateway between IP networks.
Set-top boxes may be IP enabled Content protection can be applied to individual services to restrict viewing to suitably entitled subscribers. Persons skilled in the art will appreciate that set-top boxes are named by their usual location on top of a television set, but that the term “set-top box” is not meant to limit the location of the set-top box relative to a television set with which the set-top box is associated, it being further appreciated that televisions with integrated set-top box functionality are also known in the art.
One of the major problems facing manufacturers of equipment systems used for television content delivery is the ability to provide non-stop, uninterrupted operation all the time (true 24X7 service), such that there are no picture glitches in the event of equipment failure or upgrades. This is a problem whether content is digitally broadcast or delivered on IP networks. IPTV delivery systems known in the art generally support failover mechanisms such that if a server cannot stream, another server will take over as soon as possible. Exemplary reasons why a server may not be able to stream comprise a fatal software crash, lost connection with the conditional access system, routine maintenance and/or upgrade to the server, an operating system patch, etc.
The system latency (the time taken for data to propagate from the input to the output of the server) on a stream is configurable but is generally at least one second (as this gives a good balance between excessive delay and the ability of the server to smooth out bursted input). The process of failover is reactive, i.e. once the error has been detected on the live server, the server is stopped, and the target machine(s) takes over. Therefore, there is always a minimum service outage equal to the system latency. Additionally, the conditional access system is not able to activate instantly. Typically, at least two seconds will elapse before control words and entitlement control messages (ECMs) arrive at the target machine when using CA systems such as Videoguard™ (commercially available from NDS Limited). This delay may be closer to ten seconds if a large number of channels are serviced. Even once the control words have arrived, it is not possible to start streaming immediately since ECMs must stream for some period of time before the control word can be used; a typical safe period is one second. The delay before content streaming begins may be necessary to give the set-top box (STB) sufficient time to generate the control word for that ECM in order to decrypt the content. Finally, the control word can only be activated on an I-frame (up to a 0.5 second delay in a typical MPEG-2 video elementary stream). Summing all of these delays means that the whole process can result in an outage of ten seconds or more.
When a server suddenly fails (software or hardware) and is no longer able to stream, there is little that can be done to avoid the ten second delay. When a server is properly streaming content, content providers may be reluctant to do anything to interrupt. Potentially this reluctance could delay maintenance and/or upgrades. Additionally, if the server is running on PC hardware and connected to a network, virus protection software may need to be run. Running of virus protection software may interfere with the behavior of the server and would therefore generally be run as a scheduled task preferably, when the server is not streaming.
In a small installation, a “dual hot” failover configuration can be used. In this situation, two servers will both stream the same transport streams into the same IP network switch. The failover management system will use the network switch to control which server is live (in other words, which server's transport streams are delivered) and which is the target (or back up). At a point of failure the failover management system will change the configuration of the switch so that the output of the target server is used instead of the output of the live server. One difficulty with this approach is that at the changeover point, while the underlying content is the same, the encryption applied may not be. Therefore, there is generally a delay since the STB must wait for the first ECM after the changeover and then for the first I-frame to begin decryption/decoding. With an ECM carousel rate of one second (the typical default for a Synamedia™ IPTV deployment, commercially available from NDS Limited) and 0.5 seconds between I-frames (the typical gap in MPEG-2 video streams), the delay can be anything up to 1.5 seconds. The delay may be considerably longer if the polarity of the control word on the two servers is the same but the control words are not. In this situation, the STB would need to wait for the next control word (typically 10 seconds between control word changes). This also assumes that the control software and/or switch are able to instantaneously turn off the live port and activate the target port. “Dual hot” configurations are also susceptible to complete failure if the error causing the failure is caused by the input to the servers (as both will fail simultaneously). Finally, in a larger installation comprising many servers the “dual hot” solution may be impractical due to cost and space considerations.
It is noted that the delay times given hereinabove are approximates and may vary from system to system.
The present invention, in preferred embodiments thereof, seeks to provide an improved transport stream migration system and method. The invention enables migration of transport streams from one Internet protocol-television (IPTV) delivery server to another at a point in the transport stream that would result in generally no loss of service. The server may be responsible for decrypting the transport stream if the transport stream is already encrypted. The server may be responsible for encrypting the transport stream before delivering it. When the content provider decides to move a transport stream from one server to another, the two servers may negotiate for a suitable synchronization point. Once a suitable synchronization point is found, the servers may initiate a switch with reference to the negotiated synchronization point. Assuming that the latency for each server is generally the same, there may be no glitch on a set-top box viewing the channel. The movement of a transport stream between servers may allow maintenance and upgrades without interrupting the services currently streaming. Excluding complete instantaneous failure of a server, a group of IPTV delivery servers, operative in accordance with a preferred embodiment of the present invention, may provide generally 100 percent service up time. In a further preferred embodiment of the present invention, individual channels within a transport stream may be moved between servers.
There is thus provided in accordance with a preferred embodiment of the present invention, a transport stream migration method. The transport stream migration method includes providing a live server and a target server, the live server receiving a transport stream, designating exactly one of the live server and the target server as a controlling server, the controlling server receiving a migration instruction, the target server receiving a copy of the transport stream, negotiating a synchronization point by the live server and the target server, and migrating output of the transport stream from the live server to the target server with respect to a time determined from the synchronization point negotiated.
Additionally, in accordance with a preferred embodiment of the present invention, the method further includes initializing a conditional access system on the target server to decrypt and/or encrypt transport streams, and updating conditional access parameters of the target server with conditional access parameters received from the live server.
Furthermore, in accordance with a preferred embodiment of the present invention, the negotiating further includes searching by the live server and the target server for suitable reference point values, only if the live server is designated as the controlling server then designating the target server as the responding server, only if the target server is designated as the controlling server then designating the live server as the responding server, the responding server sending at least one proposed reference point value to the controlling server from among the suitable reference point values, the controlling server informing the responding server of a chosen synchronization point chosen from among the at least one proposed reference point values, and assigning the chosen synchronization point as the synchronization point.
Still further, in accordance with a preferred embodiment of the present invention, each of the at least one proposed reference point value includes one of the following, a program clock reference (PCR) and a presentation timestamp (PTS).
Moreover, in accordance with a preferred embodiment of the present invention, the method includes the live server and the target server applying timestamps to each transport stream packet received based on the incoming transport bitrate.
Additionally, in accordance a preferred embodiment of the present invention further includes determining a swap time by the controlling server, sending a swap delta calculated from the swap time and the synchronization point from the controlling server to the responding server, determining a swap time by the responding server from the received swap delta and the synchronization point, the live server finding a first splice point and sending a splice delta to the target server computed from the splice point and the synchronization point, and the target server computing a second splice point from the received splice delta and the synchronization point.
Moreover, in accordance with a preferred embodiment of the present invention, wherein the live server includes a first output buffer and the target server includes a second output buffer, and the migrating further includes the target server starting to fill the second output buffer from the second splice point, and the live server stopping filling the first output buffer at the splice point, thus allowing the output buffer of the live server to drain.
Furthermore, in accordance with a preferred embodiment of the present invention, wherein the transport stream is an MPEG-2 compliant transport stream and wherein the method further includes managing control word polarity.
Still further, in accordance with a preferred embodiment of the present invention, wherein the migrating is of at least one transport stream, and the live server generates at least two transport streams from a single transport stream received.
There is thus further provided in accordance with another preferred embodiment of the present invention, a transport stream migration system. The transport stream migration system includes at least one live server to deliver a received transport stream, at least one target server to take over delivery of a transport stream received by the at least one live server, a transport stream splitter and switch unit to copy the received transport stream and control the delivery of the transport stream to the at least one live server and the at least one target server, an Internet protocol (IP) switch to direct the output of the at least one live server and the at least one target server, and a control unit to schedule a migration from the at least one live server to the at least one target server.
Additionally, in accordance with a preferred embodiment of the present invention, the transport stream splitter and switch unit includes at least one of the following, at least one IP switch, at least one asynchronous serial interface (ASI) splitter and at least one ASI switch, and at least one ASI matrix.
Furthermore, in accordance with a preferred embodiment of the present invention, wherein the received transport stream is a MPEG-2 transport stream.
Moreover, in accordance with a preferred embodiment of the present invention, wherein the migration from the at least one live server to the at least one target server begins with a first transport packet of a UDP/IP datagram.
There is thus further provided in accordance with another preferred embodiment of the present invention, a transport stream migration method including at least one live server receiving a transport stream, scheduling a migration from the at least one live server to at least one target server, copying the received transport stream and controlling the delivery of the transport stream and transport stream copy to the at least one live server and at the least one target server by a transport stream splitter and switch unit, and directing the output of the at least one live server and the at least one target server by an IP switch.
Additionally, in accordance with a preferred embodiment of the present invention, the transport stream splitter and switch unit includes at least one of the following, at least one IP switch, at least one asynchronous serial interface (ASI) splitter and at least one ASI switch, and at least one ASI matrix.
Furthermore, in accordance with a preferred embodiment of the present invention, the received transport stream is a MPEG-2 transport stream.
Moreover, in accordance with a preferred embodiment of the present invention, the migration from the at least one live server to the at least one target server begins with a first transport packet of a UDP/IP datagram.
There is thus further provided in accordance with another preferred embodiment of the present invention, a transport stream migration system. The transport stream migration system includes a live server receiving a transport stream, a target server receiving a copy of the transport stream, wherein exactly one of the live server and the target server is designated as a controlling server, a control unit to issue a migration instruction to the controlling server, a negotiator on the live server and the target server to control negotiation of a synchronization point between the live server and the target server, and a migration controller on the live server and the target server to migrate output of the transport stream from the live server to the target server with respect to a time determined from the synchronization point negotiated.
Additionally, in accordance with a preferred embodiment of the present invention, the system further includes a conditional access system on the target server to decrypt and/or encrypt transport streams with updated conditional access parameters received from the live server.
Furthermore, in accordance with a preferred embodiment of the present invention, the negotiator includes a search unit to look for suitable reference point values, a responding server wherein, only if the live server is designated as the controlling server, the target server is designated as the responding server, and only if the target server is designated as the controlling server, the live server is designated as the responding server, a communication unit on the responding server to send at least one proposed reference point value to the controlling server from among the suitable reference point values, and a receiver on the target server to receive a chosen synchronization point chosen by the controlling server from among the at least one proposed reference point values.
Still further, in accordance with a preferred embodiment of the present invention; each of the at least one proposed reference point value includes one of the following, a program clock reference (PCR) and a presentation timestamp (PTS).
Moreover, in accordance with a preferred embodiment of the present invention, the live server and the target server apply timestamps applied to each transport stream packet received based on the incoming transport bitrate.
Additionally, a preferred embodiment of the present invention, wherein, the controlling server determines a first swap time, the controlling server calculates a swap delta from the swap time and the synchronization point and sends the swap delta to the responding server, the responding server computes a second swap time from the swap delta and the synchronization point, the live server computes a splice delta from a first splice point and the synchronization point, and the target server computes a second splice point from the splice delta and the synchronization point.
Furthermore, in accordance with a preferred embodiment of the present invention, the live server includes a first output buffer and the live server stops filling the first output buffer from the first splice point and the target server includes a second output buffer and the target server starts to fill the second output buffer from the second splice point.
Moreover, in accordance with a preferred embodiment of the present invention, the transport stream includes an MPEG-2 compliant transport stream and the system further includes a control word polarity manager.
Still further, in accordance with a preferred embodiment of the present invention, the migration controller controls the migration of at least one transport stream wherein the live server generates at least two transport streams from the single transport stream received.
The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:
It is noted that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.
The present invention, in preferred embodiments thereof, seeks to provide an apparatus and methods for transport stream migration from one Internet protocol-television (IPTV) delivery server to another at a point in the transport stream that would result in generally no loss of service. The server may be responsible for decrypting the transport stream if the transport stream is already encrypted. The server may be responsible for encrypting the transport stream before delivering it. When the content provider decides to move a transport stream from one server to another, the two servers may negotiate for a suitable synchronization point. Once a suitable synchronization point is found, the servers may initiate a switch with reference to the negotiated synchronization point. Assuming that the latency for each server is generally the same, there may be no glitch on a set-top box viewing the channel. The movement of a transport stream between servers may allow maintenance and upgrades without interrupting the services currently streaming. Excluding complete instantaneous failure of a server, a group of IPTV delivery servers, operative in accordance with a preferred embodiment of the present invention, may provide generally 100 percent service up time. In a further preferred embodiment of the present invention, individual channels within a transport stream may be moved between servers.
Reference is now made to
Live servers 117 may further IP encapsulate the transport streams, for example, as a user datagram protocol (UDP) multicast and may route them via an appropriate switch 121 known in the art. The transport streams may be sent directly across the backbone distribution IP network 125 to appropriate set-top boxes 127 for display on televisions 129. In addition to live servers 117, the IPTV delivery system may comprise between one and M additional delivery server(s), herein termed target server(s) 119, which may be used in a redundant transport stream migration method, operative in accordance with a preferred embodiment of the present invention. For clarity purposes only, a single target server 119 is shown in
Reference is now made to
Elements with the same reference numerals in
In preferred embodiments of the present invention, transport stream source 11 may send transport stream packets. An appropriate transport stream comprises a regular generally unique time stamp. For example, an MPEG-2 transport packet contains a program clock reference (PCR) that may be used as described hereinbelow with respect to
Referring specifically to
Controlling agent 23 may control transport stream migrations. Controlling agent 23 may instruct switch 15 to perform a transport stream migration from live server 17A to target server 19. Controlling agent 23 may instruct switch 15 as to which input may be routed to its output, thus controlling which transport stream may be sent to target machine 19. Initiation of a transport stream migration may entail communication from controlling agent 23 to switch 15 and target server 19 as shown by the dotted arrows (assuming target server 19 is the controlling server).
Referring back to
Controlling agent 23 may control transport stream migrations. Initiation of a transport stream migration may entail communication from controlling agent 23 to target server 19 as shown by the dotted arrow (assuming target server 19 is the controlling server). Controlling agent 23 may instruct target server 19 to perform a transport stream migration from live server 17A to target server 19. Controlling agent 23 need not communicate with IP switch 12, as IP switch 12 may be able to route the correct IP encapsulated streams automatically to live server 17 and target servers 19.
In the discussion hereinabove with respect to
In the redundant architecture of
Well known standards exist for transport streams and packetization in the current art. Reference is now made to
PES 310 may be converted into an MPEG-2 transport stream 320, wherein transport stream packet headers 325 are inserted at regular intervals within PES 310 dividing each packet 317 into at least one MPEG-2 transport packet 327. The MPEG-2 transport stream packet header may comprise a predetermined number of bytes, for example, 4, and may include an identifier for the individual PES packet 317 associated with it. A single PES packet 317 may now be spread over several MPEG-2 packets 327. Transport stream packet headers 325 may further comprise a sample of the program clock reference (PCR) via an optional adaptation field. Each sample may be used to calculate the bitrate of the transport stream or to interpolate a timestamp per transport stream packet. MPEG-2 transport packets are generally of a fixed length, which may enable receivers to parse the transport stream easily. An MPEG-2 transport stream may further allow different elementary streams to be interleaved.
For an IP network, transport stream 320 may be divided into a multiplicity of packets encapsulated with internet protocol (IP). For IPTV, these packets may be user datagram protocol/internet protocol (UDP/IP) datagrams 330. A UDP/IP header 335 is added to each UDP/IP datagram, which typically comprises a fixed number of MPEG-2 packets, for example, 7. A logical unit of content 305 may be split between different UDP/IP packets.
Reference is now made to
The live server receives a transport stream (400). Controlling agent 23 of
The controlling server may begin synchronization negotiations with the responding server (406). As the live server and the target server may be receiving identical data, the reference point used in the synchronization may be taken from the transport steam data input. Therefore, by finding a suitable reference point in a single transport packet of the input, it may be possible for the two server machines to synchronize. A reference point may be considered suitable if the reference point may appear in only a single transport packet. Providing both machines are looking for the same kind of reference and the reference is suitable, anything suitable may be used. In a preferred embodiment of the present invention, the program clock reference (PCR) may be used as the reference point. The PCR may be included in an optional extension to the transport stream header. In a further preferred embodiment of the present invention, the PTS value in a PES header may be used as the reference point. Other suitable reference points may occur to those skilled in the art and are within the scope of the present invention. In the discussion hereinbelow, for clarity of the discussion, the PCR will be used as an exemplary non-Limiting reference point. The negotiation method is described in greater detail hereinbelow with respect to
The live and target servers may infer a timestamp, herein termed a server timestamp, for every packet that passes through the system. The server timestamps may be derived from the bitrate of the transport stream (e.g. the server timestamps may be derived from the PCR in the transport stream). In prior art IPTV delivery servers a server timestamp may be necessary to calculate the delivery time of the transport packet. When the negotiation method has completed both the live and target servers know which packet has been chosen as the synchronization point.
Optionally, the conditional access system (CA) of the target server may be initialized (410), for example, if a CA system is operating on the live server. The CA system of the target server may be activated with the same parameters as the CA system of the live server using the same CA stream. If the live server is encrypting and/or decrypting the transport streams, the live server may send its current encryption and/or decryption status to the target server so that the target server may use the same values. The sending of the current encryption and/or decryption status may be done before the swap occurs such that at the point of swap the encryption and/or decryption status is identical on the live and target servers. The current parameters may be sent from the live server to the target server during the determination of the swap point. Alternatively, each change in encryption and/or decryption status may be sent from the live server to the target server in the period between the synchronization and the swap. In a further alternative, the live server may send the CA parameters after synchronization (before determining relative times) and may stop processing CA updates for that transport stream until the swap has finished. The choice of implementation may depend on how quickly the encryption and/or decryption parameters may be applied on the target machine (i.e. they must be in place for all transport packets that follow the swap point).
Optionally, the CA system of the target server may decrypt and/or encrypt the data input and/or output as necessary (416). The server timestamps may optionally be used to control the encryption/decryption processes of the CA system (for example, the timing of control word changes). For example, if the data stream the target server receives is encrypted the data stream may be 1) delivered unchanged, 2) decrypted and delivered, or 3) decrypted, encrypted with new parameters, and then delivered. For example, if the data stream the target server receives is not encrypted the data stream may be 1) delivered unchanged or 2) encrypted and then delivered. When encrypting, the target server may use the CA parameters to ensure that the next change of control word is “clean”. For example, an MPEG-2 transport stream is marked as encrypted using two polarities (odd and even), both meaning the same thing (encrypted); however, a transition from one polarity to the other indicates that the control word has changed. When the target server receives its first control word from the CA system the target server must maintain the correct polarity to use the correct control word to be considered “clean”. This change of control word may constitute an extra step either before or after the swap itself.
Once a synchronization point has been agreed upon, the swap may be set up at some point in the future with respect to the server timestamps of the live and target servers. After synchronization, each server may have a pair of values comprising the agreed upon reference point and the server timestamp of the transport packet containing that reference point. Relative times may be determined for specific transport packets by the live server and target server (418) from each server's pair of values as they provide a common point of reference in the transport stream. The determination of relative time method is described in greater detail hereinbelow with respect to
Reference is now made to
Both the live server and target server may search for suitable reference point values in the data stream input (428). As mentioned hereinabove, both the live server and the target server may be receiving identical transport stream data. The responding server sends the controlling server at least one proposed reference point value from among the suitable reference point values as possible synchronization points (430). When a match of a reference point is made, the controlling server may send a message to the responding server indicating the particular reference point to use as the synchronization point (432). The controlling server may thus inform the responding server of the chosen synchronization point chosen from among the at least one proposed reference point values and both servers may assign the chosen synchronization point as the synchronization point.
Reference is now made to
As mentioned hereinabove, a synchronization command may have been provided by the controlling agent as part of the migration instruction (
As shown by the arrow “control agent provides T”, the control agent may have provided the time at which to perform the migration. C is the server timestamp of the first transport packet processed after the controlling agent provided the swap time.
M and N are the start points of two sequential datagrams 330. Datagram 330, which begins at M, may comprise seven transport stream packets 327. T may be the time that was designated by the controlling agent to begin migration of the transport stream to the target server. The notation TS used in the equations below indicates a server timestamp.
Time T may be given to the controlling server by the controlling agent in terms of any unit of time (for example, hours, minutes or seconds) but this may not be appropriate for the servers to use directly. Therefore, T may be converted to Trelative, a time relative to the receipt of T (if T is an absolute time and is received at time Treceipt, Trelative=T−Treceipt but if T is already a relative time, Trelative=T). In the exemplary embodiment of the present invention, T is then converted into the same units as the server timestamps. Other embodiments wherein the conversion may take place later are also within the scope of the present invention. This converted time is herein referred to as a “swap delay”. It may not be sufficient for the swap delay to be used directly by both the controlling server and responding server as there is no common point of reference. The swap delay may be needed by the controlling server so that it can establish the server timestamp of the swap point (swapTScontrolling). This may be calculated by adding the swap delay to C, the server timestamp of the first transport packet processed after the controlling agent provided T
swapTScontrolling=currentTScontrolling+swap delay.
The controlling server may then determine a “swap delta”, the difference between the swap time and the synchronization time (of S). The swap delta is
D
swap=swapTScontrolling−ATScontrolling.
The controlling server may then issue a command to the responding server to swap using the swap delta, Dswap (450).
The responding server may determine its swap time by computing the server timestamp of the transport stream packet after which the swap will take place (452) because the synchronization point S is a common point of reference.
swapTSresponding=ATSresponding+Dswap.
If a CA system was initialized, at this point the target server may have received the current CA parameters from the live server and the target server may have updated its internal state to be the same as that of the live server (454). Having agreed on the point after which the transport stream may be migrated from the live server to the target server (the swap point), it is then necessary to find the precise point at which the migration may occur, herein referred to as the splice point. As the live server is currently responsible for delivering the transport stream, it is responsible for determining the splice point (spliceTSlive). When the target server (which may be the controlling or responding server) reaches a transport stream packet that has a server timestamp that is either greater than or equal to swapTStarget, the target server may optionally pause its processing for that transport stream until a message is received from the live server (458). Without pausing, the target server may overtake the position of the live server because of buffering differences. Meanwhile, the live server may continue processing but may search for the splice point (spliceTSlive) which is the transport stream packet that has a server timestamp that is either greater than or equal to swapTSlive and is the first in a UDP/IP datagram. In
D
splice=spliceTSlive−ATSlive
and may send the splice delta to the target server (462). The target server may convert the splice delta into an actual splice point from the synchronization point (464)
spliceTStarget=Dsplice+ATStarget.
Once the relative times have been determined the migration may proceed. The target server may wait for splice point N (472). If the target server optionally paused its processing, the output from the target server may be activated and the data no longer dropped after splice point N (474). The target server may begin filling its output buffer with the transport stream packet that has a timestamp that matches spliceTStarget (478). The live server may stop filling its output buffer from this transport stream packet onwards, i.e. spliceTSlive≧swapTSlive (482). As the output buffer of the target server fills, the output buffer of the live server will drain. Once the system latency time has elapsed, the swap will have completed.
As mentioned hereinabove, a further example of a suitable reference point may be the PTS value in a PES header 315 due to the frequency of the PTS, both its resolution and occurrence in the bitstream. There is a direct, 1:1 mapping between a single PTS and MPEG-2 transport stream packet (and hence server timestamp). As both the live server and target server are receiving identical data streams, both data streams may comprise identical time references in the PTS. The PTS may not be suitable if the transport stream were already encrypted.
Numerous specific details have been described in the preceding description to provide a thorough understanding of the invention. However, it will be understood by those of ordinary skill in the art that the present invention may not require all these specific details. In other instances, well-known methods, and/or components may not have been described in full detail so as not to obscure the present invention.
An embodiment of the present invention may include an apparatus for performing the operations described herein. Such an apparatus may be specially constructed or may comprise a general-purpose computer that is operated according to a computer program stored therein. Such a computer program may be stored in any appropriate computer readable storage medium.
It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may generally be implemented in hardware, if desired, using conventional techniques.
It is appreciated that various features of the invention, which are, for clarity, described in the contexts of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination.
While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those of ordinary skill in the art. It should therefore be understood that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined only by the claims that follow:
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/GB2006/004419 | 11/27/2006 | WO | 00 | 6/2/2009 |
