Choose the right Input Protocol
Quortex I/O offers two different Protocols to submit Input Channels, SRT and RTMP. Since both Protocols have extremely different Characteristics in terms of Reliability and Security, we want to take a deeper look into both to help you understand the differences and choose the right one for your Workflow.
The Real-Time Messaging Protocol (RTMP) is a mature, well established streaming protocol with a reputation for reliability thanks to its TCP-based packet-retransmit capabilities and adjustable buffers.
Secure Reliable Transport protocol (SRT) is an open source protocol which leverages an intelligent packet retransmit mechanism on top of a UDP data flow, along with AES256 encryption.
RTMP used to be a de facto standard and still is a widely used transport protocol when it comes to contributing to Platforms like Youtube, Facebook etc. It is fairly easy to use and manage from a IT perspective, since it will always use the same port (1935) for Streaming. In Comparison to RTMP, SRT is a more recent standard, established in 2017. It uses single ports per connection, in a more recent version of the Protocol port multiplexing (StreamID), to have a RTMP like port overhead, is supported.
While SRT operates “content agnostic” TS based, RTMP comes with some limitations when it comes to codecs, audio tracks, descriptors and subtitles. For instance, you can have only one audio stream in RTMP, subtitle handling is very limited, and SCTE35 markers (for ad insertion) are not supported.
Another main difference between RTMP and SRT is the absence of timestamps in the RTMP stream packet headers. RTMP only contains the timestamps of the actual stream according to its frame rate. The individual packets do not contain this information, therefore the RTMP receiver must send each received packet within a fixed time interval to the decoding process. To smooth out differences in the time it takes for individual packets to travel, large buffers are required.
SRT on the other hand, includes a timestamp for each individual packet. This enables the recreation of signal characteristics on the receiver side and dramatically reduces the need for buffering. In other words, the bit-stream leaving the receiver looks exactly like the stream coming into the SRT sender.
Another significant difference between RTMP and SRT is the implementation of packet retransmission. RTMP is based on TCP, which relies on acknowledgments reported by the receiver. However, these acknowledgments (ACKs) are not reported immediately to the sender in order to keep the return traffic low. Only after a sequence of packets has been received, will a report of ACKs or NACKs (negative acknowledgments) be sent back. If there are lost packets within that sequence, the complete sequence of packets (going back to the last ACK) will be retransmitted.
By contrast, SRT can identify an individual lost packet by its sequence number. If the sequence number delta is more than one packet, a retransmission of that packet is triggered. Only that particular packet is sent again, to keep latency and overhead low.
Suggestion: if you don’t know how far away you are from your ingest point (in terms of RTT) and/or you are uncertain about the characteristics of your connection, definitely use SRT. If you have more than one audio stream of if you want to insert subtitles, use SRT as well.
The Real-Time Messaging Protocol (RTMP) is a mature, well established streaming protocol with a reputation for reliability thanks to its TCP-based packet-retransmit capabilities and adjustable buffers.
Secure Reliable Transport protocol (SRT) is an open source protocol which leverages an intelligent packet retransmit mechanism on top of a UDP data flow, along with AES256 encryption.
RTMP used to be a de facto standard and still is a widely used transport protocol when it comes to contributing to Platforms like Youtube, Facebook etc. It is fairly easy to use and manage from a IT perspective, since it will always use the same port (1935) for Streaming. In Comparison to RTMP, SRT is a more recent standard, established in 2017. It uses single ports per connection, in a more recent version of the Protocol port multiplexing (StreamID), to have a RTMP like port overhead, is supported.
While SRT operates “content agnostic” TS based, RTMP comes with some limitations when it comes to codecs, audio tracks, descriptors and subtitles. For instance, you can have only one audio stream in RTMP, subtitle handling is very limited, and SCTE35 markers (for ad insertion) are not supported.
Another main difference between RTMP and SRT is the absence of timestamps in the RTMP stream packet headers. RTMP only contains the timestamps of the actual stream according to its frame rate. The individual packets do not contain this information, therefore the RTMP receiver must send each received packet within a fixed time interval to the decoding process. To smooth out differences in the time it takes for individual packets to travel, large buffers are required.
SRT on the other hand, includes a timestamp for each individual packet. This enables the recreation of signal characteristics on the receiver side and dramatically reduces the need for buffering. In other words, the bit-stream leaving the receiver looks exactly like the stream coming into the SRT sender.
Another significant difference between RTMP and SRT is the implementation of packet retransmission. RTMP is based on TCP, which relies on acknowledgments reported by the receiver. However, these acknowledgments (ACKs) are not reported immediately to the sender in order to keep the return traffic low. Only after a sequence of packets has been received, will a report of ACKs or NACKs (negative acknowledgments) be sent back. If there are lost packets within that sequence, the complete sequence of packets (going back to the last ACK) will be retransmitted.
By contrast, SRT can identify an individual lost packet by its sequence number. If the sequence number delta is more than one packet, a retransmission of that packet is triggered. Only that particular packet is sent again, to keep latency and overhead low.
Suggestion: if you don’t know how far away you are from your ingest point (in terms of RTT) and/or you are uncertain about the characteristics of your connection, definitely use SRT. If you have more than one audio stream of if you want to insert subtitles, use SRT as well.
Updated on: 01/03/2024
Thank you!