Server independent cloud video playout system

Abstract

For broadcast-grade service level guarantees for linear video Playout, it is important for Playout systems and the associated server hardware to be extremely reliable. To accomplish this both the Playout software and server hardware are tightly integrated in on-premise implementations. Playout systems on the cloud allow for leveraging cloud servers dynamically for miming Playout systems. The present invention proposes a system and method redundant, cost-effective for time-advanced, server-independent cloud Playout, which is useful in a variety of scenarios including but not limited to accomplishing seamless redundancy, optimizing operating costs by choosing different service provider/regions/servers. This is achieved by pre-playing the channel ahead of schedule, and then passing it to the output through an intelligent delay buffer. By switching Playout across multiple servers by instantiating new Playout software on another cloud server without impacting the linear output feed streamed out of the delay buffer we accomplish a server independent Playout system.

1 . A redundant, cost-effective system for time-advanced, server-independent cloud Playout having (a) a Playout sub-system (PLYM)  201 , (b) a Cloud Store  204  accessible over a network interface, (c) a Delay Buffer Manager (DBM) module  202 , and (d) a Playout Orchestration Manager (PORCH)  203  module wherein:
 a. The Playout sub-system (PLYM)  201  having an Automation module, a Playout, which assembles and blends one or more assets specified in a playlist including but not limited to digital audio, video, graphics, subtitle and triggers, which is then sent to an encoder, the PLYM being executed on one or more servers based on the controls fed from an Automation module, reads assets that need to be assembled which are typically in a Cloud Store  204 , plays out the content by blending audio, video and graphics, and outputs an encoded stream using an encoder module to a target destination; 
 b. The Cloud Store  204  is accessible independent of the status of the servers on which PLYM is executed; 
 c. The DBM  202  is an intelligent delay buffer management module that takes streams from multiple instances of PLYMs and other Playout sources, delays the streams by storing them for a defined period of time, and then the sends out a timed single output stream by picking data from the different buffers thereby maintaining continuity of the output stream; 
 d. The Playout Orchestration Manager (PORCH)  203  module controls the PLYM  201  and DBM  202 , guaranteeing Playout output to be time-exact as specified in the playlist by instructing the PLYM  201  to Playout ahead of schedule (time-advanced); 
 e. The encoded output stream of the PLYM  201  is stored in the DBM, which stores it for exact duration of the time-advancement done in PLYM, after which it is instructed by PORCH  203  to output the stream after a pre-determined delay; and 
 f. The PLYM  201 , DBM  202  and PORCH  203  are implemented as Containers, which helps in executing in different servers by binding them to a server instance dynamically. 
 
     
     
         2 . A system of  claim 1  wherein the PORCH  301  and PLYM  302  sub-system communicate such that:
 a. To initiate the start of Playout, the PORCH  301  sends an instruction PORCH-PLYM-Playout  303  with the following key parameters:
 i. A playlist start offset, which specifies the point in the playlist where the PLYM is expected to Playout from, to enable scenarios when one PLYM is replaced with another, such that the second instance can be instructed to start Playout exactly at the location where the first instance of PLYM is stopped; 
 ii. A Playout rate that specifies the rate at which the Playout is to be accomplished; 
 iii. An encoder clock value, which is the value of the encoder clock for the first encoded video that is sent out of the PLYM, which is used to enable continuity of streams across multiple PLYM instances wherein scenarios when one PLYM instance is replaced with another PLYM instance, are handled by making the encoder continues the clock exactly from where the first instance of PLYM had stopped; 
 iv. A start video frame type, assigned to the first video frame to be encoded out of the Playout to enable continuity of streams across the multiple PLYM instances; and 
 v. A DBM output buffer handle, which is a destination buffer onto which the Playout is expected to provide the output; 
 
 b. Upon receiving these parameters, the PLYM assembles audio, video, graphics, subtitles and trigger data according to a playlist defined timeline, and then encodes the data and places them in the DBM output buffer handle provided; and 
 c. Upon completion of every video frame worth of encoding and buffering, the PLYM sends a status to the PORCH in the form of PLYM-PORCH-Playout-Logs  303 , which has exact details of all input parameters for the currently completed video frame. 
 
     
     
         3 . A system of  claim 1  where the Delay Buffer Manager DBM is comprised of (a) one or more delay buffers  402 - 406 , (b) a Timed data buffer selector  407 , (c) a clock for the Timed data buffer selector  408 , and (d) a Multiplexer and output streamer module  410  wherein:
 a. The delay buffers are filled with encoded video streams from one or more PLYM instances ( 403 ,  405 ) wherein the PORCH  409  instructs at least one PLYM instance to Playout ahead of a duration of time-advancement time_ 1   412 , which is more than the need to switch between PLYMs while maintaining the output stream in a time-continuous fashion; 
 b. The Timed data buffer selector  407  chooses the delay buffer from which encoded data is to be accessed for output, and is triggered to action by the PORCH by giving it the time of day from when it should start the output streaming, provided as a start instruction with a duration of time-advancement time_ 1   412 , which is the time of the Playout in accordance with a playlist; 
 c. On receiving this instruction  412 , the Timed data buffer selector  407  starts its own clock  408 , which acts as a reference timer for the Multiplexer and output streamer module  410 ; 
 d. Based on output stream periodicity needs as dictated by the clock  408 , the Timed data buffer selector  407 , finds the highest sequence numbered delay buffer with the needed timed data, wherein a higher number indicates a greater priority such that the PORCH implements a selection policy for the right PLYM output by providing the selected PLYM output to be sent to the highest sequence numbered delay buffer; and 
 e. This data is then transferred to the Multiplexer and output streamer module  410 , which then sends out the output stream. 
 
     
     
         4 . A system of  claim 3  wherein Timed data buffer selector  407  receives a ‘Start output streaming @time 1 ’ message  501  such that:
 a. When day clock is time 1  the Timed data buffer selector  407  starts the timer  502  and then starts an iterator for each of the video frame rate period  503 ; 
 b. For each frame rate period T(i), the Timed data buffer selector starts  504  another iterator to go over all delay buffers, by going from the largest to the smallest delay buffer count; and 
 c. If the timed data is found on the jth delay buffer then that is selected and passed onto Multiplexer and output streamer module  506 , else the Timed data buffer selector iterates through to a lower sequence numbered delay buffer  507 . 
 
     
     
         5 . A system of  claim 1  wherein Playout redundancy is achieved by:
 a. The PORCH monitoring one or more logs coming out of a primary PLYM_Instance_ 1 , executing (the delay buffer) at a ‘normal rate’ to check for failures; 
 b. The PORCH instantiating a second PLYM_Instance_ 2   605  when it detects a failure in primary Playout, PLYM_Instance_ 1   602 , PLYM_Instance_ 2  executing the delay buffer at a ‘fast rate’ with input parameters for Playout that match the continuity of the final output stream wherein PLYM_Instance_ 2 's output is sent to delay buffer_ 2  of the DBM  603 ; 
 c. Since PLYM_Instance_ 2  is executing at a ‘fast rate’, the delay buffer_ 2  fills with data starting from the point at which PLYM_Instance_ 1  crashed but at a much quicker rate than the ‘normal rate’ of PLYM_Instance_ 1  thereby ensuring that before DBM's Timed data buffer selector exhausts delay buffer_ 1 , PLYM_Instance_ 2  has started sending its output to delay buffer_ 2 , by time-compensating to achieve buffer depletion; 
 d. Once secondary Playout is initiated, based on the failure, the PORCH re-instantiates PLYM_Instance_ 1  in ‘normal mode’ either on a different server and or region or availability zone, with a future time determined playlist time offset and encoder clock value and video frame type; 
 e. Once the PLYM_instance_ 1  is up and running, and starting to feed the delay buffer_ 1 , the PORCH brings down the secondary Playout PLYM_Instance_ 2 ; and 
 f. The DBM's Timed data buffer selector exhausts the delay buffer_ 2 , by which time the PLYM_Instance_ 1  is back as the primary Playout and starts to send its output to delay buffer_ 1 . 
 
     
     
         6 . A system of  claim 5  wherein the PORCH ensures the delay buffer_ 1  and delay buffer_ 2  have the same timed data as part of the overlap sequence in bringing back the primary Playout. 
     
     
         7 . A system of  claim 1  wherein cost-optimization of Playout across its lifetime using the cost arbitrage available in renting cloud server time such that:
 a. The PORCH  801 , in addition to the Playout controls and other inputs, maintains information on the lowest bid price of available servers at every point in time  806 ; 
 b. When instantiating the first PLYM_Instance_ 1  as the primary Playout  802 , the PORCH  801  looks for the lowest-cost server and binds the PLYM_Instance_ 1  to that server; 
 c. The PORCH  801  then instructs Playout start to the PLYM_Instance_ 1  and sends time 1 , which is the wall clock time for Playout start as determined by playlist at which time DBM needs to start output stream  804 ; 
 d. The PORCH  801  continually looks for the lower server price from the bidding data to optimize costs such that if there is a bid server available that is lower priced than the current server executing Playout_Instance_ 1 , then PORCH activates a switch of servers to move the Playout to a lower priced server, and shuts down the higher priced one; and 
 e. The PORCH  801  accomplishes the switch by starting PLYM_Instance_ 2  in parallel  805  to PLYM_Instance_ 1 , and once PLYM_Instance_ 2  has started generating output onto the delay buffer_ 2 , then PLYM_Instance_ 1  is shutdown and PLYM_Instance_ 2  takes the place of PLYM_Instance_ 1 , with the associated output delay buffer to DBM moved to delay buffer_ 1 . 
 
     
     
         8 . A redundant, cost-effective method for time-advanced, server-independent cloud Playout comprising the steps of:
 a. A Playout sub-system (PLYM)  454 :
 i. Assembling and blending one or more assets  455  specified in a playlist including digital audio and video that is then sent to an encoder  456 , where the PLYM  452  has an automation module and the PLYM is executed on one or more servers based on the controls fed from the Automation module; 
 ii. Reading assets  454  that need to be assembled that are typically in a Cloud Store  453 ; and 
 iii. Playing out the content by blending audio, video and graphics, and outputs an encoded stream using an encoder module  457  to a target destination; 
   b. A Cloud Store  453  accessible over a network interface independent of the status of the servers on which the PLYM  452  is executed;   c. A DBM  458 , which is an intelligent delay buffer management module:
 i. Taking streams from multiple instances of PLYMs and other Playout sources  459 ; 
 ii. Delaying the streams  460  by storing them for a defined period of time  459   a ; and 
 iii. Sending out a timed single output stream  461  by picking data from different buffers thereby maintaining continuity of output stream; and 
   d. A Playout Orchestration Manager (PORCH)  462  module:
 i. Controlling the PLYM and DBM, guaranteeing Playout output to be time-exact as specified in the playlist by instructing the PLYM to Playout ahead of schedule (time-advanced); and 
 ii. Storing the encoded output stream of the PLYM in the DBM,  458  which stores it for the exact duration of the time-advancement done in the PLYM. 
   
     
     
         9 . A method of  claim 8  wherein the PORCH  462  and PLYM  452  sub-system communicate, further comprising the steps of:
 a. The PORCH  462  initiating the start of Playout by sending an instruction PORCH-PLYM-Playout  462   a  with the following key parameters:
 i. A playlist start offset, which specifies the point in the playlist where the PLYM is expected to Playout from, to enable scenarios when one PLYM is replaced with another, such that the second instance can be instructed to start Playout exactly at the location where the first instance of PLYM stopped; 
 ii. A Playout rate that specifies the rate at which the Playout is to be accomplished; 
 iii. An encoder clock value, which is the value of the encoder clock for the first encoded video that is sent out of the PLYM, which is used to enable continuity of streams across multiple PLYM instances wherein scenarios when one PLYM instance is replaced with another PLYM instance are handled by making the encoder continue the clock exactly from where the first instance of the PLYM had stopped; 
 iv. A start video frame type, assigned to the first video frame to be encoded out of the Playout to enable continuity of streams across multiple PLYM instances; and 
 v. A DBM output buffer handle, which is the destination buffer onto which the Playout is expected to provide the output; and 
 
 b. The PLYM:
 i. Assembling  455  audio, video, graphics, subtitles and trigger data according to a playlist defined timeline, upon receiving these parameters; 
 ii. Encoding  457  the data and placing them in the DBM output buffer handle provided; and 
 iii. Sending a status to the PORCH upon completion of every video frame worth of encoding and buffering, in the form of PLYM-PORCH-Playout-Logs  462   b , which has the exact details of all input parameters for the currently completed video frame. 
 
 
     
     
         10 . A method of  claim 8  wherein the Delay Buffer Manager (DBM) further comprises the steps of:
 a. Filling one or more delay buffers  402 - 406  with encoded video streams from one or more PLYM instances ( 403 ,  405 ) wherein the PORCH  409  instructs at least one PLYM instance to Playout ahead of a duration of time-advancement time 1   412 , which is more than the need to switch between PLYMs while maintaining the output stream in a time-continuous fashion; 
 b. The Timed data buffer selector  407 :
 i. Choosing the delay buffer from which the encoded data is to be accessed for output and the PORCH triggering this delay buffer to action by giving it the time of day from when it should start the output streaming, provided as a start instruction with the duration of time-advancement time 1   412 , which is the time of the Playout in accordance with a playlist; 
 ii. On receiving this instruction  412 , the Timed data buffer selector  407  starting its own clock  408 , which acts as the reference timer for the Multiplexer and output streamer module  410 ; and 
 iii. Based on the output stream periodicity needs as dictated by the clock  408 , the Timed data buffer selector  407 , finding the highest sequence numbered delay buffer with the needed timed data, wherein a higher number indicates a greater priority such that the PORCH implements a selection policy for the right PLYM output by providing the selected PLYM output to be sent to the highest sequence numbered delay buffer; and 
 
 c. Transferring this to the Multiplexer and output streamer module  410 , which then sends out output stream. 
 
     
     
         11 . A method of  claim 10  wherein the Timed data buffer selector  407  receives a ‘Start output streaming @time 1 ’ message  501  further comprising the steps of:
 a. Starting the timer  502  when day clock is time 1  and then starting an iterator for each of the video frame rate period  503 ; 
 b. Starting another iterator  504  for each frame rate period T(i) to go over all the delay buffers, by going from the largest to the smallest delay buffer count; and 
 c. Upon finding timed data in the jth delay buffer, selecting that and passing it onto Multiplexer and output streamer module  506 , else the Timed data buffer selector iterating through to a lower sequence numbered delay buffer  507 . 
 
     
     
         12 . A method of  claim 8  for Playout redundancy comprising the steps of:
 a. Instantiating PLYM_Instance_ 1  at a time earlier than time 1   701  which is the wall clock time at which Playout is to start as per playlist, with the start of playlist parameters mapping its output to delay buffer_ 1  of DBM  702 , which is the primary Playout for creating the linear feed; 
 b. Calculating a Time difference between time 1  and time of start PLYM_Instance_ 1  Playout so as to exceed the time taken for instantiating PLYM_Instance_ 2  and getting the output of that Playout to reach delay buffer_ 2 , thereby guaranteeing that during the time from start of a PLYM_Instance_ 1  crash to the time for output from PLYM_Instance_ 2  reaching delay buffer_ 2  DBM output stream is maintained without any disruptions; 
 c. Instructing the DBM to start streaming output at time 1   703  once the PLYM_Instance_ 1  is up, time 1  being the wall clock time specified in the playlist for start of Playout; 
 d. The PORCH continuously monitoring PLYM_Instance_ 1  to see that the Playout is happening as planned  704 ; 
 e. The PORCH identifying a failure of PLYM_Instance_ 1  and instantiating PLYM_Instance_ 2   705 , which is the secondary Playout instance at a ‘fast rate’ to compensate for the time of crash and for the time taken to bring up the secondary Playout; 
 f. Setting all input parameters to enable Playout to continue stream from the point of failure of PLYM_Instance_ 1 ; 
 g. The PORCH checking the reason for the failure of PLYM_Instance_ 1   706  once PLYM_Instance_ 2  is up and running; 
 h. Re-instantiating PLYM_Instance_ 1  is in a different environment, so as solve the cause of failure  707  wherein one or more input parameters to start Playout are at a future point in time, which exceeds total duration that has been spent in bringing up PLYM_Instance_ 2 , and now PLYM_Instance_ 1 ; 
 i. PLYM_Instance_ 1  on starting of Playout taking over as the primary Playout; 
 j. The PORCH checking if the PLYM_Instance_ 1  is stable  708  and if not, restarting the process of identifying an alternate reason for failure  707 . 
 k. The PORCH bringing down the secondary PLYM_Instance_ 2   709  once the PLYM_Instance_ 1  is stable and going back to monitoring PLYM_Instance_ 1  as the primary Playout option  704 ; and 
 l. Maintaining Playout output continuity even when the primary Playout instance had crashed and realizing the same on an on-demand basis without the need for a fully redundant Playout. 
 
     
     
         13 . A method of  claim 12  wherein the PORCH ensures delay buffer_ 1  and delay buffer_ 2  have the same timed data as part of the overlap sequence in bringing back the primary Playout. 
     
     
         14 . A method of  claim 8  for cost-optimization of Playout across its lifetime using the cost arbitrage available in renting cloud server time comprising the steps of:
 a. Checking a Bid server for availability of a lowest-priced server  902  at a time earlier than time 1   901  which is the wall clock time at which the Playout is to start as per playlist; 
 b. Instantiating PLYM_Instance_ 1  on the lowest priced server with the start of playlist parameters and its output mapped to delay buffer_ 1  of DBM  903  which is the primary Playout for creating the linear feed; 
 c. Calculating a time difference between time 1  and time of start PLYM_Instance_ 1  Playout so as to exceed the time taken for instantiating PLYM_Instance_ 2  and getting the output of that Playout to reach delay buffer_ 2  thereby guaranteeing that during the time of switch from PLYM_Instance_ 1  to the time for output from PLYM_Instance_ 2  reaching delay buffer_ 2  the DBM output stream is maintained without any disruptions; 
 d. Instructing the DBM to start streaming output at time 1   904  once the PLYM_Instance_ 1  is up, time 1  being the wall clock time specified in the playlist for start of Playout; 
 e. The PORCH periodically checking for the Bid server with the lowest price for the servers  905  by checking if the current played out server instance price is less than the new available lowest bid server price  906 :
 i. If so the PORCH continuing to monitor the Bid server for lowest price and comparing the same with the current played out instance price  907 , wherein if there is a server instance with a lower price, then instantiating PLYM_Instance_ 2  on the new Bid server  908  at a ‘normal rate’ and providing the inputs to start Playout at a future point in time wherein the specific time offset for playing out should exceed the maximum time taken for PLYM_Instance_ 2  to be instantiated, content assembled, encoded and received in delay buffer_ 2  of the DBM; 
 
 f. Bringing down PLYM_Instance_ 1  and renaming PLYM_Instance_ 2  to PLYM_Instance_ 1   909 , once PLYM_Instance_ 2  is active; 
 g. Changing the output of the renamed PLYM_Instance_ 1  to point to delay buffer_ 1  on DBM to effect switching the servers for Playout without interruption of the final output stream from DBM; and 
 h. The PORCH iterating looking for lower cost servers  910 .