Error de-emphasis in real-time streaming

Abstract

A reducer edge processing device and computer program product. The reducer edge processing device has a processor, a memory coupled to the processor, and non-transitory instructions embedded in the memory that, when executed by the processor, cause the device to perform a method for reducer edge processing. The method includes performing an error de-emphasis operation and sending information associated with error de-emphasis prior to sending a media segment to a client device.

Description

Technical Field

[0001] This disclosure relates to online media streaming. Specifically, this disclosure relates to enhancements to HTTP Real-Time Streaming (HLS). Background of the Invention

[0003] Over-the-top (OTT) video streaming is becoming increasingly popular compared to television. Despite its popularity, OTT video streaming does have some drawbacks compared to broadcast and cable television. Specifically, adaptive bitrate streaming, such as OTT, requires connection handshakes and playlist sets.

[0004] Additionally, streaming video applications must download and buffer video data and its associated manifest before they can play the video. During the download and buffering process, many different events can cause streaming video devices to malfunction. These malfunctions can be frustrating for users, especially when they occur during streaming.

[0005] It is against this backdrop that the proposed implementation plan is put forward. Attached Figure Description

[0006] Various aspects of this disclosure will be readily understood by considering the following detailed description taken in conjunction with the accompanying drawings, in which:

[0007] Figure 1A Describe the general architecture of an adaptive bit rate (ABR) multimedia streaming system.

[0008] Figure 1B is a flowchart illustrating the operation of a prior art client device in an HLS system.

[0009] Figure 2A HLS systems enhanced by reducing edge processing according to aspects of this disclosure are described.

[0010] Figure 2B This is a flowchart illustrating an operation method of a reduction edge processing device communicating with a client device according to aspects of this disclosure.

[0011] Figure 3 A flowchart depicts a method for de-emphasing cached playlist errors according to aspects of this disclosure.

[0012] Figure 4A A flowchart illustrating a method for de-emphasing errors in a playlist or media segment according to aspects of this disclosure is shown.

[0013] Figure 4B This is a flowchart depicting an operational method for aggravating errors in a playlist or media segment retry request, according to aspects of this disclosure.

[0014] Figure 4C This is a flowchart depicting an operational method for aggravating a playlist or media segment request retry failure error according to aspects of this disclosure.

[0015] Figure 5A A flowchart depicts a method for managing the reduction edge processing device for discontinuities in a medium according to aspects of this disclosure.

[0016] Figure 5B This illustrates the discontinuities in the alignment of the reduction edge processing device according to aspects of this disclosure.

[0017] Figure 6 Depicts a stand-alone reduced edge processing device according to aspects of this disclosure.

[0018] Figure 7 An embedded reduction edge processing system according to aspects of this disclosure is shown. Detailed Implementation

[0019] While the following detailed description contains many specific details for illustrative purposes, those skilled in the art will understand that many variations and modifications of these details are within the scope of this disclosure. Therefore, the examples of embodiments of this disclosure described below are set forth without loss of generality and without implying any limitation on the claimed disclosure.

[0020] While numerous specific details have been set forth to provide a thorough understanding of embodiments of this disclosure, those skilled in the art will understand that other embodiments can be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits have not been described in detail to avoid unnecessarily obscuring this disclosure. Some portions of the description herein are presented as algorithms and symbolic representations of operations on data bits or binary digital signals within computer memory. These algorithmic descriptions and representations can be techniques used by those skilled in the art of data processing to convey the essence of their work to others skilled in the art.

[0021] As used in this paper, an algorithm is a self-consistent sequence of actions or operations that produce a desired result. These actions or operations include physical manipulation of physical quantities. Typically, although not necessary, these quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise manipulated. It has been shown that, primarily for reasons of general use, these signals may sometimes be appropriately referred to as bits, values, elements, symbols, characters, items, numbers, etc.

[0022] Unless specifically stated or apparent from the following discussion, it should be understood that throughout the description, discussions using terms such as “processing,” “computing,” “converting,” “coordinating,” “determining,” or “identifying” refer to the actions and processes of a computer platform, which is an electronic computing device including a processor that operates as data in physical (e.g., electronic) quantities in the processor’s registers and accessible platform memory, and converts said data into other data similarly represented as physical quantities in the computer platform memory, processor registers, or display screen.

[0023] Computer programs can be stored on computer-readable storage media, such as, but not limited to, any type of disk, including floppy disks, optical disks (e.g., optical disc read-only memory (CD-ROM), digital video discs (DVD), Blu-ray discs). TM (etc.), as well as magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, flash memory, or any other type of non-transitory medium suitable for storing electronic instructions.

[0024] introduction

[0025] This disclosure addresses the drawbacks associated with existing adaptive bitrate streaming systems by using a reduction edge processor to solve parity performance issues in cross-platform client environments. In adaptive bitrate streaming, video is used on a variety of client devices that may have different capabilities. Specifically, ABR implementations are typically different across different devices, and performance for one device can vary significantly from one another. While different ABR implementations do attempt to achieve similar (but not always identical) goals, their performance varies.

[0026] The problem referred to in this paper as the "edge processing" problem is how to enable all these cross-platform clients to have equivalent capabilities to access content hosted by a Content Delivery Network (CDN). It is unlikely or unreasonable to assume that all these devices can implement all advanced edge processing technologies. The reduction edge processing architecture according to aspects of this disclosure provides edge intelligence in components outside the client device or client application, thus enabling clients to use advanced edge processing technologies without having to fundamentally reconfigure the client device or application. One of the goals of reduction edge processing according to aspects of this disclosure is to achieve cross-platform ABR parity checking.

[0027] A related issue is one aspect of "playback robustness," namely the ability of a client device or application to effectively handle adaptive bitrate streams. This is no trivial matter, especially when dealing with edge syntax and features, latency, errors, and adaptive bitrates. It's more complex than just edge handling.

[0028] As described herein, reduction edge processing technology alleviates the edge processing and robustness responsibilities of client devices and applications, enabling them to perform well on simpler tasks. The reduction edge processor, which assumes these responsibilities, is a prominent feature of various aspects of this disclosure.

[0029] Adaptive bit rate streaming architecture

[0030] Figure 1A This diagram illustrates the general architecture of an Adaptive Bit Rate (ABR) multimedia streaming system 100. Examples of common protocols used for ABR streaming multimedia on personal computers, set-top box television devices, telephones, and tablets include HTTP Real-Time Streaming (HLS) and HTTP-based Dynamic Adaptive Streaming (DASH). The multimedia streaming system 100 includes a media frame 102, a content delivery network and server 106, a key server 108, and a client device 104 connected via a network 101.

[0031] Content Delivery Network (CDN) 106 includes multiple servers and data servers configured to deliver valid multimedia content to geographically dispersed client devices 104 via network 101. Key server 108 provides encryption keys to client devices 104. These encryption keys are used to decrypt media content from CDN 106, which may be encrypted for Digital Rights Management (DRM) purposes. Media framework 102 provides the network 101 location of the video content delivered by CDN 106 via a Uniform Resource Locator (URL) or similar identifier.

[0032] Figure 1B illustrates the operation of a prior art client device in an HLS system 100. Before media can be played on client device 104, client device 104 sends a request to media framework 102 for the location of the media stream on CDN 106. Media framework 102 sends the location of CDN 106 back to client device 104. This location can be, for example, but not limited to, a URL, an Internet Protocol address (IP address), or a similar form.

[0033] Client device 104 then contacts CDN 106 to request a master playlist. The master playlist provides a list of locations where media is presented under alternative reproductions at different bitrates, in different formats, or with different content. CDN 106 then responds by sending the master playlist back to client device 104.

[0034] Client device 104 can then select a specific playback for the media presentation. This can be accomplished through the client's ABR mechanism to computationally and dynamically determine the optimal bitrate selection and corresponding playback. In response to the playback selection, client device 104 sends a request for a media playlist to CDN 106. The media playlist provides a list containing the keys and video segment locations for media presentation at a specific format, bitrate, etc. CDN 106 sends the media playlist, and the media playlist is received at client device 104.

[0035] To prepare for media playback of an encrypted stream, client device 104 can contact key server 108 by sending a request for an encryption key specific to the media presentation video segment. Key server 108 then sends the requested key, which is received by client device 104. This process is optional because not all streams are encrypted, and keys may not be available under other forms of security.

[0036] A client device initiates streaming media presentation by sending a request for a media segment to CDN 106. CDN 106 initiates sending the media segment in the same manner, which is received at client device 104. A media segment is an encoded audio, closed caption data, metadata, and control data and / or video segment that, when played together in sequence, produces a full-length media presentation. The media segment may be encoded, in which case the client device can use a key received from a key server to decrypt the media segment and begin playback. For more information on the HLS system architecture, see: Pantos, RP “HTTP Live Streaming,” Request for Comments 8216, Network Working Group 1, available at: https: / / tools.ietf.org / html / rfc8216 (August 2017), which is incorporated herein by reference.

[0037] Reduced edge processing enhanced streaming

[0038] Figure 2A This illustrates an HLS system enhanced with reduce edge processing. The user experience of HLS-based streaming can be enhanced, for example, by faster device startup times and reduced buffer times, using reduce edge processing devices or embedded devices 210. In some implementations, reduce edge processing can achieve buffer times up to 64% faster and startup times up to 60% faster.

[0039] Reduced edge processing can be performed by a client device 204 having an embedded reduced edge processing device 210, or by a client device 203 connected to a local reduced edge processing device 210, or by a client device communicating with the reduced edge processing device 210 via network 101. The embedded reduced edge processing device can be created within a dedicated circuit of the client device, or as a separate dedicated module with dedicated instructions, a processor, and memory, coupled to the processor of the client device via, for example, a communication bus. In some implementations, reduced edge processing can be implemented as a software service on the device or its operating system (OS).

[0040] The network can be, for example, but not limited to, the Internet, a local area network (LAN), or some other type of wide area network (WAN). During operation, the prefetching device can communicate with the media frame 202, the key server 208, the CDN 206, or any combination thereof via network 101. In some implementations, the prefetching device can communicate via a client device. For example, the media prefetching device can use the network interface of a client device to communicate with the server via network 101.

[0041] Figure 2B This invention describes a method of operation of a reduction edge processing apparatus communicating with a client device according to aspects of this disclosure. The media prefetching apparatus begins operation before the client device begins communication with the server hosting HLS data, as indicated by dual line 220. In some implementations, the client device may not be powered while the reduction edge processing performs operations above dual line 220.

[0042] The reduction edge processing device 210 can initiate operation by sending a request to the Domain Name System (DNS) for the location of the media frame server 202. The DNS typically sends the location of the media frame server to the reduction edge processing device 210 in the form of an IP address, which is then received at the reduction edge processing device. In some implementations, the reduction edge processing device 210 can contact a trusted source and download a Secure Sockets Layer (SSL) certificate for encrypted communication. This trusted source may be part of the media frame 202. During communication with an SSL-enabled server, the communication is encrypted using the SSL certificate. This encryption ensures that any communication intercepted by a third party from the server to the client (and vice versa) will be incomprehensible.

[0043] The reduction edge processing device 210 can then send a request for the CDN location to the media framework 202. The media framework 202 can return the CDN location to the reduction edge processing device 210. The CDN location is then stored and used for subsequent communications. The reduction edge processing device 210 sends a request for the main playlist to the CDN 206 via the network. In response, the CDN 206 sends the main playlist via the network, which is received by the reduction edge processing device 210. The reduction edge processing device 210 then stores the main playlist.

[0044] As described above, the master playlist contains a list of locations where media is presented at different bitrates, formats, or alternative versions of content. The number of different media presentations on CDN 206 is limited. Therefore, to accelerate the streaming process, in some implementations, the media prefetcher may request a master playlist including each media presentation on CDN 206. The master playlist is then stored in memory or a mass storage device. In some implementations, the reduction edge processing device 210 may predictively request the master playlist to reduce the download time and memory space required for the master playlist. For example, but not limited to, the reduction edge processing device may track a user's viewing habits in a table, such that the device has a record of the last content block viewed by the user. The device may download the master list of the content before the user requests to view the content or even launches the client device. Similarly, for games, the system may track games that the user frequently plays and download the master list if the game's playtime or number of sessions exceeds a certain threshold. Note that although this implementation is described in the context of games, it can also be applied to other media types, such as video or music.

[0045] Once the master playlist is received at the reduction edge processing unit 210, the reduction edge processing unit 210 can send a request for a media playlist to CDN 206. Similar to the master playlist, a limited number of media presentations exist on CDN 206. Therefore, the reduction edge processing unit can request a media playlist for each media presentation on CDN 206. The reduction edge processing unit 210 can optionally implement a prediction method to reduce the number of content playlists downloaded. The prediction method used for prospective extraction of content playlists is substantially similar to those described above relative to the master playlist. The tracking of user activity for content playlists is generally more granular than that for the master playlist because a content playlist represents a specific media presentation, while the master playlist represents a set of alternative versions of media presentations with different bitrates, formats, or content.

[0046] After CDN 206 receives a request for a media playlist, it sends the media playlist to the reduction edge processing device 210 via the network. The media playlist is received by the reduction edge processing device 210 and stored in a memory or mass storage device.

[0047] Then, the reduction edge processing device 210 can request a key from the key server 208 for each media playlist received from the CDN 206. After receiving these keys from the key server 208, the reduction edge processing device 210 stores these keys in memory or a mass storage device.

[0048] Once the user initializes the streaming system on client device 203, communication between client device 203 and reduction edge processing device 210 can begin. The client device can be configured to communicate with the reduction edge processing device as if it were part of a media frame and within the content delivery network. Therefore, reduction edge processing device 210 can receive requests for CDN locations from client device 203. Reduction edge processing device 210 forwards the requests to media frame 202. Media frame 202 replies with the CDN locations received by client device 203. Simultaneously, reduction edge processing device 210 sends content playlist requests to CDN 206. CDN 206 sends the content playlist, and the content playlist is received by reduction edge processing device 210.

[0049] After receiving the CDN location, client device 203 sends a request for the main playlist from reduce edge processing device 210. Client device 203 can be configured to request the playlist from reduce edge processing device 210 before or on behalf of CDN 206. Upon receiving the request for the main playlist, reduce edge processing device 210 can send the requested main playlist to client device 203. Since the reduce edge processing device has already received all main playlists from the CDN, it already has each main playlist in its memory. In a predictive implementation of requesting main playlists, the memory contains potentially requested main playlists, thus there is a possibility of incorrect prediction, and in this case, the request will be forwarded to CDN 206.

[0050] After receiving a main playlist request, the reduction edge processing device 210 can also send a request for media segments to the CDN 206 for forward-looking caching. In some implementations, the reduction edge processing device 210 can request media segments from each media playlist in the main playlist requested by the client device 203. In other implementations, the reduction edge processing device 210 can track recently requested media playlists and can request media segments from the same or identical media playlists. By way of example and not limitation, the reduction edge processing device can maintain a table of five recently requested media playlists, downloaded media segments, etc. Some metadata about each media playlist may exist; for example, table entries may have information about the order in which media playlists are typically requested, and information about the location of the next media playlist that may be requested, i.e., "Previously watched: Breaking Bad Episode 1 - Next Episode: Breaking Bad Episode 2 - Next Episode Location: Location.Location". The reduction edge processing device can request media segments from media consistent with the metadata, such as, but not limited to, the next episode in a series. In other implementations, the table may track user preferences such as language and connection speed, and request media segments from a master list that match those preferences.

[0051] Upon receiving a request for a media segment, CDN 206 begins sending the media segment to reduce edge processing device 210. Reduce edge processing device 210 receives and stores the media segment from CDN 206. The media segment can be stored in memory, such as in a buffer or in a mass storage device.

[0052] Client device 203 may request a media playlist from reduction edge processing device 210. In response, reduction edge processing device 210 may send the media playlist to client device 203. Reduction edge processing device 210 already has all media playlists of the requested master playlist in its memory, so it only needs to retrieve the requested media playlist from its memory.

[0053] Next, client device 203 may request a media segment from reduction edge processing device 210. When reduction edge processing device 210 receives a request for a media segment, it may query its memory or mass storage device for the media segment. If the media segment is found, the reduction edge processing device sends the segment to client device 203. If the media segment is not found, the request for the media segment is sent to CDN 206. Upon receiving a request for a media segment, CDN sends the requested media segment to reduction edge processing device 210. After receiving the media segment, reduction edge processing device 210 stores the media segment in memory or mass storage device. The newly stored media segment can then be sent to client device 203. As mentioned above, the media segment can be encrypted as part of DRM protection; therefore, as part of the storage process, reduction edge processing device 210 decrypts the media segment using the correct key received from the key server. In other implementations, the media segment may be decrypted before being sent to the client device. Once media segments are sent from CDN 206 and received at reduce edge processing device 210, reduce edge processing device 206 can store media segments before client device 203 and send them to client device 203 as needed.

[0054] Errors in reduction edge processing are aggravated

[0055] Error de-emphasis, as used herein, refers to operations performed by a reduction edge processing system that reduce the occurrence of errors streaming to client devices or providing immediate error feedback to client devices, thereby reducing the time costs incurred by users due to error states. Examples of error de-emphasis in the context of this disclosure include, but are not limited to, error masking, discontinuity handling, enhanced protocol usage, addressing problematic latency, resolving network outages, and bit rate control managed by the reduction edge processor.

[0056] Error masking

[0057] According to aspects of this disclosure, the reduction edge processing apparatus can achieve error de-emphasis by masking high latency in playlist reception. For example... Figure 3As shown, the reduction edge processor can send a cached version of a playlist (master playlist, media playlist, content playlist, or any combination thereof) stored in memory and received as a result of a previous or earlier playlist request. The reduction edge processor can send a request for the playlist to CDN 301 before the client device requests it. The reduction edge processor can specify a response wait time threshold from the CDN. If the CDN's response time exceeds threshold 302, the reduction edge processor can send any cached playlist in response to the client request for playlist 303. If a cached entry becomes outdated, the client can refresh it by re-issuing the playlist request at a faster rate, assuming it is capable of doing so. If not, some implementations may include the option for the client device to wait, although this may not be a good option in some cases. For example, waiting often results in playback interruption, especially if the HLS client is unqualified. In an alternative implementation, the reduction edge processor can send the latest version of the playlist cached in memory 304.

[0058] As described above, the reduction edge processing device 210 does not need to maintain a constant response. In some implementations, the reduction edge processing device 210 can be configured to always respond with content in the cache, even if it is not up-to-date. If the immediate cached response is new, the reduction edge processing device 210 can quickly respond with the new content for the client to process. If the response is stale (e.g., the same playlist), the client 203 (e.g., an HLS client) can be designed to reissue the playlist request at a faster rate. This is a useful implementation where, for example, CDN response latency would otherwise adversely affect the HLS playback experience. For example, in some cases, any delay in responding to a client request is often interpreted as a result of slower network conditions, and the client may incorrectly switch bitrates, which takes longer and results in the client 203 receiving lower quality content. In such cases, the reduction edge processing device 210 can mitigate the burden of client-side response latency by responding immediately to playlist requests from the client 203. In some implementations, if the client is to wait for a certain amount of time before timeout, the reduction edge processing device 210 may instead time out faster and issue an error message (e.g., a 404 (Not Found) error), resulting in a bitrate switch on the client instead of a long rebuffering period. As an example, and not a limitation, the reduction edge processing device may have a response threshold of, for example, 1000ms, which can be significantly less than the time the client device will wait before timeout. In this case, the reduction edge processing device 210 may send a request for the playlist to the CDN and wait 1000ms for a response. Network conditions such as network connectivity interruptions or network congestion may exist, causing high latency or inability of the CDN to respond to playlist requests. If the reduction edge processing device does not receive a response within the 1000ms threshold, the device may send a cached copy of the playlist to the client device in response to a subsequent request for the playlist. A cached copy may have already been received in response to a previous request sent to the CDN. In this way, the reduced edge processing device can reduce the occurrence of error streaming to the user, because the user will not have to wait for a longer threshold time on the client device, and the inability to receive the playlist will not immediately affect the user experience.

[0059] According to another aspect of this disclosure, error de-emphasis can provide immediate feedback on failures during streaming, or can mask failures in downloading media segments or playlists by requesting the playlist or media segment a second or subsequent time. Figure 4AThis is a flowchart illustrating a method for error de-emphasis when a playlist or media segment cannot be received from the CDN. As described above, the reduction edge processing system obtains the playlist and may even acquire the media segment before receiving a request for a media segment or playlist 401 from the client device. The reduction edge processing device may send a first request for a playlist or media segment 402 to the CDN. The reduction edge processing device may fail to receive the playlist or media segment from the CDN 403. This failure may be the result of network congestion, disconnected lines, or other conditions that increase latency and packet loss in network communication. The reduction edge processing device may be notified via the network or may initiate a failure mode if the waiting time for receiving the requested playlist or media segment exceeds a threshold or the integrity check of the media segment or playlist fails. The integrity check (which may, for example, but is not limited to) may be an operation that generates a hash of the media segment or playlist and checks the generated hash against a known hash of the media segment or playlist.

[0060] There are multiple ways to notify a reduction edge processing device of a failure. For example, if the reduction edge processing device is performing edge processing on CDN 403. The failure typically originates from the CDN. Some failures take the form of a direct response from CDN 403; others are deduced from slow, unresponsive CDN or corrupted content delivery.

[0061] In some implementations, the reduction edge processor can immediately enter fault state 408 and notify the user of a fault state message, thereby notifying the user of a fault 406. In this way, the user is immediately notified that a media segment or playlist is unavailable, thus saving the user time and reducing frustration, as they will not select an unavailable playlist or media. In another implementation, following the logic used after the first fault mode 403, the reduction edge processor sends a second or subsequent request for a media segment or playlist 404. It should be noted that this disclosure is not limited to a second request, and the device can request a media segment or playlist a third, fourth, fifth, or any number of times. After the second or subsequent request, the device determines whether it has received the requested media segment or playlist 405. For example, but not limited to, the reduction edge processor can be notified via the network or the reduction edge processor can initiate a fault mode if the waiting time for receiving the requested playlist or media segment exceeds a threshold or the integrity check of the media segment or playlist fails. If the device cannot receive the requested media segment or playlist, it sends a fault state message to the client device 406. If the device receives the requested media segment or playlist, the device will do so as described above. Figure 3The description describes the normal procedure for sending media segments or playlists to the client. In this way, errors are mitigated by improving the user experience through recovery from failure mode without notifying the user of the failure, thus creating a smooth viewing experience. It should be noted that a failure status message can be any message sent to the client device notifying the client that the client cannot receive media segments or playlists.

[0062] In some implementations, the reduction edge processing device completely takes over the ABR (Advanced Background Recovery) responsibility. In such cases, the client only plays a single variation of the playlist. If any problems arise when acquiring a segment, the reduction edge processing device can try different variations in a way that is transparent to the client. In other words, if the playlist is playable, the client will not see any errors. If the playlist becomes unplayable, the client receives the appropriate error message from the reduction edge processing device immediately and does not waste time trying to recover without providing a recovery option. Such rapid resolution is ideal in critical situations.

[0063] Figure 4B This paper describes a method for error de-exacerbation in cases where a playlist or media segment cannot be received from a CDN. As shown, the reducing edge processing unit 420 is active before the client device 203 sends a request to the reducing edge processing unit 420. The reducing edge processing unit can preemptively initiate a playlist request for later delivery to the client device. In the depicted example, the reducing edge processing unit 420 sends a media playlist request 410 to the CDN 206. The reducing edge processing unit then waits for a threshold period 411. If the reducing edge processing unit 420 does not receive the media playlist within the threshold period, in this example, the reducing edge processing unit sends a second media playlist request 412 to the CDN 206. The CDN 206 can respond to the second media playlist request 413 by sending the media playlist. In this case, the CDN may have failed to receive the first media playlist request, the first media playlist may have been lost, or some other error may have occurred that prevents the reducing edge processing unit from receiving the media playlist. It should be noted that although the depicted example illustrates operation with respect to media playlists, this disclosure is not limited thereto, and Figure 4B The examples depicted can be used in a main playlist, a content playlist, or any other media list used in a live streaming operation.

[0064] Additionally, recovery from the inability to receive a media segment in response to a media segment request is illustrated. The reduction edge processing device 420 may send a media segment request 414 to the CDN 206. If no media segment is received after a threshold time period 415, the reduction edge processing device 420 may send a second media segment request 416. After the CDN receives the media segment request, the CDN may send the media segment 417. It should be noted that this operation occurs before the client device 203 requests the media segment, thus the client device is unaffected by the inability to receive the media segment. The client device may receive the media segment 418 from the reduction edge processing device 420 much later with minimal delay between when the request for the media segment is sent to the reduction edge processing device and when the media segment is delivered to the client.

[0065] Figure 4C A timing diagram is depicted illustrating a method for error de-emphasis in the event that a playlist or media segment cannot be received from the CDN after a second request. As described above, the reduction edge processing device 420 may send a request for media playlist 411 to CDN 206. If CDN 206 does not respond with the media playlist within a threshold time period 412, the reduction edge processing device 420 sends a second request for media playlist 413. In this implementation, if the reduction edge processing device does not receive the media playlist after a second threshold time period 419, the reduction edge processor enters a fault state and terminates its operation on the media playlist. The reduction edge processing device can then respond to any request for the media playlist from a client device with a fault state message 421. This ensures that the inability to receive the media playlist from the CDN is immediately apparent, and the user can take remedial measures to improve their experience, such as trying to watch different media. It should be noted that while the depicted example illustrates a single retry operation, this disclosure is not limited thereto. In some implementations, there may be two, three, four, or any number (e.g., a user-defined number) of retries before reaching failure mode. In other implementations, the reduction edge processor does not retries sending requests for playlists or media segments to the CDN, but instead directly enters failure mode.

[0066] Discontinuity handling

[0067] Figure 5AThis is a flowchart depicting the exaggeration of errors related to discontinuities in a playlist. Discontinuities in a media playlist notify the client device that the video being played is no longer continuous. For example, a discontinuity occurs when an advertisement is inserted into the video content. The encoding of an advertisement is often completely different from the rest of the media playlist content. Other types of discontinuities include temporal discontinuities, content discontinuities, and encoding discontinuities. Ad injection is an example of a temporal discontinuity—temporal discontinuities often originate from ad injection. Content discontinuities are similar to temporal discontinuities, but are usually the result of missing or unavailable content. In encoding discontinuities, important encoding parameters change.

[0068] Discontinuities notify the media player that an advertisement is about to appear. Generally, media players don't understand the concept of an "advertisement." For a media player, all content it receives is video content. A discontinuity signifies a significant time or encoding change, and the player decides whether to do anything. This depends on the player implementation. Some players refresh the decoder, some adjust timestamp alignment, and some do nothing. Discontinuities must be aligned across playlists; otherwise, the media player will encounter an error because the playlists do not conform to the protocol. Furthermore, because media segments are encoded by multiple different encoders during streaming, discontinuities between playlists may be located in different positions, or there may be a different number of discontinuities within each playlist. Therefore, one aspect of error de-emphasis implemented in this disclosure involves aligning discontinuities between playlists with a reduction edge processing device, so that the client device does not have to handle mismatched discontinuities between playlists. Misaligned discontinuities between playlist variations may technically violate streaming protocol specifications (specs), such as the HLS specification, but can actually occur. Expecting all HLS clients to handle this issue correctly is unrealistic. Solving these kinds of problems at the edge is highly desirable.

[0069] In embodiments of this disclosure, a reduction edge processing device can receive playlists with misaligned discontinuities (i.e., at different timestamps) from a CDN. The reduction edge processing device can reorganize the discontinuities in the playlists to align them 501. This can be done, for example, but not limited to, changing the timestamps and order of media segment entries and discontinuity entries in one or more playlists. The aligned playlist can then be sent to a client device. After selecting media segments for the client device to receive, the reduction edge processing device requests and begins receiving media segments from the desired playlists 502. These media segments can then be sent to the client device immediately or after caching. During streaming, media segments from the reduction edge processing device to the client device can make a decision to switch from a first playlist to a second playlist 503. For example, but not limited to, due to network congestion, the client device or the reduction edge processing device can choose to change from a high bitrate playlist to a lower bitrate playlist. The reduction edge processing device can then begin receiving media segments from the second playlist and align the discontinuities in the second playlist to match the discontinuities in the first playlist. This alignment is achieved through the following steps: decoding the media segment in the second playlist 504, and shifting the start and end positions of breaks and discontinuities within the media segment to match those in the first playlist 505, then re-encoding the media segment while preserving the breaks and discontinuities 506. There are many ways to address this issue as long as discontinuities are aligned. For example, equivalent segments from different variations can be extracted. It should be remembered that clients in a reduction edge processing environment only see one variation. The presence of discontinuities is not particularly relevant to the client as long as the segments are provided.

[0070] In some implementations, the client device may be able to handle some misalignments in discontinuities but not others. In this case, the reduction edge processing device can format the discontinuities in the playlist and media segments to match a form compatible with the client device. In some other implementations, the client device may be unable to handle discontinuities at all; in this case, the reduction edge processing device can remove the discontinuities from the media segments before they reach the client device.

[0071] Figure 5BAn example of discontinuity alignment according to aspects of this disclosure is shown. As shown, media playlist 1 has media segments 510, 512, and 514 with discontinuities 511 and 513. In contrast, media playlist 2 has media segments 516, 517, 518, 520, and 522 with discontinuities 515, 519, and 522. Due to the illustrated arrangement of discontinuities, although both playlists have the same number of media segments and discontinuities, the playback time of each corresponding segment differs between the two playlists. Alignment 527 changes the position of the discontinuities such that the playback times of segments 523, 525, and 527 in media playlists 1 and 2 match, and the playback times of discontinuities 524 and 526 also match.

[0072] Although Figure 5B The examples depicted involve repetition patterns at discontinuities, but this disclosure is not limited thereto and includes playlists that may have discontinuities randomly distributed throughout the playlist, as well as any other organizational patterns. Furthermore, although the examples depict playlist 2 aligned with playlist 1, this disclosure is not limited thereto and may include aligning playlist 1 to playlist 2 or aligning discontinuities and breaks in media segments of both playlists to a new order. Finally, while the alignment action is described with respect to two playlists, this disclosure is not limited thereto, and the alignment methods described to date can be used for 3, 4, 5, or any number of media playlists and media segments.

[0073] Enhanced protocol usage

[0074] According to an additional aspect of this disclosure, a reduction edge processing device can be configured to handle enhanced streaming protocols. Here, an enhanced streaming protocol refers to a protocol that is a later iteration of a previous or more recently developed protocol compared to, for example, HTTP / 2. Some examples of enhanced streaming protocols are Hypertext Transfer Protocol version 2 (HTTP / 2) and WebRTC. In some cases, the client device may not be configured to handle enhanced streaming protocols. In such cases, the reduction edge processing device can convert media streams or other files accessed using enhanced streaming protocols into a format compatible with the client device. For example, but not limited to, the reduction edge processing device can create playlists for WebRTC streams and slice WebRTC streams to create media segments. The reduction edge processor can then send the converted WebRTC stream to the client device. This is a real advantage of reduction edge processing—gaining access to advanced technology that HLS clients would otherwise not have access to. These advantages have the benefit of “de-emphasizing” errors that would otherwise impact the client in a way that interferes with the user experience.

[0075] Bitrate control managed by reduction edge processor

[0076] Adaptive Bitrate Control (ABR) can be implemented on a reduction edge processing device to eliminate the need for ABR on the client device. Currently, ABR implementations in streaming devices vary widely from manufacturer to manufacturer. From a CDN perspective, this impacts user experience. To eliminate these differences, aspects of this disclosure move ABR from the client to the reduction edge processing device. ABR is a core component of most current HTTP streaming applications, but it is often generic and doesn't necessarily perform well in real-time video streaming. Therefore, the reduction edge processing device can be configured to remove the ABR decision from the client device by providing a content playlist to the client device at a single bitrate. This single bitrate playlist can be provided to the client device. Thus, the client device will behave as if only a single bitrate playlist is available, while the reduction edge processing device performs the ABR procedure to control the bitrate of the media segments sent to the client device. Shifting ABR responsibility to the reduction edge processing device can significantly reduce common errors in streaming applications. For example, ABR is often a core HLS playback component and a frequent source of problems—ABR efficiency, CDN edge processing, error handling, etc. This disclosure does not necessarily involve the introduction of new ABR algorithms. Rather, it relates to new architectures regarding where to host the ABR, especially in the presence of cross-platform players for streaming data.

[0077] Reduced edge processing devices can implement advanced forms of ABR using forward network prediction algorithms such as Moving Average Convergence Divergence (MACD). Typical ABR algorithms use a weighted average of previously observed bandwidth samples. The number of samples may vary depending on the strategy. Most of these strategies are "lagging" approaches. For exponential moving averages or weighted moving averages, ABR requires time to respond to drastic changes in bit rate. Furthermore, there is no mechanism to predict and proactively adapt to constantly changing network conditions.

[0078] Implementing ABR using the MACD algorithm prevents long lags in bit rate control by proactively predicting potential trends in system and network conditions. MACD takes the difference between two exponential filters, each with a different time constant (τ), where one time constant is shorter than the other (τ1 < τ2). Typically, the exponential filter takes a time constant (A... τ1 ) and (A τ2 The average of all data points within the time period:

[0079]

[0080] Where d represents a data point and m is the first time point in the series. Then, an exponential filter is applied to each data value after τ1 and τ2 respectively:

[0081] and

[0082]

[0083] Then, the two exponential filters A are... τ1+n and A τ2+n Subtract A from the value τ1+n -A τ2+n To generate a MACD value of τ² + n. Here, A τ1+(n-1) and A τ2+(n-1) Let represent the values ​​of the exponential filter from the previous time point, τ1 and τ2, respectively. Essentially, this creates a sliding window, where τ1 and τ2 are the lengths of each sliding window. Note that at τ2, A... τ1+n -A τ2 Calculate the MACD. Typically, the MACD is calculated using time constants of 12 days and 26 days, but embodiments of this disclosure are not limited to these and can be used for any value of time constant > 0. The MACD calculation also includes an estimate of the rate of change, referred to as the signal. The signal is the average value of the MACD over a specific time period. Based on the MACD and signal calculations, information about the immediate and long-term trends can be determined. For more information on the MACD and signal, see Stanley, Greg, “A ‘MACD Approach’ for Derivative (Rate of Change) Estimation,” available at: http: / / gregstanleyandassociates.com / whitepapers / FaultDiagnosis / Filtering / MACD-approach / macd-approach.htm (2017), which is incorporated herein by reference.

[0084] Reduction edge processing devices can compare MACD values ​​to thresholds to determine when network congestion levels or other problems may occur. They can also monitor when the MACD crosses a signal line and use this crossing to predict network congestion levels or other issues. For example, but not limited to, MACD, ping response time can be applied. When the MACD of a ping response crosses the zero threshold from negative to positive, the reduction edge processor may switch to a lower bit rate stream. Similarly, if the MACD crosses the signal line from bottom to top, the reduction edge processor may switch to a lower bit rate stream. Conversely, if the MACD crosses the threshold from positive to negative or from top to bottom, the reduction edge processor may switch to a higher quality bit rate.

[0085] The information associated with error de-emphasis in this article can be interpreted as a second or subsequent request to a media segment or playlist sent to the CDN, a fault status message sent to the client device, a media segment formatted to be compatible with the client device, or a playlist optimized for adaptive bitrate control implemented on a reduction edge processing device.

[0086] Standalone Reduced Edge Processing System

[0087] Figure 6 An example of a standalone reduced edge processing device according to aspects of this disclosure is depicted. The standalone reduced edge processing device or edge processor 600 can be coupled to a local client device 602 via a network interface 607 over a LAN or WAN. In other alternative implementations, the standalone reduced edge processing device can communicate with a non-local device 603, such as a server or another client, via a large network 604, such as the Internet, through the network interface 607. In some implementations, the client device is connected to the standalone reduced edge processing device via a communication bus (not shown), such as, but not limited to, a Peripheral Interconnect (PCI) bus, a PCI High Speed ​​bus, a Universal Serial Bus (USB), an Ethernet port, a FireWire connector, or a similar interface.

[0088] The standalone reduced edge processing device 600 may include one or more processor units 606, which may be configured according to known architectures such as single-core, dual-core, quad-core, multi-core, processor-coprocessor, unit processor, etc. The standalone reduced edge processing device 600 may also include one or more memory units 605 (e.g., random access memory (RAM), dynamic random access memory (DRAM), read-only memory (ROM), etc.).

[0089] Processor unit 606 can execute one or more instructions 608, portions of which can be stored in memory 605, and processor 606 can be operatively coupled to memory via a bus or bus-type connection. Instructions 608 can be configured to implement Figure 2B The method shown is for prefetching in an HLS system and in Figures 3 to 5B The error de-emphasis method described in the document. Additionally, memory 605 may contain instructions for storing playlists in the HLS library and a protocol stack defining the location of the HLS server. Memory 605 may also contain an HLS library 610 and a protocol stack 611. The memory may also have an encoder / decoder (CODEC) 612 configured for use with media segments. Instructions 608 can also implement storing media segments and playlists in cache 609 during operation. Instructions can implement playlist alignment and, as well as... Figure 5AThe description covers decoding and encoding media segments. Cache 609 may also be located in memory 605.

[0090] The standalone reduction edge processing device 600 may include a network interface 607 to facilitate communication via an electronic communication network 604. The network interface 607 may be configured to enable wired or wireless communication via a local area network (LAN) and a wide area network (WAN), such as the Internet. The device 600 may send and receive data and / or requests via one or more message packets through the network 604. Message packets sent via the network 604 may be temporarily stored in a cache 609 in a memory 605. A client device 602 may connect to the electronic communication network 604 via the network interface 607. Alternatively, a client device 603 may communicate with the standalone reduction edge processing device 600 via the electronic communication network 604.

[0091] Embedded Reduction Edge Processing System

[0092] Figure 7 An embedded reduced edge processing system according to aspects of this disclosure is described. The embedded reduced edge processing system may include a client computing device 700 coupled to a user input device 702. The user input device 702 may be a controller, touchscreen, microphone, keyboard, mouse, joystick, or other device that allows the user to input information, including voice data, into the system.

[0093] The client device of the embedded reduced edge processing system 700 may include one or more processor units 703, which may be configured according to known architectures such as single-core, dual-core, quad-core, multi-core, processor-coprocessor, unit processor, etc. The computing device may also include one or more memory units 704 (e.g., random access memory (RAM), dynamic random access memory (DRAM), read-only memory (ROM), etc.).

[0094] Processor unit 703 can execute one or more programs, portions of which can be stored in memory 704, and processor 703 is operatively coupled to memory, for example, by accessing memory via data bus 705. The programs can be configured to stream media via HLS system 708. Additionally, memory 704 can contain information about connections between the system and one or more streaming servers 710. Memory 704 may also contain buffers for media segments 709. Media segments and connection information can also be stored as data 718 in mass storage device 718.

[0095] The computing device 700 may also include well-known support circuitry, such as input / output (I / O) components 707, power supply (P / S) 711, clock (CLK) 712, and cache 713, which may communicate with other components of the system, for example, via bus 705. The computing device may include a network interface 714. The processor unit 703 and network interface 714 may be configured to implement a local area network (LAN) or personal area network (PAN) via a suitable network protocol for PAN, such as Bluetooth. The computing device may optionally include a mass storage device 715 (e.g., a disk drive, CD-ROM drive, tape drive, flash memory, etc.), and the mass storage device may store programs and / or data. The computing device may also include a user interface 716 to facilitate interaction between the system and a user. The user interface may include a monitor, television screen, speaker, headphones, or other means of communicating information to the user.

[0096] The computing device 700 may include a network interface 714 to facilitate communication via an electronic communication network 720. The network interface 714 may be configured to enable wired or wireless communication via a local area network (LAN) and a wide area network (WAN), such as the Internet. The device 700 may send and receive data and / or requests for files via one or more message packets through the network 720. Message packets sent via the network 720 may be temporarily stored in a buffer 709 in memory 704.

[0097] In some implementations, the embedded reduced edge processing or embedded edge processor 721 can be an embedded hardware component of the client device 700, which can be coupled to the main processor, for example, via bus 705 or I / O component 707, and can receive requests from an application (e.g., a streaming application) running on the client device. In some implementations, the embedded edge processor 721 can initiate and intercept network communications for a CDN or other servers. In these implementations, the embedded edge processor 721 may lack a network interface, or may not use a network interface. In other implementations, the embedded edge processor, the functionality of which can be implemented in streaming software 708 stored in memory 704 or in a program 717 stored in mass storage device 715 and executed on processor 703.

[0098] In some alternative implementations, the embedded edge processor 721 may be an external device coupled to the client device 700 via, for example, a local non-network connection via I / O function 707.

[0099] The processor of the embedded edge processor unit 721 can execute one or more instructions 724, portions of which can be stored in the edge processor memory 722, and the processor 723 can be operatively coupled to the memory 722 via a bus or bus-type connection. The instructions 724 can be configured to implement... Figure 2B The method shown is for prefetching in an HLS system and Figures 3 to 5B The error described in the text is to aggravate the operation. Additionally, memory 722 may contain instructions for storing playlists in the HLS library and a protocol stack defining the location of the HLS server. Memory 722 may also contain an HLS library 610, a protocol stack 611, and an encoder / decoder (CODEC) 612 configured for use with media segments. Instruction 724 can further implement storing media segments as data 725 during operation. The instructions can implement playlist alignment and, as described in the text... Figure 5A The text describes the decoding and encoding of media segments. Alternatively, the HLS library, protocol stack, and media segments can be stored in buffer 708 on client device 700, or stored as connection information 708 in memory 704, or stored as data 718 in mass storage device 715.

[0100] While the foregoing provides a complete description of preferred embodiments of this disclosure, various alternatives, modifications, and equivalents are possible. It should be understood that the foregoing description is intended to be illustrative and not restrictive. For example, although the flowcharts in the accompanying drawings illustrate a specific sequence of operations performed by certain embodiments of this disclosure, it should be understood that this sequence is not essential (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.). Furthermore, many other embodiments will be apparent to those skilled in the art upon reading and understanding the foregoing description. Although this disclosure has been described with reference to specific exemplary embodiments, it will be appreciated that this disclosure is not limited to the described embodiments but can be practiced with modifications and variations within the spirit and scope of the appended claims. Therefore, the scope of this disclosure should be determined by reference to the appended claims and the full scope of the equivalents granted by such claims. Any feature described herein (whether preferred or not) may be combined with any other feature described herein (whether preferred or not). In the appended claims, The indefinite article "a" or "a kind" "Quantity" refers to the quantity of one or more items following the article, unless otherwise expressly stated therein. The appended claims should not be construed as including means plus functional limitations, unless such limitations are explicitly stated in a given claim using the phrase "means for...".

Claims

1. A reduction edge processing device, comprising: processor; A memory coupled to the processor; A non-transitory instruction, embedded in the memory, which, when executed by the processor, causes the device to perform a method for reducing edge processing, the method comprising: Before sending the media segment to the client device, perform streaming error de-emphasis; and Sending information associated with streaming error de-emphasis, wherein performing the streaming error de-emphasis includes: Receive a main playlist that includes media streams at multiple bitrates; Predict future network conditions using the Moving Average Convergence and Divergence (MACD) algorithm; Select a single bit rate based on predicted future network conditions; The content delivery network requests a media segment at a single bitrate of the selected value; and Send a media playlist with media streams at a single bit rate to the client device.

2. The reduction edge processing apparatus of claim 1, wherein performing streaming error de-emphasis comprises: After failing to receive the playlist or media segment in response to the first request, a second request for the corresponding playlist or media segment is sent to the content delivery network without notifying the client device of the failure.

3. The reduction edge processing apparatus of claim 2, wherein sending information associated with the de-emphasis of the streaming error includes: After sending the second request or subsequent request for the media segment to the content delivery network and receiving the media segment from the content delivery network, the media segment is sent to the client device.

4. The reduction edge processing apparatus as claimed in claim 1, wherein, Performing streaming error de-emphasis also includes: requesting a playlist or media segment from a content delivery network before receiving a media segment request from the client device, and being unable to receive the requested playlist or media segment from the content delivery network, wherein sending the media segment with streaming error de-emphasis includes sending a fault status message to the client device.

5. The reduction edge processing apparatus as claimed in claim 1, wherein, Performing streaming error de-emphasis also includes sending a cached playlist stored on the reduction edge processing device to the client device when the response time to a playlist request sent from the client device to the content delivery network exceeds a threshold.

6. The reduction edge processing apparatus as claimed in claim 1, wherein, Performing streaming error de-emphasis includes: receiving first and second playlists, wherein timestamps at discontinuities in the second playlist do not match timestamps at discontinuities in the first playlist; and Change the timestamps at the discontinuities in the second playlist to match the first playlist.

7. The reduction edge processing apparatus of claim 6, wherein performing streaming error de-emphasis further comprises: Receive a media segment and a subsequent media segment having a discontinuity that does not match the discontinuity in the second playlist; as well as Decode and align the discontinuities between the media segment and subsequent media segments to match the timestamps of the discontinuities in the second playlist.

8. The reduction edge processing apparatus as claimed in claim 1, wherein, Performing streaming error de-emphasis also includes formatting discontinuities in the playlist to make the playlist compatible with the client device.

9. The reduction edge processing apparatus as claimed in claim 1, wherein, Sending information associated with the streaming error de-emphasis includes: sending a fault status message to the client device after sending a second or subsequent request for the playlist or the media segment to the content delivery network and being unable to receive the requested playlist or media segment from the content delivery network.

10. The reduction edge processing apparatus of claim 1, wherein performing streaming error de-emphasis further comprises: Request a media segment using an enhanced media streaming protocol.

11. The reduction edge processing apparatus of claim 10, wherein the enhanced media streaming protocol is HTTP / 2.

12. The reduction edge processing apparatus of claim 10, wherein the enhanced media streaming protocol is WebRTC.

13. The reduction edge processing apparatus of claim 10, wherein, Performing the streaming error de-emphasis includes: after determining that the media segment received in response to the first request is invalid, sending a second request for the media segment to the content delivery network.

14. The reduction edge processing apparatus of claim 10, wherein, Performing the streaming error de-emphasis also includes converting the requested media segment from an enhanced streaming protocol format to a format compatible with the client device.

15. A non-transitory computer-readable medium having executable instructions embedded therein, the instructions, when executed by a processor, causing a device to perform a method for reducing edge processing, the method comprising: Before sending the media segment to the client device, perform streaming error de-emphasis; as well as Sending information associated with streaming error de-emphasis, wherein performing the streaming error de-emphasis includes: Receive a main playlist that includes media streams at multiple bitrates; Predict future network conditions using the Moving Average Convergence and Divergence (MACD) algorithm; Select a single bit rate based on predicted future network conditions; The content delivery network requests a media segment at a single bitrate of the selected value; and Send a media playlist with media streams at a single bit rate to the client device.

16. The non-transitory computer-readable medium of claim 15, wherein performing streaming error de-emphasis further comprises: After failing to receive the playlist or media segment in response to the first request, a second request for the corresponding playlist or media segment is sent to the content delivery network without notifying the client device of the failure.

17. The non-transitory computer-readable medium of claim 16, wherein sending information associated with the de-emphasis of the streaming error comprises: After sending the second request or subsequent request for the media segment to the content delivery network and receiving the media segment from the content delivery network, the media segment is sent to the client device.

18. The non-transitory computer-readable medium of claim 15, wherein, Performing the streaming error de-emphasis further includes: requesting a playlist or the media segment from the content delivery network before receiving the media segment request from the client device, and being unable to receive the requested playlist or media segment from the content delivery network, wherein sending information associated with the streaming error de-emphasis includes sending a fault status message to the client device.

19. The non-transitory computer-readable medium of claim 15, wherein, Performing the streaming error de-emphasis also includes: sending a cached playlist stored on a reduction edge processing device to the client device when the response time to a playlist request sent from the client device to the content delivery network exceeds a threshold.

20. The non-transitory computer-readable medium of claim 15, wherein, Performing the streaming error de-emphasis further includes: receiving first and second playlists, wherein timestamps at discontinuities in the second playlist do not match timestamps at discontinuities in the first playlist; and Change the timestamps at the discontinuities in the second playlist to match the first playlist.

21. The non-transitory computer-readable medium of claim 20, wherein performing the streaming error de-emphasis further comprises: Receive a media segment and a subsequent media segment having a discontinuity that does not match the discontinuity in the second playlist; as well as Decode and align the discontinuities between the media segment and subsequent media segments to match the timestamps of the discontinuities in the second playlist.

22. The non-transitory computer-readable medium of claim 15, wherein, Performing the streaming error de-emphasis also includes: formatting discontinuities in the playlist to make the playlist compatible with the client device.

23. The non-transitory computer-readable medium of claim 15, wherein, Sending information associated with the streaming error de-emphasis includes: sending a fault status message to the client device after sending a second or subsequent request for the playlist or the media segment to the content delivery network and being unable to receive the requested playlist or media segment from the content delivery network.

24. The non-transitory computer-readable medium of claim 15, wherein performing the streaming error de-emphasis further comprises: Request a media segment using an enhanced media streaming protocol.

25. The non-transitory computer-readable medium of claim 24, wherein the enhanced media streaming protocol is HTTP / 2.

26. The non-transitory computer-readable medium of claim 24, wherein the enhanced media streaming protocol is WebRTC.

27. The non-transitory computer-readable medium of claim 15, wherein, Performing the streaming error de-emphasis also includes: after determining that the media segment received in response to the first request is invalid, sending a second request for the media segment to the content delivery network.

28. The non-transitory computer-readable medium of claim 24, wherein, Performing the streaming error de-emphasis also includes converting the requested media segment from an enhanced streaming protocol format to a format compatible with the client device.

29. A method for reducing edge processing, the method comprising: Before the media segment is sent to the client device, the reduction edge processing device performs streaming error de-emphasis; as well as The reduction edge processing device sends information associated with the streaming error de-emphasis, wherein performing the streaming error de-emphasis includes: Receive a main playlist that includes media streams at multiple bitrates; Predict future network conditions using the Moving Average Convergence and Divergence (MACD) algorithm; Select a single bit rate based on predicted future network conditions; The content delivery network requests a media segment at a single bitrate of the selected value; and Send a media playlist with media streams at a single bit rate to the client device.

30. A reduction edge processing system, comprising: processor; A memory coupled to the processor; Non-transitory instructions, embedded in the memory, which, when executed by the processor, cause the system to perform operations including: Before sending the media segment to the client device, perform streaming error de-emphasis; as well as Sending information associated with streaming error de-emphasis, wherein performing the streaming error de-emphasis includes: Receive a main playlist that includes media streams at multiple bitrates; Predict future network conditions using the Moving Average Convergence and Divergence (MACD) algorithm; Select a single bit rate based on predicted future network conditions; The content delivery network requests a media segment at a single bitrate of the selected value; and Send a media playlist with media streams at a single bit rate to the client device.

Images