US20140297869A1 - Adaptive streaming cost management - Google Patents
Adaptive streaming cost management Download PDFInfo
- Publication number
- US20140297869A1 US20140297869A1 US14/052,578 US201314052578A US2014297869A1 US 20140297869 A1 US20140297869 A1 US 20140297869A1 US 201314052578 A US201314052578 A US 201314052578A US 2014297869 A1 US2014297869 A1 US 2014297869A1
- Authority
- US
- United States
- Prior art keywords
- media
- slices
- performance
- source
- content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H04L65/607—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/52—Network services specially adapted for the location of the user terminal
Definitions
- the present disclosure relates to media streaming, and more particularly, to cost management for adaptive streaming.
- the Internet is becoming a primary method for distributing media content (e.g., video and audio or just audio or just video) and other information to end users. It is currently possible to download music, video, games and other media information to computers, cell phones, and virtually any network capable device.
- the percentage of people accessing the Internet for media content is growing rapidly.
- the quality of the viewer experience is a key barrier to the growth of video viewing on-line. Consumer expectations for online video are set by their television and movie viewing experiences.
- Streaming of data files or “streaming media” refers to technology that delivers sequential media content at a rate sufficient to present the media to a user at the originally anticipated playback speed without significant interruption. Unlike downloaded data of a media file, streamed data may be stored in memory until the data is played back and then subsequently deleted after a specified amount of time has passed.
- the process for preparing media content for adaptive streaming typically involves taking a source file, such as a movie, or a source feed, such as a broadcast signal, and splitting it into temporal slices (also referred to herein as chunks) or slices of media (e.g., video and audio), and encoding each slice of the media at different quality levels.
- temporal slices also referred to herein as chunks
- slices of media e.g., video and audio
- the different quality levels are achieved by encoding the media content at different bit rates according to encoding profiles.
- a consuming application selects a slice at one of the different quality levels that is best suited for the present network throughput, and the consuming applications adjusts the quality up or down as available bandwidth increases or decreases by selecting subsequent slices at the appropriate quality levels.
- Streaming media content over the Internet has some challenges, as compared to regular broadcasts over the air, satellite or cable.
- the adaptive streaming approach provides many advantages, one major disadvantage is that each temporal slice must be encoded multiple times, often a dozen or more, depending on the desired number of quality levels and playback devices or platforms. This requires some time and upfront resource costs.
- the computational resources required to encode into the multiple formats is often quite large, as is the necessary bandwidth required to move the encoded slices to their location on a web server from which they are served during playback.
- This encoding process also takes some time.
- there may be storage costs associated with storing multiple encodings of the media content For example, a content provider may have a very large library of media.
- the content provider When encoding the media for adaptive streaming, the content provider has to encode the media into the different quality levels and store the multiple copies of the media at the different quality levels for subsequent adaptive streaming to clients.
- the encoding and storage costs may be justified when the media is popular and is streamed to various clients. However, if the media is not popular, the encoding and storage of multiple copies of that media may not justify the associated cost. These costs for less popular media and even user-created content or user-uploaded content, may prevent content providers and some users from storing this media content online in a format for adaptive streaming.
- FIG. 1 is a block diagram of a network architecture in which embodiments of an adaptive streaming cost management system may operate.
- FIG. 2 illustrates client-based logic of an adaptive streaming cost management system according to embodiments.
- FIG. 3 is a flow diagram of a method of adaptive streaming cost management according to one embodiment.
- FIG. 4 illustrates a media manifest file of an adaptive streaming cost management system according to one embodiment.
- FIG. 5 illustrates server-based logic for generating a media manifest file of an adaptive streaming cost management system according to one embodiment.
- FIG. 6 is a flow diagram of a method of generating a media manifest file of an adaptive streaming cost management system according to one embodiment.
- FIG. 7 illustrates a diagrammatic representation of a machine in the example form of a computing system for adaptive streaming cost management.
- Adaptive video streaming divides a video stream into temporal slices and then encodes the slices at different quality levels, and there is a general correlation between audio/video quality and file size: the larger the size of the slice file, the higher the audio/video quality in the playback.
- higher quality media slices can be delivered and played. If the network is slower or deteriorates, lower quality media slices can be used in exchange for lower playback quality.
- CDNs Content Delivery Networks
- Level3 typically charge based on the amount of data transferred, such that higher quality media slices in adaptive streaming cost more than lower quality media slices since the higher quality slices are correspondingly larger files.
- bandwidth pricing can vary significantly throughout the world—some of the lowest rates are often found in well-connected, established markets in Europe and the United States, while bandwidth in more isolated or underdeveloped areas such as South America are often substantially higher.
- higher quality streaming's intrinsically higher cost due to file size is magnified if delivery of the video is to a relatively expensive region.
- the client side attempts to download media slices quickly enough to sustain playback so that playback is not interrupted, so it is often advantageous to deliver media from a server that is geographically (and network topologically) close to the user. For streaming playback, however, this tends to correspond to the costliest solution if the user is in a high-priced bandwidth region.
- a company in the United States delivering media to a user in Chile is faced with the decision between delivering the media from a server in the United States (where the cost will be the lowest but may impact performance due the latency) or delivering the media from a server in or near Chile (giving the best performance but at the highest cost).
- each media slice's various quality level is available for retrieval, and normally network conditions are the primary factor in deciding which quality level to use.
- the decision making process can be augmented to also take into account cost considerations, especially in scenarios when it is more likely that a higher quality slice would be used.
- a playback client in Chile with a playback buffer of 24 seconds could begin to transfer media slices from servers in the United States. Although the slices would transfer more slowly, the slower transfer would be covered by the buffer time while the slices are obtained at a lower rate or cost.
- Delivery costs may be incurred a user, such as by way of a subscription.
- the delivery costs can be charged against a user subscription.
- a user can have a subscription that provides a time-based (e.g., monthly) quota of data.
- the data can be charged against the user's quota.
- User's can also be charged on a per-use basis.
- Other mechanisms for charging users for delivery costs are myriad. Delivery costs can also be incurred to a content provider, the service provider, media publisher, etc.
- the cost consideration could still be used if the network connection is fast enough. For example, if the media slices are 8 seconds long and they can be transferred in 2 seconds from a server in Argentina to the user in Chile at a higher delivery cost, but transferring them from a server in the United States at a lower delivery cost takes 6 seconds per slice, transferring them from the United States is still feasible because the time to transfer the slice is less than the playback time of the slice. From the user's perspective they achieve the same playback quality, but the cost of delivery is significantly lower.
- Each delivery cost can be charged at a different rate. For example, a first delivery cost can be charged at a first rate and a second delivery cost can be charged at a second rate. Alternatively, the delivery cost can be identified and measured in terms of other metrics.
- Regional pricing differences are not the only scenario in which cost considerations can be useful. Another scenario would be the decision to transfer directly from a pool of origin storage servers directly or via a CDN.
- a CDN can be very helpful in distribution scalability because data is transferred from origin storage servers into the CDN, and then fanned out through a server hierarchy to many edge server locations throughout the world. For popular video content, for example, this allows the transfer of the media to hundreds of thousands or even millions of users.
- the content owner is typically billed for the transfer of data from the origin storage servers to the CDN, and then from the CDN edge locations to the users.
- the files are accessed frequently (such as in popular video content), they will be transferred from the origin storage servers only a few times and remained cached in CDN servers and delivered to users many times. For less popular content, however, the files may expire from the CDN caches frequently, such that the files have to be re-retrieved from the origin storage servers many times. In this scenario, the cost of delivery could become prohibitive. As before, however, cost could be taken into consideration when deciding the source location for transferring the files to users—if the content is not very popular, many of the media slices—especially the large, high quality media slices—could be delivered directly from a small pool of origin storage servers, skipping the delivery cost through the CDN. If the content rises in popularity, such that the media slices have a good probability of being cached in CDN servers, the delivery path could be shifted so that the slices are delivered from the origin storage servers to the CDN and then to the users.
- cost can be related to whether the client is subscribed to a particular service that has its own CDN.
- a mobile phone client can have access to a CDN of a mobile carrier at a reduced rate since the mobile phone client is subscribed to the mobile carrier.
- the client can use the CDN of the mobile carrier to obtain media slices.
- a service provider e.g., a mobile carrier
- the split data plan can include an amount of data that is a separate amount than media streaming.
- a client When a client operates in this type of data plan, it can determine whether it would be beneficial to download a set of media slice from a particular server such that it affects data or media usage under the plan in a different way. For example, a client can request media slices from a particular server that does not count against a media streaming maximum (e.g., a monthly quota).
- a media streaming maximum e.g., a monthly quota
- Some example approaches may include active client-side intelligence, as illustrated in FIGS. 1-3 .
- Other example approaches may include server-side intelligence that generates a media manifest file, as illustrated in FIGS. 4-7
- FIG. 1 is a block diagram of a network architecture 100 in which embodiments of an adaptive streaming cost management system may operate.
- Example architectures may include one or more client computing systems 102 and one or more cost management server computing systems 104 coupled via a data communications network 106 (e.g., public network such as the Internet or private network such as a local area network (LAN)).
- architecture 100 includes one or more media servers 108 a - c in different geographical locations that that can receive requests for media over the network 106 from a media player 110 executing on the client computing systems 102 .
- the network 106 may include the Internet and network connections to the Internet.
- cost management server 104 the media server 108 and the client 102 may be located on a common Local Area Network (LAN), Personal area network (PAN), Campus Area Network (CAN), Metropolitan area network (MAN), Wide area network (WAN), wireless local area network, cellular network, virtual local area network, or the like.
- the client 102 may be a client workstation, a server, a computer, a portable electronic device, an entertainment system configured to communicate over a network, such as a set-top box, a digital receiver, a digital television, a mobile phone, a smart phone, a tablet, or other electronic devices.
- portable electronic devices may include, but are not limited to, cellular phones, portable gaming systems, portable computing devices or the like.
- the client 102 may have access to the Internet via a firewall, a router or other packet switching devices.
- the cost management server computing system 104 and the media server 108 may be a network appliance, a gateway, a personal computer, a desktop computer, a workstation, etc.
- the cost management server computing system 104 may execute a manifest file generator 114 , which is configured to orchestrate a manifest file for adaptive streaming cost management, as described in further detail in conjunction with FIGS. 4-5 .
- the cost management server 104 can include web server functionality that receives requests for encoded media content over the network 106 from media players 110 executing on the client computing systems 102 .
- the functionality of the adaptive streaming cost management and the web server can be distributed over two or more cost management machines 104 (not shown).
- one cost management server computing system may host the manifest file generator and not a web server, and another cost management server computing system (not illustrated) can host a web server to handle requests for the media content.
- other configurations are possible as would be appreciated by one of ordinary skill in the art having the benefit of this disclosure.
- the architecture 100 also includes one or more content repositories, such as data storage devices, that are configured to communicate with one or more media servers 108 .
- the data storage devices may be content repositories in which encoded media content may be stored.
- a publisher or a distributor of media content may store the encoded media content in the data storage.
- Media content from the publisher may be transferred over the network to the media server 108 , which may be configured to receive, process, and store media content.
- the media server 108 delivers the media content to the client 102 , which is configured to play the content on a media player 110 that is operating on the client 102 .
- the media server 108 delivers the media content by streaming (e.g., adaptively streaming) the media content to the client 102 .
- the client 102 is configured to receive different portions or slices of the media content from multiple locations.
- media content from the media server 108 may be replicated to other locations and served to the clients 102 , such as by using web servers located on the network.
- proxy cache servers or edge servers can be used.
- the media content may be forwarded directly to the other web servers or proxy cache servers through direct communication channels without the need to traverse the Internet.
- the web servers, proxy cache servers, and media server 108 may be organized in a hierarchy of a CDN 116 to deliver the media content to the client 102 .
- a CDN 116 is a system of computers networked together across the Internet that cooperates transparently to deliver content.
- one media server 108 can be an origin content server.
- the CDN 116 may also include interconnected computer networks or nodes to deliver the media content.
- a publisher stores encoded media content in an original content file in the data storage to be distributed to one or more clients 102 .
- the content file may include data corresponding to video and/or audio corresponding to a television broadcast, sporting event, movie, music, concert or the like.
- the original content file may include uncompressed video and audio, or alternatively, uncompressed video or audio.
- the content file may include compressed content (e.g., video and/or audio) using standard or proprietary encoding schemes.
- the original content file from the publisher may be digital in form and may include media content having a high bit rate, such as, for example, 2 Mbps or greater.
- the media server 108 may receive the content file from the publisher.
- the media server 108 can decompress the content file (if encoded) into raw audio and/or video, segmenting the raw audio and/or video of the content file into multiple portions of the content (e.g., slices), and storing multiple copies of the content file in the data storage and among a plurality of servers 108 .
- the portions may have an equal duration, or alternatively, the portions may have equal file sizes, or vary one to another according to other requirements.
- each portion of the encoded media content may be retrieved, decoded and re-encoded into an encoded representation of that portion of the media content at the specified quality level.
- a media content file can be encoded into multiple encoded representations according to different quality profiles and stored as separate files that are independently requestable from the data storage via the cost management server 104 .
- the media player 110 on the client 102 can include a delivery cost module 112 to perform adaptive streaming cost management.
- the media player 110 can request media content from one or more cost management server 104 and can also request a media manifest file.
- the cost management server 104 in turn can transmit the media manifest file to the client 102 .
- the media manifest file can describe metadata for a video and could include information about different storage locations along with information about their relative costs, quality, priority, etc.
- the delivery cost module 112 then can use the data included in the media manifest file factors (e.g., geographical location, cost, quality, priority, etc.) when deciding to shift to a higher or lower bit rate, but it could also decide from which media server 108 to request media content or media slices from based on cost.
- the delivery cost module 112 could opt to request a subsequent media slice of the same quality from a slower and cheaper media server 108 .
- the delivery cost module 112 can use the manifest file to determine a media server 108 a to which the media player 110 can send a request for slices of media content for adaptive streaming.
- the delivery cost module 112 can determine a performance of the adaptive streaming of the media content from the media server 108 a .
- the media player 110 can request one or more subsequent slices from a second media server 108 b .
- the media player 110 can request one or more subsequent slices from the media server 108 a .
- the performance threshold can include a predetermined amount of slices of media in a playback buffer.
- the performance threshold can also include a minimum bit rate.
- the performance threshold can be defined based on various metrics used to measure performance of adaptive streaming.
- Some adaptive streaming implementations cannot be modified easily.
- an adaptive streaming implementation exists as part of the operating system and may be modified by third party applications. In these scenarios, cost can still be taken into consideration with some assistance by the server as described in conjunction with FIGS. 4-7 .
- the delivery cost module 112 can identify characteristics of the media servers 108 that it can use to determine where to request media slices.
- the delivery cost module 112 can submit requests to multiple media servers 108 and measure the response time for each server. If one media server 108 takes 200 ms to respond while another takes 50 ms, for example, the delivery cost module 112 can select to server with the shortest response time.
- the delivery cost module 112 can also determine other characteristics about the servers, such as average response rate, average bandwidth, average transfer time, average speed, server processor commitment, memory usage, number of requests a server handles per a unit of time (e.g., seconds) and a rolling average of any of the characteristics.
- the delivery cost module 112 can monitor server characteristics over time and build a server profile that the delivery cost module 112 can use when determining where to request media slices or files.
- the server can expose an Application Programming Interface (API) that the client can use to obtain server characteristics.
- API Application Programming Interface
- a server can permit a client to query a server for its server characteristics.
- actual server characteristics can be compared to threshold or expected server characteristics. For example, a number of requests a server handles per second can be compared against an expected capacity.
- the delivery cost module 112 can use this comparison when determining where to request media slices or files. For example, if a particular server is running at 90% load of a maximum threshold capacity, the delivery cost module 112 can factor this into decisions of where to request media slices or files.
- the delivery cost module 112 can also determine a cost associated with each server.
- the delivery cost module 112 can select the server with the lowest cost that can also provide a media slice or file within an acceptable response time. For example, if multiple servers can provide or stream a media slice or file faster than the client needs, the delivery cost module 112 can select the cheapest server from among those multiple servers.
- the cost management server 104 includes a content management system (CMS) that manages the encoded media content, for example, using a database stored in data storage.
- CMS is a computing system including a memory and a processing device coupled to the memory, the processing device to execute the manifest file generator 114 .
- the CMS may also manage the available encoded media content using one or more media manifest files.
- a publisher or server administrator can create media manifest files using the CMS. The media manifest files can be fetched by or pushed to the media player(s) 110 .
- a manifest file generator 114 (or server administrator) can create a media manifest file.
- the media manifest file can be fetched or pushed to the media player 110 .
- the computing architecture 100 may include other devices, such as directory servers, Digital Rights Management (DRM) servers, statistic servers, devices of a network infrastructure operator (e.g., an ISP), or the like.
- DRM Digital Rights Management
- ISP Internet Protocol Security
- the adaptive streaming cost management system 100 can include the cost management server 104 , delivery cost module 112 , manifest file generator 114 , or may include more or less components.
- FIG. 2 illustrates client-based logic of an adaptive streaming cost management system 200 according to embodiments.
- System 200 can include the media player 110 of FIG. 1 .
- the media player 110 has received four media slices 202 from region 204 , one of which has been played back, as indicated by the current playback position. Three media slices 202 remain in a playback buffer 214 .
- the media player 110 e.g., delivery cost module 112
- the media player 110 can request subsequent media slices that it may download while not affecting overall media playback.
- the media player 110 can determine whether to request media slice 210 a from region 204 or media slice 210 b from region 206 .
- the media player 110 can use the manifest file, as described herein, during this determination.
- queued media slices 202 to the right of the current playback position are 8 seconds each, which means that the media player has 24 seconds in which to request and obtain the next media slice 202 .
- the media player 110 can ascertain if a copy of the next media slice 202 can be obtained from a cheaper source, such as from region 206 .
- a cheaper source such as from region 206 .
- the media player 110 can request the media slice 210 b from region 206 to reduce overall costs of adaptive streaming.
- FIG. 3 is a flow diagram 300 of a method of adaptive streaming cost management according to one embodiment.
- the method 300 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computing system or a dedicated machine), firmware (embedded software), or any combination thereof.
- the delivery cost module 112 of FIG. 1 performs the method 300 .
- other components of the client computing system can perform some or all of the operations of method 300 .
- processing logic begins at block 302 by receiving a manifest file that identifies sources of slices of media content.
- a first media source can be located in a first geographical region and the second media source can be located in a second geographical region, as illustrated in the system 200 of FIG. 2 .
- Delivery of the slices of media content to the media player can incur a first delivery cost.
- processing logic requests slices of media content for playback on the media player from the first media source over a network using adaptive streaming.
- processing logic can determine, such as by using the manifest file, whether other sources of media content can deliver the same media slice at a lower cost. If no, then processing logic continues to request subsequent slices of media from the first source. If yes, then processing logic can determine a performance of the adaptive streaming during media content playback. If the performance is at or beyond a performance threshold at block 310 , then the processing logic can request a subsequent slice of media from the second source at a second cost. Delivery of the one or more subsequent slices to the media player from the second media source can incur a second delivery cost that is less than the first delivery cost. The method 300 can continue until the processing logic is no longer needs to request slices of the media.
- method 300 is one of many ways of using the determination of cheaper costs using the costs factors of the manifest file at the client device.
- the client can determine which quality of file to request for the slice and where to request the file using various factors as described herein.
- the method 300 may use the cost determination to create or modify an existing manifest to control where the files are requested based on cost as described herein.
- processing logic can send a playback request of the media content to a server device over the network.
- processing logic can receive a media manifest file from the server device over the network in response to the sending the playback request.
- processing logic can compare the performance against the performance threshold and select the second media source based on the comparison.
- FIG. 4 illustrates a media manifest file 400 of an adaptive streaming cost management system according to one embodiment.
- the media manifest file 400 can be a list or a table that includes information relating to one or more media slices.
- the media manifest file 400 includes media slices A-N, media sources A-N, costs A-N, quality A-N and URL A-N.
- Each of the sources, costs, qualities and URLs can be different. In implementations, some of these data are the same.
- source B and source C can have the same slice B, but at a different cost, quality and URL.
- a source e.g., source D
- includes multiple slices e.g., slices D-F). Any number of slices and corresponding data can be included in the media manifest file 400 .
- the media manifest file can include any data relating to adaptive streaming media slices, such as a geographical location, a delivery cost, a quality, a size, etc.
- the media manifest file can be used as a separate file than a metadata descriptor file that is used for adaptive streaming or can be integrated into the same file (i.e., the cost factors can be built into the existing data in the descriptor files).
- the media manifest file 400 is M3U file.
- a M3U file is a computer file format that stores multimedia playlists.
- a M3U file is a plain text file that specifies the locations one or more media files.
- Each line carriers on specification which can be an absolute local pathname, a local pathname relative to the M3U file location, or a URL (both absolute and relative URLs).
- the M3U file can also include comments, which are prefaced by the ‘#’ character. In extended M3U, the “#” character may also introduce extended directives.
- the Unicode version of M3U is M3U8, which uses UTF-8 Unicode characters.
- the media manifest file 400 can also specify multiple location choices, as well as the associated costs.
- the media manifest file 400 gives an overview of the content and is initially requested by a media player in order to know how to request specific files or data ranges within a file.
- a web server or media server can send transport stream files in response to the requests, however, the media content may be stored in one or multiple files. Regardless of how the media content is stored, the web server or media server can send the transport stream files with the corresponding slice of media content requested.
- the cost management server 104 or media server 108 may send the discrete file (encoded according to the appropriate quality profile) as the transport stream file in response to the request.
- an identifier and an offset may be used to retrieve the appropriate slice of the file (encoded according to the appropriate quality profile), and the cost management server 104 or media server 108 can send this slice as a transport stream file in response to the request.
- a M3U8 file 400 is created with the available quality profiles and where the media content at those profiles are located even though the media content at those different profiles do not exist at those locations.
- a media player such as media player 110 of FIG. 1 , reads the media manifest file for the media content that is being requested.
- the media manifest file 400 may also include a unique content identifier (UCID), duration of the media content, available quality profiles and locations of where the media content can be retrieved.
- UID unique content identifier
- the quality profiles may specify parameters, such as width and height of the image (i.e., image size), video bit rate (i.e., rate at which the video is encoded), audio bit rate, audio sample rate (i.e., rate at which the audio is sampled when captured), number of audio tracks (e.g., mono, stereo, or the like), frame rate (e.g., frame per second), staging size, or the like.
- the media players may individually request different quality levels of the same media content. Each media player may request the same portion (e.g., same time index) of the media content but at different quality levels.
- one media player may request a slice having HD quality video, since the computing device of the requesting media player has sufficient computational power and sufficient network bandwidth, while another media player may request a slice having a lower quality, since its computing device may not have sufficient network bandwidth, for example.
- the media player shifts between quality levels at the slice boundaries by requesting slices from different copies (e.g., different quality streams) of the media content.
- the media player can request the slices using other techniques that would be appreciated by those of ordinary skill in the art having the benefit of this disclosure.
- the media manifest file may also include other metadata, including, for example, air date of the content, title, actresses, actors, a start index, an end index, proprietary publisher data, encryption level, content duration, episode or program name, publisher; available tools for the end-user navigational environment, such as available menus, thumbnails, sidebars, advertising, fast-forward, rewind, pause, and play, or the like; or bit-rate values, including frame size, audio channel information, codecs, sample rate, and frame parser information.
- other metadata including, for example, air date of the content, title, actresses, actors, a start index, an end index, proprietary publisher data, encryption level, content duration, episode or program name, publisher; available tools for the end-user navigational environment, such as available menus, thumbnails, sidebars, advertising, fast-forward, rewind, pause, and play, or the like; or bit-rate values, including frame size, audio channel information, codecs, sample rate, and frame parser information.
- the media manifest file 400 identifies a first web address (e.g., URL) where the media content is located at the first media source and a second web address where the media content is located at the second media source.
- the media manifest file 400 also can identify a rule that a media player is to request the one or more subsequent slices from a second media server when the performance of the adaptive streaming is at or beyond the performance threshold.
- the media manifest can also include a rule to instruct a media player to request one or more media slices from a first media server when a performance of the adaptive streaming is above a performance threshold.
- the media manifest file can further identify a second web address where a copy of the plurality of media slices is geographically located at a second media server.
- the media manifest file can also identify a third web address where the media content is located at a third media source.
- the media manifest file can identify yet another rule that a media player is to request the one or more subsequent slices of media from the third media source when the performance is at or beyond a second performance threshold.
- the first performance threshold can be a first amount of time that a media player has been playing at a given bit rate.
- a media player can request and playback media slices from a first media server.
- the second performance threshold can be a second amount of time that a media player has been playing at the given bit rate.
- the media player can request media slices from a second media server at the same bit rate but with a lesser delivery cost.
- the media player can request media slices from a third source at the same bit rate but with a lesser delivery cost that the first and second media servers.
- the media manifest file can further identify another rule that instructs the media player to request the plurality of media slices from a second media server at a first quality level when the performance is at or beyond a second performance threshold, and from the second media server at a second quality level when the performance is below the second performance threshold.
- FIG. 5 illustrates server-based logic for generating a media manifest file of an adaptive streaming cost management system according to one embodiment.
- the cost management server 104 when the cost management server 104 receives a request for media content from a client 102 , the cost management server 104 obtains data from each media server (not shown) and uses the data from each media server to generate a media manifest file that is specific to the client 102 and to the requested media.
- the cost management server 104 when the cost management server 104 receives a request for a media metadata or media manifest file 400 from a client 102 , it could use standard geo-location libraries or services to determine the geographical location (e.g., country of origin) of the requesting client 102 .
- the cost management server 104 can then generate a media manifest file 400 by taking into account the relative distance (in terms of geography or network topology). For example, a server 502 in the US, upon determining that the client 102 is in Chile, could send back a media manifest file 400 that lists one or more Chilean servers 504 with lower quality levels with the smaller files and lists US servers 502 for higher quality levels with larger files. Because the higher quality slices can take longer to transfer (due to their larger file size) but also due to the higher latency, the cost management server 104 can optimize the user experience for the given network conditions, but can also manage costs for the content owner or publisher. In one embodiment, adaptive streaming cost management in the server 104 is implemented in a (CMS).
- CMS adaptive streaming cost management in the server 104 is implemented in a
- the adaptive streaming cost management can be implemented in other severs in the network.
- the media manifest file 400 could also be a static manifest file that sets the conditions based on parameters set by the designer.
- the server that manages media manifest file 400 can make these decisions at run time while receiving client requests for content.
- the cost management server 104 that generates and manages the media manifest file can use feedback, such as log files, server stats, quality of service (QoS) data, for determining the parameters of the media manifest file to strike a balance between the cost of adaptive streaming and the user's experience.
- QoS quality of service
- the adaptive streaming cost management can use various inputs to decide where to request the data.
- These various inputs can include the location of the client 102 , the latency in requests to the different locations (e.g., latency for requests for the file at that quality level from US based media servers and the latency for the file at the same or different quality level from the Chilean based media servers), amount of data in buffer 214 , current quality levels requested, previous historical data regarding the client's streaming performance, or the like.
- These inputs can be measured by the client 102 or the server 104 or can be provided by other systems.
- the client 102 can submit a request for a media slice or file directly to a media server.
- the media server can respond, such as with at least a portion of the requested media slice or file.
- the client 102 can measure the time it takes for the media server to respond and can use the response time to determine whether to request subsequent media slices from that server.
- FIG. 6 is a flow diagram of a method 600 of generating a media manifest file of an adaptive streaming cost management system according to one embodiment.
- the method 600 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computing system or a dedicated machine), firmware (embedded software), or any combination thereof.
- the server-side logic of FIG. 5 performs the method 600 .
- other components of the client computing system, server computing system or both can perform some or all of the operations of method 600 .
- processing logic begins with receiving a request from a media player executing on a client device to adaptively stream media content at block 602 .
- the media content can include multiple media slices.
- processing logic identifies a geographical location of the client device from the request. Identifying the geographical location of the client device can include extracting data from the request and sending a geographical location request with the extracted data from a location service to determine a geographical region of origin of the client device.
- processing logic generates a media manifest file based on the geographical location of the client device.
- the media manifest file such as the media manifest file 400 of FIG. 4 , can indicate one or more media sources at which a copy of the plurality of media slices is geographically located and a cost associated with delivery of the plurality of media slices from the respective one of the one or more media sources.
- processing logic transmits the media manifest file to the client device over the network.
- FIG. 7 illustrates a diagrammatic representation of a machine in the exemplary form of a computing system for adaptive streaming cost management.
- the computing system 700 is a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein.
- the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet.
- the machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a PC, a tablet PC, a set-top-box (STB), a personal data assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein for adaptive streaming cost management, such as the method 300 described above.
- the computing system 700 represents various components that may be implemented in the server computing system 106 as described above.
- the server computing system 106 may include more or less components as illustrated in the computing system 700 .
- the exemplary computing system 700 includes a processing device 702 , a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), a static memory 706 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 716 , each of which communicate with each other via a bus 730 .
- main memory 704 e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.
- DRAM dynamic random access memory
- SDRAM synchronous DRAM
- static memory 706 e.g., flash memory, static random access memory (SRAM), etc.
- SRAM static random access memory
- Processing device 702 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 702 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets.
- the processing device 702 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like.
- the processing device 702 is configured to execute the processing logic (e.g., adaptive streaming cost management 726 , media manifest file generation 726 ) for performing the operations and steps discussed herein.
- processing logic e.g., adaptive streaming cost management 726 , media manifest file generation 726
- the computing system 700 may further include a network interface device 722 .
- the computing system 700 also may include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), and a signal generation device 720 (e.g., a speaker).
- a video display unit 710 e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)
- an alphanumeric input device 712 e.g., a keyboard
- a cursor control device 714 e.g., a mouse
- a signal generation device 720 e.g., a speaker
- the data storage device 716 may include a computer-readable storage medium 724 on which is stored one or more sets of instructions (e.g., adaptive streaming cost management 726 , media manifest file generation 726 ) embodying any one or more of the methodologies or functions described herein.
- the adaptive streaming cost management 726 and media manifest file generation 726 may also reside, completely or at least partially, within the main memory 704 and/or within the processing device 702 during execution thereof by the computing system 700 , the main memory 704 and the processing device 702 also constituting computer-readable storage media.
- the adaptive streaming cost management 726 may further be transmitted or received over a network via the network interface device 722 .
- While the computer-readable storage medium 724 is shown in an exemplary embodiment to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
- the term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present embodiments.
- the term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, magnetic media or other types of mediums for storing the instructions.
- the term “computer-readable transmission medium” shall be taken to include any medium that is capable of transmitting a set of instructions for execution by the machine to cause the machine to perform any one or more of the methodologies of the present embodiments.
- the adaptive streaming cost management module (e.g., deliver cost module) 732 , and the media manifest file generation module 734 , components, and other features described herein can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs, or similar devices.
- the adaptive streaming cost management module 732 may implement operations of adaptive streaming cost management as described herein.
- the media manifest file generation module 734 may implement operations of media manifest file generation as described herein
- the adaptive streaming cost management module 732 and the media manifest file generation module 734 can be implemented as firmware or functional circuitry within hardware devices. Further, the adaptive streaming cost management module 732 and the media manifest file generation module 734 can be implemented in any combination hardware devices and software components.
- Embodiments of the present invention also relate to an apparatus for performing the operations herein.
- This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing system specifically programmed by a computer program stored in the computing system.
- a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.
Abstract
Description
- This application claims the benefit of U.S. Provisional Application No. 61/712,657, filed Oct. 11, 2012, the entire contents of which are incorporated herein by reference. This application is related to co-pending U.S. Ser. No. [to be determined], Attorney Docket No. 09174.14 (L0014), filed concurrently with the present application. The entire contents of which are incorporated by reference.
- The present disclosure relates to media streaming, and more particularly, to cost management for adaptive streaming.
- The Internet is becoming a primary method for distributing media content (e.g., video and audio or just audio or just video) and other information to end users. It is currently possible to download music, video, games and other media information to computers, cell phones, and virtually any network capable device. The percentage of people accessing the Internet for media content is growing rapidly. The quality of the viewer experience is a key barrier to the growth of video viewing on-line. Consumer expectations for online video are set by their television and movie viewing experiences.
- Audience numbers for streaming video on the web are rapidly growing, and there are a growing interest and demand for viewing video on the Internet. Streaming of data files or “streaming media” refers to technology that delivers sequential media content at a rate sufficient to present the media to a user at the originally anticipated playback speed without significant interruption. Unlike downloaded data of a media file, streamed data may be stored in memory until the data is played back and then subsequently deleted after a specified amount of time has passed.
- The process for preparing media content for adaptive streaming typically involves taking a source file, such as a movie, or a source feed, such as a broadcast signal, and splitting it into temporal slices (also referred to herein as chunks) or slices of media (e.g., video and audio), and encoding each slice of the media at different quality levels. Typically, the different quality levels are achieved by encoding the media content at different bit rates according to encoding profiles. During playback, and as network conditions fluctuate, a consuming application selects a slice at one of the different quality levels that is best suited for the present network throughput, and the consuming applications adjusts the quality up or down as available bandwidth increases or decreases by selecting subsequent slices at the appropriate quality levels.
- Streaming media content over the Internet has some challenges, as compared to regular broadcasts over the air, satellite or cable. Although the adaptive streaming approach provides many advantages, one major disadvantage is that each temporal slice must be encoded multiple times, often a dozen or more, depending on the desired number of quality levels and playback devices or platforms. This requires some time and upfront resource costs. In particular, the computational resources required to encode into the multiple formats is often quite large, as is the necessary bandwidth required to move the encoded slices to their location on a web server from which they are served during playback. This encoding process also takes some time. Also, there may be storage costs associated with storing multiple encodings of the media content. For example, a content provider may have a very large library of media. When encoding the media for adaptive streaming, the content provider has to encode the media into the different quality levels and store the multiple copies of the media at the different quality levels for subsequent adaptive streaming to clients. The encoding and storage costs may be justified when the media is popular and is streamed to various clients. However, if the media is not popular, the encoding and storage of multiple copies of that media may not justify the associated cost. These costs for less popular media and even user-created content or user-uploaded content, may prevent content providers and some users from storing this media content online in a format for adaptive streaming.
- The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that different references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
-
FIG. 1 is a block diagram of a network architecture in which embodiments of an adaptive streaming cost management system may operate. -
FIG. 2 illustrates client-based logic of an adaptive streaming cost management system according to embodiments. -
FIG. 3 is a flow diagram of a method of adaptive streaming cost management according to one embodiment. -
FIG. 4 illustrates a media manifest file of an adaptive streaming cost management system according to one embodiment. -
FIG. 5 illustrates server-based logic for generating a media manifest file of an adaptive streaming cost management system according to one embodiment. -
FIG. 6 is a flow diagram of a method of generating a media manifest file of an adaptive streaming cost management system according to one embodiment. -
FIG. 7 illustrates a diagrammatic representation of a machine in the example form of a computing system for adaptive streaming cost management. - Methods and systems for adaptive streaming cost management are described. In the following description, numerous details are set forth. It will be apparent, however, to one of ordinary skill in the art having the benefit of this disclosure, that embodiments of the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments of the present invention.
- Adaptive video streaming divides a video stream into temporal slices and then encodes the slices at different quality levels, and there is a general correlation between audio/video quality and file size: the larger the size of the slice file, the higher the audio/video quality in the playback. During playback, if network conditions are good enough, higher quality media slices can be delivered and played. If the network is slower or deteriorates, lower quality media slices can be used in exchange for lower playback quality.
- Internet bandwidth providers such as Content Delivery Networks (CDNs) like Akamai or Level3 typically charge based on the amount of data transferred, such that higher quality media slices in adaptive streaming cost more than lower quality media slices since the higher quality slices are correspondingly larger files. Further, bandwidth pricing can vary significantly throughout the world—some of the lowest rates are often found in well-connected, established markets in Europe and the United States, while bandwidth in more isolated or underdeveloped areas such as South America are often substantially higher. Thus, higher quality streaming's intrinsically higher cost due to file size is magnified if delivery of the video is to a relatively expensive region.
- When transferring data between two computers, the distance between them affects the time it takes to transfer the data due to messaging latency from the number of “hops” or intermediate network connections the data passes through, the amount of competing network traffic that can cause congestion, and the physical limits of transferring data electronically. During streaming playback, the client side attempts to download media slices quickly enough to sustain playback so that playback is not interrupted, so it is often advantageous to deliver media from a server that is geographically (and network topologically) close to the user. For streaming playback, however, this tends to correspond to the costliest solution if the user is in a high-priced bandwidth region. For example, a company in the United States delivering media to a user in Chile is faced with the decision between delivering the media from a server in the United States (where the cost will be the lowest but may impact performance due the latency) or delivering the media from a server in or near Chile (giving the best performance but at the highest cost).
- The sliced-media nature of adaptive streaming presents an opportunity to find a middle ground that balances speed/performance and cost. During playback, each media slice's various quality level is available for retrieval, and normally network conditions are the primary factor in deciding which quality level to use. The decision making process can be augmented to also take into account cost considerations, especially in scenarios when it is more likely that a higher quality slice would be used.
- On a high-speed internet connection, it is common for adaptive streaming players to not only be able to download successive media slices quickly enough, but to also be able to download additional, future slices ahead of when they are needed, creating a buffer. Normally this buffer helps protect against variability in network conditions so that playback does not jump between quality levels too often, creating an uneven user experience. For example, if media slices are 8 seconds long and a client has 3 extra slices buffered already, in theory the client could take up to 24 seconds (3 slice*8 seconds) to download the next slice without shifting to a lower quality with smaller slice files. If transmission costs are taken into account, that buffer could also be used as a chance to retrieve a slice from a slower but cheaper storage location. Continuing the previous example, a playback client in Chile with a playback buffer of 24 seconds could begin to transfer media slices from servers in the United States. Although the slices would transfer more slowly, the slower transfer would be covered by the buffer time while the slices are obtained at a lower rate or cost.
- Delivery costs may be incurred a user, such as by way of a subscription. In implementations, the delivery costs can be charged against a user subscription. For example, a user can have a subscription that provides a time-based (e.g., monthly) quota of data. When the user streams content, the data can be charged against the user's quota. User's can also be charged on a per-use basis. Other mechanisms for charging users for delivery costs are myriad. Delivery costs can also be incurred to a content provider, the service provider, media publisher, etc.
- Even in the event of little or no buffer, the cost consideration could still be used if the network connection is fast enough. For example, if the media slices are 8 seconds long and they can be transferred in 2 seconds from a server in Argentina to the user in Chile at a higher delivery cost, but transferring them from a server in the United States at a lower delivery cost takes 6 seconds per slice, transferring them from the United States is still feasible because the time to transfer the slice is less than the playback time of the slice. From the user's perspective they achieve the same playback quality, but the cost of delivery is significantly lower. Each delivery cost can be charged at a different rate. For example, a first delivery cost can be charged at a first rate and a second delivery cost can be charged at a second rate. Alternatively, the delivery cost can be identified and measured in terms of other metrics.
- Regional pricing differences are not the only scenario in which cost considerations can be useful. Another scenario would be the decision to transfer directly from a pool of origin storage servers directly or via a CDN. A CDN can be very helpful in distribution scalability because data is transferred from origin storage servers into the CDN, and then fanned out through a server hierarchy to many edge server locations throughout the world. For popular video content, for example, this allows the transfer of the media to hundreds of thousands or even millions of users. In terms of costs, the content owner is typically billed for the transfer of data from the origin storage servers to the CDN, and then from the CDN edge locations to the users. If the files are accessed frequently (such as in popular video content), they will be transferred from the origin storage servers only a few times and remained cached in CDN servers and delivered to users many times. For less popular content, however, the files may expire from the CDN caches frequently, such that the files have to be re-retrieved from the origin storage servers many times. In this scenario, the cost of delivery could become prohibitive. As before, however, cost could be taken into consideration when deciding the source location for transferring the files to users—if the content is not very popular, many of the media slices—especially the large, high quality media slices—could be delivered directly from a small pool of origin storage servers, skipping the delivery cost through the CDN. If the content rises in popularity, such that the media slices have a good probability of being cached in CDN servers, the delivery path could be shifted so that the slices are delivered from the origin storage servers to the CDN and then to the users.
- In some implementations, cost can be related to whether the client is subscribed to a particular service that has its own CDN. For example, a mobile phone client can have access to a CDN of a mobile carrier at a reduced rate since the mobile phone client is subscribed to the mobile carrier. When a client is using the CDN infrastructure of the mobile carrier, the client can use the CDN of the mobile carrier to obtain media slices. In other implementations, a service provider (e.g., a mobile carrier) offers a split data plan that distinguishes between different types of data when determining allowable consumption. For example, the split data plan can include an amount of data that is a separate amount than media streaming. When a client operates in this type of data plan, it can determine whether it would be beneficial to download a set of media slice from a particular server such that it affects data or media usage under the plan in a different way. For example, a client can request media slices from a particular server that does not count against a media streaming maximum (e.g., a monthly quota).
- A number of different methods exist for taking cost into consideration in adaptive streaming. Some example approaches may include active client-side intelligence, as illustrated in
FIGS. 1-3 . Other example approaches may include server-side intelligence that generates a media manifest file, as illustrated inFIGS. 4-7 -
FIG. 1 is a block diagram of anetwork architecture 100 in which embodiments of an adaptive streaming cost management system may operate. Example architectures may include one or moreclient computing systems 102 and one or more cost managementserver computing systems 104 coupled via a data communications network 106 (e.g., public network such as the Internet or private network such as a local area network (LAN)). In embodiments,architecture 100 includes one or more media servers 108 a-c in different geographical locations that that can receive requests for media over thenetwork 106 from amedia player 110 executing on theclient computing systems 102. Thenetwork 106 may include the Internet and network connections to the Internet. Alternatively,cost management server 104, the media server 108 and theclient 102 may be located on a common Local Area Network (LAN), Personal area network (PAN), Campus Area Network (CAN), Metropolitan area network (MAN), Wide area network (WAN), wireless local area network, cellular network, virtual local area network, or the like. Theclient 102 may be a client workstation, a server, a computer, a portable electronic device, an entertainment system configured to communicate over a network, such as a set-top box, a digital receiver, a digital television, a mobile phone, a smart phone, a tablet, or other electronic devices. For example, portable electronic devices may include, but are not limited to, cellular phones, portable gaming systems, portable computing devices or the like. Theclient 102 may have access to the Internet via a firewall, a router or other packet switching devices. The cost managementserver computing system 104 and the media server 108 may be a network appliance, a gateway, a personal computer, a desktop computer, a workstation, etc. - In the depicted embodiment, the cost management
server computing system 104 may execute amanifest file generator 114, which is configured to orchestrate a manifest file for adaptive streaming cost management, as described in further detail in conjunction withFIGS. 4-5 . Thecost management server 104 can include web server functionality that receives requests for encoded media content over thenetwork 106 frommedia players 110 executing on theclient computing systems 102. Alternatively, the functionality of the adaptive streaming cost management and the web server can be distributed over two or more cost management machines 104 (not shown). For example, in one embodiment, one cost management server computing system may host the manifest file generator and not a web server, and another cost management server computing system (not illustrated) can host a web server to handle requests for the media content. Alternatively, other configurations are possible as would be appreciated by one of ordinary skill in the art having the benefit of this disclosure. - In one embodiment, the
architecture 100 also includes one or more content repositories, such as data storage devices, that are configured to communicate with one or more media servers 108. The data storage devices may be content repositories in which encoded media content may be stored. A publisher or a distributor of media content may store the encoded media content in the data storage. Media content from the publisher may be transferred over the network to the media server 108, which may be configured to receive, process, and store media content. In one embodiment, the media server 108 delivers the media content to theclient 102, which is configured to play the content on amedia player 110 that is operating on theclient 102. The media server 108 delivers the media content by streaming (e.g., adaptively streaming) the media content to theclient 102. In a further embodiment, theclient 102 is configured to receive different portions or slices of the media content from multiple locations. - In other embodiments, media content from the media server 108 may be replicated to other locations and served to the
clients 102, such as by using web servers located on the network. Alternatively, proxy cache servers or edge servers can be used. In a further embodiment, the media content may be forwarded directly to the other web servers or proxy cache servers through direct communication channels without the need to traverse the Internet. In another embodiment, the web servers, proxy cache servers, and media server 108 may be organized in a hierarchy of a CDN 116 to deliver the media content to theclient 102. As described above, a CDN 116 is a system of computers networked together across the Internet that cooperates transparently to deliver content. In this embodiment, one media server 108 can be an origin content server. The CDN 116 may also include interconnected computer networks or nodes to deliver the media content. - In one embodiment, a publisher stores encoded media content in an original content file in the data storage to be distributed to one or
more clients 102. The content file may include data corresponding to video and/or audio corresponding to a television broadcast, sporting event, movie, music, concert or the like. The original content file may include uncompressed video and audio, or alternatively, uncompressed video or audio. Alternatively, the content file may include compressed content (e.g., video and/or audio) using standard or proprietary encoding schemes. The original content file from the publisher may be digital in form and may include media content having a high bit rate, such as, for example, 2 Mbps or greater. - The media server 108 may receive the content file from the publisher. The media server 108 can decompress the content file (if encoded) into raw audio and/or video, segmenting the raw audio and/or video of the content file into multiple portions of the content (e.g., slices), and storing multiple copies of the content file in the data storage and among a plurality of servers 108. The portions may have an equal duration, or alternatively, the portions may have equal file sizes, or vary one to another according to other requirements. During operation, as describe in more detail below, each portion of the encoded media content may be retrieved, decoded and re-encoded into an encoded representation of that portion of the media content at the specified quality level. Typically, in adaptive streaming, a media content file can be encoded into multiple encoded representations according to different quality profiles and stored as separate files that are independently requestable from the data storage via the
cost management server 104. - The
media player 110 on theclient 102 can include adelivery cost module 112 to perform adaptive streaming cost management. Themedia player 110 can request media content from one or morecost management server 104 and can also request a media manifest file. Thecost management server 104 in turn can transmit the media manifest file to theclient 102. For example, the media manifest file can describe metadata for a video and could include information about different storage locations along with information about their relative costs, quality, priority, etc. Thedelivery cost module 112 then can use the data included in the media manifest file factors (e.g., geographical location, cost, quality, priority, etc.) when deciding to shift to a higher or lower bit rate, but it could also decide from which media server 108 to request media content or media slices from based on cost. If thedelivery cost module 112 determined that it had a sufficiently large amount of data in a playback buffer or that it could risk a possibly slower slice file transfer, it could opt to request a subsequent media slice of the same quality from a slower and cheaper media server 108. For example, thedelivery cost module 112 can use the manifest file to determine amedia server 108 a to which themedia player 110 can send a request for slices of media content for adaptive streaming. Thedelivery cost module 112 can determine a performance of the adaptive streaming of the media content from themedia server 108 a. When the adaptivedelivery cost module 112 determines that the performance of the adaptive streaming is at or beyond a performance threshold, themedia player 110 can request one or more subsequent slices from asecond media server 108 b. When thedelivery cost module 112 determines that the performance of the adaptive streaming is below a performance threshold, themedia player 110 can request one or more subsequent slices from themedia server 108 a. The performance threshold can include a predetermined amount of slices of media in a playback buffer. The performance threshold can also include a minimum bit rate. Alternatively, the performance threshold can be defined based on various metrics used to measure performance of adaptive streaming. - Some adaptive streaming implementations cannot be modified easily. For example, in the Apple iOS platform and the Google Android platform, an adaptive streaming implementation exists as part of the operating system and may be modified by third party applications. In these scenarios, cost can still be taken into consideration with some assistance by the server as described in conjunction with
FIGS. 4-7 . - In implementations, the
delivery cost module 112 can identify characteristics of the media servers 108 that it can use to determine where to request media slices. Thedelivery cost module 112 can submit requests to multiple media servers 108 and measure the response time for each server. If one media server 108 takes 200 ms to respond while another takes 50 ms, for example, thedelivery cost module 112 can select to server with the shortest response time. Thedelivery cost module 112 can also determine other characteristics about the servers, such as average response rate, average bandwidth, average transfer time, average speed, server processor commitment, memory usage, number of requests a server handles per a unit of time (e.g., seconds) and a rolling average of any of the characteristics. Thedelivery cost module 112 can monitor server characteristics over time and build a server profile that thedelivery cost module 112 can use when determining where to request media slices or files. In some implementations, the server can expose an Application Programming Interface (API) that the client can use to obtain server characteristics. In implementations, a server can permit a client to query a server for its server characteristics. In implementation, actual server characteristics can be compared to threshold or expected server characteristics. For example, a number of requests a server handles per second can be compared against an expected capacity. Thedelivery cost module 112 can use this comparison when determining where to request media slices or files. For example, if a particular server is running at 90% load of a maximum threshold capacity, thedelivery cost module 112 can factor this into decisions of where to request media slices or files. - In some implementations, the
delivery cost module 112 can also determine a cost associated with each server. Thedelivery cost module 112 can select the server with the lowest cost that can also provide a media slice or file within an acceptable response time. For example, if multiple servers can provide or stream a media slice or file faster than the client needs, thedelivery cost module 112 can select the cheapest server from among those multiple servers. - In some embodiments, the
cost management server 104 includes a content management system (CMS) that manages the encoded media content, for example, using a database stored in data storage. In one embodiment, the CMS is a computing system including a memory and a processing device coupled to the memory, the processing device to execute themanifest file generator 114. The CMS may also manage the available encoded media content using one or more media manifest files. In an embodiment, a publisher (or server administrator) can create media manifest files using the CMS. The media manifest files can be fetched by or pushed to the media player(s) 110. - The cost of network bandwidth can vary significantly in different parts of the world. Traditionally the cost differences have been very challenging to content owners, forcing content owners to risk high costs or to artificially limit the quality of media streamed to developing markets or remote locations. Adaptive streaming solutions that divide the media into slices, however, give content providers the opportunity to provide high quality experiences for consumers of media while still having some control over their costs.
- In the depicted embodiment, a manifest file generator 114 (or server administrator) can create a media manifest file. The media manifest file can be fetched or pushed to the
media player 110. - In other embodiments, the
computing architecture 100 may include other devices, such as directory servers, Digital Rights Management (DRM) servers, statistic servers, devices of a network infrastructure operator (e.g., an ISP), or the like. - The adaptive streaming
cost management system 100 can include thecost management server 104,delivery cost module 112,manifest file generator 114, or may include more or less components. -
FIG. 2 illustrates client-based logic of an adaptive streaming cost management system 200 according to embodiments. System 200 can include themedia player 110 ofFIG. 1 . As illustrated, themedia player 110 has received fourmedia slices 202 fromregion 204, one of which has been played back, as indicated by the current playback position. Threemedia slices 202 remain in aplayback buffer 214. The media player 110 (e.g., delivery cost module 112) can request subsequent media slices that it may download while not affecting overall media playback. Themedia player 110 can determine whether to request media slice 210 a fromregion 204 or media slice 210 b fromregion 206. Themedia player 110 can use the manifest file, as described herein, during this determination. For example, queuedmedia slices 202 to the right of the current playback position are 8 seconds each, which means that the media player has 24 seconds in which to request and obtain thenext media slice 202. Using the manifest file, themedia player 110 can ascertain if a copy of thenext media slice 202 can be obtained from a cheaper source, such as fromregion 206. In the example, if media slice 210 a could be obtained within 3 seconds fromregion 204 and media slice 210 b could be obtained within 6 seconds fromregion 206 at a lesser cost, themedia player 110 can request themedia slice 210 b fromregion 206 to reduce overall costs of adaptive streaming. -
FIG. 3 is a flow diagram 300 of a method of adaptive streaming cost management according to one embodiment. Themethod 300 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computing system or a dedicated machine), firmware (embedded software), or any combination thereof. In one embodiment, thedelivery cost module 112 ofFIG. 1 performs themethod 300. Alternatively, other components of the client computing system can perform some or all of the operations ofmethod 300. - Referring to
FIG. 3 , processing logic begins atblock 302 by receiving a manifest file that identifies sources of slices of media content. A first media source can be located in a first geographical region and the second media source can be located in a second geographical region, as illustrated in the system 200 ofFIG. 2 . Delivery of the slices of media content to the media player can incur a first delivery cost. - At
block 304, processing logic requests slices of media content for playback on the media player from the first media source over a network using adaptive streaming. - At
block 306, processing logic can determine, such as by using the manifest file, whether other sources of media content can deliver the same media slice at a lower cost. If no, then processing logic continues to request subsequent slices of media from the first source. If yes, then processing logic can determine a performance of the adaptive streaming during media content playback. If the performance is at or beyond a performance threshold atblock 310, then the processing logic can request a subsequent slice of media from the second source at a second cost. Delivery of the one or more subsequent slices to the media player from the second media source can incur a second delivery cost that is less than the first delivery cost. Themethod 300 can continue until the processing logic is no longer needs to request slices of the media. - Of course,
method 300 is one of many ways of using the determination of cheaper costs using the costs factors of the manifest file at the client device. In other embodiments, the client can determine which quality of file to request for the slice and where to request the file using various factors as described herein. Similarly, when implemented on the server, themethod 300 may use the cost determination to create or modify an existing manifest to control where the files are requested based on cost as described herein. - In some implementations, before
block 302, processing logic can send a playback request of the media content to a server device over the network. In some implementations, processing logic can receive a media manifest file from the server device over the network in response to the sending the playback request. In other implementations where the media manifest file identifies the performance threshold, processing logic can compare the performance against the performance threshold and select the second media source based on the comparison. -
FIG. 4 illustrates amedia manifest file 400 of an adaptive streaming cost management system according to one embodiment. Themedia manifest file 400 can be a list or a table that includes information relating to one or more media slices. As illustrated, themedia manifest file 400 includes media slices A-N, media sources A-N, costs A-N, quality A-N and URL A-N. Each of the sources, costs, qualities and URLs can be different. In implementations, some of these data are the same. For example, source B and source C can have the same slice B, but at a different cost, quality and URL. In another example, a source (e.g., source D) includes multiple slices (e.g., slices D-F). Any number of slices and corresponding data can be included in themedia manifest file 400. The media manifest file can include any data relating to adaptive streaming media slices, such as a geographical location, a delivery cost, a quality, a size, etc. The media manifest file can be used as a separate file than a metadata descriptor file that is used for adaptive streaming or can be integrated into the same file (i.e., the cost factors can be built into the existing data in the descriptor files). - In one embodiment, the
media manifest file 400 is M3U file. A M3U file is a computer file format that stores multimedia playlists. Typically, a M3U file is a plain text file that specifies the locations one or more media files. Each line carriers on specification, which can be an absolute local pathname, a local pathname relative to the M3U file location, or a URL (both absolute and relative URLs). The M3U file can also include comments, which are prefaced by the ‘#’ character. In extended M3U, the “#” character may also introduce extended directives. The Unicode version of M3U is M3U8, which uses UTF-8 Unicode characters. Themedia manifest file 400 can also specify multiple location choices, as well as the associated costs. Themedia manifest file 400 gives an overview of the content and is initially requested by a media player in order to know how to request specific files or data ranges within a file. A web server or media server can send transport stream files in response to the requests, however, the media content may be stored in one or multiple files. Regardless of how the media content is stored, the web server or media server can send the transport stream files with the corresponding slice of media content requested. When the media content is stored as discrete files, thecost management server 104 or media server 108 may send the discrete file (encoded according to the appropriate quality profile) as the transport stream file in response to the request. However, when the media content is stored a single file, an identifier and an offset may be used to retrieve the appropriate slice of the file (encoded according to the appropriate quality profile), and thecost management server 104 or media server 108 can send this slice as a transport stream file in response to the request. - In one embodiment, a
M3U8 file 400 is created with the available quality profiles and where the media content at those profiles are located even though the media content at those different profiles do not exist at those locations. A media player, such asmedia player 110 ofFIG. 1 , reads the media manifest file for the media content that is being requested. Themedia manifest file 400 may also include a unique content identifier (UCID), duration of the media content, available quality profiles and locations of where the media content can be retrieved. The quality profiles may specify parameters, such as width and height of the image (i.e., image size), video bit rate (i.e., rate at which the video is encoded), audio bit rate, audio sample rate (i.e., rate at which the audio is sampled when captured), number of audio tracks (e.g., mono, stereo, or the like), frame rate (e.g., frame per second), staging size, or the like. For example, the media players may individually request different quality levels of the same media content. Each media player may request the same portion (e.g., same time index) of the media content but at different quality levels. For example, one media player may request a slice having HD quality video, since the computing device of the requesting media player has sufficient computational power and sufficient network bandwidth, while another media player may request a slice having a lower quality, since its computing device may not have sufficient network bandwidth, for example. In one embodiment, the media player shifts between quality levels at the slice boundaries by requesting slices from different copies (e.g., different quality streams) of the media content. Alternatively, the media player can request the slices using other techniques that would be appreciated by those of ordinary skill in the art having the benefit of this disclosure. The media manifest file may also include other metadata, including, for example, air date of the content, title, actresses, actors, a start index, an end index, proprietary publisher data, encryption level, content duration, episode or program name, publisher; available tools for the end-user navigational environment, such as available menus, thumbnails, sidebars, advertising, fast-forward, rewind, pause, and play, or the like; or bit-rate values, including frame size, audio channel information, codecs, sample rate, and frame parser information. - In implementations, the
media manifest file 400 identifies a first web address (e.g., URL) where the media content is located at the first media source and a second web address where the media content is located at the second media source. Themedia manifest file 400 also can identify a rule that a media player is to request the one or more subsequent slices from a second media server when the performance of the adaptive streaming is at or beyond the performance threshold. The media manifest can also include a rule to instruct a media player to request one or more media slices from a first media server when a performance of the adaptive streaming is above a performance threshold. The media manifest file can further identify a second web address where a copy of the plurality of media slices is geographically located at a second media server. - The media manifest file can also identify a third web address where the media content is located at a third media source. The media manifest file can identify yet another rule that a media player is to request the one or more subsequent slices of media from the third media source when the performance is at or beyond a second performance threshold. For example, the first performance threshold can be a first amount of time that a media player has been playing at a given bit rate. A media player can request and playback media slices from a first media server. The second performance threshold can be a second amount of time that a media player has been playing at the given bit rate. When the first performance threshold is met, then the media player can request media slices from a second media server at the same bit rate but with a lesser delivery cost. When the second performance threshold is met, then the media player can request media slices from a third source at the same bit rate but with a lesser delivery cost that the first and second media servers.
- When media slices geographically located at one or more media servers are encoded at different quality levels, the media manifest file can further identify another rule that instructs the media player to request the plurality of media slices from a second media server at a first quality level when the performance is at or beyond a second performance threshold, and from the second media server at a second quality level when the performance is below the second performance threshold.
-
FIG. 5 illustrates server-based logic for generating a media manifest file of an adaptive streaming cost management system according to one embodiment. In implementations, when thecost management server 104 receives a request for media content from aclient 102, thecost management server 104 obtains data from each media server (not shown) and uses the data from each media server to generate a media manifest file that is specific to theclient 102 and to the requested media. In one implementation, when thecost management server 104 receives a request for a media metadata or media manifest file 400 from aclient 102, it could use standard geo-location libraries or services to determine the geographical location (e.g., country of origin) of the requestingclient 102. Thecost management server 104 can then generate amedia manifest file 400 by taking into account the relative distance (in terms of geography or network topology). For example, aserver 502 in the US, upon determining that theclient 102 is in Chile, could send back amedia manifest file 400 that lists one or more Chilean servers 504 with lower quality levels with the smaller files and listsUS servers 502 for higher quality levels with larger files. Because the higher quality slices can take longer to transfer (due to their larger file size) but also due to the higher latency, thecost management server 104 can optimize the user experience for the given network conditions, but can also manage costs for the content owner or publisher. In one embodiment, adaptive streaming cost management in theserver 104 is implemented in a (CMS). Alternatively, the adaptive streaming cost management can be implemented in other severs in the network. It should be noted that themedia manifest file 400 could also be a static manifest file that sets the conditions based on parameters set by the designer. Alternatively, as described above, the server that managesmedia manifest file 400 can make these decisions at run time while receiving client requests for content. Further, thecost management server 104 that generates and manages the media manifest file can use feedback, such as log files, server stats, quality of service (QoS) data, for determining the parameters of the media manifest file to strike a balance between the cost of adaptive streaming and the user's experience. - In one embodiment, the adaptive streaming cost management, whether on the
client 102 orcost management server 104, can use various inputs to decide where to request the data. These various inputs can include the location of theclient 102, the latency in requests to the different locations (e.g., latency for requests for the file at that quality level from US based media servers and the latency for the file at the same or different quality level from the Chilean based media servers), amount of data inbuffer 214, current quality levels requested, previous historical data regarding the client's streaming performance, or the like. These inputs can be measured by theclient 102 or theserver 104 or can be provided by other systems. In an example, theclient 102 can submit a request for a media slice or file directly to a media server. The media server can respond, such as with at least a portion of the requested media slice or file. Theclient 102 can measure the time it takes for the media server to respond and can use the response time to determine whether to request subsequent media slices from that server. -
FIG. 6 is a flow diagram of amethod 600 of generating a media manifest file of an adaptive streaming cost management system according to one embodiment. Themethod 600 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computing system or a dedicated machine), firmware (embedded software), or any combination thereof. In one embodiment, the server-side logic ofFIG. 5 performs themethod 600. Alternatively, other components of the client computing system, server computing system or both can perform some or all of the operations ofmethod 600. - Referring to
FIG. 6 , processing logic begins with receiving a request from a media player executing on a client device to adaptively stream media content atblock 602. The media content can include multiple media slices. Atblock 604, processing logic identifies a geographical location of the client device from the request. Identifying the geographical location of the client device can include extracting data from the request and sending a geographical location request with the extracted data from a location service to determine a geographical region of origin of the client device. - At
block 606, processing logic generates a media manifest file based on the geographical location of the client device. The media manifest file, such as themedia manifest file 400 ofFIG. 4 , can indicate one or more media sources at which a copy of the plurality of media slices is geographically located and a cost associated with delivery of the plurality of media slices from the respective one of the one or more media sources. Atblock 608, processing logic transmits the media manifest file to the client device over the network. -
FIG. 7 illustrates a diagrammatic representation of a machine in the exemplary form of a computing system for adaptive streaming cost management. Within the computing system 700 is a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a PC, a tablet PC, a set-top-box (STB), a personal data assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein for adaptive streaming cost management, such as themethod 300 described above. In one embodiment, the computing system 700 represents various components that may be implemented in theserver computing system 106 as described above. Alternatively, theserver computing system 106 may include more or less components as illustrated in the computing system 700. - The exemplary computing system 700 includes a
processing device 702, a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), a static memory 706 (e.g., flash memory, static random access memory (SRAM), etc.), and adata storage device 716, each of which communicate with each other via a bus 730. -
Processing device 702 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, theprocessing device 702 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Theprocessing device 702 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Theprocessing device 702 is configured to execute the processing logic (e.g., adaptivestreaming cost management 726, media manifest file generation 726) for performing the operations and steps discussed herein. - The computing system 700 may further include a
network interface device 722. The computing system 700 also may include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), and a signal generation device 720 (e.g., a speaker). - The
data storage device 716 may include a computer-readable storage medium 724 on which is stored one or more sets of instructions (e.g., adaptivestreaming cost management 726, media manifest file generation 726) embodying any one or more of the methodologies or functions described herein. The adaptivestreaming cost management 726 and media manifestfile generation 726 may also reside, completely or at least partially, within themain memory 704 and/or within theprocessing device 702 during execution thereof by the computing system 700, themain memory 704 and theprocessing device 702 also constituting computer-readable storage media. The adaptivestreaming cost management 726 may further be transmitted or received over a network via thenetwork interface device 722. - While the computer-
readable storage medium 724 is shown in an exemplary embodiment to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present embodiments. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, magnetic media or other types of mediums for storing the instructions. The term “computer-readable transmission medium” shall be taken to include any medium that is capable of transmitting a set of instructions for execution by the machine to cause the machine to perform any one or more of the methodologies of the present embodiments. - The adaptive streaming cost management module (e.g., deliver cost module) 732, and the media manifest
file generation module 734, components, and other features described herein can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs, or similar devices. The adaptive streamingcost management module 732 may implement operations of adaptive streaming cost management as described herein. The media manifestfile generation module 734 may implement operations of media manifest file generation as described herein In addition, the adaptive streamingcost management module 732 and the media manifestfile generation module 734 can be implemented as firmware or functional circuitry within hardware devices. Further, the adaptive streamingcost management module 732 and the media manifestfile generation module 734 can be implemented in any combination hardware devices and software components. - Some portions of the detailed description that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like.
- It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “receiving,” “generating,” “communicating,” “capturing,” “executing,” “defining,” “specifying,” “creating,” “recreating,” “processing,” “providing,” “computing,” “calculating,” “determining,” “displaying,” or the like, refer to the actions and processes of a computing system, or similar electronic computing systems, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computing system's registers and memories into other data similarly represented as physical quantities within the computing system memories or registers or other such information storage, transmission or display devices.
- Embodiments of the present invention also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing system specifically programmed by a computer program stored in the computing system. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.
- The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to utilize the invention and various embodiments with various modifications as may be suited to the particular use contemplated.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/052,578 US20140297869A1 (en) | 2012-10-11 | 2013-10-11 | Adaptive streaming cost management |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261712657P | 2012-10-11 | 2012-10-11 | |
US14/052,578 US20140297869A1 (en) | 2012-10-11 | 2013-10-11 | Adaptive streaming cost management |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140297869A1 true US20140297869A1 (en) | 2014-10-02 |
Family
ID=51421595
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/052,578 Abandoned US20140297869A1 (en) | 2012-10-11 | 2013-10-11 | Adaptive streaming cost management |
US14/052,589 Active 2034-06-15 US9332051B2 (en) | 2012-10-11 | 2013-10-11 | Media manifest file generation for adaptive streaming cost management |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/052,589 Active 2034-06-15 US9332051B2 (en) | 2012-10-11 | 2013-10-11 | Media manifest file generation for adaptive streaming cost management |
Country Status (1)
Country | Link |
---|---|
US (2) | US20140297869A1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150288734A1 (en) * | 2012-11-09 | 2015-10-08 | Nokia Siemens Networks Oy | Adaptive leveraging of network information |
US20150373077A1 (en) * | 2013-03-01 | 2015-12-24 | Vishwanath RAMMAMURTHI | Link-aware streaming adaptation |
WO2017201379A1 (en) * | 2016-05-19 | 2017-11-23 | Vid Scale, Inc. | Client centric service quality control |
CN112003885A (en) * | 2019-05-27 | 2020-11-27 | 三星Sds株式会社 | Content transmission apparatus and content transmission method |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11132720B2 (en) * | 2001-05-11 | 2021-09-28 | Iheartmedia Management Services, Inc. | Media delivery to limited capability platforms |
US9444862B2 (en) * | 2012-09-29 | 2016-09-13 | Intel Corporation | Dynamic media content output for mobile devices |
EP2941897B1 (en) * | 2013-01-07 | 2019-03-13 | Akamai Technologies, Inc. | Connected-media end user experience using an overlay network |
WO2014124692A1 (en) * | 2013-02-15 | 2014-08-21 | Nec Europe Ltd. | Method and system for providing content in content delivery networks |
US11223510B2 (en) * | 2013-03-14 | 2022-01-11 | Comcast Cable Communications, Llc | Methods and systems for dynamic data management |
US9596170B2 (en) * | 2013-03-14 | 2017-03-14 | Level 3 Communications, Llc | Dynamically optimizing content delivery using manifest chunking |
JP2014239278A (en) * | 2013-06-06 | 2014-12-18 | ソニー株式会社 | Content supply device, content supply method, program, and content supply system |
JP2015002513A (en) * | 2013-06-18 | 2015-01-05 | ソニー株式会社 | Content supply device, content supply method, program, terminal device, and content supply system |
WO2015057229A1 (en) * | 2013-10-17 | 2015-04-23 | Hewlett-Packard Development Company, L.P. | Storing data at a remote location based on predetermined criteria |
US9191374B1 (en) | 2014-09-22 | 2015-11-17 | Belkin International Inc. | Routing device data caching |
US10284299B2 (en) | 2014-06-02 | 2019-05-07 | Belkin International, Inc. | Optimizing placement of a wireless range extender |
US10142386B2 (en) * | 2014-10-29 | 2018-11-27 | DLVR, Inc. | Determining manifest file data used in adaptive streaming video delivery |
US10084838B2 (en) | 2014-10-29 | 2018-09-25 | DLVR, Inc. | Generating and using manifest files including content delivery network authentication data |
US9426089B2 (en) | 2014-10-29 | 2016-08-23 | DLVR, Inc. | Systems and methods for session-based resource assignment, delivery, performance management and measurement in a networked environment |
US9509742B2 (en) | 2014-10-29 | 2016-11-29 | DLVR, Inc. | Configuring manifest files referencing infrastructure service providers for adaptive streaming video |
KR102263696B1 (en) * | 2015-03-20 | 2021-06-10 | 삼성전자주식회사 | Method and appratus for transmitting and receiving data in wireless communication system |
US10057314B2 (en) | 2015-04-17 | 2018-08-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic packager network based ABR media distribution and delivery |
US9787560B2 (en) * | 2015-06-04 | 2017-10-10 | Microsoft Technology Licensing Llc | Effective service node traffic routing |
US10412453B2 (en) * | 2015-10-13 | 2019-09-10 | Futurewei Technologies, Inc. | Probability weighted DASH based video streaming over an information-centric network |
CA3010038C (en) * | 2015-12-29 | 2020-09-22 | DISH Technologies L.L.C. | Methods and systems for adaptive content delivery |
US10735489B1 (en) * | 2016-03-21 | 2020-08-04 | Amazon Technologies, Inc. | Mid-stream content delivery network switching |
CN105828107A (en) * | 2016-03-30 | 2016-08-03 | 乐视控股(北京)有限公司 | Live broadcast time delay method and apparatus |
US10104143B1 (en) * | 2016-06-03 | 2018-10-16 | Amazon Technologies, Inc. | Manifest segmentation |
US10432690B1 (en) | 2016-06-03 | 2019-10-01 | Amazon Technologies, Inc. | Manifest partitioning |
US10116719B1 (en) | 2016-06-03 | 2018-10-30 | Amazon Technologies, Inc. | Customized dash manifest |
US10944806B2 (en) * | 2016-06-22 | 2021-03-09 | The Directv Group, Inc. | Method to insert program boundaries in linear video for adaptive bitrate streaming |
US10574718B2 (en) * | 2016-08-25 | 2020-02-25 | Comcast Cable Communications, Llc | Packaging content for delivery |
US10063902B2 (en) | 2016-12-22 | 2018-08-28 | Cisco Technology, Inc. | ABR network profile selection engine |
US10440085B2 (en) | 2016-12-30 | 2019-10-08 | Facebook, Inc. | Effectively fetch media content for enhancing media streaming |
US10476943B2 (en) * | 2016-12-30 | 2019-11-12 | Facebook, Inc. | Customizing manifest file for enhancing media streaming |
JP7183762B2 (en) * | 2018-12-19 | 2022-12-06 | 日本電信電話株式会社 | Server selection device, server selection method and program |
CN110740180B (en) * | 2019-10-17 | 2022-03-04 | 北京奇艺世纪科技有限公司 | Multimedia resource scheduling method and device and scheduling server |
US11546408B2 (en) * | 2020-11-02 | 2023-01-03 | Microsoft Technology Licensing, Llc | Client-side measurement of computer network conditions |
Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6243761B1 (en) * | 1998-03-26 | 2001-06-05 | Digital Equipment Corporation | Method for dynamically adjusting multimedia content of a web page by a server in accordance to network path characteristics between client and server |
US20040122832A1 (en) * | 2002-11-04 | 2004-06-24 | International Business Machines Corporation | Location independent backup of data from mobile and stationary computers in wide regions regarding network and server activities |
US20040128386A1 (en) * | 2002-09-11 | 2004-07-01 | Masao Oomoto | Service providing method |
US6763392B1 (en) * | 2000-09-29 | 2004-07-13 | Microsoft Corporation | Media streaming methods and arrangements |
US20050055441A1 (en) * | 2000-08-07 | 2005-03-10 | Microsoft Corporation | System and method for providing continual rate requests |
US20050262257A1 (en) * | 2004-04-30 | 2005-11-24 | Major R D | Apparatus, system, and method for adaptive-rate shifting of streaming content |
US7010598B2 (en) * | 2002-02-11 | 2006-03-07 | Akamai Technologies, Inc. | Method and apparatus for measuring stream availability, quality and performance |
US7295520B2 (en) * | 2001-10-31 | 2007-11-13 | Samsung Electronics Co., Ltd. | System and method of network adaptive real-time multimedia streaming |
US20080133744A1 (en) * | 2006-12-01 | 2008-06-05 | Ahn Shin Young | Multimedia data streaming server and method for dynamically changing amount of transmitting data in response to network bandwidth |
US20090031384A1 (en) * | 2007-07-24 | 2009-01-29 | Brooks Paul D | Methods and apparatus for format selection for network optimization |
US20090307367A1 (en) * | 2008-06-06 | 2009-12-10 | Gigliotti Samuel S | Client side stream switching |
US7784076B2 (en) * | 2004-10-30 | 2010-08-24 | Sharp Laboratories Of America, Inc. | Sender-side bandwidth estimation for video transmission with receiver packet buffer |
US20100303146A1 (en) * | 2009-05-26 | 2010-12-02 | Yaniv Kamay | Mechanism for dynamically changing streaming video quality |
US20100312828A1 (en) * | 2009-06-03 | 2010-12-09 | Mobixell Networks Ltd. | Server-controlled download of streaming media files |
US20110060812A1 (en) * | 2009-09-10 | 2011-03-10 | Level 3 Communications, Llc | Cache server with extensible programming framework |
US20110082946A1 (en) * | 2009-10-06 | 2011-04-07 | Openwave Systems Inc. | Managing network traffic using intermediate flow control |
US7962637B2 (en) * | 2006-11-03 | 2011-06-14 | Apple Computer, Inc. | Dynamic adjustments of video streams |
US8561102B1 (en) * | 2012-08-16 | 2013-10-15 | General Instrument Corporation | Location specific video content retrieval enabling regional blackouts to be maintained |
US20140149557A1 (en) * | 2011-07-07 | 2014-05-29 | Telefonaktiebolaget L M Ericsson (Publ) | Network-Capacity Optimized Adaptive HTTP Streaming |
US9015335B1 (en) * | 2009-06-17 | 2015-04-21 | Amazon Technologies, Inc. | Server side stream switching |
US9112948B1 (en) * | 2011-03-18 | 2015-08-18 | Amazon Technologies, Inc. | System and method for assignment and switching of content sources for a streaming content session |
Family Cites Families (74)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA1186028A (en) | 1982-06-23 | 1985-04-23 | Microdesign Limited | Method and apparatus for scrambling and unscrambling data streams using encryption and decryption |
US6604118B2 (en) | 1998-07-31 | 2003-08-05 | Network Appliance, Inc. | File system image transfer |
US5687095A (en) | 1994-11-01 | 1997-11-11 | Lucent Technologies Inc. | Video transmission rate matching for multimedia communication systems |
US7349976B1 (en) | 1994-11-30 | 2008-03-25 | Realnetworks, Inc. | Audio-on-demand communication system |
US6366614B1 (en) | 1996-10-11 | 2002-04-02 | Qualcomm Inc. | Adaptive rate control for digital video compression |
US6480541B1 (en) | 1996-11-27 | 2002-11-12 | Realnetworks, Inc. | Method and apparatus for providing scalable pre-compressed digital video with reduced quantization based artifacts |
US5953506A (en) | 1996-12-17 | 1999-09-14 | Adaptive Media Technologies | Method and apparatus that provides a scalable media delivery system |
US6732183B1 (en) | 1996-12-31 | 2004-05-04 | Broadware Technologies, Inc. | Video and audio streaming for multiple users |
US6091775A (en) | 1997-04-17 | 2000-07-18 | Sharp Kabushiki Kaisha | Video-coding device and video-decoding device |
US6091777A (en) | 1997-09-18 | 2000-07-18 | Cubic Video Technologies, Inc. | Continuously adaptive digital video compression system and method for a web streamer |
EP0919952A1 (en) | 1997-11-28 | 1999-06-02 | Ecole Polytechnique Federale De Lausanne | Method for coding/decoding of a digital signal |
IL123819A (en) | 1998-03-24 | 2001-09-13 | Geo Interactive Media Group Lt | Network media streaming |
US6195680B1 (en) | 1998-07-23 | 2001-02-27 | International Business Machines Corporation | Client-based dynamic switching of streaming servers for fault-tolerance and load balancing |
US6574591B1 (en) | 1998-07-31 | 2003-06-03 | Network Appliance, Inc. | File systems image transfer between dissimilar file systems |
US6622171B2 (en) | 1998-09-15 | 2003-09-16 | Microsoft Corporation | Multimedia timeline modification in networked client/server systems |
US6510553B1 (en) | 1998-10-26 | 2003-01-21 | Intel Corporation | Method of streaming video from multiple sources over a network |
US6272469B1 (en) * | 1998-11-25 | 2001-08-07 | Ge Medical Systems Global Technology Company, Llc | Imaging system protocol handling method and apparatus |
US6434572B2 (en) * | 1998-11-25 | 2002-08-13 | Ge Medical Technology Services, Inc. | Medical diagnostic system management method and apparatus |
US6731600B1 (en) | 1999-02-08 | 2004-05-04 | Realnetworks, Inc. | System and method for determining network conditions |
US7885340B2 (en) | 1999-04-27 | 2011-02-08 | Realnetworks, Inc. | System and method for generating multiple synchronized encoded representations of media data |
FI113124B (en) | 1999-04-29 | 2004-02-27 | Nokia Corp | Communication |
US20020073167A1 (en) | 1999-12-08 | 2002-06-13 | Powell Kyle E. | Internet content delivery acceleration system employing a hybrid content selection scheme |
AU2001256506A1 (en) | 2000-05-18 | 2001-11-26 | British Telecommunications Public Limited Company | Communications network |
US6486803B1 (en) | 2000-09-22 | 2002-11-26 | Digital Fountain, Inc. | On demand encoding with a window |
US8566211B2 (en) | 2000-11-22 | 2013-10-22 | Efficient Auctions, Llc | System and method for a dynamic auction with package bidding |
NO315887B1 (en) | 2001-01-04 | 2003-11-03 | Fast Search & Transfer As | Procedures for transmitting and socking video information |
US20020144276A1 (en) | 2001-03-30 | 2002-10-03 | Jim Radford | Method for streamed data delivery over a communications network |
US20020174434A1 (en) | 2001-05-18 | 2002-11-21 | Tsu-Chang Lee | Virtual broadband communication through bundling of a group of circuit switching and packet switching channels |
US20020188745A1 (en) | 2001-06-11 | 2002-12-12 | Hughes David A. | Stacked stream for providing content to multiple types of client devices |
US20030005455A1 (en) | 2001-06-29 | 2003-01-02 | Bowers J. Rob | Aggregation of streaming media to improve network performance |
US7274661B2 (en) | 2001-09-17 | 2007-09-25 | Altera Corporation | Flow control method for quality streaming of audio/video/media over packet networks |
US20030081582A1 (en) | 2001-10-25 | 2003-05-01 | Nikhil Jain | Aggregating multiple wireless communication channels for high data rate transfers |
EP1451958B1 (en) | 2001-11-09 | 2018-12-26 | Excalibur IP, LLC | File splitting, scalable coding, and asynchronous transmission in streamed data transfer |
US6789123B2 (en) | 2001-12-28 | 2004-09-07 | Microsoft Corporation | System and method for delivery of dynamically scalable audio/video content over a network |
US20030151753A1 (en) | 2002-02-08 | 2003-08-14 | Shipeng Li | Methods and apparatuses for use in switching between streaming video bitstreams |
US7289509B2 (en) | 2002-02-14 | 2007-10-30 | International Business Machines Corporation | Apparatus and method of splitting a data stream over multiple transport control protocol/internet protocol (TCP/IP) connections |
US7133881B2 (en) | 2002-04-29 | 2006-11-07 | Intel Corporation | Encoding and transferring media content onto removable storage |
US20040140989A1 (en) * | 2002-05-28 | 2004-07-22 | John Papageorge | Content subscription and delivery service |
US20040003101A1 (en) | 2002-06-26 | 2004-01-01 | Roth David J. | Caching control for streaming media |
US7802008B2 (en) | 2002-08-12 | 2010-09-21 | Matsushita Electric Industrial Co., Ltd. | Quality of service management in network gateways |
US7643550B2 (en) | 2002-10-09 | 2010-01-05 | Hewlett-Packard Development Company, L.P. | Method for presenting streaming media for an event |
US7716312B2 (en) | 2002-11-13 | 2010-05-11 | Avid Technology, Inc. | Method and system for transferring large data files over parallel connections |
US7792982B2 (en) | 2003-01-07 | 2010-09-07 | Microsoft Corporation | System and method for distributing streaming content through cooperative networking |
US6968387B2 (en) | 2003-01-10 | 2005-11-22 | Realnetworks, Inc. | Stochastic adaptive streaming of content |
US20040148313A1 (en) * | 2003-01-28 | 2004-07-29 | Lu Jim Jin | System and method for generating educational content structure |
US7336890B2 (en) | 2003-02-19 | 2008-02-26 | Microsoft Corporation | Automatic detection and segmentation of music videos in an audio/video stream |
US7408984B2 (en) | 2003-09-17 | 2008-08-05 | International Business Machines Corporation | Method and system for multiple pass video coding |
US20050108414A1 (en) | 2003-11-14 | 2005-05-19 | Taylor Thomas M. | System and method for transmitting data in computer systems using virtual streaming |
US7656561B2 (en) * | 2004-05-31 | 2010-02-02 | Phase One A/S | Image compression for rapid high-quality imaging |
US7640352B2 (en) | 2004-09-24 | 2009-12-29 | Microsoft Corporation | Methods and systems for presentation of media obtained from a media stream |
KR20060065482A (en) | 2004-12-10 | 2006-06-14 | 마이크로소프트 코포레이션 | A system and process for controlling the coding bit rate of streaming media data |
US20070024705A1 (en) | 2005-08-01 | 2007-02-01 | Richter Roger K | Systems and methods for video stream selection |
EP1777969A1 (en) | 2005-10-10 | 2007-04-25 | BRITISH TELECOMMUNICATIONS public limited company | Adaptive video transmission with variable frame rate |
KR100755789B1 (en) | 2006-07-31 | 2007-09-05 | 삼성전자주식회사 | Method and apparatus for video telephony in portable terminal |
US20080056373A1 (en) | 2006-08-29 | 2008-03-06 | Newlin John B | Method and system for dynamic frequency adjustment during video decoding |
US8380864B2 (en) | 2006-12-27 | 2013-02-19 | Microsoft Corporation | Media stream slicing and processing load allocation for multi-user media systems |
US7788395B2 (en) | 2007-02-14 | 2010-08-31 | Microsoft Corporation | Adaptive media playback |
US8578045B2 (en) | 2007-02-14 | 2013-11-05 | Microsoft Corporation | Adaptive bandwidth utilization |
KR100920795B1 (en) * | 2007-08-28 | 2009-10-08 | 김정태 | System for tracing copyright of contents and control method thereof |
US8695020B2 (en) * | 2009-02-06 | 2014-04-08 | Visicom Media, LLC | Techniques for customizing a toolbar using widgets |
US9137278B2 (en) * | 2010-04-08 | 2015-09-15 | Vasona Networks Inc. | Managing streaming bandwidth for multiple clients |
EP2577489A4 (en) * | 2010-06-02 | 2014-09-10 | Onmobile Global Ltd | Method and apparatus for adapting media |
US9445135B2 (en) * | 2010-09-17 | 2016-09-13 | Futurewei Technologies, Inc. | Method and apparatus for scrub preview services |
US9049494B2 (en) * | 2011-01-31 | 2015-06-02 | Cbs Interactive, Inc. | Media playback control |
CN103348656B (en) * | 2011-02-08 | 2016-08-17 | 瑞典爱立信有限公司 | Method and system for the mobility support of cache self adaptation HTTP streaming content in cellular networks |
TWI584662B (en) * | 2011-06-01 | 2017-05-21 | 內數位專利控股公司 | Content delivery network interconnection (cdni) mechanism |
JP5626129B2 (en) * | 2011-06-06 | 2014-11-19 | ソニー株式会社 | Reception apparatus and method, information distribution apparatus and method, and information distribution system |
US9209978B2 (en) * | 2012-05-15 | 2015-12-08 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
US20130080579A1 (en) * | 2011-09-26 | 2013-03-28 | Unicorn Media, Inc. | Dynamically-executed syndication services |
US9712891B2 (en) * | 2011-11-01 | 2017-07-18 | Nokia Technologies Oy | Method and apparatus for selecting an access method for delivery of media |
US20130291002A1 (en) * | 2012-04-25 | 2013-10-31 | Cox Communications, Inc. | Systems and Methods for Delivery of Media Content |
US20140040026A1 (en) * | 2012-05-04 | 2014-02-06 | Adobe Systems Incorporated | Systems and methods for including advertisements in streaming content |
US9244673B2 (en) * | 2012-06-08 | 2016-01-26 | Apple Inc. | System and method for updating application archive files |
US8949206B2 (en) * | 2012-10-04 | 2015-02-03 | Ericsson Television Inc. | System and method for creating multiple versions of a descriptor file |
-
2013
- 2013-10-11 US US14/052,578 patent/US20140297869A1/en not_active Abandoned
- 2013-10-11 US US14/052,589 patent/US9332051B2/en active Active
Patent Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6243761B1 (en) * | 1998-03-26 | 2001-06-05 | Digital Equipment Corporation | Method for dynamically adjusting multimedia content of a web page by a server in accordance to network path characteristics between client and server |
US20050055441A1 (en) * | 2000-08-07 | 2005-03-10 | Microsoft Corporation | System and method for providing continual rate requests |
US6763392B1 (en) * | 2000-09-29 | 2004-07-13 | Microsoft Corporation | Media streaming methods and arrangements |
US7295520B2 (en) * | 2001-10-31 | 2007-11-13 | Samsung Electronics Co., Ltd. | System and method of network adaptive real-time multimedia streaming |
US7010598B2 (en) * | 2002-02-11 | 2006-03-07 | Akamai Technologies, Inc. | Method and apparatus for measuring stream availability, quality and performance |
US20040128386A1 (en) * | 2002-09-11 | 2004-07-01 | Masao Oomoto | Service providing method |
US20040122832A1 (en) * | 2002-11-04 | 2004-06-24 | International Business Machines Corporation | Location independent backup of data from mobile and stationary computers in wide regions regarding network and server activities |
US20050262257A1 (en) * | 2004-04-30 | 2005-11-24 | Major R D | Apparatus, system, and method for adaptive-rate shifting of streaming content |
US7784076B2 (en) * | 2004-10-30 | 2010-08-24 | Sharp Laboratories Of America, Inc. | Sender-side bandwidth estimation for video transmission with receiver packet buffer |
US7962637B2 (en) * | 2006-11-03 | 2011-06-14 | Apple Computer, Inc. | Dynamic adjustments of video streams |
US20080133744A1 (en) * | 2006-12-01 | 2008-06-05 | Ahn Shin Young | Multimedia data streaming server and method for dynamically changing amount of transmitting data in response to network bandwidth |
US20090031384A1 (en) * | 2007-07-24 | 2009-01-29 | Brooks Paul D | Methods and apparatus for format selection for network optimization |
US20090307367A1 (en) * | 2008-06-06 | 2009-12-10 | Gigliotti Samuel S | Client side stream switching |
US20100303146A1 (en) * | 2009-05-26 | 2010-12-02 | Yaniv Kamay | Mechanism for dynamically changing streaming video quality |
US20100312828A1 (en) * | 2009-06-03 | 2010-12-09 | Mobixell Networks Ltd. | Server-controlled download of streaming media files |
US9015335B1 (en) * | 2009-06-17 | 2015-04-21 | Amazon Technologies, Inc. | Server side stream switching |
US20110060812A1 (en) * | 2009-09-10 | 2011-03-10 | Level 3 Communications, Llc | Cache server with extensible programming framework |
US20110082946A1 (en) * | 2009-10-06 | 2011-04-07 | Openwave Systems Inc. | Managing network traffic using intermediate flow control |
US9112948B1 (en) * | 2011-03-18 | 2015-08-18 | Amazon Technologies, Inc. | System and method for assignment and switching of content sources for a streaming content session |
US20140149557A1 (en) * | 2011-07-07 | 2014-05-29 | Telefonaktiebolaget L M Ericsson (Publ) | Network-Capacity Optimized Adaptive HTTP Streaming |
US8561102B1 (en) * | 2012-08-16 | 2013-10-15 | General Instrument Corporation | Location specific video content retrieval enabling regional blackouts to be maintained |
Non-Patent Citations (1)
Title |
---|
DataPath IO, "What is Network Throughput?", 2016, https://datapath.io/resources/blog/what-is-network-throughput/, pp.1-4. (Year: 2016) * |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150288734A1 (en) * | 2012-11-09 | 2015-10-08 | Nokia Siemens Networks Oy | Adaptive leveraging of network information |
US20150373077A1 (en) * | 2013-03-01 | 2015-12-24 | Vishwanath RAMMAMURTHI | Link-aware streaming adaptation |
US10721715B2 (en) * | 2013-03-01 | 2020-07-21 | Apple Inc. | Link-aware streaming adaptation |
WO2017201379A1 (en) * | 2016-05-19 | 2017-11-23 | Vid Scale, Inc. | Client centric service quality control |
CN112003885A (en) * | 2019-05-27 | 2020-11-27 | 三星Sds株式会社 | Content transmission apparatus and content transmission method |
KR20200136195A (en) * | 2019-05-27 | 2020-12-07 | 삼성에스디에스 주식회사 | Apparatus and method for transmitting contents |
US11290370B2 (en) * | 2019-05-27 | 2022-03-29 | Samsung Sds Co., Ltd. | Apparatus and method for transmitting content |
EP3745680B1 (en) * | 2019-05-27 | 2023-12-20 | Samsung SDS Co., Ltd. | Apparatus and method for transmitting content |
KR102622252B1 (en) * | 2019-05-27 | 2024-01-08 | 삼성에스디에스 주식회사 | Apparatus and method for transmitting contents |
Also Published As
Publication number | Publication date |
---|---|
US9332051B2 (en) | 2016-05-03 |
US20140250230A1 (en) | 2014-09-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9332051B2 (en) | Media manifest file generation for adaptive streaming cost management | |
US10547850B2 (en) | Audio splitting with codec-enforced frame sizes | |
US10616301B2 (en) | Request-based encoding for streaming content portions | |
US8826349B2 (en) | Multicast adaptive stream switching for delivery of over the top video content | |
US10148716B1 (en) | Dynamic generation of video manifest files | |
US9609340B2 (en) | Just-in-time (JIT) encoding for streaming media content | |
TWI580237B (en) | Unicast abr streaming | |
US9407968B2 (en) | Multicast and unicast adaptive bitrate services | |
EP2779658A2 (en) | Segmented content delivery | |
KR20170032431A (en) | Video quality enhancement | |
US20120143986A1 (en) | Systems and methods for downloading by different processes | |
KR20150079557A (en) | System and method for delivering an audio-visual content to a client device | |
Petrangeli et al. | Towards svc-based adaptive streaming in information centric networks | |
EP3993365A1 (en) | Session based adaptive playback profile decision for video streaming | |
US10750248B1 (en) | Method and apparatus for server-side content delivery network switching | |
US10750216B1 (en) | Method and apparatus for providing peer-to-peer content delivery | |
Haimi-Cohen et al. | Flexible and robust video delivery based on self-contained multimedia segments | |
FR3096210A1 (en) | A method of transmitting digital content having several versions accessible from a content server to a playback terminal. | |
Annie et al. | Enhancing scalability in on-demand video streaming services for P2P systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: UPLYNK, LLC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BRUECK, DAVID F.;OWEN, C. RYAN;BYE, TYLER;AND OTHERS;SIGNING DATES FROM 20131014 TO 20131015;REEL/FRAME:031408/0460 |
|
AS | Assignment |
Owner name: VDMS LLC, NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:UPLYNK LLC;REEL/FRAME:032717/0799 Effective date: 20131107 Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VDMS LLC;REEL/FRAME:032717/0959 Effective date: 20140217 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |