Partial video pre-fetch

The disclosed configuration includes a partial pre-fetching of source files from an origin server for playback. After pre-fetch, the remaining portions of a source file may be optimized for retrieval. By providing partial pre-fetch of source files, in conjunction with optimization, automatic video preview may be supported and source file presentation may begin in a timely fashion in response to user requested playback without inordinate bandwidth consumption.

BACKGROUND

1. Field of Art

The disclosure generally relates to improving user experience on a network, and more specifically, to optimizing video pre-fetch in a network.

2. Description of the Related Art

Mobile devices, such as smart phones and tablets, have become prevalent in recent years. Given the advances in mobile computing power and far-reaching wireless Internet access, more and more users view streamed videos on their mobile devices. There are many cases where it is desirable to have an “instant play” video experience on these mobile devices. Imagine, for example, a social media feed with embedded videos. It is common to click play and be met with long start times. As user tolerance for long start times is low, a user may quickly move on to other feeds/content when embedded videos have long start times.

To compensate for this, many applications pre-fetch the entire video before it is shown in order for it to be available as soon as the user clicks play or otherwise encounters the video (e.g., by the video appearing within a viewed portion of a display of the mobile device). The disadvantage being that pre-fetching the entire video can consume large amounts of network data. This can make it prohibitively expensive to download such data over mobile (or cellular) networks. As a consequence, these entire video pre-fetches are typically restricted to WiFi networks only.

DETAILED DESCRIPTION

Overview

To get the benefit of instant-on playback without having to download the entire file, partial pre-fetch of the source file is performed. For example, the first portion of a video file may be retrieved, but the remainder is not retrieved until needed (e.g., user requesting presentation of the video). In some embodiments, the pre-fetch portion of the source file provides 5-30 seconds of playback, at which point playback is continued through retrieval of additional source file data.

In an example automatic video play application, the pre-fetch portion of the source file may loop to provide a preview of the source file. In turn, if the user chooses to play the source file, the user device initiates playback of the pre-fetched portion to begin presentation of the video and requests the remaining data of the source file to continue video playback. The remaining data of the source file may also be requested in segments. In non-automatic play applications, the pre-fetch portion of the source file provides immediate start of video playback while the remaining data of the source file is retrieved.

In some embodiments, measurable network parameters (e.g., round trip times, latency, packet size, etc.) indicative of available bandwidth to the user device associated with providing the requested source file and are used to ascertain the quality or condition of the network connection of the user device. In embodiments where the user device is capable of adaptive bitrate (ABR) video playback, parameters of requests for additional source file data can be chosen to minimize the risk of stalling while maximizing source file quality for playback at the user device. In embodiments where the user device is not capable of playing ABR content, the remaining source file data may be delivered in the same format as the pre-fetch portion. Although the delivery of the source file data cannot be adjusted through ABR to adapt to changing network conditions, if the user device has a sufficient network connection to playback the source file in the original format, the presentation of the source file may begin without delay through playback of the pre-fetched portion and playback may continue without stalling because the duration of pre-fetch playback allows for retrieval of additional source file data.

In some embodiments, an origin server does not need to transcode a source file into all possible video bitrates for ABR playback. Instead, a selection of (or a) common bitrates (e.g., between 300-500 kbps) may be used for transcoding. Pre-fetch portions may be generated to correspond to each of the bit rates in the selection (or even a wider range). In turn, when a user device starts playback of a pre-fetch portion, the user device measures network parameters when retrieving additional source file data and determines whether to request source file data at a new desired bitrate. To serve a request specifying a desired bitrate for additional source file data, the server may generate a transcoded version of the source file on-the-fly according to the desired bitrate specified in the request or select a version of the source file (e.g., previously generated at one of the selected of bitrates) having a bitrate similar to that requested by the user device.

In one embodiment, as transcoded versions of the source file (pre-fetch portions and/or ABR segments thereof) are generated, they can be placed into a cache on the server-side so that the next time a user device requests the source file with similar parameters, it does not need to be transcoded again. Additionally, because transcoded versions of the source file may be created on-the-fly, cached versions of a source file not frequently requested may be purged. In some embodiments, especially those related to delivering user-generated content (UGC), many hundreds of thousands of source files are uploaded but few are consumed frequently. Therefore, the server may purge the cache of and/or not cache transcoded versions of source filed that are rarely requested. However, if the origin server detects many requests for a source file, the source file may be pre-transcoded for the selection of bitrates and/or transcoded versions created on-the-fly for different bit rates may be cached.

Video Pre-Fetching Environment

Referring now to FIG. (FIG. 1, it illustrates a high-level block diagram of an example communications environment100for optimizing video pre-fetch in a network. The environment100comprises user device110and an origin server170coupled by a network120. The network120is a communication network that transmits data between the user device110and the origin server170. In one embodiment the network120includes a mobile wireless (or cellular) network and the Internet (or other like wide area network). The mobile wireless network is configured to allow long range communication over the network, e.g., coast to coast mobile telephone calls, text messages, etc. Moreover, data services (e.g., access to the internet or other cloud services) are available over these mobile wireless networks from a variety of locations (e.g., mobile (or cellular) tower access points) without the need for short range local area wireless networks (e.g., wireless fidelity (or WiFi) networks). Further, it is noted that the mobile wireless networks are accessed through a device's radio integrated circuit chips that are configured to communicate on frequencies set by a mobile provider and are different from the radio frequencies of WiFi radio integrated circuit chips. Here, for ease of discussion this mobile (or cellular) wireless network is referenced as a wireless network.

In the illustrated embodiment, the network120may include a mobile network access point121for mobile wireless network access (e.g., 2G/3G/4G/5G/Long Term Evolution (LTE) etc.) through which mobile user devices110such as wireless mobile telephones and tablets retrieve data from and transmit data onto the network120. Typically, the mobile access point (e.g., mobile (or cellular) tower access point)121is associated with a provider servicing the user device110through a data plan. While only one user device110is shown, environment100may include many user devices configured as described herein that communicate with the server170. Likewise, a user device110may communicate with many different servers configured similar to server170in such environments100.

A network efficiency strategy that aspires to keep capital expenditure from outpacing revenues has to be balanced with demands from consumers for better user experiences that rely increasingly on higher data usage. Today, mobile operators are employing a variety of tools to manage capacity including data usage caps, WiFi offload, and intelligent optimization. The environment100demonstrates such a solution that provides a user experience for pre-fetching video through a wireless access point121to the network120similar to that afforded over a WiFi or hard-wire connection to the interne without the typically high data consumption involved with pre-fetching video. The solution need not be limited to network120access through a wireless access point121of a provider servicing a user device110as data caps are increasingly employed for all types of service plans such as for residential Internet subscribers. In practice, such a solution is most beneficial when user data caps and/or available bandwidth are at a minimum, which is typical in the case of user device access to the network120through subscription-based access (e.g., a mobile data plan) to a provider's access point121.

In one embodiment, the user devices110are computing devices with network access capabilities. Oftentimes, for example, the user devices110are wireless enabled mobile computing device with a web browser (not shown) and media consumption capability. The user devices110as mobile computing devices may include laptops, netbooks, tablets, smart telephones, or personal digital assistants (PDAs) and can be configured as described inFIG. 2. These example devices may be permitted to connect to the wireless access point121of the provider through a compatible wireless integrated circuit chip and/or coupling thereto having an associated subscription/service agreement with the provider that affords user device110access the network120. The web browsers may be software applications running on mobile devices110for retrieving online content such as web pages with embedded media content from the origin server170and presenting the online content on a display of, or coupled to, the user device device.

As shown, the user device110includes a media player111, a source multiplexer113A, a file cache115, a network fetcher117, and a network monitor140. Each of these may be configured in software. Software comprises computer program instructions (or code) that is storable in a storage medium (e.g., disk, a flash memory and/or random access memory) and executable by one or more processors (generally, processor). Specifically, the software is configured (or programmed) to enable the functionality as described when executed by the processor. An example of a device that stores and executes the instructions is described withFIG. 2.

In instances where online content includes media content, the media content may be presented by a media player111. For example, a web browser may communicate with a media player111on the user device110to retrieve and present media content from the server170within a webpage. In such cases, the media player111may be configured within an HTML5 compatible web browser or implemented as a plug-in or a standalone application invoked by the browser to present the media content. The media player111may also be included in (or as) a standalone application for presenting media content retrieved from the server170. Media content presented by the media player111may include audio content, video content, or other types of streamed content. Source files for media content may include one or more types of media content, for example, a source file may be multimedia content including video content and associated audio content. While video is discussed at length herein for ease of explanation, it should be taken to also include multimedia video content including audio content as well as standalone audio content, all of which may be handled in a similar fashion.

The source multiplexer113A of the user device110is configured to provide source file media content to the media player111for presentation. By way of example, the source multiplexer113A is configured to provide the media player111with the media content to be displayed on the user device110from the source file. The source multiplexer113A also may be configured to retrieve the media content from a local source file data on the user device110and/or from a stream of the source file data from the network120(e.g., by the server170). In the context of partial video pre-fetch, the local source file data may be a partial video pre-fetch (e.g., source file data corresponding to the first 5 to 30 seconds of the video) and the streamed source file data may be the remaining content of the video. The source multiplexer113A may switch between the local source file data and the streamed source file data to seamlessly present, first, the partial video pre-fetch (e.g., when the media player111initiates presentation) stored locally and, subsequently, the remaining content of the video streamed to the user device110. Thus, when the media player111is invoked to present a particular source file (e.g., video), the source multiplexer113A locates a corresponding video pre-fetch stored locally for the source file to allow presentation of the video to begin, and requests streaming of the remaining source file data from the server170to allow presentation of the video to continue. The source multiplexer113A streams the remaining source file data from the server170until the media player111moves onto other content, presentation is ceased (e.g., paused, finished), or is otherwise terminated and additional source filed data is no longer needed for presentation.

In some embodiments, the browser and/or media player111distinguishes between an “auto-play” of the source file (e.g., automatic presentation of media content upon a display area for presentation of the source file appearing within viewable display on the screen of the user device110) and a “user-play” of the source file (e.g., the user explicitly requesting presentation of media content through input such as selection of a user interface element (e.g., a “play” button) corresponding to requesting playback of the source file within the browser/media player111). Thus, embodiments of the media player111may detect whether a source file is automatically played or a user explicitly requests playback of the source file. An indication of user-play or auto-play may be passed to the source multiplexer113A. In response to an indication of auto-play, the source multiplexer113A may provide the media player111with a loop of pre-fetch source file data (e.g., allowing the user to preview the pre-fetched portion of the source file during auto-play). In response to an indication of user-play, the source multiplexer113A provides the media player111with the pre-fetch source file data (e.g., from the beginning of the video) and request streaming of additional source file data (e.g., from the end of the pre-fetched portion of the video) from the server to continue presentation of video from the end of the pre-fetched portion of the source. The above implementation may be used to avoid excessive requests associated with streaming video associated with auto-play of source files that consumes excessive amounts of the user data allowance.

In some example instances, the media player111is configured to support an adaptive bitrate (ABR). In such cases, the additional source file data requested to continue video playback through the media player111may be requested in partial pieces or segments (e.g., 5 or 30 seconds at a time, a duration similar to the partial video pre-fetch). A request for a next segment may specify a bitrate for the segment based on the network conditions experienced at the user device110. Accordingly, the source multiplexer113A provides these remaining pieces in sequential order to the media player111for presenting the video.

The file cache115of the user device110is configured to store partial video pre-fetches and other online content received at the user device110from the network120. For example, when online content retrieved by a browser includes a number of videos, a partial pre-fetch of video source file data for each video may be stored in the file cache115. In turn, when the media player111is invoked to present a given video, the source multiplexer113A may retrieve the corresponding pre-fetched data of the video source file from the file cache115to begin presentation of the given video.

The network fetcher117of the user device110is configured to retrieve source files from the network120. In one embodiment, the network fetcher117is a software (computer program instructions) based HTTP client. The network fetcher117also may be configured to determine how much of the source file to retrieve. Again, in the example where online content such as a web page retrieve by a browser includes a number of videos, the network fetcher117may request an initial portion (e.g., 5-30 seconds) of each video source file to populate the file cache115with a video pre-fetch for each video. In turn, when the source multiplexer113A requests the remaining portion of a source file from the network fetcher117(e.g., in response to a user-play) to allow continued presentation of the video from the end of the video pre-fetch, the network fetcher117requests the source file over the network120to retrieve the remaining portion of the source file (e.g., in a stream of additional source filed data from the origin server170). The network fetcher117continues the streaming additional source file data until streaming is complete (e.g., source file has reached an end) or the source multiplexer113A ceases to request streaming of the source file.

In instances where ABR is supported, the network fetcher117may receive a request indicating a desired bitrate for retrieving a segment of the source file. In some embodiments, the desired bit rate may be adjusted throughout source file retrieval. For example, the network fetcher117may retrieve an initial portion of the source file for the video pre-fetch at a first bit rate and request a subsequent portion of the source file (e.g., to continue play via streaming) at a second bit rate. As the subsequent portion of the source file may be streamed in segments, the network fetcher117may further request a different bitrate for a next segment as network conditions such as bandwidth available to the user device change.

In instances where ABR is not supported, the network fetcher117may receive a desired bit rate for retrieving the source file or a default bitrate, but will be unable to adjust the bit rate after retrieval begins. That is, the source file is considered as a whole file rather than in segments. While this may seem incongruent with retrieving an initial portion of the source file for a video pre-fetch, the source file may still be retrieved in segments, albeit without adjusting parameters. For example, the network fetcher117may request streaming source file data to retrieve a pre-fetch portion of the source file and wait the transfer of the remaining portion (e.g., by pausing connection, not requesting data, not acknowledging receipt of data, etc.). Thus, the network fetcher117is configured to request the source file to initiate streaming for retrieving an initial portion for the video pre-fetch and waits the stream until additional source filed data is requested by the source multiplexer113A, at which point the stream is resumed to retrieve the remaining source file data (e.g., by continuing connection, requesting data, acknowledging receipt of data, etc.).

The network monitor140monitors the request and retrieval of source files on the user device110. For example, the network monitor140monitors the operations of the network fetcher117. The network monitor140specifically monitors the network conditions associated with the retrieval of source file data by the user device. In turn, the network monitor140provides desired bit rates to the network fetcher117for retrieving source files. The network monitor140may also include other desired parameters in addition to desired bit rate such as frame width, frame height, sample rate, audio properties and the like. The network fetcher117may provide these parameters in requests for source file data which may be used by the origin server170streaming the source file to select a particular version of the source file for streaming and/or for transcoding the source file to a version of the source file for streaming that best meets the needs of the user device110.

The server170, or origin server, is a computer server that provides source files, such as video and audio, to the user device110via the network120. An example of a server architecture is described withFIG. 2. The server170includes a network request handler151, a source multiplexer113B, a cache source115, and a video transcoder. Each of the may be configured in software.

The network request handler151of the server170is configured to process received requests for source files and streams source file data for transmission to the user device110through the network120. The network request hander151passes the requests to the source multiplexer113B and, in turn, receives from the source multiplexer113B the corresponding source file data to stream to the user device110. In one embodiment, the network request handler151is an HTTP client.

The source multiplexer113B is configured to receive a source file request and provides the network request handler151with corresponding source file data to be provided to the user device110in response to the request. The source multiplexer113B may retrieve source file data from the cache database160for streaming to the user device110by way of the cache source155or from the video transcoder150. The source multiplexer113B can switch between the cache source155and the video transcoder150based on the desired parameters for the source file specified in the request. For example, the source multiplexer113B may pass the parameters of the request to the cache source155, which identifies a version of a source file in the cache database160that matches and/or most closely matches the desired parameters for streaming to the client.

The source multiplexer113B also can be configured to pass the parameters for the request to the video transcoder150. If the parameters specified in the request deviate too far from any version of the source file in the cache database160as identified by the cache source155, the source multiplexer113B may switch to the video transcoder150, which transcodes, on demand, a version of the source file in the cache database160that matches the parameters specified in the request. In turn, the source multiplexer113B provides the transcoded source file data matching the parameters in the request received from the video transcoder150to the network request handler151for streaming to the user device. As the desired parameters may change across requests in supporting ABR, the source multiplexer113B may pass updated parameters for a requested segment to the cache source155and video transcoder150and determine from which to retrieve source file data for the requested segment. Thus, for example, the source multiplexer113B may switch back to the cache source155if the updated parameters for the requested segment match or closely match an existing version of the source file in the cache database160to offload the transcoder150.

The video transcoder150is configured to ingest source file data from the cache database160or other source and transcodes the source file data to produce a reduced bit rate stream and/or alternate encoding format of the source file. The video transcoder150may transcode source file data in real-time based on parameters specified by the source multiplexer, such as those in a user device request for a source file and/or segment thereof. The video transcoder150may store the transcoded data from the source file temporarily in a local storage for streaming, or transfer the transcoded data to the cache database160to store as a transcoded version of the source file. Thus, for example, in the cases where a source file is being transcoded frequently, the transcoded version may be stored in the cache database160to offload the transcoder150from future requests.

The cache database160enhances the performance of the video transcoder150by eliminating the need to re-transcode source files into versions that the source file was previously transcoded into. In an embodiment, the cache database160stores the location of cached optimized versions of source files is association with the source file and their associated parameters for identification by the cache source155.

In addition to the location of the cached optimized source file, the cache database160may also contain stored last access times for each source file and its transcoded versions and total number of hits/requests for each source file and transcoded versions. Information may be collected on the different transcoded versions to identify those most often provided to user devices110. In turn, the cache database160purges transcoded versions that are requested infrequently. Accordingly, the cache database160may be efficiently managed to ensure that transcoded versions of the newer and/or more popular source files are available for distribution. In one embodiment, the video transcoder150considers cached transcoded versions of source files for deletion according to one or more of the following: least frequently used versions, last access time, number of hits (e.g., total period and last period, e.g., a rolling time window), number of duplication requests (e.g., trending up), size of version (e.g., larger files may be purged faster than smaller files to save room), or previously/recently purged (e.g., trending down).

In one example embodiment, the cache database160deletes cached versions of source files in small chunks over a long period of time in order to keep the system processor load necessary for deletion operations down to a minimum. In some instances, the cache database160redirects requests from accessing a version of a source file identified for purging prior to deletion. For example, once all user requests are redirected (e.g., to another version or to the video transcoder), the version of the source file can be deleted without affecting any user's streaming experience. In one embodiment, the cache database160maintains (more so than full transcoded versions of source files) small segments of transcoded versions of a source file to more efficiently serve the video pre-fetch operations of the user device110by eschewing the need to transcode video pre-fetches.

The cache database160and origin server170are typically formed of one or more computer servers, which may include components and functionality described in more detail with reference toFIG. 2. While only one server of each origin server170and cache database160are shown in the environment100ofFIG. 1, different embodiments may include multiple servers and caches operated by a single entity or multiple entities. In other embodiments, a single server may also provide different functionalities, such as delivering web content as a web server, as well as serving video content from source files. User devices110may also include components and functionality similar to those described inFIG. 2.

Computing Machine Architecture

Turning now toFIG. 2, it is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor (or controller) to implement the disclosed system for on-demand real-time network monitoring and subscriber identification. The example machine provides an example of how the devices inFIG. 1, for example, user device110, server170and cache database160may be structured. Each of these devices may use all or parts of the components shown and described inFIG. 2.

Continuing withFIG. 2, it shows a diagrammatic representation of a machine in the example form of a computer system200within which instructions224(e.g., software or program code) for causing the machine to perform any one or more of the methodologies and/or software functionality discussed herein may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine, e.g., server170or a client machine, e.g., user (or client) device110, in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Moreover, portions of the described architecture may be applied to dedicated machines configured to perform specific programmatic tasks, for example, as a database server (e.g., database160) that may operate with the server170.

The example computer system200includes one or more processors202(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these) (generally, processor202), a main memory204, and a static memory206, which are configured to communicate with each other via a bus208. The computer system200may further include graphics display unit210(e.g., a plasma display panel (PDP), a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)). The computer system200may also include alphanumeric input device212(e.g., a keyboard), a cursor control device214(e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit216, and a network interface device220, which also are configured to communicate via the bus208.

The storage unit216includes a machine-readable medium222on which is stored instructions224(e.g., software or program code) embodying any one or more of the functions or methodologies described herein. The functions include, for example, the functions described with the user device110and the server170inFIG. 1. The methodologies include those described below withFIGS. 3A and 3B. The instructions224may also reside, completely or at least partially, within the main memory204or within the processor202(e.g., within a processor's cache memory) during execution thereof by the computer system200, the main memory204and the processor202also constituting machine-readable media. The instructions224may be transmitted or received over a network120via the network interface device220. It is note that the network interface device220includes radios integrated circuit chips configured for communicating with the wireless network121and Internet.

FIGS. 3A-3Billustrate embodiments of example event traces for performing partial video pre-fetching.FIG. 3Ashows an example of partial video pre-fetching for a source file at an example user device, e.g., user device110. When the user device110retrieves online content such as a web page including video, the network fetcher117requests the source file for the video in the web page from the network. Rather than retrieving the full source file, the network fetcher117retrieves300a pre-fetch portion of the source file and stores the pre-fetch portion in the file cache115. In one embodiment, for example, the network fetcher117may request the source file and wait the transfer of source file data after retrieving a sufficient portion for the pre-fetch to store in the file cache115. In another embodiment, where the media player111supports ABR playback, the network fetcher117requests a segment of the source file to store as the pre-fetch portion. In either instance, the network fetcher117requests the source file or segment thereof along with desired parameters for the source file (e.g., bit rate, format, etc.) and a pre-fetch portion of the source file is stored in the file cache.

The media player111requests301the source file from the source multiplexer113A for presentation. The request301may result in response to an auto-play of the source file or a user request to play the source file, which is identified to the source multiplexer113A. Because a pre-fetch portion of the source file is stored in the file cache115, the source multiplexer113A requests303the pre-fetch portion from the file cache that includes a first portion of source file data (e.g., affording 5-30 seconds of playback). The file cache115returns305A the pre-fetch portion which the source multiplexer113A returns305B to the media player111allowing for presentation of the source file to begin.

In an auto-play scenario, the pre-fetch allows for the presentation of a preview of the source file without retrieving the whole source file that unnecessarily consumes user data allowance if the user chooses not to watch the video. In response to a request301indicating an auto-play, the source multiplexer113A may loop the pre-fetch portion303until the media player111no longer requests the source file.

The media player111may require additional source file data after receipt of the pre-fetch portion for an auto-play. For example, the media player111may require additional source file data in response to user play of the video after an auto play because the pre-fetch portion only includes a first portion of source file data. Accordingly, the source multiplexer113A may receive a subsequent request307for the source file from the media player111. The source multiplexer113A identifies the subsequent request for user-play of the source file307cannot be served from the file cache115because the initial pre-fetch portion of the source file is already returned305B to the media player111for video preview. In turn, the source multiplexer113A requests309the network fetcher117to retrieve additional source file data from the network.

In a user play scenario, the pre-fetch affords instant playback. Accordingly, in response to a request301indicating user play, the source multiplexer113A may proceed to request309fetch additional source file data from the network without waiting on a subsequent request307for the source file indicating user play after an auto-play.

The network fetcher117retrieves311additional source file data from the network, the additional source file data may correspond to a second portion of source file data subsequent to the first portion of source file data returned to the media player111in the initial pre-fetch operation (e.g., elements301-305). For example, in ABR enabled cases, the second portion of source file data may be a second segment of the source file (where the initial pre-fetch portion is a first segment of the source file). In turn, the network fetcher117returns the source file data313A for the second segment to the source multiplexer113A. The source multiplexer113A switches from the file cache115to the network fetcher117once the pre-fetch segment is consumed in order to return313B the source file data for the second (and any additional) segment to the media player111to allow continuation of source file playback at the user device. In ABR enable cases, the request/return operations for segments may be performed until the media player consumes all the segments of the source file or ceases playback.

In non ABR cases, the additional source file data may correspond to a second portion of source file data that affords continuation of data provided by the source multiplexer113A to the media player111when returning the initial pre-fetch portion of the source file from the file cache115. For example, the network fetcher117may continue a stream that was previously waited to retrieve the additional source file data311on the stream for return313A to the source multiplexer113A. In turn, the source multiplexer113A may return the additional source file data313B to the media player111to continue video playback. The source multiplexer113A detects when the media player111has consumed the pre-fetch portion305B of source file data delivered from the file cache115and switches to the source file data313A received from the network fetcher117to provide seamless delivery of source file data313B to the media player111.

In ABR cases, a network monitor140may monitor the network conditions by measuring network throughput315associated with the retrieval311/return313A of source file segments by the network fetcher117. In turn, the network monitor140may specify a higher/lower bitrate317for the media player111in one or more future segments requested by the network fetcher117.

FIG. 3Bshows an example of delivering a source file with partial video pre-fetching at an example origin server, e.g., origin server170. The network hander151receives requests for source files and passes the requests to the source multiplexer113B. When the source multiplexer113B receives a request for a source file351, the source multiplexer113B determines whether the request can be serviced by the cache source155based on the parameters of the request (e.g., bitrate, format, etc.). For example, the source multiplexer113B requests353a version of the source file from the cache source155having the parameters specified in the request. The cache source155may respond in different ways depending on the data stored in the cache database160for the requested source file. For example, the cache database160may contain a version of the source file with matching (or closely matching) parameters, only a pre-fetch portion of the source file with matching (or closely matching) parameters, or no match.

In the first two example cases, the cache source155returns355A source file data which will satisfy video pre-fetch operations at a user device110. For example, if the cache source155can service the request for the source file with a version of the source file in the cache160, data from the version of the source file or segment thereof is returned from the cache database160. If the cache source155can only service the request for the source file with a pre-fetch portion of the source file, the pre-fetch portion is returned from the cache database160. In the third example case (not shown), the source multiplexer113B requests transcoding of the source file to retrieve a pre-fetch portion of the source file matching the parameters specified in the request. The transcoder fetches source file data381from the cache database160to output transcoded source file data. The transcoder may store transcoded source file data383for the pre-fetch in the cache database160such that the cache source155may serve future requests. In each instance, the source multiplexer113B returns355B source file data sufficient for the pre-fetch operations to the request handler151for delivery to the user device.

The request handler151may pass a subsequent request377for source file data to the source multiplexer113B. For example, the subsequent request377for the source file may result from a request for an additional segment in ABR playback or the user device continuing a stream to retrieve additional source file data. As with request351, the source multiplexer113B determines whether the request377for additional source file data can be serviced by the cache source155. Specifically, the source multiplexer113B requests whether a version of the source file with matching parameters exists in the cache database160. In ABR

In non ABR cases, the parameters remain unchanged from the initial request351. Accordingly, the source multiplexer113B requests continued delivery from the cache source155if data from a version of the source file was returned initially or continued delivery from the transcoder150if no match was returned initially to provide387source file data to the request handler151for streaming to the user device. If only a pre-fetch was returned from the cache source155, the source multiplexer133B requests379transcoding of the source file to generate a transcoded version of the source file with parameters matching the pre-fetch. The transcoder fetches source file data381from the cache database160to output transcoded source file data385. In turn, the source multiplexer113B switches to the transcoder150to provide source file data387to the request handler151. The transcoder may store transcoded source file data383in the cache database160such that a transcoded version of the source file with the specified parameters exists in the cache database.

In ABR playback cases, the source multiplexer113B performs operations similar to those in the non-ABR case to identify whether the cache source155can satisfy the request for a segment from a version of the source file or whether the transcoder150should be called to transcode a segment of the source file. However, as a bitrate specified in a request for a next segment may change from the previous segment, the source multiplexer113B may switch between the cache source155and transcoder150on a per-segment basis to provide segments of source file data387to the request handler151with parameters matching those specified in received requests.

Additional Configuration Considerations

The disclosed configurations beneficially allow optimized partial pre-fetching of source files such as video files to be quickly retrieved at user devices for playback and optimized streaming of remaining portions of the source files when necessary. In conventional systems, source file are delivered wholly, and oft without any optimization, both of which are an inefficient use of limited network bandwidth and/or optimization compute availability, when a pre-fetching of a portion of the source file would suffice. By providing pre-fetch of source files, in conjunction with optimization, user satisfaction can be improved on mobile devices while maintaining the beneficial user experience of timely source file consumption without the associated negatives of inordinate bandwidth consumption and use of user data allowance for portions of source files the user may never consume.

Certain embodiments are described herein as functional logic blocs, for example, the components of the user device110and server170inFIG. 1. These functional logic blocks also may be referenced as modules or mechanisms. These modules may constitute either software modules (e.g., code embodied on a machine-readable medium), as was noted previously, or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, user device (or client) or server) or one or more hardware modules of a computer system (e.g., a processor or a group of processors202) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

The various operations of example methods (e.g., as described withFIGS. 3A-B) described herein may be performed, at least partially, by one or more processors (e.g., processor202) that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.