Technology for receiving streaming media content is disclosed. A media presentation description (MPD) for the streaming media content can be received at a user equipment (ue). A streaming interval can be selected for the streaming media content. A power consumption level can be calculated for receiving the streaming media content at each of a plurality of media content representations that are described in the MPD. A media content representation can be selected from the plurality of media content representations based on: the power consumption level associated with receiving the streamed media content at the media content representation; and power status information for the ue, using the one or more processors of the ue. The streaming media content can be received at the selected media content representation, at the ue, in accordance with the streaming interval. The streaming media content can be played at the ue.
|
1. A user equipment (ue) operable to receive streaming media content, the ue comprising one or more processors and memory configured to:
parse a media presentation description (MPD) for the streaming media content;
select a streaming interval for the streaming media content;
calculate a power consumption level for receiving the streaming media content at each of a plurality of media content representations that are described in the MPD;
select a media content representation from the plurality of media content representations based on:
the power consumption level associated with receiving the streamed media content at the media content representation; and
power status information for the ue
retrieve the streaming media content at the selected media content representation in accordance with the streaming interval to enable playback at the ue; and
determine updated power status information for the ue after each streaming interval to reflect actual power consumption at the ue, wherein the updated power status information for the ue is determined based on: a coefficient value that represents a type of screen mode for the ue, a video encoding bitrate and a value that represents a change in network bandwidth, and the updated power status information is utilized to select an updated media content representation.
16. A user equipment (ue) operable to receive streaming media content, the ue comprising one or more processors and memory configured to:
calculate a power consumption level for receiving the streaming media content at each of a plurality of media content representations that are described in a media presentation description (MPD);
select a media content representation from the plurality of media content representations based on:
a remaining amount of playback time for the streaming media content;
the power consumption level associated with receiving the streamed media content at the media content representation;
power consumption preference information from a user associated with the ue; and
power status information for the ue, wherein the power status information for the ue includes a remaining battery level for the ue,
retrieve the streaming media content at the selected media content representation for a streaming interval to enable playback at the ue; and
determine updated power status information for the ue after each streaming interval to reflect actual power consumption at the ue, wherein the updated power status information for the ue is determined based on: a coefficient value that represents a type of screen mode for the ue, a video encoding bitrate and a value that represents a change in network bandwidth, and the updated power status information is utilized to select an updated media content representation.
21. A method for receiving streaming media content, comprising:
receiving a media presentation description (MPD) for the streaming media content at a user equipment (ue), using one or more processors of the ue;
selecting a streaming interval for the streaming media content, using the one or more processors of the ue;
calculating a power consumption level for receiving the streaming media content at each of a plurality of media content representations that are described in the MPD, using the one or more processors of the ue;
selecting a media content representation from the plurality of media content representations based on:
the power consumption level associated with receiving the streamed media content at the media content representation; and
power status information for the ue, using the one or more processors of the ue;
receiving the streaming media content at the selected media content representation, at the ue, in accordance with the streaming interval, using the one or more processors of the ue;
playing the streaming media content at the ue, using the one or more processors of the ue; and
determining updated power status information for the ue after each streaming interval to reflect actual power consumption at the ue, wherein the updated power status information for the ue is determined based on: a coefficient value that represents a type of screen mode for the ue, a video encoding bitrate and a value that represents a change in network bandwidth, and the updated power status information is utilized to select an updated media content representation, using the one or more processors of the ue.
2. The ue of
select a burst size for receiving the streaming media content based on an available download rate at the ue; and
fetch bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the ue.
3. The ue of
4. The ue of
5. The ue of
increase the streaming interval when the power status information indicates that a remaining battery level for the ue is relatively high; or
decrease the streaming interval when the power status information indicates that the remaining battery level for the ue is relatively low.
6. The ue of
7. The ue of
8. The ue of
9. The ue of
receive power consumption preferences from a user associated with the ue; and
select the media content representation from the plurality of media content representations based, in part, on the power consumption preferences.
10. The ue of
11. The ue of
12. The ue of
13. The ue of
14. The ue of
15. The ue of
identify a remaining amount of time for the streaming media content;
identify a remaining battery level for the ue; and
select the media content representation at a media content representation that ensures that the remaining amount of time for the streaming media content is received at the ue within the remaining battery level for the ue.
17. The ue of
select a burst size for receiving the streaming media content based on an available download rate at the ue; and
fetch bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the ue.
18. The ue of
19. The ue of
select the streaming interval for the streaming media content; and
retrieve the streaming media content at the selected media content representation in accordance with the streaming interval to enable playback at the ue.
20. The ue of
22. The method of
selecting a burst size for receiving the streaming media content based on an available download rate at the ue; and
fetching bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the ue.
23. The method of
|
|||||||||||||||||||||||||
The growth of multimedia services, including streaming and conversational services, is one of the key drivers of the evolution to new mobile broadband technologies and standards. Digital video content is increasingly consumed in mobile devices. There are many video applications extensively used on mobile devices in daily life. For example, online video streaming include popular services such as YouTube and Hulu. Video recording and video conferencing include services such as Skype and Google Hangout. In 2011, YouTube had more than 1 trillion global views. Ten percent of the views were accessed via mobile phones or tablets. As more smart phones, tablets, and other mobile computing devices are purchased, their use for video recording and video conferencing will increase dramatically. With such high consumer demand for multimedia services coupled with developments in media compression and wireless network infrastructures, it is of interest to enhance the multimedia service capabilities of future cellular and mobile broadband systems and deliver high quality of experience (QoE) to the consumers, thereby ensuring ubiquitous access to video content and services from any location, at any time, with any device and technology.
Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure; and, wherein:
Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.
Before the present invention is disclosed and described, it is to be understood that this invention is not limited to the particular structures, process steps, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular examples only and is not intended to be limiting. The same reference numerals in different drawings represent the same element. Numbers provided in flow charts and processes are provided for clarity in illustrating steps and operations and do not necessarily indicate a particular order or sequence.
An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is intended to aid readers in understanding the technology more quickly but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.
A technology is described for receiving streaming media content at a user equipment (UE). The UE can receive a media presentation description (MPD) for the streaming media content. The MPD can describe a plurality of media content representations that are available to be received at the UE. For example, each media content representation can be associated with a corresponding bitrate and/or quality level. The UE can calculate a power consumption level for receiving the streaming media content at each of a plurality of media content representations. For example, the UE can calculate that streaming media content at a first media content representation (e.g., a first bitrate) consumes X amount of power per a unit of time, streaming media content at a second media content representation (e.g., a second bitrate) consumes Y amount of power per the unit of time, and so on. The UE can calculate the power consumption level for each media content representation using a model type associated with the UE and/or a display resolution of the UE. The UE can select at which media content representation to stream the media content based on a plurality of factors. For example, the UE can select the media content representation based on the power consumption level associated with receiving the streamed media content at the media content representation, power status information for the UE (e.g., a remaining battery level), user-defined power consumption preferences, and/or a remaining amount of time for the streaming media content. The UE can retrieve the streaming media content at the selected media content representation to enable playback at the UE.
In one configuration, the UE can select a burst size for receiving the streaming media content based on an available download rate at the UE. For example, the UE can select a 1-second burst of streaming media content, a 5-second burst of streaming media content, etc. The UE can fetch the bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the UE. For example, the UE can switch off a radio interface at the UE between bursts of streaming media content that are received at the UE. As a non-limiting example, the UE can receive a 5-second burst of streaming media content when network conditions are favorable (i.e., the network conditions allow for a relatively high download rate). The UE can then switch off the radio interface for a defined number of seconds (e.g., 4 seconds) before fetching the next burst of streaming media content in order to conserve power at the UE.
Hypertext transfer protocol (HTTP) adaptive streaming (HAS) can be used as a form of multimedia delivery of Internet video. HTTP-based delivery can provide reliability and deployment simplicity due to a broad adoption of both HTTP and HTTP's underlying protocols, including transmission control protocol (TCP)/internet protocol (IP). HTTP-based delivery can enable easy and effortless streaming services by avoiding network address translation (NAT) and firewall traversal issues. HTTP-based delivery or streaming can also provide the ability to use standard HTTP servers and caches instead of specialized streaming servers. HTTP-based delivery can provide scalability due to minimal or reduced state information on a server side.
When using HAS to deliver internet multimedia content, a video client operating on a mobile device can be configured to perform the primary role in rate adaptation by choosing and requesting the appropriate video representation levels from a video server using an HTTP GET or partial GET command to retrieve data from a specified resource, such as a multimedia server. The video client initially builds up a buffer to a certain level before beginning to playback streaming multimedia content, such as audio or video. This phase is referred to as the startup phase. After this, the client begins playback of the buffered multimedia content. The quality and resolution of the multimedia playback at the client device is dependent on the available link bandwidth. The video client typically estimates the available link bandwidth based only on higher layer throughput estimates, such as HTTP-level video streaming throughput, or on transmission control protocol (TCP) throughput.
Multimedia streaming in a high mobility environment can be challenging when fluctuations in network conditions (i.e., network variability) decreases a communication data rate associated with the multimedia content. When an overloaded network causes the communication data rate to decrease, an end user quality of experience (QoE) can decrease as well. For example, the multimedia content received at the mobile device can be of less resolution or quality and/or the multimedia content can periodically break or pause when being provided over the overloaded network.
The use of progressive download based streaming techniques in mobile networks of limited resources can be undesirable due to inefficient bandwidth utilization and poor end user quality of experience. As discussed in further detail below, hyper-text transfer protocol (HTTP) based streaming services, such as dynamic adaptive streaming over HTTP (DASH), can be used to address weaknesses of progressive download based streaming.
Multimedia content that is streamed to a client, such as a user equipment (UE), can include a plurality of multimedia content segments. The multimedia content segments can each contain different encoded versions that represent different qualities levels of the multimedia content. The different encoded versions can allow the client to seamlessly adapt to changing network conditions. For example, when the network conditions are good (i.e., the network conditions are above a predetermined threshold), the client can request multimedia content segments that are of a higher video quality. When the network conditions are poor (i.e., the network conditions are below a predetermined threshold), the client can request multimedia content segments that are of a lower video quality. As a result, the client can still be able to receive the multimedia content segments (albeit at a lower quality) when the network conditions are poor and a likelihood of the adaptive media stream being interrupted can be reduced.
In DASH, the client can select the multimedia content segments with a highest bit rate, such that the multimedia content segments can be downloaded at the client in time for media playback without causing a rebuffering event in the media playback. In other words, the client may not select multimedia content segments that are so high that the adaptive media stream is periodically interrupted in order to cache or preload a portion of the media content onto the client before resuming media playback at the client. In one example, adverse network conditions can degrade a quality of the media content stream. The adverse network conditions can include coverage nulls, abrupt bandwidth changes, packet losses, substantial delay variations, etc. Although adaptive streaming techniques can consider current network conditions when calculating an available throughput and determining an appropriate streaming bit rate based on the available throughput, smooth media playback at the client may not be guaranteed during abrupt network variations and/or adverse network conditions.
Therefore, in order to maintain a desirable quality of experience for an adaptive media stream at the client, the client's planned route and current network conditions along the planned route can be used to strategically cache the multimedia content segments at the client, thereby resulting in smoother media playback and an enhanced quality of experience at the client. The client can select a planned route (i.e., a geographical route that the client is about to embark on). The client can be streaming media content (e.g., a movie) while traveling on the planned route. In one example, the client can include a mobile device located within a moving vehicle or a computing device of the vehicle. The client can receive current network conditions for the planned route from a channel information database (CID). The current network conditions can include certain locations along the planned route (e.g., tunnels, bridges, remote areas) with corresponding network conditions that are below a predetermined threshold. The client can request additional media content segments of the media content (e.g., additional segments of the movie) from a media content server and then store the additional media content segments in the cache. When the client reaches the locations along the planned route with network conditions that are below the predetermined threshold, the client can playback media content that is stored in the cache. As a result, continuous media playback can be substantially provided at the client, even during times when current network conditions along the planned route fall below the predetermined threshold.
Wireless Multimedia Standards
There have been a number of multimedia standards that have been developed to enable multimedia to be communicated to, from, or between mobile computing devices. For instance, in streaming video, the third generation partnership project (3GPP) has developed technical specification (TS) 26.234 (e.g. Release 11.0.0) that describes packet-switched streaming services (PSS) that are based on the real-time streaming protocol (RTSP) for unicast streaming of on-demand or live content. In addition, hyper-text transfer protocol (HTTP) based streaming services, including progressive download and dynamic adaptive streaming over HTTP (DASH), are described in 3GPP TS 26.247 (e.g. Release 11.0.0). 3GPP-based multimedia broadcast and multicast services (MBMS) specification TS 26.346 (e.g. Release 11.0.0) specifies streaming and download techniques for multicast/broadcast content distribution. As such, DASH/PSS/MBMS-based mobile computing devices, such as user equipment (UEs), decode and render streamed videos at the UE devices. Support for the 3GPP file format in 3GPP TS 26.244 (e.g. Release 11.0.0) is mandated in all of these specifications to support file download and HTTP-based streaming use cases.
One example of a standard for conversational video communication, such as video conferencing, is provided in 3GPP TS 26.114 (e.g. 11.0.0). The standard describes the multimedia telephony services over IMS (MTSI) that allows delivery of advanced multimedia conversational services and content over internet protocol (IP) multimedia subsystems (IMS) based networks. IMS is standardized in 3GPP TS 26.140 (e.g. Rel. 11.0.0). An MTSI-based transmitter UE terminal can capture and record video, and then transfer the video to an MTSI-based receiver UE terminal over a 3GPP network. The receiver UE terminal can then decode and render the video. The 3GPP TS 26.140 also enables video sharing using multimedia sharing services (MMS), in which support for the 3GP file format is provided.
The standards described above are provided as examples of wireless multimedia standards that can be used to communicate multimedia files to, from, and/or between multimedia devices. The examples are not intended to be limiting. Additional standards can be used to provide streaming video, conversational video, or video sharing.
Streaming Media Standards
A more detailed explanation of HTTP streaming, and more particularly, the DASH standard is provided herein, in context with embodiments of the present invention. The detailed explanation is not intended to be limiting. As will be further explained in the proceeding paragraphs, the embodiments of the present invention can be used to efficiently communicate multimedia to, from, and/or between mobile devices by enabling the mobile devices, or the servers in communication with the mobile devices, to select and/or communicate multimedia having a desired energy characterization. The multimedia can be communicated using a standardized or non-standardized communication scheme.
Hypertext transfer protocol (HTTP) streaming can be used as a form of multimedia delivery of Internet video. In HTTP streaming, a multimedia file can be partitioned into one or more segments and delivered to a client using the HTTP protocol. HTTP-based delivery can provide reliability and deployment simplicity due to a broad adoption of both HTTP and HTTP's underlying protocols, including transmission control protocol (TCP)/internet protocol (IP). HTTP-based delivery can enable simplified streaming services by avoiding network address translation (NAT) and firewall traversal issues. HTTP-based delivery or streaming can also provide the ability to use standard HTTP servers and caches instead of specialized streaming servers. HTTP-based delivery can provide scalability due to minimal or reduced state information on a server side. Examples of HTTP streaming technologies can include Microsoft IIS Smooth Streaming, Apple HTTP Live Streaming, and Adobe HTTP Dynamic Streaming.
DASH is a standardized HTTP streaming protocol. As illustrated in
A DASH client can receive multimedia content by downloading the segments through a series of HTTP request-response transactions. DASH can provide the ability to dynamically switch between different bit rate representations of the media content as the bandwidth that is available to a mobile device changes. Thus, DASH can allow for fast adaptation to changing network and wireless link conditions, user preferences and device capabilities, such as display resolution, the type of central processing unit (CPU) employed, the memory resources available, and so forth. The dynamic adaptation of DASH can provide a better quality of experience (QoE) for a user, with shorter startup delays and fewer rebuffering events than other streaming protocols.
In DASH, a media presentation description (MPD) metadata 102 can provide information on the structure and different versions of the media content representations stored in a web/media server 212, as illustrated in
In
The multimedia in the adaptation set can be further divided into smaller segments. In the example of
As shown in
For example, a web browser 222 of the client 220 can request multimedia content using a HTTP GET message 240. The web server 218 can provide the client with a MPD 242 for the multimedia content. The MPD can be used to convey the index of each segment and the segment's corresponding locations as shown in the associated metadata information 252. The web browser can pull media from the server segment by segment in accordance with the MPD 242 as shown in 236. For instance, the web browser can request a first segment using a HTTP GET URL(frag 1 req) 244. A uniform resource locator (URL) or universal resource locator can be used to tell the web server which segments the client is to request 254. The web server can provide the first fragment (i.e., segment 1 246). For subsequent segments, the web browser can request a segment i using a HTTP GET URL(frag i req) 248, where i is an integer index of the segment. As a result, the web server can provide a segment i 250. The segments can be presented to the client via a media decoder/player 224.
In one example, the HTTP server 310 can be coupled to a channel information database 350. The channel information database 350 can include current network conditions for a plurality of geographical locations. The plurality of geographical locations can include particular roads, streets, neighborhoods, geographical regions, bridges, tunnels, etc. The current network conditions can be based on real-time monitoring of the current network conditions for the plurality of geographical locations. Therefore, the channel information database 350 can be dynamically updated due to variations in the current network conditions. Alternatively, the current network conditions can be inferred based on historical network condition information for the plurality of geographical locations. In yet another example, the current network conditions can be determined using crowd sourced network condition information.
The technology described herein provides a novel power-efficient media content (e.g., video and audio) streaming technique. The novel media content streaming technique can support the dynamic adaptive streaming over hypertext transfer protocol (DASH) protocol. The novel media content streaming technique described herein can improve difficulties with previous streaming solutions. For example, previous streaming technologies can fail to stream full movies to the UE due to battery limitations (e.g., the battery at the UE can die halfway through the movie or before the movie is completely received at the UE). Previous streaming technologies can fail to stream an entire movie at substantially the same quality level during low power conditions at the UE. Previous streaming technologies generally do not use contextual information, such as device type, device power consumption levels, etc. for various media content streaming modes at the UE. These streaming modes can include 3G, WiFi and other related streaming modes. In addition, previous streaming technologies generally provide inefficient evaluation and use of content quality when optimizing the download of media content at the UE. The novel media content streaming technique described herein can generally improve the above problems with past streaming solutions.
The technology described herein provides various advantages over prior streaming solutions, such as continuous streaming quality throughout an entire video, continuous monitoring and alignment with device conditions, an improved opportunity to avoid abrupt power failure due to inefficient use of power during media content streaming, and an improved use of other streaming context information for optimal device performance and a streaming experience. The present technology can be applicable to mobile media content streaming (e.g., both live and on-demand media content streaming) applications, as well as broadcasting applications, in which the streaming environment (e.g., the network) can have limited bandwidth and the wireless devices are battery operated. As described in further detail below, the present technology can detect an amount of energy left in the device and accordingly select a bit rate to receive the streaming media content, as well as determine a burst size for receiving the streaming media content in order to improve power efficiency at the device.
The technology described herein presents various improvements in battery-constrained UEs and bandwidth-limited scenarios involving the UEs. For example, the DASH protocol can be extended to include the UE's battery information, video consumption information, a user's data plan status, user power preferences related to power consumption at the UE, etc. These power-related factors can aid a DASH client in the UE in determining which media content segments to fetch from a media content server. As a result, media content delivery can be optimized for power efficiency, thereby providing an extended battery life.
The technology described herein can improve the DASH protocol by adding device aware capabilities (e.g., battery level, power consumption for each video bitrate), the user's power preferences, and other media content characteristics in terms of quality level and length. A end-user device can extract real-time information on the device's battery level, the user's power consumption preference, and the video content being received from a multimedia server. In one example, the device can capture the user's power consumption preferences, obtain information on the video content from a media presentation description (MPD) file, and detect the battery level based on information received from operating system (OS) drivers in the device. In another example, the number of media content representations (at various bitrates) for the streaming media content can be extended or increased at the multimedia server based on the UE status (in terms of battery, screen size or user's consumption preference for instance). In addition, additional context information can be added in the MPD file for each of the media content representations, such as a video length, a quality level, etc.
In previous versions of the DASH protocol, a DASH client in the UE can select which media content segments are to be provided to the DASH client for playback at the UE. The DASH client can select the media content segments from a list of possible media content representations that are stored at a DASH server. The DASH client can select the media content segments according to a bitrate. In other words, the DASH client can select the bitrate according to an available network throughput, and then fetch the media content segments that correspond to the selected bitrate. In previous versions of the DASH protocol, the DASH client can select the highest bitrate for the media content segments in accordance with the available network throughput, thereby providing the best possible quality with respect to current network conditions. However, in previous versions of the DASH protocol, the DASH client does not select the media content download based on content quality and power efficiency at the UE, as described with the present technology.
The UE can select a streaming interval (e.g., in minutes or seconds). The streaming interval can be a predetermined value. Alternatively, the streaming interval can be a dynamic value based on network conditions and/or based on battery status information for the UE. The streaming interval can indicate how often the UE is to update (or determine to not update) a current representation of media content segments that are being received at the UE. The UE can determine the streaming interval using the power-related contextual information, such as a remaining battery level at the UE. As a non-limiting example, if the streaming interval is 30 seconds, then the UE can determine whether or not to switch to another representation every 30 seconds. Thus, after 30 seconds, the UE can select either a representation with a higher quality level (e.g., a higher bit rate), a representation with a lower quality level (e.g., a lower bit rate), or continue receiving the streaming media content at the current representation.
The UE, via a power modeling module within the UE, can model a current power consumption while the streaming media content is being received at the UE. The UE can calculate the amount of power to be consumed at the UE for receiving each representation of media content described in the MPD file. The UE can calculate the remaining amount of power in terms of the energy consumed per second for each video bitrate. The UE can calculate the power consumption levels using battery status information for the UE, such as a remaining level (e.g., 10% of the battery is left). The UE can calculate the power consumption levels using device context information, such as a model type associated with the UE and/or a display resolution of the UE. In addition, the UE can calculate the power consumption levels using media content details (e.g., segment quality information, available bitrates), as described in the MPD file.
As a non-limiting example, the UE can calculate power consumption levels for three separate representations of streaming media content. A first representation can be of low quality, the second representation can of medium quality, and the third representation can be of high quality. The UE can determine that 10 minutes of the streaming media content at the first representation can be received at the UE before a battery dies at the UE. The UE can determine that 30 minutes of the streaming media content at the second representation can be received at the UE before the battery dies at the UE. The UE can determine that 60 minutes of the streaming media content at the third representation can be received at the UE before the battery dies at the UE. The UE can calculate the power consumption levels for the three separate representations of streaming media content using a remaining battery level at the UE (e.g., 20% of the battery is left), a model type associated with the UE, and a display resolution or screen size of the UE.
The UE, via the power modeling module in the UE, can recommend a bit rate for streaming the media content (i.e., recommend at which representation to receive the streaming media content) using the power consumption levels, wherein the power consumption levels were previously calculated for each representation of the streaming media content using the battery status information and the bitrate associated with each representation of streaming media content. In addition, the UE can select the recommended bitrate for the streaming media content using the device context information, user-defined power preference information, and a remaining amount of time for the streaming media content (e.g., the movie that is currently being received has 5 more minutes until the movie is finished). The power preference information can indicate the user's UE power preference, such as a preference to receive streaming media content of a highest quality level (or bitrate), regardless of the remaining battery level at the UE. The power preference information can indicate that the user prefers a high quality level when the remaining battery level at the UE is high, but a low quality level when the remaining battery level at the UE is low in order to conserve energy at the UE. The power preference information can indicate that the user prefers to receive streaming media content at relatively low quality levels in order to maximize the period of streaming media content to be received at the UE per battery charge. The power preference information can indicate that the user prefers certain types of media content at a higher bitrate as compared to other types of media content. For example, the user can prefer watching sports at a relatively high quality level, but can watch comedy movies at a relatively low quality level.
Based on the power consumption level associated with each representation of streaming media content, the device context information, the user-defined power preferences, the remaining amount of time in the streaming media content, etc., the power modeling module in the UE can recommend at which bitrate to receive the streaming media content. The UE can use a combination of the factors described above. In addition, certain factors can be weighted more heavily as compared to other factors. For example, receiving media content at a highest possible bitrate can outweigh conserving battery power at the UE.
As a non-limiting example, the UE can select a relatively low bitrate when the UE has 5% battery life left and 20 more minutes until the streaming media content has finished. In particular, the UE can calculate at which bitrate to stream the media content, such that the media content finishes being streamed before the battery dies at the UE. In contrast, the UE can select a relatively high bitrate when the UE's battery is full.
In another example, the UE has 80% of battery life left and begins receiving a 2-hour video. The UE can select a highest possible bitrate, such that the entire 2-hour video can be received at the UE without the battery dying. In this example, the UE can compare various representations of the 2-hour video (e.g., to determine whether the 2-hour video can be completely received at the corresponding representation with respect to the remaining battery level) and select the representation that allows for the entire 2-hour video to be received at the highest possible bitrate.
As another non-limiting example, the UE can select a relatively low bitrate when a screen size of the UE is relatively small. In other words, selecting a higher bitrate can be futile on a smaller screen size, so in order to conserve battery power without a substantial perceived quality loss for a user, the UE can select the representation of the streaming media content at the relatively low bitrate. In other examples, the UE can select bitrates that correspond with the user's power preferences. In yet another example, the UE can select a bitrate based on the user's media content streaming plan. For example, the UE can select a higher bitrate when the user's media content streaming plan allows for a relatively large amount of data to be received at the UE over a network. In another example, the UE can select a relatively high bitrate when the battery level is full (e.g., at 100%), but periodically select lower bitrates as the streaming media content is being received and the battery level decreases. In yet another example, the UE can select the bitrate for the streaming media content in accordance with a quality level threshold defined by the user. In other words, the UE can select a lower bitrate based on the remaining battery level, but a quality level associated with the streaming media content can comply with the quality level threshold.
In one example, the power modeling module in the UE can recommend a certain representation of the streaming media content, as well as recommend a burst size for receiving the streaming media content with respect to efficient power utilization. The burst size can refer to a group of media content segments that can be simultaneously received at the UE. For example, the UE can receive 2 seconds of streaming media content in a single burst. As another example, the UE can receive 10 seconds of streaming media content in a single burst. In general, a larger burst of streaming media content can result in more efficient power utilization at the UE. In one example, the recommended burst size can be recommended based on available network conditions. Favorable network conditions can allow for the UE receiving larger bursts of streaming media content, as opposed to unfavorable network conditions.
The UE, via a rate adaptation module in the UE, can fetch the media content segments to be downloaded based on the recommended representation (or bitrate). In other words, the UE can fetch the media content segments based on the power-related contextual information, rather than choosing the highest possible bitrate that matches the channel throughput, as performed in past streaming solutions. In addition, the UE, via the rate adaptation module in the UE, can fetch the bursts of streaming media content based on the burst size recommended by the power modeling module in the UE. The media content segments can be fetched from a media content server and played at the UE. In accordance with the streaming interval (e.g., every 2 minutes), the power modeling module in the UE can recalculate a recommended representation and burst size, and the rate adaptation module in the UE can fetch the streaming media content in accordance with the recalculated recommended representation. In addition, the UE can monitor and estimate current download rates and report this information to other components (e.g., the power modeling module) in the UE. For example the power modeling module in the UE can select the recommended burst sizes based on the current download rates.
The UE, via a power modeling module within the UE, can model a current power consumption (or remaining battery life) while the streaming media content is being received at the UE. In one example, the relationship between power consumption and the media content streaming rate (i.e., the bitrate) can be represented by a logarithmic relationship: battery life=−a ln (b)+c, wherein a is a coefficient value between 0.5 and 0.6 (e.g., 0.5 for a full screen mode and 0.6 for a half screen mode), b is a video encoding bitrate (in Mbps), and c is a constant that varies with changes in the network bandwidth. In other words, the video encoding bitrate, the network bandwidth, screen size, etc. can affect the remaining amount of battery power in the UE. The values of a, b and c are device and network dependent, and can be initially determined based on device details (e.g., screen size, screen mode), network conditions, etc. After each streaming interval (e.g., power estimation iteration), the power consumption model can be updated with the actual power consumption for that streaming interval, which allows for fine tuning or adjustment of the a, b and c values.
As a non-limiting example, the UE can calculate the remaining battery life using the above equation if the UE is receiving streaming media content in a full screen mode and the bitrate of the streaming media content is relatively high. As another non-limiting example, the UE can calculate the remaining battery life using the above equation if the UE is receiving streaming media content in a half screen mode and the bitrate of the streaming media content is relatively low. For example, the UE can calculate 10 hours of remaining battery life if the streaming media content is received at a first representation, and 3 hours of remaining battery life if the streaming media content is received at a second representation.
In one example, the UE can, via a power modeling block at the UE, calculate the remaining battery life for various combinations of bitrates, full/half screen modes, network bandwidth changes, etc. In other words, the UE can compute the battery life per video bitrate (i.e., the energy for receiving the streaming media content at each bit rate). The UE can access information about the plurality of representations (or bitrates) for the streaming media content from the MPD file. In addition, the UE can receive device context information (e.g., the UE's screen size, the UE's model type), user power consumption preferences, battery status information (e.g., a percentage of remaining battery life), and a length of the streaming media content. Based on the above information, the UE can choose an appropriate representation (or bitrate) for receiving the streaming media content. The UE can choose an optimal streaming rate that guarantees streaming of the video until the end, as well as substantially similar streaming quality for the length of the video before the UE runs out of power. The UE can also choose the streaming rate using the user's preferences for video quality (in terms of a threshold for a video quality level). In addition, the UE can choose an optimal burst size (or segment size) at which the UE is to receive the media content segments. The UE can choose the burst size based on an available download rate. The UE can save additional power by turning on and off a radio interface in the UE between each burst of media content segments.
The recommended streaming bitrate and burst size can be provided to a rate adaptation block. In other words, the rate adaptation block can receive a recommended streaming rate, a recommended burst size, and segment quality information from the power modeling block in the UE. The rate adaptation block can fetch the media content segments at the recommended bitrate. In addition, the radio interface can be turned off after each burst of streaming media content is received and then turned back on before another burst of streaming media content is to be fetched from a media content server.
In one configuration, the UE can monitor and estimate current download rates and report this information to other components (e.g., the power modeling module) in the UE. For example the power modeling module in the UE can choose the recommended burst sizes based on the current download rates.
In one configuration, the size of an updated streaming interval can be determined based on the UE's power status information. The updated streaming interval can be used to reiterate the power consumption estimates and ensure that the power consumption estimates are accurate enough to achieve the goal of streaming the entire video or maintaining a steady quality throughout the streaming operation. The streaming interval can be initially set to 5 seconds, 10 seconds, 30 seconds, 1 minute, or 2 minutes, etc., and can dynamically vary thereafter. In other words, upon the completion of each streaming interval, the UE can recalculate the power consumption estimates and determine whether to switch to another bitrate. When battery conditions are good, a longer streaming interval can be selected. When battery conditions are poor, a shorter streaming interval can be recommended. After each streaming interval update, if there is a mismatch between the estimated power consumption and the actual power consumption (i.e., a mismatch that is above a defined threshold), then a shorter streaming interval can be preferred in order to provide improved adjustments to the power modeling parameters.
In one configuration, the UE can receive the recommended bitrate and the recommended burst size. The UE can filter segments within the representations subject to the recommended burst size. The UE can filter a set of segments that are to fill a recommended burst request size. The UE can run an optimization function to select the set of segments with a best overall quality within the available burst size, bit rate and below a defined quality level (which is defined by the UE's user). Information on the segment quality information can be used from the MPD file. The UE can request the selected segments in successive (or parallel) requests if possible. Once the requested segments are received at the UE, a radio interface at the UE can be temporarily switched off. At a later time, the radio interface at the UE can be switched back on.
Another example provides functionality 900 of circuitry of a user equipment (UE) operable to receive streaming media content, as shown in the flow chart in
In one example, the circuitry can be further configured to: select a burst size for receiving the streaming media content based on an available download rate at the UE; and fetch bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the UE. In addition, the circuitry can be further configured to switch off a radio interface at the UE between bursts of streaming media content that are received at the UE.
In one example, the circuitry can be further configured to select an updated media content representation upon transitioning to a subsequent streaming interval, the updated media content representation being selected based on updated power status information for the UE. In another example, the circuitry can be further configured to: increase the streaming interval when the power status information indicates that a remaining battery level for the UE is relatively high; or decrease the streaming interval when the power status information indicates that the remaining battery level for the UE is relatively low.
In one example, the circuitry can be further configured to select the media content representation from the plurality of media content representations based on a remaining amount of time for the streaming media content. In another example, the power status information for the UE includes a remaining battery level for the UE. In yet another example, the circuitry can be further configured to calculate the power consumption level for receiving the streamed media content at each of the plurality of media content representations based on at least one of: a model type associated with the UE or a display resolution of the UE.
In one example, the circuitry can be further configured to: receive power consumption preferences from a user associated with the UE; and select the media content representation from the plurality of media content representations based, in part, on the power consumption preferences. In another example, the circuitry can be further configured to select media content representations having relatively low quality levels or bitrates when the power status information indicates that a remaining battery level for the UE is below a defined threshold. In yet another example, the circuitry can be further configured to select media content representations having relatively high quality levels or bitrates when the power status information indicates that a remaining battery level for the UE is above a defined threshold.
In one example, each media content representation that is described in the MPD is associated with a defined bitrate. In another example, the circuitry can be further configured to receive the streaming media content over dynamic adaptive streaming over hypertext transfer protocol (DASH). In yet another example, the circuitry can be further configured to identify the power status information for the UE based on battery level information received from an operating system (OS) driver at the UE. In addition, the circuitry can be further configured to: identify a remaining amount of time for the streaming media content; identify a remaining battery level for the UE; and select the media content representation at a media content representation that ensures that the remaining amount of time for the streaming media content is received at the UE within the remaining battery level for the UE.
Another example provides functionality 1000 of circuitry of a user equipment (UE) operable to receive streaming media content, as shown in the flow chart in
In one example, the circuitry can be further configured to select a burst size for receiving the streaming media content based on an available download rate at the UE; and fetch bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the UE. In another example, the circuitry can be further configured to switch off a radio interface at the UE between the bursts of streaming media content at the selected burst size. In yet another example, the circuitry can be further configured to select a streaming interval for the streaming media content; and retrieve the streaming media content at the selected media content representation in accordance with the streaming interval to enable playback at the UE. In addition, the circuitry can be further configured to select an updated media content representation upon transitioning to a subsequent streaming interval, the updated media content representation being selected based on updated power status information for the UE.
Another example provides a method 1100 for receiving streaming media content, as shown in the flow chart in
In one example, the method can include the operations of selecting a burst size for receiving the streaming media content based on an available download rate at the UE; and fetching bursts of streaming media content at the selected media content representation according to the selected burst size in order to optimize power consumption at the UE. In addition, the method can include the operation of switching off a radio interface at the UE between bursts of streaming media content that are received at the UE.
Various techniques, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact disc-read-only memory (CD-ROMs), hard drives, non-transitory computer readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. Circuitry can include hardware, firmware, program code, executable code, computer instructions, and/or software. A non-transitory computer readable storage medium can be a computer readable storage medium that does not include signal. In the case of program code execution on programmable computers, the computing device can include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements can be a random-access memory (RAM), erasable programmable read only memory (EPROM), flash drive, optical drive, magnetic hard drive, solid state drive, or other medium for storing electronic data. The node and wireless device can also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or timer module (i.e., timer). One or more programs that can implement or utilize the various techniques described herein can use an application programming interface (API), reusable controls, and the like. Such programs can be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations.
It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
In one example, multiple hardware circuits can be used to implement the functional units described in this specification. For example, a first hardware circuit can be used to perform processing operations and a second hardware circuit (e.g., a transceiver) can be used to communicate with other entities. The first hardware circuit and the second hardware circuit can be integrated into a single hardware circuit, or alternatively, the first hardware circuit and the second hardware circuit can be separate hardware circuits.
Modules can also be implemented in software for execution by various types of processors. An identified module of executable code can, for instance, comprise one or more physical or logical blocks of computer instructions, which can, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but can comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code can be a single instruction, or many instructions, and can even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data can be identified and illustrated herein within modules, and can be embodied in any suitable form and organized within any suitable type of data structure. The operational data can be collected as a single data set, or can be distributed over different locations including over different storage devices, and can exist, at least partially, merely as electronic signals on a system or network. The modules can be passive or active, including agents operable to perform desired functions.
Reference throughout this specification to “an example” or “exemplary” means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in an example” or the word “exemplary” in various places throughout this specification are not necessarily all referring to the same embodiment.
As used herein, a plurality of items, structural elements, compositional elements, and/or materials can be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention can be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as defacto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.
Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.
Rehan, Mohamed M., Moustafa, Hassnaa, Liao, Yiting, Foerster, Jeffrey R., Badawi, Mohamed, Hassan, Yomna
| Patent | Priority | Assignee | Title |
| 10075824, | Jun 16 2016 | Alpine Electronics, Inc. | Electronic device, system, notification method, and notification program |
| 10212467, | Mar 19 2018 | AT&T Intellectual Property I, L.P.; AT&T Intellectual Property I, L P | Method and apparatus for streaming video |
| 10412132, | Feb 16 2015 | LG Electronics Inc | Broadcasting signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method |
| 10812848, | Mar 19 2018 | AT&T Intellectual Property I, L.P. | Method and apparatus for streaming video |
| 11134290, | Mar 19 2018 | AT&T Intellectual Property I, L.P. | Method and apparatus for streaming video |
| 11496784, | Mar 19 2018 | AT&T Intellectual Property I, L.P. | Method and apparatus for streaming video |
| Patent | Priority | Assignee | Title |
| 9432433, | Sep 22 2009 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
| 20070285311, | |||
| 20090180549, | |||
| 20130007223, | |||
| 20130094364, | |||
| 20130166580, | |||
| 20140019634, | |||
| 20140019635, | |||
| 20140136727, | |||
| 20140258552, | |||
| 20140317308, | |||
| 20140365556, | |||
| 20140380379, | |||
| 20150026358, | |||
| 20150100701, | |||
| 20150200986, | |||
| 20150271179, | |||
| 20160050246, | |||
| 20160080833, | |||
| WO2014063726, | |||
| WO2014138331, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Dec 24 2014 | Intel Corporation | (assignment on the face of the patent) | / | |||
| Jan 15 2015 | MOUSTAFA, HASSNAA | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035170 | /0669 | |
| Jan 16 2015 | LIAO, YITING | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035170 | /0669 | |
| Jan 19 2015 | BADAWI, MOHAMED | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035170 | /0669 | |
| Jan 20 2015 | REHAN, MOHAMED M | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035170 | /0669 | |
| Jan 20 2015 | HASSAN, YOMNA | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035170 | /0669 | |
| Jan 26 2015 | FOERSTER, JEFFREY R | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035170 | /0669 |
| Date | Maintenance Fee Events |
| Aug 23 2021 | REM: Maintenance Fee Reminder Mailed. |
| Feb 07 2022 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Jan 02 2021 | 4 years fee payment window open |
| Jul 02 2021 | 6 months grace period start (w surcharge) |
| Jan 02 2022 | patent expiry (for year 4) |
| Jan 02 2024 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jan 02 2025 | 8 years fee payment window open |
| Jul 02 2025 | 6 months grace period start (w surcharge) |
| Jan 02 2026 | patent expiry (for year 8) |
| Jan 02 2028 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jan 02 2029 | 12 years fee payment window open |
| Jul 02 2029 | 6 months grace period start (w surcharge) |
| Jan 02 2030 | patent expiry (for year 12) |
| Jan 02 2032 | 2 years to revive unintentionally abandoned end. (for year 12) |