A video monitoring play method and system

Abstract

The application discloses a video monitoring playing method and system, which realizes the negotiation of sip signaling between a client and a video acquisition front end or a streaming media server, and the streaming media server directly sends an I frame in response to a real-time display priority identifier, the client decodes and displays a picture immediately after receiving the I frame, the video acquisition front end or the streaming media server sends the encoded video data at a maximum rate in response to a time delay priority identifier, and the normal rate is returned to send the real-time encoded video data after the encoded video data is sent, and the client reduces the time delay through a fast playing mechanism. The application solves the technical problem that the existing video monitoring playing method reduces the time interval of no video picture display by increasing the I frame frequency and changing the video encoding mode, which reduces the video encoding compression efficiency and is not suitable for the distribution and forwarding of the video data through the streaming media service mode.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of database technology, and in particular to a video monitoring playing method and system. BACKGROUND

[0002] Before the current video is transmitted over a network, the video data needs to be encoded and compressed to reduce the network bandwidth occupied by the video data in network transmission. In order to avoid the occupation of network bandwidth by multiple people calling the same video at the same time, a streaming media service mode is usually used to distribute and forward the media data. According to the video encoding characteristics, the video data can only be decoded and displayed after the I frame data is received by the requesting terminal. Therefore, the video data before the I frame is received is invalid data, so that the video picture cannot be displayed during the period from the requesting terminal to the reception of the I frame data. In order to reduce the time interval of no video picture display and increase the response speed of video picture display, it is usually required to adjust the video compression encoding mode of the video acquisition device and increase the frequency of I frame in video encoding. This will reduce the efficiency of video encoding and compression. At the same time, since the streaming media server cannot adjust the video compression encoding mode, this mode is also not suitable for distributing and forwarding the video data through the streaming media service mode. Whether for video live broadcast or video on demand, the process from the user's request to play the video stream to the display of the video picture occupies too much time, which will reduce the user experience. Therefore, how to design a video playing method that improves the picture display real-time performance and low latency of video monitoring playing without increasing the frequency of I frame and changing the video encoding mode is a technical problem that needs to be solved by those skilled in the art. SUMMARY

[0003] The present application provides a video monitoring playing method and system for improving the picture display real-time performance and low latency of video monitoring playing without increasing the frequency of I frame and changing the video encoding mode, which solves the technical problem that the existing video monitoring playing method reduces the efficiency of video encoding and compression and is not suitable for distributing and forwarding the video data through the streaming media service mode by increasing the frequency of I frame and changing the video encoding mode.

[0004] Therefore, the first aspect of the present application provides a video monitoring playing method, comprising:

[0005] The client sends a video monitoring playing request to the video acquisition front end or the streaming media server through the sip signaling in response to the user's video monitoring playing request, and requests to obtain the video monitoring picture, wherein the video monitoring playing request carries a real-time display priority identifier and a latency priority identifier;

[0006] The video acquisition front end or the streaming media server responds to the video monitoring playing request;

[0007] If the video acquisition front end or the stream media server supports real-time display priority but does not support time delay priority, the video stream is returned to the client from the coded I frame closest to the time point of the request for playing, and the number of video frames from the I frame is fed back to the client through the sip signaling;

[0008] The client decodes and displays the picture immediately after receiving the video stream I frame;

[0009] If the video acquisition front end or the stream media server supports real-time display priority and supports time delay priority, the video stream is returned to the client at the maximum rate from the coded I frame closest to the time point of the request for playing, and the number of video frames from the I frame is fed back to the client through the sip signaling until the first video data is completely sent, and then the second video data encoded in real time by the video acquisition front end or the stream media server is sent at a normal speed;

[0010] After receiving the video data, the client extracts the number of video frames from the I frame fed back by the video acquisition front end or the stream media server, starts the fast playing mechanism, and then returns to the normal playing speed to play the second video data after the video frames of the first video data are played at the preset speed.

[0011] Optionally, the preset speed is the maximum playing speed supported by the client.

[0012] The second aspect of the application provides a video monitoring playing system, comprising a client and a video acquisition front end or a stream media server.

[0013] The client is used for:

[0014] In response to a video monitoring playing request of a user, the client sends a video monitoring playing request to the video acquisition front end or the stream media server through sip signaling to request to obtain a video monitoring picture, wherein the video monitoring playing request carries a real-time display priority identifier and a time delay priority identifier.

[0015] When the video acquisition front end or the stream media server supports real-time display priority but does not support time delay priority, the video stream I frame is decoded and displayed immediately after being received.

[0016] When the video acquisition front end or the stream media server supports real-time display priority and supports time delay priority, after receiving the video data, the number of video frames from the I frame fed back by the video acquisition front end or the stream media server is extracted, the fast playing mechanism is started, and then the normal playing speed is returned to play the second video data after the video frames of the first video data are played at the preset speed.

[0017] The video acquisition front end or the stream media server is used for:

[0018] responding to a video monitoring playing request;

[0019] if real-time display priority is supported but time delay priority is not supported, starting from a video coding I frame closest to a request playing time point, returning a video stream to the client, and feeding back a video frame number from the I frame to the client through the sip signaling;

[0020] if real-time display priority is supported and time delay priority is supported, starting from a video coding I frame closest to a request playing time point, returning a video stream to the client at a maximum rate, feeding back a video frame number from the I frame to the client through the sip signaling, until all the coded first video data is sent, and then sending second video data coded in real time by the video acquisition front end or the streaming media server at a normal speed.

[0021] Optionally, the preset speed is a maximum playing speed supported by the client.

[0022] From the above technical solution, it can be seen that the video monitoring playing method and system provided by the application has the following advantages:

[0023] The video monitoring playing method provided by the application, through sip signaling negotiation between the client and the video acquisition front end or the streaming media server, after the video acquisition front end or the streaming media server responds to the real-time display priority identifier, directly sending the I frame, the client immediately decodes and displays the picture when receiving the I frame, improving the picture display real-time performance, through the video acquisition front end or the streaming media server responding to the time delay priority identifier, sending the coded video data at a maximum rate, after the coded video data is sent, returning to the normal rate to send the video data coded in real time, the client realizes the low time delay of the end-to-end picture through the fast playing mechanism, realizes the improvement of the picture display real-time performance and the playing low time delay of the video monitoring playing without increasing the I frame frequency and changing the video coding mode, solves the technical problem that the existing video monitoring playing method reduces the time interval of no video picture display by increasing the I frame frequency and changing the video coding mode, which not only reduces the video coding compression efficiency, but also is not suitable for the video data distribution and forwarding through the streaming media service mode.

[0024] The video monitoring playing system provided by the application is used to execute the video monitoring playing method provided by the application, and the principle and the technical effects obtained are the same as those of the video monitoring playing method provided by the application, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained without creative labor.

[0026] Figure 1 A flowchart of a video monitoring and playing method provided in the present application is shown in the figure.

[0027] Figure 2 A schematic diagram of a video encoding and compression principle is shown in the figure.

[0028] Figure 3 A structural schematic diagram of a video monitoring and playing system provided in the present application is shown in the figure. DETAILED DESCRIPTION

[0029] In order to make the person skilled in the art better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0030] For the convenience of understanding, please refer to Figure 1 An embodiment of a video monitoring and playing method provided in the present application comprises the following steps.

[0031] Step 101: The client sends a video monitoring and playing request to a video acquisition front end or a streaming media server through a sip signaling in response to a video monitoring and playing request of a user, and requests to obtain a video monitoring picture, wherein the video monitoring and playing request carries a real-time display priority identifier and a time delay priority identifier.

[0032] It should be noted that in the embodiment of the present application, when the user has a playing request, the client sends a video monitoring and playing request, and the client responds to the video monitoring and playing request after receiving the video monitoring and playing request of the user, and sends the video monitoring and playing request to the video acquisition front end or the streaming media server through an extended sip invite signaling, and requests to obtain a video monitoring picture from the video acquisition front end or the streaming media server, wherein the video monitoring and playing request carries a real-time display priority identifier and a time delay priority identifier.

[0033] Step 102: The video acquisition front end or the streaming media server responds to the video monitoring and playing request.

[0034] Step 103: If the video capture front-end or streaming media server supports real-time display priority but not latency priority, then the video stream is returned to the client starting from the encoded video I-frame that is closest to the requested playback time. At the same time, the number of video frames from the I-frame is fed back to the client via SIP signaling.

[0035] Step 104: The client immediately decodes and displays the video stream I-frame upon receiving it.

[0036] like Figure 2 As shown, video encoding compresses video sequences using the IBBP…BBIBBP method. I-frames are intra-frame data, while B-frames and P-frames are inter-frame data. One I-frame and a set of B-frames and P-frames are collectively called a sequence. Decoding an I-frame uses its own frame information to reconstruct the original image. Decoding B-frames and P-frames requires an I-frame within the sequence as a reference frame. Because terminal access is random and uncertain, when a request command arrives, the image sequence encoding has already completed the I-frame. Therefore, the first display of the video requires waiting for the next I-frame to begin before decoding and displaying the image. Thus, there is a certain delay between video request and video display. This delay depends on the number of intervals between I-frames during video encoding and the number of intervals between the current video frame and the next I-frame when the video is opened.

[0037] In this embodiment of the invention, after receiving a video monitoring playback request, the video acquisition front-end or streaming media server responds to the request. If the video acquisition front-end or streaming media server supports real-time display priority but not latency priority, it finds the encoded video I-frame closest to the requested playback time from the cache, and then returns the video stream to the client starting from that I-frame. Simultaneously, it calculates the number of video frames sent since that I-frame relative to the requested playback time and feeds back the number of video frames from that I-frame to the client via SIP signaling. Since the received video stream is an I-frame, the client can immediately decode and display the image.

[0038] Step 105: If the video capture front-end or streaming media server supports real-time display priority and latency priority, then start from the encoded video I-frame that is closest to the requested playback time and return the video stream to the client at the maximum rate. At the same time, the number of video frames away from the I-frame is fed back to the client via SIP signaling until all the encoded first video data is sent. Then, the second video data encoded in real time by the video capture front-end or streaming media server is sent at the normal speed.

[0039] Step 106, after receiving the video data, the client extracts the video frame number of the I frame fed back by the video acquisition front end or the streaming media server from the video request time point, starts the fast playing mechanism, and after the video frame of the first video data received is played at the preset speed, returns to the normal playing speed to play the second video data.

[0040] It should be noted that if the video acquisition front end or the streaming media server supports real-time display priority and time delay priority, the video stream is returned to the client at the maximum rate from the encoded and closest video coding I frame to the request playing time point, and the video frame number from the I frame is fed back to the client through the sip signaling, until the first video data is completely sent, and the second video data encoded by the video acquisition front end or the streaming media server in real time is sent at the normal speed. After receiving the video data, the client extracts the video frame number of the I frame fed back by the video acquisition front end or the streaming media server from the video request time point, starts the fast playing mechanism, and plays at the maximum playing speed supported by the client, until the video frame of the first video data received is played at the preset speed, and then returns to the normal playing speed to play the second video data, realizing the low time delay of the end-to-end picture.

[0041] The video monitoring playing method provided by the application, through the sip signaling negotiation between the client and the video acquisition front end or the streaming media server, after the video acquisition front end or the streaming media server responds to the real-time display priority identifier, the I frame is directly sent, the client decodes and displays the picture immediately when receiving the I frame, improves the picture display real-time performance, and through the video acquisition front end or the streaming media server responding to the time delay priority identifier, the encoded video data is sent at the maximum rate, and after the encoded video data is completely sent, the real-time encoded video data is sent at the normal rate, the client realizes the low time delay of the end-to-end picture through the fast playing mechanism, realizes the improvement of the picture display real-time performance and the playing low time delay of the video monitoring playing without increasing the I frame frequency and changing the video coding mode, and solves the technical problem that the existing video monitoring playing method reduces the time interval of the non-video picture display by increasing the I frame frequency and changing the video coding mode, which reduces the video coding compression efficiency and is not suitable for the video data distribution and forwarding through the streaming media service mode.

[0042] For the convenience of understanding, please refer to Figure 3 In the application, a video monitoring playing system is provided, which comprises a client and a video acquisition front end or a streaming media server.

[0043] The client is used for:

[0044] In response to a video monitoring play request of a user, a video monitoring play request is sent to a video acquisition front end or a streaming media server through SIP signaling to request a video monitoring picture, wherein the video monitoring play request carries a real-time display priority identifier and a time delay priority identifier;

[0045] When the video acquisition front end or the streaming media server supports real-time display priority but does not support time delay priority, decoding and picture display are performed immediately when a video stream I frame is received;

[0046] When the video acquisition front end or the streaming media server supports real-time display priority and supports time delay priority, after receiving video data, the number of video frames of an I frame fed back by the video acquisition front end or the streaming media server from a play request time point is extracted, a fast play mechanism is started, and after video frames of first received video data are played at a preset speed, a second video data is played at a normal play speed;

[0047] The video acquisition front end or the streaming media server is configured to:

[0048] respond to a video monitoring play request;

[0049] If real-time display priority is supported but time delay priority is not supported, a video stream is returned to the client from a video encoding I frame closest to a request play time point, and the number of video frames from the I frame is fed back to the client through SIP signaling;

[0050] If real-time display priority is supported and time delay priority is supported, a video stream is returned to the client from a video encoding I frame closest to a request play time point at a maximum rate, and the number of video frames from the I frame is fed back to the client through SIP signaling until all of the first video data is sent, and then second video data encoded by the video acquisition front end or the streaming media server in real time is sent at a normal speed.

[0051] The preset speed is a maximum play speed supported by the client.

[0052] The above-described embodiments are merely used to illustrate the technical solutions of the present application, but not to limit the present application; although the present application is described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalent ones; and these modifications or replacements 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 the present application.

Claims

1. A video surveillance playback method, characterized in that, include: In response to a user's video monitoring playback request, the client sends a video monitoring playback request to the video acquisition front-end or streaming media server via SIP signaling, requesting to obtain the video monitoring screen. The video monitoring playback request carries a real-time display priority identifier and a latency priority identifier. The video capture front-end or streaming media server responds to video surveillance playback requests; If the video capture front-end or streaming media server supports real-time display priority but not latency priority, then the video stream will be returned to the client starting from the encoded video I-frame that is closest to the requested playback time. At the same time, the number of video frames from the I-frame will be fed back to the client via SIP signaling. The client decodes and displays the video stream I-frames immediately upon receiving them. If the video capture front-end or streaming media server supports real-time display priority and latency priority, then the video stream is returned to the client at the maximum rate starting from the encoded video I-frame that is closest to the requested playback time. At the same time, the number of video frames away from the I-frame is fed back to the client via SIP signaling until all the encoded first video data is sent. Then the second video data encoded in real time by the video capture front-end or streaming media server is sent at the normal speed. After receiving video data, the client extracts the number of video frames from the I-frame returned by the video acquisition front-end or streaming media server to the playback request time point, starts the fast playback mechanism, and continues until the video frames of the first video data received are played at the preset speed, before returning to the normal playback speed to play the second video data.

2. The video surveillance playback method according to claim 1, characterized in that, The preset playback speed is the maximum playback speed supported by the client.

3. A video surveillance playback system, characterized in that, This includes client-side applications and video capture front-ends or streaming media servers; The client is used for: In response to a user's video monitoring playback request, a video monitoring playback request is sent to the video acquisition front-end or streaming media server via SIP signaling to request the acquisition of video monitoring footage. The video monitoring playback request carries a real-time display priority identifier and a latency priority identifier. When the video capture front-end or streaming media server supports real-time display priority but not latency priority, decoding and display should be performed immediately upon receiving an I-frame of the video stream. When the video capture front-end or streaming media server supports real-time display priority and latency priority, after receiving video data, the number of video frames between the I-frame fed back by the video capture front-end or streaming media server and the playback request time point is extracted, and the fast playback mechanism is started. The video frames of the first video data received are played at the preset speed until they are finished, and then the normal playback speed is returned to play the second video data. Video capture front-end or streaming media server is used for: Respond to requests to play video surveillance footage; If real-time display priority is supported but time-delay priority is not supported, the video stream will be returned to the client starting from the encoded video I-frame that is closest to the requested playback time. At the same time, the number of video frames from the I-frame will be fed back to the client via SIP signaling. If real-time display priority and latency priority are supported, the video stream is returned to the client at the maximum rate starting from the encoded video I-frame that is closest to the requested playback time. At the same time, the number of video frames away from the I-frame is fed back to the client via SIP signaling until all the encoded first video data is sent. Then, the second video data encoded in real time by the video acquisition front-end or streaming media server is sent at the normal speed.

4. The video surveillance playback system according to claim 3, characterized in that, The preset playback speed is the maximum playback speed supported by the client.

Images