Method, device and system for determining video stream information

Abstract

This application provides a method, apparatus, system, electronic device, computer-readable medium, and program product for determining video stream information. One specific embodiment of this application includes: determining the target storage location of the target video stream indicated by a video stream acquisition request based on a multi-level cache adapted to the video stream system architecture; generating a routing response based on the target storage location; and sending the routing response to the requesting client to which the video stream acquisition request belongs. This application determines the storage location of the target video stream based on a multi-level cache adapted to the video stream system architecture, enriching the methods for determining the storage location, avoiding the system bottleneck caused by completely relying on location query services, and helping to improve the efficiency of determining video stream information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, system, electronic device, computer-readable medium, and program product for determining video stream information. Background Technology

[0002] With the rapid development of the live streaming industry, HLS (HTTP Live Streaming) has become the mainstream protocol for internet live streaming. In large-scale live streaming scenarios, a multi-layered CDN (Content Delivery Network) distribution architecture is typically adopted, including a two-layer structure of origin and edge nodes. When a user requests a live stream, the system needs to quickly decide whether to route the request to the edge node or the origin to balance latency, bandwidth costs, and service availability.

[0003] Currently, static configuration or simple load balancing strategies are typically used, requiring real-time queries to the streaming location service to determine the routing target for each request.

[0004] This section is intended to provide background or context for the embodiments of this application as set forth in the claims. The description herein is not to be construed as prior art simply because it is included in this section. Summary of the Invention

[0005] This application provides a method, apparatus, system, electronic device, computer-readable storage medium, and program product for determining video stream information. Addressing the technical problems in the prior art where users requesting video streams always require a location lookup service, leading to excessive pressure and becoming a system bottleneck, this application determines the storage location of the target video stream based on a multi-level cache adapted to the video stream system architecture. This enriches the methods for determining the storage location, avoids the system bottleneck caused by relying entirely on the location lookup service, and helps improve the efficiency of determining video stream information.

[0006] One aspect of this application provides a method for determining video stream information, comprising: determining the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video stream system architecture; generating a routing response according to the target storage location; and sending the routing response to the requesting end to which the video stream acquisition request belongs.

[0007] Another aspect of this application provides a video stream information determination apparatus, comprising: a location determination unit configured to determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video stream system architecture; and a routing response unit configured to generate a routing response based on the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs.

[0008] Another aspect of this application provides a video streaming system, including a requesting end and a server. The requesting end is used to send a video stream acquisition request to the server. The server is used to: determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video streaming system architecture; generate a routing response according to the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs; the requesting end is also used to acquire the target video stream according to the routing response.

[0009] In another aspect of this application, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method for determining video stream information as described above.

[0010] Another aspect of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the method for determining video stream information as described above.

[0011] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method for determining video stream information as described above.

[0012] The solution provided in this application determines the target storage location of the target video stream indicated by the video stream acquisition request by using a multi-level cache adapted to the video stream system architecture; a routing response is generated based on the target storage location and sent to the requesting end to which the video stream acquisition request belongs. This enriches the methods for determining the storage location, avoids the system bottleneck caused by relying entirely on the location query service, and helps to improve the efficiency of determining video stream information.

[0013] Furthermore, the storage location of the video stream is determined sequentially based on blacklist caching, multi-level caching, and fallback caching, ensuring the stability and reliability of the routing decision-making process while achieving efficient routing decisions. Blacklist caching and multi-level caching are set according to different media characteristics such as media encapsulation format and media playback mode, ensuring that different types of video stream acquisition requests use independent cache spaces, further improving cache reliability and routing decision efficiency. For the routing response fed back to the requesting end, different effective durations are set according to the media playback mode of the requesting end, allowing the requesting end to repeatedly request the same video stream based on the routing response within the effective duration, reducing the number of requests and further improving the efficiency of video stream acquisition. Attached Figure Description

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

[0015] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0016] Figure 1 A flowchart illustrating a method for determining video stream information according to an embodiment of this application;

[0017] Figure 2 This is a schematic diagram illustrating the process of determining video stream information in this application.

[0018] Figure 3 A flowchart illustrating a method for determining video stream information according to another embodiment of this application;

[0019] Figure 4 This is a schematic diagram of the structure of a video stream information determination device provided in an embodiment of this application;

[0020] Figure 5 This is a schematic diagram of the structure of a video streaming system provided in an embodiment of this application;

[0021] Figure 6 A schematic diagram of the structure of a device suitable for implementing the solutions in the embodiments of this application.

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

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

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

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

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

[0027] This application provides a method for determining video stream information. By using a multi-level cache adapted to the video stream system architecture, the target storage location of the target video stream indicated by the video stream acquisition request is determined. A routing response is generated based on the target storage location and sent to the requesting end to which the video stream acquisition request belongs. This method, based on a multi-level cache adapted to the video stream system architecture, enriches the methods for determining the storage location, avoids the system bottleneck caused by relying entirely on the location query service, and helps to improve the efficiency of determining video stream information.

[0028] It should be noted that the collection, storage, and use of any type of data, such as user data, involved in the technical solution of this application comply with relevant national laws and regulations and are carried out with the explicit authorization of the user.

[0029] In practical scenarios, the execution entity of this method can be a user device, a device formed by integrating user devices and network devices through a network, or an application running on the aforementioned devices. The user devices include, but are not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network devices include, but are not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0030] Figure 1 The present application illustrates a processing flow 100 for a method of determining video stream information according to an embodiment of this application. The processing flow 100 includes the following steps:

[0031] Step 101: Based on the multi-level caching adapted to the video streaming system architecture, determine the target storage location of the target video stream indicated by the video stream acquisition request.

[0032] The video streaming system architecture refers to a distributed node deployment system used to provide video streaming distribution, scheduling and access services. It is organized in a hierarchical or distributed manner according to the node deployment location, service level and data flow direction, and is used to support efficient access and routing of video streaming services such as live streaming, time-shifting and video-on-demand.

[0033] Video streaming system architectures include, but are not limited to, a two-tier distribution architecture based on CDN: origin-edge nodes; a three-tier distribution architecture with multiple regional center nodes, regional edge nodes, and access nodes; an architecture based on cloud vendor availability zones with availability zone nodes and the nearest access node; a super node + ordinary node architecture with pure P2P (Peer-to-Peer) hybrid scheduling; and a multi-origin-multi-level edge hybrid architecture with multi-origin redundancy and cross-city scheduling.

[0034] Multi-level caching refers to a multi-level cache set that corresponds to the nodes at each level in the video streaming system architecture and is used to cache the storage location information of the video stream. Each level of cache corresponds to the location information of different nodes in the architecture, which is used to achieve fast query and nearest routing.

[0035] For example, in the origin-edge node architecture, multi-level caching includes origin cache and edge node cache; in the three-level distribution architecture, multi-level caching includes central cache, regional cache, and access layer cache; in the multi-availability zone architecture, multi-level caching includes availability zone-level cache and nearest-schedule cache; and in the multi-origin redundancy architecture, multi-level caching includes primary origin cache, backup origin cache, and edge cache.

[0036] A video stream retrieval request is an access request initiated by the requesting end to obtain target video stream data. It carries relevant parameters for locating the target video stream and determining the playback method. The gateway or scheduling service completes the routing decision based on this request.

[0037] Video stream acquisition requests include, for example, HLS live streaming requests initiated by the client; HLS time-shift playback requests initiated by the client; origin requests initiated by edge nodes to upper-layer nodes; and fMP4 / TS format video stream index file requests initiated by the playback terminal.

[0038] A video stream is an audio and video data transmission carrier formed by encoding and transmitting consecutive video frames in a time sequence. It is the basic data form for realizing the distribution and playback of audio and video content and can be divided into different types according to the time correlation between transmission and playback.

[0039] Video streams include, for example, real-time streams, such as live audio and video data streams pushed by live users in real time, and audio and video data streams of live broadcasts of events; and non-real-time streams, such as pre-stored audio and video data streams for video on demand, and stored audio and video data streams for live replays.

[0040] As an example, in a three-tier video stream distribution system architecture consisting of multiple regional center nodes, regional edge nodes, and access nodes, multi-level caches are pre-configured to correspond to the three node levels of this architecture. Specifically, a center-level cache is configured for the corresponding center node, a regional-level cache is configured for the corresponding regional edge node, and an access-level cache is configured for the corresponding access node. Each level of cache is used to store the storage location information of the video stream, and the cache level corresponds one-to-one with the node level, realizing hierarchical caching and fast retrieval of storage location information. When a video stream retrieval request is received from a requesting end (such as a playback terminal or mobile device), the target video stream indicated by the request is used as the core query object. Following the query order of "access-level cache → regional-level cache → center-level cache", the storage location query operation is performed sequentially in each level of cache. During the query process of each level of cache, the target video stream-related identifier carried in the request is matched. If the storage location information corresponding to the target video stream is hit in a certain level of cache, the subsequent cache query operation is stopped, and the hit storage location is determined as the target storage location, completing the target storage location determination process based on multi-level cache.

[0041] As another example, in a distributed video streaming system architecture based on cloud provider availability zones and nearest access nodes, availability zone-level caches are configured for each availability zone node, and scheduling caches are configured for each nearest access node, thus forming a multi-level cache adapted to this architecture. Upon receiving a video stream retrieval request from the requesting end, the system uses the target video stream indicated in the request as the query object. Following the order of nearest access scheduling cache and availability zone-level cache, the system queries the storage location information of the target video stream layer by layer in the multi-level cache. If a cache level matches the corresponding storage location, it is determined as the target storage location of the target video stream.

[0042] In some optional implementations of this embodiment, the multi-level cache includes an origin cache and an edge node cache in sequence. The origin cache includes the storage location of the video stream stored at the origin, and the edge node cache includes the storage location of the video stream stored at the edge node.

[0043] The source station is the core data node of the video streaming system. It is used to store the original video stream data and complete video stream resources. It is the source of video stream distribution and has the functions of generating, storing, and managing video stream data, as well as providing video stream storage location information to the upper-level scheduling service. It plays a fundamental supporting role in the unified management and distribution of video stream resources.

[0044] Origin cache is a cache unit deployed on the origin node. Its core storage content is "storage location information of all video streams stored on the origin itself". This storage location information specifically includes key information such as the storage path, index address, and access port of the video streams within the origin. It is used to quickly respond to various query requests, avoid having to traverse all storage resources of the origin for each query, and improve the query efficiency of the video stream storage location on the origin side.

[0045] Edge nodes are distributed nodes deployed close to the requesting end (such as playback terminal or access device). They are end nodes in the video stream distribution process and are used to cache popular and frequently used video stream resources obtained from the origin server and their corresponding storage location information. Their core function is to shorten the physical distance between the requesting end and the video stream storage location, reduce the video stream acquisition latency, and improve the video playback experience on the requesting end.

[0046] Edge node caching is a caching unit deployed on edge nodes. Its core storage content is the storage location information of the video streams stored on the edge node itself. These video streams are resources that the edge node obtains and caches from the origin server. The corresponding storage location information includes the local storage path, access identifier, transmission parameters, etc. of the video streams within the edge node, which is used to quickly respond to the query needs of the requesting end within the coverage area of ​​this node, and realize the nearest query and the nearest distribution.

[0047] In this implementation, step 101 is performed as follows to determine the target storage location of the target video stream indicated by the video stream acquisition request: according to the query order among the multi-level caches, the storage location query operation for the target video stream is performed in each level of cache in turn until the target storage location is determined.

[0048] As an example, in the scenario of live video streaming, the system adopts a distribution architecture consisting of the origin server and edge nodes, and configures a multi-level cache adapted to this architecture. The multi-level cache consists of the origin server cache and the edge node cache. The origin server cache stores the storage location of all live video streams at the origin server, and the edge node cache stores the storage location of the live video streams cached at the current edge node.

[0049] When the system receives a request from the requesting client to retrieve a live video stream and needs to determine the target storage location of the target live video stream, it strictly follows the preset query order of multi-level caching. First, it performs a storage location query operation on the origin server cache, extracts the stream identifier of the target live video stream carried in the request, and matches the storage location information corresponding to the stream identifier in the origin server cache. During the query process, it verifies whether the stream identifier and the cache entry are completely consistent to ensure the accuracy of the query results. If the storage location of the target live video stream is found in the origin server cache, that storage location is determined to be the target storage location, and subsequent query operations stop.

[0050] If the storage location of the target live video stream is not found in the origin cache, the system continues to send a query request to the edge node cache according to the query order. The system matches the stream identifier of the target live video stream in the nearest edge node cache of the requesting end, extracts the corresponding edge node storage location, and determines the edge node storage location as the target storage location, thus completing the entire storage location query process. This ensures that the requesting end can quickly obtain the video stream storage location in the live streaming scenario, guaranteeing the smoothness of live streaming playback.

[0051] As another example, in the video streaming on-demand service scenario, the system also adopts a distribution architecture consisting of the origin server and edge nodes. The multi-level cache consists of the origin server cache and the edge node cache. The origin server cache stores the complete storage location information of all on-demand video streams on the origin server, while the edge node cache stores the local storage location information of popular on-demand video streams on the node (popular on-demand video streams are dynamically filtered and cached to edge nodes by the system based on access frequency).

[0052] When the system receives a request from the requesting client to obtain a video stream on demand, and needs to determine the target storage location of the target video stream on demand, it first queries the source cache according to the preset multi-level cache query order. Based on the identifier of the target video stream on demand, video segment number and other information carried in the request, it retrieves the corresponding storage location in the source cache. If a matching storage location is found (i.e. the original storage location of the video stream is in the source server), the source server storage location is determined as the target storage location, and the query ends.

[0053] If the storage location of the target on-demand video stream is not found in the origin cache (i.e., the video stream has been cached to the edge node and is not stored in the origin cache), the system switches to the edge node cache for querying. It accurately matches the identifier of the target on-demand video stream in the nearest edge node cache, extracts its storage location on the edge node, determines the storage location as the target storage location, and completes the query process.

[0054] In this implementation, the storage location of the video stream can be quickly located through hierarchical caching and ordered querying, which can reduce repeated retrieval, reduce response latency, and ensure accurate location, thereby improving the playback smoothness and service stability of the video stream.

[0055] In some optional implementations of this embodiment, before determining the storage location of the target video stream based on the multi-level cache, the following operation is also performed: determining the multi-level cache corresponding to the media characteristics of the video stream acquisition request.

[0056] Media features are identifying characteristics used to distinguish different video stream service attributes, resource types, or scheduling dimensions, enabling the isolation and differentiated management of cache space. Examples include video stream service type, video resolution level, the service channel to which the video stream belongs, and the user access region type.

[0057] As an example, different multi-level caching is set for different video stream service types and video resolution levels. Specifically, for the service type of live streaming and the resolution of 4K, a separate multi-level cache is set; for the service type of live streaming and the resolution of 1080P, a separate multi-level cache is set; for the service type of video-on-demand and the resolution of 4K, a separate multi-level cache is set; and for the service type of video-on-demand and the resolution of 1080P, a separate multi-level cache is set.

[0058] As an example, independent and isolated multi-level cache partitions are pre-built according to different media characteristics. The cache under each media characteristic category includes origin cache and edge node cache. After receiving a video stream acquisition request, the media characteristic type to which the request belongs is first parsed to determine the dedicated multi-level cache corresponding to that media characteristic type. Then, the storage location is queried in the corresponding cache in the order of origin cache and edge node cache until the target storage location is determined.

[0059] In this implementation, multi-level caches are independently partitioned according to media characteristics, avoiding mutual interference between caches of different types of video streams, improving query accuracy and cache hit rate, reducing retrieval conflicts, and improving system scheduling efficiency and stability.

[0060] In some optional implementations of this embodiment, media features include media encapsulation format and media playback mode. The media encapsulation format is a standardized form for packaging and encapsulating video stream data, determining the transmission and parsing structure of the stream; for example, it may be fMP4 encapsulation or TS encapsulation under the HLS protocol. The media playback mode reflects the user's usage of the video stream and the business scenario, determining the scheduling and caching strategy; for example, it may be live streaming mode or time-shift playback mode.

[0061] For media features encapsulated in fMP4 and live streaming mode, set up independent multi-level caches; for media features encapsulated in fMP4 and time-shift playback mode, set up independent multi-level caches; for media features encapsulated in TS and live streaming mode, set up independent multi-level caches; for media features encapsulated in TS and time-shift playback mode, set up independent multi-level caches.

[0062] The system pre-configures a time-shift judgment threshold (e.g., 5 seconds) to judge the time-shift parameters in the request: if the time-shift seconds carried by the request are less than or equal to the preset threshold, it indicates that the time deviation between the current requested playback content and the real-time live stream is extremely small, and it is essentially still a need to watch the real-time live stream, rather than a need to actively trace back the time shift of historical video content.

[0063] At this point, the system classifies the request as a live stream request, automatically removes the time-shift parameters, and proceeds with subsequent processes such as generating routing responses and configuring caching strategies according to the processing logic of live stream requests. This avoids invalid time-shift parameters interfering with live stream scheduling, CDN caching, and playback continuity, ensuring the processing efficiency of live stream requests and the real-time performance of playback.

[0064] If the number of seconds of time shift in the request is greater than the preset threshold, it is determined to be a standard time shift request. The time shift parameters are retained and processed according to the time shift business logic to ensure that users can accurately obtain the video content of the corresponding historical time period.

[0065] In this implementation, the multi-level cache corresponding to the media characteristics of the video stream acquisition request is determined in the following way: the multi-level cache corresponding to the media encapsulation format and the media playback mode is determined.

[0066] As an example, the system pre-establishes isolated multi-level caches for different media container formats and media playback modes. Each type of cache includes origin cache and edge node cache. Before performing a cache query, the system first parses the corresponding container format (fMP4 / TS) and playback mode (live / time-shift) from the video stream acquisition request. Based on this, it matches a dedicated multi-level cache instance and then performs a storage location query in the group of caches in the order of origin cache and edge node cache until the target storage location is determined.

[0067] This implementation partitions the cache according to the encapsulation format and playback mode to avoid interference between different types of streams, improve the cache hit rate and query accuracy, and adapt to the differentiated scheduling requirements of live streaming and time-shifted streaming.

[0068] In some optional implementations of this embodiment, the target storage location of the target video stream indicated by the video stream acquisition request is determined by performing step 101 as follows: First step, determine whether the blacklist cache includes the stream identifier of the target video stream, wherein the blacklist cache includes the stream identifier of historical video streams whose query failure count based on the stream location query service exceeds a preset failure count threshold; Second step, in response to not including the stream identifier, determine the target storage location based on multi-level caching.

[0069] The stream location query service is a background service in the video stream scheduling system used to uniformly query the real storage address of the target video stream. It is the authoritative query entry point when multi-level cache misses.

[0070] In the context of live video streaming services, the system maintains a blacklist cache to record video streams that have failed to be queried multiple times by the stream location query service. The blacklist cache only stores stream identifiers that have not expired and whose failure count exceeds a preset threshold. The system directly determines whether the stream identifier of the target video stream exists in the blacklist cache. If it exists, it is determined to be a blacklist video stream; otherwise, it is determined to be a normal video stream.

[0071] If the target video stream is determined not to be in the blacklist cache, it is considered a normal video stream. The system then performs storage location lookup operations layer by layer according to the query order, based on a multi-level cache that includes source cache and edge node cache, until the target storage location of the target video stream is determined.

[0072] In the above embodiments, the blacklist cache only stores the stream identifiers of video streams that have not expired and whose failure count exceeds a preset threshold. In addition, blacklist caching can also be implemented in the following ways:

[0073] 1. The blacklist cache stores non-expired stream identifier entries. Expired entries are automatically cleaned up by the TTL (Time To Live) mechanism. After the system hits an entry, it further determines whether its failure count has reached the preset failure count threshold. If it has, it is determined to be a blacklisted video stream.

[0074] 2. The blacklist cache stores the TTL and failure count of the video stream. The system checks whether there is a valid, unexpired entry in the blacklist cache based on the stream name of the target video stream. If it exists and the failure count reaches the preset failure count threshold, it is determined to be a blacklisted video stream.

[0075] In this implementation, an abnormal video stream is filtered through a blacklist mechanism before determining the storage location of the video stream based on multi-level caching. This avoids invalid retrieval of streams that fail to be queried, reduces the overhead of the stream location query service call, and improves the system routing efficiency and operational stability.

[0076] In some optional implementations of this embodiment, before performing the first step described above to determine whether the blacklist cache includes the stream identifier of the target video stream, the following operation is also performed: determining the blacklist cache corresponding to the media feature of the video stream acquisition request.

[0077] As an example, separate and isolated blacklist cache partitions are pre-built according to different media characteristics. Upon receiving a video stream retrieval request, the media characteristic type to which the request belongs is first parsed to determine the exclusive blacklist cache corresponding to that media characteristic type.

[0078] Specifically, media characteristics include media container format and media playback mode. For media characteristics of fMP4 container and live streaming mode, a separate blacklist cache is set; for media characteristics of fMP4 container and time-shift playback mode, a separate blacklist cache is set; for media characteristics of TS container and live streaming mode, a separate blacklist cache is set; for media characteristics of TS container and time-shift playback, a separate blacklist cache is set.

[0079] This implementation matches the corresponding blacklist cache based on the media features of the video stream acquisition request, achieving blacklist partitioning and isolation, improving the accuracy and efficiency of blacklist retrieval, avoiding invalid interference from different feature streams, and ensuring a smooth query process in live and on-demand scenarios.

[0080] In some optional implementations of this embodiment, the following operation is also performed: in response to the failure to query the storage location of the video stream based on multi-level caching, the storage location of the video stream is determined using a stream location query service.

[0081] As an example, the system queries the storage location of the target video stream layer by layer in a preset order across multiple cache levels. If no matching storage location information is found in any level of cache, the multi-level cache query is considered to have failed. At this point, the system calls the stream location query service, passing the stream identifier of the target video stream as a query parameter. The service then retrieves and returns the actual storage location of the video stream from the backend data source, thereby determining the target storage location.

[0082] In this implementation, when multi-level cache queries fail, a fallback query is performed using the stream location query service to ensure that the video stream storage location can be obtained normally, avoiding query interruption and improving the reliability of system routing and business continuity.

[0083] In some optional implementations of this embodiment, the following operation is also performed: in response to the failure to query the storage location of the video stream using the stream location query service, the storage location of the video stream is determined based on the fallback cache.

[0084] The fallback cache includes the storage locations of historical video streams successfully queried based on the stream location query service. This fallback cache is a dedicated backup cache unit used to store the storage location information of historical video streams previously successfully queried through the stream location query service. It provides a final layer of query protection when multiple levels of caching and the stream location query service fail, preventing complete query interruption.

[0085] If the system fails to find the storage location of the target video stream after multi-level cache lookup, it will invoke the stream location query service. If this service still cannot find the storage location of the target video stream, it will immediately activate the fallback cache for querying. The system extracts the stream identifier of the target video stream and matches it with the corresponding historical storage location information in the fallback cache. If a valid record is found, the historical storage location is determined as the target storage location, and the query process is completed.

[0086] In this implementation, when both multi-level caching and stream location query services fail, historical storage locations are used as a fallback to prevent complete failure of video stream queries, ensuring uninterrupted business operations and improving system fault tolerance and service stability.

[0087] In some optional implementations of this embodiment, the following operation is also performed: based on the storage location determined by the stream location query service, update the target cache and fallback cache corresponding to the storage location in the multi-level cache.

[0088] As an example, after the stream location query service successfully determines the storage location of the target video stream as either the source station or an edge node, the system synchronously performs update operations on the multi-level cache and fallback cache according to the cache level corresponding to the storage location. If the query result indicates that the video stream is stored at an edge node, the system writes the stream identifier and corresponding storage location information of the video stream into the edge node cache, adding or updating the relevant entries in the edge node cache; if the result indicates that the video stream is stored at the source station, the corresponding information is updated to the source station cache. Simultaneously, the system synchronously updates the valid storage location information determined by the stream location query service to the fallback cache to ensure that the historical location information stored in the fallback cache is consistent with the actual node level, providing accurate backup data support for subsequent queries.

[0089] This implementation synchronously updates the multi-level cache and fallback cache based on the stream location query results, ensuring that the storage location of each level of cache is consistent with the actual node, improving the hit rate of subsequent queries, reducing duplicate queries, and enhancing system stability.

[0090] In some optional implementations of this embodiment, cache entries in the multi-level cache have a first lifetime, cache entries in the blacklist cache have a second lifetime longer than the first lifetime, and cache entries in the fallback cache have a third lifetime longer than the second lifetime.

[0091] The system configures a first lifetime, a second lifetime, and a third lifetime for multi-level cache, blacklist cache, and fallback cache, respectively, with the lifetimes increasing sequentially.

[0092] For multi-level caching (origin cache, edge node cache): each cache entry is managed according to its first lifetime. When an entry expires, the system automatically cleans it up or triggers a new query to ensure that the cached data can be updated in a timely manner as the video stream storage location changes.

[0093] Blacklist caching: Each cached entry has a second lifetime (greater than the first lifetime) and is automatically removed after expiration. This ensures that there is enough time to mark abnormal video streams and avoid repeated invalid queries in a short period of time, while also preventing the normal stream from being permanently locked.

[0094] For fallback caching: Each cached entry uses a third lifetime (greater than the second lifetime) to retain the historical valid storage location for a long time, and only updates it when it expires, ensuring that there is still available backup data in the event of extreme query failures.

[0095] The system monitors the lifespan of each cached entry in real time, automatically deleting or triggering a refresh upon expiration to maintain the effectiveness and rationality of caches at all levels.

[0096] The first lifetime adapts to the high-frequency changes in live stream location, allowing cached entries to expire and be refreshed quickly. This ensures that routing decisions are consistent with the actual stream location, preventing routing failures due to data lag. Simultaneously, a high cache hit rate significantly reduces the frequency of stream location query service calls, alleviating upstream query pressure and reducing routing latency. The second lifetime is longer than the first, continuously marking invalid streams that have failed multiple queries within the effective duration, intercepting duplicate invalid requests, reducing system resource consumption, and automatically clearing entries upon expiration. This balances abnormal stream filtering with automatic unblocking after normal stream recovery, improving system robustness. The third lifetime is the longest, storing historical valid location information successfully returned by the stream location query service for an extended period. When multiple levels of cache miss and upstream services fail, time out, or query fails, the fallback cache provides stable degradation services, ensuring uninterrupted routing and smooth playback for users.

[0097] This tiered lifespan setting matches the functional positioning and data timeliness requirements of each level of cache with a progressively increasing expiration strategy. Short lifespan ensures routing accuracy, medium lifespan optimizes resource utilization, and long lifespan improves system fault tolerance. In high-concurrency HLS live streaming scenarios, it accurately balances query performance, data accuracy, and service availability, achieving efficient, stable, and low-consumption intelligent routing.

[0098] In some optional implementations of this embodiment, the following operations are also performed: First, for a back-to-origin request issued by an edge node, it is determined whether the back-to-origin request includes a source identifier representing the edge node; then, in response to determining that it includes, it is determined whether the target of the back-to-origin request is the origin station; finally, in response to determining that it is, the back-to-origin request is sent to the origin station.

[0099] A origin request is a request sent by an edge node to the video stream source (origin server) in a video stream distribution architecture when its own cache fails to find the target video stream and cannot meet the requester's needs. The request aims to retrieve video stream data or related storage location information to replenish the cache or respond to the request. For example, in a live streaming scenario, if an edge node cannot find the storage location of a live video stream in its cache, it sends a request to the origin server to retrieve the storage location and basic stream data of that live video stream. In a video-on-demand scenario, if an edge node does not cache a popular video-on-demand stream, it sends a request to the origin server to retrieve the complete storage path and corresponding stream data of that video-on-demand stream for local caching and to respond to terminal requests.

[0100] As an example, the system first establishes a dedicated origin request verification and forwarding module to receive origin requests initiated by all edge nodes and perform layer-by-layer verification on the requests. When this module receives an origin request sent by an edge node, the first step is to parse the message content of the origin request, focusing on whether the request contains a source identifier that indicates the initiator is an edge node. This source identifier is a unique identifier pre-assigned to each edge node by the system (such as edge node ID, node IP + port combination), used to distinguish requests initiated by edge nodes from ordinary requesters and other nodes, ensuring the traceability of the request source.

[0101] Then, the system judges the parsing results. If it is determined that the origin request does not contain the above-mentioned source identifier, it means that the request was not initiated by the edge node and does not meet the processing conditions. The system directly rejects the origin request and terminates the subsequent process. If it is determined that the origin request contains the source identifier, it means that the request was indeed initiated by the edge node, and the next step of verification is performed.

[0102] Finally, the system further parses the target address information carried in the origin request to determine whether the target of the origin request is the origin server. That is, it verifies whether the target node identifier and storage address specified in the request completely match the system's preset origin server information (origin server IP, origin server node identifier). If the target is determined not to be the origin server, the system refuses to forward the request to avoid resource waste caused by incorrect origin requests. If the target is determined to be the origin server, the system immediately initiates a secure forwarding process, sending the origin request to the origin server according to the preset origin server access path. This ensures that the origin server can receive the request in a timely manner and return the corresponding video stream data or storage location information, allowing edge nodes to supplement cache, respond to terminal requests, and adapt to the origin request needs of edge nodes in live streaming and video-on-demand scenarios.

[0103] In this implementation, by verifying the source identifier and target node of the origin request, legitimate origin requests from edge nodes to the origin server are accurately filtered, avoiding illegal origin requests and erroneous forwarding, ensuring the security of the origin server and the efficiency of origin requests, and supporting the replenishment of edge node cache.

[0104] In some optional implementations of this embodiment, the following operation is also performed: in response to the target of the back-to-origin request being an edge node, an error message and alarm record are generated.

[0105] After verifying the source identifier of the origin request, the system confirms that the request is a legitimate origin request initiated by an edge node. Then, it enters the verification stage of the origin request target, focusing on parsing the target node information carried in the origin request (including target node identifier, node IP address, node type identifier, etc.).

[0106] The system will compare the parsed target node information with a pre-set node type database. This database explicitly stores node information and type labels for all source and edge nodes, used to quickly distinguish whether the target node is a source or an edge node. If the comparison confirms that the target node identifier and IP address of the origin request both correspond to a certain edge node in the system, the target of the origin request is determined to be an edge node, and the error handling process is triggered.

[0107] First, the system automatically generates standardized error messages. The error message clearly states that "the origin request target is incorrect. It is forbidden to initiate origin requests to edge nodes. The legitimate origin target should be the origin server." It also carries the core information of the origin request (the edge node identifier that initiated the request, the request time, and the target edge node information) to ensure that the edge node that initiated the request can clearly know the reason for the error and the direction for correction.

[0108] Subsequently, the system synchronously generates an alarm record, which records in detail the key information of this error event, including but not limited to: the edge node ID that initiated the back-to-origin request, the edge node IP, the time the back-to-origin request was initiated, the identifier and IP of the target edge node, the error type (back-to-origin target error), and the error description. At the same time, the alarm level is marked as a general alarm, which makes it easier for system operation and maintenance personnel to quickly identify and trace this type of error event.

[0109] After generating error messages and alarm records, the system will send the error messages to the edge node that initiated the back-to-origin request, informing it to stop the erroneous back-to-origin operation. At the same time, the alarm records will be stored in the system alarm log database for future reference. The system also supports operations and maintenance personnel to query and statistically analyze such errors in real time, providing data support for subsequent optimization of edge node back-to-origin configuration and reduction of erroneous back-to-origin requests, and ensuring the standardization of the entire back-to-origin process.

[0110] In this implementation, erroneous origin requests from edge nodes to other edge nodes are promptly identified. Error messages are used to correct the operation, and alarm records are used to trace the problem. This avoids wasting resources on invalid origin requests, ensures the standardization of the origin request process, and improves system operation and maintenance efficiency.

[0111] Step 102: Generate a routing response based on the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs.

[0112] The routing response is the response data generated by the system after determining the target storage location of the target video stream. It instructs the requesting end on how to obtain the target video stream. It includes information related to the target storage location and the necessary parameters required by the requesting end to obtain the video stream. It guides the requesting end to access the target storage location accurately and efficiently to complete the acquisition of the video stream.

[0113] Routing responses can include, for example, a response message containing the node address of the target storage location and the video stream index path; a response carrying video stream transmission protocol parameters (such as HTTP (Hypertext Transfer Protocol) or RTMP (Real-Time Messaging Protocol)) and JSON (JavaScript Object Notation) format of the target storage location; a redirect response used to guide the requesting end to access the target storage node, containing an access link to the target storage location; or a concise routing response containing only the node IP (Internet Protocol) of the target storage location and video stream identification information.

[0114] As an example, in a three-tier video stream distribution system architecture consisting of multiple regional center nodes, regional edge nodes, and access nodes, the system determines the target storage location of the target video stream (the target storage location is the video stream storage address of a certain level node in the three-tier architecture, specifically the storage address corresponding to any node among the access node, regional edge node, or multiple regional center nodes) by adapting to the multi-level cache (access layer cache, regional cache, and center-level cache) of the architecture, and then initiates the process of generating and sending the routing response.

[0115] First, the system extracts complete information about the target storage location, including the hierarchical identifier of the target storage node (access node / regional edge node / multi-regional center node), node IP address, video stream storage path, access port, and video stream transmission protocol parameters. According to the system's preset unified response specifications, the above information is integrated to generate a routing response, which clearly marks the hierarchical information and access priority of the target storage node. This ensures that the requesting end can clearly know the node type and access method of the target storage location, while also ensuring that the routing response has a standardized format, complete data, and can be correctly parsed by various requesting ends (playback terminals, access node forwarding ends, etc.).

[0116] Secondly, the system verifies the generated routing response to confirm that the node identifier, IP address, and storage path of the target storage location are correct, and that the transmission protocol parameters match the access capabilities of the requesting end, thus preventing the requesting end from being unable to obtain the video stream due to incorrect response information. After successful verification, the system extracts the requesting end's attribution information carried in the video stream acquisition request (such as the access node number and device identifier of the requesting end) to determine the access location of the requesting end in the three-tier architecture. It then plans the optimal routing response sending path, prioritizing the node forwarding link closest to the requesting end to reduce response transmission latency.

[0117] Finally, the system forwards the verified routing response to the requesting end corresponding to the video stream acquisition request according to the planned sending path. If the requesting end is a playback terminal directly connected to the access node, the routing response is forwarded to that terminal by the access node; if the requesting end is a regional edge node (forwarding requests from lower-level access nodes), the routing response is sent directly to that regional edge node, which then forwards it to the corresponding lower-level requesting end. After sending, the system logs the sending time, receiving node, and response content of the routing response to ensure that the routing response is delivered to the requesting end accurately and promptly. This guides the requesting end to efficiently initiate video stream acquisition operations based on the target storage location information in the response, adapting to the hierarchical scheduling and proximity access requirements of the three-level distribution architecture.

[0118] As another example, in a distributed video streaming system architecture based on cloud vendor availability zones and nearby access nodes, the system starts the routing response generation process after determining the target storage location of the target video stream through multi-level caching (availability zone level caching and nearby access scheduling caching).

[0119] First, the system extracts the core information of the target storage location, including the availability zone node IP, video stream storage path, access port and transmission protocol type. According to the system's preset response format (JSON format), the above information is integrated into a routing response to ensure that the response data is complete, formatted correctly, and can be parsed normally by the requesting end.

[0120] Secondly, the system performs basic verification on the generated routing response. After confirming that the target storage location information is correct and the transmission protocol parameters match the capabilities of the requesting end, it obtains the requesting end identifier (such as terminal device ID and access node number) carried in the video stream acquisition request to determine the access path of the requesting end. Finally, the system sends the verified routing response to the requesting end through a preset transmission channel. After sending, it records the response sending log to ensure that the requesting end can receive the routing response in a timely manner and initiate the video stream acquisition operation based on the target storage location information in the response.

[0121] Continue to refer to Figure 2 This diagram illustrates the process of determining video stream information. A user clicks on a display area of ​​a live stream in the short video display interface 201 via a requesting client, initiating a request to the server for that live stream. The server, based on a multi-level cache adapted to the video stream system architecture, determines the target storage location of the target video stream indicated by the video stream retrieval request; it generates a routing response based on the target storage location and sends it to the requesting client to which the video stream retrieval request belongs. The requesting client retrieves the target video stream based on the routing response and displays the live stream in the display interface 202.

[0122] In some optional implementations of this embodiment, step 102 above is performed in the following manner to generate and send a routing response back to the requesting end: First, a routing response is generated based on the storage location; then, the effective duration of the routing response in the requesting end is determined based on the media playback mode of the video stream acquisition request, and the effective duration is added to the routing response; finally, the routing response with the added effective duration is sent to the requesting end to which the video stream acquisition request belongs.

[0123] After generating the main content of the routing response based on the determined video stream storage location, the system parses the video stream acquisition request and extracts the corresponding media playback mode information. According to a preset playback mode and validity duration mapping rule, the system matches the validity duration of the current routing response at the requesting end and writes this validity duration into the corresponding field of the routing response message as a standard cache control parameter, completing the routing response configuration. Finally, the system sends the routing response carrying the validity duration to the corresponding requesting end according to the requesting end's address information, enabling the requesting end to manage the validity period of the routing information according to this duration.

[0124] As an example, when generating a route response, the system dynamically sets the HTTP cache header based on the request type: for live streaming requests, a moderate cache time (e.g., 10 seconds) is set to allow CDN caching to reduce the pressure on the origin server; for time-shifted requests, caching is disabled (max-age=0) to ensure that users obtain accurate historical content.

[0125] This implementation dynamically configures the effective duration of the route response based on the playback mode, taking into account the advantages of caching and reducing the burden of live streaming and the accuracy of time-shifted content, reducing duplicate requests, and improving CDN scheduling efficiency and terminal playback experience.

[0126] Figure 3 This paper illustrates another processing flow 300 of a method for determining video stream information provided in an embodiment of this application, wherein the processing flow 300 includes the following steps:

[0127] Step 301: Respond to the video stream acquisition request from the requesting end and determine the blacklist cache corresponding to the media characteristics of the video stream acquisition request.

[0128] Step 302: Determine whether the blacklist cache includes the stream identifier of the target video stream.

[0129] The blacklist cache includes the stream identifiers of historical video streams whose query failures based on the stream location query service exceed a preset failure threshold.

[0130] Step 303, in response to the absence of, determine the multi-level cache corresponding to the media characteristics of the video stream acquisition request.

[0131] Step 304: Following the query order among the multi-level caches, perform the query operation for the storage location of the target video stream in each level of cache sequentially until the target storage location is determined.

[0132] Step 305: In response to the failure to query the storage location of the video stream based on multi-level caching, the storage location of the video stream is determined using the stream location query service.

[0133] Step 306: In response to the failure to query the storage location of the video stream using the stream location query service, the storage location of the video stream is determined based on the fallback cache.

[0134] The fallback cache includes the storage location of historical video streams successfully queried based on the stream location query service.

[0135] Step 307: Update the target cache and fallback cache corresponding to the storage location in the multi-level cache according to the storage location determined by the stream location query service.

[0136] Step 308: Generate a routing response based on the storage location.

[0137] Step 309: Determine the valid duration of the routing response on the requesting end based on the media playback mode of the video stream acquisition request, and add the valid duration to the routing response.

[0138] Step 310: Send the route response with the added valid duration to the requesting end to which the video stream acquisition request belongs.

[0139] As can be seen from this embodiment, with Figure 1 Compared with the corresponding embodiments, the process 300 of the video stream information determination method in this embodiment specifically illustrates the process of determining video stream location information based on blacklist caching, multi-level caching and fallback caching, as well as the process of setting the effective duration of routing response based on media playback mode differentiation. This enriches the methods for determining storage location, avoids the system bottleneck caused by relying entirely on the location query service, and helps to improve the efficiency of determining video stream information.

[0140] Furthermore, embodiments of this application also provide a device for determining video stream information, the structure of which is as follows: Figure 4 As shown.

[0141] A video stream information determination device 400 includes: a location determination unit 401, configured to determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video stream system architecture; and a routing response unit 402, configured to generate a routing response according to the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs.

[0142] In some optional implementations of this embodiment, the multi-level cache includes a source cache and an edge node cache in sequence. The source cache includes the storage location of the video stream stored at the source, and the edge node cache includes the storage location of the video stream stored at the edge node. The location determination unit 401 is further configured to: perform a query operation for the storage location of the target video stream in each level of cache in the order of query between the multi-level caches until the target storage location is determined.

[0143] In some optional implementations of this embodiment, the above apparatus further includes: a cache determination unit (not shown in the figure), configured to determine a multi-level cache corresponding to the media features of the video stream acquisition request.

[0144] In some optional implementations of this embodiment, the media features include media encapsulation format and media playback mode, and the cache determination unit is further configured to determine the multi-level cache corresponding to the media encapsulation format and media playback mode.

[0145] In some optional implementations of this embodiment, the location determination unit 401 is further configured to: determine whether the blacklist cache includes the stream identifier of the target video stream, wherein the blacklist cache includes the stream identifier of historical video streams whose query failure count based on the stream location query service exceeds a preset failure count threshold; in response to not including the stream identifier, determine the target storage location based on multi-level caching.

[0146] In some optional implementations of this embodiment, the cache determination unit is further configured to: determine the blacklist cache corresponding to the media characteristics of the video stream acquisition request.

[0147] In some optional implementations of this embodiment, the above apparatus further includes: a location query unit (not shown in the figure), configured to: in response to failure to query the storage location of the video stream based on multi-level cache, determine the storage location of the video stream using a stream location query service.

[0148] In some optional implementations of this embodiment, the location determination unit 401 is further configured to: determine the storage location of the video stream based on a fallback cache in response to the failure to query the storage location of the video stream using the stream location query service, wherein the fallback cache includes the storage locations of historical video streams successfully queried based on the stream location query service.

[0149] In some optional implementations of this embodiment, the above apparatus further includes: a cache update unit (not shown in the figure), configured to update the target cache and fallback cache corresponding to the storage location in the multi-level cache according to the storage location determined by the stream location query service.

[0150] In some optional implementations of this embodiment, cache entries in the multi-level cache have a first lifetime, cache entries in the blacklist cache have a second lifetime longer than the first lifetime, and cache entries in the fallback cache have a third lifetime longer than the second lifetime.

[0151] In some optional implementations of this embodiment, the above apparatus further includes: a loopback prevention unit (not shown in the figure), configured to: for a loopback request issued by an edge node, determine whether the loopback request includes a source identifier representing the edge node; in response to determining that it includes, determine whether the target of the loopback request is the source station; and in response to determining that it is, send the loopback request to the source station.

[0152] In some optional implementations of this embodiment, the above-mentioned device further includes: an alarm unit (not shown in the figure), configured to: generate error messages and alarm records in response to the target of the back-to-source request being an edge node.

[0153] In some optional implementations of this embodiment, the routing response unit 402 is further configured to: generate a routing response based on the storage location; determine the valid duration of the routing response in the requesting end based on the media playback mode of the video stream acquisition request, and add the valid duration to the routing response; and send the routing response with the added valid duration to the requesting end to which the video stream acquisition request belongs.

[0154] In the video stream information determination device provided in this application embodiment, the location determination unit determines the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video stream system architecture; the routing response unit generates a routing response according to the target storage location and sends the routing response to the requesting end to which the video stream acquisition request belongs, thereby determining the storage location of the target video stream based on a multi-level cache adapted to the video stream system architecture, enriching the methods for determining the storage location, avoiding the system bottleneck caused by completely relying on the location query service, and helping to improve the efficiency of determining video stream information.

[0155] Furthermore, embodiments of this application also provide a video streaming system, the structure of which is as follows: Figure 5 As shown.

[0156] A video streaming system 500 includes a requesting end 501 and a server 502. The requesting end is used to send a video stream acquisition request to the server. The server is used to: determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video streaming system architecture; generate a routing response according to the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs; the requesting end is also used to acquire the target video stream according to the routing response.

[0157] In some optional implementations of this embodiment, the multi-level cache includes an origin cache and an edge node cache in sequence. The origin cache includes the storage location of the video stream stored at the origin, and the edge node cache includes the storage location of the video stream stored at the edge node. The server 502 is further used to: perform a query operation for the storage location of the target video stream in each level of the cache in the order of querying the multi-level cache, until the target storage location is determined.

[0158] In some optional implementations of this embodiment, the server 502 is further configured to: determine the multi-level cache corresponding to the media features of the video stream acquisition request.

[0159] In some optional implementations of this embodiment, the media features include media encapsulation format and media playback mode, and the server 502 is further used to: determine the multi-level cache corresponding to the media encapsulation format and media playback mode.

[0160] In some optional implementations of this embodiment, the server 502 is further configured to: determine whether the blacklist cache includes the stream identifier of the target video stream, wherein the blacklist cache includes the stream identifier of historical video streams whose query failure count based on the stream location query service exceeds a preset failure count threshold; in response to not including the stream identifier, determine the target storage location based on multi-level caching.

[0161] In some optional implementations of this embodiment, the server 502 is further configured to: determine the blacklist cache corresponding to the media characteristics of the video stream acquisition request.

[0162] In some optional implementations of this embodiment, the server 502 is further configured to: in response to the failure of querying the storage location of the video stream based on multi-level caching, use the stream location query service to determine the storage location of the video stream.

[0163] In some optional implementations of this embodiment, the server 502 is further configured to: in response to the failure of querying the storage location of the video stream using the stream location query service, determine the storage location of the video stream based on the fallback cache, wherein the fallback cache includes the storage locations of historical video streams successfully queried based on the stream location query service.

[0164] In some optional implementations of this embodiment, the server 502 is further configured to: update the target cache and fallback cache corresponding to the storage location in the multi-level cache according to the storage location determined by the stream location query service.

[0165] In some optional implementations of this embodiment, cache entries in the multi-level cache have a first lifetime, cache entries in the blacklist cache have a second lifetime longer than the first lifetime, and cache entries in the fallback cache have a third lifetime longer than the second lifetime.

[0166] In some optional implementations of this embodiment, the server 502 is further configured to: determine whether the origin request issued by the edge node includes a source identifier representing the edge node; in response to determining that it includes, determine whether the target of the origin request is the origin station; and in response to determining that it is, send the origin request to the origin station.

[0167] In some optional implementations of this embodiment, the server 502 is further configured to: generate error messages and alarm records in response to the origin request being directed to an edge node.

[0168] In some optional implementations of this embodiment, the server 502 is further configured to: generate a routing response based on the storage location; determine the valid duration of the routing response in the requesting end based on the media playback mode of the video stream acquisition request, and add the valid duration to the routing response; and send the routing response with the added valid duration to the requesting end to which the video stream acquisition request belongs.

[0169] In the video streaming system provided in this application embodiment, the server is used to determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video streaming system architecture; generate a routing response based on the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs; the requesting end is used to acquire the target video stream based on the routing response, thereby determining the storage location of the target video stream based on the multi-level cache adapted to the video streaming system architecture, enriching the methods for determining the storage location, avoiding the system bottleneck caused by completely relying on the location query service, and helping to improve the efficiency of determining video stream information.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for determining video stream information, wherein, The method includes: Based on a multi-level cache adapted to the video streaming system architecture, the target storage location of the target video stream indicated by the video stream acquisition request is determined. A routing response is generated based on the target storage location, and the routing response is sent to the requesting end to which the video stream acquisition request belongs.

2. The method according to claim 1, wherein, The multi-level cache sequentially includes an origin cache and an edge node cache. The origin cache includes the storage location of the video stream stored at the origin station, and the edge node cache includes the storage location of the video stream stored at the edge node. The method of determining the target storage location of the target video stream indicated by the video stream acquisition request, based on a multi-level cache adapted to the video stream system architecture, includes: According to the query order among the multi-level caches, the storage location query operation for the target video stream is performed sequentially in each level of cache until the target storage location is determined.

3. The method according to claim 2, wherein, Before performing the query operation for the storage location of the target video stream sequentially in each level of the cache according to the query order among the multi-level caches, until the target storage location is determined, the method further includes: Determine the multi-level cache corresponding to the media characteristics of the video stream acquisition request.

4. The method according to claim 3, wherein, The media features include media container format and media playback mode, and The multi-level cache corresponding to the media features of the video stream acquisition request includes: Determine the multi-level cache corresponding to the media encapsulation format and the media playback mode.

5. The method according to any one of claims 1-4, wherein, The method of determining the target storage location of the target video stream indicated by the video stream acquisition request, based on a multi-level cache adapted to the video stream system architecture, includes: Determine whether the blacklist cache includes the stream identifier of the target video stream, wherein the blacklist cache includes the stream identifier of historical video streams whose query failure count based on the stream location query service exceeds a preset failure count threshold; In response to the exclusion, the target storage location is determined based on the multi-level cache.

6. The method according to claim 5, wherein, Before determining whether the blacklist cache includes the stream identifier of the target video stream, the method further includes: Determine the blacklist cache corresponding to the media characteristics of the video stream acquisition request.

7. The method according to claim 1, wherein, Also includes: In response to the failure to query the storage location of the video stream based on the multi-level cache, the storage location of the video stream is determined using the stream location query service.

8. The method according to claim 7, wherein, Also includes: In response to the failure to query the storage location of the video stream using the stream location query service, the storage location of the video stream is determined based on a fallback cache, wherein the fallback cache includes the storage locations of historical video streams that were successfully queried based on the stream location query service.

9. The method according to claim 8, wherein, Also includes: Based on the storage location determined by the stream location query service, update the target cache and the fallback cache corresponding to the storage location in the multi-level cache.

10. The method according to claim 8, wherein, The cache entries in the multi-level cache have a first lifetime, the cache entries in the blacklist cache have a second lifetime longer than the first lifetime, and the cache entries in the fallback cache have a third lifetime longer than the second lifetime.

11. The method according to claim 1, wherein, Also includes: For a homing request issued by an edge node, determine whether the homing request includes a source identifier that represents the edge node; In response to the determination, it is determined whether the target of the back-to-origin request is the origin server; In response to confirmation, the origin request is sent to the origin server.

12. The method according to claim 11, wherein, Also includes: In response to the origin request being directed to an edge node, an error message and alarm record are generated.

13. The method according to claim 1, wherein, The step of generating a routing response based on the target storage location and sending the routing response to the requesting client to which the video stream acquisition request belongs includes: Generate a routing response based on the storage location; Based on the media playback mode of the video stream acquisition request, determine the effective duration of the routing response at the requesting end, and add the effective duration to the routing response; The routing response with the added effective duration will be sent to the requesting end to which the video stream retrieval request belongs.

14. A device for determining video stream information, wherein, The device includes: The location determination unit is configured to determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video stream system architecture. The routing response unit is configured to generate a routing response based on the target storage location and send the routing response to the requesting end to which the video stream acquisition request belongs.

15. A video streaming system, comprising a requesting end and a server, wherein: The requesting end is used to send a video stream acquisition request to the server; The server is used to: determine the target storage location of the target video stream indicated by the video stream acquisition request based on a multi-level cache adapted to the video stream system architecture; A routing response is generated based on the target storage location, and the routing response is sent to the requesting client to which the video stream acquisition request belongs; The requesting end is also used to obtain the target video stream based on the routing response.

16. An electronic device, the electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 13.

17. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as claimed in any one of claims 1 to 13.

18. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 13.

Images