Method, apparatus, medium and program product for processing media data

Abstract

The invention provides a method and device for processing media data, a medium and a program product. The method comprises the following steps executed by gateway equipment: acquiring a downloading rate parameter fed back by a client; based on the downloading rate parameter and the local cache state, acquiring corresponding media data in a source returning or cache multiplexing mode; calculating a corresponding smooth sending rate based on the smooth bandwidth fed back by the client; and based on the smooth sending rate, controlling the sending rate of the media data in the process of sending the media data to the client. The method comprises the following steps executed by a client: in response to receiving media data from gateway equipment, monitoring an average downloading rate of the media data in a past preset time period; a smooth bandwidth corresponding to the average downloading rate is obtained through smooth processing, and the smooth bandwidth is fed back to the gateway equipment; dynamically selecting a definition gear matched with the bandwidth according to the obtained smooth bandwidth; and sending a media fragmentation request carrying the selected definition level to the gateway device to obtain media data of the corresponding definition. According to the method and the device, smooth playing in a complex network environment is realized through a mechanism that the gateway and the client cooperatively process the media data, and high-quality media experience can be provided for a user even under the condition of traffic burst or network fluctuation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and in particular, to a method and device for processing media data, a computer readable medium and a computer program product. BACKGROUND

[0002] In the daily on-demand and live broadcast services of CDN, the existing technical solutions face some challenges in specific scenarios, such as sudden popular content or network switching. For example, when popular content is just cached to the edge node, or a large number of users simultaneously request the same content, the gateway egress bandwidth pressure increases dramatically, which may cause network congestion and packet loss, and further cause user end video stuttering. In addition, the gateway usually has difficulty in real-time sensing the changes of the terminal user network environment, such as Wi-Fi signal fluctuation or mobile network switching. When the user available bandwidth decreases, if the gateway still sends data at a high rate, it may cause the overflow of the receiving buffer and packet loss; and when the user bandwidth recovers, it cannot immediately supplement data, resulting in waste of bandwidth resources and unsmooth playing. For part of the cached or back-to-source content, the traditional processing method is easy to cause waiting and delay in the sending process, which destroys the smoothness of data output. SUMMARY

[0003] The present application provides a method and device for processing media data, a computer readable medium and a computer program product.

[0004] In an aspect of the present application, a method for processing media data in a gateway device is provided, wherein the method comprises: obtaining a download rate parameter fed back by a client; obtaining corresponding media data by back-to-source or cache multiplexing based on the download rate parameter and a local cache state; calculating a corresponding smooth sending rate based on the smooth bandwidth fed back by the client; controlling the sending rate of the media data in the process of sending the media data to the client based on the smooth sending rate.

[0005] In an aspect of the present application, a method for processing live broadcast data in a client is provided, wherein the method comprises: monitoring the average download rate of the media data in a past predetermined period in response to receiving the media data from a gateway device; obtaining a smooth bandwidth corresponding to the average download rate by performing smooth processing, and feeding back the smooth bandwidth to the gateway device; dynamically selecting a definition level matched with the smooth bandwidth according to the obtained smooth bandwidth; sending a media segment request carrying the selected definition level to the gateway device to obtain media data of the corresponding definition.

[0006] One aspect of this application provides a first apparatus for processing media data in a gateway device, wherein the first apparatus includes: The rate acquisition module is used to obtain the download rate parameters reported by the client. The media data acquisition module is used to acquire the corresponding media data based on the download rate parameters and the local cache status, either by returning to the source or by cache reuse. The transmission rate calculation module is used to calculate the corresponding smooth transmission rate based on the smooth bandwidth fed back by the client. The transmission rate control module is used to control the transmission rate of media data during the process of sending media data to the client based on the smooth transmission rate.

[0007] One aspect of this application provides a second apparatus for processing media data in a client, wherein the second apparatus includes: The rate monitoring module is used to monitor the average download rate of media data over a predetermined period of time in response to receiving media data from the gateway device. The smooth bandwidth acquisition module is used to obtain the smooth bandwidth corresponding to the average download rate by performing smoothing processing, and to feed the smooth bandwidth back to the gateway device; The resolution selection module is used to dynamically select a resolution level that matches the obtained smooth bandwidth. The request sending module is used to send a media segment request carrying the selected resolution level to the gateway device in order to obtain media data of the corresponding resolution.

[0008] In another aspect, this application provides a media data processing system, the system including a first device according to an embodiment of this application and a second device according to an embodiment of this application.

[0009] In another aspect of this application, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the methods of the embodiments of this application.

[0010] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement the methods of the embodiments of this application.

[0011] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods of embodiments of this application.

[0012] The solution provided in this application embodiment involves the client monitoring the download speed in real time and dynamically adjusting the clarity of the media data based on its own caching duration to adapt to network conditions. The gateway device receives download speed parameters from the client, perceives the network conditions of the client in real time, and adjusts its own sending rate accordingly to prevent further deterioration of network congestion. This application embodiment combines the caching status of the client and server and uses traffic shaping technology to perform smooth transmission, ensuring stable transmission of media data. This application embodiment achieves smooth playback in complex network environments through the mechanism of collaborative media data processing between the gateway and the client, providing users with a high-quality media experience even in the event of sudden traffic spikes or network fluctuations. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a method for processing media data in a gateway device and on a client according to an embodiment of this application is shown; Figure 2 An exemplary system architecture diagram according to an embodiment of this application is shown; Figure 3 A schematic diagram illustrating an exemplary client and gateway process for processing m3u8 data according to an embodiment of this application is shown; Figure 4 This illustration shows a schematic diagram of the structure of a first apparatus for processing media data in a gateway device and a second apparatus for processing media data in a client, provided in an embodiment of this application. Figure 5 A schematic diagram of the structure of a device suitable for implementing the scheme in the embodiments of this application is shown.

[0015] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0018] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0019] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer program instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0020] Figure 1 A flowchart illustrating a method for processing media data at a gateway device and at a client, according to an embodiment of this application, is shown. The method includes steps S101 to S104 performed by the gateway device, and steps S201 and S204 performed by the client.

[0021] Gateway devices include, but are not limited to, network routers, network switches, load balancers, firewalls, and dedicated media gateway devices. Clients include, but are not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and smart bands.

[0022] For example, refer to Figure 2The system architecture shown includes a client, a gateway, and an origin server. The client is responsible for sending media data requests to the gateway and dynamically selecting the resolution level based on download rate parameters and caching status, while simultaneously feeding back download rate information to the gateway. Upon receiving the client's request, the gateway, based on download rate parameters and local cache status, decides whether to provide data directly from its local cache or retrieve data from the origin server, and controls the data transmission rate using a traffic shaping algorithm (such as the token bucket algorithm) to achieve smooth transmission. The origin server is responsible for storing media data, responding to the gateway's origin server requests, and providing the required media data fragments. This example system optimizes media data transmission efficiency and user experience through close collaboration between the client and gateway, as well as the gateway's intelligent cache management and traffic shaping.

[0023] The following reference Figure 1 As explained, in step S201, the client responds to receiving media data from the gateway device and monitors the average download rate of the media data over a predetermined period of time.

[0024] Optionally, the monitoring accuracy and frequency of the average download speed can be dynamically adjusted according to different network environments. The higher the frequency, the more timely the perception of network status. For example, the monitoring accuracy can be set to kbps and the monitoring frequency to 200ms.

[0025] In step S202, the client obtains the smoothed bandwidth corresponding to the average download rate by performing smoothing processing, and feeds back the smoothed bandwidth to the gateway device.

[0026] The smoothing process is a weighted average calculation method based on historical and current data, which aims to reduce the impact of network fluctuations on download speed, thereby providing a more stable bandwidth estimate.

[0027] According to one embodiment, the smoothing bandwidth corresponding to the average download rate is calculated according to a preset smoothing calculation formula, which is based on the smoothing bandwidth of the previous moment, the download rate of the current segment, and a preset weighting coefficient. For example, the smoothing bandwidth (Bi) is calculated using the following formula (1): Bi = Bi-1 α+β currBitrate (1) Here, currBitrate represents the current download rate. α and β are weighting coefficients. Optionally, α and β can be dynamically adjusted according to actual needs, or optimized through machine learning algorithms. For example, α can be set to 0.3 and β to 0.7, meaning that most of the bandwidth is referenced to the real-time perceived bandwidth, and a small portion is referenced to historical data for smoothing, to prevent large spikes and fluctuations.

[0028] The client performs smoothing calculations using this formula to smooth the bandwidth fluctuations of the client and provide a more accurate reference basis for the transmission rate calculation of the gateway device.

[0029] In step S203, the client dynamically selects a clarity level that matches the obtained smoothed bandwidth.

[0030] According to an embodiment, based on a preset bandwidth threshold range, the smoothed bandwidth value is mapped to different clarity levels. For example, if the smoothed bandwidth value is lower than the low threshold, the low clarity level is selected; if the smoothed bandwidth value is higher than the high threshold, the high clarity level is selected; if the smoothed bandwidth value is between the two, the medium clarity level is selected.

[0031] According to an embodiment, the client dynamically selects a clarity level that matches the obtained smoothed bandwidth and the remaining duration of the current local playback buffer.

[0032] Among them, if the remaining duration of the buffer is short (for example, lower than the set buffer threshold), a lower clarity level is selected to ensure the continuity of playback; if the remaining duration of the buffer is long, a higher clarity level can be selected to improve the user experience.

[0033] Specifically, the client obtains the remaining duration of the current local playback buffer. Then, based on a predetermined corresponding rule, a clarity level that matches the smoothed bandwidth and the buffer state is selected. This corresponding rule can be implemented through a preset mapping table or algorithm to ensure the selection of the most appropriate clarity level under different network and buffer states. The client finally determines the clarity level by combining the results of bandwidth threshold judgment and cache judgment through a preset mapping table or algorithm.

[0034] For example, the following corresponding rule can be used to determine the clarity level: if the smoothed bandwidth value (Bi) is less than the first bandwidth threshold (L) and the remaining duration of the buffer is less than 5 seconds, the low clarity level is selected; if L ≤ Bi < the second bandwidth threshold (M) and the remaining duration of the buffer is less than 5 seconds, the low clarity level is selected; if L ≤ Bi < M and the remaining duration of the buffer is greater than or equal to 5 seconds, the medium clarity level is selected; if Bi ≥ M and the remaining duration of the buffer is greater than or equal to 5 seconds, the high clarity level is selected.

[0035] In step S204, the client sends a media segment request carrying the selected clarity level to the gateway device to obtain media data of the corresponding clarity.

[0036] Among them, the request contains information for indicating the clarity level, such as resolution, bandwidth, codec, etc., for the gateway device to send media data of the corresponding clarity to the client according to this information.

[0037] Optionally, after determining the appropriate resolution level, the client can select the most suitable resolution and codec based on the device's display capabilities, codec support, and current network conditions. For example, for users with small-screen devices or poor network conditions, the client may choose a lower resolution and lower bandwidth media stream to ensure smooth playback; while for users with large-screen devices and good network conditions, the client will choose a higher resolution and higher bandwidth media stream to provide a better picture quality experience.

[0038] According to one embodiment, the method further includes step S205 performed by the client.

[0039] In step S205, the client sends download speed parameters back to the gateway device.

[0040] Specifically, based on the monitored download speed, the corresponding download speed parameters are obtained and fed back to the gateway device.

[0041] The download rate parameters include various information that can be used to indicate the client's download speed or network conditions. Optionally, the download rate parameters include, but are not limited to, the average download speed, instantaneous download speed, and download speed fluctuation. The average download speed refers to the average rate at which the client downloads media data within a certain time window, reflecting the client's long-term network performance; the instantaneous download speed refers to the client's download speed at a specific moment, capturing instantaneous network fluctuations; and the download speed fluctuation describes how the client's download speed changes over time, and may include the amplitude and frequency of fluctuations, used to assess network stability.

[0042] Optionally, the download rate parameter may also include a smoothed bandwidth based on the average download rate.

[0043] Optionally, the client periodically reports download speed parameters to the gateway device.

[0044] Optionally, the client can send a media data request carrying download rate parameters to the gateway device to provide the download rate parameters.

[0045] In step S101, the gateway device obtains the download speed parameters fed back by the client.

[0046] Optionally, the download rate parameter is included in the media data request. Upon receiving a media data request from a client, the gateway device parses and obtains the client's download rate parameter. In this way, the gateway can promptly obtain the latest network status information each time a client requests media data.

[0047] For example, when a client constructs an m3u8 media segment request, it appends the download rate parameter as a query parameter to the request URL. Upon receiving the request, the gateway extracts the download rate parameter by parsing the request URL, thereby obtaining information related to the client's download rate.

[0048] In step S102, the gateway device obtains the corresponding media data based on the download rate parameters and local cache status by means of source retrieval or cache reuse.

[0049] Specifically, if the required media data (such as video segments in an m3u8 file) is not present in the cache or the data is invalid (such as expired or corrupted), the corresponding media data is retrieved from the origin server by performing a back-to-origin operation. If the required media data is present in the cache and the data is valid, the system decides whether to provide the corresponding media data from the cache based on the download speed reported by the client and its own caching strategy. Specifically, if the client's download speed is greater than or equal to a predetermined threshold, and the data in the cache can meet the client's playback requirements, the data is provided from the cache to reduce the number of back-to-origin operations and the amount of data, thereby improving response speed and system efficiency. If the client's download speed is less than the predetermined threshold, or the data in the cache is insufficient to support smooth playback for the client, the system retrieves the corresponding media data from the origin server to supplement the cache, ensuring that the client can play continuously and smoothly.

[0050] According to one embodiment, the validity of cached data is determined based on the tolerance cache duration of the requested media data, wherein the tolerance cache duration is dynamically adjusted according to the download speed most recently reported by the client.

[0051] The gateway device maintains a tolerance cache duration for each media data segment to determine the validity of the cached data. Specifically, the gateway device records the cache timestamp of each media data segment. When a client requests a media data segment, the gateway device calculates the time difference between the current time and the cache timestamp of that segment. If the time difference is less than or equal to the tolerance cache duration set for that segment, the cached data is considered still valid and can be directly provided to the client from the cache. Conversely, if the time difference exceeds the tolerance cache duration, the cached data is determined to be invalid, and the data for that segment needs to be retrieved again from the origin server.

[0052] The tolerance cache duration is dynamically adjusted based on the client's most recent reported download speed. Specifically, if the client's download speed is low (e.g., below a predetermined threshold), the tolerance cache duration is extended accordingly to prevent low-speed clients from frequently triggering origin pull operations due to premature cache expiration; conversely, if the client's download speed is high (e.g., above the predetermined threshold), the tolerance cache duration is shortened accordingly to ensure that high-speed clients can obtain the latest media data fragments in a timely manner.

[0053] According to one embodiment, the gateway device dynamically adjusts the priority and storage strategy of the cache based on changes in the download rate. For example, for popular content or high-priority media streams, the gateway device prioritizes ensuring sufficient caching even if the client's download rate is low, while for some less popular or low-priority content, the caching can be appropriately reduced as needed. As another example, when the overall download rate is detected to be consistently below a set threshold, the gateway device suppresses new origin pull concurrent connections and prioritizes reusing existing caches to prevent low-speed links from being further congested by origin pull traffic.

[0054] According to one embodiment, during the process of retrieving data from the source, the gateway device updates the newly acquired data into its local cache and maintains and manages the data in the cache. The gateway device can adopt a predetermined cache eviction policy (such as LRU, LFU, etc.) to periodically clean up infrequently used or expired data in the cache based on factors such as data access frequency and access time, so as to ensure the effective utilization of cache space.

[0055] In step S103, the corresponding smooth transmission rate is calculated based on the smooth bandwidth fed back by the client.

[0056] Specifically, the corresponding smooth transmission rate is calculated based on the current media file bitrate, the smooth bandwidth reported by the client, and the current occupancy rate of the gateway device's own cache. For example, the smooth transmission rate is calculated based on the following formula (2): smooth = min(file_bitrate, B_client) α + Buffer_Level β (2) Here, `file_bitrate` represents the bitrate of the current media file; `B_client` represents the smooth bandwidth reported by the client; `Buffer_Level` represents the current occupancy (or fill level) of the gateway device's own buffer; α and β are weighting coefficients, where α represents the degree of dependence on the client's smooth bandwidth. A higher weight means greater dependence on the client's real-time network status; β represents the degree of dependence on the current occupancy of the gateway's own buffer. A lower weight means that the current occupancy of the gateway's own buffer has less impact on the sending rate. For example, α and β values ​​are set to 0.9 and 0.1, respectively.

[0057] Using the formula described above, the gateway device can dynamically adjust the transmission rate based on the client's real-time network status and cache conditions. This dynamic adjustment mechanism effectively addresses network fluctuations, ensures smooth transmission of media data, reduces buffering, and improves user experience.

[0058] In step S104, based on the smooth transmission rate, the transmission rate of media data is controlled during the process of sending media data to the client.

[0059] According to one embodiment, the gateway device, based on the smooth transmission rate, performs traffic shaping processing using a token bucket algorithm during the process of sending media data to the client, thereby controlling the transmission rate of the media data.

[0060] Specifically, the gateway periodically issues tokens with a predetermined time precision (e.g., 50 milliseconds) based on the calculated smooth transmission rate. The number of bytes allowed to be transmitted within each token window is the smooth transmission rate divided by 20. This traffic shaping mechanism ensures that the media data transmission rate matches the client's network conditions and buffer status, thereby achieving smooth and stable media data transmission, reducing playback stuttering caused by network fluctuations, and improving the user experience. In this way, the gateway can dynamically adjust the transmission rate to adapt to different network environments, ensuring efficient transmission of media data.

[0061] According to one embodiment, traffic shaping can also be performed based on the Leaky Bucket Algorithm.

[0062] Specifically, the gateway device can be configured with a leaky bucket, whose output rate is a smooth transmission rate. After data enters the leaky bucket, it outputs the data to the client at a fixed rate. If the incoming data rate exceeds the leaky bucket's output rate, the excess data is discarded. The leaky bucket algorithm effectively smooths bursty traffic, ensuring data is output at a fixed rate and reducing network congestion. The gateway can dynamically adjust the leaky bucket's output rate based on network conditions reported by clients to adapt to different network environments.

[0063] According to the method of this application embodiment, the client monitors the download speed in real time and dynamically adjusts the clarity of the media data according to its own caching duration to adapt to network conditions; the gateway device receives the download speed parameters fed back by the client, perceives the network conditions of the client in real time, and adjusts its own sending rate accordingly to prevent further deterioration of network congestion; this application embodiment combines the caching status of the client and the server, and uses traffic shaping technology to perform smooth sending, ensuring stable transmission of media data; this application embodiment achieves smooth playback in complex network environments through the mechanism of gateway and client collaborative processing of media data, and can provide users with a high-quality media experience even in the event of traffic bursts or network fluctuations.

[0064] The following is combined with Figure 3 The examples shown are used to illustrate embodiments of this application.

[0065] Figure 3 This document illustrates an exemplary flowchart of a client and gateway processing m3u8 data according to an embodiment of this application. The method in this example is executed by a gateway and a client in a live streaming system, and the media data involved is an m3u8 file. m3u8, as a standard format based on the HTTP / HTTPS protocol, is widely used in streaming media transmission. In this example, the live streaming system supports multi-resolution m3u8 formats, meaning that when requesting and processing m3u8 files, it can dynamically select the appropriate resolution media stream for playback based on different network environments and user needs. The client can intelligently select the most suitable resolution based on the current network conditions and playback buffer status, thereby maximizing image quality while ensuring smooth playback, significantly enhancing the system's flexibility and user experience. For example, based on the following multi-resolution m3u8 formats, the client can request low-resolution, medium-resolution, and high-resolution media streams respectively: #EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=400000,RESOLUTION=240x136,CODECS="avc1.4d401f" low.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1200000,RESOLUTION=480x272,CODECS="avc1.4d401f" medium.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=720x406,CODECS="avc1.4d401f" high.m3u8 The `EXT-X-STREAM-INF` tag provides metadata about the media stream. This metadata includes information such as the stream's bandwidth, resolution, and codec. Clients can use this information to select the most suitable media stream based on current network conditions and device capabilities. `BANDWIDTH` indicates the average bitrate (bandwidth) of the media stream. `RESOLUTION` indicates the video resolution of the media stream. `CODECS` indicates the codec used by the media stream; `avc1.4d401f` mentioned above is a specific H.264 codec configuration.

[0066] The process of handling media data by the gateway and client in this example is shown below: Client Request: The client first calculates the average download rate over the past 5 seconds and determines the smoothing rate based on this average download rate using the smoothing calculation formula (1). Subsequently, the client performs a threshold judgment based on this smoothing rate: if the smoothing rate is higher than a predetermined threshold, it sends a request to the gateway for an m3u8 file, carrying the download rate parameter (e.g., downloadBitrate=3000kbps); if the smoothing rate is lower than the predetermined threshold, it determines the resolution appropriate for that smoothing rate and requests a segment of that resolution from the gateway. For example, when the client requests an m3u8 file, the format of the download rate parameter is as follows: https: / / domain:port / app / file / index.m3u8?downloadBitrate=3000kbps The process by which the client determines the appropriate resolution for the playback rate includes: adjusting the resolution selection strategy based on the remaining duration of the current playback buffer: if the remaining buffer duration is short (e.g., less than 5 seconds), a lower resolution level is preferred to ensure playback continuity; if the remaining buffer duration is long (e.g., more than 10 seconds), a higher resolution level can be appropriately selected to improve the user experience.

[0067] The gateway receives and processes requests: After receiving a request, the gateway decides whether to retrieve data from the origin server or directly from its local cache based on the parameters in the request and its own caching status. If it needs to retrieve data from the origin server, the gateway sends a request to the origin server to obtain the corresponding media data.

[0068] The client receives and responds to data: It receives media data sent by the gateway and stores it in the player's cache. Based on the download time of each segment, the client monitors the network bandwidth with the server in real time and sends this information back to the gateway.

[0069] The gateway performs calculations and traffic shaping: Based on the download time reported by the client, the client's caching status, and its own network speed perception, the gateway uses the above formula (2) to calculate the smooth transmission bit rate; based on the calculated smooth bit rate, it performs traffic shaping through the token bucket algorithm, issues tokens with a preset precision (such as 50ms), controls the data transmission rate, and achieves smooth transmission.

[0070] The gateway employs a token bucket algorithm for traffic shaping. Based on the calculated smooth bitrate, tokens are issued with a precision of 50ms to precisely control the data transmission rate. This fine-grained traffic shaping mechanism effectively avoids receive buffer overflow and packet loss, while also promptly replenishing data when user bandwidth recovers, fully utilizing bandwidth resources and reducing playback choppy situations.

[0071] Client-side playback: The client plays the data based on the cached data. Due to the gateway's smooth transmission and traffic shaping, the playback process is smoother and stuttering is reduced.

[0072] This example optimizes media data transmission and playback experience based on the m3u8 protocol through a collaborative mechanism between the client and the gateway. The client dynamically adjusts its resolution selection strategy based on the remaining duration of the playback buffer, ensuring continuous and smooth playback. The gateway intelligently decides the data acquisition method based on client requests and local cache status, achieving efficient distribution. The client monitors download time in real time and reports network conditions to the gateway, enabling the gateway to accurately perceive changes in network bandwidth. Based on this, the gateway calculates a smooth transmission bitrate and uses a traffic shaping algorithm to precisely control the data transmission rate, avoiding buffer overflows and packet loss. Simultaneously, it replenishes data promptly when bandwidth recovers, fully utilizing bandwidth resources and significantly reducing playback stuttering. The client plays based on cached data; thanks to the gateway's smooth transmission and traffic shaping mechanisms, the playback process is smoother, providing users with a high-quality viewing experience.

[0073] Figure 4 This illustration shows a schematic diagram of a first apparatus for processing media data in a gateway device and a second apparatus for processing media data in a client, according to embodiments of this application. The first apparatus includes a rate acquisition module 101, a media data acquisition module 102, a transmission rate calculation module 103, and a transmission rate control module 104. The second apparatus includes a rate monitoring module 201, a smooth bandwidth acquisition module 202, a resolution selection module 203, and a request transmission module 204.

[0074] Reference Figure 4 The rate monitoring module 201 responds to receiving media data from the gateway device and monitors the average download rate of the media data over a predetermined period of time.

[0075] Optionally, the monitoring accuracy and frequency of the average download speed can be dynamically adjusted according to different network environments. The higher the frequency, the more timely the perception of network status. For example, the monitoring accuracy can be set to kbps and the monitoring frequency to 200ms.

[0076] The smooth bandwidth acquisition module 202 performs smoothing processing to obtain the smooth bandwidth corresponding to the average download rate, and feeds back the smooth bandwidth to the gateway device.

[0077] The smoothing process is a weighted average calculation method based on historical and current data, which aims to reduce the impact of network fluctuations on download speed, thereby providing a more stable bandwidth estimate.

[0078] According to one embodiment, the smoothing bandwidth corresponding to the average download rate is calculated according to a preset smoothing calculation formula, which is based on the smoothing bandwidth of the previous moment, the download rate of the current segment, and a preset weighting coefficient. For example, the smoothing bandwidth (Bi) is calculated using the above formula (1).

[0079] The resolution selection module 203 dynamically selects a resolution level that matches the obtained smooth bandwidth.

[0080] According to one embodiment, the resolution selection module 203 maps smoothing bandwidth values ​​to different resolution levels based on a preset bandwidth threshold range. For example, if the smoothing bandwidth value is below the low threshold, a low resolution level is selected; if the smoothing bandwidth value is above the high threshold, a high resolution level is selected; and if the smoothing bandwidth value is between the two, a medium resolution level is selected.

[0081] According to one embodiment, the resolution selection module 203 dynamically selects a resolution level that matches the obtained smoothing bandwidth and the remaining duration of the current local playback buffer.

[0082] If the remaining buffer time is short (e.g., below the set buffer threshold), a lower resolution level is selected to ensure playback continuity; if the remaining buffer time is long, a higher resolution level can be selected to improve the user experience.

[0083] Specifically, the resolution selection module 203 obtains the remaining duration of the current local playback buffer. Then, based on a predetermined matching rule, it selects a resolution level that matches the smoothing bandwidth and buffering status. This matching rule can be implemented through a preset mapping table or algorithm to ensure that the most suitable resolution level is selected under different network and buffering conditions. The client, through the preset mapping table or algorithm, combined with the results of bandwidth threshold judgment and cache judgment, finally determines the resolution level.

[0084] For example, the following corresponding rules can be used to determine the clarity level: If the smooth bandwidth value (Bi) is less than the first bandwidth threshold (L) and the remaining duration of the buffer is less than 5 seconds, the low clarity level is selected; if L ≤ Bi < the second bandwidth threshold (M) and the remaining duration of the buffer is less than 5 seconds, the low clarity level is selected; if L ≤ Bi < M and the remaining duration of the buffer is greater than or equal to 5 seconds, the medium clarity level is selected; if Bi ≥ M and the remaining duration of the buffer is greater than or equal to 5 seconds, the high clarity level is selected.

[0085] The request sending module 204 sends a media fragment request carrying the selected clarity level to the gateway device to obtain media data of the corresponding clarity.

[0086] Among them, the request contains information for indicating the clarity level, such as resolution, bandwidth, codec, etc., for the gateway device to send media data of the corresponding clarity to the client according to this information.

[0087] Optionally, after determining the appropriate clarity level, the client combines the display capabilities of the device, the codec support situation, and the current network conditions to select the most suitable resolution and codec. For example, for small screen devices or users with poor network conditions, the client may select a media stream with a lower resolution and lower bandwidth to ensure smooth playback; while for users with large screen devices and good network conditions, the client will select a media stream with a higher resolution and higher bandwidth to provide a better picture quality experience.

[0088] According to one embodiment, the second device includes a rate feedback device.

[0089] The rate feedback device feeds back the download rate parameter to the gateway device.

[0090] Specifically, the rate feedback device obtains the corresponding download rate parameter based on the monitored download rate and feeds it back to the gateway device.

[0091] Among them, the download rate parameter includes various information that can be used to indicate the download rate or network situation of the client. Optionally, the download rate parameter includes but is not limited to the average download rate of the client downloading media data, the instantaneous download rate, and the fluctuation situation of the download rate, etc. Among them, the average download rate refers to the average rate at which the client downloads media data within a certain time window, which is used to reflect the long-term network performance of the client; the instantaneous download rate refers to the download rate of the client at a specific moment, which is used to capture the instantaneous fluctuations of the network; the fluctuation situation of the download rate is used to describe the change of the client's download rate over time, which may include the fluctuation amplitude and frequency, and is used to evaluate the stability of the network.

[0092] Optionally, the download rate parameter may also include a smoothed bandwidth based on the average download rate.

[0093] Optionally, the rate feedback device periodically feeds back download rate parameters to the gateway device.

[0094] Optionally, the rate feedback device sends a media data request carrying the download rate parameters to the gateway device.

[0095] Continue to refer to Figure 4 To explain, the rate acquisition module 101 acquires the download rate parameters fed back by the client.

[0096] Optionally, the download rate parameter is included in the media data request. The rate acquisition module 101, in response to receiving a media data request from the client, parses and obtains the client's download rate parameter. In this way, the gateway can promptly obtain the latest network status information each time a client requests media data.

[0097] For example, when a client constructs an m3u8 media segment request, it appends the download rate parameter as a query parameter to the request URL. After receiving the request, the gateway's rate acquisition module 101 extracts the download rate parameter by parsing the request URL, thereby obtaining the client's download rate-related information.

[0098] The media data acquisition module 102 acquires the corresponding media data based on the download rate parameters and local cache status by means of source retrieval or cache reuse.

[0099] Specifically, if the required media data (such as video segments in an m3u8 file) is not present in the cache or the data is invalid (such as expired or corrupted), the corresponding media data is retrieved from the origin server by performing a back-to-origin operation. If the required media data is present in the cache and the data is valid, the system decides whether to provide the corresponding media data from the cache based on the download speed reported by the client and its own caching strategy. Specifically, if the client's download speed is greater than or equal to a predetermined threshold, and the data in the cache can meet the client's playback requirements, the data is provided from the cache to reduce the number of back-to-origin operations and the amount of data, thereby improving response speed and system efficiency. If the client's download speed is less than the predetermined threshold, or the data in the cache is insufficient to support smooth playback for the client, the system retrieves the corresponding media data from the origin server to supplement the cache, ensuring that the client can play continuously and smoothly.

[0100] According to one embodiment, the media data acquisition module 102 determines whether the data in the cache is valid based on the tolerance cache duration of the requested media data, wherein the tolerance cache duration is dynamically adjusted according to the download speed most recently reported by the client.

[0101] The gateway device maintains a tolerance cache duration for each media data segment to determine the validity of the cached data. Specifically, the gateway device records the cache timestamp of each media data segment. When a client requests a media data segment, the gateway device calculates the time difference between the current time and the cache timestamp of that segment. If the time difference is less than or equal to the tolerance cache duration set for that segment, the cached data is considered still valid and can be directly provided to the client from the cache. Conversely, if the time difference exceeds the tolerance cache duration, the cached data is determined to be invalid, and the data for that segment needs to be retrieved again from the origin server.

[0102] The tolerance cache duration is dynamically adjusted based on the client's most recent reported download speed. Specifically, if the client's download speed is low (e.g., below a predetermined threshold), the tolerance cache duration is extended accordingly to prevent low-speed clients from frequently triggering origin pull operations due to premature cache expiration; conversely, if the client's download speed is high (e.g., above the predetermined threshold), the tolerance cache duration is shortened accordingly to ensure that high-speed clients can obtain the latest media data fragments in a timely manner.

[0103] According to one embodiment, the gateway device dynamically adjusts the priority and storage strategy of the cache based on changes in the download rate. For example, for popular content or high-priority media streams, even if the client's download rate is low, the gateway device prioritizes ensuring sufficient caching, while for some less popular or low-priority content, the caching can be appropriately reduced as needed. As another example, when the overall download rate is detected to be consistently below a set threshold, the gateway device suppresses new origin pull concurrent connections, and the media data acquisition module 102 prioritizes reusing existing cache to prevent low-speed links from being further congested by origin pull traffic.

[0104] According to one embodiment, during the process of retrieving data from the source, the gateway device updates the newly acquired data into its local cache and maintains and manages the data in the cache. The gateway device can adopt a predetermined cache eviction policy (such as LRU, LFU, etc.) to periodically clean up infrequently used or expired data in the cache based on factors such as data access frequency and access time, so as to ensure the effective utilization of cache space.

[0105] The transmission rate calculation module 103 calculates the corresponding smooth transmission rate based on the smooth bandwidth fed back by the client.

[0106] Specifically, the corresponding smooth transmission rate is calculated based on the current media file bitrate, the smooth bandwidth reported by the client, and the current occupancy rate of the gateway device's own cache. For example, the smooth transmission rate is calculated based on the above formula (2).

[0107] Using the formula described above, the gateway device can dynamically adjust the transmission rate based on the client's real-time network status and cache conditions. This dynamic adjustment mechanism effectively addresses network fluctuations, ensures smooth transmission of media data, reduces buffering, and improves user experience.

[0108] Based on the smooth transmission rate, the transmission rate control module 104 controls the transmission rate of media data during the process of sending media data to the client.

[0109] According to one embodiment, the transmission rate control module 104, based on the smooth transmission rate, performs traffic shaping processing through the token bucket algorithm during the process of sending media data to the client, thereby controlling the transmission rate of the media data.

[0110] Specifically, the transmission rate control module 104 periodically issues tokens with a predetermined time precision (e.g., 50 milliseconds) based on the calculated smooth transmission rate value. The number of bytes allowed to be transmitted within each token window is the smooth transmission rate divided by 20. This traffic shaping mechanism ensures that the transmission rate of media data matches the client's network conditions and buffer status, thereby achieving smooth and stable media data transmission, reducing playback stuttering caused by network fluctuations, and improving the user experience. In this way, the gateway can dynamically adjust the transmission rate to adapt to different network environments and ensure efficient transmission of media data.

[0111] According to one embodiment, the transmission rate control module 104 can also perform traffic shaping according to the Leaky Bucket Algorithm.

[0112] Specifically, the transmission rate control module 104 can be configured with a leaky bucket, whose output rate is a smooth transmission rate. After data enters the leaky bucket, it outputs the data to the client at a fixed rate. If the data inflow rate exceeds the leaky bucket's output rate, the excess data is discarded. The leaky bucket algorithm effectively smooths burst traffic, ensuring data is output at a fixed rate and reducing network congestion. The gateway can dynamically adjust the leaky bucket's output rate based on network conditions reported by the client to adapt to different network environments.

[0113] According to the apparatus of this application embodiment, the client monitors the download speed in real time and dynamically adjusts the clarity of the media data based on its own caching duration to adapt to network conditions; the gateway device receives the download speed parameters fed back by the client, perceives the network conditions of the client in real time, and adjusts its own sending rate accordingly to prevent further deterioration of network congestion; this application embodiment combines the caching status of the client and the server, and uses traffic shaping technology to perform smooth transmission, ensuring stable transmission of media data; this application embodiment achieves smooth playback in complex network environments through the mechanism of collaborative processing of media data by the gateway and the client, and can provide users with a high-quality media experience even in the event of traffic bursts or network fluctuations.

[0114] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0115] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0116] Figure 5The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 1202 or a program loaded from a storage portion 1208 into a Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0117] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 1208 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet.

[0118] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 1201, it performs the functions defined in the methods of this application.

[0119] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0120] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0121] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0122] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0126] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or page components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0127] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0128] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0129] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0131] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices described in an apparatus may also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A method for processing media data in a gateway device, wherein, The method comprises: acquiring a download rate parameter fed back by a client; acquiring corresponding media data by source retrieval or cache multiplexing based on the download rate parameter and a local cache state; calculating a corresponding smooth sending rate based on the smooth bandwidth fed back by the client; controlling the sending rate of the media data in the process of sending the media data to the client based on the smooth sending rate.

2. The method of claim 1, wherein, The calculation of the corresponding smooth sending rate based on the download rate parameter fed back by the client comprises: calculating the corresponding smooth sending rate according to the code rate of the current media file, the smooth bandwidth fed back by the client and the current occupancy rate of the cache of the gateway device.

3. The method of claim 1, wherein, The acquisition of the corresponding media data by the gateway device based on the download rate parameter and the local cache state through source retrieval or cache multiplexing comprises: if the required media data does not exist in the cache or the data is invalid, acquiring the corresponding media data from the source station by performing source retrieval, and if the required media data exists in the cache and the data is valid, deciding whether to provide the corresponding media data from the cache according to the download rate fed back by the client and the cache strategy of the gateway device.

4. The method of claim 3, wherein, The method further comprises: judging whether the data in the cache is valid based on the tolerance cache duration of the requested media data, which is dynamically adjusted according to the download rate fed back by the client last time.

5. The method of claim 1, wherein, The control of the sending rate of the media data in the process of sending the media data to the client based on the smooth sending rate comprises: controlling the sending rate of the media data in the process of sending the media data to the client by token bucket algorithm for traffic shaping processing based on the smooth sending rate.

6. A method for processing media data in a client, wherein, The method comprises: monitoring the average download rate of the media data in a predetermined period in the past in response to receiving the media data from the gateway device; obtaining a smooth bandwidth corresponding to the average download rate by performing smoothing processing, and feeding back the smooth bandwidth to the gateway device; dynamically selecting a definition level matching the bandwidth according to the obtained smooth bandwidth; sending a media segment request carrying the selected definition level to the gateway device to acquire media data of the corresponding definition.

7. The method of claim 6, wherein, The obtaining of the smooth bandwidth corresponding to the average download rate by performing smoothing processing comprises: calculating the smooth bandwidth corresponding to the average download rate according to a preset smoothing calculation formula, wherein the smoothing calculation formula is calculated based on the smooth bandwidth of the previous moment, the current average download rate and a preset weight coefficient.

8. The method of claim 6, wherein, The dynamic selection of the definition level matching the bandwidth according to the obtained smooth bandwidth comprises: mapping the smooth bandwidth value to different definition levels based on a preset bandwidth threshold range.

9. The method of claim 6, wherein, The dynamic selection of the definition level matching the bandwidth according to the obtained smooth bandwidth comprises: dynamically selecting a definition level matching the smooth bandwidth and the buffer state according to the obtained smooth bandwidth and the current local playback buffer remaining duration.

10. The method of claim 9, wherein, The dynamic selection of the definition level matching the smooth bandwidth and the buffer state according to the smooth bandwidth value and the current local playback buffer remaining duration comprises: acquiring the current local playback buffer remaining duration; Based on a predetermined corresponding rule, a definition level matching the smooth bandwidth and the buffer status is selected.

11. A first apparatus for processing media data in a gateway device, wherein, The first device comprises: a rate obtaining module configured to obtain a download rate parameter fed back by the client; a media data obtaining module configured to obtain corresponding media data by means of source retrieval or cache multiplexing based on the download rate parameter and a local cache status; a sending rate calculating module configured to calculate a corresponding smooth sending rate based on a smooth bandwidth fed back by the client; a sending rate controlling module configured to control a sending rate of the media data in the process of sending the media data to the client based on the smooth sending rate.

12. A second apparatus for processing media data in a client, wherein, The second device comprises: a rate monitoring module configured to monitor an average download rate of the media data in a past predetermined period in response to receiving the media data from the gateway device; a smooth bandwidth obtaining module configured to obtain a smooth bandwidth corresponding to the average download rate by performing a smoothing process, and feed back the smooth bandwidth to the gateway device; a definition level selecting module configured to dynamically select a definition level matching the bandwidth according to the obtained smooth bandwidth; a request sending module configured to send a media segment request carrying the selected definition level to the gateway device to obtain media data of a corresponding definition level.

13. A media data processing system, wherein, The system comprises the first device according to claim 11 and the second device according to claim 12. 14.An electronic device, comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 10. 15.A computer readable medium having stored thereon computer program instructions executable by a processor to implement the method of any one of claims 1 to 10. 16.A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 10.

Images