uvgRTP
uvgRTP copied to clipboard
ultravideo
Losing individual frames on Linux with high frame rates/large frames sizes
While the amount of frame loss in uvgRTP over the past 6 months has been cut drastically and streaming in normal conditions should be frame drop free, there are still some special scenarios where frames are lost without a clear reason why this is happening.
My first suggestion would be to take a look at implementing some sort of pacing for the sending end. Even just replacing the sendmmsg(2) command might improve the situation.
I would like to ask if what I'm seeing is related to this issue. I have a roughly 5Mbit h264 720p 40fps stream sent over 100Mb Ethernet with RTP(there is a single switch between the two devices with minimal other traffic). The encoder produces NALs that have to be fragmented so uvgRTP is ideal for the job. However, I'm seeing seemingly random/unexplained packet loss that involves 5 up to 30 packets in a row lost every few seconds. Based on tcpdump capture on the sending end I can see those packets are never sent. On the screenshot attached there is the reciving end on the right and the sending end on the left. It seems packet with seq no 35714 is 23ms later followed by packet seq no 35723. This looks exactly the same on both sides of the link. The sending side has its ethernet txqueuelen set to 10000 and its socket buffer upped to 1MB, with no change.
Please let me know if what I'm seeing is covered by this bug report
No error is returned by the push_frame method when this happens.
@lukolszewski Thanks for your info. Seems like it is either this bug or there is something else wrong with h264 sending. We'll try fixing the missing frames in coming weeks. Once this is fixed, we know more.
@lukolszewski I have been debugging this issue and I did not find any issue with the sending side. The sending side of uvgRTP is relatively simple and should not lose packets randomly. Therefore I don't think even the h264 is at fault.
My first suggestion would be to test without modification to system buffers, the defaults should be enough for normal streams.
One enable flag you could try is flag called RCE_NO_SYSTEM_CALL_CLUSTERING but it probably wont fix the whole issue. I will probaly make this the default situation soon.
For context flags, you could try increasing RCC_UDP_RCV_BUF_SIZE and RCC_UDP_SND_BUF_SIZE, just be careful not to overrun integer type. However, the defaults should more than enough.
If these do not solve your problem, please create a new issue as it is looks like it is a different issue.
I am now able to stream HEVC at high fps values. This requires setting RCC_UDP_RCV_BUF_SIZE in the receiver and adopting FPS API added in 2abf0bc4ef6b041cb8ea38be8aaeea7729b00f18 on the sender side using RCC_FPS_ENUMERATOR.
@lukolszewski you may try if setting the fps values helps in your case as well.
Closing.