A method, system, terminal and storage medium for video playback

Abstract

The application discloses a video reverse playing method, system, terminal and storage medium, wherein the method comprises the following steps: scanning a video, recording the timestamp value of all key frames to obtain a key frame index table; finding out the timestamp of the key frame closest to and smaller than the current timestamp; starting decoding from the position of the timestamp of the key frame by a decoding thread until the position of the current timestamp is decoded, and saving the decoded data into buffer data; starting reverse playing of the video by a playing thread after the data of the position of the current timestamp is stored in the buffer data; calculating an expected timestamp, then finding out the timestamp of the expected key frame closest to and smaller than the expected timestamp according to the key frame index table, then starting decoding from the timestamp of the expected key frame by the decoding thread until the position of the expected timestamp is decoded, and saving the decoded data into the buffer data until the video decoding is completed.

Description

Technical Field

[0001] This invention relates to the field of video processing technology, and specifically to a method, system, terminal, and storage medium for video reversal. Background Technology

[0002] With the development of multimedia technology, a large amount of audio and video data has appeared on the Internet. More and more people are starting to use audio and video editing software to generate videos. Among them, the reverse playback function is an important function for players and audio and video editing tools, which can create a variety of attractive effects.

[0003] Since the file only supports forward decoding, reverse playback requires changing the video stream position by seeking. However, this operation is time-consuming, especially for non-keyframes. If seeking is performed for every frame, the playback will be choppy. Existing methods cache most video frames or cache multiple segments over time to optimize the stuttering problem. However, this can easily consume too much memory, causing some system problems. Summary of the Invention

[0004] The main objective of this invention is to provide a method, system, terminal, and storage medium for video reverse playback, aiming to solve the problem of excessive memory usage during video reverse playback.

[0005] To achieve the above objectives, the first aspect of the present invention provides a method for reversing video playback, comprising the following steps:

[0006] After receiving the instruction to reverse the video, scan the video, record the timestamp values ​​of all keyframes, and obtain the keyframe index table;

[0007] Find the timestamp of the key frame that is closest to and less than the current timestamp based on the key frame index table;

[0008] The decoding thread starts decoding from the timestamp of the keyframe and continues until it reaches the current timestamp, saving the decoded data to the cache.

[0009] Once the cached data contains the data of the current timestamp, the playback thread starts playing the video in reverse, and after each frame is played, the playback thread deletes the completed frame from the cached data.

[0010] While the playback thread starts playing the video in reverse, it calculates the expected timestamp, which is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, according to the keyframe index table, it finds the timestamp of the expected keyframe that is closest to and less than the expected timestamp. The decoding thread then starts decoding from the timestamp of the expected keyframe until it reaches the expected timestamp, and saves the decoded data to the cache. It then recalculates the next expected timestamp and decodes between the next expected timestamp and the timestamp of the next expected keyframe that is closest to and less than the next expected timestamp, until the video decoding is complete.

[0011] In an optional embodiment of the first aspect of the present invention, after the decoding thread starts decoding from the timestamp position of the keyframe until it decodes to the current timestamp position and saves the decoded data to the cache data, before the playback thread starts playing the video in reverse after the cache data stores the data at the current timestamp position, and before the playback thread deletes the played frame from the cache data after playing each frame, the method further includes the following steps:

[0012] While the decoding thread begins decoding, the playback thread enters a pause mode or a temporary playback mode.

[0013] When the playback thread enters the pause mode, the playback thread starts playing the cached data from the key frame until the cached data stores the data at the current timestamp, and then ends the pause mode.

[0014] When the playback thread is in pause mode, the playback thread plays the key frame. When the cached data stores the data of the current timestamp, the playback screen switches to the frame of the current timestamp.

[0015] In an optional embodiment of the first aspect of the present invention, when the playback thread enters the pause mode, the playback thread reduces the playback frame rate.

[0016] In an optional embodiment of the first aspect of the present invention, after receiving the instruction to reverse the video, the steps of scanning the video, recording the timestamp values ​​of all key frames, and obtaining a key frame index table are as follows:

[0017] Determine whether the current video frame is a keyframe based on the flag information in the video packet data;

[0018] When the flag information of the video frame is a keyframe, the timestamp value of the keyframe is recorded.

[0019] In an optional embodiment of the first aspect of the present invention, while the playback thread starts playing the video in reverse, a desired timestamp is calculated, wherein the desired timestamp is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, the timestamp of the desired keyframe that is closest to and less than the desired timestamp is found according to the keyframe index table. Then, the decoding thread starts decoding from the timestamp of the desired keyframe until the position of the desired timestamp is reached, and the decoded data is saved to the cache data. The next desired timestamp is recalculated, and decoding is performed between the next desired timestamp and the timestamp of the next desired keyframe that is closest to and less than the next desired timestamp, until the video decoding is completed.

[0020] When the number of frames between the expected timestamp and the expected keyframe timestamp is greater than a first threshold, the decoding thread will delete some frames between the expected timestamp and the expected keyframe timestamp, so that the number of decoded frames is equal to the first threshold, wherein frames closer to the keyframe are deleted first.

[0021] In an optional embodiment of the first aspect of the present invention, after the cached data stores the data of the current timestamp position, the playback thread starts to reverse the video, and the playback thread deletes the played frame from the cached data after playing each frame.

[0022] When the number of cached image groups in the cached data is equal to the second threshold, the decoding thread stops decoding until the number of cached image groups in the cached data is less than the second threshold, at which point the decoding thread resumes decoding.

[0023] In an optional embodiment of the first aspect of the present invention, in the step of finding the timestamp of the key frame that is closest to and less than the current timestamp according to the key frame index table;

[0024] The playback thread uses a seek operation to change the position of the video stream to the position of the timestamp of the keyframe.

[0025] A second aspect of the present invention provides a system for reversing video playback, comprising:

[0026] The scanning module is used to scan the video after receiving the instruction to reverse the video, record the timestamp values ​​of all keyframes, and obtain a keyframe index table.

[0027] The search module is used to find the timestamp of the key frame that is closest to and less than the current timestamp, based on the key frame index table.

[0028] The first decoding module is used to decode the keyframe starting from the timestamp position until the current timestamp position is reached, and to save the decoded data to the cache data.

[0029] The playback module is used to start playing the video in reverse after the cached data contains the data of the current timestamp position, and the playback thread deletes the played frame from the cached data after each frame is played.

[0030] The second decoding module is used to calculate the expected timestamp when the playback thread starts playing the video in reverse. The expected timestamp is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, according to the keyframe index table, the timestamp of the expected keyframe that is closest to and less than the expected timestamp is found. Then, the decoding thread starts decoding from the timestamp of the expected keyframe until it reaches the position of the expected timestamp, and saves the decoded data to the cache data. The next expected timestamp is recalculated, and decoding is performed between the next expected timestamp and the timestamp of the next expected keyframe that is closest to and less than the next expected timestamp, until the video decoding is completed.

[0031] A third aspect of the present invention provides a video reversal terminal, the terminal comprising: a memory and at least one processor, the memory storing instructions, and the memory and the at least one processor being interconnected via a line;

[0032] The at least one processor invokes the instructions in the memory to cause the terminal to perform the video reversal method as described in any one of the above statements.

[0033] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the video reversal method as described in any one of the above descriptions.

[0034] Beneficial Effects: This invention provides a method, system, terminal, and storage medium for video reverse playback. The method includes, upon receiving a video reverse playback instruction, scanning the video, recording the timestamp values ​​of all keyframes to obtain a keyframe index table; finding the timestamp of the keyframe closest to and less than the current timestamp according to the keyframe index table; a decoding thread starting from the position of the timestamp of the keyframe and decoding until the current timestamp is reached, and saving the decoded data to a cache; once the cache contains the data at the current timestamp, a playback thread starts reversing the video, and after each frame is played, the playback thread removes the completed frame from the cache. The data is deleted from the cache. Simultaneously with the playback thread starting to reverse the video, the expected timestamp is calculated. This expected timestamp is equal to the timestamp of the keyframe from the previous decoding minus the inter-frame interval. Then, based on the keyframe index table, the timestamp of the expected keyframe closest to and less than the expected timestamp is found. The decoding thread then starts decoding from the timestamp of the expected keyframe until it reaches the desired timestamp, saving the decoded data to the cache. The next expected timestamp is recalculated, and decoding is performed between this next expected timestamp and the timestamp of the next expected keyframe closest to and less than the next expected timestamp, until the video decoding is complete. By generating a keyframe index table instead of caching keyframe video data, subsequent operations can quickly locate keyframe positions, and memory usage is reduced. Attached Figure Description

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

[0036] Figure 1 This is a schematic diagram of an embodiment of a video reversal method according to the present invention;

[0037] Figure 2 This is a schematic diagram of an embodiment of a video reversal system according to the present invention;

[0038] Figure 3 This is a schematic diagram of an embodiment of a video reversal terminal according to the present invention.

[0039] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0040] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0041] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0042] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0043] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0044] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0045] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 The first aspect of the present invention provides a method for reversing video playback, comprising the following steps:

[0046] S100: After receiving the instruction to reverse the video, scan the video, record the timestamp values ​​of all keyframes, and obtain the keyframe index table;

[0047] S200: Find the timestamp of the key frame that is closest to and less than the current timestamp according to the key frame index table;

[0048] S300: The decoding thread starts decoding from the timestamp position of the keyframe until it decodes to the current timestamp position, and saves the decoded data to the cache data;

[0049] S400: When the cached data contains the data of the current timestamp position, the playback thread starts playing the video in reverse, and after each frame is played, the playback thread deletes the played frame from the cached data.

[0050] S500: While the playback thread starts playing the video in reverse, calculate the expected timestamp, where the expected timestamp is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, find the timestamp of the expected keyframe that is closest to and less than the expected timestamp according to the keyframe index table. Then, the decoding thread starts decoding from the timestamp of the expected keyframe until it reaches the position of the expected timestamp, and saves the decoded data to the cache data. Recalculate the next expected timestamp, and decode between the next expected timestamp and the timestamp of the next expected keyframe that is closest to and less than the next expected timestamp, until the video decoding is finished.

[0051] In this embodiment, scanning is only performed the first time the current video enters reverse playback mode. If the video switches back to normal mode and then re-enters reverse playback mode, scanning is unnecessary. However, if a different video is used, scanning is still required. Furthermore, only the timestamp values ​​of keyframes need to be cached, not the video frame data, resulting in very low memory usage. Because keyframes contain data that other video frames depend on, decoding must begin from the keyframes for subsequent video frames to obtain complete data; otherwise, issues such as screen tearing may occur.

[0052] In an optional embodiment of the first aspect of the present invention, after the decoding thread starts decoding from the timestamp position of the keyframe until it decodes to the current timestamp position and saves the decoded data to the cache data, before the playback thread starts playing the video in reverse after the cache data stores the data at the current timestamp position, and before the playback thread deletes the played frame from the cache data after playing each frame, the following steps are further included:

[0053] While the decoding thread begins decoding, the playback thread enters a pause mode or a temporary playback mode.

[0054] When the playback thread enters the pause mode, the playback thread starts playing the cached data from the key frame until the cached data stores the data at the current timestamp, and then ends the pause mode.

[0055] When the playback thread is in pause mode, the playback thread plays the key frame. When the cached data stores the data of the current timestamp, the playback screen switches to the frame of the current timestamp.

[0056] In this embodiment, decoding from the timestamp of a keyframe to the current timestamp takes a certain amount of time. If the image remains static during this time, it will not provide a good user experience. Therefore, in playback mode, playback starts directly from the keyframe to provide a better user experience. At the same time, since the image differences within the same image group are not significant, the changes when switching to the current timestamp image will not be significant, thus achieving a good balance between smoothness and visual effect.

[0057] In an optional embodiment of the first aspect of the present invention, when the playback thread enters the pause mode, the playback thread reduces the playback frame rate.

[0058] In this embodiment, by reducing the playback frame rate, the decoding thread is prevented from decoding too slowly, which could cause stuttering.

[0059] In an optional embodiment of the first aspect of the present invention, after receiving the instruction to reverse the video, the steps of scanning the video, recording the timestamp values ​​of all key frames, and obtaining a key frame index table are as follows:

[0060] Determine whether the current video frame is a keyframe based on the flag information in the video packet data;

[0061] When the flag information of the video frame is a keyframe, the timestamp value of the keyframe is recorded.

[0062] In this embodiment, since the flag information of the video packet data before decoding can determine whether the current video frame is a key frame, decoding is not required, and the whole process takes a relatively short time.

[0063] In an optional embodiment of the first aspect of the present invention, while the playback thread starts playing the video in reverse, a desired timestamp is calculated, wherein the desired timestamp is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, the timestamp of the desired keyframe that is closest to and less than the desired timestamp is found according to the keyframe index table. Then, the decoding thread starts decoding from the timestamp of the desired keyframe until the position of the desired timestamp is reached, and the decoded data is saved in the cache data. The next desired timestamp is recalculated, and decoding is performed between the next desired timestamp and the timestamp of the next desired keyframe that is closest to and less than the next desired timestamp, until the video decoding is completed.

[0064] When the number of frames between the expected timestamp and the expected keyframe timestamp is greater than a first threshold, the decoding thread will delete some frames between the expected timestamp and the expected keyframe timestamp, so that the number of decoded frames is equal to the first threshold, wherein frames closer to the keyframe are deleted first.

[0065] In this embodiment, all video frame data between the desired keyframe timestamp and the desired timetamp are cached. These data are less than or equal to one image group. Within the same image group, there is a set of video frames with a difference in image quality less than a specific threshold. The keyframe is the first frame of this image group. Typically, an image group contains a dozen or so frames, so the memory usage is not large. A first threshold can be set. When the number of cached frames exceeds the first threshold, they are removed according to the order in which they were added to the cache. That is, video frames closer to the keyframe will be removed from the cache first. This is because when playing back in reverse, video frames farther from the keyframe will be played earlier and should therefore be kept in the cache.

[0066] In an optional embodiment of the first aspect of the present invention, after the cached data stores the data of the current timestamp position, the playback thread starts to reverse the video, and the playback thread deletes the played frame from the cached data after playing each frame.

[0067] When the number of cached image groups in the cached data is equal to the second threshold, the decoding thread stops decoding until the number of cached image groups in the cached data is less than the second threshold, at which point the decoding thread resumes decoding.

[0068] In this embodiment, by setting a second threshold, excessive decoding data can be prevented from being cached in the playback thread.

[0069] In an optional embodiment of the first aspect of the present invention, in the step of finding the timestamp of the key frame that is closest to and less than the current timestamp according to the key frame index table;

[0070] The playback thread uses a seek operation to change the position of the video stream to the position of the timestamp of the keyframe.

[0071] See Figure 2 A second aspect of the present invention provides a system for reversing video playback, comprising:

[0072] The scanning module 10 is used to scan the video after receiving the instruction to reverse the video, record the timestamp values ​​of all key frames, and obtain a key frame index table.

[0073] The searching module 20 is used to find the timestamp of the key frame that is closest to and less than the current timestamp according to the key frame index table.

[0074] The first decoding module 30 is used for the decoding thread to start decoding from the position of the timestamp of the key frame until the position of the current timestamp is reached, and to save the decoded data to the cache data;

[0075] The playback module 40 is configured to, after the cached data contains the data of the current timestamp position, start the playback thread to play the video in reverse, and delete the played frame from the cached data after each frame is played.

[0076] The second decoding module 50 is used to calculate the expected timestamp when the playback thread starts playing the video in reverse, wherein the expected timestamp is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, according to the keyframe index table, the timestamp of the expected keyframe that is closest to and less than the expected timestamp is found. Then, the decoding thread starts decoding from the timestamp of the expected keyframe until it reaches the position of the expected timestamp, and saves the decoded data to the cache data. The next expected timestamp is recalculated, and decoding is performed between the next expected timestamp and the timestamp of the next expected keyframe that is closest to and less than the next expected timestamp, until the video decoding is completed.

[0077] Figure 3This is a schematic diagram of the structure of a video reversal terminal provided in an embodiment of the present invention. The video reversal terminal can vary significantly due to differences in configuration or performance, and may include one or more processors 1 (central processing units, CPUs) (e.g., one or more processors) and memory 2, and one or more storage media 3 (e.g., one or more mass storage devices) for storing applications or data. The memory and storage media can be temporary or persistent storage. The program stored in the storage media may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the video reversal terminal. Furthermore, the processor may be configured to communicate with the storage media to execute the series of instruction operations stored in the storage media on the video reversal terminal.

[0078] The video reversal terminal of the present invention may further include one or more power supplies 4, one or more wired or wireless network interfaces 5, one or more input / output interfaces 6, and / or one or more operating systems, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 3 The terminal structure shown for video reversal does not constitute a limitation on the terminal for video reversal. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0079] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the video reversal method.

[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system, device, or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0081] If the integrated 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, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0082] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural transformations made under the concept of the present invention using the description and drawings of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A method for reversing video playback, characterized in that, Includes the following steps: After receiving the instruction to reverse the video, scan the video, record the timestamp values ​​of all keyframes, and obtain the keyframe index table; Find the timestamp of the key frame that is closest to and less than the current timestamp based on the key frame index table; The decoding thread starts decoding from the timestamp of the keyframe and continues until it reaches the current timestamp, saving the decoded data to the cache. Once the cached data contains the data of the current timestamp position, the playback thread starts playing the video in reverse, and after each frame is played, the playback thread deletes the played frame from the cached data. While the playback thread starts playing the video in reverse, it calculates the expected timestamp, which is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, according to the keyframe index table, it finds the timestamp of the expected keyframe that is closest to and less than the expected timestamp. The decoding thread then starts decoding from the timestamp of the expected keyframe until it reaches the expected timestamp, and saves the decoded data to the cache. It then recalculates the next expected timestamp and decodes between the next expected timestamp and the timestamp of the next expected keyframe that is closest to and less than the next expected timestamp, until the video decoding is finished. After the decoding thread starts decoding from the timestamp of the keyframe until it reaches the current timestamp and saves the decoded data to the cache data, and before the playback thread starts playing the video in reverse after the cache data contains the data at the current timestamp, and before the playback thread deletes the played frame from the cache data after each frame is played, the following steps are also included: While the decoding thread begins decoding, the playback thread enters a pause mode or a temporary playback mode. When the playback thread enters the pause mode, the playback thread starts playing the cached data from the key frame until the cached data stores the data at the current timestamp, and then ends the pause mode. When the playback thread is in pause mode, the playback thread plays the key frame. When the cached data stores the data of the current timestamp, the playback screen switches to the frame of the current timestamp. Simultaneously with the playback thread starting to reverse the video, a desired timestamp is calculated, where the desired timestamp is equal to the timestamp of the keyframe from the previous decoding minus the inter-frame interval. Then, based on the keyframe index table, the timestamp of the desired keyframe that is closest to and less than the desired timestamp is found. The decoding thread then starts decoding from the timestamp of the desired keyframe until it reaches the desired timestamp, saving the decoded data to the buffer. The next desired timestamp is recalculated, and decoding is performed between the next desired timestamp and the timestamp of the next desired keyframe that is closest to and less than the next desired timestamp, until the video decoding is complete. When the number of frames between the expected timestamp and the expected keyframe timestamp is greater than a first threshold, the decoding thread will delete some frames between the expected timestamp and the expected keyframe timestamp, so that the number of decoded frames is equal to the first threshold, wherein frames closer to the keyframe are deleted first.

2. The method for reversing video playback according to claim 1, characterized in that, When the playback thread enters pause mode, the playback thread reduces the playback frame rate.

3. The method for reversing video playback according to claim 1, characterized in that, After receiving the instruction to reverse the video, the process of scanning the video, recording the timestamp values ​​of all keyframes, and obtaining the keyframe index table is as follows: Determine whether the current video frame is a keyframe based on the flag information in the video packet data; When the flag information of the video frame is a keyframe, the timestamp value of the keyframe is recorded.

4. The method for reversing video playback according to claim 1, characterized in that, In the step where the playback thread starts reversing the video after the cached data contains the data of the current timestamp position, and the playback thread deletes the played frame from the cached data after each frame is played: When the number of cached image groups in the cached data is equal to the second threshold, the decoding thread stops decoding until the number of cached image groups in the cached data is less than the second threshold, at which point the decoding thread resumes decoding.

5. The method for reversing video playback according to claim 1, characterized in that, In the step of finding the timestamp of the keyframe that is closest to and less than the current timestamp according to the keyframe index table: The playback thread uses a seek operation to change the position of the video stream to the position of the timestamp of the keyframe.

6. A system for reversing video playback, characterized in that, include: The scanning module is used to scan the video after receiving the instruction to reverse the video, record the timestamp values ​​of all keyframes, and obtain a keyframe index table. The search module is used to find the timestamp of the key frame that is closest to and less than the current timestamp, based on the key frame index table. The first decoding module is used to decode the keyframe starting from the timestamp position until the current timestamp position is reached, and to save the decoded data to the cache data. The playback module is used to start playing the video in reverse after the cached data contains the data of the current timestamp position, and the playback thread deletes the played frame from the cached data after each frame is played. The second decoding module is used to calculate the expected timestamp when the playback thread starts playing the video in reverse. The expected timestamp is equal to the timestamp of the keyframe during the last decoding minus the inter-frame interval. Then, according to the keyframe index table, the timestamp of the expected keyframe that is closest to and less than the expected timestamp is found. Then, the decoding thread starts decoding from the timestamp of the expected keyframe until it reaches the position of the expected timestamp, and saves the decoded data to the cache data. The next expected timestamp is recalculated, and decoding is performed between the next expected timestamp and the timestamp of the next expected keyframe that is closest to and less than the next expected timestamp, until the video decoding is completed. The video reverse playback system also includes a reverse playback pre-buffer module, which is used for: While the decoding thread begins decoding, the playback thread enters a pause mode or a temporary playback mode. When the playback thread enters the pause mode, the playback thread starts playing the cached data from the key frame until the cached data stores the data at the current timestamp, and then ends the pause mode. When the playback thread is in pause mode, the playback thread plays the key frame. When the cached data stores the data of the current timestamp, the playback screen switches to the frame of the current timestamp. The video reverse playback system also includes a frame skipping pre-buffering module, which is used for: When the number of frames between the expected timestamp and the expected keyframe timestamp is greater than a first threshold, the decoding thread will delete some frames between the expected timestamp and the expected keyframe timestamp, so that the number of decoded frames is equal to the first threshold, wherein frames closer to the keyframe are deleted first.

7. A terminal for reversing video playback, characterized in that, The terminal includes: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the terminal to perform the video reversal method as described in any one of claims 1-5.

8. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the video reversal method as described in any one of claims 1-5.

Images