[SRT]1.Protocol introduction

1 Introduction


Secure Reliable Transport (SRT) for short, is an open source Internet transmission protocol based on the UDT protocol. Haivision and Wowza have cooperated to establish the SRT Alliance, an organization that manages and supports open source applications of the SRT protocol. This organization is committed to promoting video streaming. The interoperability of solutions and the advancement of collaboration among pioneers in the video industry enable low-latency network video transmission.

        SRT is a very popular open source low-latency video transmission protocol nowadays. SRT solves complex transmission timing problems. SRT can reduce delays, eliminate central bottlenecks, and reduce network costs.

        SRT (Secure Reliable Transport) is a transmission protocol for ultra-low (sub-second) delay real-time audio and video streaming and general batch data transmission. SRT solves complex transmission timing issues and can support real-time transmission of high-throughput files and ultra-clear videos.​​​​​​      

        SRT is an open source technology whose code

srt: Synchronized SRT library, if there is any infringement, please contact me for deletionicon-default.png?t=N7T8https://gitee.com/smartavs/srt


2.Characteristics


 2.1.Quality and reliability

No matter how unreliable your network is, SRT can recover from severe packet loss and jitter, ensuring the integrity and quality of your video streams.

2.2. Low latency

​​​​ In order to adapt to various deployment environments of users, SRT’s flow error correction strategy is configurable. Since SRT is built on the UDP protocol, it solves the problem of high transmission delay of the TCP protocol.

2.3. The content is not sensitive

SRT operates at the network transport layer and can transport any type of video format, codec, resolution or frame rate.

2.4. Use rendezvous mode to easily traverse firewalls

​​​​​The handshake process used by SRT supports outbound connections, that is, it only requires the public IP addresses of both parties, and there is no need to open port mapping in the firewall.

​​​​​​ Additionally, using connections directly from source to destination, SRT can reduce latency, eliminate central bottlenecks, and reduce network costs.

​​​​ Principle: The source and destination ports of both parties are completely consistent, achieving the purpose of deceiving the firewall to pass through, thereby establishing a connection. There is a problem that if the port is switched during network transmission, the connection cannot be made.

2.5.AES encryption

​​​​ SRT uses 128/192/256-bit AES encryption trusted by governments and organizations around the world to ensure valuable content is protected end-to-end and cannot be distributed.

2.6. Forward Error Correction (FEC) and Packet Filter API

​​​​​ Packet Filter AP allows customized processing on the sender side of network packets before they are sent, and allows customized processing on the receiver side after receiving network packets from the network.

​​​​​​ Users can manipulate the generated packet filter data in any way, such as for custom encryption, packet inspection, or to access the data before it is sent.

​ The first plugin created is Forward Error Correction (FEC), which can provide slightly lower latency than Automatic Repeat Request (ARQ) in certain use cases. This plugin allows three different modes:
​ ​                                                                                               using ’ s ’ s ’s ’ s ‐   ‐                                   having /span> ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ and ARQ ​​ by FEC and ARQ ​​retransmit lost packets that FEC cannot recover

2.7. Seamless connection

​​​​​ Similar to the management network SMPTE-2022-7, connection bonding adds seamless flow protection and failover to the SRT protocol. The technology relies on multiple IP network paths to prevent network congestion or outages from causing outage of live video streams, thus maintaining service continuity.

​​​​​ This feature is implemented by using socket groups introduced in SRT v1.5. A socket group contains multiple sockets. When the socket in use sends a failure signal, other sockets in the group will take over its operation.

Currently two modes are supported:

​         Broadcast mode – In broadcast mode, data is sent redundantly through all member links in the group. If one of the links fails or experiences network jitter and/or packet loss, the lost data will be received through the other link in the group. Redundant packets are simply discarded at the receiver side.
Master/Reading Mode-In the main/backup mode, use only one (main) link for data transmission at a time, while other (backup) connection is in a backup state to ensure the main chain chain Transmission will continue when the path fails. The goal of primary/backup mode is to identify possible link outages before they occur, thereby providing a time window within which to seamlessly switch to one of the backup links.

2.8. Access control (stream ID)

​​​​​ When multiple SRT streams need to be pushed/pulled to a single IP address and UDP port, use the stream ID to distinguish the push/pull behavior.

3.Comparison with common transmission formats

There are currently two types of live video broadcasts on the Internet:

One is a live broadcast based on the RTMP protocol. This live broadcast method uses the RTMP protocol upstream, and the downlink uses RTMP, HTTP+FLV or HLS. The live broadcast delay is generally more than 3 seconds. Live broadcast satisfies scenarios that do not require high interaction;

​​​​​ The other is the live broadcast of the WebRTC protocol. This live broadcast method uses the UDP protocol to distribute streaming media. The live broadcast delay is less than 1 second, and the number of simultaneous connections is generally less than 10. It is mainly used in video calls, shows, etc. Application scenarios.

In addition to the above two scenarios, there is also a video live broadcast scenario, which is a scenario that requires both low latency and large concurrency, such as event live broadcast, stock information synchronization, large class education, etc. SRT can well meet the requirements of the above scenarios.

        SRT works with most other video streaming formats currently on the market (such as RTMP, HLS and MPEG-DASH). It has several characteristics:

  • SRT is an open source solution that has been integrated into multiple platforms and architectures, including hardware-based portable solutions and software-based cloud solutions.
  • SRT works well on connections with delays ranging from a few milliseconds to a few seconds. Can handle long network delays.
  • SRT is load independent. Any type of video or audio media, or indeed any other data element that can be sent using UDP, is compatible with SRT. Supports multiple stream types.
  • SRT sending supports multiple concurrent streams. Multiple different media streams such as multiple camera angles or optional audio tracks can be sent via parallel SRT streams sharing the same UDP port and address on a point-to-point link.
  • The handshake process used by SRT enables outbound connections without the need to open dangerous permanent external ports in the firewall, thus maintaining corporate security policies. Enhanced firewall traversal.
  • SRT endpoints establish a stable end-to-end latency profile, eliminating the need for downstream devices to have their own buffers to account for changing signal delays. The signal time is accurate.

Guess you like

Origin blog.csdn.net/weixin_35804181/article/details/133764190