DASH protocol playing method, system, device and medium in distributed cloud scenario

Abstract

The application discloses a playing method, system, device and medium of a DASH protocol in a distributed cloud scenario. The method comprises the following steps: in response to a playing instruction, analyzing the playing instruction to determine a corresponding channel, and requesting a node list corresponding to the channel from a control center of the distributed cloud; the node list comprises at least one service group, and the service group comprises one large node and multiple small nodes; receiving the node list, requesting a multimedia playing descriptor file from the large node in the node list, and recording multiple representative identifiers in the multimedia playing descriptor file, wherein the representative identifiers are used for indicating the small nodes storing video clips with corresponding code rates; determining a current code rate of the channel and a corresponding representative identifier based on the multimedia playing descriptor file and a state of a playing terminal; and acquiring the video clip from the corresponding small node based on the representative identifier. The application can support stable services of the DASH protocol multi-code rate multi-path flow by overall scheduling of the control center, cooperation of the large node, the small node and the playing terminal.

Description

Technical Field

[0001] This application relates to the field of distributed cloud, and in particular to a method, system, device and medium for playing DASH protocol in a distributed cloud scenario. Background Technology

[0002] As the DASH protocol is increasingly used in current video-on-demand and live streaming, it distributes content through adaptive, progressive, download, or streaming methods, making it more adaptable to network conditions and providing users with a better video experience.

[0003] Distributed clouds have servers of various types and environments, but the capacity, reliability and stability of these servers are worse than those of centralized clouds. They cannot meet the requirements of the DASH protocol for server nodes. In particular, the bandwidth of small nodes is relatively small and cannot support multi-bitrate multi-streams. Therefore, the current distributed cloud scenario cannot support the DASH protocol to provide stable services for multi-bitrate multi-streams. Summary of the Invention

[0004] This application mainly provides a method, system, device, and medium for playing DASH protocol in a distributed cloud scenario, in order to solve the problem that the current distributed cloud scenario cannot support the DASH protocol to provide stable services for multiple bitrate and multiple streams.

[0005] To address the aforementioned technical problems, this application adopts the following technical solution: A method for playing DASH protocol in a distributed cloud scenario is provided, applied to a playback terminal. This method includes:

[0006] In response to a playback command, the system parses the playback command to determine the corresponding channel and requests a list of nodes corresponding to the channel from the control center of the distributed cloud. The node list contains at least one service group, and the service group contains a large node and multiple small nodes.

[0007] Upon receiving the node list, a multimedia playback descriptor file is requested from the large node in the node list. The multimedia playback descriptor file contains multiple representative identifiers, which are used to indicate the small node that stores a video segment with a corresponding bitrate.

[0008] The current bitrate of the channel and its corresponding representative identifier are determined based on the multimedia playback descriptor file and the state of the playback terminal.

[0009] The video segment is obtained from the corresponding sub-node based on the representative identifier.

[0010] In an optional embodiment of this application, the playback method of the DASH protocol in the distributed cloud scenario further includes:

[0011] In response to the playback terminal switching bitrate, the representative identifier corresponding to the new bitrate is determined based on the multimedia playback descriptor file;

[0012] Based on the new representative identifier, a new video segment is obtained from the corresponding small node, and the new video segment is played after the video segment corresponding to the previous bitrate.

[0013] In one optional embodiment of this application, the large node stores the start header of the channel;

[0014] After receiving the node list, the system also requests the channel start header from the large node;

[0015] Play the starter, and simultaneously obtain the video segment from the corresponding sub-node based on the determined representative identifier. The video segment is used to continue playback from the starter.

[0016] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a method for playing the DASH protocol in a distributed cloud scenario, applied to a cloud server, wherein the cloud server includes a control center, multiple large nodes, and multiple small nodes, and the method for playing the DASH protocol in the distributed cloud scenario includes:

[0017] In response to the node list request, the control center returns the node list to the playback terminal;

[0018] In response to a multimedia playback descriptor file request, the large node queries its local cache to see if a multimedia playback descriptor file exists; if so, it returns the multimedia playback descriptor file to the playback terminal; if not, it requests the multimedia playback descriptor file from the origin server, caches the multimedia playback descriptor file locally, and returns it to the playback terminal.

[0019] In response to a video clip request, the small node checks if a video clip exists in its local cache; if so, it returns the video clip to the playback terminal; if not, it requests the video clip from the associated large node, caches the received video clip locally, and returns it to the playback terminal.

[0020] In an optional embodiment of this application, after the large node requests the multimedia playback descriptor file from the source server, the playback method of the DASH protocol in the distributed cloud scenario further includes:

[0021] The multimedia playback descriptor file is parsed to obtain all the video segments corresponding to the bitrate, and the video segments are requested from the origin server and cached locally.

[0022] In an optional embodiment of this application, the playback method of the DASH protocol in the distributed cloud scenario further includes:

[0023] The large node periodically requests the multimedia playback descriptor file from the origin server and updates the video segment in its local cache based on the multimedia playback descriptor file.

[0024] In an optional embodiment of this application, the playback method of the DASH protocol in the distributed cloud scenario further includes:

[0025] The large node and the small node periodically report service information to the control center;

[0026] After receiving the service information, the control center updates the association between the large node and the small node based on the service information.

[0027] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a playback system of DASH protocol in a distributed cloud scenario. The playback system of DASH protocol in a distributed cloud scenario includes a playback terminal and a cloud server. The playback terminal is communicatively connected to the cloud server. The cloud server includes a control center, multiple large nodes and multiple small nodes.

[0028] The playback terminal is configured to respond to a playback command, parse the playback command to determine the corresponding channel, and request a node list corresponding to the channel from the control center; the node list includes at least one service group, the service group includes a large node and multiple small nodes; upon receiving the node list, it requests a multimedia playback descriptor file from the large node in the node list, the multimedia playback descriptor file containing multiple representative identifiers, the representative identifiers being used to indicate the small node storing a video segment with a corresponding bitrate; based on the multimedia playback descriptor file and the state of the playback terminal, it determines the current bitrate of the channel and its corresponding representative identifier; and based on the representative identifier, it obtains the video segment from the corresponding small node.

[0029] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a computer device, including a memory, a processor and a computer program stored in the memory, characterized in that the processor executes the computer program to implement the steps of the DASH protocol playback method in the distributed cloud scenario described above.

[0030] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a computer-readable storage medium storing a computer program thereon, characterized in that the computer program, when executed by a processor, implements the steps of the playback method of the DASH protocol in the distributed cloud scenario described above.

[0031] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a method, system, device, and medium for playing DASH protocol in a distributed cloud scenario. This method involves the playback terminal parsing a playback instruction upon receiving it to determine the corresponding channel, and then requesting a list of nodes corresponding to the channel from the control center of the distributed cloud. The node list includes at least one service group, which contains a large node and multiple small nodes. After receiving the node list, the playback terminal requests a multimedia playback descriptor file from the large node in the list to determine the small node corresponding to each representative identifier. After determining the current bitrate of the channel and its corresponding representative identifier, the playback terminal obtains video segments from the corresponding small nodes for playback. This method, through overall scheduling and coordination by the control center, allows the large and small nodes to work together with the playback terminal to support stable multi-bitrate, multi-stream services of the DASH protocol. Small nodes can provide single-bitrate stream services, improving service stability and increasing the transmission efficiency of the video stream. Attached Figure Description

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

[0033] Figure 1 This is a schematic diagram of the playback process of the DASH protocol playback method in a distributed cloud scenario provided in this application.

[0034] Figure 2 This is a schematic diagram of the distributed cloud architecture of Embodiment 1 of the playback method of DASH protocol in a distributed cloud scenario provided in this application;

[0035] Figure 3 This is a schematic diagram of the service group structure of an embodiment of the playback method of the DASH protocol in a distributed cloud scenario provided in this application;

[0036] Figure 4 This is a schematic diagram of the bitrate switching process of Embodiment 1 of the playback method of DASH protocol in a distributed cloud scenario provided in this application;

[0037] Figure 5 This is a schematic diagram of the playback terminal response during bitrate switching in Embodiment 1 of the playback method of DASH protocol in a distributed cloud scenario provided in this application;

[0038] Figure 6This is a flowchart illustrating Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application;

[0039] Figure 7 This is a schematic diagram of the node reporting process in Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application;

[0040] Figure 8 This is a schematic diagram of the large node service process of Embodiment 2 of the DASH protocol playback method in the distributed cloud scenario provided in this application;

[0041] Figure 9 This is a schematic diagram of the small node service process of Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application;

[0042] Figure 10 This is a flowchart illustrating the playback method of the DASH protocol in a distributed cloud scenario provided in this application;

[0043] Figure 11 This is a schematic diagram of the structure of the DASH protocol playback system in a distributed cloud scenario provided in this application, which is a third embodiment of the system. Detailed Implementation

[0044] 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 a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0045] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0046] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0047] To facilitate understanding of the playback method, system, device, and medium of the DASH protocol in a distributed cloud scenario provided in this application, some background terms used in this application will be introduced below:

[0048] Distributed cloud is a cloud model in which public cloud services are distributed to different physical locations by a cloud service provider (CSP). The CSP is responsible for the operation, governance, updates and evolution of the cloud services, and the geographical location of cloud service delivery is part of its definition.

[0049] The Distributed Cloud Control Center is the core management hub of the distributed cloud architecture. It is responsible for the unified management and control of resources distributed across the edge, local data centers, public cloud regions, and various heterogeneous nodes, while providing global scheduling, policy enforcement, security governance, and automated operation and maintenance capabilities. Essentially, it is a distributed control plane that implements a "physically distributed, logically centralized" management model through software-defined methods.

[0050] Big Node: A service node located in a network edge data center, offering good performance and stability.

[0051] Small nodes are located at the end of the network and are typically home devices such as routers, NAS devices, or PCs with P2P capabilities. These nodes generally have relatively poor performance and stability.

[0052] DASH (Dynamic Adaptive Streaming over HTTP) is a dynamic adaptive streaming media protocol based on HTTP. It is a video streaming technology that transmits video content at dynamic bitrates over the Internet, similar to Apple's HLS (HTTP Live Streaming). DASH slices video content into short video segments using a media presentation description (MPD). Each segment has multiple different bitrates, and the DASH client can select a bitrate to play based on network conditions, supporting seamless switching between different bitrates.

[0053] Multimedia playback descriptor file (MPD file): This is the core configuration file of the DASH protocol. It adopts XML format and is used to describe metadata such as the structure of streaming media content, available bitrate, segmentation information and encryption method. The client (player) dynamically requests and plays media content by parsing the MPD file.

[0054] Video segment (MPEG-4 Segment, M4S): is a media segmentation format used in streaming media technology for the DASH (MPEG-DASH) protocol. It stores a single segment of video or audio data. A stream of one bitrate is composed of individual M4S files. It is a core component of modern adaptive streaming media and is designed for efficient transmission and dynamic bitrate switching.

[0055] Example 1

[0056] This application provides a method for playing DASH protocol in a distributed cloud scenario, applied to a playback terminal, with reference to... Figure 1 , Figure 1 This is a schematic diagram of the playback process of the DASH protocol playback method in a distributed cloud scenario provided in this application, which includes:

[0057] S10: In response to a playback command, parse the playback command to determine the corresponding channel, and request the node list corresponding to the channel from the control center of the distributed cloud. The node list contains at least one service group, and each service group contains a large node and multiple small nodes.

[0058] Because existing distributed cloud technologies employ various types of servers in diverse environments, their capacity, reliability, and stability are inferior to those of centralized clouds, failing to meet the DASH protocol's requirements for server nodes. Therefore, referring to... Figure 2 , Figure 2This is a schematic diagram of the distributed cloud architecture of Embodiment 1 of the DASH protocol playback method in a distributed cloud scenario provided in this application. The distributed cloud of this application includes a control center, multiple large nodes and multiple small nodes. All large nodes and small nodes periodically report service information (including node performance, load, location, resources owned, etc.) to the control center. The control center organizes and classifies the large nodes and small nodes according to the reported service information, and associates the small nodes with the large nodes to form a service group. Each service group contains a large node and multiple small nodes. The playback terminal requests data from the large and small nodes that provide services for the corresponding channel to achieve playback.

[0059] Reference Figure 3 , Figure 3 This is a schematic diagram of the service group structure of an embodiment of the DASH protocol playback method in a distributed cloud scenario provided in this application. Based on the channel's popularity, each DASH channel is served by one or more service groups. A service group contains a large node and a group of small nodes representing each bitrate. It's important to note that a small node only provides a single bitrate stream service, but a single bitrate stream service can be provided by multiple small nodes (small node groups). For example, normally one service group can serve all bitrate streams of a complete DASH channel; however, when the channel is popular, multiple service groups can also serve all bitrate streams of a DASH channel.

[0060] When a playback terminal wants to play a video, it sends a playback command to the playback terminal SDK. Upon receiving the playback command, the playback terminal SDK begins requesting the corresponding service from the distributed cloud via the network. Specifically, when requesting data from the server, the playback terminal SDK provides the underlying network capabilities, while the playback terminal handles user interaction and business logic. The communication and interaction with the distributed cloud is handled by the playback terminal SDK. For ease of reference, this application collectively refers to both the playback terminal and the playback terminal SDK as the playback terminal; for example, most media players integrate a player SDK internally. However, it should be noted that there is a communication and interaction process between the playback terminal and the playback terminal SDK, including the playback terminal receiving the user's interaction request to play the video, sending a playback command to the playback terminal SDK, and the playback terminal SDK receiving a video segment and sending it to the playback terminal, where the playback terminal renders the video for playback.

[0061] In step S10 above, in response to the playback command, the playback terminal parses the playback command, which contains the channel requested by the user. After determining the channel, the playback terminal requests the list of nodes corresponding to the channel from the control center of the distributed cloud, that is, requests to obtain all service groups serving the channel.

[0062] S20: Receive the node list and request a multimedia playback descriptor file from the larger nodes in the list. The multimedia playback descriptor file contains multiple representative identifiers, which indicate smaller nodes that store video segments with corresponding bitrates.

[0063] In step S20 above, after receiving the node list returned by the control center, the playback terminal parses the node list to determine the major nodes in the list, and then requests the multimedia playback descriptor file (MPD file) corresponding to the current channel from the major nodes, reading the representation ID recorded in the multimedia playback descriptor file. When the channel is popular, multiple service groups may provide services for a channel, that is, there are multiple major nodes in the node list. In this case, the multimedia playback descriptor file is still requested from each major node.

[0064] The Representation ID is a key field used to uniquely identify different encoded versions of the same content (such as different bitrates, resolutions, or encoding formats). It directly affects the switching logic of adaptive streaming media, and each Representation ID corresponds to an independent video / audio stream. Since the representation ID corresponds one-to-one with various bitrates in a channel, and a small node only provides services corresponding to one bitrate, there is a one-to-one association between the representation ID and the small node. The representation ID can be used to indicate to the small node that stores the video clip (M4S file) with the corresponding bitrate, allowing the playback terminal to determine the object requesting the video clip with that bitrate.

[0065] S30: Determine the current bitrate of the channel and its corresponding representative identifier based on the multimedia playback descriptor file and the status of the playback terminal.

[0066] In step S30 above, the state of the playback terminal can be the network state of the playback terminal. For example, if the current network state is poor, the playback terminal automatically sets the bitrate of the current playback channel to a low bitrate. For example, the video software automatically sets the resolution to 480P based on the current poor network state, and automatically adjusts it to 1080P after the network state improves. The state of the playback terminal can also be a state manually adjusted by the user. For example, if the user wants to watch a 720p resolution video, they can manually switch the bitrate.

[0067] The playback terminal determines the current bitrate of the channel based on its own status, determines the representative identifier corresponding to the current bitrate based on the multimedia playback description file, and also determines from which video segment to start playback based on the multimedia playback description file, thereby supporting requests for subsequent video segments.

[0068] S40: Obtain video segments from the corresponding sub-nodes based on the representative identifier.

[0069] In step S40 above, the playback terminal, based on the representative identifier, confirms the small node that stores the video segment (M4S file) with the corresponding bitrate, and obtains the video segment to be played from the small node.

[0070] In this application, reference is made to Figure 4 , Figure 4 This is a schematic diagram of the bitrate switching process in Embodiment 1 of the DASH protocol playback method in a distributed cloud scenario provided in this application. The DASH protocol playback method in a distributed cloud scenario also includes:

[0071] S41: In response to the playback terminal switching bitrates, determine the representative identifier corresponding to the new bitrate based on the multimedia playback descriptor file.

[0072] S42: Obtain a new video segment from the corresponding small node based on the new representative identifier. The new video segment is played after the video segment corresponding to the previous bitrate.

[0073] When playing content on a channel, such as watching a live stream, users may switch bitrates due to reasons like resolution, or the playback terminal may automatically switch bitrates due to network quality issues. Whenever the bitrate switches, it means the playback terminal can no longer retrieve video segments from the sub-nodes storing the old bitrate's corresponding video segments and needs to re-match the sub-nodes corresponding to the new bitrate. At this time, the playback terminal determines the representative identifier corresponding to the new bitrate based on the multimedia playback descriptor file, and then requests the video segment from the sub-node corresponding to that representative identifier.

[0074] It's important to note that the playback terminal continuously requests video segments for playback. Each video segment requires a separate request. When the playback terminal doesn't switch bitrates, it continuously requests video segments from the same sub-node. When a bitrate is switched, the playback terminal requests the next video segment from the sub-node corresponding to the new bitrate. However, to maintain playback continuity, the playback terminal won't switch bitrates within a video segment; it will only switch to the new bitrate when requesting the next video segment. For example, if a video segment is 5 seconds long, and the user switches the bitrate after 2 seconds, the playback terminal won't immediately switch the bitrate of that segment. Instead, it will wait until the 5-second video segment ends and then switch bitrate when playing the next video segment.

[0075] Reference Figure 5 , Figure 5This is a flowchart illustrating the playback terminal's response during bitrate switching in Embodiment 1 of the DASH protocol playback method in a distributed cloud scenario provided in this application. First, after receiving a video segment (M4S file) request, the playback terminal parses the request to obtain the representative identifier corresponding to the video segment. Then, it determines whether the representative identifier has changed, i.e., whether a bitrate switch has occurred. If the representative identifier has not changed, it continues to request video segments from the small nodes of the current network connection. If the representative identifier has changed, it determines the representative identifier corresponding to the new bitrate based on the multimedia playback descriptor file, and obtains the new video segment from the corresponding small node based on the new representative identifier.

[0076] Unlike existing technologies, the DASH protocol playback method in the distributed cloud scenario provided in this application determines the representative identifier corresponding to the new bitrate through the multimedia playback descriptor file when the playback terminal switches the bitrate. This determines the new small node that provides services for the new bitrate, and then requests the video segment after the bitrate switch from the new small node. Each small node only provides the corresponding service for its corresponding bitrate. When switching the bitrate, the small node that provides the corresponding service is directly replaced, making the playback process more stable.

[0077] In this application, the playback method of the DASH protocol in a distributed cloud scenario also includes that the large node stores the start header of the channel;

[0078] After receiving the list of nodes, it also requests the channel start header from the major node;

[0079] Play the starter and simultaneously retrieve video segments from the corresponding sub-nodes based on the determined representative identifier. These video segments are used to continue playback from the starter.

[0080] In this application, the large node is responsible for sending the complete DASH stream back to the source server and providing playback initiation services to the playback terminal. When the playback terminal starts playing a channel, it first requests the start playback data (i.e., the start header) from the large node in the node list. While receiving and playing the start header, the playback terminal also needs to request the video segment of that channel for playback. That is, it simultaneously obtains the video segment from the corresponding small node based on a determined representative identifier. After receiving the video segment, the playback terminal continues playback of that video segment after the start header has finished playing.

[0081] In a streaming media or network service architecture, the origin server is the server responsible for storing and distributing raw content (such as video files and live streams) and providing data directly to edge nodes or clients upon receiving a request. Typically, when an edge node, caching server, or client requests a resource, if it is not cached locally or the cache has expired, it will eventually return to the origin server to obtain the latest data.

[0082] Unlike existing technologies, the DASH protocol playback method in the distributed cloud scenario provided in this application also provides a start-up service for large nodes, which store the start-up headers of the channels they serve. After receiving the node list, the playback terminal requests the start-up headers of the channels from the large node, and then plays the start-up headers. At the same time, based on a determined representative identifier, it obtains video segments from the corresponding small nodes and plays the video segments by continuing the start-up headers, thus ensuring the smoothness and integrity of video playback.

[0083] Unlike existing technologies where a single node cannot meet the requirements of the DASH protocol, and where small nodes have limited bandwidth and cannot support simultaneous multi-bitrate DASH stream services, this application discloses a playback method for the DASH protocol in a distributed cloud scenario. This method involves the playback terminal receiving a playback instruction, parsing the instruction to determine the corresponding channel, and requesting a list of nodes corresponding to the channel from the control center of the distributed cloud. The node list contains at least one service group, which includes a large node and multiple small nodes. Upon receiving the node list, the playback terminal requests a multimedia playback descriptor file from the large node in the list to determine the small node corresponding to each representative identifier. After determining the current bitrate of the channel and its corresponding representative identifier, the playback terminal obtains video segments from the corresponding small nodes for playback. This method, through overall scheduling and coordination by the control center, allows large nodes, small nodes, and the playback terminal to work together to support stable multi-bitrate, multi-stream services of the DASH protocol. Small nodes can provide single-bitrate stream services, improving service stability and increasing video stream transmission efficiency.

[0084] Example 2

[0085] This application provides a method for playing DASH protocol in a distributed cloud scenario, applied to a cloud server. The cloud server includes a control center, multiple large nodes, and multiple small nodes, as described above. Figure 6 , Figure 6 This is a flowchart illustrating Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application. The DASH protocol playback method in this distributed cloud scenario includes:

[0086] S50: In response to the node list request, the control center returns the node list to the playback terminal.

[0087] In this application, the cloud server is the cloud server that provides distributed cloud services, which includes a control center, multiple large nodes and multiple small nodes. The control center communicates with all large nodes and small nodes, and the large nodes communicate with their associated small nodes.

[0088] In this application, the playback method of the DASH protocol in a distributed cloud scenario also includes:

[0089] Large and small nodes periodically report service information to the control center;

[0090] After receiving the service information, the control center updates the relationship between the large and small nodes based on the service information.

[0091] In this application, reference is made to Figure 7 , Figure 7 This is a schematic diagram of the node reporting process in Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application. In the distributed cloud service, all large and small nodes periodically report service information (i.e., service capabilities, including node performance, load, location, and resources) to the control center. The control center organizes and categorizes the large and small nodes based on the reported service information, and then associates them. The playback terminal can request services or resources from the control center, such as requesting a service list, and then request data streams from the large and small nodes based on the service list returned by the control center to achieve channel playback. The association between large and small nodes is dynamic. After each large and small node reports service information to the control center, the control center must reorganize and categorize the large and small nodes based on the service information, and then re-associate them to ensure that the large and small nodes can provide the corresponding services normally.

[0092] Unlike existing technologies, the DASH protocol playback method in the distributed cloud scenario provided in this application uses a control center to coordinate the large and small nodes to provide services. Furthermore, it dynamically adjusts the relationship between the large and small nodes based on the service information periodically reported by the large and small nodes, thus supporting the stable provision of playback services by the large and small nodes.

[0093] In step S50 above, the control center receives a node list request sent by the playback terminal. The request contains the channel that the playback terminal is currently requesting to play. The control center determines one or more service groups that serve the channel and returns a node list containing all large and small nodes in the service group to the playback terminal.

[0094] When the service group of a channel changes, for example, if a node suddenly fails and the playback terminal experiences a playback error, it will send a node list request to the control center again. The control center will re-associate the relationships between large and small nodes based on the service information reported by the large and small nodes, update the service group of the channel, and return the updated node list of the channel to the playback terminal, so that the new service group can continue to provide playback services for the channel.

[0095] S60: In response to a multimedia playback descriptor file request, the large node checks whether a multimedia playback descriptor file exists in its local cache.

[0096] S61: If so, return the multimedia playback descriptor file to the playback terminal.

[0097] S62: If not, request a multimedia playback descriptor file from the source server, cache the multimedia playback descriptor file locally, and return it to the playback terminal.

[0098] In this application, the data cached locally in the large node includes multimedia playback descriptor files (MPD files) and video clips (M4S files). During caching, the multimedia playback descriptor files and video clips are cached separately. When the large node receives a data request, it first checks whether the corresponding data exists in the local cache. If it does, it directly returns the requested data; otherwise, it requests the corresponding data from the origin server and then returns it.

[0099] In step S60 above, after receiving the multimedia playback descriptor file request, the large node first checks whether the multimedia playback descriptor file exists in its local cache. If it exists, step S61 is executed, directly returning the multimedia playback descriptor file to the playback terminal; if it does not exist, step S62 is executed, requesting the multimedia playback descriptor file from the origin server, caching the multimedia playback descriptor file locally, and then returning it to the playback terminal. Steps S61 and S62 are executed in parallel and have no sequential order.

[0100] In this application, after the large node requests the multimedia playback descriptor file from the origin server, the playback method of the DASH protocol in a distributed cloud scenario also includes:

[0101] The multimedia playback descriptor file is parsed to obtain video segments corresponding to all bitrates. The video segments are then requested from the origin server and cached locally.

[0102] In this application, in addition to providing the playback terminal with the service of starting the playback, the large node can also provide a backup service. That is, the large node also caches the video segments corresponding to all bitrates of the corresponding channel. In case the playback terminal fails to request the video segment from the small node, the small node can request the video segment from the large node again to return it to the playback terminal.

[0103] After the large node requests the multimedia playback descriptor file from the origin server, it also parses the multimedia playback descriptor file to determine the video segments corresponding to the bitrates of all representative identifiers, and promptly requests these video segments from the origin server and downloads and caches them locally.

[0104] Unlike existing technologies, the DASH protocol playback method in the distributed cloud scenario provided in this application involves the large node requesting a multimedia playback descriptor file from the origin server, then parsing the multimedia playback descriptor file to obtain all video segments corresponding to the bitrate, requesting the video segments from the origin server and caching them locally. This preloading method provides a backup service for the playback terminal, facilitating a rapid response when requesting video segments later.

[0105] In this application, the playback method of the DASH protocol in a distributed cloud scenario also includes:

[0106] Large nodes periodically request multimedia playback descriptor files from the origin server and update the video segments in their local cache based on the multimedia playback descriptor files.

[0107] In this application, the large node distinguishes between multimedia playback descriptor files and video segments when caching data. If the cached data is a multimedia playback descriptor file, the multimedia playback descriptor file will be refreshed periodically. That is, the multimedia playback descriptor file will be requested from the origin server periodically. Each time a new multimedia playback descriptor file is requested, it will be parsed. Based on the new multimedia playback descriptor file, the new video segments corresponding to the bitrates marked with all representative identifiers will be determined. These new video segments will be requested from the origin server and downloaded and cached locally, that is, the video segments in the local cache will be updated.

[0108] For example, when watching a live stream, a large node refreshes the multimedia playback descriptor file to ensure the live stream continues indefinitely, and allows the playback terminal to start playback from any position. When the multimedia playback descriptor file is refreshed, the video segments corresponding to the bitrates marked therein are constantly changing, and only the most recent few video segments are recorded. Data that has finished playing is discarded.

[0109] Unlike existing technologies, the DASH protocol playback method in the distributed cloud scenario provided in this application involves large nodes periodically requesting multimedia playback descriptor files from the source server and updating the video segments in the local cache according to the multimedia playback descriptor files. This supports the continuity and stability of video playback and facilitates rapid response to continuous video segment requests.

[0110] In this application, the data requests received by the large node may fall into two categories: one is a multimedia playback descriptor file (MPD file) request, and the other is a video segment (M4S file) request. (See reference...) Figure 8 , Figure 8 This is a schematic diagram of the large node service process in Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application. First, after receiving a data request, the large node checks whether the corresponding data exists in its local cache. If it exists, it can directly return the requested data. If it does not exist, it needs to obtain the corresponding data from the origin server before returning it. Then, the large node also needs to parse whether the data obtained from the origin server is an MPD file or a video clip. If it is a video clip, it caches the video clip locally after returning it. If it is an MPD file, it downloads and caches all video clips corresponding to the bitrates marked in the MPD file, and refreshes the MPD file periodically.

[0111] S70: In response to a video clip request, the small node checks if a video clip exists in its local cache; if so, it returns the video clip to the playback terminal; if not, it requests a video clip from the associated large node, caches the received video clip locally, and returns it to the playback terminal.

[0112] After the large node parses the multimedia playback description file to determine the video segments corresponding to the bitrates of all representative identifiers, requests these video segments from the origin server and downloads and caches them locally, it can also distribute the corresponding video segments to the corresponding small nodes for local caching according to the bitrate of different representative identifiers. The small nodes only store the video segments with their corresponding bitrates.

[0113] In step S70 above, when the playback terminal requests a video segment with the corresponding bitrate from the smaller node, the smaller node first checks if the corresponding video segment exists in its local cache. If it exists, step S71 is executed, and the video segment is directly returned to the playback terminal. If it does not exist, step S72 is executed, and the smaller node also needs to request the video segment from the larger node. After receiving the video segment returned by the larger node, the smaller node returns the received video segment to the playback terminal and caches it locally. When requesting a video segment from the larger node, since the larger node has locally cached the new video segments corresponding to all the bitrates marked with representative identifiers, it can respond quickly and provide backup service for playback. Steps S71 and S72 are executed in parallel and have no sequential order.

[0114] Reference Figure 9 , Figure 9 This is a schematic diagram of the small node service process in Embodiment 2 of the DASH protocol playback method in a distributed cloud scenario provided in this application. After receiving a video segment request, the small node first checks whether the corresponding video segment exists in its local cache. If it exists, it directly returns the requested video segment to the playback terminal. If it does not exist, it also needs to request the corresponding video segment from the associated large node, and then return the received video segment to the playback terminal, while also caching the video segment locally.

[0115] Unlike existing technologies where a single node cannot meet the requirements of the DASH protocol, and where small nodes have limited bandwidth and cannot support simultaneous multi-bitrate DASH stream services, this application discloses a playback method for the DASH protocol in a distributed cloud scenario. This method dynamically associates large and small nodes through a control center to form service groups that provide multi-bitrate stream services for a single channel. A single small node provides only a single-bitrate stream service. The control center coordinates the large and small nodes, along with the playback terminal, to support stable multi-bitrate, multi-stream services of the DASH protocol. The fact that small nodes can provide only a single-bitrate stream service improves service stability and increases video stream transmission efficiency.

[0116] It should be noted that steps S50-S70 in Embodiment 2 are not executed sequentially with steps S10-S40 in Embodiment 1. Since Embodiment 1 is an embodiment of the DASH protocol playback method in a distributed cloud scenario provided by this application applied to a playback terminal, and Embodiment 2 is an embodiment of the DASH protocol playback method in a distributed cloud scenario provided by this application applied to a cloud server, steps S10-S40 correspond to steps S50-S70. After step S10 is executed in the playback terminal, step S50 is executed in the cloud server; after step S20 is executed in the playback terminal, step S60 is executed in the cloud server; after steps S30-S40 are executed in the playback terminal, step S70 is executed in the cloud server.

[0117] The playback method of the DASH protocol in the distributed cloud scenario provided in this application has an execution flow that can be referred to. Figure 10 , Figure 10 This is a flowchart illustrating the playback method of the DASH protocol in a distributed cloud scenario provided in this application. When a playback terminal plays a channel, it first initiates a data request. If the requested data is a multimedia playback descriptor file (MPD file), it first requests a list of nodes serving that channel from the control center. After receiving the node list, the playback terminal requests the MPD file from the larger node in the list. After the larger node returns the MPD file to the playback terminal, the playback terminal parses the MPD file and associates the representative identifiers of each bitrate with the corresponding smaller nodes. On the other hand, if the data requested by the playback terminal is not an MPD file, i.e., the requested data is a video segment, the playback terminal determines the current bitrate of the channel and its corresponding representative identifier based on the MPD file and the state of the playback terminal, identifies the corresponding smaller node, establishes a network connection with the smaller node, and then requests the video segment from the smaller node. If the smaller node has the requested video segment in its local cache, the smaller node directly returns the requested video segment to the playback terminal; if the smaller node does not have the requested video segment in its local cache, the smaller node first requests the corresponding video segment from the associated larger node and then returns it to the playback terminal.

[0118] Example 3

[0119] This application provides a playback system for the DASH protocol in a distributed cloud scenario, referring to... Figure 11 , Figure 11 This is a schematic diagram of the structure of the DASH protocol playback system in the distributed cloud scenario provided in this application. The DASH protocol playback system in the distributed cloud scenario includes a playback terminal 10 and a cloud server 20. The playback terminal 10 is communicatively connected to the cloud server 20. The cloud server 20 includes a control center 21, multiple large nodes 22 and multiple small nodes 23.

[0120] The playback terminal 10 is used to respond to a playback command, parse the playback command to determine the corresponding channel, and request a node list corresponding to the channel from the control center 21. The node list contains at least one service group, and the service group contains a large node 22 and multiple small nodes 23. Upon receiving the node list, it requests a multimedia playback descriptor file from the large node 22 in the node list. The multimedia playback descriptor file contains multiple representative identifiers, which are used to indicate the small nodes 23 that store video segments with corresponding bitrates. Based on the multimedia playback descriptor file and the state of the playback terminal 10, it determines the current bitrate of the channel and its corresponding representative identifier. Based on the representative identifier, it obtains the video segment from the corresponding small node 23.

[0121] In the DASH protocol playback system in the distributed cloud scenario of this embodiment three, the specific process of the interaction between the playback terminal 10 and the cloud server 20 (including the control center 21, multiple large nodes 22 and multiple small nodes 23) to achieve playback can be referred to the detailed description of the DASH protocol playback method in the distributed cloud scenario in the above embodiments one and / or two. The repeated parts will not be described again here.

[0122] Example 4

[0123] Based on the same inventive concept, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the DASH protocol playback method in a distributed cloud scenario as described in Embodiment 1 and / or Embodiment 2 above.

[0124] Example 5

[0125] Based on the same inventive concept, this application also provides a computer-readable storage medium storing a computer program / instruction thereon, which, when executed by a processor, implements the DASH protocol playback method in a distributed cloud scenario as described in Embodiment 1 and / or Embodiment 2 above.

[0126] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for playing a DASH protocol in a distributed cloud scenario, applied to a playing terminal, and characterized in that, include: In response to a playback command, the system parses the playback command to determine the corresponding channel and requests a list of nodes corresponding to the channel from the control center of the distributed cloud. The node list contains at least one service group, and the service group contains a large node and multiple small nodes. Upon receiving the node list, a multimedia playback descriptor file is requested from the large node in the node list. The multimedia playback descriptor file contains multiple representative identifiers, which are used to indicate the small node that stores video segments with corresponding bitrates. The small node only provides streaming services at a single bitrate. The current bitrate of the channel and its corresponding representative identifier are determined based on the multimedia playback descriptor file and the state of the playback terminal. The video segment is obtained from the corresponding sub-node based on the representative identifier. 2.The method of claim 1, wherein, The playback method of the DASH protocol in the distributed cloud scenario also includes: In response to the playback terminal switching bitrate, the representative identifier corresponding to the new bitrate is determined based on the multimedia playback descriptor file; Based on the new representative identifier, a new video segment is obtained from the corresponding small node, and the new video segment is played after the video segment corresponding to the previous bitrate.

3. The method of claim 1, wherein the method further comprises: The large node stores the start header of the channel; After receiving the node list, the system also requests the channel start header from the large node; Play the starter, and simultaneously obtain the video segment from the corresponding sub-node based on the determined representative identifier. The video segment is used to continue playback from the starter.

4. A DASH protocol playing method in a distributed cloud scenario, applied to a cloud server, and characterized in that, The cloud server includes a control center, multiple large nodes, and multiple small nodes. The playback method of the DASH protocol in the distributed cloud scenario includes: In response to the node list request, the control center returns the node list to the playback terminal; In response to a multimedia playback descriptor file request, the large node queries its local cache to see if a multimedia playback descriptor file exists; if so, it returns the multimedia playback descriptor file to the playback terminal; if not, it requests the multimedia playback descriptor file from the origin server, caches the multimedia playback descriptor file locally, and returns it to the playback terminal. In response to a video clip request, the small node queries its local cache to see if the video clip exists. The small node only provides single-bitrate streaming services. If the video clip exists, it returns the video clip to the playback terminal. If not, it requests the video clip from the associated large node, caches the received video clip locally, and returns it to the playback terminal.

5. The method of claim 4, wherein, After the large node requests the multimedia playback descriptor file from the origin server, the playback method of the DASH protocol in the distributed cloud scenario further includes: The multimedia playback descriptor file is parsed to obtain all the video segments corresponding to the bitrate, and the video segments are requested from the origin server and cached locally.

6. The playback method of DASH protocol in a distributed cloud scenario according to claim 5, characterized in that, The playback method of the DASH protocol in the distributed cloud scenario also includes: The large node periodically requests the multimedia playback descriptor file from the origin server and updates the video segment in its local cache based on the multimedia playback descriptor file.

7. The method of claim 4, wherein the method further comprises: The playback method of the DASH protocol in the distributed cloud scenario also includes: The large node and the small node periodically report service information to the control center; After receiving the service information, the control center updates the association between the large node and the small node based on the service information. 8.A playing system of a DASH protocol in a distributed cloud scenario, characterized in that, The DASH protocol playback system in the distributed cloud scenario includes a playback terminal and a cloud server. The playback terminal is communicatively connected to the cloud server, and the cloud server includes a control center, multiple large nodes, and multiple small nodes. The playback terminal is configured to respond to a playback command, parse the playback command to determine the corresponding channel, and request a node list corresponding to the channel from the control center; the node list includes at least one service group, the service group includes a large node and multiple small nodes; upon receiving the node list, it requests a multimedia playback descriptor file from the large node in the node list, the multimedia playback descriptor file containing multiple representative identifiers, the representative identifiers being used to indicate the small node storing a video segment with a corresponding bitrate; wherein, the small node only provides single-bitrate streaming service; based on the multimedia playback descriptor file and the state of the playback terminal, it determines the current bitrate of the channel and its corresponding representative identifier; based on the representative identifier, it obtains the video segment from the corresponding small node.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program comprises instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1-8. The processor executes the computer program to implement the steps of the DASH protocol playback method in a distributed cloud scenario as described in any one of claims 1-3 or 4-7.

10. A storage medium having stored thereon a computer program, characterized in that When executed by a processor, the computer program implements the steps of the DASH protocol playback method in a distributed cloud scenario as described in any one of claims 1-3 or 4-7.

Images