Method and apparatus for switching video playing mode, electronic device and storage medium

Abstract

The present disclosure provides a video playing mode switching method and device, electronic equipment and storage medium, and the specific implementation scheme is: in response to a mode switching event, a mode switching request is sent to a video acquisition device to make the video acquisition device send target video data including a target video frame to a terminal device; using a live broadcast player, in a case where it is determined that the target video frame belongs to a video frame in a review mode, resources occupied by the live broadcast player are released; or, in a case where it is determined that the target video frame belongs to a video frame in a live broadcast mode, the target video frame is played; using a review player, in a case where it is determined that the target video frame belongs to a video frame in a live broadcast mode, resources occupied by the review player are released; or, in a case where it is determined that the target video frame belongs to a video frame in a review mode, the target video frame is played. The present disclosure can reduce the switching delay of the video playing mode, and at the same time, reduce the resource and memory occupation of the communication connection.

Description

Technical Field

[0001] This disclosure relates to the field of video surveillance technology, specifically to a method, apparatus, electronic device, and storage medium for switching video playback modes. Background Technology

[0002] With the rapid development of video surveillance technology, video capture devices have been widely used in everyday scenarios such as home security, elderly care, and pet monitoring. Users can communicate with the video capture devices through a monitoring application installed on their terminal devices to view live video feeds. Simultaneously, video capture devices are typically equipped with memory cards or support cloud storage services, enabling the storage of captured surveillance videos. This allows users to not only view live video feeds but also review historical recordings at any time via playback, meeting post-event tracing and evidence collection needs. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for switching video playback modes.

[0004] According to a first aspect of this disclosure, a method for switching video playback modes is provided, applied to a terminal device, the method comprising: In response to a mode switching event, a mode switching request is sent to the video capture device; wherein, after receiving the mode switching request, the video capture device sends target video data to the terminal device through the target link; the target link is a communication link shared by the live player and the playback player in the terminal device; the target video data includes target video frames; Using a live streaming player, if it is determined that the target video frame belongs to the playback mode, release the resources occupied by the live streaming player; or, if it is determined that the target video frame belongs to the live streaming mode, play the target video frame. Using the playback player, if it is determined that the target video frame belongs to the live streaming mode, release the resources occupied by the playback player; or, if it is determined that the target video frame belongs to the playback mode, play the target video frame.

[0005] According to a second aspect of this disclosure, a method for switching video playback modes is provided, applied to a video capture device, the method comprising: Receive mode switching requests sent by terminal devices; Based on the mode switching request, the target video data is obtained; the target video data includes the target video frames. The target video data is sent to the terminal device via the target link; wherein, the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the terminal device is used to: release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in playback mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in live streaming mode; and release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in live streaming mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in playback mode.

[0006] According to a third aspect of this disclosure, a video playback mode switching device is provided, applied to a terminal device, the device comprising: The request sending unit is used to send a mode switching request to the video acquisition device in response to a mode switching event; wherein, after receiving the mode switching request, the video acquisition device is used to send target video data to the terminal device through the target link; the target link is a communication link shared by the live player and the playback player in the terminal device; the target video data includes target video frames; The first playback execution unit is used to release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in the playback mode; or, when it is determined that the target video frame belongs to the video frame in the live streaming mode, play the target video frame. The second playback execution unit is used to release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in the live broadcast mode; or, when it is determined that the target video frame belongs to the video frame in the playback mode, play the target video frame.

[0007] According to a fourth aspect of this disclosure, a video playback mode switching device is provided, applied to a video acquisition device, the device comprising: The request receiving unit is used to receive mode switching requests sent by the terminal device. The data acquisition unit is used to acquire target video data based on the mode switching request; wherein, the target video data includes target video frames; The data transmission unit is used to send target video data to the terminal device via the target link; wherein the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the terminal device is used to: release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in playback mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in live streaming mode; and release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in live streaming mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in playback mode.

[0008] According to a fifth aspect of this disclosure, an electronic device is provided, comprising: At least one processor; Memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, which are executed by at least one processor to enable the at least one processor to perform the method provided in the first aspect of this disclosure.

[0009] According to a sixth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions; wherein the computer instructions are used to cause a computer to perform the method provided in the first aspect of this disclosure.

[0010] According to a seventh aspect of this disclosure, a computer program product is provided, including a computer program; wherein, when executed by a processor, the computer program is capable of implementing the method provided in the first aspect of this disclosure.

[0011] Using this disclosure can reduce the latency of switching video playback modes, while also reducing the resource and memory usage of communication connections.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A flowchart illustrating a video playback mode switching method (terminal device side) provided in an embodiment of this disclosure; Figure 2 A flowchart illustrating a method for switching video playback modes (on the video capture device side) provided in an embodiment of this disclosure; Figure 3A schematic diagram of the architecture of a dual-mode playback system for surveillance video provided in an embodiment of this disclosure; Figure 4 A complete flowchart illustrating a video playback mode switching method provided in this embodiment of the disclosure; Figure 5 for Figure 4 Flowchart of sub-step S403 Figure 1 ; Figure 6 for Figure 4 Flowchart of sub-step S403 Figure 2 ; Figure 7 for Figure 4 A flowchart illustrating the sub-steps of step S408; Figure 8 A schematic structural block diagram of a video playback mode switching device (terminal device side) provided in an embodiment of this disclosure; Figure 9 A schematic structural block diagram of a video playback mode switching device (video acquisition device side) provided for an embodiment of this disclosure; Figure 10 This is a schematic structural block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0014] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0015] As mentioned earlier, with the rapid development of video surveillance technology, video capture devices have been widely used in everyday scenarios such as home security, elderly care, and pet monitoring. Users can communicate with the video capture devices through a monitoring application (APP) installed on their terminal devices to achieve real-time live viewing of the surveillance videos. At the same time, video capture devices are usually equipped with memory cards or support cloud storage services, enabling them to store the captured surveillance videos. This allows users not only to watch the surveillance videos live but also to review historical recordings at any time through playback functions, meeting the needs for post-event tracing and evidence collection.

[0016] In practical applications, users can request to switch the playback mode of the surveillance video from live mode to playback mode, or vice versa, on their terminal devices based on their needs. However, the inventors have discovered the following technical problems with the traditional video playback mode switching methods: (1) Switching between live streaming mode and replay mode requires disconnection and reconnection of the communication link. Live streaming players and playback players are typically implemented based on independent player instances and connect to the video capture device using independent point-to-point (P2P) communication. When a user switches the playback mode of the surveillance video from live streaming mode to playback mode (or vice versa), the following steps need to be executed in sequence: disconnect the current player's P2P connection with the video capture device, release the current player's resources, establish a new player's P2P connection with the video capture device, initialize a new player instance, and wait for the first frame of the surveillance video to be rendered.

[0017] The above process will cause a 2-5 second delay in mode switching, resulting in a poor user experience.

[0018] (2) Complex player status management Live streaming and replay modes need to have different characteristics, as shown in Table 1: In traditional solutions, two separate player instances are used to handle the two video playback modes, resulting in redundant implementation of some player functions, complex state management, and high resource consumption.

[0019] (3) It is impossible to distinguish between live video frames and replay video frames on the same P2P connection. In traditional solutions, when attempting to transmit live video streams (which are real-time video streams) and replay video streams simultaneously using a single P2P connection, the lack of an effective frame-level differentiation mechanism leads to aliasing of live video frames and replay video frames. The player cannot correctly identify the type of video frame, which in turn causes problems such as timestamp confusion, progress calculation errors, screen flickering, or stuttering.

[0020] (4) Differentiate between live streaming mode and replay mode by timestamp range Traditional solutions have also proposed differentiating between live streaming and replay modes by setting a preset timestamp range. However, this approach requires pre-defining the timestamp range, resulting in poor flexibility and complex handling of edge cases.

[0021] (5) Mode switching depends on coordination by an external control module. In traditional solutions, switching between live streaming and playback modes relies on explicit coordination by an external control module. Specifically, when a user triggers a mode switching operation, the external control module needs to execute the following steps in sequence: instructing the current player to stop, releasing the current player's resources, initializing the target player, and instructing the target player to start receiving video frames. This centralized control solution has the following shortcomings: During mode switching, an external control module is needed to precisely coordinate the state transitions of each player. Improper coordination may result in video frame loss or abnormal player status. The external control module interacts with the player multiple times, increasing the switching delay. The player cannot autonomously perceive changes in video frame patterns; it can only passively accept external commands.

[0022] In summary, the traditional solutions and their problems are shown in Table 2: Therefore, the technical problems to be solved by the embodiments of this disclosure include at least one of the following: How to achieve seamless switching between live streaming and replay modes on a single P2P connection, avoiding disconnection and reconnection, and reducing switching latency; How to ensure that video frames in two video playback modes are correctly isolated at the frame level and do not interfere with each other; How can a player be made to automatically detect frame mode changes and switch modes automatically, without relying on explicit coordination from external control modules, simply by using frame-level mode identifiers?

[0023] Based on this, this disclosure provides a method for switching video playback modes, which can be applied to terminal devices. The terminal device can be a workbench, mainframe computer, conventional computer (desktop computer, laptop computer, etc.), in-vehicle computer, mobile terminal (tablet computer, smartphone, etc.), or other similar computing devices. Before describing the method for switching video playback modes provided in this disclosure, some terms that may be used below are explained: Mode identifier: Identification information for video frames, used to distinguish between live video frames and playback video frames at the frame level, determined by a combination of frame-level mode flag bits and absolute capture time field; Frame-level mode flag: A flag used to identify whether a video frame belongs to a live video frame or a replay video frame. Specifically, when it takes the first value (e.g., false), it indicates that the frame belongs to a live video frame; when it takes the second value (e.g., true), it indicates that the frame belongs to a replay video frame. Absolute capture time field: This field records the absolute capture time (in milliseconds) of a video frame. Typically, the value of this field (i.e., the absolute capture time) for live video frames is less than or equal to a preset threshold; for playback video frames, the value of this field (i.e., the absolute capture time) is greater than the preset threshold and is used to characterize the actual capture time of the playback video frame. Preset threshold: The threshold used to distinguish between live video frames and playback video frames in the absolute capture time field, which is fixed at 0; Live streaming mode: This mode transmits the video stream currently being captured by the video capture device in real time. It does not support pause, progress skipping, or playback speed adjustment. Playback mode: Playback mode for historical recordings stored on a storage card or cloud server used to provide cloud storage services, supporting pause, progress jump and speed adjustment; Automatic release: When the player receives a video frame of a different mode (for example, the live player receives a video frame belonging to the playback mode; the playback player receives a video frame belonging to the live mode), it automatically releases resources and stops receiving video frames without the need for external control module coordination. P2P connection: A communication link established between a monitoring APP installed on a terminal device and a video acquisition device, used to transmit video frames and control signals; Timestamp Mapping Table: A data structure that uses camera identifiers as keys and the absolute capture time field of video frames as values, serving progress management in multi-camera scenarios; Camera Identifier: A unique identifier used to distinguish different cameras on the same video capture device. Each camera's video frame is independently marked with a pattern identifier. Rendering pipeline: The process of receiving video frames and playing them (i.e., displaying them), including decoding, format conversion, and rendering. Decentralized switching: The player automatically switches modes using only frame-level mode identifiers, without the need for external control modules to coordinate the switching.

[0024] The following will combine Figure 1 The flowchart shown illustrates the video playback mode switching method provided in this embodiment. It should be noted that, although in Figure 1 The flowchart shows a logical order, but in some cases, the steps shown or described may be performed in a different order.

[0025] Step S101: In response to the mode switching event, a mode switching request is sent to the video acquisition device.

[0026] The mode switching event can be a user operation event; the video acquisition device can be an Internet of Things (IoT) device equipped with one or more cameras; the mode switching request can be a first mode switching request or a second mode switching request. Here, the first mode switching request is used to request switching the playback mode of the surveillance video from live mode to playback mode; the second mode switching request is used to request switching the playback mode of the surveillance video from playback mode to live mode.

[0027] In this embodiment, after receiving a mode switching request, the video acquisition device can send target video data to the terminal device via a target link. The target link can be a communication link shared by the live streaming player and the playback player on the terminal device; that is, the live streaming player and the playback player can jointly monitor the target link, and the target link will always maintain a "keep connected, uninterrupted" state during the video playback mode switching process. Here, the target link can be a P2P communication link, that is, a communication link established based on P2P communication.

[0028] In this embodiment of the disclosure, the target video data may include target video frames, and the target video frames may be video frames in live mode (i.e., live video frames) or video frames in replay mode (i.e., replay video frames). Based on this, it can be understood that in this embodiment of the disclosure, when the mode switching request received by the video acquisition device is a first mode switching request, the target video frames included in the target video data sent to the terminal device through the target link are replay video frames; when the mode switching request received by the video acquisition device is a second mode switching request, the target video frames included in the target video data sent to the terminal device through the target link are live video frames.

[0029] Step S102: Using the live streaming player, if it is determined that the target video frame belongs to the video frame in playback mode, release the resources occupied by the live streaming player; or, if it is determined that the target video frame belongs to the video frame in live streaming mode, play the target video frame.

[0030] The resources used by the live streaming player can be the hardware and software resources required for the live streaming player to run.

[0031] In this embodiment of the disclosure, when it is determined that the target video frame belongs to the video frame in playback mode, after releasing the resources occupied by the live streaming player, the live streaming player will stop receiving subsequent video data; when it is determined that the target video frame belongs to the video frame in live streaming mode, the target video frame can be input into the rendering pipeline of the live streaming player to render the target video frame and realize the playback of the target video frame.

[0032] Step S103: Using the playback player, if it is determined that the target video frame belongs to the video frame in live mode, release the resources occupied by the playback player; or, if it is determined that the target video frame belongs to the video frame in playback mode, play the target video frame.

[0033] The resources used by the playback player can be the hardware and software resources required for its operation.

[0034] In this embodiment of the disclosure, when it is determined that the target video frame belongs to the video frame in the live broadcast mode, after releasing the resources occupied by the playback player, the playback player will stop receiving subsequent video data; when it is determined that the target video frame belongs to the video frame in the playback mode, the target video frame can be input into the rendering pipeline of the playback player to render the target video frame and realize the playback of the target video frame.

[0035] The video playback mode switching method provided in this disclosure can, in response to a mode switching event, send a mode switching request to the video acquisition device. Upon receiving the request, the video acquisition device sends target video data, including the target video frame, to the terminal device via the target link. Then, using the live streaming player, if it is determined that the target video frame belongs to the playback mode, it releases the resources occupied by the live streaming player; or, if it is determined that the target video frame belongs to the live streaming mode, it plays the target video frame. Similarly, using the playback player, if it is determined that the target video frame belongs to the live streaming mode, it releases the resources occupied by the playback player; or, if it is determined that the target video frame belongs to the playback mode, it plays the target video frame. The target link is a communication link shared by the live streaming player and the playback player in the terminal device. Thus, the video playback mode switching method provided in this disclosure can achieve at least the following effects: (1) Achieve seamless switching between live streaming mode and replay mode.

[0036] Since the target link (e.g., a P2P communication link) is a shared communication link between the live streaming player and the playback player, and the target link always maintains a "keep connected, uninterrupted" state during the switching of video playback modes, the switching delay caused by "disconnecting the current P2P connection and re-establishing a new P2P connection" in traditional solutions is avoided. Compared to the 2-5 second switching delay in traditional solutions, the video playback mode switching method provided in this disclosure can reduce the video playback mode switching delay to the millisecond level, significantly improving the user experience.

[0037] (2) Save communication connection resources and network bandwidth resources.

[0038] In traditional dual-connection schemes, live streaming and playback modes each use independent P2P connections, requiring the maintenance of multiple communication links between the terminal device and the video acquisition device, thus consuming additional network port and bandwidth resources. In this embodiment, the live streaming player and playback player share a single target link, meaning that both video playback modes can be supported simultaneously on a single communication link, reducing the resource and memory consumption of communication connections.

[0039] (3) Decentralized frame-driven automatic switching is implemented.

[0040] Both the live streaming player and the playback player autonomously determine whether the current video playback mode is live or playback mode based on the received target video frames, and automatically perform resource release or video playback operations accordingly. This process eliminates the need for explicit coordination and multiple interactions from external control modules, avoiding the complexity of state management and switching latency issues caused by the complex coordination steps required by traditional centralized control schemes, such as "notifying the current player to stop, releasing the current player's resources, initializing the target player, and notifying the target player to start receiving." This enables the player to autonomously perceive and automatically respond to frame mode changes, further reducing video playback mode switching latency and improving the user experience.

[0041] As previously described, in this embodiment of the disclosure, the mode switching event can be a user operation event. In this embodiment, the user operation event can be a first mode switching operation instructing the video playback mode to switch from live mode to playback mode, or a second mode switching operation instructing the video playback mode to switch from playback mode to live mode. Both the first and second mode switching operations can be triggered by the user.

[0042] In this embodiment of the disclosure, when the mode switching event is a first mode switching operation used to indicate switching the video playback mode from live mode to playback mode, step S101, that is, "sending a mode switching request to the video acquisition device in response to the mode switching event", may include: In response to the first mode switching operation, obtain the first switching information; Generate a mode switching request carrying the first switching information; Send a mode switching request to the video capture device.

[0043] The first switching information can be the switching information entered and / or selected by the user when triggering the first mode switching operation. Specifically, it can include at least one of the following: device identifier, camera identifier, playback start time, and playback end time. Here, the device identifier can be a unique identifier used to distinguish different video capture devices; the camera identifier can be a unique identifier used to distinguish different cameras on the same video capture device; the playback start time can represent the start time of the historical video segment that the user wants to view, so as to instruct the video capture device to start reading and sending playback video frames to the terminal device from that time; the playback end time can represent the end time of the historical video segment that the user wants to view, so as to instruct the video capture device to stop reading and transmitting playback video frames at that time.

[0044] It is understood that in this embodiment of the disclosure, the first switching information is obtained in response to the first mode switching operation, and the generated mode switching request carrying the first switching information is the first mode switching request, which is used to request the playback mode of the monitoring video to be switched from live mode to replay mode.

[0045] In this embodiment of the present disclosure, in response to a first mode switching operation, first switching information can be obtained, and a mode switching request carrying the first switching information can be generated. Then, the mode switching request is sent to the video acquisition device. Thus, when a user wants to switch the playback mode of the surveillance video from live mode to playback mode, the user can input or select the time interval information (i.e., playback start time to playback end time) of the desired historical recording segment through the terminal device. The terminal device carries the device identifier, camera identifier, and the time interval information in the mode switching request and sends it to the video acquisition device. This allows the video acquisition device to accurately locate and read the desired historical recording segment (including multiple playback video frames) from the video acquisition device's storage card or cloud server based on the device identifier, camera identifier, and the time interval information, and send it to the terminal device. This avoids invalid transmission of the entire historical recording, reduces communication bandwidth usage and the receiving and processing pressure on the terminal device, and enables the user to accurately playback historical recording segments at any historical time point.

[0046] In this embodiment of the disclosure, when the mode switching event is a second mode switching operation used to indicate switching the video playback mode from playback mode to live mode, step S101, that is, "sending a mode switching request to the video acquisition device in response to the mode switching event", may include: In response to the second mode switching operation, obtain the second switching information; Generate a mode switching request carrying the second switching information; Send a mode switching request to the video capture device.

[0047] The second switching information may include device identifier and / or camera identifier.

[0048] The second switching information can be the switching information entered and / or selected by the user when triggering the second mode switching operation, specifically including device identifier and / or camera identifier. Here, the device identifier can be a unique identifier used to distinguish different video acquisition devices; the camera identifier can be a unique identifier used to distinguish different cameras on the same video acquisition device.

[0049] It is understood that in this embodiment of the disclosure, in response to the second mode switching operation, the second switching information is obtained and the generated mode switching request carrying the second switching information is the second mode switching request, which is used to request the playback mode of the monitoring video to be switched from the playback mode to the live mode.

[0050] In this embodiment of the present disclosure, in response to a second mode switching operation, second switching information can be obtained, and a mode switching request carrying the second switching information can be generated. This request is then sent to the video acquisition device. Thus, when a user wishes to switch the playback mode of the surveillance video from playback mode to live mode and vice versa, the terminal device does not need to carry time parameters such as playback start time and playback end time. It only needs to send a mode switching request, including the device identifier and / or camera identifier, to the video acquisition device. This controls the video acquisition device to stop reading historical recording segments from its storage card or cloud server and switch to acquiring and transmitting the live video stream (including multiple live video frames). This achieves a rapid switch from playback mode to live mode, ensuring that the user can obtain real-time monitoring footage promptly.

[0051] In this embodiment of the disclosure, the mode switching event can be, in addition to the first mode switching operation and the second mode switching operation, a live broadcast confirmation operation or a replay confirmation operation for an abnormal event. That is, in this embodiment of the disclosure, the mode switching event can be at least one of the first mode switching operation, the second mode switching operation, the live broadcast confirmation operation for an abnormal event, and the replay confirmation operation for an abnormal event. The abnormal event can be, for example, unauthorized intrusion, smoke or fire, an elderly person falling, a baby crying continuously, or a pet exhibiting unusual agitation.

[0052] Based on this, it is understood that in this embodiment of the disclosure, when the video capture device is capturing a live video stream in real time, it can obtain anomaly detection results for the live video stream and store them together with the live video stream on the storage card of the video capture device or a cloud server. The anomaly detection results are used to characterize whether any abnormal events have occurred. These results can be obtained by analyzing the live video stream using the video capture device or the cloud server. Specifically, at least one of image recognition technology, motion detection technology, and sound detection technology can be used to analyze the live video stream. The live video stream stored on the storage card of the video capture device or the cloud server can be used as a playback video stream for users to review.

[0053] In some possible scenarios, when the current playback mode is replay mode and an abnormal event is detected based on real-time anomaly detection results, the video capture device can automatically generate a live notification of the abnormal event and send it to the terminal device via the target link. After receiving and displaying the live notification, the terminal device can send a second mode switching request to the video capture device if it detects a user-triggered live confirmation operation for the abnormal event, in order to request that the playback mode of the monitoring video be switched from replay mode to live mode. If no user-triggered live confirmation operation for the abnormal event is detected, the live notification of the abnormal event is ignored, and the replay mode is maintained.

[0054] In other words, in this embodiment of the present disclosure, the terminal device can automatically send a second mode switching request to the video acquisition device when it receives a live broadcast notification of an abnormal event and detects a live broadcast confirmation operation triggered by the user for the abnormal event. This request is used to switch the playback mode of the monitoring video from the playback mode to the live broadcast mode, thereby ensuring that the user can view the abnormal monitoring screen as soon as possible and avoid missing the abnormal event that is happening because the user is watching the historical recording. This improves the real-time response capability and security in daily scenarios such as home security, elderly care, and pet monitoring.

[0055] In other possible scenarios, when the current playback mode is live (e.g., the user has just opened the monitoring app) and the video capture device's storage card or cloud server stores a playback video stream corresponding to the abnormal event that has not been viewed by the user, the video capture device can automatically generate an abnormal event playback notification and send it to the terminal device via the target link. After receiving and displaying the abnormal event playback notification, the terminal device can send a first mode switching request to the video capture device if it detects a user-triggered playback confirmation operation for the abnormal event. This request is used to switch the playback mode of the monitoring video from live mode to playback mode, and to set the playback start time to the occurrence time of the abnormal event and the playback end time to the end time of the abnormal event. If no user-triggered playback confirmation operation for the abnormal event is detected, the abnormal event playback notification is ignored, and the live mode continues.

[0056] In other words, in this embodiment of the present disclosure, the terminal device can also automatically send a first mode switching request to the video acquisition device when it receives an abnormal event playback notification and detects a user-triggered playback confirmation operation for the abnormal event. This request is used to switch the playback mode of the monitoring video from live mode to playback mode, and to set the playback start time to the occurrence time of the abnormal event and the playback end time to the end time of the abnormal event. This allows users to quickly playback missed abnormal event recordings with a single confirmation operation without having to manually search through lengthy historical recordings, thus avoiding users missing historical abnormal events and improving the viewing efficiency and user experience of key recordings.

[0057] In summary, through the bidirectional automatic switching prompt mechanism driven by abnormal events in this embodiment, regardless of whether the current playback mode is live or replay mode, users can quickly obtain key video content by confirming the event when or after an abnormal event occurs, thereby improving the intelligence level and human-computer interaction efficiency of the monitoring APP.

[0058] In this embodiment of the disclosure, after the video acquisition device receives a mode switching request, it can acquire target video data based on the mode switching request and send the target video data to the terminal device through the target link. As mentioned above, in this embodiment of the disclosure, the target video data may include target video frames, and the target video frames belong to video frames in live mode (i.e., live video frames) or video frames in playback mode (i.e., playback video frames).

[0059] Based on this, in this embodiment of the disclosure, "obtaining target video data based on a mode switching request" may include: When the mode switching request is used to request the video playback mode to be switched from live mode to playback mode (that is, the mode switching request is the first mode switching request), the target playback video frame is obtained as the target video frame. Generate a playback mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp for the target video frame that meets the time requirements of the playback mode; Generate target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0060] As previously stated, in this embodiment of the disclosure, the first mode switching request may carry a device identifier, a camera identifier, a playback start time, and a playback end time.

[0061] Based on this, in this embodiment of the disclosure, when the identification information of the video acquisition device is consistent with the device identification, multiple target playback video frames can be determined based on the camera identification, playback start time, and playback end time, and these multiple target playback video frames can be sequentially used as target video frames. Subsequently, for each of the multiple target video frames, a playback mode flag is generated as a frame-level mode flag corresponding to that target video frame, and an absolute time flag for that target video frame that meets the playback mode time requirements is generated. Finally, target video data carrying the target video frame, the frame-level mode flag, and the absolute time flag is generated.

[0062] The playback mode flag can be a second value (e.g., true), which is used as the frame-level mode flag corresponding to the target video frame, and is the value of the frame-level mode flag bit in the target video data; the playback mode time requirement can be greater than a preset threshold (e.g., 0); the absolute time flag can be the actual acquisition time of the target video frame, which will be used as the value of the absolute capture time field in the target video data.

[0063] Correspondingly, in this embodiment of the disclosure, "obtaining target video data based on a mode switching request" may also include: When the mode switching request is used to request the video playback mode to be switched from playback mode to live mode (that is, the mode switching request is the second mode switching request), the target live video frame is obtained as the target video frame. Generate a live streaming mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp for the target video frame that meets the time requirements of the live streaming mode; Generate target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0064] As previously stated, in this embodiment of the disclosure, the second mode switching request may carry a device identifier and a camera identifier.

[0065] Based on this, in this embodiment of the disclosure, the target live video frame can be determined based on the camera identifier when the identification information of the video acquisition device matches the device identifier. Since the target live video frame is constantly updated, each new target live video frame is used as the target video frame, and a live mode flag is generated as a frame-level mode flag corresponding to the target video frame. An absolute time flag for the target video frame that meets the live mode time requirements is also generated, and target video data carrying the target video frame, frame-level mode flag, and absolute time flag is generated.

[0066] The live streaming mode flag can be a first value (e.g., false), and the frame-level mode flag corresponding to the target video frame is the value of the frame-level mode flag bit in the target video data. The live streaming mode time requirement can be less than or equal to a preset threshold (e.g., 0). Therefore, when the target live streaming video frame is used as the target video frame, the absolute time flag for the target video frame can be uniformly set to 0, which will be the value of the absolute capture time field in the target video data.

[0067] In summary, in this embodiment of the disclosure, the target video data may carry: (1) Image data buffer, used to carry image data in luminance-chrominance color space (YUV) or red-green-blue color space (RGB), that is, the target video frame; (2) Rotation angle field, used to indicate the rotation direction of the target video frame; (3) Frame-level mode flags; (4) Absolute time markers; (5) Acquisition time field, used to record the actual acquisition time of video frames (nanosecond level), serving frame rendering synchronization, etc.; (6) Camera identification.

[0068] Furthermore, in this embodiment of the disclosure, after the video acquisition device obtains the target video data based on the mode switching request, it will send the target video data to the terminal device through the target link. As mentioned above, in this embodiment of the disclosure, the target link can be a communication link shared by the live streaming player and the playback player in the terminal device. The live streaming player and the playback player have independent frame filtering logic and playback status management. Live Streaming Player: Features frame filtering to filter playback video frames, enabling live streaming mode characteristics (does not support pause / resume, progress jump, or speed adjustment; no total duration or progress management), and automatically releases resources when playback video frames are received. Playback Player: Features frame filtering to filter live video frames, enabling playback mode (supports pause / resume, progress jump, and speed adjustment, with total duration and progress management), and automatically releases resources when receiving live video frames.

[0069] It should be noted that in this embodiment, both the live streaming player and the replay player inherit from the player base class. That is, the player base class is the parent class of both the live streaming player and the replay player, used to provide shared functionality between the live streaming player and the replay player. Specifically, it may include at least one of the following: Device Identifier Matching: When receiving a video frame, determine whether the device identifier of the video frame matches the identifier information of the video capture device associated with the current player; if they do not match, discard the frame. Maintenance of the timestamp mapping table: Maintain a timestamp mapping table with the camera identifier as the key. When each video frame arrives, automatically update the value of the absolute capture time field of the corresponding camera identifier. Render view management: Maintains a set of render views and distributes video frames to the corresponding render views for display based on the camera identifier of the video frame; First Frame Event Notification: Record the time consumed when rendering the first video frame for statistical purposes regarding the display time of the first video frame.

[0070] Through the above methods, in this embodiment of the disclosure, a dual-mode playback system including a live player and a playback player can be constructed by inheriting a player base class. While utilizing the player base class to provide shared functions for both the live player and the playback player, the live player and the playback player also have independent frame filtering logic and playback state management. On the one hand, since the player base class can provide shared functions for both the live player and the playback player, these shared functions do not need to be implemented repeatedly. When adding or modifying shared functions, only one modification needs to be made in the player base class, thereby reducing code redundancy caused by repeated development of functions and reducing the complexity of development and maintenance of the monitoring APP. On the other hand, the live player and the playback player independently maintain their own frame filtering logic and playback state management, so that the live mode and the playback mode can maintain their own unique mode characteristics while sharing the underlying basic capabilities. This achieves the architectural design of "reusing common functions and isolating characteristic functions," avoiding the problems of chaotic playback state management and duplicate function implementation caused by the completely independent implementation of two players in the traditional dual-player solution.

[0071] Based on the above settings, in this embodiment of the disclosure, after the live streaming player receives the target video data based on the target link shared by it and the playback player, it can determine whether the target video frame belongs to the playback mode or the live streaming mode based on the mode identifier (including the frame-level mode flag and the absolute time flag) carried in the target video data.

[0072] Therefore, step S102, "releasing the resources occupied by the live stream player when it is determined that the target video frame belongs to the video frame in playback mode," may include: Extract frame-level mode flags from the target video data; When the frame-level mode flag is set to playback mode, the target video frame is determined to be a video frame in playback mode, and the resources occupied by the live stream player are released.

[0073] As previously stated, in this embodiment of the disclosure, the playback mode flag can be a second value (e.g., true).

[0074] In this embodiment of the disclosure, step S102, "releasing the resources occupied by the live stream player when it is determined that the target video frame belongs to the video frame in playback mode," may further include: Extract the absolute time flag from the target video data when the frame-level mode flag is not the lookback mode flag. If the absolute time stamp meets the time requirements of the playback mode, determine that the target video frame belongs to the video frame in the playback mode, and release the resources occupied by the live stream player.

[0075] As previously stated, in this embodiment of the disclosure, the absolute time stamp can characterize the absolute acquisition time of the target video frame; the playback mode time requirement can be greater than a preset threshold (e.g., 0).

[0076] In this embodiment of the disclosure, after releasing the resources occupied by the live streaming player, the live streaming player will stop receiving subsequent video data. The resources occupied by the live streaming player can be the hardware and software resources required for its operation, such as video information timers (used for stability detection of video frame rates) and monitoring registration resources for the target link.

[0077] Furthermore, in this embodiment of the present disclosure, the step S102 of "playing the target video frame when it is determined that the target video frame belongs to the video frame in the live broadcast mode" can be: when the absolute time stamp does not meet the time requirements of the playback mode, determine that the target video frame belongs to the video frame in the live broadcast mode and play the target video frame. Specifically, the target video frame can be input into the rendering pipeline of the live broadcast player to render the target video frame and realize the playback of the target video frame.

[0078] Similarly, based on the above settings, in this embodiment of the present disclosure, after the playback player receives the target video data based on the target link shared with the live player, it can determine whether the target video frame belongs to the live mode or the playback mode based on the mode identifier (including frame-level mode flag and absolute time flag) carried in the target video data.

[0079] Therefore, step S103, "releasing the resources occupied by the playback player when it is determined that the target video frame belongs to the live video frame mode," may include: Extract frame-level mode flags from the target video data; When the frame-level mode flag is set to live mode, the target video frame is determined to be a video frame in live mode, and the resources occupied by the playback player are released.

[0080] As previously stated, in this embodiment of the disclosure, the live streaming mode flag can be a first value (e.g., false).

[0081] In this embodiment of the disclosure, step S103, "releasing the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in live broadcast mode," may further include: When the frame-level mode flag is not the live mode flag, extract the absolute time flag from the target video data; If the absolute time stamp meets the time requirements of the live streaming mode, determine that the target video frame belongs to the live streaming mode and release the resources occupied by the playback player.

[0082] As previously stated, in this embodiment of the disclosure, the absolute time stamp is used to characterize the absolute acquisition time of the target video frame; the live streaming mode time requirement may be less than or equal to a preset threshold (e.g., 0).

[0083] In this embodiment of the disclosure, after releasing the resources occupied by the playback player, the playback player will stop receiving subsequent video data. The resources occupied by the playback player can be the hardware and software resources required for its operation, such as a progress timer (used to periodically report playback progress to the application layer) and monitoring registration resources for the target link.

[0084] Furthermore, in this embodiment of the present disclosure, the step S103 of "playing the target video frame when it is determined that the target video frame belongs to the video frame in the playback mode" can be: when the absolute time stamp does not meet the time requirements of the live broadcast mode, determine that the target video frame belongs to the video frame in the playback mode and play the target video frame. Specifically, the target video frame can be input into the rendering pipeline of the playback player to render the target video frame and realize the playback of the target video frame.

[0085] In summary, in this embodiment of the present disclosure, after the live streaming player receives the target video data by monitoring the target link, it can extract a frame-level mode flag from the target video data. If the frame-level mode flag is a playback mode flag, it determines that the target video frame belongs to the video frame in playback mode and releases the resources occupied by the live streaming player. Alternatively, if the frame-level mode flag is not a playback mode flag, it can extract an absolute time flag from the target video data. If the absolute time flag meets the playback mode time requirements, it determines that the target video frame belongs to the video frame in playback mode and releases the resources occupied by the live streaming player. Or, if the absolute time flag does not meet the playback mode time requirements, it determines that the target video frame belongs to the video frame in live streaming mode and plays the target video frame. After the playback player receives the target video data by monitoring the target link, it can extract the frame-level mode flag from the target video data. If the frame-level mode flag is a live mode flag, it determines that the target video frame belongs to the live mode video frame and releases the resources occupied by the playback player. Alternatively, if the frame-level mode flag is not a live mode flag, it can extract the absolute time flag from the target video data. If the absolute time flag meets the live mode time requirements, it determines that the target video frame belongs to the live mode video frame and releases the resources occupied by the playback player. Or, if the absolute time flag does not meet the live mode time requirements, it determines that the target video frame belongs to the playback mode video frame and plays the target video frame.

[0086] In other words, in this embodiment of the present disclosure, frame-level mode isolation can be achieved through a dual combination of frame-level mode flag and absolute time flag. This ensures that video frames of the two video playback modes can be accurately distinguished and do not interfere with each other when transmitted through a shared target link. This avoids problems such as timestamp confusion, progress calculation errors, screen flickering, or stuttering caused by the aliasing of live video frames and playback video frames in traditional solutions. Moreover, due to the dual judgment logic of prioritizing the frame-level mode flag and assisting with the absolute time flag, even in extreme cases where a single flag deviates due to abnormal network transmission or encoder status (e.g., the frame-level mode flag is read incorrectly due to data packet corruption), the player can still perform cross-verification by combining the other flag. This effectively avoids mode switching errors or resource release errors caused by misjudgment of a single flag, greatly improving the accuracy of frame mode recognition and system robustness.

[0087] Furthermore, in this embodiment of the disclosure, "determining that the target video frame belongs to the video frame in the replay mode and playing the target video frame when the absolute time stamp does not meet the time requirements of the live broadcast mode" may include: If the absolute time stamp does not meet the time requirements of the live streaming mode, determine that the target video frame belongs to the video frame in the playback mode, and extract the camera identifier from the target video data. Based on the absolute time stamp, determine the playback progress corresponding to the camera identifier; Play the target video frame and display the playback progress.

[0088] In some alternative implementations, "determining the playback progress corresponding to the camera identifier based on an absolute time stamp" may include: In the timestamp mapping table, the historical timestamp corresponding to the camera identifier is updated to an absolute time flag to obtain the current timestamp corresponding to the camera identifier; Create a scheduled progress reporting task using the camera identifier as the key; Execute a scheduled progress reporting task to extract the current timestamp corresponding to the camera identifier from the timestamp mapping table according to a preset time period; Based on the current timestamp corresponding to the camera identifier, and the playback start time and playback end time extracted from the target video data, the playback progress corresponding to the camera identifier is determined.

[0089] In practice, the player base class can be used to update the historical timestamps corresponding to the camera identifiers to absolute timestamps in the timestamp mapping table to obtain the current timestamps corresponding to the camera identifiers. Subsequently, a timed progress reporting task is created with the camera identifier as the key. This task periodically (i.e., according to a preset time period, which can be every 1 second) extracts the current timestamps corresponding to the camera identifiers from the timestamp mapping table. Based on the current timestamps corresponding to the camera identifiers, and the playback start and end times extracted from the target video data, the playback progress corresponding to the camera identifier is determined.

[0090] After determining the playback progress corresponding to the camera identifier based on the absolute time stamp, the playback progress can be displayed synchronously when playing the target video frame.

[0091] In this embodiment, by means of the above method, even when the absolute timestamp does not meet the time requirements of the live streaming mode, it can determine that the target video frame belongs to the playback mode, extract the camera identifier from the target video data, determine the playback progress corresponding to the camera identifier based on the absolute timestamp, play the target video frame, and display the playback progress. In other words, in this embodiment, the playback player can use the absolute timestamp carried by the playback video frame itself as the reference time for the progress, achieving accurate playback progress calculation and display without relying on external time synchronization or additional timestamp mapping protocols.

[0092] Furthermore, it should be noted that in this embodiment of the present disclosure, when the user initiates a progress jump operation, the playback player can calculate the offset (that is, the time difference between the start playback position and the playback start time) based on the start playback position indicated by the progress jump operation, and calculate the target acquisition time (that is, the playback start time plus the offset) based on the offset, and then send a playback request carrying the target acquisition time, playback end time and offset to the video acquisition device.

[0093] The target acquisition time serves as the starting boundary of the time range for this playback jump, instructing the video capture device to jump to that time point and begin reading and transmitting playback video frames until the playback ends. This ensures that the video capture device only transmits historical recording data within the user-specified time interval, eliminating the need to send other historical recording data that the user is not interested in to the terminal device, thus reducing communication bandwidth waste caused by invalid data transmission. Simultaneously, the target acquisition time can serve as a data stream verification basis, ensuring that the first frame data read by the video capture device matches the user-indicated starting playback position. If there is a deviation, fine-tuning is performed to guarantee positioning accuracy. The offset is used to assist video acquisition... The video capture device can quickly locate target data in the memory card or cloud server. For example, when the video file uses constant bitrate encoding, the video capture device can directly calculate the byte offset position of the starting playback position in the video file based on the offset, realizing direct jump of the file pointer. When using variable bitrate encoding, the offset can be used as an index lookup key to quickly query the corresponding frame position or byte offset in the video file index table. This allows the video capture device to jump to the vicinity of the starting playback position without having to traverse the video file header one by one or scan the timestamp frame by frame. This reduces the addressing overhead of the memory card and the file system parsing time, and further reduces the response latency of reading historical video data.

[0094] This disclosure provides a method for switching video playback modes, which can be applied to video capture devices. As mentioned above, in this disclosure, the video capture device can be an IoT device equipped with one or more cameras. The following will be combined with... Figure 2 The flowchart shown illustrates the video playback mode switching method provided in this embodiment. It should be noted that, although in Figure 2 The flowchart shows a logical order, but in some cases, the steps shown or described may be performed in a different order.

[0095] Step S201: Receive a mode switching request sent by the terminal device.

[0096] The mode switching request can be either a first mode switching request or a second mode switching request. Here, the first mode switching request is used to request switching the playback mode of the surveillance video from live mode to playback mode; the second mode switching request is used to request switching the playback mode of the surveillance video from playback mode to live mode.

[0097] Step S202: Based on the mode switching request, obtain the target video data.

[0098] The target video data may include target video frames, and the target video frames may be video frames in live mode (i.e., live video frames) or video frames in replay mode (i.e., replay video frames).

[0099] Step S203: Send target video data to the terminal device through the target link.

[0100] The target link can be a communication link shared by the live streaming player and the playback player in the terminal device. That is, the live streaming player and the playback player can listen to the target link together, and the target link will always maintain a "keep connected, uninterrupted" state during the switching of video playback modes. Here, the target link can be a P2P communication link, that is, a communication link established based on the P2P communication method.

[0101] In this embodiment of the disclosure, when the mode switching request received by the video acquisition device is a first mode switching request, the target video frames included in the target video data sent to the terminal device through the target link are playback video frames; when the mode switching request received by the video acquisition device is a second mode switching request, the target video frames included in the target video data sent to the terminal device through the target link are live video frames.

[0102] Furthermore, in this embodiment of the disclosure, the terminal device can be used to: release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in the playback mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in the live streaming mode; release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in the live streaming mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in the playback mode. The resources occupied by the live streaming player can be the hardware and software resources required for the operation of the live streaming player; the resources occupied by the playback player can be the hardware and software resources required for the operation of the playback player.

[0103] In some optional implementations, step S202, namely, "obtaining target video data based on mode switching request", may include: When the mode switching request is used to request the video playback mode to be switched from live mode to playback mode, the target playback video frame is obtained as the target video frame. Generate a playback mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp that meets the time requirements of the playback mode; Generate target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0104] For the specific functions and examples of the above steps, please refer to the relevant descriptions in the aforementioned embodiments of the video playback mode switching method applied to terminal devices, which will not be repeated here.

[0105] In some optional implementations, step S202, namely, "obtaining target video data based on mode switching request", may also include: When the mode switching request is used to request switching the video playback mode from playback mode to live mode, the target live video frame is obtained as the target video frame. Generate a live streaming mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp that meets the time requirements of the live streaming mode; Generate target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0106] For the specific functions and examples of the above steps, please refer to the relevant descriptions in the aforementioned embodiments of the video playback mode switching method applied to terminal devices, which will not be repeated here.

[0107] The following, combined with Figure 3 This paper describes the architecture of a dual-mode playback system for surveillance video provided in an embodiment of the present disclosure.

[0108] In this embodiment of the disclosure, the dual-mode playback system, from top to bottom, may include: (1) Application layer: includes live page, replay page and switching control module, which are responsible for displaying live video frames, displaying replay video frames, and providing users with the ability to trigger mode switching operations, such as first mode switching operation, second mode switching operation, live confirmation operation for abnormal events or replay confirmation operation for abnormal events.

[0109] (2) Player management layer: including live player, replay player and player base class.

[0110] The live streaming player is used to implement frame filtering logic, live streaming features, and an automatic release mechanism; The playback player is used to implement frame filtering logic, playback features, automatic release mechanism, and progress management. The player base class provides shared functions such as rendering view management, event notification, recording, and screenshots; both the live stream player and the replay player inherit from the player base class.

[0111] (3) Video acquisition equipment: responsible for video frame acquisition and encoding, frame timestamp marking (live broadcast / playback), mode switching response, and historical recording storage and retrieval.

[0112] The application layer and playback management layer are deployed on the terminal device, communicating with the video acquisition device through the target link layer (e.g., a P2P connection layer). When the target link layer is a P2P connection layer, it can include a P2P client and a Web Real-Time Communication (WebRTC) engine. The P2P client is responsible for single P2P connection management, frame reception and distribution, mode switching request sending, and connection state management; the WebRTC engine is responsible for peer-to-peer connection management, video frame decoding, and data channel communication.

[0113] The following, combined with Figure 4 , Figure 5 , Figure 6 and Figure 7 The complete process of a video playback mode switching method provided in the embodiments of this disclosure will be described.

[0114] On the terminal device side: Step S401: In response to the mode switching event, a mode switching request is sent to the video acquisition device.

[0115] The mode switching event can be either a first mode switching operation that indicates switching the video playback mode from live mode to replay mode, or a second mode switching operation that indicates switching the video playback mode from replay mode to live mode.

[0116] On the video capture device side: Step S402: Receive a mode switching request sent by the terminal device.

[0117] Step S403: Based on the mode switching request, obtain target video data including the target video frame.

[0118] Among them, the target video frame belongs to the video frame in live mode (i.e., live video frame) or belongs to the video frame in replay mode (i.e., replay video frame).

[0119] In some optional implementations, step S403, namely, "obtaining target video data based on mode switching request", may include: S403-11, In the case where the mode switching request is used to request the video playback mode to be switched from live mode to playback mode, the target playback video frame is obtained as the target video frame. S403-12, Generate playback mode flag, which serves as the frame-level mode flag corresponding to the target video frame; S403-13, Generate an absolute time stamp for the target video frame that meets the time requirements of the playback mode; S403-14 generates target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0120] In some optional implementations, step S403, namely, "obtaining target video data based on mode switching request", may include: S403-21, In the case where the mode switching request is used to request the video playback mode to be switched from playback mode to live mode, the target live video frame is obtained as the target video frame. S403-22, Generate a live streaming mode flag, which serves as the frame-level mode flag corresponding to the target video frame; S403-23, Generate an absolute time stamp for the target video frame that meets the time requirements of the live streaming mode; S403-24 generates target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0121] Step S404: Send target video data, including target video frames, to the terminal device via the target link.

[0122] The target link can be a communication link shared by the live streaming player and the playback player in the terminal device. That is, the live streaming player and the playback player can listen to the target link together, and the target link will always maintain a "keep connected, uninterrupted" state during the switching of video playback modes. Here, the target link can be a P2P communication link, that is, a communication link established based on the P2P communication method.

[0123] On the terminal device side: In step S405, the live streaming player receives target video data, including target video frames, by monitoring the target link.

[0124] Step S406: Extract frame-level mode flags from the target video data.

[0125] Step S407: Determine whether the frame-level mode flag is the lookback mode flag.

[0126] If the frame-level mode flag is the lookback mode flag, proceed to step S408; if the frame-level mode flag is not the lookback mode flag, proceed to step S409.

[0127] Step S408: Determine that the target video frame belongs to the video frame in playback mode, and release the resources occupied by the live stream player.

[0128] Step S409: Extract the absolute time stamp from the target video data.

[0129] Among them, the absolute time stamp can represent the absolute acquisition time of the target video frame.

[0130] Step S410: Determine whether the absolute time flag meets the time requirements of the playback mode.

[0131] If the absolute time stamp meets the time requirements of the playback mode, proceed to step S408; if the absolute time stamp does not meet the time requirements of the playback mode, proceed to step S411.

[0132] Step S411: Determine that the target video frame belongs to the live streaming mode and play the target video frame.

[0133] In step S412, the playback player receives target video data, including target video frames, by monitoring the target link.

[0134] Step S413: Extract frame-level mode flags from the target video data.

[0135] Step S414: Determine whether the frame-level mode flag is a live mode flag.

[0136] If the frame-level mode flag is the live mode flag, proceed to step S415; if the frame-level mode flag is not the live mode flag, proceed to step S416.

[0137] Step S415: Determine that the target video frame belongs to the live streaming mode and release the resources occupied by the playback player.

[0138] Step S416: Extract the absolute time stamp from the target video data.

[0139] Among them, the absolute time stamp can represent the absolute acquisition time of the target video frame.

[0140] Step S417: Determine whether the absolute time flag meets the time requirements of the live streaming mode.

[0141] If the absolute time flag meets the time requirements of the live streaming mode, proceed to step S415; if the absolute time flag does not meet the time requirements of the live streaming mode, proceed to step S418.

[0142] Step S418: Determine that the target video frame belongs to the video frame in playback mode, and play the target video frame.

[0143] In some optional implementations, step S418, namely, "determining that the target video frame belongs to the video frame in playback mode and playing the target video frame", may include: Step S418-1: Determine that the target video frame belongs to the video frame in playback mode, and extract the camera identifier from the target video data; Step S418-2: Determine the playback progress corresponding to the camera identifier based on the absolute time stamp; Step S418-3: Play the target video frame and display the playback progress.

[0144] For the specific functions and examples of the above steps, please refer to the relevant descriptions in the aforementioned embodiments of the video playback mode switching method applied to terminal devices and the video playback mode switching method applied to video acquisition devices, which will not be repeated here.

[0145] To better implement the aforementioned method for switching video playback modes applied to terminal devices, this disclosure also provides a video playback mode switching device. Hereinafter, it will be discussed in conjunction with... Figure 8 The schematic block diagram shown illustrates the video playback mode switching device 800 provided in the disclosed embodiment.

[0146] The request sending unit 801 is used to send a mode switching request to the video acquisition device in response to a mode switching event; wherein, after receiving the mode switching request, the video acquisition device is used to send target video data to the terminal device through the target link; the target link is shared by the live streaming player and the playback player in the terminal device; the target video data includes target video frames; The first playback execution unit 802 is used to release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in the playback mode; or, when it is determined that the target video frame belongs to the video frame in the live streaming mode, play the target video frame. The second playback execution unit 803 is used to release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in the live broadcast mode; or, when it is determined that the target video frame belongs to the video frame in the playback mode, play the target video frame.

[0147] In some optional implementations, the first playback execution unit 802 is used for: Extract frame-level mode flags from the target video data; When the frame-level mode flag is set to playback mode, the target video frame is determined to be a video frame in playback mode, and the resources occupied by the live stream player are released.

[0148] In some optional implementations, the first playback execution unit 802 is used for: When the frame-level mode flag is not the lookback mode flag, the absolute time flag is extracted from the target video data; whereby the absolute time flag is used to characterize the absolute acquisition time of the target video frame. If the absolute time stamp meets the time requirements of the playback mode, determine that the target video frame belongs to the video frame in the playback mode, and release the resources occupied by the live stream player.

[0149] In some optional implementations, the first playback execution unit 802 is used for: If the absolute time stamp does not meet the time requirements of the playback mode, determine that the target video frame belongs to the live broadcast mode and play the target video frame.

[0150] In some optional implementations, the second playback execution unit 803 is used for: Extract frame-level mode flags from the target video data; When the frame-level mode flag is set to live mode, the target video frame is determined to be a video frame in live mode, and the resources occupied by the playback player are released.

[0151] In some optional implementations, the second playback execution unit 803 is used for: When the frame-level mode flag is not the live mode flag, the absolute time flag is extracted from the target video data; whereby the absolute time flag is used to characterize the absolute acquisition time of the target video frame. If the absolute time stamp meets the time requirements of the live streaming mode, determine that the target video frame belongs to the live streaming mode and release the resources occupied by the playback player.

[0152] In some optional implementations, the second playback execution unit 803 is used for: If the absolute time stamp does not meet the time requirements of the live streaming mode, determine that the target video frame belongs to the video frame in the playback mode, and play the target video frame.

[0153] In some optional implementations, the second playback execution unit 803 is used for: If the absolute time stamp does not meet the time requirements of the live streaming mode, determine that the target video frame belongs to the video frame in the playback mode, and extract the camera identifier from the target video data. Based on the absolute time stamp, determine the playback progress corresponding to the camera identifier; Play the target video frame and display the playback progress.

[0154] In some optional implementations, the second playback execution unit 803 is used for: In the timestamp mapping table, the historical timestamp corresponding to the camera identifier is updated to an absolute time flag to obtain the current timestamp corresponding to the camera identifier; Create a scheduled progress reporting task using the camera identifier as the key; Execute a scheduled progress reporting task to extract the current timestamp corresponding to the camera identifier from the timestamp mapping table according to a preset time period; Based on the current timestamp corresponding to the camera identifier, and the playback start time and playback end time extracted from the target video data, the playback progress corresponding to the camera identifier is determined.

[0155] In some optional implementations, the mode switching event is a first mode switching operation used to indicate switching the video playback mode from live mode to replay mode; the request sending unit 801 is used to: In response to a first mode switching operation, first switching information is obtained; wherein, the first switching information includes at least one of device identifier, camera identifier, playback start time and playback end time; Generate a mode switching request carrying the first switching information; Send a mode switching request to the video capture device.

[0156] In some optional implementations, the mode switching event is a second mode switching operation used to indicate switching the video playback mode from playback mode to live mode; the request sending unit 801 is used to: In response to a second mode switching operation, second switching information is obtained; wherein, the second switching information includes a device identifier and / or a camera identifier; Generate a mode switching request carrying the second switching information; Send a mode switching request to the video capture device.

[0157] The specific functions and examples of each unit in the video playback mode switching device 800 in this embodiment can be found in the relevant descriptions of the corresponding steps in the aforementioned embodiment of the video playback mode switching method applied to a terminal device, and will not be repeated here.

[0158] To better implement the aforementioned method for switching video playback modes applied to video acquisition devices, this disclosure also provides a video playback mode switching device. The following will be combined with... Figure 9 The schematic block diagram shown illustrates a video playback mode switching device 900 provided in the disclosed embodiment.

[0159] The request receiving unit 901 is used to receive a mode switching request sent by the terminal device; The data acquisition unit 902 is used to acquire target video data based on a mode switching request; wherein, the target video data includes target video frames; The data sending unit 903 is used to send target video data to the terminal device via the target link; wherein the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the terminal device is used to: release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in playback mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in live streaming mode; and release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in live streaming mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in playback mode.

[0160] In some optional implementations, the data acquisition unit 902 is used for: When the mode switching request is used to request the video playback mode to be switched from live mode to playback mode, the target playback video frame is obtained as the target video frame. Generate a playback mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp for the target video frame that meets the time requirements of the playback mode; Generate target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0161] In some optional implementations, the data acquisition unit 902 is used for: When the mode switching request is used to request switching the video playback mode from playback mode to live mode, the target live video frame is obtained as the target video frame. Generate a live streaming mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp for the target video frame that meets the time requirements of the live streaming mode; Generate target video data carrying the target video frame, frame-level mode flag, and absolute time flag.

[0162] The specific functions and examples of each unit in the video playback mode switching device 900 in this embodiment can be found in the relevant descriptions of the corresponding steps in the aforementioned embodiment of the video playback mode switching method applied to a video acquisition device, and will not be repeated here.

[0163] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0164] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0165] Figure 10 A schematic structural block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure is shown. The electronic device 1000 is intended to represent various forms of digital computers, such as in-vehicle computing devices, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device 1000 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0166] like Figure 10 As shown, the electronic device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 1002 or a computer program loaded from a storage unit 1008 into a random access memory (RAM) 1003. The RAM 1003 may also store various programs and data required for the operation of the electronic device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0167] Multiple components in electronic device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of renderers, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0168] The computing unit 1001 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above. For example, in some embodiments, the video playback mode switching method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the video playback mode switching method described above can be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured in any other suitable manner (e.g., by means of firmware) as a method for switching video playback modes.

[0169] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0170] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data optimization device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0171] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0172] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a rendering device (e.g., a cathode ray tube (CRT) renderer or a liquid crystal display (LCD)) for rendering information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices are also used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0173] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0174] A computer system can include client and server components. Clients and servers are generally located far apart and typically interact via a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, a server in a distributed system, or a server incorporating blockchain technology.

[0175] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute a method for switching video playback modes.

[0176] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements a method for switching video playback modes.

[0177] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure is achieved, and this is not limited herein. Furthermore, in this disclosure, relational terms such as "first," "second," and "third" are used merely 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. Additionally, "multiple" in this disclosure can be understood as at least two.

[0178] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for switching video playback modes, applied to a terminal device, the method comprising: In response to a mode switching event, a mode switching request is sent to the video acquisition device; wherein, after receiving the mode switching request, the video acquisition device is used to send target video data to the terminal device via a target link; the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the target video data includes target video frames; Using the live streaming player, if it is determined that the target video frame belongs to the video frame in playback mode, the resources occupied by the live streaming player are released; or, if it is determined that the target video frame belongs to the video frame in live streaming mode, the target video frame is played. Using the playback player, if it is determined that the target video frame belongs to the live streaming mode, the resources occupied by the playback player are released; or, if it is determined that the target video frame belongs to the playback mode, the target video frame is played.

2. The method according to claim 1, wherein, The step of releasing the resources occupied by the live stream player when it is determined that the target video frame belongs to the video frame in playback mode includes: Extract frame-level mode flags from the target video data; If the frame-level mode flag is set to the playback mode flag, the target video frame is determined to be a video frame in playback mode, and the resources occupied by the live streaming player are released.

3. The method according to claim 2, wherein releasing the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in playback mode includes: If the frame-level mode flag is not the playback mode flag, an absolute time flag is extracted from the target video data; wherein, the absolute time flag is used to characterize the absolute acquisition time of the target video frame; If the absolute time flag meets the time requirements of the playback mode, the target video frame is determined to be a video frame in the playback mode, and the resources occupied by the live streaming player are released.

4. The method according to claim 3, wherein, The step of playing the target video frame when it is determined that the target video frame belongs to the live streaming mode includes: If the absolute time stamp does not meet the time requirements of the playback mode, the target video frame is determined to be a video frame in the live broadcast mode, and the target video frame is played.

5. The method according to claim 1, wherein, The step of releasing the resources occupied by the playback player when it is determined that the target video frame belongs to the live streaming mode includes: Extract frame-level mode flags from the target video data; If the frame-level mode flag is set to live mode, the target video frame is determined to be a video frame in live mode, and the resources occupied by the playback player are released.

6. The method according to claim 5, wherein, The step of releasing the resources occupied by the playback player when it is determined that the target video frame belongs to the live streaming mode includes: If the frame-level mode flag is not the live mode flag, an absolute time flag is extracted from the target video data; wherein, the absolute time flag is used to characterize the absolute acquisition time of the target video frame; If the absolute time stamp meets the time requirements of the live streaming mode, the target video frame is determined to be a video frame in the live streaming mode, and the resources occupied by the playback player are released.

7. The method according to claim 6, wherein, When it is determined that the target video frame belongs to the video frame in playback mode, playing the target video frame includes: If the absolute time stamp does not meet the time requirements of the live streaming mode, the target video frame is determined to be a video frame belonging to the replay mode, and the target video frame is played.

8. The method according to claim 7, wherein determining that the target video frame belongs to the video frame in the replay mode and playing the target video frame when the absolute time stamp does not meet the time requirements of the live broadcast mode includes: If the absolute time stamp does not meet the time requirements of the live streaming mode, the target video frame is determined to be a video frame in the playback mode, and the camera identifier is extracted from the target video data. Based on the absolute time stamp, determine the playback progress corresponding to the camera identifier; Play the target video frame and display the playback progress.

9. The method according to claim 8, wherein, The step of determining the playback progress corresponding to the camera identifier based on the absolute time stamp includes: In the timestamp mapping table, the historical timestamp corresponding to the camera identifier is updated to the absolute time flag to obtain the current timestamp corresponding to the camera identifier; Create a timed progress reporting task using the camera identifier as the key; The scheduled progress reporting task is executed to extract the current timestamp corresponding to the camera identifier from the timestamp mapping table according to a preset time period. Based on the current timestamp corresponding to the camera identifier, and the playback start time and playback end time extracted from the target video data, the playback progress corresponding to the camera identifier is determined.

10. The method according to any one of claims 1 to 9, wherein, The mode switching event is used to indicate the first mode switching operation that switches the video playback mode from live mode to replay mode. The step of sending a mode switching request to the video capture device in response to a mode switching event includes: In response to a first mode switching operation, first switching information is obtained; wherein, the first switching information includes at least one of device identifier, camera identifier, playback start time and playback end time; Generate the mode switching request carrying the first switching information; Send the mode switching request to the video acquisition device.

11. The method according to any one of claims 1 to 9, wherein, The mode switching event is a second mode switching operation used to indicate switching the video playback mode from playback mode to live mode; The step of sending a mode switching request to the video capture device in response to a mode switching event includes: In response to a second mode switching operation, second switching information is obtained; wherein, the second switching information includes a device identifier and / or a camera identifier; Generate the mode switching request carrying the second switching information; Send the mode switching request to the video acquisition device.

12. A method for switching video playback modes, applied to a video capture device, the method comprising: Receive mode switching requests sent by terminal devices; Based on the mode switching request, target video data is obtained; wherein, the target video data includes target video frames; The target video data is sent to the terminal device via the target link; wherein the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the terminal device is used to: release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in playback mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in live streaming mode; and release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in live streaming mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in playback mode.

13. The method according to claim 12, wherein, The step of obtaining target video data based on the mode switching request includes: When the mode switching request is used to request switching the video playback mode from live mode to playback mode, the target playback video frame is obtained as the target video frame. Generate a playback mode flag, which serves as a frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp for the target video frame that meets the time requirements of the playback mode; Generate the target video data carrying the target video frame, the frame-level mode flag, and the absolute time flag.

14. The method according to claim 12, wherein, The step of obtaining target video data based on the mode switching request includes: When the mode switching request is used to request switching the video playback mode from playback mode to live mode, the target live video frame is obtained as the target video frame. Generate a live streaming mode flag, which serves as the frame-level mode flag corresponding to the target video frame; Generate an absolute time stamp for the target video frame that meets the time requirements of the live streaming mode; Generate the target video data carrying the target video frame, the frame-level mode flag, and the absolute time flag.

15. A video playback mode switching device, applied to a terminal device, the device comprising: A request sending unit is configured to send a mode switching request to a video acquisition device in response to a mode switching event; wherein, after receiving the mode switching request, the video acquisition device is configured to send target video data to the terminal device via a target link; the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the target video data includes target video frames; The first playback execution unit is used to release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in the playback mode; or, when it is determined that the target video frame belongs to the video frame in the live streaming mode, play the target video frame. The second playback execution unit is used to release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in the live broadcast mode; or, when it is determined that the target video frame belongs to the video frame in the playback mode, play the target video frame.

16. A video playback mode switching device, applied to a video acquisition device, the device comprising: The request receiving unit is used to receive mode switching requests sent by the terminal device. A data acquisition unit is configured to acquire target video data based on the mode switching request; wherein the target video data includes target video frames; A data sending unit is configured to send the target video data to the terminal device via a target link; wherein the target link is a communication link shared by the live streaming player and the playback player in the terminal device; the terminal device is configured to: use the live streaming player to release the resources occupied by the live streaming player when it is determined that the target video frame belongs to the video frame in playback mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in live streaming mode; and use the playback player to release the resources occupied by the playback player when it is determined that the target video frame belongs to the video frame in live streaming mode; or, play the target video frame when it is determined that the target video frame belongs to the video frame in playback mode.

17. An electronic device comprising: At least one processor; A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method according to any one of claims 1 to 14.

18. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 14.

19. A computer program product comprising a computer program; wherein, When the computer program is executed by a processor, it can implement the method of any one of claims 1 to 14.

Images