CN111447486A

CN111447486A - Reverse playing method for forward pushing of historical code stream

Info

Publication number: CN111447486A
Application number: CN202010265010.3A
Authority: CN
Inventors: 王丹; 师少飞; 刘其峰; 王小虎; 王继能
Original assignee: Shanghai Sailing Information Technology Co ltd
Current assignee: Shanghai Sailing Information Technology Co ltd
Priority date: 2020-04-07
Filing date: 2020-04-07
Publication date: 2020-07-24

Abstract

The invention discloses a reverse playing method for forward pushing of historical code streams, which relates to the field of reverse playing and connection of video code streams, and comprises the following steps: acquiring a current timestamp and sending a historical video reverse playing request; receiving a reverse play code stream, and decoding when a stream time stamp is smaller than the current time stamp; decoding the GOP needing to be played in reverse order, and recording the decoded data information into a corresponding data file; and after decoding is finished, acquiring the data information in the data file in a reverse order and displaying the data information in sequence. By implementing the invention, the additional process memory is not needed, the performance and the stability are improved, no frame skipping, no card frame and no screen splash are carried out in the reverse direction, and the simultaneous reverse playing of multiple paths of high-definition code streams is supported.

Description

Reverse playing method for forward pushing of historical code stream

Technical Field

The invention relates to the field of video code stream reverse playing and linking, in particular to a reverse playing method for forward pushing of historical code streams.

Background

With the continuous expansion of the application range of the security industry, the large integration of services, the scene and the diversification of applications and the popularization of artificial intelligence of the security industry are realized, and in addition, the technologies such as face recognition, language recognition, image recognition and the like are combined with corresponding services in various fields, so that the integration and the application of various small platforms and large and medium platforms to intelligent services are promoted. Video data is one of the main data sources of a safe city, and is very important for the analysis and application of the video data. In the field of security application, particularly in the field of video networking monitoring, video data needs to be collected and subjected to corresponding structural analysis, specific details in specific scenes are extracted, and investigation or case solving is carried out through cyclic and repeated previewing of specific pictures.

The existing method for realizing the reverse playing mainly comprises the following steps: the first method is that a lower platform supports a reverse playing signaling and correctly pushes a video appointed to be reversely played, the scheme completely depends on the lower platform, and if the lower platform does not support, the reverse playing operation of historical videos cannot be finished; the other scheme is that a video is requested from a lower-level platform, the corresponding video is buffered in a cache, and then data in the cache is numbered, decoded and played in a reverse order.

Therefore, those skilled in the art are dedicated to develop a reverse playing method based on forward pushing of historical code streams, no additional process memory is needed, performance and stability are improved, reverse frame skipping, card frame blocking and screen flashing are avoided, and simultaneous reverse playing of multiple paths of high-definition code streams is supported.

Disclosure of Invention

In view of the above defects in the prior art, the technical problems to be solved by the present invention are that the occupation of the picture card segment, the screen splash and the frame skip in the process of reverse playing is too high, and the memory has a large range of wave pairs according to the code rate and the resolution of the video code stream, and cannot realize efficient and stable support for multiple high-definition code streams.

In order to achieve the above object, the present invention provides a reverse playing method for forward pushing a history code stream, including:

step 1, acquiring a current timestamp and sending a historical video reverse playing request;

step 2, receiving the reverse play code stream, and decoding when the stream time stamp is smaller than the current time stamp;

step 3, decoding the GOP needing to be played in reverse order, and recording the decoded data information into a corresponding data file;

and 4, after decoding is finished, acquiring the data information in the data file in a reverse order and displaying the data information in sequence.

Further, the step 1 comprises:

requesting historical videos 4 times forward of the current timestamp, wherein the time periods are 1s, 2s, 4s, 8s and 16s forward;

and the current timestamp is timestamp information of the current playing frame.

Further, the step 4 comprises:

judging whether a key frame exists in the reverse play code stream, if so, buffering data from the key frame, and recording timestamp information of the key frame;

and when the stream timestamp is larger than the current timestamp, continuing to receive the reverse play stream.

Further, the step 3 comprises:

creating a decoding thread;

a decode queue is created.

Further, the decoding thread includes:

reading the GOP in the buffer closest to the current timestamp;

naming and caching the decoded data to a local disk according to the timestamp information;

and recording the decoded GOP queue, and recording the timestamp information of the current decoding queue into the decoding queue.

Further, the step 3 further comprises:

setting the position of a stream collection marker after the GOP decoding requested last time is completed;

and after the stream receiving mark position is set, starting a new round of receiving and playing the code stream backwards and starting the decoding thread.

Further, when the stream timestamp is greater than the current timestamp, the stream receiving flag bit is cleared, and the reception of the reverse play code stream is suspended.

Further, the step 4 comprises:

step 4.1, creating a display thread;

step 4.2, the display thread records the timestamp information displayed currently;

4.3, the display thread acquires the last timestamp information in the decoding queue, and reads corresponding YUV data information from a local disk for display according to the information;

and 4.4, judging whether the buffer size of the YUV is smaller than the GOP size by the display thread.

Further, the step 4.3 comprises:

if the difference value between the current timestamp information and the last timestamp information in the decoding queue is more than 3600, waiting; otherwise, the last data is obtained for playing.

Further, the step 4.4 includes:

the YUV buffer size is smaller than the GOP size, video frames corresponding to the timestamps in the decoding queue are sequentially displayed, and the current display timestamp information is synchronously updated;

and the YUV buffer size is larger than the GOP size, the last timestamp information in the decoding queue is obtained again, and corresponding YUV data information is read from a local disk for display according to the information.

Compared with the prior art, the invention at least has the following beneficial technical effects:

1. the problems of frame skipping, blockage and screen blooming in the process of reverse playing are solved;

2. the corresponding decoded picture is stored on the disk in the reverse playing process, so that the operation on the memory is not needed, and the stability and the performance are improved;

3. the multi-channel high-definition variable-code-rate video support does not influence the memory occupied by the process, and the multi-channel reverse playing is efficiently supported.

The conception, the specific structure and the technical effects of the present invention will be further described with reference to the accompanying drawings to fully understand the objects, the features and the effects of the present invention.

Drawings

FIG. 1 is a flow chart of the steps of the present invention;

FIG. 2 is an inverse flow chart of the present invention;

FIG. 3 is an overall frame diagram of the present invention;

FIG. 4 is a principal business flow diagram of the present invention;

FIG. 5 is an overall flow diagram of the present invention;

FIG. 6 is a data queue data structure of the present invention;

FIG. 7 is a decode queue data structure of the present invention;

fig. 8 is a GOP queue data structure of the present invention.

Detailed Description

The technical contents of the preferred embodiments of the present invention will be more clearly and easily understood by referring to the drawings attached to the specification. The present invention may be embodied in many different forms of embodiments and the scope of the invention is not limited to the embodiments set forth herein.

In the drawings, structurally identical elements are represented by like reference numerals, and structurally or functionally similar elements are represented by like reference numerals throughout the several views. The size and thickness of each component shown in the drawings are arbitrarily illustrated, and the present invention is not limited to the size and thickness of each component. The thickness of the components may be exaggerated where appropriate in the figures to improve clarity.

As shown in fig. 1, the process of the present invention includes:

step 101, obtaining a current timestamp, and sending a historical video reverse playing request.

Wherein, the current timestamp requests the historical video 4 times ahead, the time period is 1s, 2s, 4s, 8s, 16s ahead, so as to reduce the signaling pressure of the lower platform, and simultaneously ensure that the local has enough buffer data to ensure the continuous playing of the picture.

And 102, receiving the reverse play code stream, and decoding when the stream time stamp is smaller than the current time stamp.

And 103, decoding the GOPs needing to be played in the reverse order, and recording the decoded data information into a corresponding data file.

And decoding the requested video and storing the decoded picture under a folder of a corresponding channel on an appointed disk according to a certain rule. And in the process of reverse playing, a synchronous request of the code stream and updating of the buffer frame are carried out according to the condition of the storage frame of the disk, the connection is carried out according to the timestamp of the frame of the code stream pushed by the lower platform, and the frame smaller than the current timestamp is stored in the disk and the corresponding queue.

And step 104, after the decoding is finished, acquiring the data information in the data file in a reverse order and displaying the data information in sequence. And performing reverse-order playing according to the timestamp information of the current queue during playing.

As shown in fig. 2, the reverse play process of the present invention includes:

in step 201, it is determined whether the flow reception flag is 1.

Step 202, receiving and analyzing the data, storing original data for buffering and recording current timestamp information, and storing data GOP information to a queue according to the analysis, wherein the data GOP information comprises GOP serial numbers and frame serial numbers.

Step 203, determine whether the stream timestamp is greater than the current timestamp. If yes, step 204, if no, step 205.

And step 204, clearing the stream receiving mark, suspending stream receiving, updating the current time stamp, and recording the current GOP sequence number and the GOP size.

Step 205, the decoding thread reads the original data and acquires the GOP data according to the current GOP sequence number.

And step 206, decoding a GOP data, storing the decoded GOP data in a specified disk directory, and recording a GOP decoded queue of the decoded data.

Step 207, determine whether the last requested GOP decoding is complete. If so, step 208, if not step 205.

In step 208, the receive flag is set.

And step 209, the display thread acquires data according to the decoded GOP serial number, and reads corresponding YUV data information from the local disk for display. And if the difference value between the current timestamp information and the last timestamp information in the queue is greater than 3600, waiting, otherwise, acquiring the last data for playing.

Step 210, determine whether the YUV buffer size is smaller than the GOP size. If yes, step 211, if no, step 209.

Step 211, synchronously displaying and updating the time stamp.

As shown in fig. 3, the overall framework diagram of the present invention, based on which the main business flow diagram of the present invention is shown in fig. 4, includes:

step 401, create 75+25M memory (about 3s data +1 GOP decoded data), where the data queue data structure is shown in fig. 6.

Step 402, create a stream GOP queue, wherein the GOP queue data structure is shown in fig. 8.

Step 403, binding the GOP and the data frame.

Step 404, the received 264 data is stored in a memory and structured.

And step 405, stopping receiving the stream when the stream time stamp is larger than the current time stamp.

Step 406, obtaining the current GOP, and decoding the GOP queue of the current request, wherein the data structure of the decoding queue is shown in fig. 7.

Step 407, entering a decoding buffer pool after decoding.

And step 408, synchronously displaying after all the GOPs are decoded.

And step 409, recovering the flow collection.

As shown in FIG. 5, the overall flow chart of the present invention includes the forward cut-reverse placement and the reverse cut-forward placement. Wherein, the forward cutting and reverse placing comprises the following steps: video on demand, namely recording a screen of the played video and storing the record; switching to reverse playing, stopping screen recording operation, and closing the file; checking the length of the screen recording file, and deleting the file which is too small; and judging whether the frame of the current timestamp is in the screen recording file or not, if so, playing the local file, and otherwise, requesting the video forward by the current timestamp.

The foregoing detailed description of the preferred embodiments of the invention has been presented. It should be understood that numerous modifications and variations could be devised by those skilled in the art in light of the present teachings without departing from the inventive concepts. Therefore, the technical solutions available to those skilled in the art through logic analysis, reasoning and limited experiments based on the prior art according to the concept of the present invention should be within the scope of protection defined by the claims.

Claims

1. A reverse playing method for forward pushing of historical code streams is characterized by comprising the following steps:

2. The backward playing method for forward pushing of historical code streams according to claim 1, wherein the step 1 comprises:

3. The backward playing method for forward pushing of historical code streams according to claim 1, wherein the step 2 includes:

4. The backward playing method for forward pushing of historical code streams according to claim 1, wherein the step 3 comprises:

creating a decoding thread;

a decode queue is created.

5. The backward method for forward pushing of historical code streams according to claim 4, wherein the decoding thread comprises:

reading the GOP in the buffer closest to the current timestamp;

6. The backward playing method for forward pushing of historical code streams according to claim 5, wherein the step 3 further comprises:

7. The backward playing method for forward pushing of historical code streams according to claim 3, wherein when the stream timestamp is greater than the current timestamp, the stream receiving flag bit is cleared, and the reception of the backward playing code stream is suspended.

8. The backward playing method for forward pushing of history code stream according to claim 1, wherein the step 4 comprises:

step 4.1, creating a display thread;

9. The backward playing method for forward pushing of history code stream according to claim 8, wherein the step 4.3 comprises:

10. The backward playing method for forward pushing of history code stream according to claim 8, wherein the step 4.4 comprises:

and if the buffer size of the YUV is larger than the size of one GOP, re-acquiring the last timestamp information in the decoding queue, and reading the corresponding YUV data information from a local disk according to the information to display.