Mechanisms provide intermediate key frame animation during a media seek. A streaming server receives a seek request from a client device while the streaming server provides the client device with a media stream. The seek request is made when the media stream is playing at an initial location and the seek request includes a request to play the media stream from a seek location. In some embodiments, intermediate key frames before the seek location are identified. In other instances, intermediate key frames between the initial location and the seek location are identified. These intermediate key frames are provided to the client device for display before the media stream begins playing at the seek location.

Methods and systems are provided for adjusting a size of a buffer based on a probability that a rewind request will be received during a currently playing segment of media. When the system determines that receiving a rewind request is likely, the system will increase the size of a buffer such that the rewind request can be accommodated using data from the buffer. When the system determines that receiving a rewind request is unlikely, the system will decrease the size of the buffer to free resources for other system components.

Systems and methods are disclosed herein for avoiding playback of an advertisement by selectively switching between media streams. To this end, a media guidance application receives a plurality of media streams from different sources, switches to a first media stream and plays back a first media asset of the first media stream, and determines that an end to playback of the first media asset is imminent. The media guidance application then determines whether a second media stream of the plurality of media streams is within a threshold amount of time of playing back a beginning of a second media asset, and if the second media stream is within the threshold amount of time of playing back the beginning of the second media asset, the media guidance application switches from the first media stream to the second media stream and plays back the second media asset.

Methods and system for providing content are disclosed. One method can comprise receiving a request for data at a first time, wherein the data comprises a first time duration, determining a buffer size based upon the first time duration, and determining a playback window based upon the determined buffer size and the first time. The method can also comprise synchronizing presentation of content on a plurality of devices.

The disclosure provides a connection allocation method in a media playing process, including: receiving playing requests initiated by a player embedded in a webpage, wherein the player plays media data in the webpage; storing the received playing requests into a buffering queue to queue according to a receiving sequence of the playing requests; and allocating connections to the playing requests in the buffering queue according to an upper limit of the number of concurrent connections usable for the buffering queue and the receiving sequence, wherein the connections are used for the player to request to-be-played media data. The disclosure further provides a media playing device and a storage medium.

Embodiments described herein relate to real-time streaming of large quantities of time critical data over multiple distinct networks from a communications device. More specifically, embodiments described herein may address challenges and problems of maintaining consistent data reception quality when faced with the anomalies of a moving sender that is sending data using a relatively unstable method. This may be achieved by converting single source data into multiple data streams, placing them in transport buffers and storing them for forwarding.

Methods and system for providing content are disclosed. One method can comprise receiving a request for data at a first time, wherein the data comprises a first time duration, determining a buffer size based upon the first time duration, and determining a playback window based upon the determined buffer size and the first time. The method can also comprise synchronizing presentation of content on a plurality of devices.

Prior to receiving a request from a client device for information from a content distribution network (CDN), a Reductive Edging device predictively requests the information from the CDN based on prior user activity and stores it in memory. The Reductive Edging device is thus configured to respond to the request from the client device for information from the CDN with the information stored in the memory prior to receiving the request.

A receiver driven approach for playback of remote content is described. One embodiment includes obtaining information concerning the content of the media file from the remote server, identifying a starting location within the media sequence, identifying byte ranges of the media file corresponding to media required to play the media sequence from the starting location, requesting the byte ranges required to play the media sequence from the starting location, buffering received bytes of information pending commencement of playback, playing back the buffered bytes of information, receiving a user instruction, identifying byte ranges of the media file corresponding to media required to play the media sequence in accordance with the user instruction, flushing previous byte range requests, and requesting the byte ranges required to play the media in accordance with the user instruction.

Techniques are described for low-latency streaming of media content using a lossless protocol. For example, a media stream, comprising encoded video data, can be streamed to a plurality of streaming clients via the lossless protocol. The plurality of streaming clients can be monitored to determine whether any of them have fallen behind in streaming the media stream. When a streaming client falls behind, a portion of video data to be streamed to the streaming client can be selectively dropped based on scalability information and/or long term reference (LTR) frame information. The low-latency streaming can be performed without using per-client quality feedback from the plurality of streaming clients. When streaming using a semi-lossy protocol, a plurality of delivery modes can be used, where each delivery mode is for a different type of encoded video data and provides a different level of reliability.