I've been using this between Chrome and my phone:


And the latency is really good - less than 1 second.

I've been trying to replicate that on my computer with no success.

ffmpeg -f video4linux2 -i /dev/video0  -s 320x200 -r 50 -deadline realtime -vcodec libvpx -f webm -fflags nobuffer udp://

And then using ffplay on the other side.

It's still got a couple of seconds of lag to it.

Eventually I'd like to stream from my computer to the Android phone, but the latency has got to be good.

Edit - this works significantly better. If I could shave just a bit off of this, I'd be happy:

ffmpeg -vcodec rawvideo -f video4linux2 -i /dev/video0  -s 320x200 -r 25 -vcodec libvpx -f rtp -deadline realtime rtp://
  • 1
    The link is dead. Basically you want to convert video and stream it to your phone? On wifi or external? – jiggunjer May 22 '15 at 20:26
  • What I want to do is stream from a camera attached to a device and have it show up on an Android tablet (Nexus 10) that is connected via USB. – David N. Welton May 26 '15 at 11:52
  • 1
    I don't know much about these codecs but have you checked that they are hardware accelerated where possible? That would be my guess as to why you see more than 1 second latency. – snoopen May 29 '15 at 5:57
  • vpx is going to be tricky to close to realtime, I know x264 has a tune "low latency" or something like that FWIW – rogerdpack Nov 4 '17 at 21:30

The problem is mostly from the fact that you are using software transcoding, instead of hardware transcoding.

As a rule of thumb, if the conversion uses the hardware acceleration, the latency will be of less-than-a-second order (usually milliseconds). If it is done in software, then the latency will be of more-than-a-second order.

FFmpeg supports hardware acceleration, but it is usually tricky to make it work for you.


On the other hand, Google Chrome supports VP8 and H264 (where it is available) hardware encoding/decoding, both on your computer and your Android phone:


  • 1
    It's not just about hardware acceleration though... codec configuration plays a much larger part in the latency. The codec needs to be tuned to keep the latency low, at the expense of quality and bandwidth. This can be done whether you're using hardware accelerated codecs or not. – Brad May 23 '17 at 17:24
  • That link specifically says Chrome does NOT support hardware encoding on desktop, ONLY on android. – davr Mar 18 at 21:37
  • Sorry but Brad is right, the answer is totally wrong: as long as you set the same codec settings, there is no difference at all if you do hardware or software encoding (as long as you have enough CPU power to do realtime encoding with your codec settings). Correct is that it is not only about video codec settings but mostly about the type of transport and buffering behaviour of the decoder. WebRTC works because it is tuned for low-latency. Typical Webm decoder is not intended to do Low-Latency – Harry Jul 19 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.