I am working on RTP IN/OUT with mediasoup server. There are two implementations which give very different results.
In implementation 1, when I stream rtp media over mediasoup, so many packet loss occurs both during RTP IN and during RTP OUT in a way that I cannot view proper video on receiver side.
For example; 20mbps data enters mediasoup server, but only 8mbps data leaves the mediasoup in direction to receiver.
In implementation 2, when I stream rtp media directly to public ip of an endpoint and port, streaming quality is flawless.
I would like to blame my ffmpeg implementation but if I had issue in my implementation then why does my implementation 2 work properly even in >4K resolutions?
I can publish all trace logs etc…
But at first glance what would be the issue?
Thanks in advance
The Linux server in dev Hugh you are running mediasoup is probably facing UDP packet loss due to kernel limits. Search for “increase Linux UDP buffer” to solve it. Not a mediasoup limitation. This kind of setup must be done in any server running a RTP UDP stack.
El El mar, 17 ene 2023 a las 0:38, serio via mediasoup <email@example.com> escribió:
Increasing UDP buffer in mediasoup server Linux pc didn’t solve the problem for now. I need to investigate further. I will share the solution if I find it.
Referring to the picture above, I did more research and found out why implementation 2 works well but implementation 1 has packet corruption.
The default udp packet size for ffmpeg rtp streaming is 1472 bytes. So, when I send rtp end-to-end, as shown in implementation 2, the sender sends 1472 bytes and the receiver receives 1472 bytes. There is no reason for udp fragmentation to happen because the value is not close to the default udp packet size of 1500 bytes. But if I change the udp pkt size from 1472 to 1500 in the rtp sender and send it to mediasoup, it gives the following warning (that is expected).
I think the warning threshold for RTP IN and RTP OUT on mediasoup is set to 1500.
What went wrong with implementation 1’s packets? I found out later that it was “udp fragmentation.” Because mediasoup adds a 20-bytes additional data before sending RTP IN to RTP OUT, if we set the rtp sender udp packet size to 1472 bytes in ffmpeg, it sends 1472 bytes to mediasoup but 1492 bytes out. 1492 is a risky value because it is close to the limit (1500 bytes), which in my case was causing the udp fragmentation.
I didn’t figure this out until much later because mediasoup didn’t give me warning me until the packet size was over 1500, but udp fragmentation can happen even when the packet size is over 1472.
To sum up,
All of my problems were solved by two key steps.
1-Increasing the size of the UDP read/write buffer in the mediasoup server PC
2-Limiting the packet size in the RTP sender so that it doesn’t go over 1452. (rtp:/ip:port?pkt size=1452)
RTP IN (1552 bytes) —> Mediasoup —> RTP OUT (1552 + 20 = 1472 bytes).
My question is why does mediasoup add 20 bytes before it forwards rtp ?
(In the picture you can see producer trace packet size =1496 , consumer trace packet size = 1516)
Because it adds RTP header extensions in the packet depending on receiver announced capabilities.
how to expand the buffer of udp?
Assuming you’re using linux, look at tuning the following kernel parameters:
In our setup, we set these parameters in a sysctl.d config file on boot.