send and receiving a video? about uvgrtp

[altonen]

Hello,

uvgRTP uses an 8 KB buffer in the receiving end for datagrams so any packet larger than that is currently incorrectly handled. I'll push a fix later this week that'll increase the size to 65 KB which is the actual maximum size which can be expected so thank you for reporting this bug.

In the mean time, there are two different ways of temporarily fixing this. First is to set the value recv_buffer_len in [1] to 10000 and recompile uvgRTP. This should fix the issue but I'm not 100% certain if that is the only place where this 8 KB max size assumption is made so it may not work.

Another way of fixing this is to provide RCE_FRAGMENT_GENERIC in the flags parameter when you're creating the media. This will fragment the input frame given to push_frame to RTP frames of 1500 bytes and the RTP receiver will reconstruct the full frame from the fragments when pull_frame is called, [2] shows you how to do that

[1] https://github.com/ultravideo/uvgRTP/blob/master/src/pkt_dispatch.cc#L216
[2] https://github.com/ultravideo/uvgRTP/blob/master/docs/examples/sending_generic.cc

[Thanh-Binh]

Thanks for your response.
Why is the data length limited by 65Kbytes?
It is much lower than VGA gray.scaled images!

[altonen]

It's determined by IPv4 packet's max size which is 65 KB. If you want to send larger frames, there are several RFCs which define how a certain media type should be fragmented and transported over the network, e.g., RFC 7798 for HEVC. Because we don't have the manpower to implement all of these payload formats, we've instead implemented a generic interface which can be used to fragment any media. The only problem is that it only works with uvgRTP so you need to use it for both sending and receiving.

[Thanh-Binh]

@altonen thanks.
I understood: because the max size is 65KB so that we have to use RCE_FRAGMENT_GENERIC
But do not understand why this mode sends multiple packets of 1.5KB. Why 1.5KB?

[altonen]

Maximum transmission unit (MTU) [1] defines the size for an Ethernet frame and 1500 bytes is probably the most commonly used size. Basically uvgRTP just tries to fill each Ethernet frame with as much data as possible. You can change this 1.5 KB limit to some other value you find suitable using RCC_MTU_SIZE [2]. For example, if you wanted to fragment the input into frames of 5000 bytes, you would call hevc->configure_ctx(RCC_MTU_SIZE, 5000);.

[1] https://en.wikipedia.org/wiki/Maximum_transmission_unit
[2] https://ultravideo.github.io/uvgRTP/html/classuvgrtp_1_1media__stream.html#addf1cde9cb8c4e4af3160ce24c4288a5

[Thanh-Binh]

Thanks
I have just tested for sending a big data with fragment generic, it works well!
but I want to inform the receiver the image information like width, height, depth etc by initialization!
That means I have to send a small data (4 x 32bits data = 16bytes) firstly .
But I can not receive those data!
Are small data discarded before sending?
Thanks

[Thanh-Binh]

Clear that is limited by 65KBytes but it is bug that smaller data than defined packet value (here 1.5K) is discarded!

[altonen]

Hi and sorry for the long wait.

You're absolutely correct that discarding small packets is not correct. I believe I fixed this and there's even a test case in docs/examples/sending_generic.cc which demonstrates that both large and small packets can be sent through the interface. Looking at the implementation I cannot spot where the bug is so I'll have to write more robust test cases to reveal it. Unfortunately I don't have the time to do that right now.

The hackiest hack I can come up with off the top of my head is to pad your control data (width, height, depth etc.) to, for example, 2000 bytes with zeros and then send that data through the interface. uvgRTP will fragment that into smaller packets and you can receive the whole 2 KB block and then just extract your information from that larger block. This solution is ugly beyond words but it should work if you're able to receive large packets but not small ones.

[Thanh-Binh]

May be you forgot to update it!
I see the last change 14 days as go

[Thanh-Binh]

@altonen Could you please change for supporting 65KBytes?
I really need it for Kvazzup, which does not work correctly with audio. Thanks

[altonen]

It's in master now, I did it last week but forgot to push it to Github.

I'll try to investigate what the issue is with small frames when RCE_FRAGMENT_GENERIC is used

[Thanh-Binh]

Thanks
I am Investing now on echo problem with audio in Kvazzup, which relates to uvgRTP