The memory 210 may be a hardware component configured to store data related to operations performed by the TSACO server 125. For example, the memory 210 may store a rebasing shift value that is calculated for a transport stream. The display device 215 may be a hardware component configured to show data to a user while the I/O device 220 may be a hardware component that enables the user to enter inputs. It should be noted that the display device 215 and the I/O device 220 may be separate components or integrated together such as a touchscreen. The display device 215 and the I/O device 220 may enable an administrator to manage the transport stream automatic change over mechanism according to the exemplary embodiments. The transceiver 225 may be a hardware component configured to establish a connection with components of entities involved in a broadcast chain.

As described above, the exemplary embodiments may also be implemented in a cloud or with virtual machines. Thus, the description herein with regard to the TSACO server 125 being embodied in hardware and/or in the components of the TSACO server 125 is only for illustrative purposes. When implemented in a cloud or with virtual machines, the functionalities described below for the components and engines of the TSACO server 125 may be instructions that may cause other components or other devices to perform corresponding operations. For example, the functionalities of the engines 235-250 of the processor 205 may represent respective instructions for one or more components/devices to achieve the intended operation. In another example, the transceiver 225 may represent a connection mechanism for components of entities of the broadcast chain and/or components/devices within an entity of the broadcast chain to communicate.

As described above, the exemplary embodiments provide a clean change over performed automatically between a selected first transport stream to a second one of at least one further available transport stream. For example, the change over or switch may be performed for various reasons including a failure of the first transport stream, an anticipated switch, etc. In an exemplary embodiment, the TSACO server 125 may receive the primary transport stream 110 and the secondary transport stream 120 which are de-multiplexed (demuxed) into a buffer. The TSACO server 125 may then re-multiplex (remux) a selected one of the transport streams into the output 130. When an issue arises for the selected transport stream used to remux into the output 130, the TSACO server 125 may switch and select another demuxed transport stream to be used in remuxing into the output 130. This switch may be performed by the TSACO server 125 such that the output 130 is generated without interruption and in a continuous manner as if no switch was performed.

The selection engine 235 may select between the primary transport stream 110 and the secondary transport stream 120. As noted above, the TSACO server 125 may receive the primary transport stream 110 and the secondary transport stream 120 (e.g., via the transceiver 225) for subsequent demuxing (e.g., by a demuxer or demuxing operation performed by the processor 205 (not shown)). The demuxed transport streams 110, 120 may be stored in a buffer (e.g., as part of the memory arrangement 210 reserved for the mechanism according to the exemplary embodiments or using a remote storage component). Thus, according to this exemplary implementation, the selection engine 235 may select one of the demuxed transport streams 110, 120 for subsequent processing. As will be described below, based on subsequent operations, the selection engine 235 may select a different, unselected transport stream to be remuxed. The selection engine 235 may determine that a selection is to be performed based on a variety of triggers. For example, the selection engine 235 may receive an indication that the primary content source 105 is deactivated (e.g., through a remote indication, by a manual entry input through the I/O device 220, etc.). In another example, the selection engine 235 may determine that the primary content source 105 is deactivated when a predetermined number of consecutive packets or a predetermined number of packets within a given time period are not received in the primary transport stream 110. Further examples of when a switch may be performed from the primary transport stream 110 may include a primary buffer associated with the primary transport stream 110 getting too low, a packet loss in the primary transport stream 110, a jitter level of the primary transport stream 110 being too high, a format change to video/audio/etc. that is unexpected, an external application program interface indicating the switch, etc. The mechanism according to the exemplary embodiments and the selection functionality of the selection engine 235 may also be configured in other manners. For example, the selection engine 235 may select the transport stream prior to demuxing.

The frametime engine 240 may determine a correlation between the transport streams 110, 120 for the selection engine 235 to perform a clean switch when selecting a different transport stream. The frametime engine 240 may utilize the features of transport streams such as the predetermined size and the constant bitrate. As will become apparent herein, the frametime engine 240 may determine a frametime in which a timestamp may be used to determine a frame of the content in the currently selected transport stream (referred to herein as the “primary transport stream”) that corresponds to a frame of the content in a different transport stream to be selected to replace the currently selected transport stream (referred to herein as the “secondary transport stream”). It is noted that the use of primary and secondary for the transport streams does not connote any primacy or hierarchy to the transport streams, the terms are merely used to distinguish between a currently selected transport stream and the one or more transport streams that are not currently selected. The frametime engine 240 may determine the frametime based on a start time of an identified content item and a completed playout or progression in a buffer of that identified content item (hereinafter referred to as “completed progression”). Each content item processed by the output system 100 may include a start time or time value at which the content item commences (hereinafter collectively referred to as “start time”). As the content item progresses, using the features of transport streams, each frame may be assigned or stamped with a time value relative to the start time (hereinafter collectively referred to as a “timestamp”). This timestamp may be used to synchronize the primary content source 105 and the secondary content source 115 or synchronize the primary transport stream 110 and the secondary transport stream 120. Therefore, at the time a switch is to be performed, the frametime engine 240 may utilize the completed progression of the currently selected primary transport stream and determine a corresponding frame in the secondary transport stream to be selected. As will be described in detail below, the switch may be performed based on an I frame of the transport streams. With the transport streams 110, 120 synchronized, the corresponding frame in the secondary transport stream to be selected may coincide with the frame of the completed progression in the currently selected primary transport stream. Thus, a switch may be performed where a last frame of a currently selected primary transport stream continues with a first frame of the secondary transport stream to be selected such that the content item is output in a clean manner, seamlessly with no artifacts, glitches, etc.

The rebasing engine 245 may determine a shift used in a selected one of the transport streams 110, 120 to generate the output 130. The rebasing engine 245 may utilize a first rebasing to remux a selected transport stream (e.g., the primary transport stream 110). Thus, a first rebase value may be used on each packet of the selected transport stream to generate the output 130. When a switch to a new transport stream (e.g., the secondary transport stream 120) is performed, the rebasing engine 245 may utilize the output of the frametime engine 240 to determine a second rebase value to be used on each packet of the newly selected transport stream.

The muxing engine 250 may generate the output 130 based on the outputs of the selection engine 235, the frametime engine 240, and the rebasing engine 245. Thus, when a selection is made by the selection engine 235 for the primary transport stream 110, the rebasing engine 245 may indicate a first rebase value to be used in the remux operation. The muxing engine 250 may continue to use the first rebase value to remux the buffered demuxed primary transport stream 110 until the selection engine 235 indicates a new selection to the secondary transport stream 120. The muxing engine 250 may then receive an indication from the rebasing engine 245 for a second rebase value on which to perform the remux operation (e.g., the second rebase value being based on an output of the frametime engine 240). The muxing engine 250 may use the second rebase value to remux the buffered demuxed secondary transport stream 120. The muxing engine 250 may continue to use the second rebase value until the transport stream concludes or when a further selection is made to switch transport streams.

FIGS. 3-5 show exemplary packet sequences 300, 400, 500 according to various exemplary embodiments described herein. FIG. 3 shows a first packet sequence 300 in which the TSACO server 125 generates the output 130 by remuxing the buffered packets of the primary transport stream 110. FIG. 4 shows a second packet sequence 400 in which the TSACO server 125 generates the output 130 by switching from the primary transport stream 110 to the secondary transport stream 120. FIG. 5 shows a third packet sequence 500 in which the TSACO server 125 generates the output 130 by remuxing the buffered packets of the secondary transport stream 120. Thus, the packet sequence 300 shows when the primary transport steam 110 is operating successfully, the packet sequence 400 shows when the primary transport stream fails and the secondary transport stream 115 is used, and the packet sequence 500 shows the secondary transport stream 120 continuing to be used when the primary transport stream 110 remains down.

FIGS. 3-5 include the primary content source 105 outputting the primary transport stream 110, the secondary content source 115 outputting the secondary transport stream 120, the primary transport stream 110 and the secondary transport stream 120 demuxed into a buffer 305 and remuxed in a muxer 310 to generate the output 130. The packets of the transport streams 110, 120 that are buffered as illustrated as I/P/B frames (e.g., for video) and A frames (e.g., for audio) where the I/P/B frames corresponds to the A frames along a sequence (e.g., from 601 to 627). The buffer 305 being illustrated as a single buffer is only exemplary. Those skilled in the art will understand that there may be an individual buffer for each of the transport streams 110, 120.

As described above, the TSACO server 125 may utilize an I frame as a basis to perform the switch from the primary transport stream 110 to the secondary transport stream 120. For example, as shown in the packet sequence 300, the muxer 310 may receive buffered I/P/B and A frames based on the primary transport stream 110. In the packet sequence 400, there may be an indication that the primary content source 105 is no longer providing the primary transport stream 110 to the TSACO server 125. For example, the primary content source 105 may have transmitted frames 601 to 615 which have been demuxed and stored in the buffer 305. However, after frame 615, the primary content source 105 may have failed and the primary transport stream 110 may have stopped being received. The secondary content source 115 may continue to be operational and provide the secondary transport stream 120 after the primary transport stream 110 has stopped being received. As the I frames may be used as breakpoints, the muxer 310 may use the buffered frames 601 to 612 from the primary transport stream 110 to be remuxed for the output 130. Packets of the primary transport stream 110 that were buffered after the I frame breakpoint may be discarded.

In switching to the buffered frames of the secondary transport stream 120, the muxer 310 may use the last I frame from the primary transport stream 110 for which the preceding frames are complete. Accordingly, in the packet sequence 500 in which the primary content source 105 is no longer transmitting the primary transport stream 110 to be demuxed and stored in the buffer 305, the muxer 310 may use the buffered frames 613 and onward from the secondary transport stream 120 to be remuxed and used in the output 130.

The above process of switching from the primary transport stream 110 to the secondary transport stream 120 relies on an assumption that the next I frame of the secondary transport stream 120 corresponds to the I frame of the primary transport stream 110 used as a breakpoint to discontinue use in remuxing for the output 130. However, with the above failure scenario for the primary transport stream 110, there are instances when the selected I frame 613 of the secondary transport stream 120 is not the correct I frame to begin remuxing the secondary transport stream 120 for the output 130.

When considering transport streams, there is no guarantee that a particular frame number in a list of packets for a content source that is demuxed and stored in the buffer 305 corresponds to a second list of packets for a further content source that is demuxed and stored in the buffer 305. Those skilled in the art will understand that a PCR or a program timestamp (PTS) may not be used to synchronize the lists of packets for the primary transport stream 110 and the secondary transport stream 120. For example, the secondary content source 115 may have been active for a first time period, then failed during a second timer period, and became active again for a third time period. When the secondary content source 115 restarts at the third time period, the frames may be reset to a different frame number (e.g., a reference, initial frame number such as 0). Therefore, the frame number, the PCR, or the PTS may not provide a sufficient basis to ensure that the correct remuxing point is used when a switch is performed.

As described above, the frametime engine 240 may determine a frametime that allows the transport streams 110, 120 to be synchronized (e.g., a first frame in a first transport stream corresponds to a second frame in a second transport stream for a content item). For example, the frametime may be used to convert a timestamp of the primary transport stream 110 (e.g., a selected transport stream) based on a start time and a completed progression to a frame which is correlated to a frame of the secondary transport stream 120 (e.g., a newly selected transport stream) and a corresponding timestamp.

To utilize the frametime, the primary content source 105 and the secondary content source 115 may be configured to communicate with one another to perform a synchrolock operation. The synchrolock operation may entail the secondary content source 115 requesting a list of packets or frames that the primary content source 105 intends on playing out. Therefore, the primary content source 105 and the secondary content source 115 may be configured to transmit the same packets or frames to the TSACO server 125. The list may be for the packets themselves or may enumerate other types of information used to indicate the intended playout for the primary content source 105. For example, the list may be for different content items in an intended order. Each content item may be referred to as an “assist” where the list also identifies a start time for each assist or a time that the associated content item is to start.

The list may indicate that a first clip may start at a first time (e.g., in a format of hour:minute:second.frame to indicate the time with hour, minute, and second the frame indicating a number of frames after the given time). The list may then indicate that a second clip may start at a second time (e.g., hour:minute:second.frame following the first time). Using the principles of transport streams with sections of predetermined amounts of data (e.g., 188 bytes) and a constant bitrate, the frametime engine 240 may use the time and frame(s) of the start time to determine a frametime. Any content source that performs the synchrolock operation with the primary content source 105 may agree with the frametime. In this manner, the primary content source 105 and the secondary content source 115 may use the same synchronized schedule to generate the primary transport stream 110 and the secondary transport stream 120. By agreeing to play out a selected piece of content at a corresponding time, the clocks of the content sources 105, 115 may also be synchronized with regard to the transport streams 110, 120.

The frametime may also utilize existing transport stream specifications. For example, an additional communication arrangement may not be required. However, such an implementation may also be utilized for the exemplary embodiments. In utilizing existing transport stream specifications, the frametime may be inserted into an available space in the transport streams. For example, a PES header may include 128 bits that are empty. The frametime may only use, for example, 64 bits that may fit in the empty space of the PES header.

Using the frametime, the buffers for the primary transport stream 110 and the secondary transport stream 120 may include demuxed packets or frames that have a known synchronization. Thus, in remuxing a selected transport stream to generate the output 130, the frametime may enable a seamless switch to be performed. However, as noted above, timestamps may be reset when, for example, the corresponding content source is restarted. In view of the issue with timestamps, the rebasing engine 245 may provide a rebasing operation so that the timestamps corresponds to an intended time in the remuxing operation of the muxing engine 250.

FIG. 6 shows a PTS sequence 600 according to various exemplary embodiments described herein. The rebasing engine 245 may be used to determine a rebasing value applied to a selected transport stream. For example, the PTS may be timestamp segments that increment in a predetermined manner. As shown in the PTS sequence 600, the primary transport stream 110 may have an initial PTS of A+2X. In an exemplary implementation, the PTSs of the primary transport stream 110 may increment by a first value. For example, the PTSs may increment by X. Thus, a second PTS may have be A+3X. This may continue for each PTS in the primary transport stream 110. While the primary transport stream 110 is remuxed to generate the output 130, the PTSs of the primary transport stream 110 may correspond to PTSs of the output 130. A first PTS of the primary transport stream 110 that is used in a first PTS of the output 130 may have a first difference. The first difference may correspond to the rebasing value. As illustrated, a first rebasing value used to rebase the primary transport stream 110 to the output 130 may be delta_1. The rebasing engine 245 may use the determined rebasing value of delta_1 and apply it to each subsequent PTS of the primary transport stream 110 for a duration that the primary transport stream 110 is remuxed into the output 130. As illustrated, the primary transport stream 110 may be used for six PTSs in the output 130. Thus, the delta 1 being applied to the six PTSs of the primary transport stream 110 results in six PTSs of the output 130 having values of B, B+X, B+2X, . . . , B+5X.

Due to various reasons (e.g., a restart of the secondary content source 115), a sequence of the PTSs of the primary transport stream 110 may not correspond to a sequence of the PTSs of the secondary transport stream 120. As illustrated, the first PTS of the primary transport stream 110 may have a value of A+2X while the first PTS of the secondary transport stream 120 may have a value of A. The secondary transport stream 120 may increment in a manner substantially similar to the primary transport stream 110. Thus, the second PTS of the secondary transport stream 120 may have a value of A+X and so forth. Therefore, the PTSs of the primary transport stream 110 and the secondary transport stream 120 may not be in parallel with another. However, the PTSs may still be aligned in the manner illustrated in the PTS sequence 600 where the first PTS of the primary transport stream 110 aligns with the first PTS of the secondary transport stream 120 and so forth. The resulting alignment of PTSs between the primary transport stream 110 and the secondary transport stream 120 may still be used since the rebasing engine 245 dynamically rebases PTSs used in the output 130.

As illustrated in the PTS sequence 600, the primary transport stream 110 may have terminated after the sixth PTS having a value of A+7X. Thus, by using the rebasing value of delta 1, the six PTSs of the output 130 may be determined. Starting with the seventh PTS of the output 130, the TSACO server 125 may remux the output 130 using the secondary transport stream 120. Thus, the seventh PTS and onward of the secondary transport stream 120 may be used in corresponding positions of the output 130. However, the same rebasing value as applied to the primary transport stream 110 may not be correct. Thus, the rebasing engine 245 may determine a second rebasing value to be applied to the PTSs of the secondary transport stream 120. Since the next PTS for the output 130 following the PTSs of the remuxed primary transport stream 110 is shown as having a value of B+6X, the rebasing engine 245 may determine the second rebasing value as delta 2 which is applied to the seventh PTS of the secondary transport stream 120 having a value of A+6X to result in B+6X. This process may continue in which the rebasing value of delta 2 is applied to each PTS of the secondary transport stream 120 that is used in remuxing to generate the output 130.

Using the rebasing value, the timestamps of the output 130 may also be properly determined to progress in the correct manner even when the PTSs of the primary transport stream 110 is no longer running in parallel to the PTSs of the secondary transport stream 120. In this manner, the frametime may enable the correct correlation of data to be used in remuxing to generate the output 130 when a switch is performed while the rebasing value may enable the correct correlation of timestamps for the output 130 when the remuxing is performed after the switch.

The exemplary embodiments described above are directed to the output system 100 including two content sources 105, 115 each generating transport streams 110, 120 which are received by the TSACO server 125 to generate the output 130 which is transmitted to an entity in the broadcast chain. However, the output system 100 may include further components and/or have various modifications. In a first example, as noted above, there may be further content sources and further transport streams that are received by the TSACO server 125. Thus, if the primary content source 105 fails such that the primary transport stream 110 is no longer received, the TSACO server 125 may use the secondary transport stream 120 from the secondary content source 115. If the secondary content source 115 fails such that the secondary transport stream 120 is no longer received and the primary content source 105 has not been restarted, the TSACO server 125 may use a tertiary transport stream (not shown) from a tertiary content source (not shown). If the secondary content source 115 fails such that the secondary transport stream 120 is no longer received and the primary content source 105 has been restarted, the TSACO server 125 may use the primary transport stream 110 or the tertiary transport stream. The output system 100 may therefore incorporate these further content sources and transport streams as redundant fallbacks to be used by the TSACO server 125. For example, if a particular transport stream is associated with a high priority or high revenue channel, this multiple redundancy configuration may ensure an intended playout in the output 130 even under significant failure conditions.

In a second example, there may be a plurality of output systems 100 that are integrated into an overall system. In a substantially similar way that the output system 100 is a converging, debranching, or merging scheme (collectively referred to as a “converging” scheme) in which multiple inputs result in a single output, the overall system may include a plurality of output systems 100 such that a plurality of outputs 130 from individual output systems 100 may be used as inputs much like the transport streams 110, 120. Thus, at a most divergent, highest level, each output system 100 may receive transport streams from content sources (e.g., as illustrated in FIG. 1). At a next lower level, there may be half the output systems 100 that reside on the immediately higher level. In this lower level, each output system 100 may receive a plurality of the outputs 130 from the output systems 100 in the higher level as remuxed transport streams. The output systems in the lower level may then generate respective outputs 130 as remuxed transport streams. This may continue until a lowest output system 100 that receives outputs 130 as remuxed transport streams to generate a final output 130. In this manner, the overall system may be equipped with redundant output systems 100 that provides a buffer that the exemplary embodiments may use to remux into a final output. That is, if a primary TSACO server 125 were to fail, there may be a secondary TSACO server 125 that provides an output 130 used in remuxing into a further output 130.

The output systems 100 in lower levels may also utilize the features described above with regard to frametime and rebasing. For example, the outputs 130 of different output systems 100 residing on a first level may have mismatching PCR and/or PTS values when received by an output system 100 residing on a second, lower level. However, the frametime operation and the rebasing operation may synchronize the outputs 130 from the first level such that the packets or frames buffered in the buffer 305 have known correlations. The PTSs may also be synchronized through the rebasing operation using respective rebasing values for each PTS.

The output system 100 may also be configured with monitoring features to provide alerts to an administrator. In a first example, the TSACO server 125 may read and process PAT/PMT packets to ensure that the correct PIDs in the primary transport stream 110 and the secondary transport stream 120 are included and/or match the PIDs in the TSACO server 125. If not included or mismatched, the TSACO server 125 may raise an error when either of the transport streams 110, 120 fails this verification. In a second example, the TSACO server 125 may monitor when the primary content source 105 and the secondary content source 115 are still operational or have failed using the various criteria indicated above. In a third example, the output system 100 may also generate an indication as to its own health and status. The output system 100 may communicate this information using, for example, representational state transfer (REST), simple network management protocol (SNMP), etc. The information may include buffer levels for each transport stream being received, a group of pictures (GOP) in the buffer, input jitter, missing input PIDs, unexpected PIDs, mismatched PMT/PAT, PCR/realtime jitter, etc.

The output system 100 may also utilize a preliminary clock synchronization operation so that extreme drift cases may be avoided. As noted above, the frametime operation and the rebasing operation enable a synchronization of the transport streams so that all of the components in the output system 100 may agree on a common time. Assuming a buffer overrun or underrun situation does not arise, the output system 100 may synchronize clocks based on the components of the output system 100 being configured with a network time protocol (NTP). NTP may keep the clocks synchronized with a reasonable threshold to keep the buffers from encountering significant error or drift.

FIG. 7 shows an exemplary method 700 to generate the output 130 using the transport streams 110, 120 according to various exemplary embodiments described herein. The method 700 illustrates a manner in which to synchronize the packets of the transport streams 110, 120 using a frametime and properly convert timestamps when different transport streams are used in remuxing the output 130 through a rebasing operation. The method 700 may be performed by the selection engine 235, the frametime engine 240, the rebasing engine 245, the muxing engine