Video playing method, device, equipment and storage medium

Abstract

The application relates to the field of video monitoring, and proposes a video playing method, device, equipment and storage medium. The method comprises the following steps: a communication link between a first application process and a second application process is established; the first application process sends a window handle for video playing and video source data needing to be played to the second application process through the communication link; the second application process plays a window of the video source data through the window handle, decodes the video source data, and renders and plays through the window corresponding to the window handle. Since the available memory space of the second application process with a high number is greater than the available memory space of the first application process, the requirement of the memory space during video playing can be better met, the probability of the first application process collapsing is reduced, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of video surveillance, and in particular to video playback methods, devices, equipment, and storage media. Background Technology

[0002] With the emergence of "smart cities" and "intelligent transportation," the security industry has maintained rapid growth. Currently, previewing and playback of surveillance videos mostly utilizes desktop clients. As user demand for previewing and playback increases, video quality becomes clearer, requiring more channels to be previewed and played back simultaneously, thus increasing the memory needed for video decoding. For example, the video resolution for user previewing and playback might be 1080P or 4K, and the number of channels to be previewed simultaneously might be 32 or 64.

[0003] However, most current desktop clients are 32-bit programs. In a Windows environment, the maximum available memory is 4GB, with even less actually available for the program. Typically, the UI and functional layers of a desktop client consume a significant amount of memory, leaving little for video decoding. Insufficient memory for decoding can prevent the desktop client from previewing and playing back the desired number of video channels. When the memory consumed by decoding reaches a critical point, it may cause the desktop client to crash, negatively impacting the user experience. Summary of the Invention

[0004] In view of this, embodiments of this application provide a video playback method, apparatus, device, and storage medium to solve the problem in the prior art that when playing multi-channel, high-quality videos through low-bit (e.g., 32-bit) application processes, insufficient memory can easily lead to program crashes.

[0005] A first aspect of this application provides a video playback method, the method comprising:

[0006] A communication link is established between the first application process and the second application process. The bit width of the second application process is greater than that of the first application process. The first application process and the second application process are processes used for video playback.

[0007] Through the communication link, the first application process sends the window handle for video playback and the video source data to be played to the second application process.

[0008] The second application process decodes the video source data through the window that plays the video source data via the window handle, and renders and plays the video through the window corresponding to the window handle.

[0009] In conjunction with the first aspect, in the first possible implementation of the first aspect, after rendering and playing through the window corresponding to the window handle, the method further includes:

[0010] The second application process sends the playback time of the second application process back to the first application process;

[0011] The first application process updates its display information based on the playback time.

[0012] In conjunction with the first possible implementation of the first aspect, in the second possible implementation of the first aspect, the first application process updates its display information according to the playback time, including:

[0013] The first application process updates the playback progress bar in its display information based on the playback time.

[0014] Alternatively, the video source data may be video data from vehicle monitoring, and the first application process may update the map data in the display information of the first application process, as well as the vehicle's position on the map, according to the playback time.

[0015] In conjunction with the second possible implementation of the first aspect, in the third possible implementation of the first aspect, the first application process updates the map data in the display information of the first application process and the vehicle location information in the map data according to the playback time, including:

[0016] The first application process searches for the vehicle location information corresponding to the playback time within the first application process;

[0017] The map data and the vehicle's location on the map in the display information of the first application process are updated based on the vehicle location information.

[0018] In conjunction with the first aspect, in the fourth possible implementation of the first aspect, after establishing the communication link between the first application process and the second application process, the method further includes:

[0019] The first application process sends the number of video channels to be played to the second application process;

[0020] The second application process creates corresponding channels based on the number of channels, and decodes, renders, and plays the video in the corresponding channels according to the channel identifiers in the video source data.

[0021] In conjunction with the first aspect, in the fifth possible implementation of the first aspect, a communication link is established between the first application process and the second application process, including:

[0022] Establish communication links between the second application process and multiple first application processes;

[0023] After establishing the communication link between the first application process and the second application process, the method further includes:

[0024] The second application process creates a corresponding audio player for each first application process, and plays the audio from the video source data sent by the corresponding first application process through the audio player.

[0025] In conjunction with the first aspect, in the sixth possible implementation of the first aspect, a communication link is established between the first application process and the second application process, including:

[0026] When the first application process starts, it checks whether the second application process exists;

[0027] If the second application process does not exist, the second application process is created according to the pre-set relative paths between the first and second application processes.

[0028] A second aspect of this application provides a video playback device, the device comprising:

[0029] A communication link establishment unit is used to establish a communication link between a first application process and a second application process, wherein the bit width of the second application process is greater than that of the first application process, and the first application process and the second application process are processes used for video playback.

[0030] The data transmission unit is used to send the window handle for video playback and the video source data to be played from the first application process to the second application process through the communication link.

[0031] The decoding and playback unit is used by the second application process to play the video source data through the window handle, decode the video source data, and render and play it through the window corresponding to the window handle.

[0032] A third aspect of this application provides a video playback device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any of the first aspects.

[0033] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any of the first aspects.

[0034] The beneficial effects of this application embodiment compared with the prior art are as follows: This application establishes a communication link between a first application process and a second application process. The first application process sends video source data and a window handle to the second application process. The second application process decodes the video source data and renders and plays the decoded data through the window determined by the window handle. Since the memory space available to the high-bit second application process is greater than that available to the first application process, it can better meet the memory space requirements during video playback, reduce the probability of the first application process crashing, and improve the user experience. Attached Figure Description

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

[0036] Figure 1 This is a diagram showing the memory usage of 32-bit desktop client application processes currently used for video surveillance.

[0037] Figure 2 This is a schematic diagram illustrating the implementation process of a video playback method provided in an embodiment of this application;

[0038] Figure 3 This application provides an embodiment of an interaction diagram between a first application process and a second application process;

[0039] Figure 4 This is a schematic diagram of a video playback device provided in an embodiment of this application;

[0040] Figure 5 This is a schematic diagram of the video playback device provided in the embodiments of this application. Detailed Implementation

[0041] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0042] To illustrate the technical solution described in this application, specific embodiments are provided below.

[0043] Figure 1This diagram illustrates the memory usage of a 32-bit desktop client application process currently used for video surveillance. Typically, a 32-bit desktop client process can use about 4GB of memory. The desktop client includes modules such as the UI layer and functional layers (including preview and playback functions), which consume a certain amount of memory. The video decoding library within the desktop client can only use less than 4GB of memory. When the functional layer calls the video decoding library for video decoding, the available memory is insufficient to meet the decoding requirements of high-quality, multi-channel video, potentially causing the video surveillance desktop client to crash and negatively impacting the user experience. Since 32-bit programs cannot call 64-bit DLLs (Dynamic Link Libraries), compiling the video decoding library to 64-bit will not meet the video playback requirements of the desktop client.

[0044] To address the aforementioned problems, this application proposes a video playback method, such as... Figure 2 As shown, the method includes:

[0045] In S201, a communication link is established between the first application process and the second application process.

[0046] The second application process has a larger bit width than the first application process, and both the first and second application processes are used for video playback.

[0047] In possible implementations, the first application process can be a 32-bit application process. For example, the first application process could be the process corresponding to a desktop client used for video playback or replay in commonly used video surveillance scenarios. The second application process can be a 64-bit application process. However, this is not a limitation; with technological advancements, the second application process could also be 128-bit, 256-bit, etc. The device hosting both the first and second application processes can be a higher-bit device, for example, it could include a 32-bit first application process and a 64-bit second application process running on a 64-bit device.

[0048] The bit length of the application process refers to the address length of the application compiler corresponding to that process. Because the first application process has a smaller bit length, its available memory space is limited; for example, if the first application process has only 4GB of available memory, it cannot directly meet the requirements for high-quality, multi-channel video playback. The second application process has a larger bit length than the first; for example, if the second application process is 64-bit, it can support a maximum memory space of 256TB, which can effectively meet the requirements for high-quality (e.g., 2K, 1080P, etc.) and multi-channel (e.g., 16-channel, 32-channel, etc.) video playback.

[0049] When establishing a communication link between the first application process and the second application process, a communication link based on the Socket protocol can be established between the first application process and the second application process.

[0050] One possible implementation is to configure the second application process to start automatically at system boot. When the first application process starts, it is then established. The automatically started second application process can then establish a communication link with the first application process. Alternatively, the second application process can be started manually by the user, and a communication link can be established between the started second application process and the first application process.

[0051] In one possible implementation, the second application process can be triggered by the first application process. For example, the first application process can be established when it starts, and the system can detect whether a second application process exists. If a second application process exists, a communication link can be established with it. If a second application process does not exist, it can be triggered and established based on a pre-defined relative path between the first and second application processes, thereby establishing a communication link between them.

[0052] If the second application process has a larger bit width than the first application process (e.g., 64-bit), multiple video tasks can be created within it. Each video task can have multiple pre-defined channel tasks, and each channel task can decode and render the corresponding video source data. A correspondence can be established between each video task and the first application process. When a first application process is started, a corresponding video task is assigned to it, and a number of decoding channels can be created within that video task based on the number of video channels in the first application process.

[0053] For example, the second application process can pre-set 100 unassigned video tasks, and each video task can pre-set 32 ​​unassigned channel tasks. The channel tasks are used to decode and render the video source data of the corresponding channel in the first application process.

[0054] In S202, through the communication link, the first application process sends the window handle for video playback and the video source data to be played to the second application process.

[0055] like Figure 3In the interaction diagram of the first application process and the second application process shown, after the first application process and the second application process establish a communication link, the first application process can send the video source data that needs to be played to the second application process, and send the handle of the window used to determine the playback of the source video data, i.e., the window handle, to the second application process.

[0056] When the first application process includes video source data from multiple channels, the second application process checks if a corresponding video task exists. If not, a new video task is created. Alternatively, within the same first application process, corresponding video tasks can be created in the second application process based on different operation states. For example, video tasks can be created in the second application process based on playback or preview states.

[0057] Within the created video task, multiple channel tasks can be created accordingly, and a correspondence can be established between the channel task identifiers and the video channels in the first application process. Based on this correspondence, the video source data of each channel in the first application process can be sent to the corresponding channel tasks in the video task, thereby performing transcoding, decoding, or rendering operations on the video source data of each channel.

[0058] In this embodiment, the first application process also sends a window handle corresponding to the window used to display the decoded video. The window handle used for video display is a unique resource in the system. After being sent by the first application process to the second application process, the second application process can normally call and use the window handle to obtain the window used to display the video.

[0059] like Figure 3 As shown, when a second application process establishes a communication link with multiple first application processes, to avoid interference between different video tasks, an audio player belonging to the corresponding first application process can be created within the second application process for each video task. This audio player is used to play the audio from the video source data sent by the corresponding first application process, thus making the audio playback of each first application process independent. When playing audio, the audio player can play the audio from the selected channel among multiple channels in the first application process.

[0060] In S203, the second application process decodes the video source data through the window that plays the video source data via the window handle, and renders and plays the video through the window corresponding to the window handle.

[0061] After receiving the video source data sent by the first application process, the second application process can perform decoding and rendering. Based on the window handle sent by the first application process, the second application process uses the window corresponding to that handle to play the video source data. Due to the bitness of the second application process...

[0062] During video playback, the second application process can receive playback control commands from the first application process, including commands such as play, pause, frame advance, frame rewind, electronic zoom, add mosaic, speed up playback, turn sound on / off, image placement, and screenshot.

[0063] In this embodiment of the application, when the second application process plays the video source data transmitted by the first application process, it can also send the playback time back to the first application process according to the frame information being played.

[0064] In order to match the UI interface in the first application process with the playback status in the second application process, the first application process can dynamically update the content in the UI (User Interface) interface based on the returned playback time, including updating the playback progress bar in the UI interface.

[0065] When the first application process is a desktop client for in-vehicle video surveillance, the UI can also include map data and the vehicle's location on the map.

[0066] In one possible implementation, video source data is sent to the second application process when the vehicle is moving, and stopped when the vehicle is stationary. At this point, based on the video playback time returned by the second application process (e.g., playback time returned every second), the playback progress bar and the map data and vehicle position on the map in the UI can be dynamically updated. For example, the map can be moved forward at a constant speed based on the playback time, and the vehicle's position on the map can be changed at a constant speed. This ensures that the UI in the first application process matches the playback progress in the second application process.

[0067] In one possible implementation, the first application process can record the correspondence between the playback time of the video source data and the location data. Based on the playback time returned by the second application process, the corresponding location data is retrieved, and the map data in the display information of the first application process, as well as the vehicle's position on the map, are updated based on the location data.

[0068] When the video task of the first application process ends, it can send a command to the second application process, which will then release the allocated video task and put it into an idle state.

[0069] This application uses a second application process with a higher bit depth to decode and render the video source data of the first application process, and determines the display window based on the window handle. This allows the first application process to complete video playback with the help of the second application process, solving the problem of insufficient memory resources and effectively adapting to the requirements of high-quality, multi-channel video playback tasks. In this embodiment, the second application process is a shared process, which can be used by all applications on the same computer that require decoding, thus adapting to the playback requirements of various video tasks.

[0070] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0071] Figure 4 This is a schematic diagram of a video playback device provided in an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0072] The communication link establishment unit 401 is used to establish a communication link between the first application process and the second application process. The number of bits in the second application process is greater than the number of bits in the first application process. The first application process and the second application process are processes used for video playback.

[0073] The data transmission unit 402 is used to send the window handle for video playback and the video source data to be played from the first application process to the second application process via a communication link.

[0074] The decoding and playback unit 403 is used by the second application process to play the video source data through the window handle, decode the video source data, and render and play it through the window corresponding to the window handle.

[0075] Figure 4 The video playback device shown is, with Figure 2 The video playback method shown corresponds to this.

[0076] Figure 5 This is a schematic diagram of a video playback device provided in one embodiment of this application. Figure 5 As shown, the video playback device 5 of this embodiment includes: a processor 50, a memory 51, and a computer program 52, such as a video playback program, stored in the memory 51 and executable on the processor 50. When the processor 50 executes the computer program 52, it implements the steps in the various video playback method embodiments described above. Alternatively, when the processor 50 executes the computer program 52, it implements the functions of each module / unit in the various device embodiments described above.

[0077] For example, the computer program 52 may be divided into one or more modules / units, which are stored in the memory 51 and executed by the processor 50 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 52 in the video playback device 5.

[0078] The video playback device may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of video playback device 5 and does not constitute a limitation on video playback device 5. It may include more or fewer components than shown, or combine certain components, or different components. For example, the video playback device may also include input / output devices, network access devices, buses, etc.

[0079] The processor 50 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0080] The memory 51 can be an internal storage unit of the video playback device 5, such as a hard disk or memory of the video playback device 5. The memory 51 can also be an external storage device of the video playback device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the video playback device 5. Furthermore, the memory 51 can include both internal and external storage units of the video playback device 5. The memory 51 is used to store the computer program and other programs and data required by the video playback device. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0082] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0083] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

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

[0087] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

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

Claims

1. A video playback method, characterized in that, The method includes: A communication link is established between the first application process and the second application process. The bit width of the second application process is greater than that of the first application process. The first application process and the second application process are processes used for video playback. Through the communication link, the first application process sends the window handle for video playback and the video source data to be played to the second application process. The second application process decodes the video source data through the window handle of the window that plays the video source data, and renders and plays it through the window corresponding to the window handle. When the second application process establishes a communication link with multiple first application processes, the second application process creates an audio player belonging to the corresponding first application process for each video task. The audio player is used to play the audio in the video source data sent by the corresponding first application process. The second application process sends the playback time back to the first application process. The first application process updates its display information according to the playback time, including: the first application process searches for the vehicle location information corresponding to the playback time in the first application process; and updates the map data and the vehicle's position on the map in the display information of the first application process according to the vehicle location information.

2. The method according to claim 1, characterized in that, The first application process updates its display information based on the playback time, and further includes: The first application process updates the playback progress bar in its display information based on the playback time.

3. The method according to claim 1, characterized in that, After establishing the communication link between the first application process and the second application process, the method further includes: The first application process sends the number of video channels to be played to the second application process; The second application process creates corresponding channels based on the number of channels, and decodes, renders, and plays the video in the corresponding channels according to the channel identifiers in the video source data.

4. The method according to claim 1, characterized in that, Establishing a communication link between the first application process and the second application process includes: When the first application process starts, it checks whether the second application process exists; If the second application process does not exist, the second application process is created according to the pre-set relative paths between the first and second application processes.

5. A video playback device, characterized in that, The device includes: A communication link establishment unit is used to establish a communication link between a first application process and a second application process, wherein the bit width of the second application process is greater than that of the first application process, and the first application process and the second application process are processes used for video playback. The data transmission unit is used to send the window handle for video playback and the video source data to be played from the first application process to the second application process through the communication link. The decoding and playback unit is used by the second application process to play the video source data through the window handle, decode the video source data, and render and play it through the window corresponding to the window handle. When the second application process establishes a communication link with multiple first application processes, the second application process creates an audio player belonging to the corresponding first application process for each video task. The audio player is used to play the audio in the video source data sent by the corresponding first application process. The second application process sends the playback time back to the first application process. The first application process updates its display information according to the playback time, including: the first application process searches for the vehicle location information corresponding to the playback time in the first application process; and updates the map data and the vehicle's position on the map in the display information of the first application process according to the vehicle location information.

6. A video playback device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 4.

Images