Techniques for coded multi-source media delivery to legacy devices via edge proxy

Abstract

A method is disclosed for delivering multi-source media content to a legacy client device via an edge proxy. The method includes determining that one or more criterion for a multi-source relay mode is met based on a determination that a client device requesting media content lacks support for decoding multi-source media data. In response thereto, the method may include instantiating, at a first server in communication with the client device, a multi-source media decoder associated with the client device. The method may also include (i) receiving, at the first server and concurrently from a plurality of multi-source media sources, multi-source media data corresponding to the media content; (ii) decoding, using the multi-source media decoder, the multi-source media data into uncoded media content data corresponding to the media content; and (iii) delivering at least a portion of the uncoded media content data from the first server to the client device.

Description

TECHNIQUES FOR CODED MULTI-SOURCE MEDIA DELIVERY TO LEGACY DEVICES VIA EDGE PROXYCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to European Application No. 23306438.5 filed August 30, 2023 and European Application No. 24151187.2 filed 10 January, 2024, each of which is incorporated by reference herein in its entirety.TECHNICAL FIELD

[0002] This application relates generally to the distribution of media content, for example, video, audio, images, applications, firmware, application data, and / or any other content where there is a desire to improve delivery, over a distribution network to one or more client devices.SUMMARY

[0003] Various aspects of the present disclosure relate to devices, systems, and methods to distribute media content over a distribution network to one or more client devices using an edge proxy to provide multi- source media content to legacy client devices that are not configured to request or receive multi-source media content on their own.

[0004] In one aspect of the present disclosure, there is provided a method that may include determining whether one or more criterion for a multi-source relay mode is met. The method may also include a determination that the one or more criterion for the multi- source relay mode is met based on a determination that a client device requesting media content lacks support for decoding multi-source media data. The method may also include in accordance with the determination that the one or more criterion for the multi-source relay mode is met, instantiating, at a first server in communication with the client device requesting the media content, a multi-source media decoder associated with the client device requesting the media content. The method may also include receiving, at the first server and concurrently from a plurality of multi-source media sources, multisource media data corresponding to the media content. The method may also include decoding, using the multi- source media decoder, the multi- source media data corresponding to the media content into uncoded media content data corresponding to the media content. The method may alsoinclude delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device.

[0005] In addition to any combination of features described above, the one or more criterion for the multi- source relay mode being met may include a determination that a quantity of client devices within communication range of the first server, and lacking support for decoding multi-source media data, exceeds a threshold quantity.

[0006] In addition to any combination of features described above, the one or more criterion for the multi- source relay mode being met may include a determination that one or more performance parameters associated with delivery of data corresponding to the media content to the client device requesting the media content is outside of one or more performance criterion.

[0007] In addition to any combination of features described above, the method may include in accordance with a determination that a second client device requesting the media content includes support for decoding multi-source media data, delivering multi-source media data corresponding to at least a portion of the media content from the first server to the second client device without using the multi- source media decoder.

[0008] In addition to any combination of features described above, determining that the client device requesting the media content lacks support for decoding multi-source media data may be based on data included in a request for the media content.

[0009] In addition to any combination of features described above, the multi- source media data corresponding to the media content corresponds to DASH or HLS segments.

[0010] In addition to any combination of features described above, the plurality of multi- source media sources may include a cache populated via a just-in-time encoding process associated with the client device requesting the media content.

[0011] In addition to any combination of features described above, the plurality of multi- source media sources includes a cache populated via an encoding process associated with a client device other than the client device requesting the media content.

[0012] In addition to any combination of features described above, the plurality of multi- source media sources includes a peer device, a local cache, or both the peer device and the local cache.

[0013] In addition to any combination of features described above, the method may include instantiating, at a second server, a different multi-source media decoder associated with the client device requesting the media content. The method may also include receiving, at the second server and concurrently from a second plurality of multi-source media sources, the multi-source media data corresponding to the media content. The method may also include decoding, using the different multi-source media decoder, the multi-source media data corresponding to the media content into the uncoded media content data corresponding to the media content. The method may also include delivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device.

[0014] In addition to any combination of features described above, instantiating, at the second server, the different multi-source media decoder associated with the client device requesting media content, may be performed in response to movement data associated with movement of the client device. The movement data may indicate that the client device is moving away from the first server and toward the second server.

[0015] In addition to any combination of features described above, delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device and delivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device may be performed concurrently. Alternatively, in addition to any combination of features described above, the method may include ceasing delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device prior to delivering at least a portion of the uncodcd media content data corresponding to the media content from the second server to the client device.

[0016] In another aspect of the present disclosure, there is provided a computing apparatus that may include at least one electronic processor. The computing apparatus may also include a memory storing instructions, which when executed by the at least one electronic processor, cause the computing apparatus to perform the method and / or any combination of features described above.

[0017] In another aspect of the present disclosure, there is provided a non-transitory computer- readable storage medium storing instructions which, when executed by a computing apparatus, cause the computing apparatus to perform the method and / or any combination of features described above.

[0018] Other aspects of the embodiments will become apparent by consideration of the detailed description and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG. 1 illustrates an example distribution network for distributing media content according to embodiments described herein.

[0020] FIG. 2 is a hardware block diagram of an example client device included in the distribution network of FIG. 1 according to embodiments described herein.

[0021] FIG. 3 is a block diagram of an example edge server included in the distribution network of FIG. 1 according to embodiments described herein.

[0022] FIGS. 4A-4B illustrate a flowchart of an example method for instantiating a Multisource Media Format (MMF)-compliant proxy on an edge compute resource available in the distribution network of FIG. 1 (e.g., on the edge server of FIG. 3) according to embodiments described herein.DETAILED DESCRIPTION

[0023] Media content, for example, video and / or audio, may be delivered over a distribution network to one or more client devices for output by the client devices. Delivery of media content over the distribution network may include a unicast model (one source providing the media content to a requesting client device over a single communication path). Delivery of media content over the distribution network may additionally or alternatively include a single client device utilizing multiple unicast models (e.g., different communication channels, paths, modalities, etc.) to request media content (in its entirety or different portions of the media content) from the single source. However, these different communication channels, paths, modalities, etc. (i.e., communication links) are often asynchronous such that data received from one communication link cannot be used to decode data from another communication link and vice versa.

[0024] Thus, resource management and scheduling of media content requests and delivery based on perceived communication link quality is needed to orchestrate delivery of the full media content requested by a client device. Such resource management and scheduling of media content requests and delivery consumes power and processing resources on the client device and within the distribution network. Additionally, such resource management and scheduling are based onperceived communication link quality that is variable and may change during a media content request and / or delivery (e.g., as a client device moves into or out of a building, as a client device moves between different coverage areas of different edge networks, as one type of communication link becomes heavily used by other nearby client devices, as one type of communication link is affected by some type of interference, etc.). When changes occur to the perceived communication link quality, the resource management and scheduling is updated to reflect the changed conditions, which further consumes power and processing resources of the client device and / or the distribution network. Additionally, delivery of media content may be delayed since the original resource management and scheduling was based on perceived communication link quality before the conditions of the communication links changed. Accordingly, there are technological problems with communication of media content via asynchronous communication links in a distribution network.

[0025] To address the technological problems explained above, a Multi- source Media Format (MMF) may be used to deliver media content to client devices. As opposed to a traditional or single- source media format designed to carry a single encoded version of a source media, a multisource media format (MMF) is a format designed for carrying multiple representations of a source media. For example, media content delivered via a multisource media format (MMF) includes one or more coded representations along with corresponding signaling data enabling downstream processing across the various representations (e.g., decoding, recoding, etc. jointly leveraging more than one representation). For example, a Coded Multi-source Media Format (CMMF) may be used, where a rateless code (e.g., a type of code permitting generation of an arbitrary number of encoded packets from a set of original uncoded packets) is encapsulated in a MMF container with signaling data. By using MMF to deliver media content to client devices, each client device, when equipped with a MMF decoder, may decode MMF packets received from any source in the distribution network via any communication link in the distribution network in a synchronous manner. Accordingly, resource management and scheduling of media content requests and delivery can be reduced or eliminated since equally useful information from multiple communication links may be received and decoded by each client device. In other words, if one communication link experiences an unexpected delay, the client device will continue to receive media content via other communication links / channels until enough MMF packets have been received overall (from any communication link) to fully decode a media segment that is then output by the client device. Thus, not only can resource management and scheduling of media contentrequests and delivery be reduced or eliminated, but the media content can also be delivered to client devices in an efficient manner that reduces or eliminates delays caused by changes in quality of communication links.

[0026] As indicated above, to take advantage of the above-explained benefits of delivering media content using MMF, client devices typically must be specifically configured to engage in MMF functionality (i.e., be MMF-compliant). For example, client devices typically must be specifically configured to include a MMF client component that acts as (i) a MMF request generator to provide MMF requests to upstream devices in the distribution network and (ii) a MMF decoder to decode MMF packets received from upstream devices in the distribution network.

[0027] However, many client devices may be legacy client devices that are not MMF- compliant. Additionally, in some instances, configuring and / or upgrading all legacy client devices to be MMF-compliant may be impractical due to the many different operating systems, media players, etc. that each client devices is configured to use. Thus, there is a technological problem that non-MMF-compliant devices (i.e., legacy devices) may not be able to request or receive media content using MMF.

[0028] To address this technological problem, a MMF-compliant proxy may be instantiated on an edge compute resource available in the distribution network. For example, a MMF-compliant proxy (e.g., a Hypertext Transfer Protocol (HTTP) proxy) may be instantiated on an edge server and may include a MMF client component that includes (i) a MMF request generator to translate requests from a non-MMF-compliant client device to a request for MMF media content and (ii) a MMF decoder to decode MMF packets received from upstream devices to uncoded media content to be delivered to the non-MMF-compliant client device.

[0029] The MMF-compliant proxy instantiated on an edge compute resource addresses the above-note technological problem by allowing the legacy non-MMF-compliant client device to receive MMF media content from multiple devices upstream of the edge server using MMF, which can (i) reduce or eliminate resource management and scheduling of media content requests and delivery and (ii) allow media content to be delivered from numerous sources to the non-MMF- compliant client device in an efficient manner that reduces or eliminates delays caused by changes in quality of communication links. Additionally, the MMF-compliant proxy instantiated on an edge compute resource may be more practical to implement than configuring or upgrading many clientdevices to be MMF-compliant because the MMF-compliant proxy can be instantiated on a temporary basis and a number of different instances of the MMF-compliant proxy can be instantiated for each of a number of different non-MMF-compliant client devices as explained in greater detail herein.

[0030] Furthermore, the use of a MMF-compliant proxy allows for additional MMF media content to be requested and cached within the distribution network 100 such that other client devices (such as MMF-compliant client devices) can have increased quality of service / experience (QoS / E), for example, by retrieving MMF media content that is cached further downstream and / or cached sooner than it would have been had the MMF-compliant proxy not previously requested the MMF media content.

[0031] FIG. 1 shows an example distribution network 100 for distributing media content. The network 100 includes a content server 105 that is configured to store and / or to provide original media content or source content (e.g., audio / video (A / V) encoded content ready for adaptive bit rate (ABR) (e.g., dynamic and Adaptive Streaming over HHTP (DASH) or HTTP live streaming (HLS)) distribution and playback, images, applications, firmware, application data, etc.). The distribution network 100 also includes a MMF encoder 110. In some instances, the MMF encoder 110 is a processing server configured to (i) ingest media content from the content server 105 in various representations and (ii) prepare network coded blocks with different versions (e.g., MMF packets). Network coded blocks can be recombined arbitrarily and decoded to output the original media content (e.g., as received over asynchronous communication links) as explained previously herein. The MMF encoder 110 may encode the original media content into a plurality of MMF packets that are distributed to one or more origin servers 115.

[0032] In some embodiments, data corresponding to media content is encoded with a rateless code (e.g., rateless erasure code, digital fountain code, fountain code, etc.) encapsulated in a MMF container (e.g., CMMF). For example, content is encoded with a rateless code such as Dolby xCD- 1 Code, Digital Fountain Code, LT Code, Raptor Code, RaptorQ Code, Online Code, Linear Network Code, Random Linear Network Code, or other code permitting generation of an arbitrary number of encoded packets from a set of original uncoded packets. In some embodiments, the rateless code is a network code. For example, content is encoded using simple network code, linear network code, random linear network code (RLNC), or other form of network code permitting generation of functionally equivalent coded representations at intermediate nodes without requiringcoded packets to be de-coded then re-encoded. Regardless of code type, the encoded output (e.g., of the linear network encoder) may include systematic packets in addition to non-systematic packets, and the amount of each on a partition / tile basis may be adjusted according to various factors (e.g., tile priority, network conditions, cost, performance requirements, quality of experience (QoE), etc.). The techniques described herein may be applied with respect to any type of multi-source media (MMF) content / data including, but not limited to, CMMF content / data.

[0033] In some instances, the origin servers 115 are HTTP servers that each correspond to one particular Content Delivery Network (CDN) 120. Each origin server 115 stores network coded blocks (e.g., MMF packets) of the encoded content. Depending on configuration, all versions or only subsets (e.g., a version) of the network coded blocks are available in each origin server 115. MMF clients downstream of the origin servers 115 can place “GET” requests to these origin servers 115 to acquire network coded blocks. The subset of MMF packets associated with a given media segment may be referred to as a coded version of the media segment. Thus, each origin server 115 may store different coded versions of a given media segment, but as explained previously herein, because the coded versions include MMF packets, any MMF packet from any one of the origin servers 115 may be used synchronously with each other by a receiving device to reconstruct the media segment assuming that the receiving device includes a MMF decoder to decode the received MMF packets (i.e., assuming that the receiving device is MMF-compliant). In some instances, CDN proxy-caches are HTTP proxy caches that are used in distribution and storage of media content fetched from the origin server 115 in a respective CDN 120.

[0034] In some instances, a content provider starts a MMF just-in-time (JIT) service, configuring the service to fetch packaged content from its existing origin server 115 and reconfiguring its CDNs 120 to use the JIT as their origin. The JIT encoding proxy is a simple containerized service, capable of running in any cloud environment via a multitude of orchestration tools. The JIT is stateless, allowing for easy horizontal scaling. The JIT decides whether to encode content based on arguments provided in a Uniform Resource Locator (URL) path. Upon receiving each request for media content from a downstream device, the JIT encoding proxy will parse the URL path for information on how to encode the response. Original content is downloaded from the origin and streamed into a MMF encoder (which is a reverse proxy) running in the cloud and that has access to original source coded and packaged media. In other words, the JIT encoding proxymay encode uncoded media content data into MMF for downstream transmission to one or more components of the distribution network 100 that request MMF data.

[0035] An edge network 125 of the distribution network 100 may include one or more edge servers 130. The one or more edge servers 130 may bidirectionally communicate with one or more of the CDNs 120, for example, to request media data from one or more origin servers 115 and / or to receive media data from one or more origin servers 115 as explained in greater detail herein. In some instances, the edge network 125 is an operator’s core network that is a network operated network that serves one or more client devices 135 over various access types: 3G, 4G, 5G, 6G radio access networks 1406, Broadband to the home, Wi-Fi networks 140A (wireless local area network (WLAN), wired ethernet (LAN), etc.), Satellite links 140C, and / or the like. The edge network 125 gives the one or more client devices 135 access to the internet via gateways and the CDNs 120. As explained in greater detail below, the edge server 130 may be configured to include a MMF Proxy (i.e., a Smart HTTP proxy cache server) instantiated on-demand in a datacenter with high bandwidth and low-latency connectivity to the edge network 125 and the access networks 140. As illustrated, Wi-Fi network 140A, 4G / 5G network 1406, and Satellite networks 140C are Radio Access Networks to which one or more client devices 135 is attached to access the operator’s core network 125 (i.e., the edge network 125).

[0036] In some instances, client devices 135 (i.e., UE (User Equipment) 135) are multi-access capable devices that include a media player. The client devices 135 may be a playback device configured to output audio and / or video media content to a user). Example client devices 135 include, but arc not limited to, televisions, smartphones, computers, tablet personal computers, audio and / video rendering devices, and / or the like. Each client device 135 may or may not include a MMF decoder. In other words, each client device 135 may or may not be MMF-compliant. Accordingly, the edge server 130 may provide media data to each client device 135 in the form of uncoded media data or multi-source media data (e.g., MMF packets) depending on whether each client device 135 is MMF-compliant or non-MMF-compliant (i.e., a legacy device) as explained in greater detail herein.

[0037] In some instances, a client device 135 may be configured to communicate directly with one or more CDNs 120 without such communication passing through the edge network 125. For example, MMF-compliant client devices 135 may be able to directly communicate with one or more CDNs 120 using some communication channels / modalities. However, MMF-compliant clientdevices 135 may be configured to additionally or alternatively communicate with CDNs 120 via the edge network 125 using other communication channels / modalities in some instances. In some instances, a MMF-compliant client device 135 may concurrently communicate directly with a CDN 120 using a first communication channcl / modality and indirectly with another CDN 120 via the edge network 125 using a second communication channel / modality.

[0038] The distribution network 100 shown in FIG. 1 is merely an example. In some instances, the distribution network 100 includes additional or fewer components. For example, the distribution network 100 may include additional or fewer content servers 105, MMF encoders 110, origin servers 115, CDNs 120, client devices 135, and / or access networks 140. Additionally, although only one edge network 125 and one edge server 130 are shown in FIG. 1, in some instances, the distribution network 100 may include additional edge networks 125 and edge servers 130. For example, different edge networks 125 may have different geographical coverage areas to provide service to client devices 135 within communication range of the edge networks 125 as the client devices 135 move geographically. While the edge network 125 is shown as including a single edge server 130, in some instances, multiple computing devices with multiple electronic processors may together be referred to as the edge server 130 as long as all such computing devices and electronic processors are pail of the edge network 125 (i.e., the operator’s core network). In some instances, an electronic device that is considered to be the edge server 130 is implemented as part of a distributed system including one or more components located in different locations. For example, in some instances, the electronic device includes local hardware components and one or more remote hardware components (e.g., cloud-based components, hosted on public and / or private cloud infrastructure, SaaS, PaaS, etc.) as long as all such components are part of the edge network 125. Similarly, in some instances, the origin server 115 of each CDN 120 may comprise multiple computing devices with multiple electronic processors (e.g., that are part of a distributed system) as long as all such computing devices and electronic processors are part of the respective CDN 120.

[0039] Additionally, FIG. 1 does not necessarily illustrate all communication paths that exist within the distribution network 100. For example, as explained previously herein, a MMF- compliant client device 135 may communicate directly with one or more CDNs 120. As another example, while some arrows in FIG. 1 are bidirectional arrows and some arrows are unidirectional arrows, in some instances, the components between unidirectional arrows may be able to communicate bidirectionally with each other.

[0040] FIG. 2 is a hardware block diagram of a client device 135 according to one example embodiment. In the example illustrated, the client device 135 includes a first electronic processor 205 (for example, a microprocessor or other electronic device). The first electronic processor 205 includes input and output interfaces (not shown) and is electrically coupled to a first memory 210, a first network interface 215, an optional microphone 220, a speaker 225, and a display 230. In some embodiments, the client device 135 includes fewer or additional components in configurations different from that illustrated in FIG. 2. For example, the client device 135 may not include the microphone 220. As another example, the client device 135 may include one or more additional input devices such as a computer mouse and / or a keyboard that receive inputs from a user of the client device 135. As yet another example, the client device 135 may include environment sensors such as an ambient light sensor or movement sensors such as an accelerometer and / or a location tracking device (e.g., a global positioning system (GPS) receiver). As yet another example, the first electronic processor 205 may comprise multiple electronic processors within the client device 135 that together function to control various aspects of the client device 135. Thus, in the claims, if an apparatus or system is claimed, for example, as including an electronic processor or other element configured in a certain manner, for example, to make multiple determinations, the claim or claim element should be interpreted as meaning one or more electronic processors (or other element) where any one of the one or more electronic processors (or other element) is configured as claimed, for example, to make some or all of the multiple determinations. In some embodiments, the client device 135 performs functionality other than the functionality described below.

[0041] The first memory 210 may include read only memory (ROM), random access memory (RAM), other non-transitory computer-readable media, or a combination thereof. The first electronic processor 205 is configured to receive instructions and data from the first memory 210 and execute, among other things, the instructions. In particular, the first electronic processor 205 executes instructions stored in the first memory 210 to perform the methods described herein.

[0042] The first network interface 215 sends data to and receives data from other devices within the distribution network 100 (e.g., the edge network 125 and / or the CDNs 120, for example via one or more of the access networks 140). In some embodiments, the first network interface 215 includes one or more transceivers for wirelessly communicating with the other devices within the distribution network 100. Alternatively or in addition, the first network interface 215 may include a connector or port for receiving a wired connection to one or more of the other devices in thedistribution network, such as an Ethernet cable. The first electronic processor 205 may receive media content (for example, audio, video, and / or the like) from other devices (such as the edge server 130) via the first network interface 215. The first electronic processor 205 may output the media content received from the edge server 130 via the speaker 225, the display 230, or a combination thereof. Additionally, the first electronic processor 205 may communicate data generated by the client device 135 (e.g., requests for media content) to upstream devices in the distribution network 100 (e.g., the edge server 130, one or more CDNs 120, etc.).

[0043] In some instances, the first electronic processor 205 is configured to implement a MMF decoder to decode multi-source media data (e.g., MMF packets) received from other devices such as the edge server 130. In some instances, the first electronic processor 205 is also configured to place “GET” requests for multi-source media data (e.g., MMF packets) to other devices such as the edge server 130. When the first electronic processor 205 of a client device 135 is configured to request multi-source media data and decode multi-source media data, the client device 135 may be referred to as a MMF-compliant client device 135. On the other hand, when the first electronic processor 205 of a client device 135 is not configured to request multi-source media data or decode multisource media data, the client device 135 may be referred to as a non-MMF-compliant client device 135 (i.e., a legacy client device 135). For example, a client device 135 may be non-MMF-compliant when the client device 135 lacks support for MMF decoding either natively or via an installed media player application across an operator access network.

[0044] The display 230 is configured to display images, video, text, and / or data to the user. The display 230 may be a liquid crystal display (ECD) screen or an organic light emitting display (OEED) display screen. In some embodiments, a touch sensitive input interface may be incorporated into the display 230 as well, allowing the user to interact with content provided on the display 230. In some embodiments, the display 230 includes a projector or future-developed display technologies. In some embodiments, the speaker 225 and the display 230 are referred to as output devices that present media content and other information to a user of the client device 135. In some embodiments, the microphone 220, a computer mouse, and / or a keyboard or a touch- sensitive display are referred to as input devices that receive input from a user of the client device 135.

[0045] FIG. 3 is a block diagram of the edge server 130 according to one example embodiment.In the example shown, the edge server 130 includes a second electronic processor 305 electricallyconnected to a second memory 310 and a second network interface 315. These components are similar to the like-named components of the client device 135 explained above with respect to FIG.2 and function in a similar manner as described above. For example, the second electronic processor 305 sends and receives data to and from one or more downstream client devices 135 and / or one or more upstream CDNs 120 via the second network interface 315. In some instances, the edge server 130 includes fewer or additional components in configurations different from that illustrated in FIG. 3. For example, the edge server 130 may additionally include a display such as a touch screen to allow a backend user to reprogram settings or rules of the edge server 130. As another example, the second electronic processor 305 may comprise multiple electronic processors that together function to control various aspects of the client device 135. Thus, in the claims, if an apparatus or system is claimed, for example, as including an electronic processor or other element configured in a certain manner, for example, to make multiple determinations, the claim or claim element should be interpreted as meaning one or more electronic processors (or other element) where any one of the one or more electronic processors (or other element) is configured as claimed, for example, to make some or all of the multiple determinations. In some instances, the edge server 130 performs functionality other than the functionality described below.

[0046] As explained previously herein, a client device 135 may be MMF-compliant or non- MMF-compliant. For a MMF-compliant client device 135, a client component of the MMF system is integrated into a service’s existing video streaming application on the client device 135. The MMF client component includes a networking component that handles making and decoding multisource requests to upstream devices such as the edge server 130. This networking component is initialized once per app session. The MMF client component also includes a metrics component that integrates with a media player (e.g., a video player) and gathers QoE data. This metrics component may be re-initialized for each media file played.

[0047] Upon initialization, the networking component may download configuration information from a configuration service. This configuration information may include information regarding which information sources (e.g., CDNs 120, etc.) to download media content from. The MMF client component is also configured to register a custom Uniform Resource Locator (URL) scheme with an operating system of the client device 135. All media content requests that use this scheme will be passed to the MMF client component to be handled. For example, to play a video via MMF,a service must serve the manifest via a URL with a custom Uniform Resource Identifier (URI) scheme and hostname.

[0048] Upon receiving a media content request, the MMF client component will inspect the URL and decide whether to issue a request for MMF encoded multi-source content. In some instances, the MMF client component is configured to determine whether to issue the request for MMF encoded multi-source content based on a predetermined set of rules regarding, for example, size and / or content of the requested media content. For example, non-media files (e.g., manifests and subtitles) may be too small to see a significant benefit from MMF encoding. Accordingly, for these files, the MMF client component may request full versions of the original media content files from each of the available information sources because doing so is unlikely to affect QoE (e.g., delays in media transmission are unlikely to be significant enough to cause delays in playback that would affect QoE) while doing so increases robustness by giving multiple sources that ability to provide full versions of the original media content files in case one of the files is corrupted in transit.

[0049] For media content requests regarding video and / or audio segments, the MMF client component may determine to issue a request for MMF-encoded multi-source content. To do so, the MMF client component adds arguments to a URL path to signal to upstream devices (e.g., a MMF encoding proxy) that the requested content should be MMF encoded. The MMF client component utilizes the hostnames of the information sources (e.g., N CDNs) from the configuration information to issue N HTTP requests for the encoded content simultaneously (e.g., from multiple sources on multiple communication paths). Upon receiving the first byte of response including MMF encoded multi-source media content from any source, the MMF client component initializes a MMF decoder to decode the multi-source media content. In some instances, the multi-source media data / content (i.e., MMF packets) includes Dynamic Adaptive Streaming over HTTP (DASH) or HLS segments.

[0050] MMF header information included in received multi-source media content (i.e., MMF packets) is used to configure the MMF decoder. Data from the N sources is then transmitted to the MMF configured decoder. Upon the MMF-compliant client device 135 receiving a complete packet from any source, the MMF decoder is configured to add the complete packet to its internal matrix. In one type of deployment example and setting, systematic MMF packets may be received in-order and can be streamed to the media player of the client device 135. Once the decoder has enough datato decode the entire segment, the decoded data is streamed to the media player and any outstanding HTTP requests are cancelled.

[0051] To minimize the amount of data in-flight when the decoder completes decoding of the entire segment, a download manager runs for each MMF information source and issues byte-range requests for the multi-source media content. The purpose of this component is to minimize the amount of outstanding data requested from each information source at any given time while maintaining full throughput.

[0052] Turning to a non-MMF-compliant client device 135, the client component of the MMF system is not integrated into a service’s existing video streaming application on the client device 135. For example, the non-MMF-compliant client device 135 lacks support for MMF decoding either natively or via an installed media player application across an operator access network. The non-MMF-compliant client device 135 also lacks support for requesting multi-source media content (e.g., MMF packets). As explained previously herein, it would be useful for both the non-MMF- compliant client device 135 and other MMF-compliant client devices 135 if the non-MMF- compliant client device 135 could request MMF packets (i.e., multi-source media content) from at least some upstream devices without configuring and / or upgrading the non-MMF-compliant client device 135 to be MMF-compliant. Examples manners of implementing this functionality are described herein with reference to FIGS . 4A-4B .

[0053] FIGS. 4A-4B illustrate a flowchart of a method 400 for instantiating a MMF-compliant proxy on an edge compute resource available in the distribution network 100 (e.g., on the edge server 130 of the edge network 125). The method 400 is described as being performed primarily by the edge server 130 of the edge network 125. While a particular order of processing steps, message receptions, and / or message transmissions is indicated in FIGS. 4A-4B as an example, timing and ordering of such steps, receptions, and transmissions may vary where appropriate without negating the purpose and advantages of the examples set forth in detail throughout the remainder of this disclosure.

[0054] As shown in FIGS. 4A-4B and as explained herein, in some instances, the edge server 130 uses an MMF proxy to enable MMF optimized media content delivery to legacy non-MMF- compliant client devices 135 by performing a process including (i) the edge server 130 detecting that a client device 135 is not MMF-compliant and instantiating the MMF proxy on the edge server130; (ii) the edge server 130 acting as a proxy (MMF proxy) for DASH / HLS requests; (iii) the edge server 130 serving uncoded DASH / HLS content in a local cache if the requested content is available; (iv) the edge server 130 handling content misses as MMF requests to origins servers 115; and (v) the edge server 130 receiving coded content from origin servers 115 and decoding in the edge server 130 via the MMF proxy and delivering decoded / uncoded media content to the non- MMF-compliant client device 135.

[0055] At block 405, the method 400 is initiated when a non-MMF-compliant client device 135 connects to a configuration server to retrieve configuration information to request media content. In some instances, the client device 135 connects to a service configuration endpoint upon launching of a media playback application. In some instances, the edge server 130 acts as the configuration server or communicates with the configuration server to provide the configuration information to the client device 135.

[0056] At block 410, the edge server 130 determines whether one or more criterion is met to instantiate a multi-source relay mode (i.e., whether one or more criterion is met to instantiate a MMF proxy for relayed MMF delivery to the non-MMF-compliant client device 135). In some instances, the one or more criterion includes the edge server 130 determining whether the client device 135 requesting the configuration information and the media content lacks support for decoding multi-source media data (i.e., whether the client device 135 is a non-MMF-compliant client device 135). In some instances, the one or more criterion includes the edge server 130 determining that a quantity of non-MMF-compliant client devices 135 within communication range of the edge server 130 exceeds a threshold quantity. In some instances, the one or more criterion includes the edge server 130 determining that one or more performance parameters associated with delivery of data corresponding to media content to the client device 135 (or to other client devices 135) is outside of one or more performance criterion.

[0057] In situations where the client device 135 is MMF-compliant, the one or more criterion for instantiating a multi-source relay mode is not met because the client device 135 already has its own MMF client component to take advantage of MMF communication. On the other hand, when the client device 135 is not MMF-compliant, the edge server 130 may determine that one or more criterion is met to instantiate a multi-source relay mode. In some instances, the edge server 130 is configured to determine that the client device 135 requesting the media content lacks support for decoding multi-source media data (i.e., is a non-MMF-compliant client device 135) based on dataincluded a request for the media content that is received by the edge server 130 from the client device 135. For example, the data included in a request from the client device 135 for the media content may include a URL, a device ID associated the client device, etc. that indicates that the client device 135 is non-MMF-compliant.

[0058] In some instances, the edge server 130 may not determine to instantiate a multi-source relay mode until the quantity of non-MMF-compliant client devices 135 within communication range of the edge server 130 is greater than the threshold quantity and / or until the one or more performance parameters associated with delivery of data corresponding to media content to one or more client devices 135 is outside one or more performance criterion. For example, if traditional single path media content distribution is not causing poor QoE for the client device 135 and / or for nearby client devices 135 (e.g., because the type or amount of requested content is too small to cause poor QoE), the edge server 130 may register the non-MMF-compliant client device 135 to traditional single path distribution and engage in non-MMF-compliant media content delivery (at block 415). However, during traditional single path media content distribution, the edge server 130 may continue evaluating one or more criterion to determine whether a multi-source relay mode should be instantiated as explained immediately below. In some instances, performance parameters of client devices 135 include minimum requirements based on, for example, estimated latency, startup time, buffering behaviors, and / or playback errors, associated with delivery of the requested media content. In some instances, the edge server 130 may evaluate performance parameters of non-MMF-compliant client devices 135 and / or MMF-compliant client devices because performance parameters of both types of devices may be improved by instantiating MMF proxies of non-MMF- compliant client devices 135 as explained herein.

[0059] In addition to the above-noted one or more criterion, the one or more criterion used to determine whether to instantiate a multi-source relay mode at the edge server 130 may include whether edge compute resources are currently available in the local / regional area to provide the non-MMF-compliant client device 135 with a MMF proxy at the edge server 130 to perform MMF- compliant tasks and relaying of MMF information between the non-MMF-compliant client device 135 and upstream devices such as CDNs 120. The edge server 130 may perform a service capability look-up to determine whether edge compute resources and capability are available to instantiate a MMF proxy. Instantiating a MMF proxy may require a certain amount of edge compute resources and capability that may or may not be available in certain edge networks 125 atcertain times. While upstream resources could theoretically be used to instantiate the MMF proxy, doing so as far as downstream as possible (e.g., at the edge network 125) provides the most benefit from an efficiency and QoE perspective since MMF delivery can occur over more communication paths of the distribution network 100.

[0060] When the edge server 130 determines that the one or more criterion is not met to instantiate a multi-source relay mode at the edge server 130 for the client device 135, the method 400 proceeds to block 415. At block 415, the edge server 130 registers the non-MMF-compliant client device 135 to traditional single path distribution and engages in non-MMF-compliant media content delivery. For example, using a service configuration application programming interface (API), the edge server 130 may register the non-MMF-compliant client device 135 to a service configuration server to engage in traditional single path media content distribution. In such media content distribution, media content is requested on a single communication path and is received on the single communication path. Unlike MMF media content that takes advantage of providing media content from multiple communication sources along multiple communication paths, single path media content distribution does not take advantage of multiple communication paths and multiple media content sources. Accordingly, client devices 135 using single path media content distribution may experience delays in receiving media content which may result in lower QoE. However, in some situations (e.g., when the client device 135 is non-MMF-compliant and when the edge server 130 determines that edge compute resources and / or capability are not available to instantiate a MMF proxy), the client device 135 and the edge server 130 may engage in single path media content distribution to receive media content from upstream devices such as the CDNs 120. As noted previously herein and as indicated in FIG. 4A, during traditional single path media content distribution at block 415, the edge server 130 may continue evaluating one or more criterion to determine whether a multi-source relay mode should be instantiated (at block 410). For example, characteristics of the edge network 125 and / or of the client device(s) 135 may change such that the one or more criterion is later met to instantiate a multi-source relay mode.

[0061] When the edge server 130 determines that the one or more criterion is met to instantiate a multi-source relay mode at the edge server 130 (at block 410), the method 400 proceeds to block 420. At block 420, the edge server 130 instantiates a containerized instance of a MMF proxy (i.e., an edge proxy) at the edge server 130. In some instances, the MMF proxy performs the same functions as the MMF client component on a MMF-compliant client device 135 except that thefunctions are moved upstream to be performed by the edge compute of the edge network 125 (i.e., by the edge server 130). In some instances, there arc two parts of the MMF proxy: (i) a networking component that handles making and decoding multi-source media content requests; and (ii) a metric component that gathers QoE data from the client device 135. The networking component is initialized once per application session. In some instances, instantiation of the MMF proxy includes instantiation, at the edge server 130, of a multi-source media (e.g., MMF) decoder associated with the non-MMF-compliant client device 135 requesting the configuration information (and later the media content) from the edge server 130.

[0062] Upon MMF proxy instantiation on the edge server 130, the networking component of the MMF proxy is configured to download configuration information from the configuration server. This configuration information includes information regarding which information sources (e.g., CDNs, servers, etc.) to download media content from. Additionally, the networking component of the MMF proxy is configured to generate a unique URF (including domain name system (DNS) record(s) if / as necessary) hostname for routing the non-MMF-compliant client to MMF media content sources upstream via the instantiated MMF proxy. In other words, the MMF proxy registers the non-MMF-compliant client device 135 (using its unique client ID) with upstream devices as the connecting end point for receiving media content delivery. The MMF proxy generates a unique extension to the client ID of the non-MMF-compliant client device 135 and also registers the unique extension to the MMF proxy. The unique extension using the client ID uniquely associates the containerized MMF proxy with the specific non-MMF-compliant client device 135. Through this registration process by the MMF proxy, the MMF proxy inherits security / access properties of the non-MMF-compliant client device 135, which enables the non-MMF-compliant client device 135 to take advantage, via the MMF proxy, of transfer of MMF media content for requested media content.

[0063] In one type of deployment example and setting, during the registration process, the non- MMF-compliant client device 135 registers a custom URF scheme with its operating system. All requests that use this scheme will be passed to the non-MMF-compliant client device 135 such that requests for MMF traffic are routed to the MMF proxy per the unique hostname generated during MMF proxy instantiation. In a different type of deployment example and setting (that does not involve changing a client-side networking library), a Content Steering mechanism (e.g., steering server, media presentation description (MPD) with base URFs to CDN1: CDNn, Steering Server, etc.) defined in MPEG-DASH may be utilized to include either an extension to or referencing theMMF proxy’s BaseURL, etc. in the content steering manifest’s service location elements and the steering server’s response which includes a pathway-priority element. The pathway-priority element may indicate (to the client non-MMF-compliant client device 135) which service location has the highest priority to request content from. In this second type of deployment example and setting, the MMF / edge proxy is essentially added as another CDN. In some instances, the DASH MPD includes a content steering element which defines the URL of the steering server. In some instances, a similar content steering mechanism exists for HLS as well (e.g., depending on a type of operating system of the non-MMF-compliant client device 135).

[0064] As indicated by the above explanation of the registration process and MMF proxy instantiation, the MMF proxy instance is uniquely coupled with the non-MMF-compliant client device 135 such that no other non-MMF-compliant device 135 can access the specific instance of the MMF proxy. In other words, additional non-MMF-compliant client devices 135 would require their own MMF edge proxy for which the edge server 130 would separately perform the method 400 to determine whether to instantiate additional MMF proxies for additional non-MMF-compliant client devices 135.

[0065] Upon receiving a media content request from the non-MMF-compliant client device 135 (at block 425), the MMF proxy at the edge server 130 is configured to inspect the URL and decide whether to issue a request for MMF multi- source media content (at block 430). For example, as explained previously herein with respect to the MMF client component on a MMF-compliant client device 135, non-media files (e.g., manifests and subtitles) may be too small to see a significant benefit from MMF encoding. Accordingly, for these files, the MMF proxy may request full versions of the original media content files from each of the available information sources (at block 435) because doing so is unlikely to affect QoE (e.g., delays in media transmission are unlikely to be significant enough to cause delays in playback that would affect QoE) while doing so increases robustness by giving multiple sources that ability to provide full versions of the original media content files in case one of the files is corrupted in transit. Once the MMF proxy at the edge server 130 has decided to handle the media content request without using MMF encoding (at block 435), the method 400 may proceed back to block 425 where the MMF proxy may wait for additional media content requests from the non-MMF-compliant client device 135.

[0066] For media content requests regarding video and / or audio segments, at block 430, the MMF proxy may determine to issue a request for MMF-encoded multi-source content. To do so,the MMF proxy performs similar functions as the MMF client component as explained previously herein. For example, the MMF proxy adds arguments to a URL path to signal to upstream devices (e.g., a MMF encoding proxy) that the requested content should be MMF encoded. The MMF proxy utilizes the hostnames of the information sources (e.g., N CDNs) from the configuration information to issue N HTTP requests for the encoded content simultaneously (e.g., from multiple sources on multiple communication paths) (at block 440).

[0067] At block 445, the edge server 130 receives, concurrently from a plurality of multi-source media sources (e.g., CDNs 120 and / or other devices upstream of the edge server 130) multi-source media data (e.g., MMF packets) corresponding to the media content requested by the edge server 130. Upon receiving the first byte of response including MMF encoded multi-source media content from any source, the MMF proxy initializes a multi-source media (e.g., MMF) decoder to decode the multi- source media content (e.g., MMF packets).

[0068] At block 450, the MMF proxy on the edge server 130 decodes, using the multi-source media decoder, the multi-source media data corresponding to the requested media content into uncoded media content data corresponding to the requested media content. In a similar manner as explained previously herein with respect to MMF-compliant client devices 135, MMF header information included in received multi-source media content (i.e., MMF packets) is used to configure the multi-source media (e.g., MMF) decoder. Data from the N sources is then streamed to the MMF configured decoder of the MMF proxy. Upon receiving a complete packet from any source, the MMF decoder is configured to add the complete packet to its internal matrix. In one type of deployment example and setting, systematic MMF packets may be received in-order and can be held in the second memory 310 at the edge server 130.

[0069] Once the decoder has enough data to decode the entire requested MMF segment, at block 455, the edge server 130 delivers at least a portion of the uncoded media content data corresponding to the requested media content to the non-MMF-compliant client device 135 that previously requested the media content. For example, delivering at least a portion of the uncoded media content data corresponding to the media content from the edge server 130 to the non-MMF- compliant client device 135 is performed using one or more access networks 140 shown in FIG. 1. In some instances, the decoded / uncoded data is relayed or requested via HTTP and standard streaming protocols such as HLS or Moving Pictures Expert Group-Dynamic Adaptive Streaming over HTTP (MPEG-DASH) to the non-MMF-compliant client device 135 using the unique URLhostname generated earlier. In other words, while the uncoded media content data is uncoded in that it is not multi-source coded content data, the uncoded media content data may nevertheless be ‘source’ coded and packaged with, for example, MPEG video coding and MPEG-DASH or HLS packaging, etc. by the edge server 130 for transmission to the client device 135. Other example options for non-MMF-compliant client devices 135 relaying media content requests through a MMF edge proxy include the use of web real-time communication (WebRTC) peer connections. Additionally, once the decoder has enough data decode the entire requested MMF segment, any outstanding HTTP requests from the MMF proxy are cancelled in a similar manner as explained above with respect to the client component of MMF-compliant client devices 135.

[0070] Once the entire requested MMF segment has been decoded and corresponding uncoded data has been provided to the non-MMF-compliant client device 135, the method 400 may proceed back to block 425 where the MMF proxy may wait for additional media content requests from the non-MMF-compliant client device 135.

[0071] In some instances, after a predetermined period of time of the MMF proxy not being used to relay media content to the non-MMF-compliant client device 135, the edge server 130 is configured to cease operation of the MMF proxy to free up edge compute resources. For example, in response to not receiving a media content request from the non-MMF-compliant client device 135 for the predetermined period of time, the edge server 130 may cease operation of the MMF proxy. In some instances, in response to receiving an indication from the non-MMF-compliant client device 135 (for example, that indicates that the media player of the client device 135 is no longer active), the edge server 130 may cease operation of the MMF proxy.

[0072] As indicated previously herein, in some instances, the edge server 130 is configured to instantiate multiple MMF proxies that are each uniquely associated with a different non-MMF- compliant client device 135. Accordingly, the edge server 130 may relay media content (e.g., uncoded media content data) to multiple non-MMF-compliant client devices 135 concurrently. Additionally, concurrently with delivering media content to the multiple non-MMF-compliant client devices 135, the edge server 130 may also deliver multi-source media content / data (e.g., MMF packets) to one or more MMF-compliant client devices 135. For example, in accordance with a determination by the edge server 130 that a second client device 135 requesting media content includes support for decoding multi-source media data (i.e., is MMF-compliant), the edge server 130 delivers multi-source media data (e.g., MMF packets) corresponding to at least a portion of themedia content to the second client device 135 without using an instantiated multi- source media (MMF) decoder since the second client device 135 is capable of decoding the multi-source media data on its own.

[0073] In some instances, during execution of the method 400, the edge server 130 monitors whether the non-MMF-compliant client device 135 is moving / in-transit (for example, moving away from the edge server 130 and moving out of a coverage area of the edge server 130). In some instances, the edge server 130 monitors the movement of the client device 135 by receiving movement data from the client device 135 as recorded by movement sensors of the client device 135 (e.g., an accelerometer, a location tracking device, and / or the like).

[0074] In some instances, the MMF proxy at a first edge server 130 that is uniquely paired with a non-MMF-compliant client device 135 is dynamically migrated across available edge compute (e.g., to a different edge server 130 and edge network 125) in situations where the non-MMF- compliant client device 135 is in-transit. For example, when the non-MMF-compliant client device 135 is moving between coverage areas of adjacent edge networks 125, the first edge server 130 may communicate with a second edge server 130 toward which the client device 135 is moving. The first edge server 130 may instruct the second edge server 130 to instantiate, at the second edge server 130, a different multi-source media (e.g., MMF) proxy associated with the client device 135 requesting the media content in response to determining that movement data associated with movement of the client device indicates (i) that the client device 135 is approaching an outer limit of a communication range of the first edge server 130 and / or (ii) that the client device is moving away from the first edge server 130 and / or toward the second edge server 130. In some instances, the different MMF proxy on the second edge server 130 may be a copy of the MMF proxy that was previously generated by the first edge server 130.

[0075] The second edge server 130 may instantiate the MMF proxy, as instructed and assuming there are edge compute resources and capability on the second edge server 130 as explained previously herein, to be uniquely associated with the client device 135 in a similar manner as explained above with respect to block 420 of FIG. 4A. For example, the instantiation of the MMF proxy may include instantiation of a different multi-source media (e.g. MMF) decoder associated with the client device 135. The second edge server 130 may receive, concurrently from a second plurality of multi-source media sources, the multi-source media data corresponding to the media content requested by the client device 135 from the first edge server 130 and / or the second edgeserver 130. The second edge server 130 may decode, using the different multi-source media decoder, the multi-source media data (e.g., MMF packets) corresponding to the media content into uncoded media content data corresponding to the media content requested hy the client device 135. The second edge server 130 may deliver at least a portion of the uncodcd media content data corresponding to the media content from the second edge server 130 to the client device 135.[00761 In some instances, delivering at least a portion of the uncoded media content data corresponding to the media content from the first edge server 130 to the client device 135 and delivering at least a portion of the uncoded media content data corresponding to the media content from the second edge server 130 to the client device 135 is performed concurrently. In other words, both the first edge server 130 and the second edge server 130 may be delivering uncoded media content data to the client device 135 at the same time (e.g., during a handover / dynamic migration of the MMF proxy at the two edge servers 130). For example, such concurrent uncoded media content delivery may occur over separate communication links in a unicast manner. In some instances, the first edge server 130, whose coverage area is being left by the client device 135, is configured to cease delivering at least a portion of the uncoded media content data corresponding to the media content to the client device 135 prior to the second edge server 130 delivering at least a portion of the uncoded media content data corresponding to the media content from to the client device 135. In other words, in some instances, only one edge server 130 at a time may deliver uncoded media content to the client device 135. In some of such instances, the first edge server 130 may cease delivering the uncoded media content to the client device 135 at the same time that the second edge server 130 begins delivering the uncoded media content to the client device 135. In some instances, the first edge server 130 and the second edge server 130 may communicate with each other during handoff / dynamic migration of the MMF proxy to ensure seamless transition of MMF proxy service for the client device 135. For example, the first edge server 130 may inform the second edge server 130 of a point in the uncoded media content at which the first edge server 130 sent its last packet so that the second edge server 130 can begin its delivery at the same point.

[0077] Execution of the method 400 and the related functionality explained herein results in numerous advantages. For example, media content that could only previously be provided to a non- MMF-compliant client device 135 via a single communication path through the distribution network 100 is now able to be transmitted through upstream portions of the distribution network 100 (e.g., the edge server 130 with the MMF proxy and devices upstream of the edge server 130) as multisource media data corresponding to requested media content that is transmitted concurrently, frommore than one source to the edge server 130 that then ultimately provides the media content to the client device 135. In some instances, the more than one source may include a cache populated via a JIT encoding process associated with the client device 135 requesting the media content. For example, the cache may be located at one or more origin servers 115 of a CDN 120. As another example, the cache may be additionally or alternatively located on the edge server 130 itself. In the example when a cache is located on the edge server 130, the edge server 130 is configured to update the rights / permissions of the cached media content such that the cached media content could be accessed by other client devices 135 even though it was requested by the MMF proxy that is uniquely paired to a single non-MMF-compliant client device 135. Accordingly, (i) MMF- compliant client devices 135 or (ii) other non-MMF-compliant client devices 135 for which a MMF proxy is created may both take advantage of cached multi-source media content at the edge server 130 or elsewhere in the distribution network 100 that was previously requested by other client devices 135 and populated via encoding processes associated with other client devices 135. In some instances, a cache may be additionally or alternatively located on a peer device (e.g., another client device 135) and / or a local cache (e.g., a device connected to the same local network or WLAN as the client device 135 requesting the media content).

[0078] Due to the general increase of caching of multi- source media content throughout the distribution network 100 that occurs by implementing a MMF proxy at the edge server 130 for at least some non-MMF-compliant client devices 135, other client devices 135 (e.g., MMF-compliant client devices 135) benefit from execution of the method 400. For example, additional cached multi-source media content throughout the distribution network 100 means that all devices requesting such content often can request such content from a source further downstream than would have otherwise been required. Accordingly, delivery of such content from one or more sources to many client devices 135 that did not necessarily cause the downstream cache at the sources to be populated with such content can occur more quickly and efficiently. In other words, execution of the method 400 and the related functionality herein include populating CDN caches with multi-source coded media (e.g., CMMF packets) for all non-MMF-compliant and MMF- compliant client devices 135, thereby reducing or eliminating the need to cache both MMF and non- MMF media content. Reducing or eliminating the need to store non-MMF media content reduces the amount of storage space utilized by, for example, origin servers 115 in CDNs 120, which increases the amount of storage space available to store MMF media content for all client devices 135.

[0079] Additionally, the techniques described herein enable multi-access and edge optimized streaming of media content where (i) MMF-compliant client devices 135 stream via one or several access networks 140 simultaneously; (ii) the edge server 130 may only be accessible over a subset of the access networks (e.g., 4G / 5G only); (iii) the edge server 130 is instantiated by a network operator on-demand (e.g., high number of non-MMF devices, many subscribers in the area, etc.); and (iv) the client devices 135 probe various access networks 140 and select which one (or more) to request from. The benefits include QoS / E improvements via multi-source and multi-path (statistical multiplexing) gains from MMF end-to-end and without requiring complex network orchestration and / or scheduling.

[0080] It is to be understood that the embodiments are not limited in its application to the details of the configuration and arrangement of components set forth herein or illustrated in the accompanying drawings. The embodiments are capable of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings.

[0081] In addition, it should be understood that embodiments may include hardware, software, and electronic components or modules that, for purposes of discussion, may be illustrated and described as if the majority of the components were implemented solely in hardware. However, one of ordinary skill in the art, and based on a reading of this detailed description, would recognize that, in at least one embodiment, the electronic-based aspects may be implemented in software (e.g., stored on non-transitory computer-readable medium) executable by one or more electronic processors, such as a microprocessor and / or application specific integrated circuits (“ASICs”). As such, it should be noted that a plurality of hardware and software based devices, as well as a plurality of different structural components, may be utilized to implement the embodiments. For example, “servers” and “computing devices” described in the specification can include one or more electronic processors, one or more computer-readable medium modules, one or more input / output interfaces, and various connections (e.g., a system bus) connecting the various components.

[0082] Various aspects of the present disclosure may be appreciated from the following Enumerated Example Embodiments (EEEs):EEE 1. A method comprising: determining whether one or more criterion for a multi-source relay mode is met; and in accordance with a determination that the one or more criterion for the multi- source relay mode is met, wherein the one or more criterion for the multi-source relay mode being met includes a determination that a client device requesting media content lacks support for decoding multi-source media data: instantiating, at a first server in communication with the client device requesting the media content, a multi-source media decoder associated with the client device requesting the media content; receiving, at the first server and concurrently from a plurality of multi-source media sources, multi-source media data corresponding to the media content; decoding, using the multi- source media decoder, the multi- source media data corresponding to the media content into uncoded media content data corresponding to the media content; and delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device.EEE 2. The method of EEE 1, wherein the one or more criterion for the multi- source relay mode being met includes a determination that a quantity of client devices within communication range of the first server, and lacking support for decoding multi-source media data, exceeds a threshold quantity.EEE 3. The method of any one of EEEs 1-2, wherein the one or more criterion for the multi- source relay mode being met includes a determination that one or more performance parameters associated with delivery of data corresponding to the media content to the client device requesting the media content is outside of one or more performance criterion.EEE 4. The method of any one of the preceding EEEs, further comprising:in accordance with a determination that a second client device requesting the media content includes support for decoding multi- source media data: delivering multi-source media data corresponding to at least a portion of the media content from the first server to the second client device without using the multi- source media decoder.EEE 5. The method of any one of the preceding EEEs, wherein determining that the client device requesting the media content lacks support for decoding multi-source media data is based on data included in a request for the media content.EEE 6. The method of any one of the preceding EEEs, wherein the multi- source media data corresponding to the media content corresponds to DASH or HLS segments.EEE 7. The method of any one of the preceding EEEs, wherein the plurality of multi-source media sources includes a cache populated via a just-in-time encoding process associated with the client device requesting the media content.EEE 8. The method of any one of the preceding EEEs, wherein the plurality of multi-source media sources includes a cache populated via an encoding process associated with a client device other than the client device requesting the media content.EEE 9. The method of any one of the preceding EEEs, wherein the plurality of multi-source media sources includes a peer device, a local cache, or both the peer device and the local cache.EEE 10. The method of any one of the preceding EEEs, further comprising: instantiating, at a second server, a different multi-source media decoder associated with the client device requesting the media content; receiving, at the second server and concurrently from a second plurality of multi-source media sources, the multi-source media data corresponding to the media content; decoding, using the different multi-source media decoder, the multi-source media data corresponding to the media content into the uncoded media content data corresponding to the media content; anddelivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device.EEE 11. The method of EEE 10, wherein instantiating, at the second server, the different multisource media decoder associated with the client device requesting media content, is performed in response to movement data associated with movement of the client device, wherein the movement data indicates that the client device is moving away from the first server and toward the second server.EEE 12. The method of any one of EEEs 10-11, wherein delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device and delivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device is performed concurrently.EEE 13. The method of any one of EEEs 10-11, further comprising: ceasing delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device prior to delivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device.EEE 14. A computing apparatus, comprising: at least one electronic processor; and memory storing instructions, which when executed by the at least one electronic processor, cause the computing apparatus to perform the method of any one of EEEs 1-13.EEE 15. A non-transitory computer-readable storage medium storing instructions which, when executed by a computing apparatus, cause the computing apparatus to perform the method of any one of EEEs 1-13.

[0083] Various features and advantages are set forth in the following claims.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: receiving a request for media content from a client device; determining whether one or more criterion for configuring a multi-source relay mode is met at a first server, the multi- source relay mode enabling media data received from a plurality of multisource media sources on multiple communication paths to be decoded for delivery to the client device; and in accordance with a determination that the one or more criterion for the multi- source relay mode is met, wherein the one or more criterion for the multi-source relay mode being met includes a determination that the client device requesting media content lacks support for decoding multisource media data: instantiating, at the first server in communication with the client device requesting the media content, a multi-source media decoder associated with the client device requesting the media content; receiving, at the first server and concurrently from a plurality of multi-source media sources, multi-source media data corresponding to the media content; decoding, using the multi- source media decoder, the multi- source media data corresponding to the media content into uncoded media content data corresponding to the media content; and delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device.

2. The method of claim 1, wherein the one or more criterion for the multi-source relay mode being met includes a determination that a quantity of client devices within communication range of the first server, and lacking support for decoding multi- source media data, exceeds a threshold quantity.

3. The method of any one of claims 1-2, wherein the one or more criterion for the multi- source relay mode being met includes a determination that one or more performance parameters associated with delivery of data corresponding to the media content to the client device requesting the media content is outside of one or more performance criterion.

4. The method of any one of the preceding claims, further comprising: in accordance with a determination that a second client device requesting the media content includes support for decoding multi-source media data: delivering multi-source media data corresponding to at least a portion of the media content from the first server to the second client device without using the multi- source media decoder.

5. The method of any one of the preceding claims, wherein determining that the client device requesting the media content lacks support for decoding multi- source media data is based on data included in the request for the media content.

6. The method of any one of the preceding claims, wherein the multi-source media data corresponding to the media content corresponds to DASH or HLS segments.

7. The method of any one of the preceding claims, wherein the plurality of multi- source media sources includes a cache populated via a just-in-time encoding process associated with the client device requesting the media content.

8. The method of any one of the preceding claims, wherein the plurality of multi-source media sources includes a cache populated via an encoding process associated with a client device other than the client device requesting the media content.

9. The method of any one of the preceding claims, wherein the plurality of multi- source media sources includes a peer device, a local cache, or both the peer device and the local cache.

10. The method of any one of the preceding claims, further comprising: instantiating, at a second server, a different multi-source media decoder associated with the client device requesting the media content; receiving, at the second server and concurrently from a second plurality of multi-source media sources, the multi-source media data corresponding to the media content;decoding, using the different multi-source media decoder, the multi-source media data corresponding to the media content into the uncoded media content data corresponding to the media content; and delivering at least a portion of the uncodcd media content data corresponding to the media content from the second server to the client device.

11. The method of claim 10, wherein instantiating, at the second server, the different multi- source media decoder associated with the client device requesting media content, is performed in response to movement data associated with movement of the client device, wherein the movement data indicates that the client device is moving away from the first server and toward the second server.

12. The method of any one of claims 10-11, wherein delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device and delivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device is performed concurrently.

13. The method of any one of claims 10-11, further comprising: ceasing delivering at least a portion of the uncoded media content data corresponding to the media content from the first server to the client device prior to delivering at least a portion of the uncoded media content data corresponding to the media content from the second server to the client device.

14. A computing apparatus, comprising: at least one electronic processor; and memory storing instructions, which when executed by the at least one electronic processor, cause the computing apparatus to perform the method of any one of claims 1-13.

15. A non-transitory computer- readable storage medium storing instructions which, when executed by a computing apparatus, cause the computing apparatus to perform the method of any one of claims 1-13.

Images