I have a simple application where I send OPUS packets from one client to other say A to B.
A reads one packet from a OPUS file, and send to B.
Again after 20ms or 30ms reads one more packet and send to B, so on..
Till now I was using RTP over UDP, so on receiving side at B, when I receive the packet, I receive complete packet. After receiving complete packet I write to a new file.
This works fine.
Now I am planning to support RTP over TCP.
A will read a complete packet from OPUS file and send to B.
When packet is received at B, it may be received as a single packet or multiple packet (tcp behaviour). My requirement is, I should buffer the data till I receive complete packet. Once I receive complete packet, I will write it to a file.
Now my question is, how do I determine the length of OPUS packet at B while I receiving, so that I can buffer it.
Do not want to use libopus etc if somehow I can avoid it. If by any means from received data, can I find out length of packet?
TCP is a stream protocol. You have two primary choices: add a length word (16 bits is enough) before each Opus packet (read length, then read packet, dealing with buffering (wait to get enough bytes for the read), or pad every Opus packet to a specific size. Opus doesn't use fixed-size packets; they depend on the content and the bitrate and quality settings.
Related
I want to simulate a simple client/server application streaming 2-3 4k 25 fps videos within 5G network using OMNeT++ stack. After capturing all incoming video flows with opencv and encoding with h264 codec I have roughly 20 kilobytes for each frame encoded as bytes -- uint8_t. Of course capturing for each of flow happens in a separate thread.
Now I want to send it to some clients over 5G using UDP protocol. If you look almost at every open source implementation of video streaming, the process of transmission is presented very simple:
uint_8* buffer; // encoded frame
int size; // buffer size
send(clientSocket, buffer, size, 0); // send to client
and on the client side a loop with an appropriate recv pulls. The same basically happens in every OMNeT++ simualtion.
Of course a UDP packet with around 20Kb payload will be fragmented on its way to pass good old IPv4 1500 bytes MTU at the backhaul part of a standard 5G architecture. So here comes my question: could I benefit something if I try to reduce my maximal UDP payload to, let's say, 1280 bytes to avoid IP fragmentation and to fit IPv6 minimum reassembly buffer size?
I'm afraid that if I just cluelessly send the encoded frame as in the code above, some fragmented packets may be lost and my decoder (h264 as well) on the client side can fail to decode the frame. Well however the same could happen if I send mine fragmented 1280 bytes packets... so here the question is pretty general, considering the fact that it happens in OMNeT++ simulation but with real video files: is there any advantage of controlling the packet size before sending or you just can cluelessly send any less than 64 Kb UDP datagram and just chill?
I am writing a program for receiving udp multicast packet. I came across short read. Is that applicable to udp? How do I ensure that I read one packet at a time? Is that possible?
My packet has a fixed size header followed by a variable length body.
https://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/overview/core/streams.html#:~:text=When%20a%20short%20read%20or,write()%20and%20async_write()%20.
"I came across short read"
What does that mean? You mean you "heard about it"? Or received the error?
Is that applicable to udp?
No. UDP is connectionless and DATAGRAM.
How do I ensure that I read one packet at a time?
That's how UDP works.
Is that possible?
Something else is not possible, although you can set flags that allow an incomplete datagram when the supplied buffer is too small to receive the complete datagram.
My packet has a fixed size header followed by a variable length body.
SUMMARY
The title of the page you linked was Streams, Short Reads and Short Writes. Your sockets are UDP, that is, not streams.
Im trying to figure out which is the maximum size of a RTP packet. I know that the minimum header size is 12 bytes, but i dont find anything about the payload.
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size? I mean, that i have only a RTP packet with a huge payload. Is this possible and, in this case, there is any recommended size for the RTP packet for not doing this?
For example im encapsulating MP3 frames in RTP. Do I make an RTP frame with 1 MP3 frame, 2, or how many?
I hope you understand my question :)
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size?
The RTP standard does not set a maximum size so you're free to do this.
(Jumbo packets often have issues of their own with transport, but that's generally to do with the lower layer protocols playing up.)
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size? I mean, that i have only a RTP packet with a huge payload. Is this possible and, in this case, there is any recommended size for the RTP packet for not doing this?
Yes, you could create a 1446 byte long payload and put it in a 12 byte RTP packet (1458 bytes) on a network with an MTU of 1500 bytes.
By the time you include an 8 byte UDP header + 20 byte IP header + 14 byte Ethernet header you've 42 bytes of overhead which takes you to 1500 bytes.
In practice if you're transporting this over the internet, this traffic is getting encapsulated or carried across varied transport layers, you'd probably want to keep it below 1400 bytes to be on the safe side.
For example im encapsulating MP3 frames in RTP. Do I make an RTP frame with 1 MP3 frame, 2, or how many?
RTP has a one-to-one mapping from one unique source to one RTP stream (Unless the streams are mixed/muxed together into one stream) so each of the MP3 sources would be put into their own RTP stream, each with it's own unique Synchronization Source Identifier (SSRC) to differentiate between each stream.
For more info on RTP there's the RFC 3550 itself, there's a great book by Colin Perkins called "RTP: Audio and Video for the Internet", I'vea fair bit on RTP on my blog and I've also created a Python library for creating RTP packets.
when transmit data from esp32 to an esp32,does the BLE's libary contain errorchecking? AKA resending packets? uses Ack-Naks? error correction also?
Thanks
There is error checking.
You can check if a write was successful.
A Ble packet consist of:
Preamble: RF synchronization sequence.
Access address: 32 bits, advertising or data access addresses (it is
used to identify the communication).
Header: its content depends on the packet type (advertising or data
packet).
Length: Length of the data payload(When encryption is used, the
message integrity code (MIC) at the end of the packet is 4 bytes, so
this leads to 251 bytes as actual maximum available payload size.
Checksum: CRC.
There is no error correction or resending of packets, unless you implement it yourself.
So,if a write was not successful you can resend a packet.
We are making calls using JsSIP. We are seeing "Sender's packet count" is very high in Wireshark. Can some one explain what is this Sender's count and why this count is so much big?
It means "total number of RTP data packets transmitted by the sender".
RTCP packets contain statistics about an RTP session.
RTP packets carry audio and video stream data. So, high number of RTP packets is normal in most situations.