Not Receiving RTP Packets from FFmpeg about uvgrtp HOT 5 CLOSED

It appears that winsock is not even seeing the UDP packet from ffmpeg. In line 451 of reception_flow.cc I see that pfds->revents == 0, so there is no data to start processing. This is truly strange as I see UDP packets going to the same port when I run ffmpeg and the uvgrtp sender, but in the case of ffmpeg winsock is not getting any packets.

On closer inspection this was due to telling ffmpeg to send to "localhost", which caused it to send to ipv6 ::1. It looks like the library won't find localhost ipv6 unless explicity listening to ::1, which I ended up needing to use to listen to another media server.
I'm now handling a different issue, on line 879 of socket.cc the WSARecvFrom call returns -1.

from uvgrtp.

I found that WSARecvFrom was failing with code 10040 WSAEMSGSIZE.
On line 874 of socket.cc I increased the buffer length by 8 and it is now capable of handling ffmpeg's RTP packets. I imagine there's more data coming in than was used to compute buf_len, which was causing it to fail. I can continue with my patch but it's probably worth finding out why the buffer is too short.

from uvgrtp.

If you try to increase in RCC_MTU_SIZE, does it work then? IIRC FFmpeg sent a few extra bytes over 1500 which caused issues but I can't find a reference for it now

from uvgrtp.

Hello,

@dagrooms52 what is the situation with this? I think @altonen meant reducing the MTU size in uvgRTP so that they fit when the MTU size of the network is smaller than the default size in uvgRTP. We are currently working on a paper, but after that we can get more involved in helping with issues.

BR, Joni

from uvgrtp.

As I am reading the issue, it indeed seems that either decreasing the sending side MTU or increasing the receiving side MTU is the answer. This buf_len value is determined said RCC_MTU_SIZE flag. This can be changed with configure_ctx function in media_stream. I'm closing this issue.

Better default MTU size values can be suggested, but increasing means that it does not pass through all connections. It still might be worth it though if it means we operate better with ffmpeg.

BR, Joni

from uvgrtp.