<p>Try using UDP. It should be faster than TCP but with possibility of losing paackets.</p>

CC BY-SA 3.0
2018-04-23T16:33:25.180Z
2018-04-23T16:33:25.180Z
user10024395
<p>Sources of any delays:</p>

<ol>
<li>TCP protocol. Long handshake, possible error with time loss in future</li>
<li>Long encoder initialization (video call already prepared it)</li>
<li>Long decoder initialization (video call already prepared it), buffering for analyze data</li>
<li>Unoptimized protocol / format for low-time communication, like MKV</li>
<li>Prebuffering in encoder for B-frames and other optimizations</li>
</ol>

<p>Video conferencing software also have many tricks to detect delays and resync streams. It why in video conferencing has frame drops and it not suitable for transmitting high quality video.</p>

CC BY-SA 3.0
2018-04-23T23:59:49.970Z
2018-04-23T23:59:49.970Z
bukkojot
<p>Why video call has no (even if there is, it is lower than human perception can discern) latency,  but no matter what options of ffmpeg I tried to transmit video to a remote server, the lowest I can get is ~0.2s latency (estimated, not sure how to profile)? </p>

<p><strong><em>What is the technology behind video call that allows it to be much faster than ffmpeg?</em></strong></p>

<p>I tried sending to the server and make the server send back the stream using the following commands:</p>

<p>CLIENT:</p>

<p>termimal 1-</p>

<pre><code>ffmpeg -pixel_format mjpeg -s hd720 -r 30 -i /dev/video1 -c libx264 -preset ultrafast -tune zerolatency -crf 18 -b 5M -f matroska -vf hflip tcp://X:5000
</code></pre>

<p>termimal 2-</p>

<pre><code>mplayer -benchmark ffmpeg://tcp://Y:5000?listen
</code></pre>

<p>SERVER:</p>

<pre><code>ffmpeg -i tcp://X:5000 -c copy -f matroska tcp://Y:5000
</code></pre>

<p>However, the video I got back has a slight delay of about 0.5s (estimated, not sure how to profile). Is sending to and fro different that causes it to have longer delay?</p>

CC BY-SA 3.0
2018-04-17T12:37:15.717Z
Try skipping format probe in server cmd: `ffmpeg -f matroska -i tcp://X:5000 -c copy -f matroska tcp://Y:5000`
Gyan
CC BY-SA 3.0
2018-04-17T12:56:22.637Z
What software is your video call made with, and who are you calling? Recipient on server X, I assume?
Tony Sepia
CC BY-SA 3.0
2018-04-17T16:01:50.757Z
@Gyan same latency
user10024395
CC BY-SA 3.0
2018-04-17T16:02:03.210Z
@TonySepia facetime between mac
user10024395
CC BY-SA 3.0
2018-04-17T16:04:36.217Z
Have you looked at using RTP with ffmpeg? FaceTIme appears to use it. Check here: https://en.wikipedia.org/wiki/FaceTime
Tony Sepia
CC BY-SA 3.0
2018-04-17T16:47:03.433Z
@TonySepia is tcp slower than rtp? isn't rtp also using tcp behind the scene?
user10024395
CC BY-SA 3.0
2018-04-17T21:34:19.580Z
@user136266 I would Google first, seriously! https://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp
Tony Sepia
CC BY-SA 3.0
2018-04-21T20:38:42.427Z
It should be noted that UDP is not actually a requirement for low-latency streams. For example, the NDI protocol from Newtek is based on TCP and it is able to transmit 1080p60 video over a local network with less than a frame of latency
mcont
<video><ffmpeg><latency>
Why video call has no latency, but no matter what options of ffmpeg I tried to transmit video, the lowest I can get is ~0.2s latency?
user10024395
# Why video call has no latency, but no matter what options of ffmpeg I tried to transmit video, the lowest I can get is ~0.2s latency?

(Asked by: username_0 on 2018-04-13)

Why video call has no (even if there is, it is lower than human perception can discern) latency,  but no matter what options of ffmpeg I tried to transmit video to a remote server, the lowest I can get is ~0.2s latency (estimated, not sure how to profile)? 
What is the technology behind video call that allows it to be much faster than ffmpeg?
I tried sending to the server and make the server send back the stream using the following commands:
CLIENT:
termimal 1-
ffmpeg -pixel_format mjpeg -s hd720 -r 30 -i /dev/video1 -c libx264 -preset ultrafast -tune zerolatency -crf 18 -b 5M -f matroska -vf hflip tcp://X:5000

termimal 2-
mplayer -benchmark ffmpeg://tcp://Y:5000?listen

SERVER:
ffmpeg -i tcp://X:5000 -c copy -f matroska tcp://Y:5000

However, the video I got back has a slight delay of about 0.5s (estimated, not sure how to profile). Is sending to and fro different that causes it to have longer delay?

**Tags:** video, ffmpeg, latency

> **Comments:**
> **username_1**: Try skipping format probe in server cmd: `ffmpeg -f matroska -i tcp://X:5000 -c copy -f matroska tcp://Y:5000`  
> **username_2**: What software is your video call made with, and who are you calling? Recipient on server X, I assume?  
> **username_0**: @username_1 same latency  
> **username_0**: @TonySepia facetime between mac  
> **username_2**: Have you looked at using RTP with ffmpeg? FaceTIme appears to use it. Check here: https://en.wikipedia.org/wiki/FaceTime  
> **username_0**: @TonySepia is tcp slower than rtp? isn't rtp also using tcp behind the scene?  
> **username_2**: @user136266 I would Google first, seriously! https://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp  
> **username_3**: It should be noted that UDP is not actually a requirement for low-latency streams. For example, the NDI protocol from Newtek is based on TCP and it is able to transmit 1080p60 video over a local network with less than a frame of latency  

---

## 2 answers

### Answer by username_0 on 2018-04-23. Score: 1 | Accepted answer

Try using UDP. It should be faster than TCP but with possibility of losing paackets.


---

### Answer by username_4 on 2018-04-23. Score: 0

Sources of any delays:

1. TCP protocol. Long handshake, possible error with time loss in future
2. Long encoder initialization (video call already prepared it)
3. Long decoder initialization (video call already prepared it), buffering for analyze data
4. Unoptimized protocol / format for low-time communication, like MKV
5. Prebuffering in encoder for B-frames and other optimizations

Video conferencing software also have many tricks to detect delays and resync streams. It why in video conferencing has frame drops and it not suitable for transmitting high quality video.


---

