The invention relates to configuring communication systems based on performance metrics.
Communication systems for delivering content (e.g., multimedia content) from a server to a client include software that runs on the server and software that runs on a client device. Software modules on the client and server implement a communication protocol used over a network connection between the server and client. Classes of software applications that run on the client device include media browser applications and media player applications, for example. Media browser applications permit a user to search a catalog of content (e.g., audio or video content) on the server, select content of interest, and invoke a media player application to present the selected content to the user using the device display screen and/or speaker or headphones.
Some media browser applications for wireless mobile devices use the Wireless Access Protocol (WAP). Such browsers are called WAP browsers. Other mobile applications include Macromedia's Flash for mobile phones (Flash Lite), Synchronous Multimedia Integration Language (SMIL) players, and special purpose media search and playback applications.
In some approaches to delivering multimedia content data to a mobile device, the size of downloaded files, or the length of a data stream, is reduced by compressing the content data (or an approximate representation of the content data) using an encoder. The data is decompressed using a decoder that resides on the mobile device, for example, either as an installed software application or embedded in an integrated circuit on the mobile device.
In a general aspect, the invention features a method, and corresponding software and system, for configuring a communication system. The method includes, for each of a plurality of requests in a communication protocol between a client and a server, estimating values for a plurality of attributes associated with the request, and computing a resource usage estimate, based on a plurality of the estimated attributes, that represents resources used by the communication protocol in response to the request. The method also includes determining at least one group of two or more requests to combine into a combined request based on the respective resource usage estimates for the requests to be combined, and storing a program module for executing the communication protocol including instructions for processing the combined requests.
Aspects of the invention may include one or more of the following features.
Determining at least one group of two or more requests to combine into a combined request comprises selecting at least one request to combine with the request that has the smallest resource usage estimate.
Determining at least one group of two or more requests to combine into a combined request comprises determining a group based on the respective resource usage estimates for the requests to be combined, and a value representing proximity between states of a client program configured to access the communication protocol. Each request is associated with at least one client program state from which the request is able to be transmitted.
Transitions between states of the client program include at least some transitions associated with user input received by the client program.
The user input represents at least one of a button press, a screen tap, a screen drag, or a voice command.
A value representing proximity from a first client program state associated with a first request to a second client program state associated with a second request to be combined with the first request comprises the minimum number of transitions associated with user input that are traversed over any path from the first client program state to the second client program state.
Determining at least one group of two or more requests to combine into a combined request comprises selecting at least one request to combine with a request that has the smallest resource usage estimate.
Selecting the at least one request comprises selecting a request associated with a client program state that has the smallest proximity from a client program state associated with the request that has the smallest resource usage estimate.
Selecting the at least one request comprises selecting from multiple requests corresponding to the smallest proximity, a request that has the smallest resource usage estimate.
Determining whether to combine a group of two or more requests into a combined request comprises computing re-estimated attributes representative of corresponding estimated attributes for each of the requests to be combined.
Computing a re-estimated attribute comprises adding corresponding estimated attributes for each of the requests to be combined.
Computing a re-estimated attribute comprises selecting a maximum among corresponding estimated attributes for each of the requests to be combined.
Determining whether to combine the group of two or more requests into a combined request comprises comparing the re-estimated attributes with a budget based on constraints of the communication system.
The constraints of the communication system comprise constraints of the client, the server, or a communication channel between the client and the server.
Determining at least one group of two or more requests to combine into a combined request comprises determining a request that has the smallest resource usage estimate among requests that include at least one combined request, and selecting at least one request to combine with the request that has the smallest resource usage estimate.
The attributes associated with the request comprise delays associated with processing the request.
The attributes associated with the request comprise amounts of memory used to process the request.
The attributes associated with the request comprise two or more of: server computational delay, client computational delay, server memory usage, client memory usage, an amount of data to be transferred between the server and client, and delay associated with transferring the data.
Estimating values for a plurality of attributes associated with the request comprises estimating the values based on information characterizing past usage of the communication system.
Computing the resource usage estimate comprises normalizing the estimated attributes based on respective maximum values of the estimated attributes over the plurality of requests.
Computing the resource usage estimate for a first request comprises computing a linear combination of the normalized estimated attributes associated with the first request.
Coefficients of the linear combination comprise weights representing the relative contribution of the attributes to the resource usage estimate.
An instruction for processing a combined requests processes the combined request in response to any of the original requests that were combined to form the combined request.
Advantages may include one or more of the following:
The content delivery system can be configured to take into account performance constraints when delivering and presenting multimedia content to mobile devices. For example, a mobile device may have memory and computational constraints, and/or may be connected to a bandwidth-constrained wireless network.
Techniques for configuring server and/or mobile client operating characteristics such as communication protocol requests, operating modes of program modules, or content increase responsiveness of the system to the user.
The techniques enable methods of developing multimedia search, browse, and playback applications optimized for specific devices or classes of devices and for bandwidth-constrained networks, and optimized presentation of multimedia data on portable devices.
The techniques provide a procedure for focusing development efforts on those operating characteristics that contribute most to decreasing the responsiveness to the user or decreasing the quality of the rendered content. Other features and advantages of the invention will become apparent from the following description, and from the claims.
Overview
The number of mobile devices is increasing at a rapid rate. Mobile devices that are wirelessly connected to a network provide access to a large variety of data sources. Some mobile devices can access the internet just as easily as a desktop or laptop computer. However, most mobile devices are not as computationally powerful as a desktop or laptop computer. Some characteristics of a content delivery system, including software for a server and mobile client device, can be configured to take into account the lower computational power (e.g., processing speed), the smaller display screen size, and the smaller speaker size of mobile devices. A configuration system can perform various procedures (e.g., optimization procedures) to prepare the server and/or client device to provide a rich and responsive user experience.
Referring to
The client 104 includes a client application 120 that includes one or more computer program modules that run within the OS 122 on the client 104 (e.g., Java (J2ME), BREW, Symbian, or Windows Mobile). The program modules can include modules that implement communication protocols, and modules for browsing and playing content, for example. The client application 120 has access to volatile memory 124, persistent storage 126, a display screen 128, and an audio output 130 (e.g., a speaker) on the device. The client 104 can also include any of a variety of types of user interfaces for receiving input from a user (e.g., keypad, pressure-sensitive screen, and/or microphone), depending on the type of device.
Data is transferred between the server 102 and the client 104 using a communication protocol for handing request and delivery of content objects (or “content object protocol”). The client 104 sends a content object request to the server 102, and in response the server sends content object data to the client. The server application 110 and client application 120 include program modules to configure messages and data to be transferred according to the content object protocol.
Applications for the client 104 can be characterized by various performance characteristics, such as program size, the amount of memory used to run the program, and the time that elapses in responding to various user inputs. The time to respond to user input can be characterized according to computational delays and delays in accessing data stored on the device (e.g., in volatile memory or persistent storage) or downloaded or streamed via a network connection (e.g., to a local area network, a wide area network, or the internet). The fastest response times involve, for example, low computational delays and access to data in local memory. The slowest response times involve, for example, high computational delays (e.g., decrypting and decompressing a video file), or access to data on the internet with a low-bandwidth connection, or both.
Referring to
The estimated attributes can include attributes of client or server software and/or hardware or attributes of a network over which the client and server are to be connected. For example, the attributes can include computational delays, transfer delays, or memory usage for different types of requests, or for different possible instantiations of program modules. The configuration module 202 determines budgets for the attributes based on system information 208 characterizing the capabilities of the server 102, client 104, and network 106.
In some implementations, the configuration module 202 configures existing program modules, and in other implementations, the configuration module 202 generates new configured program modules. An optional loader 212 loads the configured program modules 206 into a server 102 or a client 104. Alternatively, the configuration system 200 can store program modules as individual source or executable files or compiled into server applications or client applications, to be loaded into a server 102 or client 104.
The Content Object Protocol
The client application 120 communicates with the server application 110, for example, to present audio and video content to the user or in order to present a list of content that is available for presentation to the user. The user can search, browse, or playback multimedia content on the client 104 within an appropriate program module of the application 120. The content object protocol affects the responsiveness of the client application, for example, whenever the client needs to retrieve data from the server. The program modules on the server 102 and client 104 that communicate according to the content object protocol are configured to reduce communication delays and increase responsiveness. The content object protocol includes multiple layers of protocols, including network compatible, server compatible, and client compatible protocols. The network compatible protocols are typically specified by the network, but other portions of the content object protocol are configured to be compact and parsimonious such that client-server communication bandwidth and delays are reduced.
Referring to
There are various types of delays that can be associated with various aspects of delivering and presenting content to a user of the client 104.
There is a delay associated with establishing a connection between the server 102 and client 104 over the network 106. For example, it can take several seconds or more to establish a HyperText Transfer Protocol (HTTP) connection over a wide area network. In some implementations, the content object protocol is configured to reduce the number of new connections established between the client and the server so that the connection delays are reduced.
There is also a delay associated with a request to the server 102 from the client 104. The length of delay depends on what the server 102 needs to do in response to the request. Also, there can be a delay associated with a request to the client 104 from the server 102. Such delays are referred as request processing delays.
There are also communication delays associated with transferring data. Once a connection is established and a request is processed by the server 102, data are transferred between the server 102 and the client 104 at a rate that is determined by the network bandwidth. For example, if the network bandwidth is 10,000 bytes per second then it will take 10 seconds to transfer 100,000 bytes between the client and the server. However, if the 100,000 bytes could be compressed to 10,000 bytes, then it would only take 1 second for the transfer. In some implementations, the content object protocol is configured to reduce the number of bytes that need to be transferred between the client 104 and the server 102.
Configuring the Content Object Protocol
The configuration system 200 can generate a configured client request module 300 for the server 102, and corresponding program module for the client 104, to implement a content object protocol that reduces delays to provide increased responsiveness to a user. The configuration module 202 is able trade off different attributes that affect delay times to reduce delays associated with various requests. In some cases, the configuration module 202 optimizes program module characteristics based on a metric that represents weighted contributions from multiple attributes.
The configuration module 202 can incorporate a tradeoff between reducing the number of new connections, reducing the number of requests, reducing the number of bytes transferred per connection, and reducing the number of bytes transferred per request. For example, one approach to reducing the number of new connections is to use a single connection, keep that connection open until the application terminates, and make multiple requests through that single open connection. While maintaining an open connection and making multiple requests through a single connection is feasible in some situations, a large number of users would lead to a large number of open connections and could potentially overburden the server 102. Another approach to reducing the number of new connections is to use a single connection to transfer all possible data needed by the application in a single download. This option is viable if (1) the connection has a very large bandwidth, (2) the application requires the transfer of a very small amount of data, or (3) the application can parse and use the data before the download completes.
One approach to reducing the number of bytes transferred per connection is to simply limit the number of bytes transferred to a single byte or to a small number of bytes. In this case, the number of new connections will be so large that the user could spend a significant amount of time waiting for connections to be established. Another approach is to use a single connection and to reduce the number of bytes transferred per request by limiting the number of bytes transferred per request to a single byte or to a small number of bytes, and maintaining an open connection while making multiple requests.
In some implementations, the configuration module 202 generates program modules configured to perform an optimized content object protocol that balances the tradeoff between reducing the number of new connections, reducing the number of requests, reducing the number of bytes transferred per connection, and reducing the number of bytes transferred per request given the constraints of the network, the server, and the client. In some implementations, only one request per connection is permitted. In this case, the tradeoff can be made by a joint minimization of the number of new requests and the number of bytes transferred per request. Other implementations based on aforementioned approaches are possible.
In some implementations, the configuration module 202 determines how to optimize the content object protocol based on relationships between requests and program states of the client application 120. As the client application 120 executes on a client device, the application 120 transitions among various program states. Each program state may present a corresponding screen state on the device from which the program state can interact with a user.
For example, referring to
In some cases, the user input triggers a transition to a different screen state. For example, from the home state 402, the user is able to provide input to transition to the media browser state 404A, the media player state 406A, or the preference state 408A. From these states, the user is able to navigate to other states or return to the home state 402. The user input provided to navigate among the user preferences states 408A-408D are local actions that do not trigger communication between the client 104 and server 102.
In some cases, the user input triggers a request from the client 104 to the server 102 (e.g., via a content protocol program module in communication with or integrated with the media application 400). For example, user input provided to navigate among the media browser states 404A-404C trigger requests to the server to retrieve, for example, data related to genres, artists, or songs for selection by the user. Some user input may trigger a request to the server 102 without triggering a screen state transition (e.g., to retrieve a next page of songs in a partial list of songs). If a user selects a song or video, the media application 400 transitions to a media player audio playback state 406B or video playback state 406C, and triggers a request for media playback. In some implementations, a content protocol program module may first attempt to satisfy a request from a cache on the client 104, and then send a request to the server 102 upon a cache miss.
When a request related to a screen state or related to media playback is triggered by user input, there is a response time that corresponds to the time between the user input and an associated user presentation (e.g., presentation of a new screen state, or start of media playback). The response time can include, for example, the time for sending and processing request and response messages, data access delay, and computational delay.
Some client requests to the server 102 include requests related to screen states and other client requests include requests related to media playback, for example. In response to a request related to a screen state, the server 102 composes a Content Object that can include the text, images, audio, video, and/or instructions for rendering and manipulating objects on the screen, according to the request. In response to a request related to media playback, the server 102 composes a Content Object that includes media content data and/or instructions or data related to media playback, according to the request. A Content Object may include data corresponding to multiple screen states and/or data corresponding to media playback.
The number of new requests to the server can be reduced by combining requests that are associated with multiple screen states and by anticipating user behavior. The configuration module 202 can configure program modules for an optimized content object protocol based on collected application usage data 210 that characterizes a users use of the application.
In response to a request related to a screen state, the server 102 sends data used to render one or more images to be displayed in response to user input. In response to a request related to media playback, the server 102 may send screen related data, media data, and/or links to media files. In a screen state associated with media download, more than one image may be presented to the user, or objects on the screen may move or appear to move during media download in order to occupy or distract the user and reduce the perceived download time. An amount of screen related data that can be sent within a specified time period in response to a screen state request can be determined and maximized. Similarly, for media playback requests, an amount of screen related data that can be sent along with the media data or links to media files within a specified time period can be determined and maximized.
A request from the client 104 to the server 102 is associated with a server response and a subsequent client response. The response to a request can be characterized by one or more attributes, including, for example, the server response computational delay, the server response memory usage, the client response computational delay, the client response memory usage, the amount of data that is accessed, the data access type, and the data access delay. The data access type may be, for example: local memory, local file system, local area network, or wide area network. The “click distance” (or “number of clicks”) between two screen states is the minimum number of transitions associated with user input that are traversed over any path from one screen state to the other. In some cases, the click distance from a first screen state to a second screen state is different than the click distance from the second screen state to the first screen state. For example, the click distance from the media browser state 404C to the audio playback state 406B is one, since there is a minimum of one user input transition to navigate from state 404C to state 406B. However, the click distance from the audio playback state 406B to the media browser state 404C is four, since there is a minimum of four user input transitions to navigate from state 406B to state 404C.
Certain screen states can be grouped together into a set of screen states in order to decrease the response time to the user inputs. Screen states that display progress during the download of media data or during the initial loading of streaming media data typically have a large response time to a click corresponding to a media playback request. In some implementations, screen states are grouped according to their click distance and the Content Objects associated with requests triggered from user input are sent to the client 104 as a group.
In one approach to optimization of the content object protocol the configuration system 200 generates configured program modules as follows. The configuration module 202 receives the estimates of attributes associated with different requests available in the content object protocol. The server and client computational delay attributes for a request q are denoted by cqs and cqc, the server and client memory usage attributes for a request q are denoted by mqs and mqc, the number of bytes that are transferred in response to a request q is denoted by nq, and the delay associated with transferring data for a request q is denoted by dq. The configuration module 202 determines budgets for each of these attributes based on system information 208 characterizing capabilities of the server 102, client 104, and network 106.
The configuration module 202 ensures that each of the attributes satisfies the budget requirements. A developer using the configuration system 200 to provide configured program modules may optionally adjust some parameters to ensure that the budget requirements are met. Requests for which the difference between an attribute value and the corresponding budget value is greater than zero do not satisfy the budget requirements and the responsiveness of such requests are either improved in order to meet the budget requirements or the budget requirements are adjusted.
The configuration module 202 configures the content object protocol program modules to reduce the usage of system resources to increase the overall responsiveness of the system to a user. The configuration module 202 uses a combined metric to determine the overall resources such as computation time, network bandwidth, working program memory, and data storage memory used by the communication protocol in response to a request. A resource usage estimate is computed from the attributes to distinguish requests that have high attribute values (and thus use more resources) from those that have low attribute values (and thus use fewer resources).
First, the attribute values are normalized based on maximum values obtained from the usage data 210. For a given attribute value, the configuration module 202 determines the maximum attribute value across all requests and divides the attribute value by the maximum attribute value. For example, if the maximum data access delay is dqmax, then the normalized attribute value is dq/dqmax. Before normalization, the delay attribute values are given in seconds and the memory usage attribute values are given in kilobytes. After normalization, the attribute values are unitless numbers in the range [0,1]. Alternative normalization procedures are possible.
The configuration module 202 stores attribute estimates corresponding to each possible request in the content object protocol in a Request Attribute Table. The Request Attribute Table lists for each request q, the attributes cqs, cqc, mqs, mqc, nq, and dq . . . . The estimation module 208 estimates the attributes based on the usage data 210, and is able to update the estimates as more application usage data 210 is collected.
The procedure 600 sorts 604 the requests in ascending order according to their resource usage estimate σq. Each request is associated with at least one screen state from which the request is able to be transmitted. The procedure 600 determines 606 the minimum click distance from a state associated with the request with the lowest resource usage estimate to a state associated with each of the other requests. The procedure 600 determines 608 a candidate request grouping by grouping the request with the lowest resource usage estimate with a request having an associated state with the lowest click distance. If more than one request is associated with a state with the lowest click distance, then the procedure selects the one having the lowest resource usage estimate. The procedure 600 re-estimates the attributes for a potential combined request that includes both of the grouped requests based on the individual attributes for both requests, as described in more detail below.
The procedure 600 determines 610 whether to store a single combined request to replace the two grouped requests in a new Request Attribute Table based on whether the combined request would satisfy the budget requirements. If the candidate request grouping does not cause any of the re-estimated attribute values for the combined request to exceed the budget value for that attribute, then the combined request is added to the Request Attribute Table. If the candidate request grouping does cause a budget value to be exceeded, then the procedure 600 selects another candidate request to group with the request having the lowest resource usage estimate. The procedure 600 searches for another candidate request first according to the request associated with the lowest click distance, and second (as a tie-breaking criterion) according to the request with the lowest resource usage estimate.
The procedure 600 determines 612 whether a desired reduction in the number of requests is achieved, or whether no further grouping of requests satisfy the budget requirements. If either of these conditions is true, then the procedure 600 ends 614. If not, then the procedure 600 repeats using the new Request Attribute table.
The procedure 600 re-estimates the attributes for a potential combined request based on the individual attributes for both grouped requests using different procedures depending on which attribute is being re-estimated. The computational delays, number of bytes transferred, and the data transfer delay attributes are summed. The memory usage attribute of the combined request is the maximum value of the individual memory usage attributes.
When a click distance is calculated for two requests, and at least one of the requests is a combined requests, the procedure 600 can use any of a variety of techniques to select a reference request among the corresponding grouped requests. The reference request is then used for computing click distances. For example, the reference request can be the request that was associated with the largest click distance when the requests were combined. Alternatively, the reference request can be the request that was associated with the smallest click distance when the requests were combined. Alternatively, the request with the largest amount of data to be transferred and/or the largest transfer delay can be chosen as the reference request.
Configuring Client Applications
Client applications can be configured to support reconfigurable user interface components without the need for rebuilding or re-compiling the application. The content delivery system 100 supports dynamic content, e.g., the ability to change content “on the fly.” Client applications can be optimized by jointly optimizing performance characteristics such as program size, memory usage, and responsiveness to user input.
In an exemplary configuration process for the application 800, a set of required program modules is identified along with the program size, memory usage, and response time characteristics for each module. A main program for the application 800 is also treated as a program module. Each program module may have several different instantiations. Each instantiation of module i has associated with it an instantiation index Ji, and the set of instantiation indices for all modules will be denoted by J, i.e., J={J1,J2 . . . Jn}.
The application 800 has associated with it K states, and at any time while the application is executing the application is in an identifiable and observable state k. In practice, the number of states of an application may be quite large. Let aik denote the activity of module i at state k. The activity aik is a binary variable with a value of 0 or 1, i.e., a module is either active (aik=1) or inactive (aik=0). The module activity matrix, denoted by a, indicates which modules are active in any state.
The number of states and the identity of each state of an application can be determined by executing the application with each distinct set of possible user inputs and identifying which modules are active at any time. States are identified by changes in the number of modules that are active or changes in memory usage. Alternatively the configuration process can use a pre-defined set of states.
The number of states associated with multi-threaded applications is determined by the number of states for each thread. If the threads are independent, then the number of states is the sum of the number of states for each thread. If the threads are dependent, then an upper bound on the number of states of the application is the product of the number of states for each thread. Typically, the number of states of a multi-threaded application is between the sum of the number of states for each thread and the product of the number of states for each thread. The total amount of memory used by the application generally depends on the number of threads active at any given time. Memory usage for simultaneously active threads tends to create a dependency between those threads.
Hierarchical application design tends to simplify the determination of the number of states and tends to make the activity matrix sparse or reduced in rank. Hierarchical application design in this context includes the reduction of the number of active modules for any given state. As will be shown, hierarchical application design will tend to reduce the complexity of the optimization procedure.
Let the program size of instance j of module i be denoted by sij. The program size is a simple performance characteristic to measure because it is independent of the application state and memory usage.
The memory usage of a module can be a bit more difficult to measure because the memory usage may be state dependent. To incorporate state dependence, the memory usage within each state is measured. Let the memory usage of instance j of module i in state k be denoted by mijk. Let Mk(J) be the total memory used by the application in state k given the choice of instantiations implied by J, the instantiation index set. The total memory in use by the application in any state k is the sum of the memory used by all active modules in that state, i.e., Mk(J)=Σi=1naikmiJdi ik.
The response time of a module may be the most difficult performance characteristic to measure because it may be dependent on the application state, the memory usage of the application, the network bandwidth, or on all three. The response time is also dependent on the computational capabilities of the device and the software environment (e.g., operating system) on the device. The application 800 can be optimized for each device and software environment. Modules may be restricted such that only one user input occurs per module and, correspondingly, only one response time needs to be measured per module. In practice there may be multiple user inputs per module and, correspondingly, multiple response times per module. However, user inputs can be categorized into several groups and, correspondingly, the response times can be categorized into the same number of groups. User inputs and response times are categorized according to their computational requirements, memory requirements, and data access requirements, and one response time performance characteristic is defined for each category. An exemplary table of user input categories are shown in
The dependence of the response time of instance j of module i on the total memory usage in state k is denoted by rijk(Mk). The response time may also be a function of the network bandwidth at time k, Bk, i.e., rijk=rijk(Bk), if the response requires downloading or uploading data from or to a server, for example. (A case in which the download bandwidth is different from the upload bandwidth is also possible.) In general, the response time is a function both the total memory usage and the network bandwidth, i.e., rijk=rijk(Mk,Bk). The functional dependence of the response time on total memory usage and network bandwidth is assumed to be separable, i.e., rijk(Mk,Bk)=f(Mk)g(Bk). The functional dependence of the response time on total memory usage is directly proportional to the total memory usage, i.e., increasing memory usage leads to increased response times. This dependence is typically nonlinear. In some implementations the dependence of the response time on the total memory usage is measured for each total memory usage value. Alternative implementations employ several other functional dependencies. The functional dependence of the response time on network bandwidth is inversely proportional to the network bandwidth. In practice, the time dependency of network bandwidth is often unknown. In some implementations the expected network bandwidth is used, i.e., Bk is set to E[Bk]=B, and the dependence on network bandwidth is modeled by g(B)=g0B−1+D, where D is a delay associated with establishing a network connection. If the network bandwidth is in units of kilobits per second and the delay is in units of seconds, then g0 is 1 kilobit.
With these definitions, the performance of an application can be characterized by the instantiation index set, the activity matrix, the module sizes, the module memory usage, and the module response times. This set of application characteristics is denoted by A(J), i.e., A(J)={aik,sij,mijk,rijk,Ji; i=1,2, . . . n; j=Ji; k=1, . . . K}. Next, a set of performance measures and an optimization objective function is defined so that the best instantiation index set can be chosen such that the performance measures are optimized across all states, modules, and instantiations.
Various performance measures can be used to optimize the performance of an application. In some implementations, three performance measures are used: the total application size, the maximum memory usage of the application, and the overall responsiveness of the application. The total application size performance measure, denoted by S, is the total program size for a selected instantiation index set and is computed as the sum of the sizes of all program modules given J, i.e., S(J)=Σi=1nsiJ
The overall application responsiveness performance measure, denoted by R, is the sum of the response times for each module across all states given J, i.e., R(J)=Σk=1KΣi=1nriJ
There are several approaches to jointly minimizing the application program size, memory usage, and response times given maximum allowed values for each of these values. In some implementations, the following approach is taken. Let Sb, Mb, and Rb denote the budget values for the application program size, memory usage, and response time, respectively. The objective function, E, for the optimization procedure is E(J)=wsS(J)+wMM(J)+wRR(J), where wS, wM, and WR are emphasis weights for the program size, memory usage, and response time measures. If the three measures have equal emphasis, the emphasis weights are chosen to simply normalize the performance measures. For example, the program size is normalized to the maximum possible program size given the program sizes of all instantiations for each module. So if the three measures have equal emphasis, each term in the objective function will range from 0 to 1 and contribute equally. The goal of the optimization procedure is to find the instantiation index set that minimizes the objective function. The optimization procedure minimizes the objective fimction over all possible instantiation index sets J subject to the constraints S(J)≦Sb, M(J)≦Mb, and R(J)≦Rb. If any of the performance measures associated with the optimal instantiation index set exceeds the budgeted value, then additional instantiations are required. Thus, the terms in each of the application performance characteristic sums provide an indication of which if any program modules require improved performance characteristics.
The objective function can be written explicitly as
Given the set of performance characteristics and emphasis weights, the performance measures and the objective function can be computed. The minimum objective function can be found by computing the objective function for each possible instantiation index set and choosing the set that minimizes the objective function and satisfies the performance budget constraints.
If no instantiation index set exists that satisfies all of the performance budget constraints, additional instantiations are used. The individual contributions to the performance measures by each module may be used to determine the modules for which additional instantiations will be most productive.
If there are L performance characteristics (e.g., L=3 for a single response time characteristic per module), n modules, I instantiations per module, and K discrete states, then the complexity of the optimization procedure is O[I(n+nK+LnK)]. If there are 16 types of responses to user inputs, then L=2+16=18. Although the complexity analysis above assumes the number of instantiations is the same for each module, this constraint is not necessary. The optimization procedure is applied to each target device or device class.
The hierarchical application design concept points the way toward an alternative iterative approach to optimization. In this alternative approach, the activity matrix is analyzed and clusters of modules in the same state are identified for optimization. This process of identifying and optimizing submatrices within the activity matrix is repeated until all modules and states have been optimized and a global minimum of the objective function is reached.
In an extension to the optimization procedure, each screen state that can be presented to the user within the application can be assigned a specific performance characteristic budget, e.g., the modules associated with generating each screen state may be assigned a maximum program size, memory, and response time. Such per screen state performance budgets serve as additional constraints on the solution. To implement this extension, the list of modules required to produce each screen state is used and performance measures are computed for each screen state by modifying the summations over the modules to include only those modules required to produce the screen.
Configuring Content
The server 102 can configure content before it is provided to the client 104, such that the content is optimized for a given target device or class of devices, or such that the content has properties that enable the content delivery system 100 to deliver the content with increased responsiveness to the user. For example, two exemplary types of content configuring are described below: audio content optimization, and video content optimization.
Audio
Optimizing audio content for the target device involves a tradeoff between audio quality, bit rate, and, in some applications, speed of encoding. The bit rate constraint may be determined by the network bandwidth or by the amount of memory or storage available on the target device. The amount of memory or storage available on the device may also require that the audio data be broken up into segments. One exemplary audio content optimization procedure assumes that the network bandwidth has been specified or determined prior to or at the time the media content is to be transferred, and that the amount of memory and storage available on the target device has been specified or determined prior to or at the time the media content is to be transferred. The optimization procedure achieves the highest audio quality given the bit rate constraint. In an alternative implementation, an additional constraint on the speed of encoding is taken into account.
Some cell phones are optimized for voice signals and are not optimized for music content. However, music content can be optimized for presentation on target devices by taking into account device speaker, audio decoder, and audio playback characteristics as well as data from listening tests. Volume normalization is employed to achieve consist volume levels for each piece of audio content. Alternatively, level-dependent companding of the sampled audio is employed to avoid low volume levels during playback.
The speaker on the device can be characterized by playing a test signal such as a linear chirp on the device and measuring the output from the speaker. The speaker output is compared with the original signal and the distortion introduced by the speaker is characterized. Typically, the speaker distortion characterization takes the form of a frequency response curve. This frequency response curve is taken into account when preparing audio content to be played on the device. For example, if certain portions of the frequency spectrum are characterized by a low response, those portions of the spectrum can be amplified in the signal that is to be played on the device. A compensatory filter is applied to the input signal so that the resulting signal to be played on the device will have the desired frequency response. The desired frequency response is enhanced in regions of low response (e.g., to compensate for poor speaker response) or attenuated in regions of excessive response (e.g., to avoid vibrational noise). Various types of compensatory filters can be constructed using digital signal processing techniques.
Data from listening tests may also suggest modifications of the response in certain portions of the spectrum for specific devices. For example, if most subjects report a deficient low frequency response, the compensatory filter is adjusted to produce higher response in the low frequency portion of the spectrum. In some implementations, if more than 75% of subjects report a characteristic that is common to most input signals and that can be compensated for, then the compensation is applied to all input signals.
In some implementations, the headphones that are shipped with the device, or a list of target headphones, are characterized using the same methods that were used with the speaker.
In some implementations, the audio formats compatible with the device are analyzed with respect to audio quality and bit rate. The audio format that produces the highest perceived quality at the target bit rate is chosen. In some cases, listening tests are performed to determine which audio format produces the highest perceived quality at the target bit rate.
An exemplary optimization procedure is as follows. A reference audio signal is chosen that represents the typical audio content that will be used. The reference audio signal is modified using methods such as compensatory filtering, compression, and companding. Each modified signal is characterized by a set of attributes. The attributes of the modified signals are: an objective quality measure, a subjective quality rating, and a modification processing delay. The objective quality measure is, for example, the segmental signal-to-noise ratio. A number of other objective quality measures could be used. Subjective quality ratings are obtained via listening tests in which subjects listen to the modified signals and rate them on a scale from −3 to 3, where 0 represents no difference from the unmodified signal. Subjective quality ratings are averaged across subjects. The attribute values are normalized by determining the range of values for each attribute and transforming the attribute values so that they range from 0 to 1. In the case of the modification processing delay, the inverse of the modification processing delay is transformed into the [0,1] range. For each modified signal, the sum of all normalized attribute values is computed. The normalized attributes may be weighted to emphasize certain attributes more than others. The modified signal with the highest sum of normalized attribute values is chosen as the optimum modification process.
In some implementations, this optimum modification process is applied to all audio content. In other implementations, some fraction of the audio content that will be used in the application undergoes this optimization process. In some implementations, each piece of audio content is optimized using additional objective quality measures instead of the subjective quality ratings.
Video
Optimizing video content for the target device involves a tradeoff between video quality, bit rate, and, in some applications, speed of encoding. The bit rate constraint may be determined by the network bandwidth or by the amount of memory or storage available on the target device. The amount of memory or storage available on the device may also require that the video data be broken up into segments. exemplary video content optimization procedure assumes that the network bandwidth has been specified or determined prior to or at the time the media content is to be transferred, and that the amount of memory and storage available on the target device has been specified or determined prior to or at the time the media content is to be transferred. The optimization procedure achieves the highest video quality given the bit rate constraint. In an alternative implementation, an additional constraint on the speed of encoding is taken into account.
In some implementations, video quality is increased for presentation on target devices by taking into account the characteristics of the screen on the device, the video decoder if any, and the image rendering capabilities of the software environment as well as data from viewing tests. Luminance or gamma correction is used to compensate for display screens that tend to be dark or bright.
Some display screens do not accurately reproduce the colors specified in an image or video file. Various methods can be used for correcting color distortion introduced by displays including gamma correction and color transformation and matching. In some implementations, a color test image is used to adjust the colors using color matching.
Luminance contrast enhancement is a type of luminance modification that can be used to enhance the perceived image quality. Opponent color contrast enhancement is a type of color modification that can be used to improve the perceived image quality. In some implementations, luminance contrast enhancement and opponent color contrast enhancement are performed via opponent color center-surround shunt processing. Alternative implementations use other contrast enhancement methods.
In addition to luminance correction, color correction, luminance contrast enhancement, and opponent color contrast enhancement, frame rate modifications can be performed on video signals to enhance the perceived video quality during playback. Sometimes, for example, using a faster decoded frame rate has the effect of smoothing out pixelization artifacts that occur as a result of compression. In some implementations, frame rate reduction is performed by reducing the number of key frames. Some implementations subsample the number of frames in the original video or generate a reduced number of output frames as part of the compression process.
An exemplary optimization procedure is as follows. A reference video signal is chosen that represents the typical video content that will be used. The reference video signal is modified using methods such as luminance correction, color correction, luminance contrast enhancement, opponent color contrast enhancement, frame rate resampling, and compression. Each modified signal is characterized by a set of attributes. The attributes of the modified signals are: an objective quality measure, a subjective quality rating, and a modification processing delay. The objective quality measure is, for example, the peak signal-to-noise ratio. A number of other objective quality measures could be used. Subjective quality ratings are obtained via viewing tests in which subjects view the modified signals in a controlled environment and rate them on a scale from −3 to 3, where 0 represents no difference from the unmodified signal. Subjective quality ratings are averaged across subjects. The attribute values are normalized by determining the range of values for each attribute and transforming the attribute values so that they range from 0 to 1. In the case of the modification processing delay, the inverse of the modification processing delay is transformed into the [0,1] range. For each modified signal, the sum of all normalized attribute values is computed. The normalized attributes may be weighted to emphasize certain attributes more than others. The modified signal with the highest sum of normalized attribute values is chosen as the optimum modification process.
In some implementations, this optimum modification process is applied to all video content. In other implementations, some fraction of the video content that will be used in the application undergoes this optimization process. In some implementations, each piece of video content is optimized using additional objective quality measures instead of the subjective quality ratings.
Network Environment
The network 106 over which the data stream is sent to the client 104 can be any type of network including, for example, wired, wireless, Bluetooth, personal area networks, local area networks, or wide area networks. Some wireless network architectures, such as General Packet Radio Service (GPRS), impose bandwidth limitations on communication systems. Such communication systems can benefit from the techniques described herein. Additionally, communication systems operating on networks with high bandwidth will benefit from the techniques described herein because such networks can have a lower effective bandwidth if there are an excessive number of users, a large number of users in a single cell, users are moving between cells, and/or the client and server communication path is blocked by structures such as buildings. The communications protocol used is compatible with the network 106.
Alternative Implementations
Many other implementations other than those described above are within the scope of the following claims. For example, even though specific content types may have been mentioned above, any of a variety of types of content can be included. Content types can include text, images, audio, and video. The text content may represent information related to image, audio, or video data, parameters for rendering the screen, or instructions for rendering the screen. Image content may include splash screens, artwork related to the audio or video content, artwork related to the multimedia application, artwork related to the content provider, or informational images. Audio content may include ringtones, segments of music tracks, full music tracks, interviews, sound effects, and informative announcements. Video content may include music videos, interviews, movie previews, game previews, and informative announcements. Video content may include video data without audio content or video and audio content.