Web real-time communication video conference system compatible with gb / t 28181 device and media stream conversion method

Abstract

This invention relates to the field of computer multimedia communication, and in particular to a WebRTC video conferencing system and media stream conversion method compatible with GB / T28181 devices. The system adopts a layered architecture, including a service layer, a STUN / TURN server, a signaling layer, and a media layer. The service layer provides service interfaces for WebRTC clients and stores service data. The STUN / TURN server is used to implement NAT traversal. The signaling layer includes a WebRTC signaling module, a signaling protocol conversion module, and a GB / T28181 signaling module. The media layer includes a WebRTC media module, a media transcoding module, a congestion control module, and a GB / T 28181 media module. This solution proposes the IGCC-A algorithm to reduce frequent jitter in the transmission rate caused by small fluctuations in network latency, and realizes the structure of a WebRTC video conferencing system that accesses GB28181 devices.

Description

Technical Field

[0001] This invention relates to the field of computer multimedia communication, and in particular to a WebRTC video conferencing system and media stream conversion method compatible with GB / T28181 devices, which optimizes congestion control and stream transcoding methods. Background Technology

[0002] Video conferencing systems are a comprehensive application of multiple technologies such as networking, communication, and multimedia. With the increasing demand for real-time information, video conferencing systems have received more and more attention due to their intuitive, realistic, cross-regional, and low-cost communication features. They are widely used in various fields of organizational activities, such as distance education, remote negotiation, telemedicine, and remote diagnosis.

[0003] Especially with the continuous construction and development of new smart city infrastructure, the command and dispatch applications in urban management require command center personnel, on-site operators, and business and technical experts to collaborate through multi-terminal video conferencing. This provides command center personnel, on-site operators, and business and technical experts with intuitive, realistic, and cross-regional real-time information exchange anytime and anywhere. However, traditional video conferencing systems are too costly and time-consuming to promote, making WebRTC (Web Real-Time Communication), with its shorter development time and lower cost, the preferred choice for video conferencing.

[0004] The original WebRTC GCC algorithm incorporates both latency-based and packet loss-based congestion control strategies. When network congestion occurs, it can estimate the bitrate within 2 to 3 seconds to adapt to the network condition, resulting in a brief pause. For intermittent packet loss, it can adapt the transmission bitrate to the current network condition in about 2 seconds; however, in weak network environments, it easily reduces the bitrate to very low levels, causing image distortion. Therefore, the latency-based bandwidth estimation module may mistakenly assume excessive network usage in scenarios with network jitter, leading to an erroneous reduction in bitrate. Furthermore, the original GCC algorithm selects the smaller of the candidate transmission rates based on packet loss rate and candidate transmission rates based on network latency changes as the target transmission rate for the next stage, making it overly sensitive to changes in network latency in strong network environments. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a WebRTC video conferencing system and media stream conversion method compatible with GB / T28181 devices. It achieves the transcoding of PS streams from GB28181 devices into WebRTC streams, enabling GB28181 devices to access the conferencing system. Furthermore, to optimize the performance of the GCC algorithm in network jitter scenarios and improve audio and video experience, this invention proposes the IGCC-A algorithm, which is an improvement on the GCC algorithm in the latest version of WebRTC. To avoid bandwidth reduction due to sudden delays, this algorithm does not immediately reduce bandwidth in the additive increase-multiplicative decrease rate controller after detecting congestion changes. Instead, it observes six round-trip times. If overuse still occurs, bandwidth is reduced, and this reduction is repeated three times until it reaches 0.85 times the successful reception rate. Simultaneously, after GCC obtains two candidate transmission rates and before determining the target transmission rate, the algorithm adds a strong network constraint condition, reducing the sensitivity of GCC to network latency under strong network conditions and minimizing frequent jitter in the transmission rate caused by small fluctuations in network latency.

[0006] The present invention provides the following technical solution: a WebRTC video conferencing system compatible with GB / T28181 equipment, wherein the system adopts a layered architecture, including a service layer, a STUN / TURN server, a signaling layer and a media layer;

[0007] Business layer: Used to provide business interfaces for WebRTC clients and store business data;

[0008] STUN / TURN server: used to implement NAT traversal;

[0009] The signaling layer includes a WebRTC signaling module, a signaling protocol conversion module, and a GB / T28181 signaling module. The WebRTC signaling module enables signaling interaction between the video conferencing system and the client; the signaling protocol conversion module converts WebRTC signaling to GB / T28181 signaling; and the GB / T28181 signaling module establishes a session with the GB / T28181 terminal acquisition device.

[0010] The media layer includes a WebRTC media module, a media transcoding module, a congestion control module, and a GB / T28181 media module. The WebRTC media module enables media transmission between the video surveillance equipment and the WebRTC client. The media transcoding module converts the WebRTC media stream to the GB / T28181 media stream. The GB / T28181 media module enables media transmission with the terminal acquisition device. The congestion control module, located between the transcoding module and the WebRTC media module, reduces packet loss and network latency in the network.

[0011] The implementation of the media layer interface includes obtaining the local media stream (getMedia), establishing a real-time communication connection (RTCPeerConnection), a real-time communication data channel (RTCDataChannel), and creating a GB / T28181 RTP packet receiving port (openRtpServer).

[0012] The `getMedia` interface is used to retrieve media streams captured from a local camera and microphone. This interface has different names in different browsers; in Chrome it's called `webkitGetUserMedia`, and in Firefox it's called `mozGetUserMedia`. Therefore, browser compatibility should be ensured when using it. The `getMedia` interface uses the format `getUserMedia`, which includes `constraints`, `successCallback`, and `errorCallback`. `constraints` represents settings for whether audio and video are supported, and is formatted as a JSON string. `successCallback` is a function that will be executed if the retrieval is successful, and `errorCallback` is a function that will be executed if the retrieval fails.

[0013] After obtaining the media stream by calling `getMedia`, it needs to be bound to the `video` tag, and its `autoplay` attribute set to `true`; otherwise, only one image will be displayed on the screen. Simultaneously, the local media stream data obtained through `getMedia` is converted into a URL using the `window.URL.createObjectURL` function, and this URL is used as the video source for the `video` tag.

[0014] The RTCPeerConnection interface is used to establish a real-time communication connection between two nodes, enabling the transmission of data streams. RTCPeerConnection can also be used as a parameter in the browser's event target interface. The Event class is the default HTML class, and the target returns the element that triggered the event.

[0015] The real-time communication data channel RTCDataChannel reliably and efficiently transmits data of any format between two users. It also implements the interface getThreadsLoad for obtaining network thread load, openRtpServer for the RTP packet receiving port of GB / T28181 stream, closeRtpServer for closing the RTP packet receiving port of GB / T28181 stream, getRtpInfo for obtaining RTP push end information, and ProcessInterface for RTP packet processing.

[0016] Create a GB / T28181RTP packet receiving port openRtpServer. If the data received on this port times out, it will be automatically reclaimed. Close the GB / T28181RTP receiving port closeRtpServer, getRtpInfo interface to obtain RTP push stream information, and ProcessInterface interface to process RTP packets.

[0017] A media stream conversion method based on the above-mentioned conferencing system, wherein the media stream conversion is used to convert GB / T28181 media streams to WebRTC streams, and the specific steps are as follows:

[0018] Step 1: The receiving port receives RTP packets with PS payload. The GB28181 media stream is a PS stream with RTP packet payload. First, find the first RTP packet with PS header, and then put the RTP packet with PS payload into the PS packet buffer.

[0019] Step 2: Check if the RTP packet sequences are continuous. If they are continuous, proceed to step 3. If they are not continuous, clear the PS buffer, clear the main H.264 buffer and frame buffer, and jump to step 5.

[0020] Step 3: Parse RTP packets in the PS packet buffer, and continue to receive RTP packets and put them into the PS packet buffer until a complete PS packet is received. Parse the video data carried in the complete PS packet into an ES stream and put it into the main H.264 buffer and the secondary H.264 buffer.

[0021] Step 4: Split the ES stream in the main H.264 buffer into frames and put each complete H.264 frame into the frame buffer;

[0022] Step 5: Split the ES stream extracted from the PS packet into frames. When splitting frames, split the last buffer of the secondary H.264 buffer into frames and put each complete H.264 frame into the frame buffer to ensure that there is always a picture on the playback end.

[0023] Step 6: Pack the complete H.264 frames in the frame buffer into a WebRTC stream using the packing module;

[0024] Step 7: Based on the transmission bitrate fed back by the IGCC-A algorithm in the congestion control module, push the packaged stream to the WebRTC streaming media module through the URL push module.

[0025] The IGCC-A algorithm described is an optimized version of the GCC algorithm, Google Congestion Control (GCC). This algorithm consists of two parts: packet loss-based rate control and latency-based rate control. Both parts achieve congestion control by adjusting the data transmission rate.

[0026] Rate control based on packet loss follows this basic idea: packet loss indicates network congestion. If the packet loss rate is 0 or very low, the network is in good condition, and the bit rate can be appropriately increased to improve clarity. If the packet loss rate increases, it indicates network quality deterioration, requiring a reduction in the amount of data sent to the network and a decrease in the sender's encoding bit rate. Otherwise, the sending bit rate remains unchanged. The sender's bit rate control calculates the expected sending bit rate based on the packet loss rate, which is included in the received RTCP report message. The calculation formula is as follows, where f... l (t k ) represents t k Packet loss rate at time A s (t k ) represents t k Transmission bitrate at any given time:

[0027]

[0028] Delay-based rate control is based on the idea that the arrival time delay of RTP packets reflects network congestion. When the delay is small, it indicates that network congestion is not severe, and the target bit rate can be appropriately increased; when the delay increases, it indicates that network congestion is severe, and the target bit rate needs to be decreased; when the delay remains at a low level, the target bit rate remains unchanged.

[0029] The transmitter's rate control calculates the expected transmission rate based on the delay. The calculation formula is as follows, where t... i Let R represent the time when the i-th video frame is received, η = 1.05, α = 0.85, and R r (t i A represents the received bit rate measured in the last 500ms. r (t i ) represents t i Transmission bitrate at any given time:

[0030]

[0031] In recent implementations of WebRTC, all bandwidth estimation is performed at the sending end. This means the sender performs both packet loss-based and latency gradient-based bandwidth estimation. To enable latency gradient-based bandwidth estimation at the receiving end, WebRTC extends the RTP / RTCP protocol. Firstly, it adds an RTP header with a session-level sequence number, allowing for statistical analysis of feedback information across a single session, rather than just a single audio or video stream. Secondly, it adds an RTCP feedback message, `transport-cc-feedback`, which provides the arrival times of all media packets received by the receiver. The receiver can then calculate the latency gradient based on the reception delay and transmission interval, thereby estimating the bandwidth.

[0032] WebRTC's original GCC algorithm incorporates both latency-based and packet loss-based congestion control strategies. When network congestion occurs, it can estimate the bitrate within 2 to 3 seconds to adapt to the network condition, resulting in a brief pause. For intermittent packet loss, it can adapt the transmission bitrate to the current network condition in about 2 seconds; however, in weak network environments, it easily reduces the bitrate to very low levels, causing image distortion. Therefore, the latency-based bandwidth estimation module may mistakenly assume network overuse in jitter scenarios, leading to an erroneous reduction in bitrate. Furthermore, the original GCC algorithm selects the smaller of two candidate transmission rates—one based on packet loss rate and the other on network latency variation—as the target transmission rate for the next stage. However, in strong network conditions, GCC is overly sensitive to changes in network latency.

[0033] To address the need for targeted optimization of the GCC algorithm in network jitter scenarios and improve audio and video experience, this paper proposes the IGCC-A algorithm, which is an improvement upon the GCC algorithm in the latest version of WebRTC. The detailed algorithm specifications are as follows:

[0034] 1) After detecting congestion changes, the additive rate controller does not immediately reduce bandwidth. Instead, it observes six round-trip times. If overuse still occurs, it reduces bandwidth three times consecutively until it reaches 0.85 times the successful reception rate. The IGCC-A algorithm groups packets with similar arrival times into one packet group and calculates only one delay change. Packets that are far apart are grouped into different groups. This avoids the original algorithm from calculating unidirectional delay changes by packet group when sudden jitter occurs, causing the delay-based rate controller to mistakenly identify congestion and reduce bandwidth.

[0035] 2) Calculate t in GCC based on packet loss rate and latency variation respectively. i The two candidate transmission rates A at time A s (t i) and A r (t i After that, IGCC-A makes its decision as follows:

[0036]

[0037] Where A(t) i ) for t i The transmission bit rate at time t, and the constraint function P(t) i The value of P(t) represents the value of IGCC-A allowing the current congestion algorithm to ignore minor latency fluctuations when the call quality of the current session is sufficiently reliable. i When )>0, IGCC-A directly selects the rate given by the rate controller based on the packet loss rate as the current target transmission rate; once the value of the constraint function does not meet the requirements, i.e., P(t) i When )≤0, IGCC-A revoks the permission and performs congestion control according to the original GCC algorithm rules.

[0038] To allow the constraint function to adapt more flexibly to different packet loss rates and latency fluctuations, we define the constraint function as follows:

[0039]

[0040] Where f r (t i ) and f l (t i ) represents t i RTT and packet loss rate at any given time and Representing additional factors The impact on the constraint function is considered. Furthermore, once the packet loss rate exceeds 3%, the network quality of the live channel is deemed suboptimal, and minor latency fluctuations are no longer ignored. In P(t) i When )>0.

[0041] As described above, this solution allows GB28181-compliant devices to access the conferencing system, enabling the conversion of GB / T28181 PS streams to WebRTC streams. It also employs the IGCC-A algorithm, which optimizes the performance of the GCC algorithm in network jitter scenarios and improves the audio and video experience. The IGCC-A algorithm is an improvement on the GCC algorithm in the latest version of WebRTC. To avoid bandwidth drops due to sudden delays, the additive increase / multiplicative decrease rate controller does not immediately reduce bandwidth after detecting congestion changes. Instead, it observes six round-trip times. If overuse persists, bandwidth is reduced, and this reduction is repeated three times until it reaches 0.85 times the successful reception rate. Furthermore, after the GCC obtains two candidate transmission rates but before determining the target transmission rate, a strong network constraint is added. This reduces the sensitivity of the GCC to network latency under strong network conditions and minimizes frequent jitter in the transmission rate caused by small fluctuations in network latency. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of a video conferencing system according to a specific embodiment of the present invention;

[0043] Figure 2 This is a flowchart of media stream conversion;

[0044] Figure 3 This is a schematic diagram of the stream conversion structure in a streaming media service;

[0045] Figure 4 It is an optimization diagram of an additive rate controller with multiplicative decrement. Detailed Implementation

[0046] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of specific embodiments. Obviously, the described specific embodiments are merely one specific embodiment of the present invention, and not all specific embodiments. Based on the specific embodiments of the present invention, all other specific embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] As shown in the attached diagram, this solution provides a WebRTC video conferencing system compatible with GB / T28181 devices. The system adopts a layered architecture, as follows: Figure 1 As shown, it includes a service layer, a STUN / TURN server, a signaling layer (signaling server), and a media layer (streaming media server); each layer adopts a modular design with low coupling and high cohesion.

[0048] Business layer: Used to provide business interfaces for WebRTC clients and store business data.

[0049] STUN / TURN servers: used to implement NAT traversal.

[0050] The signaling layer includes a WebRTC signaling module, a signaling protocol conversion module, and a GB / T28181 signaling module. The WebRTC signaling module enables signaling interaction between the video conferencing system and the client. The signaling protocol conversion module converts WebRTC signaling to GB / T28181 signaling. The GB / T28181 signaling module establishes sessions with GB / T28181 terminal acquisition devices. The WebRTC2SIP gateway is used to convert the SIP protocol from WebSocket-based transmission to UDP / TCP-based transmission on the WebRTC client APP side, enabling interoperability of SIP session messages.

[0051] The media layer includes a WebRTC media module, a media transcoding module, a congestion control module, and a GB / T 28181 media module. The WebRTC media module enables media transmission between the video surveillance equipment and the WebRTC client. The media transcoding module converts the WebRTC media stream to the GB / T 28181 media stream. The GB / T 28181 media module enables media transmission with the terminal acquisition device. The congestion control module, located between the transcoding module and the WebRTC media module, reduces packet loss and network latency in the network.

[0052] The implementation of the media layer interface includes obtaining the local media stream (getMedia), establishing a real-time communication connection (RTCPeerConnection), a real-time communication data channel (RTCDataChannel), and creating a GB / T28181 RTP packet receiving port (openRtpServer).

[0053] The local media stream getMedia tool is used to acquire media streams captured from the local camera and microphone.

[0054] The RTCPeerConnction interface is used to establish a connection for transmitting data streams between two nodes.

[0055] The real-time communication data channel RTCDataChannel reliably and efficiently transmits data of any format between two users. It also implements the interface getThreadsLoad for obtaining network thread load, openRtpServer for the RTP packet receiving port of GB / T28181 stream, closeRtpServer for closing the RTP packet receiving port of GB / T28181 stream, getRtpInfo for obtaining RTP push end information, and ProcessInterface for RTP packet processing.

[0056] Create a GB / T28181 RTP packet receiving port openRtpServer. If the data received on this port times out, it will be automatically reclaimed. Close the GB / T28181 RTP receiving port closeRtpServer, getRtpInfo interface to obtain RTP push stream information, and ProcessInterface interface to process RTP packets.

[0057] The getMedia interface uses the getUserMedia format, which includes constraints, successCallback, and errorCallback. Constraints represent settings for whether audio and video are supported, and are in JSON string format. successCallback is a function that will be executed if the retrieval is successful. errorCallback is a function that will be executed if the retrieval fails.

[0058] A media stream conversion method based on the above system, such as Figure 2 As shown, the real-time conversion steps from a PS stream to a WebRTC stream according to GB / T28181 are as follows: The specific steps are as follows:

[0059] Step 1: The receiving port receives RTP packets with PS payload. The GB28181 media stream is a PS stream with RTP packet payload. First, find the first RTP packet with PS header, and then put the RTP packet with PS payload into the PS packet buffer.

[0060] Step 2: Check if the RTP packet sequences are continuous. If they are continuous, proceed to step 3. If they are not continuous, clear the PS buffer, clear the main H.264 buffer and frame buffer, and jump to step 5.

[0061] Step 3: Parse RTP packets in the PS packet buffer, and continue to receive RTP packets and put them into the PS packet buffer until a complete PS packet is received. Parse the video data carried in the complete PS packet into an ES stream and put it into the main H.264 buffer and the secondary H.264 buffer.

[0062] Step 4: Split the ES stream in the main H.264 buffer into frames and put each complete H.264 frame into the frame buffer;

[0063] Step 5: Split the ES stream extracted from the PS packet into frames. When splitting frames, split the last buffer of the secondary H.264 buffer into frames and put each complete H.264 frame into the frame buffer to ensure that there is always a picture on the playback end.

[0064] Step 6: Pack the entire H.264 frame into a WebRTC stream using the packing module;

[0065] Step 7: Based on the transmission bitrate fed back by the IGCC-A algorithm in the congestion control module, push the packaged stream to the WebRTC streaming media module through the URL push module.

[0066] like Figure 3 As shown, the conversion system built using the real-time conversion method of GB / T28181 for converting PS streams to WebRTC live streams includes a PS stream receiving module, an RTP payload PS packet caching module, a media stream caching module, an H.264 frame packing module, and a URL push streaming module.

[0067] The PS stream receiving module is responsible for receiving RTP packets carrying the PS stream. The RTP payload PS packet buffering module is responsible for parsing the RTP packets carrying the PS stream. It first finds the first RTP packet carrying the PS header, then places the RTP packet carrying the PS packet into the PS packet buffer. It also checks if the RTP packet sequences are consecutive. If consecutive, the main H.264 buffer is split into frames in the media stream buffering module. If not consecutive, the PS buffer is cleared, along with the main H.264 buffer and frame buffer. The last ES stream in the secondary H.264 buffer is split into frames to ensure the playback end always has a picture. The PS packet parsing module is responsible for parsing the RTP packets in the PS packet buffer, while continuously receiving RTP packets and placing them into the PS packet buffer until a complete PS packet is received. Finally, it parses the video data carried in this complete PS packet and places it into the main H.264 buffer and the secondary H.264 buffer. The media stream caching module is responsible for splitting the H.264 data (ES stream) in the main H.264 buffer and the secondary H.264 buffer into frames, and placing each complete H.264 frame into a frame buffer. The H.264 frame packaging module is responsible for packaging the complete H.264 frames into WebRTC frames. The congestion control module sends TransportFeedback messages through the WebRTC streaming module, estimates the transmission bitrate based on the IGCC-A algorithm, and sends the transmission bitrate to the URL push streaming module. Finally, the URL push streaming module pushes the stream to the WebRTC streaming module via a URL address based on the transmission bitrate estimated by the congestion module.

[0068] The IGCC-A algorithm is an optimized version of the GCC algorithm, and the optimizations include:

[0069] 1) Improvements to the delay jitter problem: The GCC algorithm groups packets into groups, with each group consisting of packets within a 5ms interval. It calculates the one-way transmission delay for each group by using the transmission time of the first packet in the i-th group and the time of the last received packet within that group. This data is then passed to a Trendline filter to calculate the linear slope of the delay variation.

[0070] The improved method addresses the issue that network conditions can cause packets to arrive out of order, with some arriving very close together and others far apart, rather than being grouped according to the 5ms intervals at the time of transmission. Therefore, the IGCC-A algorithm groups packets with similar arrival times into one packet group and calculates only one delay change, while packets that are far apart are grouped into different groups. This avoids the situation where, when sudden jitter occurs, the original algorithm calculates the one-way delay change by packet group, causing the delay-based rate controller to mistakenly interpret it as congestion and reduce bandwidth.

[0071] The original delay-based rate controller algorithm is quite sensitive; bandwidth drops directly when network jitter occurs. Therefore, the IGCC-A algorithm optimizes this by: after detecting congestion changes, the additive (increase-increase, multiplicative-decrease) rate controller does not immediately reduce bandwidth. Instead, it observes six round-trip times. If overuse persists, bandwidth is reduced, repeating this process three times until it reaches 0.85 times the successful reception rate. The IGCC-A algorithm groups packets with similar arrival times into a single packet group and calculates only one delay change, while packets with significantly different arrival times are grouped separately. This avoids the original algorithm's error of calculating unidirectional delay changes by packet group when sudden jitter occurs, which could lead the delay-based rate controller to mistakenly interpret as congestion and reduce bandwidth. Figure 4 As shown.

[0072] 2) Calculate t in GCC based on packet loss rate and latency variation respectively. i The two candidate transmission rates A at time A s (t i ) and A r (t i After that, IGCC-A makes its decision as follows:

[0073]

[0074] Where A(t) i ) for t i The transmission bit rate at time t, and the constraint function P(t) i The value of P(t) represents the value of IGCC-A allowing the current congestion algorithm to ignore minor latency fluctuations when the call quality of the current session is sufficiently reliable. i When )>0, IGCC-A directly selects the rate given by the rate controller based on the packet loss rate as the current target transmission rate; once the value of the constraint function does not meet the requirements, i.e., P(t) i When )≤0, IGCC-A revoked the permission and performed congestion control according to the original GCC algorithm rules;

[0075] To allow the constraint function to adapt more flexibly to different packet loss rates and latency fluctuations, we define the constraint function as follows:

[0076]

[0077] Where f r (t i ) and f l (t i ) represents t i RTT and packet loss rate at any given time and Representing additional factors The impact on the constraint function is considered. Furthermore, once the packet loss rate exceeds 3%, the network quality of the live channel is deemed suboptimal, and minor latency fluctuations are no longer ignored. In P(t) i When )>0.

[0078] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A WebRTC video conferencing system compatible with GB / T28181 equipment, characterized in that: The system adopts a layered architecture, including a business layer, a STUN / TURN server, a signaling layer, and a media layer. The business layer is used to provide business interfaces for WebRTC clients and store business data. STUN / TURN server: used to implement NAT traversal; The signaling layer includes a WebRTC signaling module, a signaling protocol conversion module, and a GB / T28181 signaling module; The WebRTC signaling module enables signaling interaction between the video conferencing system and the client; the signaling protocol conversion module enables conversion between WebRTC signaling and GB / T28181 signaling; and the GB / T28181 signaling module enables session establishment with GB / T28181 terminal acquisition devices. The media layer includes a WebRTC media module, a media transcoding module, a congestion control module, and a GB / T28181 media module. The WebRTC media module enables media transmission between the video surveillance equipment and the WebRTC client. The media transcoding module converts the WebRTC media stream to the GB / T28181 media stream. The GB / T28181 media module enables media transmission with the terminal acquisition device. The congestion control module, located between the transcoding module and the WebRTC media module, reduces packet loss and network latency in the network. The congestion control module uses the IGCC-A algorithm for congestion control. The IGCC-A algorithm is an optimized version of the GCC algorithm, and the optimizations include: 1) After detecting congestion changes, the additive rate controller does not immediately reduce bandwidth. Instead, it observes six round-trip times. If overuse still occurs, it reduces bandwidth three times consecutively until it reaches 0.85 times the successful reception rate. The IGCC-A algorithm groups packets with similar arrival times into one packet group and calculates only one delay change. Packets that are far apart are grouped into different groups. This avoids the original algorithm from calculating unidirectional delay changes by packet group when sudden jitter occurs, causing the delay-based rate controller to mistakenly identify congestion and reduce bandwidth. 2) Calculate t in GCC based on packet loss rate and latency variation respectively. i Two candidate transmission rates at time A S ( t i )and A r ( t i After that, IGCC-A makes its decision as follows: ， in, A ( t i )for t i Transmit bitrate at time t, constraint function P ( t i The value of ) represents the value of IGCC-A allowing the current congestion algorithm to ignore minor latency fluctuations when the call quality of the current session is sufficiently reliable. P ( t i When the packet loss rate is greater than 0, IGCC-A directly selects the rate given by the rate controller based on the packet loss rate as the current target transmission rate; once the value of the constraint function does not meet the requirements, i.e. P ( t i When )≤0, IGCC-A revoked the permission and performed congestion control according to the original GCC algorithm rules; To allow the constraint function to adapt more flexibly to different packet loss rates and latency fluctuations, we define the constraint function as follows: ， in, and represent t i RTT and packet loss rate at any given time and Representing additional factors The impact on the constraint function is considered. Furthermore, once the packet loss rate exceeds 3%, the network quality of the live channel is deemed suboptimal, and minor latency fluctuations are no longer ignored. hour.

2. The WebRTC video conferencing system compatible with GB / T28181 equipment according to claim 1, characterized in that, The implementation of the media layer interface includes obtaining the local media stream (getMedia), establishing a real-time communication connection (RTCPeerConnection), a real-time communication data channel (RTCDataChannel), and creating a GB / T28181 RTP packet receiving port (openRtpServer).

3. The WebRTC video conferencing system compatible with GB / T28181 equipment according to claim 2, characterized in that, The `getMedia` interface is used to acquire media streams captured from the local camera and microphone; the `RTCPeerConnction` interface is used to establish a connection for transmitting data streams between two nodes; the `RTCDataChanne1` interface reliably and efficiently transmits data of any format between two users, and also implements the `getThreadsLoad` interface for acquiring network thread load, the `openRtpServer` interface for the RTP packet receiving port of the GB / T28181 stream, the `closeRtpServer` interface for closing the RTP packet receiving port of the GB / T28181 stream, the `getRtpInfo` interface for acquiring RTP push end information, and the `ProcessInterface` interface for RTP packet processing; it creates the GB / T28181 RTP packet receiving port `openRtpServer`, which will be automatically reclaimed if the data reception on this port times out, and closes the GB / T28181 RTP receiving port `closeRtpServer`, the `getRtpInfo` interface for acquiring RTP push end information, and the `ProcessInterface` interface for RTP packet processing.

4. The WebRTC video conferencing system compatible with GB / T28181 equipment according to claim 3, characterized in that, The getMedia interface uses the getUserMedia format, which includes constraints, successCallback, and errorCallback. Constraints represent settings for whether audio and video are supported, and are in JSON string format. successCallback is a function that will be executed if the retrieval is successful. errorCallback is a function that will be executed if the retrieval fails.

5. A media stream conversion method based on the conferencing system of claim 1, 2, 3, or 4, characterized in that: The media stream conversion is used to convert GB / T28181 media streams to WebRTC streams. The specific steps are as follows: Step 1: The receiving port receives RTP data packets carrying PS streams. First, it finds the first RTP packet carrying the PS packet header, and then puts the RTP packet carrying the PS packet into the PS packet buffer. Step 2: Check if the RTP packet sequences are continuous. If they are continuous, proceed to step 3. If they are not continuous, clear the PS buffer, clear the main H.264 buffer and frame buffer, and jump to step 5. Step 3: Parse the RTP packets in the PS packet buffer, and continue to receive RTP packets and put them into the PS packet buffer until a complete PS packet is received. Parse the video data carried in the complete PS packet into an ES stream and put it into the main H.264 buffer and the secondary H.264 buffer. Step 4: Split the ES stream in the main H.264 buffer into frames and put each complete H.264 frame into the frame buffer; Step 5: Split the ES stream extracted from the PS packet into frames. When splitting frames, split the last buffer of the secondary H.264 buffer into frames and put each complete H.264 frame into the frame buffer to ensure that there is always a picture on the playback end. Step 6: Package the complete H.264 frames in the frame buffer into a WebRTC media stream using the packaging module; Step 7: Based on the transmission bitrate fed back by the IGCC-A algorithm in the congestion control module, push the packaged stream to the WebRTC streaming media module through the URL push module.

Images