Low-latency http live streaming

Abstract

Implementations provide low-latency live-video streams using existing content delivery networks. An example method includes receiving a video broadcast as a series of frames and determining, for each frame, whether the frame is a break frame. Responsive to determining that the frame is a break frame, the method includes removing an in-progress tag from a current segment file in a playlist for the video broadcast. The playlist includes at least a previous segment file, the current segment file, and a next segment file, which also has a respective in-progress tag. The method also includes associating the frame with a next segment file in a playlist and transmitting the playlist to a cache server. Responsive to determining the frame in the series of frames is not a break frame, the method includes associating the frame with the current segment file. The frame is transmitted to the cache server as a chunk.

1 . A method comprising:
 receiving a playlist for a video broadcast from a caching server, the playlist identifying a plurality of segments, the plurality of segments including a completed segment and at least one segment with an in-progress tag, the in-progress tag indicating that the at least one segment is not fully written, wherein each segment in the plurality of segments has a respective target duration;   requesting the completed segment and the segment with the in-progress tag, from the caching server;   repeatedly receiving content from the caching server, the received content being associated with a segment of the plurality of segments; and   determining a starting segment of the plurality of segments based on the in-progress tag,   wherein received content for the starting segment is added to a playback buffer first.   
     
     
         2 . The method of  claim 1 , wherein determining the segment to start playing is further based on respective date-time tags associated with the plurality of segments in the playlist. 
     
     
         3 . The method of  claim 1 , further comprising:
 requesting, at regular intervals, the playlist; and   responsive to receiving an updated playlist with a new in-progress segment, sending a request for the new in-progress segment.   
     
     
         4 . The method of  claim 1 , further comprising:
 determining a size of the playback buffer based on network jitter and a minimum buffer size.   
     
     
         5 . The method of  claim 4 , wherein the network jitter is included in a tag in the playlist. 
     
     
         6 . The method of  claim 1 , wherein each segment of the plurality of segments has a respective date-time tag and the method further includes:
 determining, based on the in-progress tag and the respective date-time tags, a playback buffer size and a particular segment of the plurality of segments to request first.   
     
     
         7 . The method of  claim 1 , the method further comprising:
 determining, for received content, whether the content is an end-of-file message, wherein the end-of-file message refers to a segment;   responsive to determining the received content is not an end-of-file message, adding the content to a pipeline for rendering frames associated with the segment associated with the received content; and   responsive to determining the received content is an end-of-file message, switching to a decode pipeline for a next segment in the playlist.   
     
     
         8 . The method of  claim 1 , wherein the respective target duration is an approximate duration. 
     
     
         9 . The method of  claim 1 , wherein portions of the at least one segment are received from the caching server before the at least one segment is fully written. 
     
     
         10 . A player apparatus comprising:
 at least one processor; and   memory storing instructions that, when executed by the at least one processor, cause the player apparatus to perform operations including:
 receiving a playlist for a video broadcast from a caching server, the playlist identifying segment files including at least a completed segment and at least one segment with an in-progress tag, the in-progress tag indicating that the at least one segment is not fully written, 
 requesting the completed segment and the segment with the in-progress tag, from the caching server, 
 using the in-progress tag to determine one of the segment files to start playing when joining the video broadcast, and 
 start playing the video broadcast from the determined one of the segment files. 
   
     
     
         11 . The player apparatus of  claim 10 , wherein portions of the at least one segment are received from the caching server before the at least one segment is fully written. 
     
     
         12 . The player apparatus of  claim 10 , wherein received content for the determined one of the segment files is added to a playback buffer first. 
     
     
         13 . The player apparatus of  claim 12 , the operations further including:
 determining a size of the playback buffer based on network jitter and a minimum buffer size.   
     
     
         14 . The player apparatus of  claim 13 , wherein the network jitter is included in a tag in the playlist. 
     
     
         15 . The player apparatus of  claim 10 , wherein each segment in the segments has a respective target duration. 
     
     
         16 . The player apparatus of  claim 15 , wherein the respective target durations are approximate durations. 
     
     
         17 . The player apparatus of  claim 10 , the operations further including:
 requesting, at regular intervals, the playlist; and   responsive to receiving an updated playlist with a new in-progress segment, sending a request for the new in-progress segment to the caching server.   
     
     
         18 . The player apparatus of  claim 10 , wherein each segment of the segments has a respective date-time tag and the operations further include:
 determining, based on the in-progress tag and the respective date-time tags, a playback buffer size and the one of the segment files to start playing.   
     
     
         19 . A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, causes a computing device to perform operations including:
 receiving a playlist for a video broadcast from a caching server, the playlist identifying segment files including at least a completed segment and at least one segment with an in-progress tag, the in-progress tag indicating that the at least one segment is not fully written;   requesting the completed segment and the segment with the in-progress tag, from the caching server;   using the in-progress tag to determine one of the segment files to start playing when joining the video broadcast; and   start playing the video broadcast from the determined one of the segment files.   
     
     
         20 . The non-transitory computer-readable medium of  claim 19 , wherein the at least one segment with the in-process tag has a target duration.