A dynamic bit rate adaptive network video transmission method and terminal device

Abstract

The present invention discloses a dynamic bit rate adaptive network video transmission method and terminal device, the video transmission method comprising: sending a request message to the edge side server, the request message carrying the length information of the target buffer, a timestamp, and the network information perceived by the client; receiving the video quality reference information and the target media file segment sent by the edge side server; configuring the playback parameters based on the video quality reference information, and starting to play when the length of the target buffer filled by the media file reaches a specified threshold. The method disclosed in the present invention fully utilizes the characteristics of edge computing to realize the use of edge side servers to provide video services to users, and the method disclosed in the present invention does not require a separate network element to be responsible for the transmission of information, and does not increase the complexity of the network and the signaling overhead.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a dynamic bit rate adaptive network video transmission method and terminal equipment. Background Art

[0002] The basic concept of Multi-access Edge Computing (MEC) was formally proposed by ETSI (European Telecommunications Standards Institute) in 2014, and ETSI established a related specification working group. In 2016, ETSI extended edge computing scenarios from mobile cellular networks to other wireless access networks, further expanding the original concept into Multi-access MEC. MEC is now becoming a key technology in 5G. According to ETSI's definition, mobile edge computing deploys corresponding infrastructure at the edge of the network and provides users with a platform that combines network, storage, and computing capabilities.

[0003] With the continuous development of the internet, it's widely believed that video streaming applications will dominate internet traffic in the near future. Furthermore, with the emergence of emerging multimedia applications such as virtual reality (VR) and augmented reality (AR), supporting 4K ultra-high-definition video content streaming has become a fundamental requirement for future internet architectures. In the context of 5G networks, one of operators' primary goals is to provide users with guaranteed Quality of Experience (QoE). In this context, the QoE guarantee objectives are twofold: first, a seamless streaming experience should be provided while minimizing playback interruptions. Second, video playback should be guaranteed to have a high bitrate.

[0004] In recent years, some video content providers have adopted Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH, to provide video streaming services. Although MPEG-DASH has many advantages, such as providing more flexible bitrate adaptation through existing video quality adaptation algorithms, and being easy to implement on existing HTTP infrastructure, and being based on TCP, it means reliable content transmission, which can avoid video quality degradation caused by, for example, I-frame loss. However, on the other hand, when wireless mobile user devices use DASH to stream video, traditional DASH is often client-driven. The client-driven and decentralized nature of DASH limits the control and coordination between the client and server or network behavior, resulting in suboptimal streaming performance.

[0005] With the increasing number of mobile terminal users and the rapid development of network communication technology, each user will have the same data flow requirements, such as interactive network television, audio or video multicast data streams, live sports events, etc. Broadcast and multicast service technology will play a key role in 5G systems and has great development prospects. Taking advantage of the information transmission characteristics of wireless channels, the unicast, multicast, and broadcast signals required by each user can be transmitted simultaneously, fully utilizing the communication efficiency of the downlink transmission link and conserving spectrum resources.

[0006] Existing methods do not incorporate the characteristics of 5G edge computing, and require the establishment of separate network elements to be responsible for information transmission, which additionally increases network complexity and signaling overhead. Summary of the Invention

[0007] The embodiments of the present invention provide a dynamic bit rate adaptive network video transmission method and terminal device, which are used to fully utilize the characteristics of edge computing and realize the use of edge-side servers to provide video services to users.

[0008] An embodiment of the present invention provides a dynamic bitrate adaptive network video transmission method, which is applied to a user's client and a network architecture consisting of an edge-side server and a remote server. The edge-side server is located close to the user, communicates with the remote server via a backbone network, and has storage capabilities to provide video services to the client. The video transmission method includes:

[0009] Sending a request message to the edge server, wherein the request message carries the length information of the target buffer, a timestamp, and network information perceived by the client;

[0010] Receiving video quality reference information and target media file segments sent by the edge-side server;

[0011] Playback parameters are configured based on the video quality reference information, and playback is started when the length of the target buffer filled by the media file reaches a specified threshold.

[0012] In some embodiments, before sending the request information to the edge-side server, the video transmission method further includes: sending a first request information to the edge-side server to request the MPD file of the edge-side server, and requesting a target media file segment of a specified bit rate based on the media information of the MPD file; and

[0013] When the client cannot confirm its network information, it requests a target media file segment with a minimum bitrate according to the MPD file.

[0014] In some embodiments, after playing, the client detects whether the last segment of the target media file has been downloaded based on the MPD file;

[0015] If the last segment of the target media file has not been downloaded, it is determined whether the target buffer has reached an upper limit. If the upper limit has not been reached, the download is continued.

[0016] In some embodiments, when the last segment of the target media file has not been downloaded, the method further includes: detecting whether the target buffer is completely consumed by the playback behavior, and if the target buffer is completely consumed, determining that the playback is stuck, and sending a stuck information to the edge server, wherein the stuck information includes a timestamp of the stuck; and

[0017] Continue to obtain the target media file segment, and send recovery information to the edge side server after resuming playback, where the recovery information has a recovery timestamp.

[0018] In some embodiments, the edge-side server includes a video proxy sub-server, a network assistance sub-server, and a local video source sub-server;

[0019] The video proxy sub-server is configured to obtain the request information;

[0020] The network assistance sub-server is configured to send video quality reference information to the client based on the request information;

[0021] The local video source sub-server is configured to send the target media file segment to the client based on the request information.

[0022] In some embodiments, the video proxy sub-server is further configured to send the request information to the remote server if it is determined based on the request information that the target media file segment does not exist in the local cache, so as to obtain the corresponding resource from the remote server and then send it to the client.

[0023] In some embodiments, the network assistance sub-server is further configured to determine playback-related events based on each timestamp, and determine video quality reference information based on the playback-related events, wherein the playback-related events include starting downloading, ending downloading, starting to freeze, and starting to replay.

[0024] An embodiment of the present invention further provides a terminal device, which includes a processor and a memory, wherein a client program is installed in the memory, and when the client program is called by the processor, the dynamic bit rate adaptive network video transmission method described in each embodiment of the present disclosure is implemented.

[0025] The embodiments of the present invention make full use of the characteristics of edge computing to provide video services to users using edge-side servers. In addition, the method disclosed in the present invention does not require a separate network element to be responsible for information transmission, and does not increase the complexity of the network and signaling overhead.

[0026] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0028] Figure 1 A schematic diagram of the basic architecture of the video transmission method disclosed herein;

[0029] Figure 2 is a basic flow chart of the video transmission method disclosed herein;

[0030] Figure 3 This is the basic architecture of the edge-side server in the video transmission method disclosed in the present invention. DETAILED DESCRIPTION

[0031] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0032] The embodiment of the present invention provides a dynamic bit rate adaptive network video transmission method, which is applied to the user's client and a network architecture composed of an edge side server and a remote server, wherein the edge side server is set on the side close to the user, communicates with the remote server through the backbone network, has storage capacity, and is used to provide video services to the client. Figure 1As shown, the method disclosed herein uses MEC as an edge server with functions that ordinary remote servers and existing CDNs do not have. The goal of network operators deploying DASH services is to provide consistent service quality for users in the network, and content providers hope to provide sufficiently high QoE to all users who have previously been guaranteed to have access to the network and services. Even when user-plane data is congested, content providers still hope to provide certain advanced users with stable and specific service quality, which requires operators to be able to support this demand by influencing their QoS control and resource allocation.

[0033] The MEC of the method disclosed in the present invention is located between the user and the Internet, has storage capabilities, and is closer to the user. It has the characteristics of low latency and high bandwidth, and is suitable for high-speed caching. In addition, MEC is the operator's infrastructure and has strong communication capabilities with the backbone network, making it suitable for pre-fetching video content.

[0034] As an edge cloud platform, MEC has better control over QoS. In addition, it has the ability to monitor the network and manage wireless resources. It can provide users with better estimates of the short-term throughput of the wireless network and provide real-time and accurate wireless access network information so that DASH transmission can better adapt to the status of the wireless network and avoid client buffer underload and jamming. Therefore, MEC is very helpful for optimizing video transmission in cellular networks.

[0035] MEC is also the node where service providers deploy services and is suitable for deploying some control policies to continuously ensure user QoE.

[0036] As an edge node, MEC can perform collaborative caching and collaborative control of multiple edge nodes.

[0037] like Figure 2 As shown, the video transmission method includes the following steps:

[0038] In S201, a request message is sent to the edge-side server, wherein the request message carries the length information of the target buffer, a timestamp, and the network information perceived by the client. The request message referred to in the method of the present disclosure is a request sent when the client requests a segment of video data. When a user plays a video data, the video can be divided into multiple continuous video segments, and a request message is sent each time to request a video segment. The request message includes a next request and the first post request after the download is completed, wherein the first post request after the download is completed can carry the length information of the target buffer, a timestamp, and the network information perceived by the client, wherein the network information perceived by the client can be used to describe the current network environment of the client.

[0039] In S202, the video quality reference information and the target media file segment sent by the edge server are received. After receiving the request information, the edge server can send the video quality reference information and the target media file segment to the client according to the network information perceived by the client.

[0040] In S203, playback parameters are configured based on the video quality reference information, and playback begins when the length of the target buffer filled by the media file reaches a specified threshold. After each download is completed, the client checks whether the buffer length reaches the set playback threshold. If so, video playback begins. If not, the client continues downloading video segments to fill the buffer until the video reaches the playback threshold.

[0041] The embodiments of the present invention make full use of the characteristics of edge computing to provide video services to users using edge-side servers. In addition, the method disclosed in the present invention does not require a separate network element to be responsible for information transmission, and does not increase the complexity of the network and signaling overhead.

[0042] In some embodiments, before sending the request information to the edge-side server, the video transmission method further includes: sending a first request information to the edge-side server to request the MPD file of the edge-side server, and requesting a target media file segment of a specified bit rate based on the media information of the MPD file; and

[0043] When the client cannot confirm its network information, it requests a target media file segment with a minimum bitrate according to the MPD file.

[0044] Specifically, before the client needs to play a certain video, it can send a first request message to the edge-side server. The first request message can be a second post request, which is used to request the MPD file of the edge-side server and request the target media file segment of the specified bit rate based on the media information of the MPD file. When making the first request, the request can be started from the lowest bit rate, that is, when the client has no knowledge of the current network information, the video with the lowest bit rate is automatically requested to ensure that the user can watch the video smoothly. That is, before starting to download the target media file segment, a second post request can also be sent to the service and network auxiliary server of the edge-side server. The second post request carries information such as the timestamp of the current request, so that the edge-side server can determine the playback-related events of the client. After sending the second post request, the aforementioned request message is sent to request the video segment of the specified bit rate. After the download is complete, the first post request is sent to the server. The request carries information such as the length information of the current buffer, the network information currently perceived by the client, and the timestamp.

[0045] In some embodiments, after playing, the client detects whether the last segment of the target media file has been downloaded based on the MPD file; if the last segment of the target media file has not been downloaded, it determines whether the target buffer is filled to the upper limit, and if the upper limit has not been reached, continues downloading.

[0046] Specifically, after the client starts playing the video, its download task will not stop. Downloading the file (video segment) is the act of filling the target buffer, while playing the video is the act of consuming the target buffer. The target buffer will have a maximum value, and the buffer threshold for starting playback is less than its buffer maximum value. Therefore, when the client starts playing and consuming the buffer, it is also filling the buffer. The interaction with the server during the process of filling the buffer is similar to the interaction during the playback of the aforementioned filled buffer. The second post request to be downloaded is also sent before the download is prepared. After the download is complete, the first and second post requests are sent simultaneously to obtain the next video segment and report the client's own information.

[0047] After each download is completed, the client can detect whether the last segment of the video has been downloaded based on the MPD file. If the download is complete, the download is stopped. Otherwise, it is determined whether the buffer has reached the upper limit. If not, the download continues to fill the buffer.

[0048] In some embodiments, when the last segment of the target media file has not been downloaded, the method further includes: detecting whether the target buffer is completely consumed by the playback behavior, and if the target buffer is completely consumed, determining that the playback is stuck, and sending a stuck information to the edge server, wherein the stuck information includes a timestamp of the stuck; and

[0049] Continue to obtain the target media file segment, and send recovery information to the edge side server after resuming playback, where the recovery information has a recovery timestamp.

[0050] Playing a video consumes the target buffer. In this example, the client performs a buffer check each time a target buffer segment is consumed. If the last video segment has been played, playback ends according to the MPD file. If not, the client checks whether the buffer has been consumed. If not, the client continues downloading the video and then plays it. If the buffer is consumed, playback will be stalled, and stall information, including the stall timestamp, will be sent to the MEC service and network assistance server. At the same time, the client downloads the video segment to refill the buffer. Once playback resumes, the client sends a message to the server indicating that playback has resumed, including the timestamp.

[0051] In some embodiments, the edge-side server includes a video proxy sub-server, a network assistance sub-server, and a local video source sub-server;

[0052] The video proxy sub-server is configured to obtain the request information;

[0053] The network assistance sub-server is configured to send video quality reference information to the client based on the request information;

[0054] The local video source sub-server is configured to send the target media file segment to the client based on the request information.

[0055] In some embodiments, services and network-assisted related service modules are deployed on the MEC, mainly consisting of a wireless information service module, an auxiliary decision service module, a cache prefetch service module, and an indicator collection service module, among which:

[0056] The wireless information service module is primarily responsible for providing wireless-side information to DASH clients. This includes wireless link status, air interface resource contention in the current wireless environment, such as the number of users using data services at the current base station, and network conditions between the MEC and the backbone network, such as the latency and bandwidth associated with the MEC to the remote video server. DASH clients can use this data using the HTTP GET protocol as auxiliary information for decision-making. DASH clients can use this information as part of their adaptive algorithm to detect rapid fluctuations in the wireless side, compensating for the client's slow perception of the wireless network.

[0057] The decision-making support service module allows the decision maker on the MEC server to combine DASH client metrics and relevant decision-making algorithms, such as reinforcement learning or deep reinforcement learning algorithms, to assist in decision-making. This module can also be deployed with the service provider's relevant control policies. By deploying relevant control policies, the service provider can allocate different service resources based on user tiers. Relevant bandwidth allocation policies can also be deployed to ensure user fairness. This service module is actually a supplement to the client-driven approach. In fact, the server can also fully control the bitrate adjustment, so that the client does not need to select the bitrate. However, this is a relatively extreme option. In actual production deployment scenarios, if the server makes all the decisions, it will put too much pressure on the server.

[0058] The cache prefetching service module manages the caching of video segments and prefetches videos from remote servers. Caching primarily involves deploying appropriate caching strategies within limited disk space to improve the target file hit rate. Prefetching involves pre-caching videos not in the cache from the remote video server to the MEC when a client requests a video resource to reduce latency. Prefetching strategies can also be deployed to ensure user QoE.

[0059] The metrics collection service module is primarily responsible for collecting video-related metrics from DASH clients, such as average client bandwidth, current buffer level, initial playback latency, and HTTP requests. This information is primarily used to assist decision-making services and facilitate statistical analysis of client status as input to algorithms. Furthermore, collecting user QoE metrics facilitates fault detection and debugging, manages streaming performance, and enables network operators and service providers to provide QoE-aware network adaptation and service provisioning.

[0060] like Figure 3 As shown, the edge-side server includes a video proxy sub-server (video proxy server), a network assistance sub-server (network assistance service), and a local video source sub-server (local Tomcat video server). The video proxy sub-server and the network assistance sub-server can be implemented using Jetty, and the local video source sub-server is implemented using Tomcat. The video proxy sub-server and the network assistance sub-server are not independent of each other. There is a necessary connection between the two sub-servers. For example, the information obtained by the video proxy can be used for network assistance. Some results of the network assistance service can also serve as reference information for the video proxy service.

[0061] Specifically, the edge server's video proxy sub-server: This sub-server is the actual URL and port when the client plays the video, and responds to the client's request based on the request information function. The reverse proxy means that the address requested by the client is the proxy's address and port.

[0062] In some embodiments, the video proxy sub-server is further configured to send the request information to the remote server when it is determined based on the request information that the target media file segment does not exist in the local cache, so as to obtain the corresponding resources from the remote server and then send them to the client. That is, the proxy sub-server also obtains resources from the back-end video server according to the client's request, and then returns the video and other resources to the client. In this process, the video proxy sub-server can obtain information such as the request from the client, such as counting the number of video segments requested by the client to know its playback process. In addition, the proxy service needs to judge the video cache status on the MEC. If the current video is not in the cache area, it will obtain the resources after distributing the client's request to the remote video server and then return them to the client. If the local video source sub-server has a cache, then the resources are directly obtained from the local video source sub-server and then returned to the client.

[0063] Furthermore, the video proxy subserver can control the user's downlink bandwidth by controlling the rate of traffic returned to the client. It can also modify the content returned by the backend server (remote server) to implement content filtering and other functions. This functionality is primarily implemented by rewriting Jetty's rewriteTarget, onResponseContent, and newWriteListener methods. rewriteTarget is responsible for selecting the backend video server and replaces the information in the client's request URL with the address of the corresponding backend server.

[0064] The network auxiliary sub-server of the edge server: This sub-server corresponds to the four processes of the client interacting with the MEC and makes corresponding decisions. The specific monitoring service can be implemented through Servlet. In this service, the problem of cross-domain access of JavaScript may occur. The corresponding field needs to be added to the header of the response returned by each Servlet.

[0065] The local Tomcat video sub-server on the edge server: This service is responsible for processing client-requested content, including HTML files, JS files, MPD files, video files, and other files, and is also responsible for storing cached content. This service operates on port 8088.

[0066] In some embodiments, the network assistance sub-server is further configured to determine playback-related events based on each timestamp, and determine video quality reference information based on the playback-related events, wherein the playback-related events include starting downloading, ending downloading, starting to freeze, and starting to replay.

[0067] The specific monitoring process of the network auxiliary sub-server includes:

[0068] Start downloading: This monitoring corresponds to the start of each download of the front-end. By obtaining the timestamp transmitted by the front-end, the download start time can be accurately known. Combined with the download completion time, the client's bandwidth level and network status can be calculated.

[0069] Download completion: This monitoring corresponds to the completion of each download segment on the front end. The current bandwidth and buffer information of the front end interaction are obtained, and the download completion timestamp can also be obtained. Then, based on the information sent by the client, service and network auxiliary operations are performed. For example, pre-fetching operations can be performed to determine the number of pre-fetched segments by detecting whether the client buffer is in a low-level state or the buffer is full. Alternatively, by detecting the client buffer status, corresponding resource control strategies can be implemented to ensure the user's QoE. It is also possible to combine wireless side information and client side information on the MEC to adopt some adaptive algorithms to assist the client in making decisions. At the same time, wireless side information can be exchanged with the client to assist the client in making decisions.

[0070] Start of Stuttering: This function monitors client-side stuttering, records the timestamp of the stuttering, and calculates the duration of the client-side stuttering by combining it with the timestamp of the restart of playback. By detecting the stuttering state, appropriate bandwidth control strategies or load balancing strategies can be implemented to enable the client to resume playback.

[0071] Start replay: Responsible for monitoring the client to return to the playback state. Mainly used to detect freezes.

[0072] In summary, the video transmission method disclosed in the present invention is based on 5G edge computing to transmit dynamic bitrate adaptive video on the edge side. It does not require a separate network element for information transmission and will not increase the complexity of the network and signaling overhead. The method disclosed in the present invention is based on the idea of ​​cloud-edge-end collaboration, obtains network and other status information of the end and cloud sides on the edge side, defines relevant protocols, processes, etc., and refines the DASH method for service and network assistance on the 5G edge side. The method disclosed in the present invention can also be based on the Wireless Network Information Service (RNIS) on the 5G edge computing platform to dynamically adjust the user video bitrate according to the current wireless channel quality of the user side, thereby improving the user's viewing quality.

[0073] An embodiment of the present invention further provides a terminal device, which includes a processor and a memory, wherein a client program is installed in the memory, and when the client program is called by the processor, the dynamic bit rate adaptive network video transmission method described in each embodiment of the present disclosure is implemented.

[0074] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0075] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0076] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better embodiment. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0077] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are protected by the present invention.

Claims

1. A dynamic bit rate adaptive network video transmission method, characterized in that: A network architecture is applied to a user's client and is composed of an edge-side server and a remote server, wherein the edge-side server is located on a side close to the user, communicates with the remote server via a backbone network, has storage capabilities, and is used to provide video services to the client. The video transmission method includes: Sending a request message to the edge server, the request message carrying the target buffer length information, a timestamp, and client-perceived network information, the client-perceived network information being used to describe the client's current network environment. When a user plays a video data, the video is divided into multiple consecutive video segments, and a request message is sent each time to request a video segment; Receiving video quality reference information and target media file segments sent by the edge-side server; configuring playback parameters based on the video quality reference information, and starting playback when a length of the target buffer filled with the media file reaches a specified threshold; The method further includes: sending a first request message to the edge-side server to request the MPD file of the edge-side server, and requesting a target media file segment of a specified bitrate based on the media information of the MPD file; and requesting a target media file segment of a minimum bitrate based on the MPD file if the client cannot confirm its network information; After playing, the client detects whether the last segment of the target media file has been downloaded based on the MPD file; If the last segment of the target media file has not been downloaded, determining whether the target buffer has reached an upper limit, and if the upper limit has not been reached, continuing the download; In the case that the last segment of the target media file has not been downloaded, the method further includes: detecting whether the target buffer is completely consumed by the playback behavior; if the target buffer is completely consumed, determining that the playback is stuck, and sending stuck information to the edge side server, wherein the stuck information includes a timestamp of the stuck.

2. The method for dynamic bit rate adaptive network video transmission according to claim 1, wherein: Also includes: Continue to obtain the target media file segment, and send resumption information to the edge side server after resuming playback, where the resumption information has a resumption timestamp.

3. The dynamic bit rate adaptive network video transmission method according to claim 2, wherein: The edge-side server includes a video proxy sub-server, a network auxiliary sub-server and a local video source sub-server; The video proxy sub-server is configured to obtain the request information; The network assistance sub-server is configured to send video quality reference information to the client based on the request information; The local video source sub-server is configured to send the target media file segment to the client based on the request information.

4. The method for dynamic bit rate adaptive network video transmission according to claim 3, wherein: The video proxy sub-server is further configured to send the request information to the remote server if it is determined based on the request information that the target media file segment does not exist in the local cache, so as to obtain the corresponding resource from the remote server and then send it to the client.

5. The dynamic bit rate adaptive network video transmission method according to claim 3, wherein: The network assistance sub-server is further configured to determine playback-related events based on each timestamp, and determine video quality reference information based on the playback-related events, wherein the playback-related events include starting downloading, ending downloading, starting freeze, and starting replaying.

6. A terminal device, characterized in that: The terminal device includes a processor and a memory, wherein a client program is installed in the memory, and when the client program is called by the processor, the dynamic bit rate adaptive network video transmission method according to any one of claims 1 to 5 is implemented.

Images