Video point-to-point preview method and device based on client decoding

Abstract

The invention provides a video point-to-point preview method and device based on client decoding, and belongs to the technical field of video stream processing. The method comprises the following steps: setting a real-time streaming protocol RTSP address of a source video, wherein the RTSP address comprises a user name, a password, an IP address, a port number and an access path; the original stream data corresponding to the RTSP address is pulled, and the H.264 coding format and the H.265 coding format in the RTSP stream are decoded; based on a WebRTC standard, recoding the decoded original stream data into a VP8 format or a VP9 format, and converting a data packet based on a real-time transport protocol RTP into a data packet format supported by WebRTC; and performing real-time preview playing on the transcoded original stream data through a video label function. The point-to-point low-delay and high-quality real-time preview playing of the video is realized, and the stability of video transmission and the user experience are greatly improved.

Description

Technical Field

[0001] The present application belongs to the field of video stream processing technology, and specifically relates to a video point-to-point preview method and device based on client decoding. Background Art

[0002] With the rapid development of information technology, more and more application scenarios require the use of network cameras (IPCs) for real-time monitoring preview. However, because video streams are transmitted over the network and network conditions in real environments are often unstable, traditional streaming media parsing methods, such as pulling the original stream from the device on the server, transcoding it, and then transmitting it to the client, are prone to packet loss when network bandwidth is limited or unstable, resulting in reduced video quality. At the same time, the longer data flow path also increases playback delay. Summary of the Invention

[0003] In order to solve at least one technical problem existing in the background technology, the present application provides a video point-to-point preview method based on client decoding, which realizes low-latency, high-quality real-time preview and playback of video point-to-point, greatly improving the stability of video transmission and user experience.

[0004] The technical solutions adopted in this application are:

[0005] The first embodiment of the present application provides a video point-to-point preview method based on client decoding, comprising:

[0006] Set the real-time streaming protocol RTSP address of the source video, wherein the RTSP address includes a user name, password, IP address, port number, and access path;

[0007] Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream;

[0008] Based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and data packets based on the Real-time Transport Protocol (RTP) are converted into a data packet format supported by WebRTC;

[0009] The video tag function is used to preview and play the transcoded original stream data in real time.

[0010] According to the video point-to-point preview method based on client decoding provided by the embodiment of the first aspect of the present application, first, by setting the RTSP address of the source video (including username, password, IP address, port number and access path), it is ensured that the video source device can be accurately located, which simplifies the configuration process and enhances the flexibility and security of the system; then, the client directly pulls the original stream data corresponding to the RTSP address and decodes the H.264 and H.265 encoding formats in the RTSP stream. This process avoids the delay and instability problems caused by traditional server transit, and greatly improves the stability and efficiency of video transmission; then, based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and the RTP-based data packets are converted into the data packet format supported by WebRTC, so that the video stream can be played directly in the browser environment, which not only achieves low-latency and high-quality video transmission, but also improves cross-platform compatibility; finally, by adapting to HTML5 <video>The tag function uses JavaScript or WebAssembly to build a media stream processing interface, enabling real-time preview and playback of transcoded raw stream data without installing additional plug-ins or controls, providing a lightweight and convenient user experience. In summary, this method significantly improves video playback stability, reduces latency, and significantly enhances the user viewing experience by shortening the video stream transmission path and optimizing codec and encapsulation protocol conversion.

[0011] According to one embodiment of the present application, the real-time streaming protocol RTSP address of the source video is set, and the RTSP address includes a user name, password, IP address, port number and access path, specifically:

[0012] Enter the RTSP address through the front-end interface or configuration file. The RTSP address format is: rtsp: / / [username]:[password]@[ip]:[port] / [path];

[0013] The parameters of the RTSP address are parsed in the client, and the parameters are transmitted to the streaming media processing module to establish a connection with the video source device.

[0014] According to one embodiment of the present application, the pulling of the original stream data corresponding to the RTSP address and decoding of the H.264 and H.265 encoding formats in the RTSP stream are specifically as follows:

[0015] Deploy a middleware module on the client to directly pull the original video stream transmitted via the RTSP protocol from the video source device;

[0016] Utilize the middleware module to establish a session connection through RTSP protocol negotiation and subscribe to the RTP data packet transmission channel;

[0017] The receiving end is controlled to continuously receive the RTP-encapsulated video data packets from the video source device.

[0018] According to one embodiment of the present application, pulling the original stream data corresponding to the RTSP address and decoding the H.264 and H.265 encoding formats in the RTSP stream also includes:

[0019] Parsing the received RTP encapsulated video data packets to extract H.264 and H.265 encoded video frames;

[0020] The video frame is decoded using hardware accelerated decoding or software decoding to generate original pixel data in YUV or RGB format.

[0021] According to one embodiment of the present application, based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and the data packets based on the real-time transport protocol RTP are converted into a data packet format supported by WebRTC, specifically:

[0022] Integrating a WebRTC codec into the middleware module;

[0023] Sending the decoded raw pixel data in the YUV and RGB formats to the WebRTC codec;

[0024] The original pixel data is re-encoded into a compressed video stream in VP8 or VP9 format through the WebRTC codec, and the timestamp and sequence number information in the original RTSP / RTP stream is mapped into the WebRTC data frame.

[0025] According to one embodiment of the present application, the process of re-encoding the decoded original stream data into VP8 or VP9 format based on the WebRTC standard and converting data packets based on the Real-time Transport Protocol (RTP) into a data packet format supported by WebRTC further includes:

[0026] The encoded video frames are encapsulated into a data packet format that complies with the WebRTC transmission specification and transmitted point-to-point through the ICE / STUN / TURN mechanism.

[0027] According to one embodiment of the present application, the real-time preview and playback of the transcoded original stream data is performed by using the video tag function, specifically:

[0028] Native HTML5 in the browser front end <video>Tags are used for adaptive encapsulation, and media stream processing interfaces are constructed through JavaScript or WebAssembly.

[0029] The WebRTC format video stream output by the middleware module is injected into the encapsulated video tag, and local rendering and playback are achieved using the MediaStream API or the WebRTC PeerConnection interface.

[0030] A second embodiment of the present application provides a video point-to-point preview device based on client decoding, comprising:

[0031] An address setting module, adapted to set a real-time streaming protocol RTSP address of a source video, wherein the RTSP address includes a user name, password, IP address, port number, and access path;

[0032] A decoding module adapted to pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream;

[0033] An encoding module adapted to re-encode the decoded original stream data into VP8 or VP9 format based on the WebRTC standard, and convert data packets based on the Real-time Transport Protocol (RTP) into a data packet format supported by WebRTC;

[0034] The playback module is adapted to preview and play the transcoded original stream data in real time through the video tag function.

[0035] An embodiment of the third aspect of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the video point-to-point preview method based on client decoding as described in any embodiment of the first aspect described above is implemented.

[0036] The present application also provides a non-volatile computer storage medium having computer executable instructions stored thereon, characterized in that when the computer program is executed by a processor, the video point-to-point preview method based on client decoding in any embodiment of the first aspect described above is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0038] Figure 1 A schematic diagram of a process for a point-to-point video preview method based on client decoding provided in an embodiment of the present application;

[0039] Figure 2 A schematic diagram of the structure of a video point-to-point preview device based on client decoding provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0041] Reference numerals:

[0042] 110, address setting module; 120, decoding module; 130, encoding module; 140, playback module; 810, processor; 820, communication interface; 830, memory; 840, communication bus. DETAILED DESCRIPTION

[0043] In order to more clearly illustrate the overall concept of the present application, a detailed description is given below in an illustrative manner in conjunction with the accompanying drawings.

[0044] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application may also be implemented in other ways than those described herein, and therefore, the scope of protection of the present application is not limited by the specific embodiments disclosed below. It should be noted that the embodiments of the present application and the features of each embodiment may be combined with each other unless there is a conflict.

[0045] In this application, unless otherwise expressly specified or limited, a first feature "above" or "below" a second feature may be such that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in an appropriate manner in any one or more embodiments or examples.

[0046] like Figure 1 As shown, the first embodiment of the present application provides a video point-to-point preview method based on client decoding, comprising:

[0047] Step 100: Set the Real-Time Streaming Protocol (RTSP) address of the source video. The RTSP address includes a user name, password, IP address, port number, and access path.

[0048] Step 200: Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream.

[0049] Step 300: Based on the WebRTC standard, the decoded original stream data is re-encoded into the VP8 or VP9 format, and the data packets based on the Real-time Transport Protocol (RTP) are converted into the data packet format supported by WebRTC.

[0050] Step 400: Preview and play the transcoded original stream data in real time through the video tag function.

[0051] Step 100 marks the beginning of the entire peer-to-peer video preview process. The user or system administrator enters the RTSP address of the video source device through the front-end interface, configuration file, or other means. This address typically uses the standard format: rtsp: / / [username]:[password]@[ip]:[port] / [path], which includes the username and password for authentication, the device's IP address, the service port, and the specific access path. This information provides an accurate connection basis for subsequent clients to pull the video stream.

[0052] By configuring the RTSP address locally on the client, we avoid the latency and security issues associated with traditional architectures that rely on centralized server management of video sources. This approach also improves system flexibility and deployability, allowing users to quickly change video source devices based on actual needs, enhancing the system's usability and adaptability.

[0053] In step 200, the client deploys a middleware module responsible for pulling the original video stream transmitted via the RTSP protocol directly from the video source device. The middleware negotiates a session connection via the RTSP protocol and subscribes to the RTP packet transmission channel to receive encapsulated video packets from the video source device. These packets are typically transmitted over the RTP protocol and contain video frames encoded in the H.264 or H.265 format.

[0054] By directly pulling and decoding the video stream on the client side, the additional delay and bandwidth usage caused by uploading the video stream to the server and then forwarding it to the client in the traditional mode are avoided. At the same time, it supports hardware acceleration or software decoding of mainstream video encoding formats (H.264 / H.265), which can efficiently convert compressed video into raw pixel data in YUV or RGB format, providing a foundation for subsequent transcoding processing, further improving overall video processing efficiency and playback quality.

[0055] In step 300, the core process involves re-encoding the decoded raw pixel data into the VP8 or VP9 formats natively supported by the browser, leveraging the WebRTC codec integrated into the client middleware. During this process, metadata such as the original timestamp and sequence number are mapped into the new WebRTC data frames, ensuring the time synchronization and integrity of the video stream. Furthermore, the data structure originally encapsulated using the RTP protocol is converted into a data packet format that complies with the WebRTC transmission specification, enabling direct use within the browser environment.

[0056] This processing method enables a seamless transition of video streams from traditional security surveillance encoding to modern web-compatible formats, enabling playback on mainstream browsers without relying on plugins. Furthermore, by establishing point-to-point connections through the ICE / STUN / TURN mechanisms, it effectively penetrates NAT network environments, ensuring low latency and high stability of video streams. This makes it particularly suitable for real-time video preview scenarios under complex network conditions.

[0057] In step 400, by adapting HTML5 <video>The tag and its associated API interfaces inject WebRTC-formatted video streams into the browser's playback component. Using a media stream processing interface built with JavaScript or WebAssembly, the video stream output by the middleware can be bound to page elements and rendered in real time, ultimately achieving smooth video playback. This process relies entirely on native browser capabilities and does not rely on any third-party plug-ins or extensions, significantly improving system security and cross-platform compatibility.

[0058] This lightweight playback method not only lowers the barrier to entry for end users but also significantly reduces deployment and maintenance costs. Furthermore, because the video stream is processed and played directly on the client, delays caused by intermediate links are avoided, significantly improving the real-time performance of video previews. It is suitable for a variety of application scenarios requiring high response speed, such as remote monitoring, online education, and video conferencing.

[0059] According to the video point-to-point preview method based on client decoding provided by the embodiment of the first aspect of the present application, first, by setting the RTSP address of the source video (including username, password, IP address, port number and access path), it is ensured that the video source device can be accurately located, which simplifies the configuration process and enhances the flexibility and security of the system; then, the client directly pulls the original stream data corresponding to the RTSP address and decodes the H.264 and H.265 encoding formats in the RTSP stream. This process avoids the delay and instability problems caused by traditional server transit, and greatly improves the stability and efficiency of video transmission; then, based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and the RTP-based data packets are converted into the data packet format supported by WebRTC, so that the video stream can be played directly in the browser environment, which not only achieves low-latency and high-quality video transmission, but also improves cross-platform compatibility; finally, by adapting to HTML5 <video>The tag function uses JavaScript or WebAssembly to build a media stream processing interface, enabling real-time preview and playback of transcoded raw stream data without installing additional plug-ins or controls, providing a lightweight and convenient user experience. In summary, this method significantly improves video playback stability, reduces latency, and significantly enhances the user viewing experience by shortening the video stream transmission path and optimizing codec and encapsulation protocol conversion.

[0060] In some embodiments of the present application, the real-time streaming protocol RTSP address of the source video is set. The RTSP address includes a user name, password, IP address, port number, and access path, specifically:

[0061] Enter the RTSP address through the front-end interface or configuration file. The RTSP address format is: rtsp: / / [username]:[password]@[ip]:[port] / [path];

[0062] The client parses the parameters of the RTSP address and transmits the parameters to the streaming media processing module to establish a connection with the video source device.

[0063] Users can enter the RTSP address of the video source device through a graphical front-end interface (such as a browser page or client configuration interface), or preset it through a local configuration file (such as a JSON, XML, or INI format file). The entered RTSP address follows the standard format: rtsp: / / [username]:[password]@[ip]:[port] / [path], which includes the username and password for authentication, the IP address of the video source device, the service port, and the specific access path information. This address structure ensures that the client can accurately identify and connect to the target video source device.

[0064] Furthermore, when the client initiates the video preview process, the system's internal address parsing module performs syntax analysis and parameter extraction on the input RTSP address, extracting fields such as the username, password, IP address, port number, and access path, and passing these parameters to the streaming media processing module. Based on the parsed information, the streaming media processing module establishes an RTSP session connection with the video source device, completing operations such as authentication, stream pulling, and data subscription, thereby providing basic support for subsequent video stream pulling and decoding. This implementation not only improves the system's automation and connection efficiency, but also enhances its compatibility and adaptability with video sources in various network environments.

[0065] In some embodiments of the present application, the original stream data corresponding to the RTSP address is pulled, and the H.264 and H.265 encoding formats in the RTSP stream are decoded, specifically:

[0066] Deploy a middleware module on the client to directly pull the original video stream transmitted via the RTSP protocol from the video source device;

[0067] Use the middleware module to establish a session connection through RTSP protocol negotiation and subscribe to the RTP data packet transmission channel;

[0068] Control the receiving end to continuously receive RTP-encapsulated video data packets from the video source device.

[0069] A middleware module dedicated to processing video streams is deployed on the client side. This module is capable of directly communicating with the video source device and actively pulling the original video stream based on the RTSP protocol. The middleware module parses the RTSP address information configured in step 100 to obtain the authentication parameters and network connection information of the target video source device, and then initiates an RTSP connection request based on this information.

[0070] The middleware module further interacts with the video source device using the RTSP protocol, completing standard signaling interactions such as authentication, OPTIONS, DESCRIBE, SETUP, and PLAY, and negotiating the establishment of the session connection required for video streaming. Furthermore, it subscribes to the RTP data packet transmission channel sent by the video source device to receive the RTP data stream encapsulated with video frames. The middleware module then controls the receiving end to continuously listen for and receive RTP-encapsulated video packets from the video source device, ensuring the continuity and integrity of the video stream.

[0071] Through the above implementation method, the client can directly obtain the original video stream from the video source device without relying on a remote server for transfer, effectively reducing the data transmission path, reducing the packet loss rate and playback delay caused by network fluctuations, and improving the real-time and stability of video preview.

[0072] In some embodiments of the present application, pulling the original stream data corresponding to the RTSP address and decoding the H.264 and H.265 encoding formats in the RTSP stream also includes:

[0073] Parse the received RTP-encapsulated video data packets and extract the H.264 and H.265 encoded video frames;

[0074] Decode the video frames using hardware accelerated decoding or software decoding to generate raw pixel data in YUV or RGB format.

[0075] After the middleware module successfully receives the RTP-encapsulated video data packet from the video source device, the system further parses and processes the packet. Specifically, the middleware module analyzes the RTP protocol header information to identify the video payload data carried therein and, based on the payload type, determines the video encoding standard used (such as H.264 or H.265). The system then extracts the complete video frame data from the RTP packet, providing input for subsequent decoding operations.

[0076] Furthermore, the system decodes the extracted H.264 / H.265 encoded video frames using either hardware-accelerated decoding or software-accelerated decoding. Hardware-accelerated decoding leverages GPUs or dedicated codec chips (such as Intel QuickSync, NVIDIA NVENC / VDPAU, etc.) for efficient decoding, significantly reducing CPU utilization and improving decoding performance. Software-accelerated decoding, on the other hand, leverages general-purpose decoding libraries (such as FFmpeg, OpenH264, etc.) for greater compatibility and flexibility. After decoding, the video frames are converted into raw pixel data in YUV or RGB format for subsequent WebRTC transcoding and browser rendering.

[0077] This implementation not only improves video decoding efficiency and resource utilization, but also enhances the system's compatibility with different encoding formats, providing a solid technical foundation for achieving low-latency, high-quality point-to-point video preview.

[0078] In some embodiments of the present application, based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and the data packets based on the Real-time Transport Protocol (RTP) are converted into a data packet format supported by WebRTC, specifically:

[0079] Integrate WebRTC codec in middleware module;

[0080] The decoded raw pixel data in YUV and RGB formats is fed into the WebRTC codec.

[0081] The original pixel data is re-encoded into a compressed video stream in VP8 or VP9 format through the WebRTC codec, and the timestamp and sequence number information in the original RTSP / RTP stream is mapped into the WebRTC data frame.

[0082] The client-side middleware module integrates a WebRTC-compliant video codec component that re-encodes raw pixel data (such as YUV or RGB formats) into the VP8 or VP9 video codec formats natively supported by the browser. This encoding method ensures that the generated video stream can be played directly in major modern browsers without relying on any plug-ins or third-party players.

[0083] Furthermore, the middleware module feeds the raw pixel data obtained from decoding H.264 / H.265 video frames into the WebRTC codec for processing. During the encoding process, the system not only compresses the video data but also maps key metadata, such as timestamps and sequence numbers, carried in the original RTSP / RTP video stream into the newly generated WebRTC data frames. This ensures the temporal synchronization and continuity of the video stream during playback, avoiding issues such as screen freezes and audio / video asynchrony.

[0084] Through the above implementation method, the system can complete the complete transcoding process from the original video stream to the WebRTC compatible format on the client side, significantly reducing the video transmission delay, improving the playback smoothness and real-time performance, and at the same time enhancing the compatibility with cross-platform browser environments to meet the application requirements of low-latency, high-quality video preview.

[0085] In some embodiments of the present application, based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and data packets based on the Real-time Transport Protocol (RTP) are converted into a data packet format supported by WebRTC, further comprising:

[0086] The encoded video frames are encapsulated into a data packet format that complies with the WebRTC transmission specification and transmitted point-to-point through the ICE / STUN / TURN mechanism.

[0087] After encoding the video frames, the system further packages the resulting VP8 or VP9 compressed video frames according to the encapsulation format specified by the WebRTC protocol. This encapsulation process includes adding necessary transmission metadata (such as timestamps, sequence numbers, payload types, etc.) and constructing SRTP (Secure Real-Time Transport Protocol) data packets that comply with the WebRTC transport specification to ensure that the video stream can be correctly parsed and played back over the network.

[0088] Subsequently, the system establishes a peer-to-peer (P2P) communication channel between the client and the browser by integrating the ICE (Interactive Connection Establishment), STUN (Session Traversal Tool for NAT), and TURN (Traversal of NAT Using Relays) mechanisms. The ICE framework is responsible for collecting candidate network paths, STUN is used to obtain public IP addresses for NAT penetration, and TURN provides relay forwarding services when a direct connection cannot be established. Through the combination of the above mechanisms, the system can successfully establish a stable, low-latency video transmission link in complex network environments, achieving a high-quality real-time video preview experience.

[0089] This implementation not only improves the transmission efficiency and security of video streams, but also significantly enhances the system's adaptability in different network environments, providing solid technical support for achieving lightweight, low-latency, and highly compatible point-to-point video preview.

[0090] In some embodiments of the present application, the video tag function is used to preview and play the transcoded original stream data in real time, specifically:

[0091] Native HTML5 in the browser front end <video>Tags are used for adaptive encapsulation, and media stream processing interfaces are constructed through JavaScript or WebAssembly.

[0092] Inject the WebRTC format video stream output by the middleware module into the encapsulated video tag, and use the MediaStream API or WebRTC PeerConnection interface to achieve local rendering and playback.

[0093] In the browser front end, through the native HTML5 <video>The tag is adaptively encapsulated to build a lightweight player component that supports WebRTC format video streaming. This encapsulation process includes using JavaScript or WebAssembly to implement the media stream processing interface, connect to the video stream data output by the client middleware module, and perform parsing, buffering, and rendering control on it, thereby achieving efficient playback of the video stream.

[0094] Furthermore, the system injects the video stream that complies with the WebRTC standard output by the middleware module into the encapsulated <video>The browser uses the MediaStream API or WebRTC PeerConnection interface to render and play the video stream locally. The PeerConnection interface establishes a real-time communication channel with the middleware module, ensuring that video frames are received and delivered to the player in a timely manner. The MediaStream API manages the lifecycle and playback status of the video stream, enabling features such as automatic playback, pause and resume, and resolution adaptation.

[0095] This approach allows users to directly view video from RTSP source devices in mainstream browsers (such as Chrome, Firefox, and Edge) without installing any plug-ins or extensions, significantly improving system compatibility, security, and user experience. Furthermore, because video stream processing and playback are all performed on the client, transmission latency is effectively reduced, meeting the demanding requirements for real-time video preview in scenarios such as security monitoring, remote learning, and video conferencing.

[0096] like Figure 2 As shown, the second embodiment of the present application provides a video point-to-point preview device based on client decoding, including:

[0097] An address setting module 110 is adapted to set a real-time streaming protocol (RTSP) address of a source video, wherein the RTSP address includes a user name, a password, an IP address, a port number, and an access path;

[0098] The decoding module 120 is adapted to pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream;

[0099] The encoding module 130 is adapted to re-encode the decoded original stream data into VP8 or VP9 format based on the WebRTC standard, and convert data packets based on the Real-time Transport Protocol RTP into a data packet format supported by WebRTC;

[0100] The playback module 140 is adapted to perform real-time preview and playback of the transcoded original stream data through the video tag function.

[0101] The video point-to-point preview device based on client decoding provided in the embodiment of the second aspect of this application can implement the video point-to-point preview method based on client decoding in any embodiment of the first aspect above, and thus can achieve any technical effect of the video point-to-point preview method based on client decoding above, which will not be repeated here.

[0102] An embodiment of the third aspect of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the video point-to-point preview method based on client decoding in any embodiment of the first aspect is implemented.

[0103] Figure 3 An example of a physical structure diagram of an electronic device is shown below. Figure 3 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the video point-to-point preview method based on client decoding in any embodiment of the first aspect above, the method comprising:

[0104] Step 100: Set the Real-Time Streaming Protocol (RTSP) address of the source video. The RTSP address includes a user name, password, IP address, port number, and access path.

[0105] Step 200: Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream.

[0106] Step 300: Based on the WebRTC standard, the decoded original stream data is re-encoded into the VP8 or VP9 format, and the data packets based on the Real-time Transport Protocol (RTP) are converted into the data packet format supported by WebRTC.

[0107] Step 400: Preview and play the transcoded original stream data in real time through the video tag function.

[0108] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0109] On the other hand, the present invention further provides a computer program product, comprising a computer program, which may be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the client-side decoding-based video point-to-point preview method provided by the above methods, which includes:

[0110] Step 100: Set the Real-Time Streaming Protocol (RTSP) address of the source video. The RTSP address includes a user name, password, IP address, port number, and access path.

[0111] Step 200: Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream.

[0112] Step 300: Based on the WebRTC standard, the decoded original stream data is re-encoded into the VP8 or VP9 format, and the data packets based on the Real-time Transport Protocol (RTP) are converted into the data packet format supported by WebRTC.

[0113] Step 400: Preview and play the transcoded original stream data in real time through the video tag function.

[0114] In another aspect, the present invention further provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for performing the client-side decoding-based video point-to-point preview provided by the above methods is implemented. The method includes:

[0115] Step 100: Set the Real-Time Streaming Protocol (RTSP) address of the source video. The RTSP address includes a user name, password, IP address, port number, and access path.

[0116] Step 200: Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream.

[0117] Step 300: Based on the WebRTC standard, the decoded original stream data is re-encoded into the VP8 or VP9 format, and the data packets based on the Real-time Transport Protocol (RTP) are converted into the data packet format supported by WebRTC.

[0118] Step 400: Preview and play the transcoded original stream data in real time through the video tag function.

[0119] Finally, the present invention also provides a non-volatile computer storage medium having computer executable instructions stored thereon. When the computer program is executed by a processor, the method for performing the client-side decoding-based video point-to-point preview provided by the above methods is implemented. The method includes:

[0120] Step 100: Set the Real-Time Streaming Protocol (RTSP) address of the source video. The RTSP address includes a user name, password, IP address, port number, and access path.

[0121] Step 200: Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream.

[0122] Step 300: Based on the WebRTC standard, the decoded original stream data is re-encoded into the VP8 or VP9 format, and the data packets based on the Real-time Transport Protocol (RTP) are converted into the data packet format supported by WebRTC.

[0123] Step 400: Preview and play the transcoded original stream data in real time through the video tag function.

[0124] Anything not described in this application can be achieved by adopting or drawing on existing technologies.

[0125] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0126] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included in the protection scope of the present application.< / video> < / video> < / video> < / video> < / video> < / video> < / video>

Claims

1. A video point-to-point preview method based on client decoding, characterized in that: include: Set the real-time streaming protocol RTSP address of the source video, wherein the RTSP address includes a user name, password, IP address, port number, and access path; Pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream; Based on the WebRTC standard, the decoded original stream data is re-encoded into VP8 or VP9 format, and data packets based on the Real-time Transport Protocol (RTP) are converted into a data packet format supported by WebRTC; The video tag function is used to preview and play the transcoded original stream data in real time.

2. The video point-to-point preview method based on client decoding according to claim 1, characterized in that: The Real-Time Streaming Protocol (RTSP) address of the source video is set. The RTSP address includes a user name, password, IP address, port number, and access path. Specifically, Enter the RTSP address through the front-end interface or configuration file. The RTSP address format is: rtsp: / / [username]:[password]@[ip]:[port] / [path]; The parameters of the RTSP address are parsed in the client, and the parameters are transmitted to the streaming media processing module to establish a connection with the video source device.

3. The video point-to-point preview method based on client decoding according to claim 2, characterized in that: Pulling the original stream data corresponding to the RTSP address and decoding the H.264 and H.265 encoding formats in the RTSP stream is specifically as follows: Deploy a middleware module on the client to directly pull the original video stream transmitted via the RTSP protocol from the video source device; Utilize the middleware module to establish a session connection through RTSP protocol negotiation and subscribe to the RTP data packet transmission channel; The receiving end is controlled to continuously receive the RTP-encapsulated video data packets from the video source device.

4. The video point-to-point preview method based on client decoding according to claim 3 is characterized in that: Pulling the original stream data corresponding to the RTSP address and decoding the H.264 and H.265 encoding formats in the RTSP stream also includes: Parsing the received RTP encapsulated video data packets to extract H.264 and H.265 encoded video frames; The video frame is decoded using hardware accelerated decoding or software decoding to generate original pixel data in YUV or RGB format.

5. The video point-to-point preview method based on client decoding according to claim 4 is characterized in that: The decoded original stream data is re-encoded into VP8 or VP9 format based on the WebRTC standard, and the data packets based on the real-time transport protocol RTP are converted into the data packet format supported by WebRTC, specifically: Integrating a WebRTC codec into the middleware module; Sending the decoded raw pixel data in the YUV and RGB formats to the WebRTC codec; The original pixel data is re-encoded into a compressed video stream in VP8 or VP9 format through the WebRTC codec, and the timestamp and sequence number information in the original RTSP / RTP stream is mapped into the WebRTC data frame.

6. The video point-to-point preview method based on client decoding according to claim 5, characterized in that: The method further includes: re-encoding the decoded original stream data into VP8 or VP9 format based on the WebRTC standard, and converting data packets based on the Real-time Transport Protocol (RTP) into a data packet format supported by WebRTC; The encoded video frames are encapsulated into a data packet format that complies with the WebRTC transmission specification and transmitted point-to-point through the ICE / STUN / TURN mechanism.

7. The video point-to-point preview method based on client decoding according to any one of claims 3 to 6, characterized in that: The real-time preview and playback of the transcoded original stream data is performed by using the video tag function, specifically: Native HTML5 in the browser front end <video> Tags are used for adaptive encapsulation, and media stream processing interfaces are constructed through JavaScript or WebAssembly.< / video> The WebRTC format video stream output by the middleware module is injected into the encapsulated video tag, and local rendering and playback are achieved using the MediaStream API or the WebRTC PeerConnection interface.

8. A video point-to-point preview device based on client decoding, characterized in that: include: An address setting module, adapted to set a real-time streaming protocol RTSP address of a source video, wherein the RTSP address includes a user name, password, IP address, port number, and access path; A decoding module adapted to pull the original stream data corresponding to the RTSP address and decode the H.264 and H.265 encoding formats in the RTSP stream; An encoding module adapted to re-encode the decoded original stream data into VP8 or VP9 format based on the WebRTC standard, and convert data packets based on the Real-time Transport Protocol (RTP) into a data packet format supported by WebRTC; The playback module is adapted to preview and play the transcoded original stream data in real time through the video tag function.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the video point-to-point preview method based on client decoding is implemented as described in any one of claims 1 to 7.

10. A non-volatile computer storage medium having computer executable instructions stored thereon, characterized in that: When the computer program is executed by a processor, the method for peer-to-peer video preview based on client decoding as described in any one of claims 1 to 7 is implemented.

Images