How to force a process transmit over UDP instead of TCP?
Solution 1
You cannot just force a program to use UDP instead of TCP, without rewriting parts of the program itself. These protocols are just too different to be interchangeable.
TCP is stream-oriented (the receiver sees everything as a continuous stream in the exact order that the sender output it); UDP is datagram-oriented (each datagram is sent in a separate packet, and they can even get reordered).
TCP has flow control, so the sender (or the sender's OS) knows exactly how fast it should send data without overflowing the link or significantly affecting other connections. UDP doesn't do any of this – a poorly-"forced" program might start sending gigabytes of data per second over UDP, regardless of link speed.
TCP has retransmission, so if a packet is dropped in the middle (e.g. because the network is overloaded or has other problems) it will be resent. If the protocol depends on a reliable transport and you force it to go over UDP, the connection might die completely as soon as at least a single packet gets lost. (And packets will get lost; see points #1 and #2 above.)
Solution 2
As others have mentioned, UDP and TCP are fundamentally different protocols.
However, if you must transport data over UDP instead of TCP, you can use a relay tool such as socat. You can configure socat to listen for a TCP connection, and forward the contents of the TCP stream as a UDP stream to another host. If the other host is expecting TCP traffic, you can use another instance of the relay there to convert back to TCP. This will remove retry and ack behavior from the host-to-host link. Retries and acks will still be present between the local relay tool and the local application, but you're unlikely to see retries on a local loopback link.
However, this is unlikely to solve your delay problem. If your application is built to use TCP instead of UDP, it may not be tolerant of dropped packets, in which case this hack may cause unstable behavior.
Solution 3
Unless you're using really slow connections, your delay problem is most likely due to your video codec.
To efficiently compress video, you'll have to use predictive encodings (see this article on Wikipedia).
Predictive codings basically calculate images from earlier or later images. This has the following implications:
If you use many P-frames (calculated from earlier frames), you'll get a delay before the display of the video starts, because the client has to wait for the next full video frame (I-frame). However, once the stream is established, you can watch the video relatively lag-free.
If you use B-frames (calculated from earlier AND later images), you'll have some really big delay: Additionally to the inital delay from above, the client has to wait for the next I-frame to start playback from the last I-frame. This will introduce lag (client plays video noticeably later than server records/sends it, often many seconds). If you're encoding the video on the fly, you'll also have a delay from the server – it will need to wait for the next I-frame to send everything starting from the previous I-frame.
For most codecs, you can tweak the usage of B- and P-frames according to your needs, however, there is a trade-off delay vs. compression efficiency
If you have enough bandwidth, you could also use a codec without B-/P-frames, like MJPEG
Another reason for a delay would be buffering on the player side, so you don't have any distortions if there's a jittery network transmission. Many video players allow you to tweak the buffer sizes.
Related videos on Youtube
dempap
Updated on September 18, 2022Comments
-
dempap over 1 year
I 'm running an ffserver process on a Linux machine, in order to achieve video streaming via ffmpeg. However, there is a delay on video streaming. On ffserver configuration file I define
Port 8090
.Command netstat -tulnap gives me this:
root@beagleboard:/etc# netstat -tulnap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address Stat e PID/Program name tcp 0 0 0.0.0.0:68 0.0.0.0:* LIST EN 654/pump tcp 0 0 0.0.0.0:111 0.0.0.0:* LIST EN 662/portmap tcp 0 0 0.0.0.0:22 0.0.0.0:* LIST EN 698/dropbear tcp 0 0 0.0.0.0:8090 0.0.0.0:* LIST EN 744/ffserver tcp 0 52 192.168.1.104:22 192.168.1.111:10838 ESTA BLISHED 724/dropbear udp 0 0 0.0.0.0:514 0.0.0.0:* 703/syslog-ng udp 0 0 0.0.0.0:111 0.0.0.0:* 662/portmap udp 0 0 0.0.0.0:60628 0.0.0.0:* 709/avahi-daemon: r udp 0 0 0.0.0.0:5353 0.0.0.0:* 709/avahi-daemon: r
As you can see, ffserver process uses tcp protocol to transmit and I suspect that this is the reason of video streaming delay. How can I force process to make use or udp protocol? Should I change port?
-
ratchet freak about 10 yearstcp vs udp is a very different usage and not interchangeable
-
dempap about 10 yearsYou 're telling me there is no way acheiving transmission over UDP?
-
heavyd about 10 yearsThat is a change that needs to happen at the application level, you can't do it externally.
-
Josh about 10 yearsWhat you want is to tell FFMpeg to stream via Simple RTP, see also the "Point to point streaming" section. RTP can use UDP.
-
NothingsImpossible about 10 yearsThe question should have been titled "how to make ffmpeg stream over UDP"
-
sudo over 5 yearsYou can maybe tune your kernel's TCP parameters to make this work better over TCP, if your network is unusual and you know it really well.
-
-
Jordan Doyle about 10 yearsIs the connection dropped if the sender doesn't abide by the flow control?
-
Bakuriu about 10 years@JordanDoyle No. That will just make the connection slower because the receiver will have to drop the extra packets, which will then require retransmission.
-
Jordan Doyle about 10 years@Bakuriu ah thanks. Does anything happen if the sender doesn't abide?
-
Bakuriu about 10 years@JordanDoyle As I said, nothing special will happen except that more packets will be dropped and the connection will get slower and slower, because the sender will be filling all the link capacity. You are just increasing the traffic in the network uselessly and you might cause a congestion of the network.