Video storage method, device, system and equipment for camera and medium

Abstract

The embodiment of the invention provides a video storage method, device, system and equipment for a camera and a medium, and relates to the technical field of data transmission, the method is applied to a management engine of a streaming application system, and the method comprises the following steps: in response to a received alarm event, determining target time information based on target occurrence time of the alarm event; detecting whether a flow pulling task meeting a preset merging condition exists or not currently; if yes, time information of the pull flow task is updated based on target time information, so that the pull flow task of which the corresponding alarm event contains the alarm event is obtained; if not, generating a pull flow task corresponding to the alarm event based on the target time information; and in response to the task execution time for reaching any stream pulling task, based on the time information of the stream pulling task, performing stream extraction from the camera through the stream extraction application to obtain an event video of the alarm event corresponding to the stream pulling task. According to the invention, the event video of the alarm event can be stored to the central management equipment end.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and in particular to video recording and storage methods, apparatus, systems, devices and media for cameras. Background Technology

[0002] Cameras can capture video and images and issue alarms for certain events. To ensure the integrity and traceability of alarm events, there is a need to back up or store the recordings of alarm events. For example, the recordings of alarm events need to be stored on a central management device, such as the cloud. The recordings of alarm events can represent the content of the alarm events.

[0003] However, due to protocol limitations, some cameras are unable to actively record alarm events and therefore cannot actively store alarm recordings to the cloud, such as a central management device. In other words, these cameras are limited by the protocol and cannot actively stream recordings.

[0004] It is evident that how to store alarm event recordings to the central management device when the camera cannot actively record and stream is an urgent problem to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, system, device, and medium for storing video recordings from cameras, so as to store alarm event recordings to a central management device when the camera is unable to actively stream video. The specific technical solution is as follows:

[0006] In a first aspect, embodiments of this application provide a video recording and storage method for a camera, applied to the management engine of a streaming application system, wherein the streaming application system further includes a streaming terminal; the method includes:

[0007] In response to receiving an alarm event reported by the camera, the target time information for recording the event required for the alarm event is determined based on the target occurrence time of the alarm event;

[0008] The system detects whether there are any streaming tasks that meet predetermined merging conditions. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task used to instruct the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0009] If it exists, based on the target time information, update the time information in the task information of the existing streaming task to obtain the streaming task containing the alarm event; if it does not exist, based on the target time information, generate the streaming task corresponding to the alarm event.

[0010] In addition, in response to the task execution time in the task information of any streaming task being reached, based on the time information in the task information of the streaming task, the streaming terminal extracts the stream from the camera to obtain the event recording of the alarm event corresponding to the streaming task.

[0011] Secondly, embodiments of this application provide a video recording and storage device for a camera, and a management engine for a streaming application system, wherein the streaming application system further includes a streaming terminal; the device includes:

[0012] The time information determination module is used to respond to an alarm event reported by the camera and determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event;

[0013] The detection module is used to detect whether there is a streaming task that meets the predetermined merging conditions. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task that instructs the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging conditions are: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0014] The streaming task determination module is used to, if it exists, update the time information in the task information of the existing streaming task based on the target time information to obtain the streaming task that contains the alarm event corresponding to the alarm event; if it does not exist, generate the streaming task corresponding to the alarm event based on the target time information.

[0015] The streaming module is used to respond to the task execution time in the task information of any streaming task, and based on the time information in the task information of the streaming task, to extract the stream from the camera through the streaming terminal to obtain the event recording of the alarm event corresponding to the streaming task.

[0016] Thirdly, embodiments of this application provide a streaming application system, including: a management engine and a streaming terminal;

[0017] The management engine is configured to, in response to receiving an alarm event reported by a camera, determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event; detect whether there is a streaming task that meets a predetermined merging condition; if so, update the time information in the task information of the existing streaming task based on the target time information to obtain a streaming task that includes the alarm event; if not, generate a streaming task corresponding to the alarm event based on the target time information; and, in response to reaching the task execution time of any streaming task, send a request to the streaming terminal carrying the time information in the task information of the streaming task.

[0018] The streaming terminal is used to respond to a request issued by the management engine, and based on the time information in the task information of the streaming task, to retrieve the stream from the camera and obtain the event recording of the alarm event corresponding to the streaming task.

[0019] Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task used to instruct the streaming end to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0020] Fourthly, embodiments of this application provide an electronic device, including:

[0021] Memory, used to store computer programs;

[0022] The processor, when executing a program stored in memory, implements any of the described video recording and storage methods for a camera.

[0023] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the aforementioned video recording and storage methods for a camera.

[0024] This application also provides a computer program product containing instructions that, when run on a computer, causes the computer to execute any of the above-described video recording and storage methods for a camera.

[0025] Beneficial effects of the embodiments in this application:

[0026] The video recording and storage method for cameras provided in this application embodiment is applied to the management engine of a streaming application system, which also includes a streaming terminal. In this application, each streaming task is used to instruct the streaming terminal to obtain a video recording of the corresponding alarm event from the camera. Each streaming task can correspond to one or more consecutive alarm events, and the task information of each streaming task includes the task execution time and the time information of the video recording of the corresponding alarm event. By executing the streaming task, the streaming terminal obtains the video recording of the alarm event corresponding to the streaming task from the camera according to the time information of the streaming task. This enables the storage of the video recording of the alarm event to the central management device when the camera cannot actively push the video stream.

[0027] Additionally, if an alarm event is received from a camera, the target time information of the required event recording can be determined based on the target occurrence time of the alarm event. Furthermore, it can be checked whether there are any unfinished streaming tasks that overlap in time between the required event recording and the event recording related to the corresponding alarm event. If such a task exists, the time information in the task information of the existing streaming task is updated based on the target time information to obtain a streaming task containing the alarm event. If such a task does not exist, a streaming task corresponding to the alarm event is generated based on the target time information. Essentially, if a streaming task that meets the predetermined merging conditions exists, the event recording required for the alarm event can be merged with the event recording of the alarm event corresponding to the streaming task into a single recording. The time information in the streaming task is then updated, and the alarm event corresponding to the updated streaming task contains the alarm event, eliminating the need to generate a corresponding streaming task for that alarm event. In this way, the streaming of event recordings for multiple alarm events can be achieved through the execution of a single streaming task, reducing the number of interactions with the camera and minimizing the strain on the camera's processing power.

[0028] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

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

[0030] Figure 1 A schematic flowchart illustrating a video recording and storage method for a camera, provided as an embodiment of this application;

[0031] Figure 2 A timing diagram of the streaming task generated by the management engine provided in this application embodiment;

[0032] Figure 3 Another timing diagram of the streaming task generated by the management engine provided in this application embodiment;

[0033] Figure 4 This is a schematic diagram of the structure of a stream-taking application system provided in an embodiment of this application;

[0034] Figure 5 This is another schematic diagram illustrating a video recording and storage method for a camera, provided as an embodiment of this application.

[0035] Figure 6 A schematic diagram of a flow extraction process provided in an embodiment of this application;

[0036] Figure 7 A schematic diagram illustrating the execution process of a streaming task provided in an embodiment of this application;

[0037] Figure 8 A schematic diagram illustrating the retry process provided in an embodiment of this application;

[0038] Figure 9 A timing diagram illustrating the generation and execution of streaming tasks by the management engine provided in this embodiment of the application;

[0039] Figure 10 A schematic diagram of the structure of a video recording storage device for a camera provided in an embodiment of this application;

[0040] Figure 11 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0041] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0042] Cameras can be divided into national standard equipment and proprietary equipment. National standard equipment refers to camera equipment implemented in accordance with national standard protocols (such as GB / T28181-2022), while proprietary equipment refers to camera equipment customized by manufacturers according to proprietary protocols, adapted to their own ecosystems, with outstanding functions and performance optimizations but poor cross-brand compatibility.

[0043] Some private devices can record alarm events using their own capabilities and upload the recordings to the central management device for storage; however, some cameras (such as national standard devices) cannot actively stream recordings due to protocol limitations.

[0044] Based on this, embodiments of this application provide a method, apparatus, system, device, and medium for storing video recordings of cameras, so as to store the recordings of alarm events to a central management device when the camera is unable to actively push video streams.

[0045] The video recording and storage method for cameras provided in the embodiments of this application will be described below.

[0046] The video recording and storage method for cameras provided in this application embodiment can be applied to the management engine of a streaming application system. The streaming application system can also include a streaming terminal. The management engine can manage streaming tasks and obtain the event recording of the alarm event corresponding to the streaming task by drawing the stream from the camera through the streaming terminal. This enables the event recording of the alarm event to be stored at the central management device.

[0047] Furthermore, the management engine and the streaming terminal in the streaming application system of this application embodiment can be software programs or hardware devices; for example, the management engine or the streaming terminal can be the electronic device itself, or a software program deployed in the electronic device. The electronic device can include: a cloud server, a local management device, or a client device, specifically related to the form and location of the management engine and the streaming terminal. Specific examples will be described in detail in subsequent system embodiments and will not be repeated here. The central management device in this application embodiment can be understood as a cloud (cloud server) or a local management device. The management engine can be deployed on the central management device, and streaming can be implemented through the cloud or a local management device. Also, the camera involved in this application embodiment can be understood as a camera that cannot actively record and push streams. That is, this application can be applied to scenarios where the camera cannot actively push streams, and it is necessary to store the recordings of the camera's alarm events on the central management device.

[0048] The video recording and storage method for cameras provided in this application embodiment is applied to the management engine of a streaming application system, wherein the streaming application system further includes a streaming terminal; the method includes:

[0049] In response to receiving an alarm event reported by the camera, the target time information for recording the event required for the alarm event is determined based on the target occurrence time of the alarm event;

[0050] The system detects whether there are any streaming tasks that meet predetermined merging conditions. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task used to instruct the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0051] If it exists, based on the target time information, update the time information in the task information of the existing streaming task to obtain the streaming task containing the alarm event; if it does not exist, based on the target time information, generate the streaming task corresponding to the alarm event.

[0052] In addition, in response to the task execution time in the task information of any streaming task being reached, based on the time information in the task information of the streaming task, the streaming terminal extracts the stream from the camera to obtain the event recording of the alarm event corresponding to the streaming task.

[0053] The video recording and storage method for cameras provided in this application embodiment is applied to the management engine of a streaming application system, which also includes a streaming terminal. In this application, each streaming task is used to instruct the streaming terminal to obtain a video recording of the corresponding alarm event from the camera. Each streaming task can correspond to one or more consecutive alarm events, and the task information of each streaming task includes the task execution time and the time information of the video recording of the corresponding alarm event. By executing the streaming task, the streaming terminal obtains the video recording of the alarm event corresponding to the streaming task from the camera according to the time information of the streaming task. When the camera cannot actively push the video recording, the video recording of the alarm event is stored at the central management device.

[0054] Additionally, if an alarm event is received from a camera, the target time information of the required event recording can be determined based on the target occurrence time of the alarm event. Furthermore, it can be checked whether there are any unfinished streaming tasks that overlap in time between the required event recording and the event recording related to the corresponding alarm event. If such a task exists, the time information in the task information of the existing streaming task is updated based on the target time information to obtain a streaming task containing the alarm event. If such a task does not exist, a streaming task corresponding to the alarm event is generated based on the target time information. Essentially, if a streaming task that meets the predetermined merging conditions exists, the event recording required for the alarm event can be merged with the event recording of the alarm event corresponding to the streaming task into a single recording. The time information in the streaming task is then updated, and the alarm event corresponding to the updated streaming task contains the alarm event, eliminating the need to generate a corresponding streaming task for that alarm event. In this way, the streaming of event recordings for multiple alarm events can be achieved through the execution of a single streaming task, reducing the number of interactions with the camera and minimizing the strain on the camera's processing power.

[0055] The video recording and storage method for a camera provided in this application will be described exemplarily below with reference to the accompanying drawings.

[0056] like Figure 1 As shown in the embodiment of this application, a video recording and storage method for a camera may include the following steps:

[0057] S101: In response to receiving an alarm event reported by the camera, determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event;

[0058] Understandably, before acquiring the event recording of an alarm event, it is necessary to first determine the time information of the event recording, such as the start and end times of the event recording, so as to obtain the event recording by extracting the stream from the camera based on the time information.

[0059] Each alarm event can be associated with a target occurrence time. When a camera reports an alarm event, it can also report the target occurrence time of the alarm event to the management engine. Alternatively, the management engine can query the target occurrence time of the alarm event from the camera. In this way, after receiving an alarm event reported by the camera, the management engine can determine the target time information for the event recording required for that alarm event based on the target occurrence time. The target time information can be understood as including the start and end times of the event recording.

[0060] For example, for any alarm event, the required event recording starts earlier than the occurrence time of the alarm event and is separated by a first duration, and ends later than the occurrence time of the alarm event and is separated by a second duration.

[0061] Optionally, in one implementation, the target occurrence time is the moment the alarm event occurs (e.g., when a camera detects an alarm event, if an alarm event is detected at a certain moment, that moment is taken as the occurrence time of the detected alarm event). The method for determining the target time information includes: determining the target time information of the event recording required for the alarm event based on the occurrence time of the alarm event, a first duration, and a second duration; wherein, the first duration is a preset time interval between the start time of the event recording of the alarm event and the occurrence time of the alarm event, and the second duration is a preset time interval between the occurrence time of the alarm event and the end time of the event recording of the alarm event. For example, if the target occurrence time is 10 seconds, the first duration is 5 seconds, and the second duration is 10 seconds, then the target time information is 5 seconds and 20 seconds, that is, the event recording required for the alarm event is the recording between 5 seconds and 20 seconds. In this embodiment, the relationship between the first duration and the second duration is not limited and can be set according to actual needs.

[0062] Optionally, in another implementation, the target occurrence time is the time range of the alarm event (e.g., if a camera continuously detects an alarm event, and the alarm event continues to occur, then the time range of the alarm event is taken as the occurrence time range of the alarm event). The method for determining the target time information includes: determining the target time information of the required event recording for the alarm event based on a first moment and a second moment, as well as a first duration and a second duration, within the occurrence time range of the alarm event; wherein the first moment is the earliest moment within the occurrence time range of the alarm event, and the second moment is the latest moment within the occurrence time range of the alarm event. For example, if the target occurrence time is the time range from 10s to 15s, the first duration is 5s, and the second duration is 10s, then the target time information is 5s and 25s, meaning the required event recording for the alarm event is the recording between 5s and 25s.

[0063] By setting the first and second durations, the time period between the start and end times of the required event recording for an alarm event includes the time range before and after the occurrence of the alarm event. In this way, the event recordings of the alarm event acquired subsequently can more completely represent the event content of the alarm event.

[0064] It should be noted that the start time and end time involved in the embodiments of this application can be understood as moments or points in time, not a certain time period or time range. The start time and end time in the target time information can jointly represent a time period, which is the time period of the event recording represented by the target time information.

[0065] S102: Detect whether there is a pull task that meets the predetermined merging conditions;

[0066] Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is used to instruct the streaming end to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task is not completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0067] Each streaming task in this embodiment instructs the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. That is, by executing the streaming task, the streaming terminal obtains the stream from the camera. The task information for each streaming task includes the task execution time and the time information of the event recording for the corresponding alarm event. The task execution time can be later than the event recording time information. For example, the event recording time information includes a start time of 5 seconds and an end time of 20 seconds, while the task execution time is 65 seconds. The task execution time can be determined based on the start time and the task delay interval (e.g., 60 seconds) in the time information. The fact that the task execution time is later than the event recording time information ensures that the management engine only retrieves the stream from the streaming terminal after the alarm event recording is generated at the camera, ensuring that a complete event recording of the alarm event can be obtained.

[0068] In addition, considering that reducing the number of interactions with the camera can reduce the consumption of the camera's processing performance, the embodiments of this application do not interact with the camera once for each alarm event to obtain the event recording of the alarm event. That is, each streaming task is not limited to one alarm event, but can also correspond to multiple consecutive alarm events. In this way, the streaming of event recordings for multiple alarm events can be achieved by executing one streaming task, which can reduce the number of interactions with the camera and reduce the consumption of the camera's processing performance.

[0069] The term "consecutive alarm events" refers to alarm events occurring consecutively, or in other words, alarm events occurring in chronological order (e.g., at the 35th second, the 45th second, etc.). It does not mean that the events must be adjacent. Furthermore, the video recording of the corresponding alarm event indicated by the streaming task refers to a recording within a complete time period. If the streaming task corresponds to one alarm event, the recording indicated by the task is a single recording for that alarm event. If the streaming task corresponds to multiple consecutive alarm events, the recording indicated by the task is a recording of the same event corresponding to all multiple alarm events (i.e., the recording represents the content of multiple alarm events).

[0070] In this embodiment, the management engine can first detect whether there is a streaming task that meets the predetermined merging conditions. If so, the alarm event can be merged into the streaming task, meaning that the recording indicated by the merged streaming task contains the event recording required for the alarm event. The predetermined merging conditions are: the event recording required for the alarm event is not yet completed and there is a temporal overlap between the event recording of the alarm event corresponding to the streaming task. This allows for the merging of event recordings of multiple consecutive alarm events with temporal overlap, which can then be represented by a single streaming task.

[0071] It should be noted that the specific methods for determining time overlap will be described in detail in subsequent embodiments, and will not be repeated here.

[0072] S103: If it exists, update the time information in the task information of the existing streaming task based on the target time information to obtain the streaming task that contains the alarm event; if it does not exist, generate the streaming task corresponding to the alarm event based on the target time information.

[0073] If a streaming task that meets the predetermined merging conditions exists, the time information in the task information of the existing streaming task is updated according to the target time information. This is equivalent to merging the event recording of the alarm event with the event recording to be retrieved by the streaming task, resulting in a streaming task that includes the alarm event. At this point, the event recording may not necessarily be obtained; only the time of the event recording indicated by the streaming task is updated so that the updated streaming task includes the event recording required for the alarm event. If the streaming task is in progress and has not yet been completed (e.g., if the task delay interval is set to 10 seconds, a streaming task that meets the predetermined merging conditions may occur and is in progress), the streaming task can continue to be executed after updating the time information in the task information of the streaming task. This allows the streaming end to continue retrieving the stream from the camera, and the resulting event recording includes the event recording required for the alarm event. If the streaming task is not executed (e.g., if the task delay interval is set to 60s, there may be a streaming task that meets the predetermined merging conditions, but the streaming task is not executed), then after updating the time information in the task information of the streaming task, when the task execution time of the streaming task is reached, the streaming task will be executed, and the event recording obtained by streaming will contain the event recording required for the alarm event.

[0074] If no streaming task meets the predetermined merging conditions, a streaming task corresponding to the alarm event is directly generated based on the target time information. (This streaming task may later be used as a streaming task that meets the predetermined merging conditions, and the recording indicated by this streaming task will be merged with the event recording of the subsequent alarm event.) For example, in one implementation, generating the streaming task corresponding to the alarm event may include: creating task information based on the target time information to obtain the streaming task corresponding to the alarm event. The task information may include: target time information (including the start and end times of the event recording required for the alarm event), task execution time (which can be determined according to the above implementation method), etc. Furthermore, to describe the streaming task in more detail, the task information may also include task ID, task status, etc., which will be described in detail in subsequent embodiments and will not be elaborated here.

[0075] For example, in one implementation, the target time information includes the start time and the end time; the time information in the task information of each streaming task includes the start time and the end time.

[0076] Based on the target time information, update the time information in the task information of existing streaming tasks to obtain the streaming tasks that contain the corresponding alarm event, including:

[0077] Update the end time in the task information of the existing streaming tasks with the end time in the target time information to obtain the streaming tasks that contain the corresponding alarm event.

[0078] The target time information includes the start and end times of the event recording. The time information in the task information of each streaming task includes the start and end times of the recording segment to be pulled by that task. If the recording segment to be pulled by that task overlaps with the event recording of the alarm event, then the end time in the task information of the existing streaming task can be directly updated with the end time in the target time information to merge the event recording of the alarm event with the event recording to be pulled by the streaming task. For example, if the start and end times of the recording segment to be pulled by the streaming task are 5s and 20s respectively, and the start and end times in the target time information are 15s and 30s respectively, then the start and end times of the recording segment to be pulled by the streaming task after updating the time information can be 5s and 30s respectively.

[0079] As can be seen, in this embodiment of the application, by updating the end time in the task information of the existing streaming task through the end time in the target time information, the event recording of the alarm event can be merged with the event recording pulled by the streaming task. The merging method is simple and fast. Furthermore, by executing the merged streaming task, the recordings representing the event content of multiple alarm events can be directly obtained. The streaming of event recordings of multiple alarm events can be achieved by executing one streaming task, which can reduce the number of interactions with the camera and reduce the consumption of camera processing performance.

[0080] S104: In response to the arrival of the task execution time in the task information of any streaming task, based on the time information in the task information of the streaming task, the streaming terminal extracts the stream from the camera to obtain the event recording of the alarm event corresponding to the streaming task.

[0081] For any streaming task (whether it is a streaming task after updating time information or a streaming task directly generated based on target time information), when the task execution time in the task information of the streaming task is reached, the management engine can retrieve the stream from the camera through the streaming terminal based on the time information in the task information of the streaming task (i.e. the start time and end time of the event recording to be obtained), so as to obtain the event recording of the alarm event corresponding to the streaming task.

[0082] For example, in one implementation, the management engine can directly send the time information from the task information of the streaming task to the streaming terminal. The streaming terminal can then automatically retrieve the stream from the camera based on the time information (for example, the streaming terminal sends a start streaming command carrying the start time of the time information to the camera, and sends a stop streaming command to the camera when it detects that the end time of the time information has been reached).

[0083] In another implementation, the management engine can send a streaming request carrying the start time in the task information to the streaming client, and when it detects that the end time of the task information has been reached, it sends a termination request to the streaming client to control the streaming client to stop streaming. The specific implementation method will be described in detail in subsequent embodiments, and will not be repeated here.

[0084] It should be noted that steps S101-S103 can be executed in parallel with step S104. That is, while managing tasks, for a streaming task that has reached its execution time, the streaming task can be executed and the corresponding event recording can be obtained. Alternatively, step S104 can be executed first. This application embodiment does not limit this.

[0085] In the technical solution of this application, the acquisition, storage, use, processing, transmission, provision and disclosure of alarm events, event recordings, target occurrence time and streaming task information are all carried out with the user's authorization.

[0086] The video recording and storage method for cameras provided in this application embodiment is applied to the management engine of a streaming application system, which also includes a streaming terminal. In this application, each streaming task is used to instruct the streaming terminal to obtain a video recording of the corresponding alarm event from the camera. Each streaming task can correspond to one or more consecutive alarm events, and the task information of each streaming task includes the task execution time and the time information of the video recording of the corresponding alarm event. By executing the streaming task, the streaming terminal obtains the video recording of the alarm event corresponding to the streaming task from the camera according to the time information of the streaming task. When the camera cannot actively push the video recording, the video recording of the alarm event is stored at the central management device.

[0087] Additionally, if an alarm event is received from a camera, the target time information of the required event recording can be determined based on the target occurrence time of the alarm event. Furthermore, it can be checked whether there are any unfinished streaming tasks that overlap in time between the required event recording and the event recording related to the corresponding alarm event. If such a task exists, the time information in the task information of the existing streaming task is updated based on the target time information to obtain a streaming task containing the alarm event. If such a task does not exist, a streaming task corresponding to the alarm event is generated based on the target time information. Essentially, if a streaming task that meets the predetermined merging conditions exists, the event recording required for the alarm event can be merged with the event recording of the alarm event corresponding to the streaming task into a single recording. The time information in the streaming task is then updated, and the alarm event corresponding to the updated streaming task contains the alarm event, eliminating the need to generate a corresponding streaming task for that alarm event. In this way, the streaming of event recordings for multiple alarm events can be achieved through the execution of a single streaming task, reducing the number of interactions with the camera and minimizing the strain on the camera's processing power.

[0088] Optionally, in another embodiment of this application, the method for determining whether there is a temporal overlap between the event recording required for the alarm event and the event recording for the corresponding alarm event includes:

[0089] Determine whether the time interval between the occurrence time of the specified alarm event and the target occurrence time is not greater than the target duration. If it is not greater, then it is determined that there is a time overlap.

[0090] The target duration is the sum of the durations of the first duration and the second duration.

[0091] For any streaming task, if the streaming task corresponds to one alarm event, the designated alarm event corresponding to the streaming task is that one alarm event; if the streaming task corresponds to multiple consecutive alarm events, the designated alarm event corresponding to the streaming task is the latest alarm event among the multiple consecutive alarm events.

[0092] When determining whether there is a time overlap between the event recording required for an alarm event and the event recording of an alarm event corresponding to a certain streaming task, the specified alarm event corresponding to the streaming task can be determined first. That is, if the streaming task corresponds to one alarm event, then that alarm event is the specified alarm event. If the streaming task corresponds to multiple consecutive alarm events, then the specified alarm event corresponding to the streaming task is the latest alarm event among the multiple consecutive alarm events. Then, it is determined whether the interval between the occurrence time of the specified alarm event and the target occurrence time of the alarm event is not greater than the target duration. If it is not greater, it is determined that there is a time overlap.

[0093] In addition, it can be determined whether the start time in the target time information of the alarm event is within the time information in the task information of the streaming task, that is, whether it is within the time range of the start and end time of the time information. If it is, it is determined that there is a time overlap.

[0094] The target duration is the sum of the first duration and the second duration. Determining whether the time interval between the occurrence time of the specified alarm event and the target occurrence time is not greater than the target duration can be understood as follows: if it is not greater than the target duration, it means that the start time in the target time information of the alarm event is within the time range of the start and end times of the time information, that is, there is a time overlap between the two recordings.

[0095] For example, taking a first duration of 5 seconds and a second duration of 10 seconds as an example, in one implementation, such as... Figure 2 As shown, Event 1, as the first alarm event, occurs at 10 seconds. The corresponding event recording starts at 5 seconds and ends at 20 seconds. A streaming task for Event 1 can be directly created (the start and end times of the recording are 5 seconds and 20 seconds, respectively). For Event 2, it occurs at 25 seconds. The corresponding event recording starts at 20 seconds and ends at 35 seconds. Based on the above method, it is determined that the event recording for Event 2 overlaps with the event recording for Event 1. Therefore, the event recording for Event 2 is merged into the streaming task for Event 1. The start and end times in the updated streaming task information are 5 seconds and 35 seconds, respectively. Events 3 and 4 are determined in a similar way, and it is determined that their event recordings overlap with the event recordings indicated by the streaming task. The start and end times of the recording 1 indicated by the streaming task are 5 seconds and 50 seconds, respectively (which can represent the event content of Events 1-4). Among them, the designated alarm event corresponding to event 2 is event 1, the designated alarm event corresponding to event 3 is event 2, and the designated alarm event corresponding to event 4 is event 3.

[0096] For example, in another implementation, such as Figure 3As shown, Event 1, as the first alarm event, occurs at 10 seconds, and the corresponding event recording starts at 5 seconds and ends at 20 seconds. Therefore, a streaming task for Event 1 can be created directly. For Event 2, it occurs at 40 seconds, and the corresponding event recording starts at 35 seconds and ends at 50 seconds. Based on the above method, it is determined that the event recording for Event 2 does not overlap with the event recording for Event 1, so a streaming task for Event 2 can be created directly (the indicated start and end times for recording 2 are 35 seconds and 50 seconds respectively). For Event 3, it occurs at 70 seconds, and the corresponding event recording starts at 65 seconds and ends at 80 seconds. Based on the above method, it is determined that the event recording corresponding to event 3 does not overlap in time with the event recordings of event 1 and event 2. Therefore, a streaming task for event 3 is directly created (the start and end times of the indicated recordings are 65s and 80s, respectively). For event 4, its occurrence time is 80s, and the start time of the corresponding event recording is 75s and the end time is 90s. Based on the above method, it is determined that the event recording corresponding to event 4 overlaps in time with the event recording of event 3. Therefore, the event recording of event 4 is merged into the streaming task corresponding to event 3. The start and end times of recording 3 indicated by the updated streaming task are 65s and 90s, respectively.

[0097] As can be seen, in this implementation, for any alarm event, the system can accurately and quickly determine whether there is a time overlap by checking if the time interval between the target occurrence time of the alarm event and the occurrence time of the specified alarm event is no greater than the target duration. If there is a time overlap, and the streaming task has not been completed (in this embodiment, the task delay interval can be 60 seconds, meaning that if there is a time overlap, it means that the streaming task has not been completed and can be directly merged), then the event recording of the alarm event can be merged into the streaming task. This allows the streaming of event recordings for multiple alarm events to be obtained through the execution of a single streaming task, reducing the number of interactions with the camera and reducing the consumption of camera processing performance. If there is no time overlap, a streaming task corresponding to the alarm event can be generated directly based on the target time information of the alarm event, and the event recording of the alarm event can be obtained through the execution of the streaming task.

[0098] The management engine in this application will be described below with reference to an embodiment.

[0099] To minimize interactions with the camera—that is, to initiate only one streaming request for a complete recording—multiple streaming tasks for alarm events belonging to the same recording segment can be merged. For more accurate and non-overlapping streaming, the streaming range only needs to cover the time of the event recording, and streaming terminates once the recording is complete. Furthermore, considering the need for timely triggering of streaming requests, and the requirement that streaming can begin after the camera's local recording is generated following an alarm event (i.e., the event recording is already generated when the streaming request is triggered), this application designs a delayed streaming time after the event occurs, based on the camera's recording data generation delay. This means the streaming task needs a delay, with a possible delay interval of 60 seconds, which can actually be shortened to 10 seconds, depending on requirements.

[0100] To address the aforementioned requirements, the management engine in this embodiment of the application processes the following steps upon receiving any alarm event:

[0101] For any alarm event, determine the start and end times of the event recording for that alarm event, and determine whether the event recording for that alarm event needs to be merged into the previous event recording, i.e., whether there is a streaming task that meets the predetermined merging conditions. The specific determination method can be found in the above embodiment, and will not be elaborated here.

[0102] If merging is not required, that is, there is no pull stream task that meets the predetermined merging conditions, meaning the event recording of the alarm event is a new recording, then a pull stream task is created based on the start and end times of the event recording, including the start and end times of the event recording, and the execution time of the pull stream task.

[0103] If merging is required, i.e., there is a streaming task that meets the predetermined merging conditions, then when the event recording needs to be merged into the previous event recording (the recording that the streaming task that meets the predetermined merging conditions indicates to be pulled), the end time in the task information of the streaming task is updated according to the end time of the event recording.

[0104] For example, such as Figure 9 As shown, Event 1 occurs at 10 seconds. For Event 1, a streaming task 1 can be created, with a start time of 5 seconds, an end time of 20 seconds, and a task execution time of 65 seconds. Event 2 occurs at 35 seconds. For Event 2, a streaming task 2 can be created, with a start time of 30 seconds, an end time of 45 seconds, and a task execution time of 90 seconds. Event 3 occurs at 45 seconds. For Event 3, the event recording of Event 3 can be merged into the streaming task of Event 2. The event recording of Event 3 is merged into streaming task 2, that is, the end time of streaming task 2 is updated to the end time of Event 3 (55 seconds).

[0105] At 65 seconds, streaming task 1 is executed, and a streaming request is sent. That is, at 65 seconds, the task execution time of streaming task 1 is reached, and the management engine sends the streaming request of streaming task 1 to the streaming client. At 80 seconds, the end time of streaming task 1 is reached, and the management engine sends the termination request of streaming task 1 to the streaming client. At 90 seconds, streaming task 2 is executed, and a streaming request is sent. That is, at 90 seconds, the task execution time of streaming task 2 is reached, and the management engine sends the streaming request of streaming task 2 to the streaming client. At 115 seconds, the end time of streaming task 2 is reached, and the management engine sends the termination request of streaming task 2 to the streaming client.

[0106] In this embodiment, under normal circumstances, the execution time of the task is consistent with the recording duration (e.g., the recording duration of video 1 is from the 5th to the 20th second, a total of 15 seconds; during the execution of streaming task 1, 1 second of video data is retrieved every 1 second, i.e., the execution time of streaming task 1 is from the 65th to the 80th second, a total of 15 seconds). If abnormal situations occur (such as being affected by device network latency during the retrieval process), the execution time of the task may be longer than the recording duration. In this case, the execution time and end time of subsequent streaming tasks can be postponed, etc.

[0107] To facilitate understanding of the solution in this application, the flow extraction application system involved in the embodiments of this application will be introduced below.

[0108] like Figure 4 As shown, the streaming application system involved in this application embodiment may include: a device access application, a management engine, a streaming terminal, a video file management module, and a metadata management module.

[0109] The management engine is used for: 1. Controlling which devices need to pull streams (business layer applications), processing alarm events reported by cameras, and creating pull stream tasks (pull stream requests can be sent to the streaming end during task execution). 2. Acting as the management engine for pull stream task execution, managing the process of pull stream task execution. 3. Processing pull stream results, adjusting task status, and reporting recording metadata to the metadata management module, etc.

[0110] The streaming client is used for: 1. Receiving streaming requests from the management engine and initiating playback streaming to the camera. 2. Processing the acquired streaming media content, splitting the recording into smaller files. 3. Uploading the recording files to the recording file management module and sending the streaming results and recording metadata back to the management engine.

[0111] The metadata management module is used for saving, processing, querying, and deleting video recording metadata.

[0112] The video file management module is used as a file storage service to save video files.

[0113] The device access application is used to manage device (camera) access, receive alarm events reported by cameras and forward them to the management engine.

[0114] The management engine can be controlled through the business layer application, and video recordings can be queried from the metadata management module.

[0115] The overall process of video recording and storage for cameras is as follows: Figure 5 As shown, after an event is triggered at the camera side, the camera reports the triggered event to the device access application. The device access application filters the event, performs alarm processing on the filtered events that require alarms, and forwards the alarm event to the management engine. The management engine creates a streaming task for the alarm event, or merges the event recording of the alarm event into a streaming task that meets predetermined merging conditions. When the execution time of any streaming task is reached, the management engine retrieves the stream through the streaming terminal, and uploads the obtained recording file and metadata to the recording file management module and metadata management module for storage, respectively.

[0116] Among them, the events that need to be alerted after filtering are those related to video alarms, such as: human video alarms, moving target detection alarms, abandoned object detection alarms, object removal detection alarms, tripwire detection alarms, intrusion detection alarms, reverse movement detection alarms, loitering detection alarms, traffic statistics alarms, density detection alarms, video anomaly detection alarms, rapid movement alarms, image occlusion alarms, etc. The specific event detection methods and filtering methods can be similar to existing technologies, and will not be elaborated here.

[0117] This application embodiment uses a streaming application system to perform merging and discarding calculations on alarm events reported by cameras in a certain way, and combines a management engine and streaming terminal to extract streams from cameras, thereby realizing the central management device-side storage of event recordings of camera alarm events; in addition, this application has the characteristics of high recording integrity, high reliability, low recording generation latency, and controllable concurrency (i.e., supporting the parallel execution of multiple streaming tasks, accelerating the event recording acquisition process).

[0118] Specifically, in this embodiment of the application, the occurrence time of the alarm event reported by the camera is received. For the corresponding event recording, the event recording is processed by the streaming task management engine, such as merging and discarding, and then the streaming is initiated to the camera. The event recording is then saved to the central management device.

[0119] Optionally, in another embodiment of this application, in response to the arrival of the task execution time in the task information of any streaming task, based on the time information in the task information of the streaming task, the streaming terminal extracts the stream from the camera to obtain the event recording of the alarm event corresponding to the streaming task, including:

[0120] In response to the completion of any streaming task's execution time, a streaming request carrying the start time from the task information of the streaming task is sent to the streaming terminal. This causes the streaming terminal to respond to the streaming request by sending a start streaming command carrying the start time from the streaming request to the camera to start streaming from the camera. Whenever the video data obtained from the camera meets the conditions for generating a video sub-file, a video sub-file is generated based on the obtained video data, and the video sub-file is stored. The management engine is also fed back an acknowledgment result carrying at least the metadata of the stored video sub-file. The metadata includes the end time of the video data used to generate the video sub-file.

[0121] In response to the receipt result, the metadata in the receipt result is parsed as the event recording metadata of the alarm event corresponding to the streaming task, and it is determined whether the end time in the parsed metadata is not earlier than the end time in the task information of the streaming task. If so, a termination request corresponding to the streaming task is sent to the streaming terminal, so that the streaming terminal responds to the termination request and sends a stop streaming command to the camera.

[0122] In this implementation, the management engine controls the start and end of streaming. When the execution time for any streaming task is reached, the management engine sends a streaming request to the streaming terminal, carrying the start time from the task information. The streaming terminal receives the request and sends a start streaming command to the camera, carrying the start time from the request, to begin streaming from the camera at that start time. During the streaming process, whenever the video data obtained from the camera meets the conditions for generating a video sub-file (e.g., the acquired video data reaches a predetermined size, such as 5MB), a video sub-file is generated based on the obtained video data. The size of the video sub-file can be 5MB or less, and it is uploaded to the video file management module for storage. Additionally, the management engine receives a receipt containing at least the metadata of the stored video sub-file (it may also contain streaming results, such as the streaming task status or progress, which will be described in detail later). The metadata of the video sub-file is used to describe the video sub-file. It can include the end time of the video data of the video sub-file so as to determine whether to end the streaming based on the end time. The metadata can also include other content, such as: the file name, file size, generation time, modification time, storage location, etc. of the video sub-file.

[0123] The management engine can receive the acknowledgment results of the recorded sub-files, parse the metadata in the acknowledgment results, and obtain the end time contained in the metadata. If the end time is not earlier than the end time in the task information of the streaming task, it sends a termination request corresponding to the streaming task to the streaming terminal. The streaming terminal receives the termination request and sends a stop streaming command to the camera, ending the streaming from the camera. Furthermore, the metadata parsed from the acknowledgment results of each recorded sub-file is the event recording metadata of the alarm events corresponding to the streaming task. This event recording metadata of the alarm events corresponding to the streaming task can be uploaded to the metadata management module for storage.

[0124] In this embodiment, the management engine can control the streaming end to start streaming through a streaming request, and control the end of streaming through a termination request based on the end time in the metadata of the streaming end's receipt result; and store the metadata in the receipt result; the management engine manages the creation, merging and execution of streaming tasks, and can store metadata in real time during the execution process, and store video sub-files through the streaming end, realizing real-time streaming and storage of video files and metadata. If streaming is interrupted, it can still store part of the acquired video files and metadata, and resume streaming from the time of the interruption later.

[0125] Optionally, in another embodiment of this application, the task information of each streaming task further includes: at least one specified attribute, the at least one specified attribute including one or more of the following: task status attribute, streaming progress attribute, error code attribute, and retry attribute; the error code attribute is used to characterize the error code that caused the streaming failure.

[0126] The streaming terminal is also used to report an error code to the management engine indicating the reason for the streaming failure if the streaming fails to be retrieved from the camera.

[0127] After sending a streaming request carrying the start time from the task information of the streaming task to the streaming terminal, the method further includes:

[0128] Based on the information fed back from the streaming terminal, update the attribute values ​​of the specified attributes of the streaming task that match the information fed back from the streaming terminal; wherein the information fed back from the streaming terminal includes at least a receipt result or an error code.

[0129] In addition to the target time information and task execution time, the task information for each streaming task may also include one or more of the following attributes: task status attribute, streaming progress attribute, error code attribute, and retry attribute (and may also include task ID, etc.). The error code attribute is used to characterize the error code that caused the streaming failure, and the error code can be a string obtained by combining letters and symbols; this application embodiment does not limit this.

[0130] Among them, the task ID is the unique identifier of the streaming task; the task status attribute is used to represent the status information of the streaming task; the streaming progress attribute is used to represent the end time of the retrieved recording (i.e., the end time of the video data of the retrieved recording sub-files); the retry attribute is used to represent the number of retries after an error. After the retry limit is reached, the streaming task will no longer be executed.

[0131] Task status attributes may include:

[0132] Initial state: The state of newly created or merged pull tasks after receiving an alarm event;

[0133] Pulling stream in progress: This state is entered after the management engine sends a pull stream request;

[0134] Streaming in progress: The status after receiving the metadata of the acknowledgment result from the streaming end;

[0135] Streaming Complete: The status of the event recording corresponding to the streaming task being successfully retrieved;

[0136] Streaming failure: The status after a streaming task fails. The failed streaming task can be retried based on the error code and the number of retries.

[0137] The streaming client can also send an error code indicating the reason for the failure to retrieve the stream from the camera to the management engine. Furthermore, the receipt can include task status attributes, streaming progress attributes, error code attributes, and retry attributes.

[0138] The management engine can update the attribute values ​​of specified attributes of the streaming task that match the information returned by the streaming client, based on information such as error code receipts. In other words, during the streaming process, the status and progress of the streaming task are updated in real time; and if the streaming fails, the error code and the number of retries are updated in real time.

[0139] In this embodiment, the task information of the streaming task also includes at least one specified attribute. The streaming terminal can also feed back the content of the specified attribute to the management engine, such as: error code, task status, streaming progress, etc.; then, the management engine can update the attribute value of the specified attribute of the streaming task according to the information fed back by the streaming terminal; that is, the streaming task can be described in real time through the attribute value of the specified attribute of the streaming task.

[0140] The process of fetching streams is as follows: Figure 6 As shown:

[0141] The streaming client sends a receipt (the error code can be part of the receipt) to the management engine. The receipt can contain an error code or a message indicating successful streaming. If it is an error code, it means that the streaming failed. The task is then updated to an error status and the error code is updated. In other words, the task status of the streaming task is updated to an error status, and the error code is updated as an attribute value to the error code attribute. If the stream retrieval is successful, the retrieval process will proceed. During the retrieval process, the management engine can determine whether the stream is out of range based on the end time in the metadata of the receipt result, i.e., whether the end time in the metadata is not earlier than the end time in the task information of the retrieval task. If yes, i.e., it exceeds the range of the event recording to be retrieved, a termination request is sent to the retrieval end, and the task is updated to the retrieval completion status, i.e., the task status of the retrieval task is updated to the retrieval completion status. If no, i.e., it does not exceed the range of the event recording to be retrieved, the task is updated to the retrieval in progress and the retrieval progress is updated, i.e., the task status of the retrieval task is updated to the retrieval in progress, and the retrieval progress attribute is updated based on the retrieval progress in the receipt result (such as the end time of the currently acquired video data) as the attribute value. Then, the step of determining whether the stream is out of range is returned, and the retrieval process continues.

[0142] In some cases, unreliable factors at various stages during the execution of a streaming task may ultimately result in no event recordings. Therefore, defining various streaming states during the streaming task specification process, as well as managing state updates and failure handling strategies at each stage, are crucial to ensuring the integrity and reliability of event recordings.

[0143] The execution process of the streaming task is as follows: Figure 7 As shown, the streaming task in the initial state is executed with a delay, that is, the streaming task is executed only when the task execution time is reached; during the execution, the management engine sends a streaming request to the streaming terminal, and the streaming terminal responds back to the management engine (that is, responds to the streaming request). The streaming terminal retrieves the stream from the camera. Under normal circumstances, the event recording is completed after the streaming is finished, that is, the streaming is completed.

[0144] However, exceptions may occur during the initial state, when issuing the pull request, and when retrieving the stream, causing the pull to fail. The exceptions are as follows:

[0145] Anomaly 1: The streaming task was lost, resulting in the loss of the corresponding event recordings. This may be because the streaming task was not executed when its scheduled execution time arrived.

[0146] Anomaly 2: The streaming task was not executed, and the recording was lost. This may be due to an error on the streaming terminal after the streaming request was sent, resulting in the request not being processed; or, the streaming terminal is unable to stream, and the acknowledgment result fails; or, during the retry of streaming, the number of streaming channels of the camera reaches the limit, preventing streaming.

[0147] Anomaly 3: The streaming task failed to acquire the video stream (video data), and the event recording was lost. This could be due to a camera malfunction, preventing successful streaming and sending an error code and failure result to the management engine; or, acquiring a portion of the video stream but being unable to continue streaming, sending an error code and failure result to the management engine; or, the streaming end failed to upload the recording file, sending an error code and failure result to the management engine; or, the streaming end failed to send a response to the management engine.

[0148] Optionally, in another embodiment of this application, at least one specified attribute includes a task status attribute, a streaming progress attribute, an error code attribute, and a retry attribute; the retry attribute is used to characterize the number of retries for the streaming task.

[0149] The method also includes:

[0150] After the task execution time in the task information of any streaming task is reached, monitor whether the attribute value of the error code attribute of the streaming task is one of the preset attribute values; wherein, the preset attribute values ​​include: a first attribute value for the failure of the streaming request to be sent by the streaming end, and a second attribute value for the failure of the streaming end to retrieve the stream.

[0151] If the attribute value of the error code attribute of the streaming task is one of the preset attribute values, determine the exception handling strategy for the streaming task that matches the attribute value of the error code attribute.

[0152] Implement the determined exception handling strategy;

[0153] Among them, the exception handling strategy that matches the first attribute value is the first strategy, and the exception handling strategy that matches the second attribute value is the second strategy; the first strategy includes: resending the pull request to the stream-fetching end;

[0154] The second strategy includes: if the number of retries represented by the retry attribute value does not exceed a specified number, sending a retry request to the streaming terminal to trigger the streaming terminal to retry the streaming from the camera.

[0155] In this embodiment, at least one specified attribute includes a task status attribute, a streaming progress attribute, an error code attribute, and a retry attribute. To ensure the reliability of streaming task execution, the management engine can also monitor whether the error code attribute value of any streaming task is one of the preset attribute values ​​after the task execution time of any streaming task is reached. If the error code attribute value is detected as one of the preset attribute values, it indicates that the streaming task has failed and can be retried (the error code may contain a retryable field; if the field contains a preset field value, it indicates that the streaming task can be retried). Then, an exception handling strategy that matches the error code attribute value for the streaming task can be determined, and the determined exception handling strategy can be executed.

[0156] The preset attribute values ​​may include a first attribute value indicating that the pull request from the stream-fetching end failed to be sent (corresponding to the above-mentioned exception 1), and a second attribute value indicating that the stream-fetching end failed to fetch (corresponding to the above-mentioned exception 2 where the stream-fetching end cannot fetch the stream and the receipt result feedback fails; exception 2 where the stream-fetching end is abnormal after the pull request is sent and the pull request is not processed; and exception 3).

[0157] Additionally, if a streaming task is in its initial state and fails to execute after its scheduled execution time, the error code attribute of that task can be set to the first attribute value. If the management engine sends a streaming request but does not receive a response during the streaming task's execution (i.e., the streaming request is being sent, but the streaming client does not respond to the request for an extended period), the error code attribute of that task can also be set to the first attribute value. If the streaming task executes, but the streaming client sends a retryable error code, or the management engine marks the streaming task as abnormal, the error code attribute of that task can be set to the second attribute value. If the streaming client sends a streaming result during the execution of the task, but the streaming is not finished and no further results are sent, meaning the processing time of the streaming task is too long, the error code attribute of that task can be set to the second attribute value.

[0158] The exception handling strategy adapted to the first attribute value is the first strategy of resending the pull request to the streaming end. That is, if the pull request fails to be sent, it can be resent to execute the pull task. The exception handling strategy adapted to the second attribute value is the second strategy. That is, if the number of retries represented by the retry attribute value does not exceed the specified number (e.g., 3 times, which can be set as needed), a retry request is sent to the streaming end to trigger the streaming end to retry the streaming from the camera. In other words, if the streaming end fails to stream, and the current number of retries has not exceeded the upper limit of the number of retries (the specified number), a retry request can be sent to the streaming end, and the streaming end will retry according to the previously sent pull request.

[0159] For example, in another implementation, each preset attribute value also includes: a third attribute value indicating that the pull request has not been issued;

[0160] The third strategy adapted to the third attribute value includes: if the number of streaming channels currently supported by the camera has not reached the maximum number of channels, resend the streaming request for the streaming task to the streaming terminal;

[0161] Before sending a pull request carrying the start time from the task information of the pull task to the pull terminal, the method further includes:

[0162] Determine whether the number of streaming channels currently supported by the camera has not reached the maximum number. If so, trigger the step of sending a streaming request carrying the start time of the streaming task information to the streaming terminal. Otherwise, set the error code attribute value of the streaming task to the third attribute value.

[0163] Each preset attribute value includes a third attribute value that indicates that the streaming request has not been sent (corresponding to the above-mentioned exception 2, when the number of streaming channels of the camera reaches the upper limit and cannot be streamed during the retry of streaming). The corresponding third strategy is: if the number of streaming channels currently supported by the camera has not reached the maximum number of channels, resend the streaming request of the streaming task to the streaming terminal.

[0164] In addition, before executing the third strategy, it can be determined whether the number of streaming channels currently supported by the camera has not reached the maximum number (the management engine can determine whether the number of streaming channels currently supported by the camera has not reached the maximum number through the streaming terminal). If it has not reached the maximum number, it means that the camera currently supports streaming, and the third strategy is executed to send a streaming request to the streaming terminal; if it has reached the maximum number, it means that the camera cannot currently stream, and the error code attribute value of the streaming task continues to remain at the third attribute value until the number of streaming channels supported by the camera has not reached the maximum number, and then a streaming request is sent to the streaming terminal again.

[0165] In this embodiment, by monitoring the attribute values ​​of the error code attributes of the streaming task and determining and executing the corresponding exception handling strategy based on the attribute values, various abnormal links of the streaming task can be handled and retried, ensuring the reliability of the streaming task execution.

[0166] In this embodiment of the application, the retry process described above can be executed by the management engine, and the specific process is as follows: Figure 8 As shown:

[0167] The management engine can be configured with a task pool containing various streaming tasks; tasks can be retrieved from the task pool, monitored, and error codes of the streaming task can be obtained.

[0168] If the error code is one of the preset attribute values ​​(first, second, or third attribute value), then a matching strategy is applied based on the attribute value, and the strategy is executed. These strategies can include: task assignment, marking an exception, and no processing (e.g., if the number of retries exceeds or reaches a specified number, then the streaming task is not processed). Task assignment corresponds to the exception handling strategy for the first attribute value; marking an exception corresponds to the exception handling strategies for the second and third attribute values, and the specific strategy can be determined based on the attribute value.

[0169] During the execution of the strategy, tasks can be updated, such as updating the attribute values ​​of specified attributes like the task status attribute and streaming progress attribute (if retry is successful). Furthermore, the above process can be executed periodically and can be performed on every incomplete streaming task in the task pool to ensure the reliability of streaming task execution. This application provides a robust streaming management strategy (i.e., anomaly handling strategy): through the management of the flow status of each node during the streaming task execution process, and the capture and handling of various anomalies, it provides a video recording and storage method for cameras characterized by strong recording timeliness, high integrity, low device interaction frequency, and controllable concurrency.

[0170] Based on the above method embodiments, this application also provides a video recording and storage device for a camera, and a management engine for a streaming application system, wherein the streaming application system further includes a streaming terminal; as shown Figure 10 As shown, the device includes:

[0171] The time information determination module 1010 is used to respond to an alarm event reported by the camera and determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event;

[0172] The detection module 1020 is used to detect whether there is a streaming task that meets a predetermined merging condition. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task that instructs the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0173] The streaming task determination module 1030 is used to, if it exists, update the time information in the task information of the existing streaming task based on the target time information to obtain the streaming task that contains the alarm event corresponding to the alarm event; if it does not exist, generate the streaming task corresponding to the alarm event based on the target time information.

[0174] The streaming module 1040 is used to respond to the task execution time in the task information of any streaming task, and based on the time information in the task information of the streaming task, to extract the stream from the camera through the streaming terminal to obtain the event recording of the alarm event corresponding to the streaming task.

[0175] Based on the above embodiments, this application also provides a streaming application system, including: a management engine and a streaming terminal;

[0176] The management engine is configured to, in response to receiving an alarm event reported by a camera, determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event; detect whether there is a streaming task that meets a predetermined merging condition; if so, update the time information in the task information of the existing streaming task based on the target time information to obtain a streaming task that includes the alarm event; if not, generate a streaming task corresponding to the alarm event based on the target time information; and, in response to reaching the task execution time of any streaming task, send a request to the streaming terminal carrying the time information in the task information of the streaming task.

[0177] The streaming terminal is used to respond to a request issued by the management engine, and based on the time information in the task information of the streaming task, to retrieve the stream from the camera and obtain the event recording of the alarm event corresponding to the streaming task.

[0178] Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task used to instruct the streaming end to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

[0179] For details regarding the implementation of the management engine and the stream acquisition end, please refer to the relevant content in the above method embodiments, which will not be repeated here.

[0180] Optionally, the management engine is a first cloud server or management software set on the first cloud server, and correspondingly, the stream retrieval end is a second cloud server or a stream retrieval application set on the second cloud server.

[0181] or,

[0182] The management engine is a local management device or management software set on the local management device. Correspondingly, the stream acquisition end is a client device or a stream acquisition application set in the client device. The client device is a device with human-computer interaction function.

[0183] or,

[0184] The management engine is a first cloud server or management software set on the first cloud server, and correspondingly, the stream retrieval end is the client device or a stream retrieval application set in the client device.

[0185] In this embodiment, the streaming application system can be located in the cloud. In this case, the management engine can be a first cloud server (hardware) or management software set on the first cloud server; the streaming end can be a second cloud server (hardware) or a streaming application (software for streaming) set on the second cloud server; and when both the management engine and the streaming end are software, that is, the management engine is the management software set on the first cloud server and the streaming end is the streaming application set on the second cloud server, the first cloud server and the second cloud server can be the same or different devices.

[0186] The streaming application system can also be located locally. In this case, the management engine is a local management device (hardware) or management software installed on the local management device; the streaming end is a client device (hardware) or a streaming application installed on the client device; the client device has human-computer interaction capabilities and can stream from a camera. The local management device can act as a server for the client device, managing the streaming of the client device.

[0187] In addition, the management engine in the streaming application system can be located in the cloud, while the streaming endpoint can be located on a local client device. In this case, the management engine can be the primary cloud server or management software set up on the primary cloud server; the streaming endpoint is the client device or a streaming application set up on the client device. The primary cloud server acts as the server for the client device, managing the streaming of the client device.

[0188] As can be seen, in this embodiment, the management engine and the streaming terminal can have various forms and settings. The management engine and the streaming terminal can be flexibly set up to meet user needs. This can meet the user's requirements for the layout of the management engine and the streaming terminal. When the camera cannot actively record and push the video, the event recording of the alarm event is stored at the central management device.

[0189] This application also provides an electronic device, such as... Figure 11 As shown, it includes:

[0190] Memory 1101 is used to store computer programs;

[0191] When the processor 1102 executes the program stored in the memory 1101, it implements the steps of the video recording and storage method for the camera as described below.

[0192] Furthermore, the aforementioned electronic device may also include a communication bus and / or a communication interface, with the processor 1102, the communication interface, and the memory 1101 communicating with each other via the communication bus.

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

[0194] The communication interface is used for communication between the aforementioned electronic devices and other devices.

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

[0196] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0197] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described video recording and storage methods for a camera.

[0198] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the video recording and storage methods for a camera described in the above embodiments.

[0199] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially 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, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. 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 data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0200] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0201] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system and device embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0202] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A video recording and storage method for a camera, characterized in that, A management engine for a streaming application system, wherein the streaming application system further includes a streaming terminal; the method includes: In response to receiving an alarm event reported by the camera, the target time information for recording the event required for the alarm event is determined based on the target occurrence time of the alarm event; The system detects whether there are any streaming tasks that meet predetermined merging conditions. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task used to instruct the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time. If it exists, based on the target time information, update the time information in the task information of the existing streaming task to obtain the streaming task containing the alarm event; if it does not exist, based on the target time information, generate the streaming task corresponding to the alarm event. In addition, in response to the task execution time in the task information of any streaming task being reached, based on the time information in the task information of the streaming task, the streaming terminal extracts the stream from the camera to obtain the event recording of the alarm event corresponding to the streaming task.

2. The method according to claim 1, characterized in that, For any alarm event, the start time of the required event recording is earlier than the occurrence time of any alarm event and separated by a first time interval, and the end time is later than the occurrence time of any alarm event and separated by a second time interval; The methods for determining whether there is a temporal overlap between the event recordings required for the alarm event and the event recordings related to the corresponding alarm event include: Determine whether the time interval between the occurrence time of the specified alarm event and the occurrence time of the target is not greater than the target duration. If it is not greater, it is determined that there is a time overlap. The target duration is the sum of the durations of the first duration and the second duration; For any streaming task, if the streaming task corresponds to one alarm event, the designated alarm event corresponding to the streaming task is that one alarm event; if the streaming task corresponds to multiple consecutive alarm events, the designated alarm event corresponding to the streaming task is the latest alarm event among the multiple consecutive alarm events.

3. The method according to claim 1, characterized in that, The target time information includes the start time and end time; the time information in the task information of each streaming task includes the start time and end time. The step of updating the time information in the task information of existing streaming tasks based on the target time information to obtain the streaming tasks whose corresponding alarm events contain the alarm event includes: The end time in the target time information is used to update the end time in the task information of the existing streaming tasks, so as to obtain the streaming tasks that contain the corresponding alarm event.

4. The method according to any one of claims 1-3, characterized in that, In response to the task execution time in the task information of any streaming task, based on the time information in the task information of the streaming task, the streaming terminal extracts the stream from the camera to obtain the event recording of the alarm event corresponding to the streaming task, including: In response to the completion of any streaming task's execution time, a streaming request carrying the start time from the task information of the streaming task is sent to the streaming terminal. This causes the streaming terminal to respond to the streaming request by sending a start streaming instruction carrying the start time from the streaming request to the camera to start streaming from the camera. Furthermore, whenever the video data obtained from the camera meets the conditions for generating a video sub-file, a video sub-file is generated based on the obtained video data, and the video sub-file is stored. Additionally, an acknowledgment result is sent back to the management engine, carrying at least the metadata of the stored video sub-file. The metadata includes the end time of the video data used to generate the video sub-file. In response to the receipt result, the metadata in the receipt result is parsed as the metadata of the event recording of the alarm event corresponding to the streaming task, and it is determined whether the end time in the parsed metadata is not earlier than the end time in the task information of the streaming task. If so, a termination request corresponding to the streaming task is sent to the streaming terminal, so that the streaming terminal responds to the termination request and sends a stop streaming command to the camera.

5. The method according to claim 4, characterized in that, Each streaming task's task information also includes: at least one specified attribute, which includes one or more of the following: task status attribute, streaming progress attribute, error code attribute, and retry attribute; the error code attribute is used to characterize the error code that caused the streaming failure. The streaming terminal is also used to report an error code representing the reason for the streaming failure to the management engine in the event that streaming fails to be retrieved from the camera. After sending a streaming request carrying the start time from the task information of the streaming task to the streaming terminal, the method further includes: Based on the information fed back from the streaming terminal, the attribute value of the specified attribute of the streaming task that matches the information fed back from the streaming terminal is updated; wherein, the information fed back from the streaming terminal includes at least a receipt result or an error code.

6. The method according to claim 5, characterized in that, The at least one specified attribute includes a task status attribute, a streaming progress attribute, an error code attribute, and a retry attribute; the retry attribute is used to characterize the number of retries for the streaming task. The method further includes: After the task execution time in the task information of any streaming task is reached, monitor whether the attribute value of the error code attribute of the streaming task is one of the preset attribute values; wherein, the preset attribute values ​​include: a first attribute value for the failure of the streaming request to be sent by the streaming terminal, and a second attribute value for the failure of the streaming terminal to retrieve the stream. If the attribute value of the error code attribute of the streaming task is one of the preset attribute values, determine the exception handling strategy for the streaming task that matches the attribute value of the error code attribute. Implement the determined exception handling strategy; Among them, the exception handling strategy that matches the first attribute value is the first strategy, and the exception handling strategy that matches the second attribute value is the second strategy; the first strategy includes: resending the pull request to the stream-taking end; The second strategy includes: sending a retry request to the streaming terminal when the number of retries represented by the retry attribute value does not exceed a specified number, so as to trigger the streaming terminal to retry the streaming of the camera.

7. The method according to claim 6, characterized in that, Each preset attribute value also includes: a third attribute value indicating that the pull request has not been issued; The third strategy adapted to the third attribute value includes: if the number of streaming channels currently supported by the camera has not reached the maximum number of channels, resending the streaming request for the streaming task to the streaming terminal; Before sending a streaming request carrying the start time from the task information of the streaming task to the streaming terminal, the method further includes: Determine whether the number of streaming channels currently supported by the camera has not reached the maximum number of channels. If so, trigger the step of sending a streaming request to the streaming terminal carrying the start time of the streaming task in the task information. Otherwise, set the attribute value of the error code attribute of the streaming task to the third attribute value.

8. A video recording storage device for a camera, characterized in that, A management engine for a streaming application system, the streaming application system further including a streaming terminal; the device includes: The time information determination module is used to respond to an alarm event reported by the camera and determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event; The detection module is used to detect whether there is a streaming task that meets the predetermined merging conditions. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task that instructs the streaming terminal to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging conditions are: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time. The streaming task determination module is used to, if it exists, update the time information in the task information of the existing streaming task based on the target time information to obtain the streaming task that contains the alarm event corresponding to the alarm event; if it does not exist, generate the streaming task corresponding to the alarm event based on the target time information. The streaming module is used to respond to the task execution time in the task information of any streaming task, and based on the time information in the task information of the streaming task, to extract the stream from the camera through the streaming terminal to obtain the event recording of the alarm event corresponding to the streaming task.

9. A stream acquisition application system, characterized in that, include: Management engine and stream acquisition end; The management engine is used to respond to an alarm event reported by the camera and determine the target time information of the event recording required for the alarm event based on the target occurrence time of the alarm event; Check if there are any pull stream tasks that meet the predetermined merging conditions; If it exists, based on the target time information, update the time information in the task information of the existing streaming task to obtain the streaming task that contains the corresponding alarm event; If it does not exist, generate a streaming task corresponding to the alarm event based on the target time information; In addition, in response to the arrival of the task execution time of any streaming task, a request carrying the time information from the task information of the streaming task is sent to the streaming terminal. The streaming terminal is used to respond to a request issued by the management engine, and based on the time information in the task information of the streaming task, to retrieve the stream from the camera and obtain the event recording of the alarm event corresponding to the streaming task. Each streaming task corresponds to one or more consecutive alarm events, and each streaming task is a task used to instruct the streaming end to obtain an event recording of the corresponding alarm event from the camera. The task information of each streaming task includes the task execution time and the time information of the event recording of the corresponding alarm event. The predetermined merging condition is: the task has not been completed and the event recording required for the alarm event and the event recording of the corresponding alarm event overlap in time.

10. The flow extraction application system according to claim 9, characterized in that, The management engine is a first cloud server or management software set on the first cloud server, and correspondingly, the stream retrieval end is a second cloud server or a stream retrieval application set on the second cloud server. or, The management engine is a local management device or management software set on the local management device. Correspondingly, the stream acquisition end is a client device or a stream acquisition application set in the client device. The client device is a device with human-computer interaction function. or, The management engine is a first cloud server or management software set on the first cloud server, and correspondingly, the stream retrieval end is the client device or a stream retrieval application set in the client device.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images