I am trying to make a perfect mobile webcam fitting my needs with the RPI and camera module I have here already. I run Arch both on the RPI and on the Laptop I intend as the "client". I have the cam running and can pipe its data from raspivid somewhere, and I am able to ssh back and forth.

Now I am trying to get the transmission via the local network to work. Ideally, I would start the "server" script on the RPI and be able to connect as many clients as often as I want until I decide to close the server again. And, ideally, the delay from having a separate device and wireless transmission is almost unnoticeable so that I don't have to compensate and try to sync up video and audio. So from what I read, using VLC is out of the question. Also ideally, the "client" would make the stream available as /dev/video1 or whatever — though currently I just want to get it into OBS somehow.

Until now I tried to follow some tutorials particularly involving netcat, but the process stopped immediately or as soon as a disconnect happened, as I was unable to play the stream on the client.

Any hints on where to look or how to plan this? I thought about using something like a media server for that dynamic client (dis)connect thing, but it would need to be super lightweight.

1 Answer 1


If you want to stream video, use a protocol that's made for video streaming. Which means UDP and multicast, so you can connect as many clients as you like. Because with TCP and unicast, it will stop as soon as you disconnect, as you discovered.

Such protocols exists, e.g. RTSP, and server implementations exist, e.g. icecast. It's not "super lightweight", but should work fine on a RaspPi.

And no, you don't want to make the stream available as /dev/video1. Instead you should use a client that will properly connect to the multicast group, and then just will read the stream from the network.

I am not exactly sure what you read about VLC and why it is out of the question, but VLC (and most other videoplayers) as a client for an RTSP stream should work just fine, and shouldn't have trouble syncing up video and audio if the get streamed in sync (which could be a problem depending on how the hardware is connected to the RaspPi, but you didn't say anything about your audio source in the first place).


If you insist on minimalism, you can also use ffmpeg to stream in various ways, but you'll need to invest a bit of time to understand the protocols involved, their differences and the command line options you need for them.


Ok, I watched the video (at least the beginning with VLC and latency, I don't particularly like watching videos).

Of course there'll be a lot of latency if you use any decent encoding method - it will need quite a few frames to efficiently encode (and then it will need the same number of frames to decode). On top of that, it'll buffer a lot to ensure nothing gets lost.

Just for fun, I tried ffmpeg with RTP on a multicast group, and I also got a lot of latency (on the order of 1-2 seconds with a H264, with the extra latency ffplay adds). Reducing latency is a science in itself, and will need a lot of fiddling with options (and reading up about them). But having latency is not a sign that something is wrong, on the contrary.

So if you have an absolute low-latency requirement, you need to trade off the compression, image size, quality of encoding, and bandwidth. If nothing else helps, remove the encoding step.

  • In particular, I saw this video. Since VLC and gstreamer didn't achieve good latency, I did go straight for netcat. Audio will not come from the RPI but from an audio interface connected directly to the laptop, so it is out of scope of this thread. Commented Sep 12, 2018 at 8:04
  • I had a look at icecast, but I'm kind of stuck at configuring the mount. From what I got by now I cannot just assign a file or pipe to stream when a client connect, but I need a streaming client that somehow picks up some data and hands it to the server. Alright, that's an architectural decision unfortunate for my case (and it will probably raise the latency considerably), but I only came across ices0, ices2 and other audio stream solutions... Commented Sep 12, 2018 at 8:20
  • [having noticed and read the edit] Yeah, in the meantime I had a closer look at ffmpeg as well. It did work, udp was horrible (totally expected, especially without any tweaking) but tcp was better (though weirdly at little below 6 fps transmission while capure and everything was fine at 30 — both regardless of image dimensions :/ ) Commented Sep 14, 2018 at 21:13
  • I am not exactly knowledgable nor experienced with this, but I would guess that choosing a faster but less compressing encoding is not really a problem for me, since I don't intend to send the video over the internet but just a few meters using wifi, and if that turns out too slow directly via an ethernet cable. Commented Sep 14, 2018 at 21:20
  • I want to go as low latency as possible because I don't want to have the cam terribly out of sync but I definitely don't want to have a huge additional buffer holding back the rest data before it can be "merged" with the cam, since I want to do some realtime audio computing that already challenges my laptop on its own. Commented Sep 14, 2018 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .