SRT or RTMP for Records / VOD ?

[ericsouza]

Hey! First of all thanks for this masterpiece of software engineering.

Well, I have a need to stream in real-time but also record in a way that I cannot miss any frames. I know that this is possible with RTMP because of YouTube and Twitch that works really well saving the VODs. My question is if SRT provides the same guarantees of not loosing any frame.

[ethouris]

It can be configured this way. The SRTO_TLPKTDROP option controls the dropping, and it can be set to false to disable it.

Note though that the possibility of losing the data exists for a reason. It results simply from the rule that SRT controls the bandwidth only exceptionally (to avoid spikes), but the overall transmission bitrate should be kept as configured on the encoder (so, in distinction to TCP, as well as file mode in SRT itself, it doesn't slow down sending any further). If the network can't withstand this bandwidth, even if it happens rarely and occasionally, you have only two possibilities: either you allow the data to be partially dropped, or you risk having the head-of-the-line-blocking problem. In RTMP you usually don't have this problem because in order to keep up with the live streaming requirements, you need to have the bitrate way below the bandwidth limit. Of course, adaptive bitrate can solve this problem, but in case of SRT it must be done at the application's side.

WIth the default settings then SRT does drop packets that were lost and not recovered on time, This can be turned off by setting SRTO_TLPKTDROP option to false; note though that avoiding the risk of head-of-the-line-blocking problem must be somehow solved by the application. With this option set this way, SRT will stubbornly recover every single packet, even if it means holding up packets following the loss infinitely long (this risks having the receiver buffer overflown, which in case of a live stream can only end up with a broken connection). Note that SRT even in this form has an advantage over TCP (and so RTMP) due to recovering the loss quicker (immediate loss reports and repeated loss reports). For that there might be interesting options like SRTO_NAKREPORT (default: true, sets the repeated loss reports) and SRTO_RETRANSMITALGO (default: 1, which currently avoids retransmissions done too early since the last one), although their default values should ensure best efficiency.

[ericsouza]

Thanks for the detailed explanation!