search

Haivision / srt

Secure, Reliable, Transport
https://www.srtalliance.org
Mozilla Public License 2.0
3.12k stars 853 forks source link

Bitrate control to prevent socket disconnection #3045

Closed sinais54 closed 1 month ago

sinais54 commented 1 month ago

hello I use srt-live-transmit to send a live video to an SRT relay server on a VPS. My method of use is as follows: using ffmpeg, I take the video from the camera and after setting the bitrate, I send it to srt-live-transmit with UDP to be sent to the server. The bandwidth of the network I use is low and fluctuates a lot, and its upload speed varies between 5Mbps and 0.2Mbps. When I increase the bitrate, the socket connection between vps and srt-live-transmit drops after a few seconds. I think that this happens because of the decrease in network bandwidth and as a result, the bitrate value is higher than the bandwidth capacity. My idea is to use the parameters in the srt-live-transmit logs to notice the bandwidth reduction and reduce the bitrate in ffmpeg before disconnecting. Is such a thing possible? If so, how do I know when it's time to change the bitrate?

ethouris commented 1 month ago

It is not possible first of all because the times when sending packets are decided by the application. SRT doesn't regulate anything time-related here because this must be correlated with the timestamps in the live stream, of which SRT has no idea. All you can count on from SRT are the running statistics that you can read to have idea of what is going on on the link. If you need that your application temporarily reduce the bitrate, these statistics can hint you the necessity of doing it.

See statistics such as pktFlightSize, pktFlowWindow and byteAvailSndBuf (or better pktSndBuf if you know the size of the sender buffer expressed in packets).

sinais54 commented 1 month ago

Thank you very much for your good and timely reply.

If I want to display only the logs of one socket ID, is there an option for this?

2024-10-11T23:04:13.816642-0900,28004,832935780,28004,8192,8192,0,0.205,123.984,1000,0,0,0,0,0,0,0,0,0,12288000,0,0,12,109,109,0,0,0,0,0,0,0,130944,130944,0,0,12244500,96,0.730063,120 2024-10-11T23:04:13.816812-0900,32286,832935781,32286,25600,8192,4,146.617,982.08,20,115,115,0,0,0,0,139856,139856,0,12261000,178,0.779968,450,0,0,0,0,0,0,0,0,0,0,0,0,0,12286500,0,0,1000 2024-10-11T23:04:14.783523-0900,28971,832935780,28971,8192,8192,0,0.215,126.552,1000,0,0,0,0,0,0,0,0,0,12288000,0,0,12,97,97,0,0,0,0,0,0,0,118196,118196,0,0,12249000,95,0.977955,120 2024-10-11T23:04:14.783695-0900,33253,832935781,33253,25600,8192,7,187.115,1555.76,20,92,92,0,0,0,0,110644,110644,0,12259500,180,0.91547,443,0,0,0,0,0,0,0,0,0,0,0,0,0,12286500,0,0,1000 2024-10-11T23:04:15.708233-0900,29896,832935780,29896,8192,8192,0,0.131,143.952,1000,0,0,0,0,0,0,0,0,0,12288000,0,0,12,99,99,0,0,0,0,0,0,0,119788,119788,0,0,12253500,95,1.03634,120 2024-10-11T23:04:15.708762-0900,34178,832935781,34178,25600,8192,17,184.65,1071.62,20,100,100,0,0,0,0,121712,121712,0,12250500,216,1.05259,442,0,0,0,0,0,0,0,0,0,0,0,0,0,12286500,0,0,1000

i use this command: ./srt-live-transmit -pf:csv -s 100 srt://127.0.0.1:6002?mode=listener "srt://myip:6001?mode=caller&streamid=publish:/live/stream2&peerlatency=1000&maxbw=2500000&transtype=live&tlpktdrop=true"

sinais54 commented 1 month ago

According to the logs I posted above, could you elaborate on how to use pktSndBuf to achieve what I want?

ethouris commented 1 month ago

pktSndBuf shows you the number of packet units in the sender buffer. Note that in the live mode the use of the sender buffer is kinda specific (in comparison, for example, to file transmission, where you store the buffer full in the beginning and then sending is done as long as the link allows).

In the live mode you have the sender buffer split (logically) into two sections:

In live mode normally you should have at most 2 packets in the SCHEDULED section. More you can have only in case when you have bandwidth limitations applied and packets have to wait longer for a green light.

How much you should have in the HISTORY section, depends on the current RTT, but you can measure it at the time when you observe no lost packets - in which case ACK should come always for the very last packet received at the moment when the ACK is sent, so this way the HISTORY section represents packets in flight. This should be the tolerable size of the buffer.

If the size of the buffer grows enormously above this value, and simultaneously the number of lost packets increases, this is a signal that your link's capacity is currently too small to handle the signal at the current bitrate and it must be then quickly reduced.

ethouris commented 1 month ago

Ah this logging per socket ID - no, this isn't possible, but then if you are using only one SRT connection in the application this shouldn't matter. Note that not every part of the code even KNOWS the socket ID being used because SRT contains a special kind of object that functions as a wrapper over the UDP socket (called "multiplexer"), which allows the facilities using the UDP socket to be shared between SRT sockets (so that you can use a single UDP link to send multiple streams at a time).

sinais54 commented 1 month ago

Thank you for your good explanation