Video streaming methods, devices, and systems applied in banking

Abstract

This application provides a video streaming method, apparatus, and system for use in banking. The method includes: acquiring a video request, wherein the video request is a request from an upstream node to a downstream node to send video; acquiring a target video from the downstream node based on the video request; and sending the target video from the downstream node to a target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the one with the lowest load among the multiple streaming media servers. This solution addresses the problem in existing streaming media polling scheduling strategies where uneven load distribution can lead to excessive load or even crashes of individual streaming media servers, thus affecting the stable operation of the entire system.

Description

Technical Field

[0001] This application relates to the field of computer streaming media technology, and more specifically, to a video streaming transmission method, apparatus, computer program product, and video transmission system for use in banking. Background Technology

[0002] With the rapid development of the internet and the increasing number of users, high-concurrency streaming scenarios are constantly emerging, posing a significant challenge to traditional streaming media technologies (servers). Currently, traditional streaming media polling scheduling strategies suffer from load imbalance, which may lead to individual streaming media becoming overloaded or even crashing, thereby affecting the stable operation of the entire system. Summary of the Invention

[0003] The main objective of this application is to provide a video streaming method, apparatus, computer program product, and video transmission system for use in banks, so as to at least solve the problem that the existing streaming media polling scheduling strategy has an unbalanced load, which may lead to excessive load or even crash of a single streaming media, thereby affecting the stable operation of the entire system.

[0004] To achieve the above objectives, according to one aspect of this application, a video streaming method for use in a bank is provided, comprising: acquiring a video request, wherein the video request is a request from an upstream node to a downstream node to send a video; acquiring a target video of the downstream node according to the video request; and sending the target video of the downstream node to a target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the streaming media server with the lowest load among the multiple streaming media servers.

[0005] According to another aspect of this application, a video streaming transmission device for use in a bank is provided, comprising: a first acquisition unit for acquiring a video request, wherein the video request is a request from an upstream node to a downstream node to send a video; a second acquisition unit for acquiring a target video of the downstream node according to the video request; and a sending unit for sending the target video of the downstream node to a target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the streaming media server with the lowest load among the multiple streaming media servers.

[0006] According to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of any of the video streaming methods applied to a bank.

[0007] According to another aspect of this application, a video transmission system is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any of the video streaming methods described above for use in banking.

[0008] By applying the technical solution of this application, when video needs to be transmitted, the downstream transmits the video to the upstream streaming media server with the least load. This can improve the throughput of the streaming media cluster, and the video can be allocated to the streaming media server with the best performance and fastest response, thereby achieving load balancing of streaming media servers and avoiding overload of a single streaming media server. Attached Figure Description

[0009] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0010] Figure 1 A hardware structure block diagram of a mobile terminal for performing a video streaming method applied to a bank, according to an embodiment of this application, is shown.

[0011] Figure 2 A flowchart illustrating a video streaming method for use in a bank, according to an embodiment of this application, is shown.

[0012] Figure 3 A flowchart illustrating the streaming media scheduling algorithm of this scheme is shown;

[0013] Figure 4 A schematic diagram illustrating the deployment and cascading method of the streaming media service cluster in this solution is shown;

[0014] Figure 5 This diagram illustrates the selection of the minimum load node using the entropy weight-TOPSIS model.

[0015] Figure 6 A structural block diagram of a video streaming device for use in a bank, according to an embodiment of this application, is shown.

[0016] The above figures include the following reference numerals:

[0017] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0021] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0022] Streaming media: refers to a technology that compresses a series of media data and transmits it in segments over a network in a streaming manner, so as to realize the real-time transmission of audio and video for viewing.

[0023] Streaming media server: Its main function is to transmit video files to the client using streaming protocols (RTP / RTSP, MMS, RTMP, etc.) for users to watch online; it can also receive real-time video streams from video capture and compression software and then send them to the client using streaming protocols.

[0024] Entropy weighting method: For a given indicator, the entropy value can be used to determine its degree of dispersion. The smaller the information entropy value, the greater the dispersion of the indicator, and the greater its influence (i.e., weight) on the overall evaluation. Therefore, information entropy can be used to calculate the weight of each indicator, providing a basis for multi-indicator comprehensive evaluation.

[0025] TOPSIS model (Technique for Order Preference by Similarity to an Ideal Solution) is a method that ranks evaluation objects based on their similarity to an idealized goal. It is a comprehensive distance evaluation method.

[0026] Monitoring center: refers to a location that uses network technology to receive and process information from security systems and manage and control system equipment.

[0027] Under the existing head office-branch management model of banks, due to the hierarchical deployment of streaming media in the bank's security system and network bandwidth limitations, there may be repeated acquisition of video streams, resulting in excessive load on the data source, large streaming latency, low efficiency, or even frame drops.

[0028] Traditional streaming media polling scheduling strategies suffer from load imbalance and untimely feedback of actual streaming media load information, which may lead to individual streaming media becoming overloaded or even crashing, thus affecting the stable operation of the entire system. In addition, it is difficult to guarantee load balancing when streaming media clusters are deployed and video streams are reused.

[0029] Currently, cluster deployments of streaming media services require adding a central node scheduling server to make decisions and process all client requests, determining the optimal streaming media node to respond to each client request. However, in a tiered deployment scenario like that of banks, adding a central node can lead to latency issues in computing streaming media load, and a failure of the central node can render the entire streaming media service unavailable. Furthermore, request loops can occur during video stream retrieval. Therefore, the stability of the scheduling service will affect the stability of the entire video system.

[0030] As described in the background section, existing streaming media polling scheduling strategies suffer from load imbalance, which may lead to excessive load or even crashes of individual streaming media, thereby affecting the stable operation of the entire system. To solve the above problems, embodiments of this application provide a video streaming transmission method, apparatus, computer program product, and video transmission system applicable to banks.

[0031] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0032] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal used in a video streaming method for banking, according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0033] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the device information display method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0034] This embodiment provides a video streaming method for use in banking, which runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] Figure 2 This is a flowchart illustrating a video stream transmission method applied to a bank, according to an embodiment of this application. Figure 2As shown, the method includes the following steps:

[0036] Step S201: Obtain a video request, wherein the video request is a request from the upstream node to the downstream node to send a video.

[0037] Specifically, the system receives a video request from an "upstream node." An upstream node typically refers to a node located higher in the network hierarchy, such as the head office's monitoring center or a first-level branch's monitoring center. The goal of this request is to request video to be sent from a "downstream node" (i.e., a node lower in the network hierarchy, such as a second-level branch's monitoring center or the location of the video source device). The video request can be a real-time preview request, a playback request, or a video download request, depending on the monitoring needs of the upstream node.

[0038] Step S202: Based on the video request, obtain the target video of the downstream node.

[0039] Specifically, upon receiving a video request, the downstream node begins processing the request. Its main task is to obtain the specified video stream from the video source (such as a surveillance camera). The target video here refers to the specific video stream requested by the upstream node; it can be a live feed from a camera or a playback video from historical records. The downstream node retrieves the target video from the video source device based on information in the video request, such as the video ID and timestamp.

[0040] Step S203: The target video from the downstream node is sent to the target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the streaming media server with the lowest load among the multiple streaming media servers.

[0041] Specifically, after acquiring the target video, downstream nodes select which "target streaming media server" to send the video stream to based on their cached load information and video stream channel information. Since upstream nodes may contain multiple streaming media servers, downstream nodes use the entropy weight method and the TOPSIS model to calculate and determine the streaming media server with the lowest current load. Selecting the server with the lowest load for video stream transmission ensures the efficiency and stability of video stream transmission, avoids overloading a single server, further optimizes the video stream transmission path, and guarantees fast response and high quality video transmission.

[0042] In this embodiment, when video transmission is required, the downstream transmits the video to the upstream streaming media server with the least load. This can improve the throughput of the streaming media cluster, and the video can be allocated to the streaming media server with the best performance and fastest response, thereby achieving load balancing of the streaming media servers and avoiding overload of a single streaming media server.

[0043] Specifically, the proposed solution addresses the load balancing issue when deploying streaming media clusters under a head office-branch management structure. It dynamically schedules streaming media under bandwidth constraints to achieve load balancing and supports the reuse of existing video streams, thereby effectively saving network bandwidth, maximizing the use of existing resources, and improving the performance of streaming media and video sources.

[0044] Specifically, the proposed solution mainly includes determining the minimum load node and obtaining the target streaming link based on streaming media status information, as well as the entire system consisting of streaming media cluster, video equipment, and clients.

[0045] Specifically, the scheduling process of this solution is as follows: Figure 3 As shown, the steps can be described as follows:

[0046] (1) Determine the organizational level based on the video stream request initiated by the client, and determine whether the current request is a preview request;

[0047] (2) If it is a preview request, determine whether the current preview video stream exists based on the current cache:

[0048] ① If it exists, obtain the streaming media service node where the video stream is located, and determine whether the streaming media directly requested by the video stream is the parent node of the node where the current video stream is located:

[0049] 1) If so, forward the video stream to the smallest streaming media node of the upstream load and respond with the video stream to the client;

[0050] 2) Otherwise, directly send the video stream to the client;

[0051] ② If it does not exist, obtain the list of directly affiliated streaming media services of the organization, obtain the streaming media service node with the lowest load in the list, and determine whether the video stream requesting the directly affiliated streaming media is the parent node of the node where the current video stream is located:

[0052] 1) If so, forward the video stream to the smallest streaming media node of the upstream load and respond with the video stream to the client;

[0053] 2) Otherwise, directly send the video stream to the client;

[0054] (3) If it is not a preview request, then proceed to step (2)-②.

[0055] (4) After each video stream connection ends or is disconnected, update the streaming media load status information and existing video stream channel information in the cache, and wait for the next connection.

[0056] Specifically, a "video preview request" typically refers to a request initiated from the monitoring center or a remote client to view the video feed from one or more cameras in real time. When a bank's monitoring center operator or authorized user wants to monitor a specific location in real time, they send a video preview request to the system. Upon receiving this request, the system retrieves the corresponding video stream based on the information in the request (such as camera ID, preview time, etc.) and transmits these video streams over the network to the requester's device for real-time playback.

[0057] Specifically, existing streaming media servers are deployed in clusters or two-level cascades, which is sufficient for scenarios with a small number of devices and simple streaming patterns, but does not support complex business scenarios with large data volumes, high concurrency, and multi-level cascading. In the banking sector, with its head office and branch offices, video requests from subordinate institutions are intercepted by a scheduling service. This can lead to loopbacks in streaming media service requests. For example, if the scheduling service is deployed at the head office, a client from a branch office requesting a video stream from that branch will first request the scheduling service, which will then allocate a streaming media server and respond to the client, allowing the client to access the corresponding streaming media. Directly requesting the streaming media service from the branch office itself avoids this loopback problem, resulting in shorter response times and less network resource consumption.

[0058] In the specific implementation process, before obtaining the video request, the above method also includes the following steps: obtaining the first scheduling information of the Nth layer node, wherein the first scheduling information is the information of the Nth layer node requesting the scheduling of the N+1th layer node, where N≥1; based on the first scheduling information, scheduling the N+1th layer node to provide services to the Nth layer node.

[0059] This solution avoids the information feedback delays inherent in traditional centralized scheduling and reduces the risk of service unavailability due to central node downtime. Furthermore, through multi-level cascading and video stream multiplexing, unnecessary video stream transmission is reduced, saving network resources and costs. The intelligent scheduling strategy ensures efficient resource utilization, reduces the streaming pressure on video source devices, and since the Nth-level node can directly schedule the N+1th-level node, the number of request processing layers is reduced, improving the efficiency of video stream processing and system performance.

[0060] Specifically, in the tiered deployment of a bank's security system, the Nth-layer node can be a monitoring center or streaming media server located at different levels, such as the head office, first-level branches, and second-level branches. This node collects and sends "first scheduling information," which includes scheduling requests from the Nth layer to the N+1th layer (i.e., the next level). These requests may include requests for previewing, playing back, or downloading video streams, as well as the node's own assessment of its video stream transmission capabilities.

[0061] The N+1 layer nodes (typically the next-level streaming media server cluster) perform intelligent scheduling using entropy weighting and the TOPSIS model based on the received initial scheduling information. This process involves dynamically calculating the load of each streaming media server and selecting the server with the lowest load to respond to the video stream requests from the N layer nodes. Once the target server is determined, the video stream will be transmitted from the video source device to the N layer node via the optimal path, fulfilling its monitoring requirements.

[0062] Specifically, suppose a large bank's security system uses a three-tiered streaming media server deployment: the head office monitoring center (tier 1), the first-tier branch monitoring center (tier 2), and the second-tier branch monitoring center (tier 3).

[0063] The head office monitoring center (Level 1) needs to preview the real-time video surveillance footage of Branch A. The head office monitoring center will send a first scheduling message, requesting that Branch A's streaming media server (Level 2) provide the real-time video stream. This scheduling message includes not only the video stream ID, request type (real-time preview), and required video time period, but also the head office monitoring center's own status information, such as currently connected streaming media servers and the number of video streams already acquired, for load assessment by the next-level streaming media servers.

[0064] After receiving information from the head office, the streaming media server cluster of Branch A (Level 1) calculates the weights of indicators using the entropy weight method based on its own server load (such as CPU utilization, memory utilization, and bandwidth utilization) and existing video stream channel information. Then, using the TOPSIS model, it determines which server in the cluster has the lowest load and is most suitable to provide video streaming services to the head office. Assuming server B has the lowest load, the cluster will schedule server B to start transmitting the video stream. Upon receiving the scheduling instruction, server B will begin pulling the required real-time video stream from the video source devices of the Branch A (Level 2) and transmitting it to the head office monitoring center. During transmission, server B will update the communication channel information of the video stream in its cache for rapid reuse in subsequent requests.

[0065] Specifically, based on the business needs of security systems in the banking sector, the networks between different first-level branches may not be interconnected. Therefore, this section introduces the equipment-secondary branch-primary branch-head office hierarchy, and the specific deployment method is as follows: Figure 4 As shown.

[0066] Specifically, in the banking sector, a head office-branch structure is adopted. The head office establishes a monitoring center responsible for monitoring all office spaces within the head office and all subordinate branches' network of outlets and office buildings. This center can initiate video stream requests through its client and has the right to view monitoring video from all office spaces nationwide. For branches, separate monitoring centers are established to manage all monitoring equipment within their respective branches and subordinate branches. These centers can also initiate video stream requests from their own branches and subordinate branches through their client. To alleviate the burden of numerous video stream requests nationwide, streaming media servers are deployed at the head office, branches, and sub-branches, reusing existing video streams. This effectively conserves network resources, reduces device streaming pressure, and enables rapid response to client requests. Each branch's cluster servers share a cache that records the status information of all streaming media servers deployed at that level and the communication channel information of existing video streams.

[0067] Specifically, existing technologies do not consider the cascading problems caused by network connectivity issues between regions during actual operation. Currently, in the banking sector, due to bandwidth limitations and high costs of private networks, network connectivity between regions is disrupted, and communication during streaming media relies excessively on scheduling servers.

[0068] In some embodiments, before obtaining the video request, the method further includes the following steps: obtaining third scheduling information of the first node in layer M, wherein the third scheduling information is information of the first node in layer M requesting to schedule the second node in layer M, M≥2, M≤N; sending the third scheduling information to the node in layer M-1; scheduling the second node in layer M to provide services to the node in layer M-1 based on the third scheduling information, and the node in layer M-1 forwarding the data sent by the second node in layer M to the first node in layer M.

[0069] This scheme achieves efficient scheduling and transmission of video streams across a multi-layered structure through cross-level data forwarding, ensuring the continuity and timeliness of data transmission. The multi-level scheduling mechanism ensures secure information transmission between nodes at each level, while data forwarding through upper-level nodes makes the video stream transmission path more controllable, avoiding the risk of data leakage that might arise from direct cross-level communication.

[0070] Specifically, in a tiered bank security system, layer M can represent any intermediate level, such as a first-level branch or a second-level branch, where M ranges from 2 to N (N being the highest level in the entire hierarchical structure). Assume that within the same layer M, the first node (e.g., the streaming media server cluster of first-level branch A) needs to obtain a video stream from the second node (e.g., the streaming media server cluster of first-level branch B). The first node will collect and generate "third-level scheduling information," which contains detailed information about the video stream request from the second node, including the video stream ID, request type (e.g., live preview or historical playback), and the video's time segment.

[0071] The first node (the streaming media server cluster of first-level branch A) does not communicate directly with the second node (the streaming media server cluster of first-level branch B). Instead, it sends the third scheduling information to a higher level, namely the (M-1)th layer (which may be the head office monitoring center where first-level branch A is located). This design takes into account the isolation of the network at each level in the banking system and the characteristics of private network communication, ensuring the secure transmission of information.

[0072] After receiving the third scheduling information, the node at layer M-1 (the head office monitoring center) uses the entropy weight method and the TOPSIS model to evaluate the load of the second node (the streaming media server cluster of the first-level branch B), and selects the server with the least load to provide the video stream to the first node. Once the target server is determined, the second node at layer M will begin transmitting the video stream to the node at layer M-1, realizing cross-layer transmission of the video stream.

[0073] After receiving the video stream from branch B, the head office monitoring center forwards this data back to the streaming media server cluster of branch A, the original requester. In this way, the first node does not need to communicate directly with the second node, but instead obtains the video stream indirectly through the node at the next higher level. This mechanism ensures controllability of data flow and communication efficiency, while also avoiding potential loopback issues.

[0074] Taking the monitoring center of branch A (assumed to be the first node of layer M, where M=2) as an example, it needs to obtain video streams from the monitoring center of branch B (i.e., the second node of layer M) for internal monitoring analysis or to provide video data to the head office monitoring center. Branch A's monitoring center will generate third-party scheduling information based on its own needs and the load of branch B's monitoring center. This information includes key elements such as video stream information (e.g., surveillance camera ID), request type (real-time preview or historical playback), and the required video time range.

[0075] The monitoring center of branch A will not directly send a request to the monitoring center of branch B. Instead, it will report the third-level scheduling information to its superior node, namely the head office monitoring center (layer M-1, M=1). This design takes into account the internal network isolation and communication security of the bank system, ensuring that the request information can be transmitted securely and orderly between layers.

[0076] After receiving the third scheduling information, the head office monitoring center uses the entropy weight method and the TOPSIS model to evaluate the load of the streaming media server cluster in the first-level branch B monitoring center. It determines which server has the lowest CPU utilization, memory utilization, and bandwidth utilization, making it the most suitable for providing video streaming services to the first-level branch A. Assuming server C has the lowest load, the head office monitoring center will schedule server C to begin transmitting the video stream.

[0077] Server C (located in the monitoring center of the first-level branch B) begins processing video stream requests, acquiring video data from video source devices (such as surveillance cameras in the second-level branch) and transmitting this data to the head office monitoring center. Upon receiving the video stream, the head office monitoring center then forwards the video data to the original requesting first-level branch A monitoring center. This process ensures the continuity and efficiency of video stream transmission while avoiding network latency and data security issues that could arise from direct cross-branch communication.

[0078] Specifically, the solution proposed in this application considers multi-level cascading of streaming media and the reuse of video streams within the streaming media. In terms of service deployment, it eliminates the previous centralized scheduling service. Each service node in the cluster calculates its own load status, eliminating the need to wait for the stream to be fetched or closed before notifying the scheduling service, enabling rapid processing within the streaming media service. Furthermore, it avoids request loopback issues during processing, ensuring rapid response while conserving network resources. The multi-level streaming media service cluster deployment alleviates the pressure of massive device data volumes, significantly improving performance compared to a single service node. It can still operate normally even with concurrent requests from multiple clients and is suitable for situations with insufficient network bandwidth in the banking security field.

[0079] Specifically, the proposed solution is a two-level cascading approach, which is suitable for scenarios with a small number of devices and a simple cascading mode, but does not support complex business scenarios with large amounts of device data, high concurrency, and multiple cascading levels. This solution proposes a multi-level cascading method for streaming media suitable for the banking security field, alleviating the pressure on a single streaming media service node corresponding to a large number of video devices and enabling rapid processing of multiple concurrent requests.

[0080] Specifically, to alleviate the workload of streaming media servers, the current mainstream solution is streaming media service cluster technology. In this scenario, the video transmission strategy of streaming media becomes one of the core components of the entire streaming media technology, determining the maximum throughput of the server cluster.

[0081] Currently, load balancing algorithms are mainly divided into two types: static load balancing algorithms and dynamic load balancing algorithms. The performance of a streaming media server can generally be evaluated using parameters such as CPU utilization, memory utilization, and bandwidth usage. Traditional static load balancing algorithms distribute load in a fixed manner. While simple to implement and fast, they struggle to ensure load balancing in real-world scenarios where streaming media cluster performance parameters fluctuate, especially considering the streaming media's own operational status and certain complex situations. Dynamic load balancing algorithms, on the other hand, calculate the load based on node status information during operation and select the node with the lowest load to handle client requests.

[0082] In the specific implementation process, the target video of the downstream node is obtained according to the video request, which can be achieved through the following steps: according to the video request, check whether there is cached data of the target video in the cache; if there is cached data of the target video in the cache, schedule the downstream node where the target video is located; find the target video from the streaming media server of the downstream node, and send the target video to the upstream node.

[0083] In this solution, the caching mechanism enables the system to quickly respond to repeated video requests without needing to retrieve the video stream from the video source device, significantly improving video stream scheduling speed and user experience. Reusing cached data reduces frequent access to the video source device, lowering data transmission bandwidth requirements.

[0084] Specifically, when a monitoring center (upstream node) issues a video request, such as requesting to preview or play back a specific video stream (target video) for a particular branch, the system will first check its cache to see if cached data for that video exists. Cached data refers to video streams that have been previously requested and stored locally or on nodes at the same level. The purpose is to quickly respond to future identical requests, reduce frequent access to the video source device, and save network bandwidth.

[0085] If the cached data of the target video is found in the cache, the system will directly schedule the downstream node where the video is located (i.e., the node providing the video stream, usually the monitoring center of the first or second-level branch where the video source device is located). The downstream node will search for the target video from its local storage or the streaming media server that is currently transmitting, according to the scheduling instructions, and prepare to send it to the upstream node.

[0086] After receiving a scheduling request, the downstream node's streaming media server searches its database for the storage location or transmission status of the target video. If the target video is currently being transmitted or has already been stored, the server transmits the video data to the upstream node. Upon receiving the video data, the upstream node completes the preview or playback request. The entire process does not require fetching the video stream from the video source device again, thus significantly reducing network communication latency and bandwidth consumption.

[0087] Suppose that in the security monitoring system of a large bank, the head office monitoring center (upstream node) needs to preview the real-time video surveillance footage of a first-level branch X. This system employs a multi-level streaming media server cluster deployment, including the head office monitoring center, multiple first-level branch monitoring centers (M layers, M=2), and second-level branch monitoring centers (N layers, N=3).

[0088] When the head office monitoring center sends a video request to retrieve the video stream from branch X, the system first searches for the cached data of that video stream in the head office monitoring center's cache. The cache records communication channel information for all retrieved video streams, including the identifier of the streaming media server, the ID of the video stream, and the current transmission status of the video stream.

[0089] If video stream data for branch X is found in the cache, it means there is a video stream currently being transmitted or already stored that can be reused. At this point, the system will schedule the downstream node where the target video resides, i.e., the streaming media server cluster of branch X. The scheduling process involves dynamically evaluating the load of each node in the branch X streaming media server cluster, using the entropy weight method to calculate the weights of hardware module utilization, and combining this with the TOPSIS model to determine which server in the cluster has the lowest load and is most suitable for providing video streaming services to the head office.

[0090] In the streaming media server cluster of Branch X, the scheduled server will begin searching for the target video from its stored or currently transmitting video streams. The server identifies the target video's communication channel information through its internal video stream management mechanism. This information includes the video stream ID, timestamp, video source device identifier, and the current status of the video stream (e.g., transmitting, stored, or not retrieved). Once the target video is found, the server begins preparing the video data and sends the video stream to the head office monitoring center via the dedicated network.

[0091] For example, a security analyst at the head office monitoring center selects to preview the live monitoring video of a first-level branch X on the monitoring system client. Upon receiving the video request, the system first searches the head office's cache for the video stream cache data of first-level branch X. Because of a previous preview request, the video stream has already been cached, and the system quickly finds the cached information for the target video. Next, the system schedules the streaming media server cluster of first-level branch X to determine the optimal node for providing the video stream.

[0092] In the streaming media server cluster of Branch X, load assessment was performed using the entropy weight method and the TOPSIS model. Server D was determined to be the node with the lowest load and the most suitable as the video source. Server D retrieved the target video stream from its cache and began transmitting the video data to the head office monitoring center. After receiving the video data, the head office monitoring center displayed the real-time monitoring screen of Branch X on the analyst's client. The entire process was efficient and fast.

[0093] In some embodiments, obtaining the target video of the downstream node according to the video request can be achieved through the following steps: if the cached data of the target video is not in the cache, call the camera of the downstream node; control the camera of the downstream node to perform shooting to obtain the target video, and send the target video to the upstream node.

[0094] This solution allows for rapid real-time video capture or retrieval of historical video from cameras when the target video is not in the cache, providing immediate response capabilities to sudden or initial request events. Even without cached data, precise scheduling of the target camera avoids unnecessary video resource fetching, reducing network bandwidth consumption, a particularly significant effect when network resources are limited. Even without cached data, dynamic camera activation flexibly handles various video requests, including real-time monitoring and historical video playback, improving the solution's adaptability and flexibility.

[0095] Specifically, when the monitoring center (upstream node) issues a video request, if the requested video stream (target video) is not found in the cache (a mechanism for temporarily storing data to quickly respond to requests), it means that the video stream has not been requested before or has expired and is not cached.

[0096] Downstream nodes refer to the monitoring centers of the first- or second-level branches where the video source device (such as a camera) is located. The system sends control commands to these nodes to call the camera corresponding to the target video. This command contains key information such as the camera ID, the type of video stream requested (real-time or historical), and the time period of the required video.

[0097] Upon receiving the call command, the downstream streaming media server controls the target camera to begin operation. If it's a real-time video request, the camera will begin capturing and streaming the video. If it's a request for historical video, the camera or its connected storage device will retrieve the video data for the corresponding time period from storage. The streaming media server is responsible for processing and encoding the video data to form the target video stream.

[0098] Once the target video stream is acquired, the streaming media server sends it to the monitoring center (upstream node) that requested the video. This process may involve cross-level transmission, such as from the second-level branch monitoring center to the first-level branch, and then to the head office monitoring center, to ensure that the video stream can be transmitted along the preset optimized path to achieve the goals of fast response and low network consumption.

[0099] Suppose that security personnel at the head office monitoring center need to review the CCTV footage of a branch X's lobby on a specific day. Upon receiving this video request, the monitoring center's system first checks its cache for corresponding CCTV data from branch X within the requested timeframe. If the data is not found in the cache (possibly because there were no previous similar requests or the cached data has expired), the system proceeds to the next step: accessing the CCTV camera.

[0100] Once the system detects that a video request cannot be fulfilled using cached data, it sends a control command to the streaming media server of branch X, requesting that the surveillance cameras in the lobby be activated. This step may involve searching the camera database, locating the target camera, and sending specific shooting instructions, including video quality settings and shooting time periods.

[0101] After receiving the call instruction from the head office, the streaming media server of branch X will control the designated camera to start working. If it is a real-time video request, the camera will start capturing images and generating a video stream in real time; if it is a historical video playback request, the system will retrieve and extract video data within the requested time range from the storage device. The streaming media server is responsible for processing and encoding the video data, converting it into a transmittable video stream format.

[0102] The streaming media server of Branch X sends the generated or retrieved target video stream to the head office monitoring center. This process may involve video stream transmission over a dedicated network to ensure video data security and transmission speed. Once the head office monitoring center receives the video stream, the video request is fulfilled, and security personnel can view or replay the target video in the monitoring system.

[0103] Specifically, in existing solutions, the weights used to calculate the streaming media with the least load are fixed, based on the hardware module utilization rate of the streaming media, the number of streaming channels, the number of preset specification channels, and the number of video streams that have been acquired from the device but not forwarded to the upstream streaming media. However, in reality, hardware usage information is often closely related to the performance of streaming media, and the weights are not fixed. Furthermore, the empirical values ​​given by humans often have deviations and cannot accurately measure the actual load of streaming media.

[0104] In the specific implementation process, before sending the target video from the downstream node to the target streaming media server of the upstream node, the method further includes the following steps: obtaining relevant metrics of the streaming media server, wherein the relevant metrics include one or more of CPU utilization, memory utilization, bandwidth utilization, number of preview streams, number of playback download streams, and number of video download streams; determining the weight values ​​of all the relevant metrics according to the entropy weight method; and using the TOPSIS algorithm, filtering from multiple streaming media servers according to the relevant metrics and their corresponding weight values ​​to find the target streaming media server.

[0105] This solution combines entropy weighting and the TOPSIS algorithm to intelligently assess the current load and performance of streaming media servers, achieving dynamic load balancing of the server cluster and ensuring high efficiency and stability of video services. This technology ensures that video requests are allocated to the server with the best current performance and lowest load, avoiding excessive resource consumption and server overload, and optimizing the overall system's resource utilization efficiency. The intelligent filtering mechanism can quickly identify and schedule target streaming media servers, reducing video request processing time and improving the real-time response capabilities of video monitoring and playback.

[0106] When the system needs to process a video request, it first collects performance metrics of the streaming media server related to video transmission. These metrics may include:

[0107] CPU utilization reflects the server's ability to process video streams and its current workload.

[0108] Memory usage: This indicates the available memory on the server and has a direct impact on video stream caching and processing speed.

[0109] Bandwidth utilization: determines the efficiency and quality of video streaming. Insufficient bandwidth may lead to video transmission delays or interruptions.

[0110] Preview Streams: This counts the number of real-time preview video streams currently being processed by the server, which affects the server's real-time responsiveness.

[0111] Playback Streams: This calculates the number of historical video streams currently being played back, reflecting the usage of server resources by the high-definition streams.

[0112] Video download path count: This records the number of video file download requests currently in progress on the server, which affects the server's storage and transmission capabilities.

[0113] Entropy weighting is a statistical method used to dynamically evaluate and determine the weights of indicators. In this scenario, the system uses entropy weighting to analyze the collected streaming media server-related indicators and calculate the weight value of each indicator's impact on overall server performance. The magnitude of the weight value reflects the relative importance of the indicator to the streaming media server performance evaluation in the current scenario.

[0114] TOPSIS (Technique for Order Preference by Similarity to an Ideal Solution) is a multi-criteria decision analysis method used to determine the option closest to the ideal solution. This system employs the TOPSIS algorithm, combining previously determined metrics and weights to evaluate the performance of each streaming media server and select the target streaming media server from multiple servers that offers the best performance and meets the current video request requirements. This algorithm considers the comprehensive impact of all relevant metrics, including not only hardware performance indicators but also the load of real-time and historical video services, ensuring that the selected server achieves an optimal balance in all aspects.

[0115] In one specific application scenario, within a large bank's multi-level security monitoring system, the head office monitoring center needs to intelligently schedule streaming media servers to ensure efficient and stable video stream transmission under high-concurrency requests for both real-time and historical data. The following are detailed implementation steps and effect demonstrations based on the aforementioned technology:

[0116] When the head office monitoring center receives a real-time video preview request from a first-tier branch, the system begins collecting key performance indicators from multiple streaming media servers. Assume there are three streaming media servers: A, B, and C. The indicators acquired by the system include: CPU utilization, memory utilization, bandwidth utilization, the number of currently previewing video streams, the number of ongoing historical video playback downloads, and the number of video file downloads for each server.

[0117] Server A's metrics are: CPU utilization 50%, memory utilization 60%, bandwidth utilization 40%, preview streams 10, playback download streams 5, and video download streams 3.

[0118] Server B's metrics are: CPU utilization 30%, memory utilization 70%, bandwidth utilization 50%, preview streams 15, playback download streams 7, and video download streams 2.

[0119] The metrics for server C are: CPU utilization 40%, memory utilization 50%, bandwidth utilization 30%, preview streams 8, playback download streams 4, and video download streams 1.

[0120] The entropy weight method was used to calculate the weight values ​​of the six metrics mentioned above (CPU utilization, memory utilization, bandwidth utilization, preview streams, playback download streams, and video download streams). Assuming the calculated weight values ​​are: 0.15 (CPU), 0.20 (memory), 0.25 (bandwidth), 0.15 (preview streams), 0.15 (playback download streams), and 0.10 (video download streams), these weight values ​​reflect the importance of each metric to the performance of the streaming media server in the current video service environment.

[0121] Next, the system uses the TOPSIS algorithm to comprehensively evaluate the calculated weight values ​​and relevant metrics of each server to determine which server is most suitable as the target server for video stream transmission. The TOPSIS algorithm first standardizes the metric values ​​of each server, then calculates the positive and negative ideal solution distances for each server based on the weight values, and finally determines the server closest to the positive ideal solution as the target server.

[0122] Assuming that the proximity scores of servers A, B, and C, calculated using the TOPSIS algorithm, are 0.65, 0.82, and 0.74, respectively, the system will select server B as the target streaming media server to handle video preview requests from the first-level branch.

[0123] Specifically, this solution is based on the entropy weight-TOPSIS model for video stream transmission. This method considers factors such as the type of client video stream request, reuse of existing video streams, and selection of the least loaded streaming media, thereby improving the throughput of the streaming media cluster system and providing a better user experience for clients. Before a client initiates a video request, it queries the streaming media cluster cache directly under the client's organization to obtain the streaming media server with the lowest current load, and then connects to the target server to proceed with subsequent steps.

[0124] Specifically, this solution selects the service node with the lowest load as the optimal node based on the entropy weight-TOPSIS model. The entropy weight method is used to dynamically calculate the weights of each indicator to avoid the inaccuracy of empirical values. The TOPSIS model is combined with indicators such as CPU utilization, memory utilization, bandwidth utilization, preview streams, and playback / video download streams of the streaming media server to achieve the selection of the node with the lowest load, thereby improving the throughput of the streaming media cluster system and providing a good experience for the client.

[0125] Specifically, this scheme dynamically determines the weights of various metrics on a streaming media server, such as CPU utilization, memory utilization, and bandwidth utilization. The entropy weight method is based on information entropy theory; the lower the information entropy, the greater the dispersion of the metric, and the greater its impact on the overall evaluation, meaning its weight should be higher. This method avoids using fixed or empirical weights and can more accurately reflect the actual load on the server.

[0126] TOPSIS, short for Technique for Order Preference by Similarity to an Ideal Solution, is a decision analysis method used to identify the optimal and suboptimal solutions among multiple alternatives. In this approach, TOPSIS selects the streaming media server with the lowest load. It evaluates server performance by calculating the distance of each server to the "ideal solution" (best performance) and the "worst solution" (worst performance). Servers closer to the ideal solution and farther from the worst solution are considered to have the lowest load and are most suitable as nodes for video streaming.

[0127] Specifically, in the aforementioned scheme, the weights for selecting the streaming media with the lowest load based on its status information are fixed. However, in reality, hardware utilization is often closely related to streaming media performance, and the weights are not fixed. Moreover, empirical values ​​often have biases and cannot accurately measure the actual load of the streaming media. This scheme provides a dynamically adjustable weight based on the operating status, comprehensively considering the influence of various indicators to obtain the optimal selection.

[0128] Currently, in the banking sector, due to bandwidth limitations and high costs of dedicated networks, inter-regional networks are often disconnected, leading to excessive reliance on scheduling servers for communication during streaming media transmission. Furthermore, video requests are often intercepted by the scheduling service, potentially causing loopbacks in streaming media service requests. This solution proposes sending requests directly to the streaming media service directly under the institution's jurisdiction. Each service updates its cache information based on its current state, eliminating loopback issues and resulting in shorter response times and reduced network resource consumption.

[0129] Specifically, the method for obtaining the streaming media server with the lowest load mentioned in the above steps selects CPU utilization, memory utilization, bandwidth utilization, preview streams, and playback / video download streams as load calculation indicators for the streaming media service. The entropy weight method is used to calculate the weights of each indicator to dynamically measure the impact of each indicator on the streaming media load. Then, based on the TOPSIS model, the node in the cluster closest to the optimal solution and furthest from the worst solution is selected as the streaming media node with the lowest load. The selection of the minimum load node is based on the entropy weight-TOPSIS model, such as... Figure 5 As shown, the specific steps are as follows:

[0130] (1) Data standardization:

[0131] There are m streaming media server nodes, and n node load evaluation metrics. The server node to be evaluated is denoted as X. ij(i = 1, 2, ..., m; j = 1, 2, ..., n) represents the j-th evaluation metric for the i-th server node, and the data matrix X corresponding to the metric is as follows:

[0132]

[0133] Because the selected evaluation indicators differ in nature and magnitude, to apply the entropy weighting method, the impact of these differences on the evaluation results must first be eliminated. After data standardization, the original evaluation matrix model X yields a new matrix Y = {y...} ij}(0≤i≤1,0≤j≤1), y ij Let y be the standardized value of the j-th evaluation index for the i-th evaluation object. ij ∈[0,1]. Transform all indicators into directions where smaller values ​​are better. The specific formula is:

[0134]

[0135] The matrix Y after standardization is:

[0136]

[0137] (2) Determine the proportion of the j-th indicator in the i-th evaluation sample, and calculate the entropy value of the j-th indicator:

[0138]

[0139]

[0140] (3) Calculate the degree of difference in entropy values:

[0141] g j =1-e j .

[0142] (4) Calculate the entropy weight of the j-th indicator:

[0143]

[0144] (5) Construct the normalized decision matrix:

[0145] Based on the TOPSIS calculation requirements, normalization is performed on the basis of the standardization process in step 1 to ensure that the directions are consistent when calculating the positive and negative ideal solutions in the following text.

[0146]

[0147] The normalization process yields a new matrix:

[0148]

[0149] By multiplying the calculated entropy weight Wj by matrix Y′, we obtain the formula for the objective weighted evaluation matrix:

[0150]

[0151] (6) Calculate the optimal and worst solutions based on the weighted evaluation matrix:

[0152]

[0153] (7) Calculate the distance from the weighted standardized vector of the sample evaluation index to the optimal and worst solutions.

[0154]

[0155] (8) Calculate the proximity of the optimal solution for each streaming media and sort them in ascending order. The higher the ranking, the lower the load, and vice versa.

[0156]

[0157] In some embodiments, after sending the target video from the downstream node to the target streaming media server of the upstream node, the method further includes the following steps: obtaining the status information and video channel information of the streaming media server in the cache, wherein the status information is the operating status data of the streaming media server at a certain moment, and the video channel information is the transmission path of the video stream; updating the status information and video channel information in the cache to obtain the updated status information and the updated video channel information.

[0158] This solution accurately assesses server load by updating status information in real time, preventing over-allocation of resources and achieving dynamic load balancing across the server cluster. This not only improves resource utilization efficiency but also ensures the stability and response speed of the video service. Updated video channel information helps quickly identify which video streams are cached or currently being transmitted, enabling video stream reuse, reducing frequent access to source devices and network resource consumption, and improving the overall efficiency of the video service.

[0159] Specifically, in the bank's multi-level security monitoring system, each level of the monitoring center deploys a streaming media server cluster to handle the reception, forwarding, and storage of video streams. To achieve fast and intelligent video stream scheduling, the system maintains a cache that stores the status information of the streaming media servers and video channel information.

[0160] Status information refers to the operational status data of a streaming media server at a given moment, including but not limited to CPU utilization, memory utilization, bandwidth utilization, and the number of preview and playback streams. This data reflects the server's current load and performance, and is crucial for intelligent scheduling.

[0161] Video channel information refers to the transmission path of a video stream within a server cluster, including the source device of the video stream, the streaming media servers it passes through, and the target receiver (such as a client in a monitoring center). This information is used to quickly identify the current location of the video stream and whether another server is already processing the same video stream, thereby enabling video stream reuse and reducing additional resource consumption.

[0162] The system automatically updates the cached streaming media server status information and video channel information periodically or when triggered by specific events (such as the start or end of video streaming). Updates to the status information involve real-time collection of server performance data, including CPU, memory, and bandwidth usage, as well as the number of preview and playback streams. Updates to the video channel information include recording the latest transmission path of the video stream and which servers are currently processing or have already processed a specific video stream.

[0163] Once the update process is complete, the system will have the latest and most accurate streaming media server status information and video channel information. This updated information is crucial for subsequent video stream scheduling decisions, ensuring that the system can make optimal decisions based on current server performance and resource usage when processing new video requests.

[0164] Specifically, status information refers to the operational status data of a streaming media server at a certain moment, including but not limited to the following:

[0165] CPU utilization: The degree to which the server's processors are being used;

[0166] Memory utilization: The amount of available memory used by the server;

[0167] Bandwidth utilization: The bandwidth usage of the network connection, especially the portion used for video streaming;

[0168] Preview Streams: The number of video streams currently being previewed by the client;

[0169] Playback / Video Download Streams: The number of video streams currently in playback or video download operation.

[0170] This information is an important indicator of the streaming media server load. By updating the status information in real time, the system can accurately determine the real-time load status of the server, providing a basis for subsequent entropy weight calculation and the selection of the minimum load node in the TOPSIS model.

[0171] Video stream channel information refers to the path and status details of the video stream transmitted from the video source to the client, including:

[0172] Video Stream ID: An ID used to uniquely identify a video stream;

[0173] Source streaming media server: The streaming media server where the video stream originally resides;

[0174] Current streaming media server: The server currently transmitting this video stream, which may have gone through multiple levels of streaming media servers;

[0175] Client Information: Information about the client receiving the video stream, including the client ID and connection status.

[0176] The above approach ensures that the same video stream can be reused by multiple requests, avoiding resource waste and redundant bandwidth consumption. It determines the shortest path of the video stream from the source to the client, reducing transmission latency. If video stream transmission is interrupted, transmission can be quickly resumed without re-establishing a connection or starting the stream from scratch.

[0177] Whenever a video stream connection ends (e.g., the client stops previewing the video) or the video stream is interrupted (e.g., due to network issues), the streaming media server updates the aforementioned status information and video stream channel information. This means that the server load is adjusted in real time, and the video stream multiplexing status is updated. The system can immediately reflect the latest resource availability and provide optimal scheduling decisions for the next video stream request. This mechanism ensures high performance and efficiency, especially in high-concurrency and bandwidth-constrained environments.

[0178] In summary, this application employs the entropy weight method and the TOPSIS model to dynamically evaluate the load of streaming media servers and select the optimal service node accordingly. The entropy weight method dynamically adjusts the weights of each indicator by calculating its information entropy to reflect the true load of the server. The TOPSIS model, based on the optimized weights, comprehensively considers multiple indicators (such as CPU utilization, memory utilization, and bandwidth utilization) to calculate the distance of each server from the ideal state, thereby selecting the server closest to the ideal state, i.e., the one with the lowest load, to respond to video streaming requests.

[0179] The solution proposed in this application emphasizes the reuse of existing video streams during video streaming, rather than fetching them anew each time. This means that if a video stream has already been used by a client, other clients requesting the same video stream can utilize the existing stream without having to push the stream from the source again. This significantly reduces network bandwidth requirements and the pressure on the video source, thereby improving resource utilization.

[0180] This application's solution also considers the hierarchical management characteristics of bank security systems, designing a multi-level streaming media service cluster deployment method to avoid the latency and request loop problems that may be caused by traditional centralized scheduling servers. Each streaming media service node can make independent decisions based on local cache and status information without waiting for a response from the central scheduling server, which speeds up request processing and enhances system stability and responsiveness.

[0181] This application also provides a video streaming device for use in banks. It should be noted that the video streaming device for use in banks described in this application can be used to execute the video streaming method for use in banks provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0182] The following describes the video streaming device for use in banks provided in the embodiments of this application.

[0183] Figure 6 This is a structural block diagram of a video streaming device applied in a bank, according to an embodiment of this application. Figure 6 As shown, the device includes:

[0184] The first acquisition unit 10 is used to acquire a video request, wherein the video request is a request from an upstream node to a downstream node to send a video.

[0185] The second acquisition unit 20 is used to acquire the target video of the downstream node according to the video request.

[0186] The sending unit 30 is used to send the target video of the downstream node to the target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the streaming media server with the lowest load among the multiple streaming media servers.

[0187] In this embodiment, when video transmission is required, the downstream transmits the video to the upstream streaming media server with the least load. This can improve the throughput of the streaming media cluster, and the video can be allocated to the streaming media server with the best performance and fastest response, thereby achieving load balancing of the streaming media servers and avoiding overload of a single streaming media server.

[0188] In the specific implementation process, the above-mentioned device also includes a third acquisition unit and a scheduling unit. The third acquisition unit is used to acquire the first scheduling information of the Nth layer node before acquiring the video request. The first scheduling information is the information of the Nth layer node requesting the scheduling of the N+1th layer node, where N≥1. The scheduling unit is used to schedule the N+1th layer node to provide services to the Nth layer node based on the first scheduling information.

[0189] This solution avoids the information feedback delays inherent in traditional centralized scheduling and reduces the risk of service unavailability due to central node downtime. Furthermore, through multi-level cascading and video stream multiplexing, unnecessary video stream transmission is reduced, saving network resources and costs. The intelligent scheduling strategy ensures efficient resource utilization, reduces the streaming pressure on video source devices, and since the Nth-level node can directly schedule the N+1th-level node, the number of request processing layers is reduced, improving the efficiency of video stream processing and system performance.

[0190] In some embodiments, the above-described apparatus further includes a fourth acquisition unit, a sending unit, and a processing unit. The fourth acquisition unit is used to acquire third scheduling information of the first node of the M layer before acquiring a video request, wherein the third scheduling information is information of the first node of the M layer requesting to schedule the second node of the M layer, M≥2, M≤N; the sending unit is used to send the third scheduling information to the node of the (M-1)th layer; the processing unit is used to schedule the second node of the M layer to provide services to the node of the (M-1)th layer based on the third scheduling information, and the node of the (M-1)th layer forwards the data sent by the second node of the M layer to the first node of the M layer.

[0191] This scheme achieves efficient scheduling and transmission of video streams across a multi-layered structure through cross-level data forwarding, ensuring the continuity and timeliness of data transmission. The multi-level scheduling mechanism ensures secure information transmission between nodes at each level, while data forwarding through upper-level nodes makes the video stream transmission path more controllable, avoiding the risk of data leakage that might arise from direct cross-level communication.

[0192] In the specific implementation process, the second acquisition unit includes a search module, a scheduling module, and a sending module. The search module is used to search in the cache for whether there is cached data of the target video according to the video request. The scheduling module is used to schedule the downstream node where the target video is located if there is cached data of the target video in the cache. The sending module is used to find the target video from the streaming media server of the downstream node and send the target video to the upstream node.

[0193] In this solution, the caching mechanism enables the system to quickly respond to repeated video requests without needing to retrieve the video stream from the video source device, significantly improving video stream scheduling speed and user experience. Reusing cached data reduces frequent access to the video source device, lowering data transmission bandwidth requirements.

[0194] In some embodiments, the second acquisition unit includes a calling module and a processing module. The calling module is used to call the camera of the downstream node when there is no cached data of the target video in the cache. The processing module is used to control the camera of the downstream node to perform shooting operations, obtain the target video, and send the target video to the upstream node.

[0195] This solution allows for rapid real-time video capture or retrieval of historical video from cameras when the target video is not in the cache, providing immediate response capabilities to sudden or initial request events. Even without cached data, precise scheduling of the target camera avoids unnecessary video resource fetching, reducing network bandwidth consumption, a particularly significant effect when network resources are limited. Even without cached data, dynamic camera activation flexibly handles various video requests, including real-time monitoring and historical video playback, improving the solution's adaptability and flexibility.

[0196] In specific implementation, the above-mentioned device further includes a fifth acquisition unit, a determination unit, and a filtering unit. The fifth acquisition unit is used to acquire relevant indicators of the streaming media server before sending the target video from the downstream node to the target streaming media server of the upstream node. The relevant indicators include one or more of CPU utilization, memory utilization, bandwidth utilization, number of preview channels, number of playback download channels, and number of video download channels. The determination unit is used to determine the weight values ​​of all the relevant indicators according to the entropy weight method. The filtering unit is used to use the TOPSIS algorithm to filter from multiple streaming media servers according to the relevant indicators and their corresponding weight values ​​to find the target streaming media server.

[0197] This solution combines entropy weighting and the TOPSIS algorithm to intelligently assess the current load and performance of streaming media servers, achieving dynamic load balancing of the server cluster and ensuring high efficiency and stability of video services. This technology ensures that video requests are allocated to the server with the best current performance and lowest load, avoiding excessive resource consumption and server overload, and optimizing the overall system's resource utilization efficiency. The intelligent filtering mechanism can quickly identify and schedule target streaming media servers, reducing video request processing time and improving the real-time response capabilities of video monitoring and playback.

[0198] In some embodiments, the above-described apparatus further includes a sixth acquisition unit and an update unit. The sixth acquisition unit is used to acquire, after sending the target video from the downstream node to the target streaming media server of the upstream node, the status information and video channel information of the streaming media server in the cache, wherein the status information is the operating status data of the streaming media server at a certain moment, and the video channel information is the transmission path of the video stream; the update unit is used to update the status information and the video channel information in the cache to obtain the updated status information and the updated video channel information.

[0199] This solution accurately assesses server load by updating status information in real time, preventing over-allocation of resources and achieving dynamic load balancing across the server cluster. This not only improves resource utilization efficiency but also ensures the stability and response speed of the video service. Updated video channel information helps quickly identify which video streams are cached or currently being transmitted, enabling video stream reuse, reducing frequent access to source devices and network resource consumption, and improving the overall efficiency of the video service.

[0200] The aforementioned video streaming device for use in banks includes a processor and a memory. The first acquisition unit, the second acquisition unit, and the sending unit are all stored as program units in the memory, and the processor executes these program units to achieve their respective functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0201] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, the problem of uneven load distribution in existing streaming media polling scheduling strategies can be addressed. This uneven load can lead to overload or even crashes of individual streaming media streams, thus affecting the stable operation of the entire system.

[0202] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0203] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the video streaming method applied to a bank.

[0204] This invention provides a processor for running a program, wherein the program executes the video streaming method applied to banks.

[0205] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements at least the steps of a video streaming method applied to banking. The device described herein can be a server, PC, tablet, mobile phone, etc.

[0206] A computer program product includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the video streaming method for banks described in various embodiments of this application.

[0207] This application also provides a video transmission system, including: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include methods for performing any of the above-described video streaming methods applied to banks.

[0208] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0209] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0210] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0211] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0212] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0213] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

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

[0215] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0216] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0217] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A video stream transmission method applied in banks, characterized in that, include: Obtain a video request, wherein the video request is a request from an upstream node to a downstream node to send a video; Based on the video request, obtain the target video of the downstream node; The target video of the downstream node is sent to the target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the streaming media server with the lowest load among the multiple streaming media servers.

2. The method according to claim 1, characterized in that, Before obtaining the video request, the method further includes: Obtain the first scheduling information of the Nth layer node, wherein the first scheduling information is the information of the Nth layer node requesting to schedule the N+1th layer node, where N≥1; Based on the first scheduling information, the N+1 layer node is scheduled to provide services to the N layer node.

3. The method according to claim 2, characterized in that, Before obtaining the video request, the method further includes: Obtain the third scheduling information of the first node in the Mth layer, wherein the third scheduling information is the information of the first node in the Mth layer requesting to schedule the second node in the Mth layer, M≥2, M≤N; The third scheduling information is sent to the node at layer M-1; Based on the third scheduling information, the second node of the M layer is scheduled to provide services to the node of the M-1 layer, and the node of the M-1 layer forwards the data sent by the second node of the M layer to the first node of the M layer.

4. The method according to claim 1, characterized in that, Based on the video request, obtain the target video of the downstream node, including: Based on the video request, check the cache to see if there is cached data for the target video; If the cached data of the target video exists in the cache, schedule the downstream node where the target video is located; The target video is located in the streaming media server of the downstream node and sent to the upstream node.

5. The method according to claim 4, characterized in that, Based on the video request, obtain the target video of the downstream node, including: If the cached data of the target video is not in the cache, the camera of the downstream node is invoked; The downstream node's camera is controlled to capture the target video, which is then sent to the upstream node.

6. The method according to claim 1, characterized in that, Before sending the target video from the downstream node to the target streaming media server of the upstream node, the method further includes: Obtain relevant metrics of the streaming media server, wherein the relevant metrics include one or more of CPU utilization, memory utilization, bandwidth utilization, number of preview streams, number of playback download streams, and number of video download streams; The weight values ​​of all the relevant indicators are determined according to the entropy weight method; The TOPSIS algorithm is used to filter from multiple streaming media servers based on the relevant indicators and their corresponding weight values ​​to find the target streaming media server.

7. The method according to any one of claims 1 to 6, characterized in that, After sending the target video from the downstream node to the target streaming media server of the upstream node, the method further includes: Obtain the status information and video channel information of the streaming media server from the cache, wherein the status information is the operating status data of the streaming media server at a certain moment, and the video channel information is the transmission path of the video stream; Update the status information and video channel information in the cache to obtain the updated status information and video channel information.

8. A video streaming device for use in banks, characterized in that, include: The first acquisition unit is used to acquire a video request, wherein the video request is a request from an upstream node to a downstream node to send a video. The second acquisition unit is used to acquire the target video of the downstream node according to the video request; The sending unit is used to send the target video of the downstream node to the target streaming media server of the upstream node, wherein the upstream node includes multiple streaming media servers, and the target streaming media server is the streaming media server with the lowest load among the multiple streaming media servers.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the video streaming method for banks as described in any one of claims 1 to 7.

10. A video transmission system, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing the video streaming method for use in a bank as described in any one of claims 1 to 7.

Images