Streaming local Webcam in a Linux machine, and acessing it when on vacations - which protocol to choose?
I want to configure a local webcam to stream (and possibly record) a live feed open to the internet, and acess it half-world away while traveling, using FOSS only acessing it via Android VLC
This guide was quite comprehensive; however the packages for nginx-rtmp are quite abandoned in arch linux. So I thought maybe WebRTC could be an alternative - the communication itself should be encrypted, which WebRTC seems to do; however, I still can't figure out if VLC will handle this well
Also, it seems that I might need to self-host a VPN to achieve this?
What are my options? Has anyone else done this ?
I recently set up a personal Owncast instance on my home server, it should do what you're looking for. I use OBS Studio to stream random stuff to friends, if your webcam can send RTMP streams it should be able to stream to Owncast without OBS in the middle - else, you just need to set up OBS to capture from the camera and stream to Owncast over RTMP.
the communication itself should be encrypted
I suggest having the camera/OBS and Owncast on the same local network as RTMP is unencrypted and could possibly be intercepted between the source and the Owncast server, so make sure it happens over a reasonably "trusted" network. From there, my reverse proxy (apache) serves the owncast instance to the Internet over HTTPS (using let's encrypt or self-signed certs), so it is encrypted between the server and clients. You can watch the stream from any web browser, or use another player such as VLC pointing to the correct stream address [1]
it seems that I might need to self-host a VPN to achieve this
Owncast itself offers no authentication mechanism to watch the stream, so if you expose this to the internet directly and don't want it public, you'd have to implement authentication at the reverse proxy level (HTTP Basic auth), or as you said you may set up a VPN server (I use wireguard) on the same machine as the Owncast instance and only expose the instance to the VPN network range (with the VPN providing the authentication layer). If you go for a VPN between your phone and owncast server, there's also no real need to setup HTTPS at the reverseproxy level (as the VPN already provides encryption)
Of course you should also forward the correct ports (VPN or HTTPS) from your home/ISP router to the server on your LAN.
Thank you, I managed to get it working with MediaMTX and DockoVPN
I still don't know how I would manage dynamic IP changes during the days I'm away, that would break the VPN
For the dynamic ip address that you can get a free domain name from afraid or noip or maybe others and point your vpn to your domain name instead of direct ip address. Following that you can run cron job scripts to ensure the ip address that the domain points to is up to date
I'm using Frigate with a Google Coral connected to Home Assistant, it'd send an image and a short video to a Telegram group with my wife whenever it detects a person.
I'm using OpenIPC firmware flashed on a chinese Goke camera and works great. It connects to Frigate using RTMP.
That's true, they could. So could the devs of Wireguard. I see zero implication that either will.
Worry is interest paid on a debt you don't have.
TS already has a paid tier, so I don't see it as likely. And if they do change in someway, I can either move to paid or move to WG then, if needed.
Plus it's much easier to setup and manage, and has some neat features like Funnel. It's as easy as running an installer on the machines, and creating an account.
Last I checked (perhaps a year ago) Wireguard still required a bit of manual effort to connect machines to each other (generating/sharing keys, updating each machine config, etc), while Tailscale handles that by using an account which manages key distribution.
You can self-host TS to not be dependent on their servers for the account management. That doesn't sound like developers that are going to "pull the rug".
It's interesting, I see TS doing a lot of stuff Hamachi did 20 years ago, with having relay capability if ports can't be forwarded/opened via UPNP, or you're on a firewalled network. I'm a bit surprised it took this long, Hamachi was great in the early 2000's.
I don't see them going away, they've really developed. I'll be moving to a paid tier when I rebuild my network and lab, not that I need to, but it'll be nice to have support, and I'll be contributing to a tool that I've missed for years in Hamachi.
I'd go for HLS due to its simplicity: just files over http(s). VPN or not - depends on your network. If your machine is accessible from the internet, just putting the files into a webserver subdirectory with a long random path and using https will be secure enough for the usecase. Can be done with an ffmpeg oneliner.
The downside of HLS is the lag (practically -- 10s or more, maybe 5 if you squeeze it hard). It is in no way realtime. Webrtc does it better (and other things too), but it is also a bigger pain to set up and forward.
Also, just in case, test that the webcam works fine if left active 24/7. I had (a cheapo) one that required a powercycle after a week or so...
My use case is similar. So i use a Pi 5 running motioneye dev 64bit.
3 cams 2 usb webcams (uvc compliant) 1 esp32 cam wifi.
Another Pi a 4 this time runs pihole and wireguard vpn. Static ip so all is good.
Homarr is my dashboard and i can view from that or the motioneye interface directly.