user21908: 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?

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

21908: <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>
 21908: <p>Try using UDP. It should be faster than TCP but with possibility of losing paackets.</p>
