Recovery method and device of pushed video, electronic equipment and storage medium

Abstract

The invention provides a pushed video recycling method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a recommended log data stream and displayed data streams sent by a plurality of terminals, and obtaining second undisplayed data detected by the plurality of terminals; determining first undisplayed data according to the recommended log data stream and the displayed data stream; intersection data of the first undisplayed data and the second undisplayed data is determined, and the intersection data comprises a video pushing batch and a user id; if the intersection data exists in a recommendation history library, the intersection data is deleted from the recommendation history library, so that the videos in the pushing batch are pushed to the user corresponding to the user id again, the videos in the recommendation history library are not recommended to the corresponding user any more, and waste of video resources is avoided.

Description

Technical Field

[0001] The present application relates to the field of video push technology, and in particular to a method, device, electronic device and storage medium for recovering pushed videos. Background Art

[0002] Currently, videos are pushed based on user preferences. Generally speaking, in order to ensure user experience, the number of videos pushed at one time is greater than the number displayed on the terminal screen. This results in the videos that the user has not seen actually being recorded in the recommendation history database. When the user visits next time, the data in the recommendation history database will no longer be pushed to the user. This results in the videos that have been pushed to the user but have not been watched by the user being filtered out, resulting in a waste of video resources. Summary of the invention

[0003] In order to solve the above technical problems or at least partially solve the above technical problems, the present application provides a method, device, electronic device and storage medium for recycling pushed videos.

[0004] In a first aspect, the present application provides a method for recovering a pushed video, the method comprising:

[0005] Acquire a recommended log data stream and displayed data streams sent by multiple terminals, and acquire second non-displayed data detected by the multiple terminals;

[0006] determining first non-displayed data according to the recommended log data stream and the displayed data stream;

[0007] Determine intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes a push batch of the video and a user ID;

[0008] If the intersection data exists in the recommendation history library, the intersection data is deleted from the recommendation history library to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

[0009] Optionally, determining the first non-displayed data according to the recommended log data stream and the displayed data stream includes:

[0010] Determine a target data record in the displayed data stream, wherein the target data record includes a target push batch, a target user ID, and a displayed video ID;

[0011] Searching the push video id corresponding to the target push batch and the target user id in the recommendation log data stream;

[0012] The video IDs other than the displayed video ID in the pushed video IDs are used as undisplayed video IDs;

[0013] taking the target push batch, the target user ID and the undisplayed video ID as a data record in the first undisplayed data;

[0014] All data records in the displayed data stream are traversed, and a plurality of data records in the first undisplayed data are generated.

[0015] Optionally, acquiring the second non-displayed data detected by the multiple terminals includes:

[0016] Get the http message sent by each terminal;

[0017] Parsing the http message to obtain a parsing record, wherein each parsing record includes a push batch of the video, a user ID, and a scene identifier;

[0018] If it is determined according to the scene identifier that the video in the parsing record is allowed to be recycled, the parsing record is written into a queue.

[0019] Optionally, before determining the intersection data of the first non-displayed data and the second non-displayed data, the method further includes:

[0020] Determine the final time when the first non-displayed data generates a data record for the last time, wherein the first non-displayed data generates a data record every set time period;

[0021] Determining the length of time between the final moment and the current system moment;

[0022] If the interval duration does not exceed the duration threshold, it is determined that there is no abnormality in the data flows of the recommended log data flow and the displayed data flow.

[0023] Optionally, after determining the interval between the final moment and the current system moment, the method further includes:

[0024] If the interval duration exceeds the duration threshold, it is determined that the data flow of at least one of the recommended log data flow and the displayed data flow is abnormal, and the video recycling process is interrupted.

[0025] Optionally, writing the parsed record into a queue comprises:

[0026] The parsed record is written into a delay queue, wherein a delay duration in the delay queue is greater than a delay duration of the recommended log data stream and the first non-displayed data stream.

[0027] Optionally, after acquiring the displayed data streams sent by multiple terminals, the method further includes:

[0028] If the video id is missing in at least one data record of the displayed data stream, it is determined that the data record is lost and the video recovery process is interrupted.

[0029] In a second aspect, the present application provides a device for recovering pushed videos, the device comprising:

[0030] an acquisition module, configured to acquire a recommended log data stream and displayed data streams sent by a plurality of terminals, and acquire second non-displayed data detected by the plurality of terminals;

[0031] A first determining module, configured to determine first non-displayed data according to the recommended log data stream and the displayed data stream;

[0032] A second determination module, configured to determine intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes a push batch of videos and a user ID;

[0033] A push module is used to delete the intersection data from the recommendation history library if the intersection data exists in the recommendation history library, so as to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

[0034] In a third aspect, an electronic device is provided, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0035] Memory, used to store computer programs;

[0036] The processor is used to implement any of the steps of the method for recovering pushed videos when executing a program stored in the memory.

[0037] In a fourth aspect, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, any of the steps of the method for recycling pushed videos is implemented.

[0038] The above technical solution provided by the embodiment of the present application has the following advantages compared with the prior art:

[0039] The method provided in the embodiment of the present application, on the one hand, determines the undisplayed data in the real-time data stream through the recommendation log data stream and the displayed data stream, and on the other hand, obtains the undisplayed data detected by the terminal, and takes the intersection of the two undisplayed data to ensure that the video data that has been pushed to the user and has not been viewed by the user is accurate. Finally, the intersection data in the recommendation history library is deleted, so that the recommended video that the user has not seen is pushed back to the user. The present application realizes accurate video data recovery through the fusion of three-party data to avoid waste of video resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0042] Figure 1 A schematic diagram of the hardware environment of a method for recycling pushed videos provided in an embodiment of the present application;

[0043] Figure 2 A flowchart of a method for recycling pushed videos provided in an embodiment of the present application;

[0044] Figure 3 A schematic diagram of a system flow for pushing video recovery provided in an embodiment of the present application;

[0045] Figure 4 A schematic diagram of the structure of a push video recovery device provided in an embodiment of the present application;

[0046] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0048] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0049] In order to solve the problems mentioned in the background technology, according to one aspect of the embodiments of the present application, an embodiment of a method for recycling pushed videos is provided.

[0050] Optionally, in the embodiment of the present application, the above-mentioned method for recovering pushed videos can be applied to: Figure 1 In the hardware environment composed of the terminal 101 and the server 103 shown in FIG. Figure 1 As shown, the server 103 is connected to the terminal 101 via a network, and can be used to provide services for the terminal or a client installed on the terminal. A database 105 can be set on the server or independently of the server to provide data storage services for the server 103. The above-mentioned network includes but is not limited to: a wide area network, a metropolitan area network or a local area network, and the terminal 101 includes but is not limited to a PC, a mobile phone, a tablet computer, etc.

[0051] The embodiment of the present application provides a method for recycling pushed videos, which can be applied to a server to avoid wasting video resources.

[0052] The following will be combined with a specific implementation method to describe in detail a method for recovering a pushed video provided by an embodiment of the present application. Figure 2 As shown, the specific steps are as follows:

[0053] Step 201: obtaining a recommended log data stream and displayed data streams sent by multiple terminals, and obtaining second non-displayed data detected by multiple terminals;

[0054] Step 202: determining first non-displayed data according to the recommended log data stream and the displayed data stream;

[0055] Step 203: determining intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes a push batch of the video and a user ID;

[0056] Step 204: If the intersection data exists in the recommendation history library, the intersection data is deleted from the recommendation history library to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

[0057] The backend server will recommend videos to users based on their preferences, including but not limited to long videos, popular videos, short videos, etc. The service desk will generate a recommendation log data stream when pushing videos. The recommendation log data stream includes a log of each recommendation, and a single log includes a batch of videos pushed to multiple users.

[0058] The video pushed to the terminal by the background is often larger than the video that can be displayed on the terminal interface, so the video that the user can see on the terminal is only part of the video, which results in the other part of the video being pushed to the user but not being seen by the user, resulting in a waste of video resources. The terminal will split the pushed video by itself, and the video that the user can see is classified as the displayed video stream, and the video that the user cannot see is classified as the undisplayed video data.

[0059] Both the recommended log data stream and the displayed data stream belong to the real-time data stream of the background. Generally speaking, the background can filter out the displayed data stream from the recommended log data stream, and the remaining is the video data that the user has not seen (the first non-displayed data). However, in the process of data transmission from the terminal to the server, it may be affected by unstable factors such as network fluctuations and signal interference. There is a risk of data loss in the data stream. The first non-displayed data obtained in this way is not accurate enough.

[0060] The terminal automatically diverts the video to obtain the second undisplayed data. The second undisplayed data is detected by the terminal and the result is relatively reliable. If the video in the second undisplayed data is simply resent to the user, the video return path will also have the risk of loss, resulting in inaccurate recovery.

[0061] Based on the fact that both the real-time data stream in the background and the undisplayed data stream detected by the terminal are at risk of loss, this application will take the intersection of the first undisplayed data obtained based on the real-time data stream and the second undisplayed data detected by the terminal, and the obtained intersection data includes the video push batch evid and the user id. In the embodiment of the present application, it is assumed that each user id corresponds to a terminal id. Generally speaking, a batch of pushed videos have the same push batch. If the video is lost, all the videos in the push batch are lost, and the situation of partial video loss in the same push batch will not occur. Therefore, when taking the intersection of the first undisplayed data and the second undisplayed data, it is only necessary to take the intersection based on the push batch and the user id. The intersection data obtained in this way exists in both the real-time data stream and the terminal, so the intersection data is accurate.

[0062] The recommendation history library includes multiple pushed videos. Then the videos in the recommendation history library will no longer be recommended to the corresponding users. In order to be able to push videos that have been pushed to users but have not been watched by users again, these videos need to be deleted from the recommendation history library. Therefore, the server determines whether the intersection data obtained above exists in the recommendation history library. If so, the intersection data will be deleted from the recommendation history library, so that the videos in the push batch will be pushed again to the user corresponding to the user id, thereby realizing the recovery of the pushed videos; if not, return to step 201.

[0063] Since both the first undisplayed data and the second undisplayed data may be affected by unstable factors, there may be risks in directly using either data for video recovery. By taking the intersection of the two types of data, it can be ensured that the obtained intersection data exists in both the real-time data stream and the terminal detection, thereby reducing the risk caused by data loss or errors. The data after taking the intersection is more accurate because it has been double-verified. On the one hand, it exists in the real-time data stream in the background, indicating that these videos have indeed been pushed; on the other hand, it also exists in the undisplayed data detected by the terminal, indicating that these videos are not watched by the user. This double verification mechanism greatly reduces the possibility of data loss or errors.

[0064] In this application, on the one hand, the undisplayed data in the real-time data stream is determined by recommending the log data stream and the displayed data stream, and on the other hand, the undisplayed data detected by the terminal is obtained. By taking the intersection of the two undisplayed data, it is ensured that the video data that has been pushed to the user and has not been viewed by the user is accurate. Finally, the intersection data in the recommendation history library is deleted, so that the recommended video that the user has not seen is pushed back to the user. This application realizes accurate video data recovery through the fusion of three-party data to avoid waste of video resources.

[0065] In step 202, determining the first non-displayed data according to the recommendation log data stream and the displayed data stream includes the following contents: determining a target data record in the displayed data stream, wherein the target data record includes a target push batch, a target user ID, and a displayed video ID; searching for a push video ID corresponding to the target push batch and the target user ID in the recommendation log data stream; using video IDs other than the displayed video IDs in the push video IDs as non-displayed video IDs; using the target push batch, the target user ID, and the non-displayed video ID as a data record in the first non-displayed data; traversing all data records in the displayed data stream, and generating multiple data records in the first non-displayed data.

[0066] Both the recommended log data stream and the displayed data stream include multiple data records, and the content of each data record includes: push batch, user id and at least one video id. The difference is that the recommended log data stream contains the pushed video id, while the displayed data stream contains the displayed video id. That is, the data records of the recommended log data stream include: push batch, user id and push video id, and the data records of the displayed data stream include: push batch, user id and displayed video id.

[0067] The server traverses each data record in the displayed data stream. Specifically, any data record is taken as the target data record, and the content of the target data record includes: target push batch, target user ID and displayed video ID. Then, the server searches for the push video ID that matches the target push batch and target user ID in the recommendation log data stream. The purpose of this step is to find all the videos that the user may have watched in this batch push. The server excludes those video IDs that have been watched by the user (i.e., displayed video IDs) from the acquired push video IDs, so that it can identify which videos have not been watched by the user, i.e., undisplayed video IDs. For each combination of target push batch, target user ID and undisplayed video ID, they are added as a new data record to the first undisplayed data. Finally, the entire displayed data stream is traversed and the above process is repeated to generate corresponding undisplayed video IDs for each target push batch and target user ID. In this way, a comprehensive data set that reflects the situation of videos that users have not watched can be obtained.

[0068] By traversing the displayed data stream and combining it with the recommended log data stream, the server can accurately identify which videos the user has not watched yet, ensuring the integrity and accuracy of the dataset, because each combination of the target push batch and the target user ID is considered in detail, thus avoiding missing any potential unwatched videos. Through this series of steps, the video data that has been pushed to the user but not watched by the user can be determined based on the real-time data stream.

[0069] In step 203, obtaining the second undisplayed data detected by multiple terminals includes the following contents: obtaining an http message sent by each terminal; parsing the http message to obtain a parsing record, wherein each parsing record includes a push batch of the video, a user id, and a scene identifier; if it is determined according to the scene identifier that the video in the parsing record is allowed to be recycled, then writing the parsing record into a queue.

[0070] When the terminal detects video data that is not displayed on the interface, it sends an HTTP message to the server. After receiving the HTTP message, the server parses it and extracts a parsing record suitable for the terminal. This parsing record contains the video push batch, user ID and scene ID.

[0071] The scene identifier is an important piece of information that indicates whether the video content supports recycling. If the video content does not support recycling, such as unpopular videos or videos whose display period has expired, the server will discard this parsing record when processing the second non-displayed data. This can avoid generating intersection data related to these video contents that do not support recycling in subsequent calculations, thereby reducing unnecessary calculations.

[0072] However, if the video content is determined to support recycling based on the scene identifier, the server will write this parsing record into a queue, which is a temporary storage area for storing parsing records to be processed. The server will then take this parsing record out of the queue and compare it with the first undisplayed data in the real-time data stream to take their intersection. In this way, it can be determined whether the parsing record exists in both the second undisplayed data detected by the terminal and the first undisplayed data in the real-time data stream.

[0073] This processing method ensures that only video content that supports recycling is taken into consideration, thereby improving the processing efficiency and accuracy of the system. At the same time, it also avoids mistakenly including video content that does not support recycling in the recommendation range, ensuring the quality of user experience.

[0074] The queue in the embodiment of the present application can be a Kafka queue or a queue provided by Pulsar. The present application does not limit the type of message queue.

[0075] Video recycling refers to the process of returning videos that were previously pushed to users but not watched to the recommendation pool so that they can be recommended to users again in the future. Whether a video is allowed to be recycled depends on a variety of factors, including the popularity of the video, the user's viewing history, and the freshness of the video. The following are some factors that may affect the decision to recycle a video:

[0076] Popularity of the video: Popular videos generally have a higher probability of being viewed, so even if the user has not watched them before, these videos may be allowed to be recycled in order to capture the chance that the user may have changed their interests.

[0077] User viewing history: If a user shows a sustained interest in a certain type of content, then those videos may be allowed to be recycled even if they have not previously watched them. Conversely, if a user clearly indicates a lack of interest in certain types of content, then those videos may not be recycled.

[0078] Freshness of the video: Newly released videos may be given higher priority because they are more likely to be content that users are interested in. Therefore, even popular videos may not be allowed to be recycled if they have been around for a while to make room for new content.

[0079] User feedback: Direct user feedback (such as likes, comments, and shares) can be used as an important basis for whether to allow video recycling. If users have positive interactions with a video, even if they have not watched it before, the video may be allowed to be recycled.

[0080] Recommendation strategy: Different recommendation systems may have different recommendation strategies. Some systems may be more inclined to recommend new content, while others may pay more attention to personalization and user's historical preferences.

[0081] Business considerations: Sometimes business objectives also influence the decision to recycle a video. For example, if a video is relevant to an upcoming advertising campaign, it may be allowed to be recycled to increase exposure even if it is not a popular video.

[0082] As an optional implementation, before determining the intersection data of the first undisplayed data and the second undisplayed data, the method also includes: determining the final moment when the first undisplayed data generated a data record for the last time, wherein the first undisplayed data generates a data record every set time period; determining the interval duration between the final moment and the current system moment; if the interval duration does not exceed the duration threshold, determining that there is no abnormality in the data flows of the recommended log data stream and the displayed data stream.

[0083] Before the server performs an intersection operation on the first undisplayed data and the second undisplayed data, it needs to go through a process called mark verification to ensure the normal operation of the data stream, which is crucial to ensuring the accuracy of the video recycling process.

[0084] The specific steps of Mark verification are as follows:

[0085] 1. Regular search: The server will regularly search for data content in the displayed data stream in the recommended log data stream. Whenever a matching data is found, a new data record will be generated in the first undisplayed data.

[0086] 2. Obtaining the second undisplayed data: After the server obtains the second undisplayed data from the queue, it determines the current system time and finds out the time point when the first undisplayed data last generated a data record.

[0087] 3. Calculate the interval time: Then, the server calculates the interval time between the current system time and the time point when the first undisplayed data last generated a data record.

[0088] 4. Determine the interval duration: If the interval duration does not exceed the preset duration threshold, the data flow can be considered normal, and the operation of taking the intersection between the two undisplayed data is performed normally; conversely, if it exceeds the duration threshold, it indicates that the data flow is abnormal. In order to avoid incorrect recycling behavior, the server will interrupt the entire video recycling process.

[0089] For example, suppose there is a video recommendation system that continuously pushes new videos to users. To ensure user experience, the system records which videos have been pushed (recommendation log data stream). At the same time, the system obtains the displayed data stream sent by the terminal and the second undisplayed data detected. The system periodically searches for the displayed data stream in the recommendation log data stream, and generates a data record in the first undisplayed data for each data found.

[0090] In this scenario, the server may check the displayed data stream regularly, for example, every 30 seconds. If 10 videos are marked as displayed in the last half minute, the information of these 10 videos will be added to the first undisplayed data as new undisplayed records. The server will then compare these new records with the video IDs in the second undisplayed data to find the set of video IDs that exist in both the first undisplayed data and the second undisplayed data. This set is the list of videos that may be suitable for recycling.

[0091] However, before this process is carried out, the server must confirm the status of the data stream through mark verification. Assume that the duration threshold is set to 31 seconds, that is, the server expects to find new displayed video records in the displayed data stream at least every 31 seconds. If the interval between two consecutive mark checks exceeds 31 seconds, the server will consider that the data stream is abnormal, which may be due to data transmission problems caused by network delays, system failures, or other reasons. In this case, the server will not perform any video recovery operations, but will first solve the problem of the data stream to ensure the integrity and accuracy of the data.

[0092] As an optional implementation, writing the parsing record into a queue includes: writing the parsing record into a delay queue, wherein a delay duration in the delay queue is greater than a delay duration of the recommended log data stream and the first non-displayed data stream.

[0093] In the video recycling process, when the server parses a resolution record suitable for the terminal, this record will be written into a special queue, namely the delay queue. The characteristic of the delay queue is that it will not process these records immediately, but will wait for a preset period of time (i.e., the delay duration) before processing. It is important that this delay duration needs to be greater than the delay duration between the recommended log data stream and the first undisplayed data stream.

[0094] The delay between the recommended log data stream and the first undisplayed data stream is mainly due to the following reasons:

[0095] Data processing and transmission time: It takes a certain amount of time from when a user watches a video to when the information is recorded in the recommended log data stream, and from when these log data are processed and the first undisplayed data is generated. This includes multiple links such as data collection, transmission, storage, and processing. Each link may introduce a certain amount of delay.

[0096] System load and performance: In the case of high concurrency, the system load will increase, which may cause data processing to slow down, thereby increasing the delay time. In addition, if the system performance is insufficient, it may also lead to reduced efficiency in data processing and transmission.

[0097] Network conditions: Network latency is also an important reason for the delay between the recommended log data stream and the first undisplayed data stream. During data transmission, it may be affected by factors such as network congestion and packet loss, resulting in data not being able to reach the server in time.

[0098] In order to ensure the accuracy and effectiveness of the video recycling process, it is necessary to write the parsing records into the delay queue and set a sufficiently long delay time. In this way, even if there is a delay between the recommended log data stream and the first undisplayed data stream, it can be ensured that when processing these records, the relevant data has all arrived at the server and has been processed correctly. This design can improve the fault tolerance and stability of the system and reduce erroneous operations caused by inconsistent or missing data.

[0099] As an optional implementation, after acquiring the displayed data streams sent by multiple terminals, the method further includes: if at least one data record of the displayed data stream lacks a video id, determining that the data record is lost and interrupting the video recovery process.

[0100] In the video recovery process, the server collects displayed data streams from multiple terminals. These data streams are crucial to determine which videos have been watched by users because they directly affect the accuracy and efficiency of video recovery. After the server obtains these displayed data streams, it will conduct a comprehensive analysis and processing of these data streams. In this process, if it is found that at least one displayed data record lacks key video ID information, the server will make an important decision - determine that this data record is lost and interrupt the entire video recovery process.

[0101] This processing method has many effects. First, it can ensure the accuracy and reliability of the video recycling process. Video ID is a unique identifier for identifying a video. If the video ID is missing in the data record, the server cannot accurately determine whether the video has been watched by the user, and cannot determine whether the video is suitable for recycling. In this case, continuing the video recycling process may lead to erroneous operations, such as recommending videos that have already been watched to users again, thereby reducing the user experience. Therefore, by interrupting the video recycling process, the server can avoid this potential erroneous operation and protect the user experience.

[0102] Secondly, this processing method can also help to promptly discover and solve problems in the system. If the lack of video IDs in the data records is caused by system failure, network problems or other reasons, then interrupting the video recovery process can prompt relevant personnel to investigate and solve the problem as soon as possible and restore the normal operation of the system. This helps to maintain the stability and reliability of the system and ensure that the subsequent video recovery process can proceed smoothly.

[0103] In summary, when the server obtains the displayed data streams sent by multiple terminals, if it is found that at least one data record lacks a video id, then determining that the data record is lost and interrupting the video recovery process is an effective processing method. It can ensure the accuracy and reliability of the video recovery process, and at the same time promptly discover and solve problems in the system, ensuring user experience and stable operation of the system.

[0104] In summary, when the server obtains the displayed data streams sent by multiple terminals, if it is found that there is no data record in the displayed data stream, it is an effective way to determine that the displayed data is lost and interrupt the video recovery process. It can ensure the accuracy and reliability of the video recovery process, and at the same time timely discover and solve problems in the system, ensuring user experience and stable operation of the system.

[0105] Figure 3 A schematic diagram of the system flow of push video recovery provided by this application. It includes the following steps:

[0106] Step S1: When the system pushes videos to multiple users, it generates a recommendation log data stream. Each data record in the recommendation log data stream includes: push batch evid, user id and push video id ( Figure 3 The feed in it represents the video id, that is, feed1 and feed2 represent video id1 and video id2 respectively, and so on). The system writes the recommended log data stream into the show_data database and saves it.

[0107] Step S2: The client distinguishes the displayed data stream and the second non-displayed data according to the received video data and the video data displayed on the interface. Each data record of the displayed data stream includes: a push batch, a user ID and a displayed video ID, and each data record of the second non-displayed data includes: a push batch and a user ID.

[0108] Step S3: The displayed data stream is written to and updates the show_data database. The update logic is: the displayed video queries the batch number evid and user id of a batch of recommendation results from the database, sets the display status of the batch data (data record) to true, and puts the videos of the same batch that have not been displayed into a recyclable list for online service reading. The above process is repeated for each displayed video received.

[0109] The specific process is: search the recommended log data stream for the pushed video ID that matches the target push batch and target user ID in the displayed data stream, exclude those video IDs that have been watched by users (i.e., displayed video IDs) from the acquired pushed video IDs, so that it is possible to identify which videos have not been watched by users, i.e., undisplayed video IDs, and obtain a data record in the first undisplayed data: target push batch, target user ID, and undisplayed video ID. Traverse each data record in the displayed data stream to obtain multiple data records in the first undisplayed data.

[0110] Step S4: The client sends an http message to the server based on the second undisplayed data. The server parses the video push batch and user ID, and then performs basic verification. The basic verification refers to verifying whether the video content supports recycling based on the scene identifier. If it supports recycling, the subsequent steps are executed. If it does not support recycling, the parsing record is discarded.

[0111] Step S5: The parsed second undisplayed data is saved in a delay queue, and then the data is consumed.

[0112] Step S6: Determine whether the data stream is running normally through mark verification. If the data stream is abnormal, interrupt the video reflow; if the data stream is normal, continue to perform the following steps.

[0113] Step S7: The intersection data of the first undisplayed data and the second undisplayed data is obtained according to the push batch and the target user ID.

[0114] Step S8: msg_list determines whether the intersection data exists in the recommendation history library. If so, execute step S9; if not, execute step S10.

[0115] Step S9: If the intersection data exists in the recommendation history library, the recommendation history library is updated, that is, the intersection data is deleted from the recommendation history library.

[0116] Step S10: combining with the recommendation history library, re-pushing the videos that have been pushed to the user but not watched by the user to the user.

[0117] This application avoids filtering out videos that the user may like without being displayed by re-pushing videos that have been pushed to the user but not watched by the user, thereby improving the user experience and avoiding waste of video resources.

[0118] The most stringent verification mechanism is implemented during the recycling process, and recycling can be abandoned if the verification fails. This mechanism can effectively control risks and avoid online service problems caused by data errors. At the same time, since there is a certain redundancy and complementarity between the three copies of data, even if there is a problem with one of the data, it can be verified and corrected through the other two copies of data, reducing the risk of data loss.

[0119] Based on the same technical concept, the embodiment of the present application also provides a device for recycling pushed videos, such as Figure 4 As shown, the device comprises:

[0120] The acquisition module 401 is used to acquire the recommended log data stream and the displayed data stream sent by multiple terminals, and acquire the second non-displayed data detected by the multiple terminals;

[0121] A first determination module 402, configured to determine first non-displayed data according to the recommended log data stream and the displayed data stream;

[0122] A second determination module 403 is used to determine intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes a push batch of the video and a user ID;

[0123] The push module 404 is used to delete the intersection data from the recommendation history library if the intersection data exists in the recommendation history library, so as to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

[0124] Optionally, the first determining module 402 is used to:

[0125] Determine a target data record in the displayed data stream, wherein the target data record includes a target push batch, a target user ID, and a displayed video ID;

[0126] Find the push video ID corresponding to the target push batch and target user ID in the recommendation log data stream;

[0127] The video IDs other than the displayed video IDs in the pushed video IDs are regarded as the undisplayed video IDs;

[0128] According to the target push batch, the target user ID and the undisplayed video ID, a data record is taken in the first undisplayed data;

[0129] All data records in the displayed data stream are traversed, and multiple data records in the first undisplayed data are generated.

[0130] Optionally, the acquisition module 401 is used to:

[0131] Get the http message sent by each terminal;

[0132] Parse the http message to obtain a parsing record, wherein each parsing record includes the push batch of the video, the user ID and the scene ID;

[0133] If it is determined according to the scene identifier that the video in the parsing record is allowed to be recycled, the parsing record is written into the queue.

[0134] Optionally, the device is also used for:

[0135] Determine the final time when the first undisplayed data generates a data record for the last time, wherein the first undisplayed data generates a data record every set time period;

[0136] Determine the length of time between the final time and the current system time;

[0137] If the interval duration does not exceed the duration threshold, it is determined that there is no abnormality in the data flows of the recommended log data flow and the displayed data flow.

[0138] Optionally, the device is also used for:

[0139] If the interval duration exceeds the duration threshold, it is determined that at least one of the recommended log data stream and the displayed data stream is abnormal, and the video recycling process is interrupted.

[0140] Optionally, the acquisition module 401 is used to:

[0141] The parsing record is written into a delay queue, wherein the delay duration in the delay queue is greater than the delay durations of the recommended log data stream and the first non-displayed data stream.

[0142] Optionally, the device is also used for:

[0143] If the video id is missing in at least one data record of the displayed data stream, it is determined that the data record is lost and the video recovery process is interrupted.

[0144] Based on the same technical concept, an embodiment of the present invention further provides an electronic device, such as Figure 5As shown, it includes a processor 501, a communication interface 502, a memory 503 and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0145] Memory 503, used for storing computer programs;

[0146] The processor 501 is used to implement the above steps when executing the program stored in the memory 503.

[0147] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0148] The communication interface is used for communication between the above electronic device and other devices.

[0149] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0150] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0151] In another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods are implemented, including the following contents.

[0152] Acquire a recommended log data stream and displayed data streams sent by multiple terminals, and acquire second non-displayed data detected by the multiple terminals;

[0153] Determine the first undisplayed data according to the recommendation log data stream and the displayed data stream; determine the intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes the push batch and user ID of the video;

[0154] If the intersection data exists in the recommendation history library, the intersection data is deleted from the recommendation history library to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

[0155] Optionally, determining the first non-displayed data according to the recommended log data stream and the displayed data stream includes:

[0156] Determine a target data record in the displayed data stream, wherein the target data record includes a target push batch, a target user ID, and a displayed video ID;

[0157] Find the push video ID corresponding to the target push batch and target user ID in the recommendation log data stream;

[0158] The video IDs other than the displayed video IDs in the pushed video IDs are regarded as the undisplayed video IDs;

[0159] According to the target push batch, the target user ID and the undisplayed video ID, a data record is taken in the first undisplayed data;

[0160] All data records in the displayed data stream are traversed, and multiple data records in the first undisplayed data are generated.

[0161] Optionally, acquiring the second non-displayed data detected by the multiple terminals includes:

[0162] Get the http message sent by each terminal;

[0163] Parse the http message to obtain a parsing record, wherein each parsing record includes the push batch of the video, the user ID and the scene ID;

[0164] If it is determined according to the scene identifier that the video in the parsing record is allowed to be recycled, the parsing record is written into the queue.

[0165] Optionally, before determining the intersection data of the first non-displayed data and the second non-displayed data, the method further includes:

[0166] Determine the final time when the first undisplayed data generates a data record for the last time, wherein the first undisplayed data generates a data record every set time period;

[0167] Determine the length of time between the final time and the current system time;

[0168] If the interval duration does not exceed the duration threshold, it is determined that there is no abnormality in the data flows of the recommended log data flow and the displayed data flow.

[0169] Optionally, after determining the interval between the final moment and the current system moment, the method further includes:

[0170] If the interval duration exceeds the duration threshold, it is determined that at least one of the recommended log data stream and the displayed data stream is abnormal, and the video recycling process is interrupted.

[0171] Optionally, writing the parsed record to the queue includes:

[0172] The parsing record is written into a delay queue, wherein the delay duration in the delay queue is greater than the delay durations of the recommended log data stream and the first non-displayed data stream.

[0173] Optionally, after acquiring the displayed data streams sent by multiple terminals, the method further includes:

[0174] If the video id is missing in at least one data record of the displayed data stream, it is determined that the data record is lost and the video recovery process is interrupted.

[0175] In another embodiment of the present invention, a computer program product including instructions is provided, which enables the computer to execute any one of the methods in the above embodiments when the computer program product is executed on the computer.

[0176] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0177] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0178] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for recovering pushed videos, characterized in that: The method comprises: Acquire a recommended log data stream and displayed data streams sent by multiple terminals, and acquire second non-displayed data detected by the multiple terminals; determining first non-displayed data according to the recommended log data stream and the displayed data stream; Determine intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes a push batch of the video and a user ID; If the intersection data exists in the recommendation history library, the intersection data is deleted from the recommendation history library to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

2. The method according to claim 1, characterized in that: Determining the first non-displayed data according to the recommended log data stream and the displayed data stream includes: Determine a target data record in the displayed data stream, wherein the target data record includes a target push batch, a target user ID, and a displayed video ID; Searching the push video id corresponding to the target push batch and the target user id in the recommendation log data stream; The video IDs other than the displayed video ID in the pushed video IDs are used as undisplayed video IDs; taking the target push batch, the target user ID and the undisplayed video ID as a data record in the first undisplayed data; All data records in the displayed data stream are traversed, and a plurality of data records in the first undisplayed data are generated.

3. The method according to claim 1, characterized in that Acquiring the second non-displayed data detected by the plurality of terminals includes: Get the http message sent by each terminal; Parsing the http message to obtain a parsing record, wherein each parsing record includes a push batch of the video, a user ID, and a scene identifier; If it is determined according to the scene identifier that the video in the parsing record is allowed to be recycled, the parsing record is written into a queue.

4. The method according to claim 2, characterized in that: Before determining intersection data of the first non-displayed data and the second non-displayed data, the method further includes: Determine the final time when the first non-displayed data generates a data record for the last time, wherein the first non-displayed data generates a data record every set time period; Determining the length of time between the final moment and the current system moment; If the interval duration does not exceed the duration threshold, it is determined that there is no abnormality in the data flows of the recommended log data flow and the displayed data flow.

5. The method according to claim 4, characterized in that After determining the interval between the final time and the current system time, the method further includes: If the interval duration exceeds the duration threshold, it is determined that the data flow of at least one of the recommended log data flow and the displayed data flow is abnormal, and the video recycling process is interrupted.

6. The method according to claim 3, characterized in that Writing the parsed record into a queue comprises: The parsed record is written into a delay queue, wherein a delay duration in the delay queue is greater than a delay duration of the recommended log data stream and the first non-displayed data stream.

7. The method according to claim 4, characterized in that After acquiring the displayed data streams sent by the multiple terminals, the method further includes: If the video id is missing in at least one data record of the displayed data stream, it is determined that the data record is lost and the video recovery process is interrupted.

8. A device for recovering pushed videos, characterized in that: The device comprises: an acquisition module, configured to acquire a recommended log data stream and displayed data streams sent by a plurality of terminals, and acquire second non-displayed data detected by the plurality of terminals; A first determining module, configured to determine first non-displayed data according to the recommended log data stream and the displayed data stream; A second determination module, configured to determine intersection data of the first undisplayed data and the second undisplayed data, wherein the intersection data includes a push batch of videos and a user ID; A push module is used to delete the intersection data from the recommendation history library if the intersection data exists in the recommendation history library, so as to re-push the videos in the push batch to the user corresponding to the user id, wherein the videos in the recommendation history library are no longer recommended to the corresponding user.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1 to 7 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1 to 7 are implemented.

Images