Hypertext transfer protocol live streaming

Illustrative embodiments disclose receiving a command to play a selected audio visual media on a client device. The client device determines portions of audio visual media from elected audio visual media and a sequence identifying each portion of the portions in a particular order for playing the portions. The portions and the sequence are determined according to a policy for playing each portion on the client device. The client device retrieves the portions to play in sequence and plays at least a partially retrieved first portion of the portions of the selected audio visual media on the client device. The first portion is identified based on the particular order in the sequence.

BACKGROUND

The disclosure relates generally to an improved data processing system, and in particular, to streaming media. Still more particularly, the present disclosure relates to a method and apparatus for streaming media on client computer systems.

2. Description of the Related Art

In a progressive Hypertext Transfer Protocol (HTTP) download for a media file, an HTTP server first transmits information for the file followed by the media file data itself. A client stores the data in a file as the file is received, just like any other download. A media player knows how to play the stored media from the transmitted file data.

Progressive downloading is being currently replaced by Hypertext Transfer Protocol Live Streaming (HTTP-LS). In Hypertext Transfer Protocol Live Streaming, a media file is duplicated as a partitioned file divided into equal chunks stored in a separate file. To play a media file, a client device first retrieves a list of the stored chunks making up the media itself. The client player then retrieves the chunks. Pre-partitioning the media file into chunks creates a considerable burden for the server as it partitions the file into chunks and stores the chunks in a memory location, and the server must maintain both a partitioned and un-partitioned copy in memory.

Servers, such as server computer systems and server software systems that can hold state for client and server communication sessions are more expensive than servers that are stateless. Stateless servers can be more easily distributed allowing for better performance and lower costs. Thus, client and server media download sessions that use state in a server to manage the client and server media download sessions require more server processing power that is desired. Further, a client device may be used to identify information for the client device that the server does not have. This information may include a location of the client device and a client device user's orders or commands. It may be expensive to send this information from the client device to the server device. Also, the server would have to have even more state in order to remember this additional client information.

Client devices that are mobile have performance and technical issues when attempting to download large amounts of data needed to retrieve audio video media. For example, it may be impossible for mobile clients to download an entire file through one cell tower or even through one cell phone provider. Also, the server and the network used to transfer the file from the server to the client device may have problems causing a failure or unacceptable delay in transfer of the file to the client device.

Therefore, it would be advantageous to have a method and apparatus that takes into account at least some of the issues discussed above, as well as possibly other issues.

SUMMARY

Illustrative embodiments disclose receiving a command to play a selected audio visual media on a client device. The client device determines portions of audio visual media from elected audio visual media and a sequence identifying each portion of the portions in a particular order for playing the portions. The portions and the sequence are determined according to a policy for playing each portion on the client device. The client device retrieves the portions to play in sequence and plays at least a partially retrieved first portion of the portions of the selected audio visual media on the client device. The first portion is identified based on the particular order in the sequence.

DETAILED DESCRIPTION

Turning now toFIG. 1, an illustration of a basic mobile communication system is depicted in accordance with an illustrative embodiment. It should be appreciated thatFIG. 1is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the system in which different embodiments may be implemented. Many modifications to the depicted system may be made.

As depicted, mobile communication system100depends on router105to route messages to their intended addresses. Cell site110communicates with user devices in its coverage area using transceiver115. Cell site120communicates with user devices in its coverage area using transceiver125. Cell site130communicates with user devices in its coverage area using transceiver135. Cell site140communicates with user devices in its coverage area using transceiver145. In these illustrative examples, user150uses a user device comprising mobile communication device155, such as, for example, a mobile client device, with wireless link157to communicate with transceiver145. As depicted, movement vector160depicts movement of user150and communication device155from cell site140to cell site130. In these illustrative examples, as user150and communication device155moves from cell site140to cell site130, communications using wireless link157must be switched, or a hand off performed, from transceiver145to135. This involves updating location data and routing information on the communication device155and intervening routers, such as router105, and any other communication node involved with communicating with communication device155, so that router105or other nodes correctly delivers message packets or generates correctly addressed message packets to mobile communication device155using a subsequent wireless link (not shown). Hand off can also require registration and authentication on the new cell site. Often, message packets can be dropped and data lost during hand off.

In these illustrative examples, each transceiver115,125,135, and145can be associated with a different server managing communications on the respective cell sites110,120,130, and140. As depicted, router105routes communications between communication network170, cell site110, cell site120, cell site130, and cell site140. Communication network170facilitates communication from media devices such as camera device175to media server180. In these illustrative examples, media server180receives media, such as live streaming video from camera device175, and processes and stores the data for distribution, which is then transmitted to the user150on communication device155. Media server180can also store media in files for transmission to communication device155upon request by user150.

As used herein, “client device” or “client” refers to any device configured to play media data, such as streaming multimedia. A client may be, for example, a computer, a laptop computer, a mobile phone, a set top box, a gaming console, a tablet computer, and other suitable types of communication devices. “Server” as used herein, generally refers to any device, more specifically, a hardware computer server used to manage network resources, including media database, file storage, distribution, and communication. However, more generally, server can refer to a computer program running to serve the needs or requests of other programs running on the same or different computer, a physical computer dedicated to serve the needs of programs running on other computers on the same network, or a combination of a software and hardware system running on a dedicated computer or distributed among a plurality of computers. There are many possible types of servers dependant on the task the servers is configured to perform.

As used herein, “media” is defined as audio, visual/video, or a combination of the two, data transmitted over a computer system to communicate information. “Multimedia” is sometimes defined in the art as the use of computers to present text, graphics, audio, video, and animation in an integrated way. “Media” as used herein, generically includes multimedia and includes, for example, generated game animation, recorded sound, recorded movies, and recorded television programming, live concerts, live sporting events, live news broadcast, or other live, recorded, or generated audio video data. Thus, media includes any type of audio data, video data, audio video data, picture data, and this media data may also include streamed data, such as live media being streamed from a media device to a computer system for further routing to user devices, such as clients, which are receiving data for playback on the user devices, recorded media streamed from a media server or other data storage device to a computer system for further routing to user devices for playback, or generated media such as game animation video and audio data streamed from a server or other computer device to a computer system for further routing to user devices for use or playback.

FIG. 2depicts an illustrative block diagram of a streaming media system in accordance with an illustrative embodiment. It should be appreciated thatFIG. 2is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the architecture in which different embodiments may be implemented. Many modifications to the depicted architecture may be made. As depicted, streaming media architecture200includes communication environment205. Computer network210includes server211. Server211can comprise a network computer server configured to support distributing streaming audio visual media such as a hypertext transport protocol server or hypertext transport protocol live streaming server. Server211may be implemented using software, hardware, or a combination of the two.

In these illustrative examples, server211configuration can include cache212storing metadata213for media available from server211. Metadata213can comprise, for example, live media indicator, name for the media, memory locations storing parts of media, policy data such as digital rights management information that can limit use of media or set rules236, duration of access to media, frame width, frame height, frame rate video was recorded with, and encoding standard.

In these illustrative examples, server211does not store state information for each request. In these illustrative examples, server211responds to each request individually. For example, a first request is processed from server211as an independent request unrelated to any previous request. In these illustrative examples, a stateless protocol used for communications with server211does not require server211to store session or status information regarding the communications. For example, each communication with server211may consist of independent pairs of requests and responses. As depicted, stateless request handler214handles the request for a portion of media216.

In these illustrative examples, media encoder215can processes media216to produce media in a desired format for transmission and storage on the server. For example, media encoder215may retrieve media216for converting media216into the desired format for transmission to particular client devices. The conversion may also include compressing media216. In these illustrative examples, media encoder215encodes media216. For example, media encoder may generate encoded media, such as encoded media file217, in a desired encoding. Current video media encoding standards, for example, include the Moving Picture Experts Group (MPEG) encoding standards. These encoding standards include encoding and compression of audio visual data for streaming media over networks and distribution on physical media, for voice communications on a telephone or videophone, for broadcast television applications, and for other media applications.

As depicted, media encoder215may also implement a codec for converting media216into a particular encoding for transmission and storage in the form of encoded media. The codec can further be used to emphasize and better resolve motion, color, surface texture, and sound. Media processor218processes encoded media, such as encoded media file217generated by the media encoder215in response to a request to transmit portion219. In these illustrative examples, media processor218can comprise a program module or sub-program, such as a Java applet and/or servlet running on server211.

In these illustrative examples, media processor218can also comprise a software module operating on the server211and any other combination of software and/or hardware on server211that is configured to generate portion219. As depicted, portion219has media name220, begin location221, and end location222. In these illustrative examples, media name220is an identifier for media file217for a portion of media file217. Begin location221and end location222represent a first location and a second location that determine the start of the portion and the end of the portion in media file217in these illustrative examples.

In these illustrative examples, stream handler223manages streaming portion219of encoded media file217over communication network224to client225from server211. The depiction of server211is not meant to limit where the components of server211may be implemented. In other illustrative examples, the components of server211may be distributed and located on other servers. For example, stream handler223can be distributed among multiple servers such as server211in computer network219along with stateless request handler214. Because stateless request handler214operates stateless, client device requests may easily be distributed among a plurality of servers without a requirement to synchronize state for client device requests, thus improving server response time to handle each client device request.

In these illustrative examples, client225includes portion request module226for generating portion request227for portion219. List generator module228generates list of portions229. As depicted, play sequence230sets forth the order for playing each portion, such as portion219, of the list of portions229. In these illustrative examples, portion request module may use buffer231and other storage to store portions such as portion219for later use.

In these illustrative examples, play sequence230can be used by client225to control the location used in buffer231for each portion stored in buffer231. For example, client225may use play sequence230to store each portion in the order for playing each portion. Also, as depicted, client225may store the portions in buffer231in the order received and then use play sequence230to retrieve the portions in the order for playing each portion. In these illustrative examples, client225uses user interface232to input commands to client225. For example, a user may enter a command to play media216into user interface232.

In these illustrative examples, state manager233in client225stores state information to facilitate transmitting media216and support downloading and streaming of encoded media file217from server211. In these illustrative examples, client225is “statefull” keeping track of the state of interactions between client225and server211with values set in a storage field maintained by state manager233. Sever211can comprise a hardware, software, or a combination of both hardware and software. Commonly, server211comprises a dedicated computer configured as a media server for providing media services over a communication network to store and distribute encoded media217.

State information maintained by client225by the state manager233can include communication session information such as, for example, application layer data, session layer data, transport layer data, authentication data, server management data, configuration settings data, transaction data, or any other data for the next session. For example, application layer data can include the protocol and method used in an Internet Protocol (IP) network communication, session layer information can include requests and responses between applications that occur in the background, and transport layer information can include connection-oriented data stream support, reliability, flow control, and multiplexing data. In these illustrative examples, state manager233stores and manages the state information required for communication between client225and server211, while server211, and any other server supporting the communication, remains stateless.

In these illustrative examples, server211lacks “state” and thus comprises a “stateless” server. Each interaction between server211and client225occurs independently without knowledge or reference to any earlier transaction by server211. Server211comprises a “stateless server” using a “stateless protocol” for communications treating each request and answer in a communication session as an independent transaction unrelated to any previous communication so that the communication consists of independent pairs of requests and responses. In these illustrative examples, server211does not retain session information or status about client225or the communication with client225; client225retains the session information and thus is statefull.

In these illustrative examples, performance monitor234operating on client225monitors performance metrics relating to the communication between the client225and the server211. For example, signal strength metrics, signal quality metrics, bit rate metrics, coding standard metrics, portion219size metrics, available bandwidth metrics, bandwidth used metrics, memory storage utilization metrics, and memory storage available metrics are possible metrics monitored by performance monitor234. Signal quality metrics can also include resolution and quality of the video picture received.

In these illustrative examples, communication environment monitor238provides additional performance metrics to performance monitor234. For example, communication environment monitor238may provide signal strength metrics, signal quality metrics, data traffic metrics, cell location metrics, client movement speed metrics, and client movement vector metrics. As depicted, state manager233can track the metrics of performance monitor234and communication environment monitor238for use by client225. In these illustrative examples, client225can respond to changes in the performance metrics monitored by performance monitor234. For example, client225can responds to a change in signal strength and signal quality monitored and measured by performance monitor234and communication environment monitor238to modify the size and video resolution, quality of media, encoding standard, or some other adjustment to portion request227to address the specific metric change. As depicted, in generating portion request227, portion request module226uses metadata213, preferences235, rules236, policies250, and metrics from performance monitor234and communication environment monitor238. Within the confines of these sometimes-conflicting inputs and requirements, portion request module226manages and adjusts portion request227to generate portion219for viewing on client225.

In these illustrative examples, as changes become necessary to modify portion request227, in some embodiments, the client225can transmit a cancel command to stop generating one or more portion219, and the client225can generate a new portion request227incorporating adjustments as required to address metadata213, preferences235, rules236, policies250, and metrics from performance monitor234and communication environment monitor238. For example, if four portion request227remain pending with no corresponding portion219received, in response to one or more metric changes client225can transmit a cancel command to stop server211from processing one or more of the portion request227.

As depicted, client225can generate four modified portion request227addressing the metric changes. The ability to stop generation of prior portion request227can be dependant on a parameter, such as for example the number of pending portion request227, a threshold size of portion219, or a threshold for latency between receiving portion request227and generating corresponding portion219. Threshold for latency refers to a minimum specified amount of time for the message packet containing the portion to travel from server211to client225. However, in other embodiments, the server211may be retrieving portion219so fast based on portion request227that insufficient latency exist to cancel a pending portion request227, and client225simply must modify portion request227on-the-fly with the older portion request227generating portion219without modification. In these illustrative examples, client225request portion219on-the-fly with minimal memory storage of pending portion request227in a queue.

In these illustrative examples, preferences235is a list of preferences of the preferred communication environment of client225, such as for example a display size, a buffer size, a bit rate, a signal quality, a video resolution, a sound resolution, a closed caption enablement, and any other suitable preference for a media device such as client225. As depicted, rules236are restrictions that apply to media216. For example, rules236may include a plurality set of portions available to client225, list of portion permitted to store on client225, number of bytes permitted to store on client225, limit the number of bytes permitted to download, limit the size of portion219, limits on portion219storable on client225, media access by client225, and concurrent download authorization for client225. For example, client225may be configured to block particular media, to limit a total number or total size of media data downloads over a particular period of time, to restrict editing of content from a particular media stream, to block live media, and to permit audio media downloads only.

As illustrated, rules236can be set on the client225, such as by a parent user for a child user of client225. For example, a user may configure client225to block certain media216. In other illustrative examples, rules236can also be set by data in or associated with portion219, such as in response to received digital rights management251data in portion219, client225plays portion219with a specified restricted resolution and required bit rate. In another example, preferences235can specify the desired encoding format, MPEG-2 versus MPEG-4 as one example. Preferences235also may include a preferred or optimal buffer size, video resolution, and closed captioning enabled. Moreover, since the server is stateless and only the client is statefull, each portion219can reflect different preferences235or rules236. For example, client225changes portion request227to alter subsequent portion219in the media stream to enhance closed captioning data and delete audio data from the stream, restrict future content of the stream to edit out certain ones of portion219, as for example switching from a parent user to a child user, or to permitting certain ones of portion219to play, as for example switching from a child user to a parent user.

In these illustrative examples, state manager233along with preferences235and rules236manage portion219. For example, state manager233may be set according to preferences235to control or specify display size, bit rate, and signal quality of transmission, or streaming, of portion219. State manager233, as another example, may be set according to rules236to limit the numbers of bytes downloaded, size of buffer, and size of portion219. As depicted, portion219, on the other hand, may include information to edit, permanently or temporarily, or set preferences235or rules236. In these illustrative examples, alternatively preferences235and rules236may manage portion219independent of state manager233to control playing of portion219and function of client225.

In these illustrative examples, client225includes client display237for playing video media. In other examples, client225may lack a suitable client display237and thus limited to audio media. As depicted, client225may also include a communication environment monitor238to monitor various metrics relating to the communication system and environment.

As depicted, media environment239provides content240to server211including media216. In these illustrative examples, content240comprises data from media source241to transmit to server211. As depicted, media source241can comprise live media242with audio243and video244components. In these illustrative examples, media source, for example media source241, can comprise vendor245, subscriber service246, media web host247, previously recorded248, and pay per view service249. As depicted, live media242provides media216from a real-time transmission. That is, digital movie cameras and audio devices capture a live event to generate live media242and stream the data in real time to server211. In these illustrative examples, vendor245can include selling media216for a one-time, limited time frame viewing, or even recording/storing media216. Subscriber service246can include selling media216, which can include live or stored media216. Media web host247can include live or stored recorded media216for free viewing. In these illustrative examples, media web host247may provide media216such as, for example, delayed television network programming. For example, previously recorded248can comprise free service with unlimited downloads of media216, and pay per view service249can comprise pay per view service with charges for a single viewing or viewing within a specified time frame.

In these illustrative examples, content240from media source241may also provide live performance data generated by audio video recording devices as live media242or media216previously recorded and stored on a server. As depicted, vendor245, subscriber service246, media web host247, and pay per view service249can all provide live performance data. In these illustrative examples, associated with each media source, such as media source241, and content240are policies250for managing content240. For example, digital rights management251in policies250may limit the use of content240by particular devices to only those usages desired by media source241or the owners of intellectual property rights in content240. In these illustrative examples, various policies250can also, for example, limit the viewable portion of content240, limit number of bytes of content240storable, limit number of downloadable content240, limit number of viewings of content240a restrictive date range for access to content, limit the quality of content240in a stream for free viewing, and block copying of content240.

As depicted, digital rights management251in policies250limits usage of content240to only those uses authorized by the intellectual property owner. In these illustrative examples, digital rights management251can, for example, limit the amount of data that can be downloaded by client225, limit a number of times content240can be accessed, limit which portion219of the audio video media can be played by the client225, mandate a minimum quality for download, limit encoding for download, and block conversion to other formats of content240. In these illustrative examples, digital rights management251can include and implement restrictive licensing agreements governing the access to the content240, as well as copyright and public domain controls. In these illustrative examples, digital rights management251can impose restrictive licenses as a condition of entering a website to access a media source241or before downloading content240. In these illustrative examples, digital rights management251can also include encryption protocols scrambling content absent the proper encryption keys to decode content240.

In these illustrative examples, client225can use policies250to set rules236on client225. In some illustrative examples, policies250associated with media216can be transmitted to client225to configure rules236before creating portion request227, such as, for example, configuring client225upon initial registration with subscriber service246based on a chosen service plan. Other illustrative examples may embed polices250into the data packet stream used to transmit potion219to client225to set or change rules236. In these illustrative examples, some policies250can, alternatively as one example, cause server225to limit the number of bytes in generating portion219and enact a restrictive time frame controlling when content240can be accessed.

As depicted, client225can access policies250using server211by contacting media environment239, or client225can access policies directly on media environment239without using sever211. In another example, server211can access policies250upon receipt of a request for media216available on server211, upon receipt of portion request227, or upon receipt of content240. As depicted, server211, in some illustrative embodiments, can store policies250, and in some illustrative embodiments client225can store policies250. As depicted, client225uses policies250, preferences235, rules236, metadata213, and metrics from performance monitor234and communication environment monitor238to generate portion request227.

With reference toFIG. 3, an illustrative diagram of a communication environment monitor is depicted in accordance with an illustrative embodiment. It should be appreciated thatFIG. 3is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the architecture in which different embodiments may be implemented. Many modifications to the depicted architecture may be made.

As depicted, communication environment monitor300can be implemented on client225ofFIG. 2as communication environment monitor238, and it can include locator305operating in conjunction with route identifier310. In these illustrative examples, client225ofFIG. 2can store information regarding its communication environment, such as data on cell 1315, cell 2320, cell 3325, and cell 4330. As depicted, route identifier310can determine data relating to movement vector350and signal strength indicating impending movement from cell 3325to cell 2320. In these illustrative examples, client225ofFIG. 2can dynamically respond to the hand off to another transceiver by increasing the size or otherwise adjusting portion219, considering policies250, preferences235, rules236, metadata213, and metrics from performance monitor234and communication environment monitor238ofFIG. 2. In these illustrative examples, increasing the size of the portion219avoids disruption of the streaming media216from buffer latency that can interfere with playing media216during a hand off. Buffer latency can occur during a hand off, when data is buffered in a memory associated a server on the cell site while a mobile communication device completes registration and authentication onto a new cell site. If registration and authentication takes to long, the buffer empties interrupting play. By requesting a larger portion219, the client225can buffer one or more larger portion219to play un-interrupted during hand off.

As depicted, client225can generate portion219considering, as an example, policies250limiting the size of portion219and encoding format, preferences235relating to display size and resolution, rule236blocking access to portions of content240, and metadata213giving encoded format available, size of encoded media217, and indicator that encoded media217is not live. In these illustrative examples, client225maintains state information, and thus is statefull, while server211remains stateless. Because only client225participates in the entire streaming or downloading of media216, compared to servers managing communication at each cell site, e.g., referring toFIG. 1cell sites110,120,130, and140, only client225can preserve and use state data for requesting and transmitting portion219.

With reference now toFIG. 4, an illustration of a streaming media architecture is depicted in accordance with an illustrative embodiment. It should be appreciated thatFIG. 4is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the architecture in which different embodiments may be implemented. Many modifications to the depicted architecture may be made.

As depicted, streaming media architecture400is a network of computers in which the illustrative embodiments may be implemented. Client405connects with wireless communication network415, such as, for example, mobile communication system100and the cellular network inFIG. 1. Client405, in one illustrative example, can comprise a wireless communication device implemented using a processor configured to execute computer code. More typically, client405comprises a smartphone device configured and capable of playing streaming media. A “smartphone” as defined herein, means a high-end mobile cell phone combining functions of a personal digital assistant (PDA), also referred to as a palmtop computer, and a mobile cellular telephone, with a processor and memory configured to execute program code and process data. Smartphones can usually operate as portable media players using a high-resolution touchscreen with a web browser that can access and properly display standard web pages. Smartphones also typically possess more advanced computing ability and connectivity than more conventional cellular phones, although the distinction can be vague and there is no official definition for what constitutes the difference between them. Current popular cellular phones that meet the definition of a smartphone, as example embodiments and not as a limitation, include Apple's® iPhone®, LG's® Revolution®, Motorola's® Droid X2® Nokia's® Sybian®, Research in Motion's® (RIM®) BlackBerry® Torch®, and Samsung's® Galaxy® or Droid Pro®.

As depicted, communication network415also connects to server420. Server420can function as a web server, media server, hypertext transport protocol (HTTP) server, hypertext transport protocol live streaming (HTTP-LS) server, or some other server supporting media streaming. As depicted, communication network415also connects to media source425, which can comprise a plurality of media sources such as, with reference toFIG. 2, by example only and not as a limitation, content240that can include live media242, vendor245, subscriber service246, media web host247, previously recorded248, or pay per view service249. In these illustrative examples, communication network415supports communication between client405, server420, and media source425using both surface and wireless communication links. Surface communication links can be comprised of wire cable or fiber optic cable links, such a cellular system depicted inFIG. 1. In these illustrative examples, media216inFIG. 2furnished client405can be stored in its entirety on server420, or server420can facilitate transmitting streaming media from media source425to client405.

As depicted, client405receives metadata430from server420on media available from server420. In these illustrative examples, metadata430can comprise information on media files that can include, for example, a name for the media file, byte length of the media file, memory locations where the media file is stored, live media indicator, policy data such as digital rights management information251ofFIG. 2that can place limits on generation of portion219or set rules236, duration of access to the encoded media file217, frame width, frame height, frame rate video was recorded with, and encoding standard. In these illustrative examples, list generator module435uses metadata430along with policies250, preferences235, rules236, and metrics from performance monitor234and communication environment monitor238to generate list of portions229and play sequence230ofFIG. 2. In these illustrative examples, user interface440allows a user of client405to select an encoded media file217ofFIG. 2for playing on client405. In these illustrative examples, portion request module445receives selection input from user interface440to generate portion request227ofFIG. 2, also using policies250, preferences234, rules236, metadata430, and metrics from performance monitor234and communication environment monitor238to generate portion request227. As depicted, list generator module435generates list of portions229responsive to inputs from communication performance monitor234or communication environment monitor238as well as considering policies250, preferences235, rules236, metadata430, and data stored by state manager233ofFIG. 2, in conjunction with portion request module445, to adjust the portion request227ofFIG. 2and compensate for changes in the communication performance or environment.

In these illustrative examples, server420receives media data as media216ofFIG. 2from a media source425over communication network415that media encoder450processes to produce encoded media file217ofFIG. 2. In these illustrative examples, media encoder450also generates in part the metadata430to describe encoded media file217ofFIG. 2. For example, metadata430can contain data providing a starting byte location and ending byte location that can comprise a byte length of the encoded media file217as well as memory addresses storing the bytes on server420. In these illustrative examples, metadata430can also comprise data provided by media source425and media encoder450. In these illustrative examples, portion request module445transmits output, i.e., a portion request460, over communication network415to server420. As depicted, media processor455processes portion request460outputted by portion request module445to retrieve portion457identified by portion request module445in portion request460. In these illustrative examples, media processor455copies the portion of identified encoded media file217ofFIG. 2specified by a byte begin location221and a byte end location222ofFIG. 2. The byte begin location221and end location222ofFIG. 2can comprise memory addresses, byte length designations, timestamp data, a combination, or some other method to designate and identify the beginning and ending of a segment of stored encoded media file217. In these illustrative examples, media processor455copies the parts of encoded media file217specified in the portion request460to configure and generate portion457. As depicted, encoded media file217remains intact and un-partitioned. In these illustrative examples, media processor455then provides portion457to client405using stream handler223ofFIG. 2. The received portion457can then be buffered in memory and played on client display465, which can comprise a screen and speaker.

With reference now toFIG. 5, an illustration of a flowchart for a client media process is depicted in accordance with an illustrative embodiment. The client media process500is an illustrative example of the implementation on a client to play streaming media referring to client405inFIG. 4. It should be appreciated thatFIG. 5is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the process in which different embodiments may be implemented. Many modifications to the depicted process may be made.

As depicted, the process initiates at step505with a request for information on available media from server420. In these illustrative examples, this request, for example, can occur based on results from a web browser search, media advertisement, or web link connection. The request can further comprise a general request giving results for a plurality of media files such as all movies, or a specific request for a single media file such as for a specific identified movie, or a less restrictive request for a limited number of files, such as media files related to a particular movie genre. A general listing of a plurality of media files or a single media file may result from an initial request.

As depicted, in response to the request, client405can receive metadata430with information on an available, encoded media file (step510). In these illustrative examples, metadata430ofFIG. 4received can include, for example, the name for the media file, a byte length, memory location, live media indicator, policy data, digital rights management information, and encoding standard. Metadata430can also, in an illustrative example, cover a plurality of media files. In these illustrative examples, metadata430can also contain policies250for use or to configure rules236and preferences235ofFIG. 2on client405.

From the received metadata430and other inputs such as, for example, policies250, preferences235, rules236, and state manager233ofFIG. 2, client405can generate a list of portions229on list generator module435for breaking down encoded media file217into encoded media file portions (step515). In these illustrative examples, for live media, the length of encoded media file217ofFIG. 2remains unknown, as only a small number of bytes of the total length of bytes in the file may have been generated. In these illustrative examples, client405, and more particularly, list generator module435ofFIG. 4, assigns a pre-determined length to generate the final portion457from the available bytes on the server420based on a probable length for that particular portion218.

In these illustrative examples, a plurality of encoded portion457can be arranged in play sequence230and may be adjusted based on metrics monitored by communication performance monitor234or communication environment monitor238ofFIG. 2. For example, when the communication link between client405and server420is exceptionally good, client405can selectively increase the size of portion457requested to minimize protocol chatter and help to reduce latency and bandwidth usage ofFIG. 4. If client405movement places it on the edge of cell site coverage, client405can also increase the size of portion457requested ofFIG. 4, minimizing the probability of play disruption or lost message packets.

As depicted, once list generator module435generates list of portions229ofFIG. 2, a user may be able to select either a portion of the media file to play or the entire media file to play. In these illustrative examples, client405operates to identify at least one portion457ofFIG. 4according to list of portions229ofFIG. 2to retrieve (step520). In these illustrative examples, using list of portions229, client405creates portion request460using portion request module226to request identified portion457of the list of portions229ofFIG. 2(step525). As depicted, portion457requested also correlates to play sequence230.

However, client405can also use list generator module435ofFIG. 4and portion request module226to generate list of portions229ofFIG. 2, play sequence230, and portion request460to implement fast forward, reverse, or fast reverse functions. In these illustrative examples, client405can also be used to skip ahead or reverse to selectively play portion457out of sequence either forward or reverse. This gives client405greater flexibility as to how to present the media and the granularity of control provided to the user.

As depicted in step530, client405transmits portion request460to server420corresponding to at least one of identified portion457ofFIG. 4on list of portions229ofFIG. 2. In response, client405receives requested portion457of encoded media file217and stores portion457in buffer231for playing (step540). Buffer231ofFIG. 2can store a plurality of portion457ofFIG. 4to play according to play sequence230. In these illustrative examples, portion457can also contain policies250such as digital rights management251for configuring rules236or preferences235ofFIG. 2on client405and control access to, or otherwise limit, client405usage to only those uses authorized. As depicted, client405, for example, can be configured to limit the viewable portion media, limit number of bytes of media storable on a device, limit number of bytes of media that are downloadable on a device, limit number of viewings on a device, limit a date range for access to media, limit a quality of the media in a stream of media for free viewing, and block copying of the media.

Subsequent to portion457being buffered into a memory, client405plays received portion457in accordance with any policies or rules set on the client (step545). As depicted, client405then clears the played portion457from buffer231(step550).

At step555, client405determines if the end of the media stream making up the complete requested portions of the media file was received, such as may occur for a live event. In these illustrative examples, if client405received the final portion of the media stream making up encoded media file217, the process ends.

If the end of the media stream making up the entire encoded media file217was not received in step555, such as for live streaming, then client405updates the list of portions229ofFIG. 2(step560). In these illustrative examples, this may require re-generating or appending list of portions229to further divide and add the new bytes received and available on the server420. This creates one or more new portion457ofFIG. 4by generating additional identified portions on the list of portions229and adds to play sequence230ofFIG. 2. In these illustrative examples, for a live event, new generated potion457ofFIG. 4should include at least part of the event occurring during the generating, downloading, and playing of previous portion457. As depicted in step565, client405identifies the next portion457of the encoded media file according to identified portions on list of portions229(step565). From step565, the process proceeds to step525.

With reference now toFIG. 6, an illustration of an audio visual media list generated by a client is depicted in accordance with an illustrative embodiment. Audio visual list600, in one illustrative example, can be generated by the client225on the list generator module228and list portions to request portion219from a server211ofFIG. 2. It should be appreciated thatFIG. 6is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the process in which different embodiments may be implemented. Many modifications to the depicted process may be made.

As depicted, audio visual media list600comprises a listing that includes identifier601for a portion. In these illustrative examples, identifier601can be a media file name, such as for example a movie title, an alphanumeric designation, a derivative name based on the name of the media file such as an abbreviated movie title, or some other media file name or alphanumeric designation. Typically, in these illustrative examples, identifier601corresponds to the name of the media file. Sequence number602designates an order for playing the portions and organizing the portions into a play sequence. As depicted, sequence 0002 directly follows sequence 0001 in a play sequence. Alternatively, in these illustrative examples, audio visual media list600can arrange the portions out of sequence for retrieval to play according to play sequence230ofFIG. 2. As depicted, begin603designates the beginning location of the portion and can comprise a memory location storing the beginning byte of the portion, a time stamp associated with each byte of memory representative of elapsed play time to the beginning of the byte or media file, or a byte length designation corresponding to the beginning byte location in the total byte length of the media file. As depicted, end604designates the ending location of the portion and can comprise a memory location storing the ending byte of the portion, a time stamp associated with each byte of memory representative of elapsed play time to the ending of the byte, or a byte length designation corresponding to the ending byte location in total byte length of the media file.

As depicted, portion 1605marks the first portion generated and typically corresponds to the first portion to play in play sequence230ofFIG. 2designating the order of play for the retrieved portions. In these illustrative examples, the identifier for portion 1605is moviel with a sequence number of 0001. As depicted, begin603location of AAAA designates the beginning location of the 0001 sequence in the encoded media file, while end604location BBBB designates the ending location. As depicted, portion 2610marks the second portion generated and typically corresponds to the second portion to play in the play sequence designating the order of play for the retrieved portions. In these illustrative examples, identifier601for portion 2610is moviel with sequence number602of 0002. As depicted, begin603location of CCCC designates the beginning location of the portion 0002 in the encoded media file, while end604location DDDD designates the ending location.

In the illustrative example, portion 3615marks the third portion generated and typically corresponds to the third portion to play in the play sequence designating the order of play for the retrieved portions. In these illustrative examples, identifier601for portion 3615is moviel with sequence number602of 0003. As depicted, begin603location of EEEE designates the beginning location of the portion 0003 in the encoded media file, while end604location FFFF designates the ending location. As depicted, portion (n)620marks the nth portion generated and corresponding to the final portion to play in the play sequence designating the order of play for the retrieved portions. In these illustrative examples, identifier601for portion (n)620is moviel with a sequence number of “####” or the final sequence generated. As depicted, begin603location of YYYY designates the beginning location of the final portion #### in the encoded media file, while end604location ZZZZ designates the ending location. In these illustrative examples, the portions in this example are contiguous portions in encoded media file217ofFIG. 2listed in sequence and played in sequence from beginning location AAAA to ending location ZZZZ. In these illustrative examples, however, alternatively, the AAAA begin603location can designate any point within the encoded media file and not the beginning and can be arranged out of sequence but requested and played in sequence according to sequence player230ofFIG. 2.

With reference now toFIG. 7, an illustration of an audio visual media list generated by a client is depicted in accordance with an illustrative embodiment. Audio visual list for fast reverse700is one illustrative example that can be generated by the client on list generator module228and list portions to request from server211ofFIG. 2. It should be appreciated thatFIG. 7is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the process in which different embodiments may be implemented. Many modifications to the depicted process may be made.

As depicted, audio visual media list for fast reverse700comprises a listing that includes identifier701for a portion. In these illustrative examples, identifier701can be a media file name, such as for example a movie title, an alphanumeric designation, a derivative name based on the name of the media file such as an abbreviated movie tile, or some other media file name or alphanumeric designation. Typically, in these illustrative examples, identifier701corresponds to the name of the media file. As depicted, sequence number702designates an order for playing the portions and organizing the portions into play sequence230ofFIG. 2. As depicted, sequence 0002 directly follows sequence 0001 in a play sequence.

As depicted, begin703designates the beginning location of the portion and can comprise a memory location storing the beginning byte of the portion, a time stamp associated with each byte of memory representative of elapsed play time to the beginning of the byte, or a byte length designation corresponding to the beginning byte location in total byte length. As depicted, end704designates the ending location of the portion and can comprise a memory location storing the ending byte of the portion, a time stamp associated with each byte of memory representative of elapsed play time to the ending of the byte, or a byte length designation corresponding to the ending byte location in total byte length. In these illustrative examples, the media stream implements a fast reverse function as requested by portion request227as listed in list of portions229ofFIG. 2.

In the illustrative example, portion 1705marks the first portion generated and typically corresponds to the first portion to play in play sequence230ofFIG. 2designating the order of play for the retrieved portions. In these illustrative examples, however, play sequence230generated is in reverse order. That is, instead of a normal play sequence beginning at begin603AAAA and progressing forward to end604address ZZZZ as inFIG. 6, the fast forward function begins within a file and advances out of sequence, in this example, in reverse order from NNNN to AAAA, and plays in reverse order. In other words, in these illustrative examples, all bytes play in reverse order compared to normal forward play. In these illustrative examples, identifier701for portion 1705is moviel with sequence number702of 0001. As depicted, begin703location of NNNN designates the beginning location of the 0001 sequence in the encoded media file, while end704location MMMM designates the ending location. In these illustrative examples, however, rather than the beginning of encoded media file217, NNNN designates some other location within the encoded media file217ofFIG. 2.

As depicted, portion 2710marks the second portion generated and typically corresponds to the second portion to play in play sequence230designating the order of play for the retrieved portions. As depicted, identifier701for portion 2710is moviel with sequence number702of 0002. As depicted, the begin703location of JJJJ designates the beginning location of portion 2710in the encoded media file, while end704location IIII designates the ending location. In these illustrative examples, however, sequence number 0002 does not correlate to the next contiguous sequence in encoded media file217but rather correlates to some other earlier sequence in encoded media file217ofFIG. 2. Rather than a progressive, contiguous sequence one after the other in a forward direction, portion 2710, sequence 0002 skips backward to retrieve a non-contiguous portion in reverse.

In the illustrative example, portion 3715marks the third portion generated and typically corresponds to the third portion to play in the play sequence designating the order of play for the retrieved portions. As depicted, identifier701for portion 3715is moviel with sequence number702of 0003. As depicted, begin703location of FFFF designates the beginning location of the portion 0003 in the encoded media file, while end704location EEEE designates the ending location. As depicted, portion (n)720marks the nth portion generated and corresponds to the final portion to play in the play sequence designating the order of play for the retrieved portions to implement fast reverse. As depicted, identifier701for portion n720is moviel with sequence number702of “####” or the last sequence generated. As depicted, begin703location of BBBB designates the beginning location of the final portion #### in the encoded media file, while AAAA designates end704location and, in this example, the beginning of encoded media file217ofFIG. 2. In a similar manner, a fast forward operation can be played by requesting non-contiguous portions. Similar toFIG. 6in these illustrative examples, a reverse function can be implemented by reversing the order of the portions requested and playing in contiguous order.

InFIG. 8, an illustration of a streaming media data structure is depicted in accordance with an illustrative embodiment. Streaming media data structure800is one illustrative example data structure of an embodiment on client405ofFIG. 4of data elements used by client405used to request portion457and includes audio visual media name805generally corresponding to the name of the encoded media file. It should be appreciated thatFIG. 8is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the process in which different embodiments may be implemented. Many modifications to the depicted data structure may be made.

In these illustrative examples, audio visual media list810generally comprises the same data ofFIG. 6for a portion, which can include a portion identifier in the list of portions and a begin location and an end location for the portion. In these illustrative examples, audio visual media list810generally also comprises the play sequence for the portion, but play sequence230ofFIG. 2can control the sequence in which portion457plays, actually playing the portions out of the listed sequence.

As depicted, total byte length of media file820can be useful for live media. The server can use this total byte length to help determine if the media comprises live media, as this value will not equal the total byte length stored on server420ofFIG. 4. In these illustrative examples, a mismatched value for total byte length between server420and of client405ofFIG. 4can indicate media is live media. For recorded media content, the value of total byte length for server425and client405matches. However, for live media, the total byte length does not match, at least not till the live event ends. Live media can be indicated by this means or in metadata213ofFIG. 2, but this means can alternative or also be used to indicate the end of live media.

Client405receives an indicator that live media has ended from server420in the illustrative examples. For example, client405can make a portion request460having a begin indication and end indication for portion request460, with server420calculating the end of portion request460extending beyond the end of the media. In these illustrative examples, because server420recognizes the media as live media, server420continues sending the portion as it arrives from media source425and as requested by client405. But, unless client405receives an indication that the live media ended, the client continues making media request. In these illustrative examples, if the total byte length of media file820on client405ofFIG. 4matches the total byte length of media file on server420, server420can indicate an end of the media stream in the next transmitted portion457, and client405can terminate the session.

As depicted, type825can designate a requested or preferred file encoding standard for audio visual, audio or visual only, live event, or pre-recorded and stored. In these illustrative examples, type825can specify the coding standard, such as the audio standard, which include for example G.711, G.723, G.726, G.729, GSM, QCELP, MP3, and DTMF, or the video standard such as H.261, H.263, H.264, MPEG-1, MPEG-2, and MPEG-4.

In these illustrative examples, type825can also indicate whether the media requested comprises multimedia, interactive video game, personal communication, multimedia email, video surveillance, emergency system messaging, or broadcasting media stream. As depicted, server420can use this information contained in a portion request460to generate the portion457with the correct coding standard optimized for the specified media.

In these illustrative examples, policies830can designate the policies applicable to encoded portion457ofFIG. 4such as, for example, digital rights management, preferences, codec standard, minimum bandwidth requested to stream portion457, requested bit rate to stream and play portion457, minimum preferred signal quality standard for portion457, encoded frame rate, frame size, encryption standard for securing the stream transmission of portion457, data storage limitation on client405, and maximum byte size supported by client405. In these illustrative examples, these policies830enable client405to request portion457on-on-the-fly from server420, adapting to changes detected by client405ofFIG. 4during a communication session.

In these illustrative examples, status835can indicate, for example, an impending change in file transmission quality for portion457, congestion problems in the communication environment caused by high traffic or demand, low available bandwidth, service interruption warning or indicator, low available resources, or service interruption. As depicted, status835can be derived from policies250, preferences235, rules236, and state manager233ofFIG. 2. In these illustrative examples, commands840can include, for example, a teardown command to server420to terminate the communication link and can be used to terminate live streaming of a media event, a pause command can temporarily stop streaming, a record command can request server420send a number of bytes to a memory or the buffer as dictated by policies250, preferences235, or rules236, state manager233, or monitored metrics ofFIG. 2.

In these illustrative examples, policies830, status835, and commands840data can be stored and tracked by state manager233and/or used by client405to provide enhanced flexibility and control over the media stream as the data components are used to generate each portion request460. As depicted, in conjunction with state manager233, client405can control most aspects of the streaming media data, making changes on-the-fly during a single communication session to generate and modify the media packet by modifying the portion request460of the media stream, rather than having static streaming media data during a communication session lacking any client control over the generation of media data packets making up the media stream.

With reference now toFIG. 9, an illustration of a flowchart for a server media process is depicted in accordance with an illustrative embodiment. Server media process900is an illustrative example of the implementation on a server to play streaming media referring to server420inFIG. 4. It should be appreciated thatFIG. 9is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the process in which different embodiments may be implemented. Many modifications to the depicted process may be made.

As depicted, the process begins with server420receiving media input from a media source (step905). In these illustrative examples, server420ofFIG. 4processes media input to generate media216and encodes media216with a media encoder215to produce encoded media file217ofFIG. 2and associated metadata430(step910). In step915, server420receives a request for available media files, and in response server420transmits metadata430ofFIG. 4on available media files (step920).

As depicted, server420can receive portion request460to request part of encoded media file217that includes a begin location and an end location for a portion within the encoded media file217corresponding to a portion457in list of portions229(step925). In these illustrative examples, the begin location and end location can comprise a byte address location address in memory, a byte length, a timestamp associated with the portion, or some other designation protocol to designate a set of bytes for processing. In these illustrative examples, server420processes portion request460ofFIG. 4with media processor218ofFIG. 2to copy and process bytes of the requested portion of the encoded media file starting at the begin location and stopping at the end location (step930), which creates portion457. As depicted, server420determines if portion457is the end of live streaming media (step935). That is, for live media, the client405ofFIG. 4does not know the total size of encoded media file217and list of portions229ofFIG. 2, and play sequence230must be updated to create additional portion request460ofFIG. 4. In these illustrative examples, unless the client405receives an indication that live media ended, client405continues transmitting portion request460after the end of a live event. As depicted, if portion457is the end of live streaming media, then server420appends portion457ofFIG. 4to indicate end of live media streaming (step940) and then proceeds to step945. As depicted, if portion457is not the end of live media in step935, then server420transmits portion457ofFIG. 4of encoded media file217ofFIG. 2corresponding to the portion request460ofFIG. 4(step945).

Turning now toFIG. 10, an illustration of a block diagram of a data processing system is depicted in accordance with an illustrative embodiment. In this illustrative example, data processing system1000includes communications fabric1002, which provides communications between processor unit1004, memory1006, persistent storage1008, communications unit1010, input/output (I/O) unit1012, and display1014.

Memory1006and persistent storage1008are examples of storage devices1016. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Memory1006, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage1008may take various forms, depending on the particular implementation.

For example, persistent storage1008may contain one or more components or devices. For example, persistent storage1008may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage1008also may be removable. For example, a removable hard drive may be used for persistent storage1008.

Communications unit1010, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit1010is a network interface card. Communications unit1010may provide communications through the use of either or both physical and wireless communications links.

Input/output unit1012allows for input and output of data with other devices that may be connected to data processing system1000. For example, input/output unit1012may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, input/output unit1012may send output to a printer. Display1014provides a mechanism to display information to a user.

Instructions for the operating system, applications, and/or programs may be located in storage devices1016, which are in communication with processor unit1004through communications fabric1002. In these illustrative examples, the instructions are in a functional form on persistent storage1008. These instructions may be loaded into memory1006for processing by processor unit1004. The processes of the different embodiments may be performed by processor unit1004using computer implemented instructions, which may be located in a memory, such as memory1006.

Program code1018is located in a functional form on computer readable media1020that is selectively removable and may be loaded onto or transferred to data processing system1000for processing by processor unit1004. Program code1018and computer readable media1020form computer program product1022in these examples. In one example, computer readable media1020may be computer readable storage media1024or computer readable signal media1026. Computer readable storage media1024may include, for example, an optical or magnetic disk that is inserted or placed into a drive or other device that is part of persistent storage1008for transfer onto a storage device, such as a hard drive, that is part of persistent storage1008. Computer readable storage media1024also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory, that is connected to data processing system1000. In some instances, computer readable storage media1024may not be removable from data processing system1000. In these illustrative examples, computer readable storage media1024is a non-transitory computer readable storage medium.

Alternatively, program code1018may be transferred to data processing system1000using computer readable signal media1026. Computer readable signal media1026may be, for example, a propagated data signal containing program code1018. For example, computer readable signal media1026may be an electromagnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communication links, such as wireless communication links, optical fiber cable, coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In some illustrative embodiments, program code1018may be downloaded over a network to persistent storage1008from another device or data processing system through computer readable signal media1026for use within data processing system1000. For instance, program code stored in a computer readable storage medium in a server data processing system may be downloaded over a network from the server to data processing system1000. The data processing system providing program code1018may be a server computer, a client computer, or some other device capable of storing and transmitting program code1018.

In these illustrative examples, program code1018may be program code for managing communications sent to customers. Program code1018may include instructions which, when executed by processor unit1004, manage the communications. For example, program code1018may include functions for calculating a probability of success of sending the communications. In other examples, results from sending communications to customers may be stored in memory1006and/or persistent storage1008. Program code1018may include instructions for analyzing the results. Based on the analysis, data processing system1000may provide recommendations for managing the communications.

In still another illustrative example, processor unit1004may be implemented using a combination of processors found in computers and hardware units. Processor unit1004may have a number of hardware units and a number of processors that are configured to run program code1018. With this depicted example, some of the processes may be implemented in the number of hardware units, while other processes may be implemented in the number of processors.

As another example, a storage device in data processing system1000is any hardware apparatus that may store data. Memory1006, persistent storage1008, and computer readable media1020are examples of storage devices in a tangible form.

As another example, a storage device in data processing system1000is any hardware apparatus that may store data. Memory1006, persistent storage1008, and computer readable media1020are examples of storage devices in a tangible form.

In these illustrative examples, for example, server211ofFIG. 2can comprise multiple computer servers in mobile communication system100implementing components210,211,212,213,214,215,216,217,218, and223. These computers servers211can comprise a data processing system as depicted inFIG. 10. Similarly, as depicted, client225, media environment239, or media source241can comprise a plurality of data processing system1000.

Referring toFIG. 2, advantages of the illustrative example embodiments presented include never actually partitioning media files into portions, or chunks, on server211. This reduces memory overhead, because it is not necessary to maintain both the unmodified file and the partitioned file in memory; effectively halving the memory storage required. An added advantage is that when client225becomes aware of the modification not requiring pre-partitioning, client225can request media portion219on any boundary and of any reasonable length, which is useful when client225performs fast forward or reverse play of the respective encoded media file217. Client225possesses more flexibility in how to present the media and the granularity of the controls on client225.

In addition, when the communication link between client225and server211exhibits exceptional quality, client225can increase requested portion219, size in portion request227to minimize protocol chatter, reduce latency, and consume less bandwidth. When network problems arise, client225can choose to reduce requested portion219size to minimize retransmissions in the event of packet failure.

Choosing not to pre-partition encoded media file217into chunks also improves other facilities in a data network, such as byte and object caching and the need to preprocess media. Pre-partitioning media files into chunks creates artificial string interruptions in a byte cache that limit the length of string matches, diminishing the media file's compressibility. Similarly, for an object cache many file names are replaced by one file names.

Another realized advantage for not pre-partitioning encoded media file217on server211is that the file requires no preprocessing, so an encoded media file217can be retrieved from anywhere on demand without using a local copy. Not pre-processing the media file into chunks means that media can be retrieved from any location. The client simply creates list of portions229, with enriched file names, on-the-fly for any encoded media file217designating portions to generate and retrieve. Therefore, client225does not require pre-fetching the file so it can be partitioned and the appropriate playlist created, leaving the server211with no requirement to perform file management duties.

Instead of dividing a media file into chunks, client225creates a dynamic list of portions where the file names are encoded messages describing how to retrieve portion219from encoded media file217available on server211. If “moviex” names a media file in its entirety, client225creates list of portions229for moviex such that the names for the portions, or “chunks,” describe how to derive each chunk from moviex alone. The “chunk” name contains “moviex” plus a sequentially increasing sequence number plus the starting and ending location in “moviex” for the respective chunks, the first chunk name being “moviex,0001,XXXX,YYYY”, where XXXX is the starting location in moviex for chunk 1 and YYYY is the ending location.

Server211can use an added processor module to process “chunk requests.” When a request for a media file is received, such as for “moviex,0001,XXXX, YYYY”, the processor operates to retrieve as a result the bytes in moviex beginning at XXXX and ending at YYYY. Server211never actually partitions media216or encoded media file217, but client225now functions to create a list of portions229requesting identified portion219while server211, and any other servers managing communication with client225, remain stateless. Instead, client225becomes statefull, tracking the communication between the client225and any servers managing communication.