I’m no fan of cloud.

Well, that implies I don’t like The Cloud. That’s not true. I don’t like the hype surrounding The Cloud; and in particular the obsession with AWS. What I do like is using the right tool for the job, and in some cases that is indeed The Cloud.

The thing is, it just isn’t. The right tool that is. And I would argue so in nearly all cases.

Once upon a time, it made sense. Why spend money (capex) on hardware based on your peak demand when it would sit idle 95% of the time? If you rented shared hardware (for a small premium) you could scale up just when you needed to, and end up better off.

Except that it’s 15 years later and you now need to commit and prepay 3 years up front to achieve reasonable pricing. That sounds an awful lot like capex to me. And that small premium for flexibility hasn’t gone away.

Now rinse and repeat that mindset for every layer of the stack from network to application, every service, database row, ingress and egress byte, etc. and you really have to wonder how this came to be?!

Furthermore, it’s so complex and with so many deliberately crafted tricks to lock-in and price gouge that there are a complex web of professions dedicated to make sense of it all. Now wasn’t one of the other arguments in favour of The Cloud that you didn’t need all these technical skills and staff? Hmm.

Now… cloud-like technology? Sure! Virtualisation, Containerisation, Orchestration, Automation, etc. all make a ton of sense both in terms of architectural flexibility and operational fluidity.

And here’s the thing. You can do all that pretty easily yourself on any hardware – owned or leased – as you like. In turns out you don’t need to pay a handsome fee to someone like Amazon to do pretty simple stuff.

But why take my word for it? David Hansson probably said it better…

https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0

So, with remote working and hybrid teaming currently upsetting the status-quo, there are some new technical challenges presenting themselves.

It was all so easy when people were in the office. They went into a meeting room equipped with a big screen, a decent PTZ webcam, and maybe an audio setup on the table. When they were all hiding at home from the (other) Big C it was also pretty easy: everybody had a webcam they begrudgingly enabled and meetings proceeded.

But what to do when things go hybrid? How do you facilitate all-hands meetings in an office when some proportion of staff are remote? Camera setups in all-hands situations get weird.

There are off-the-shelf solutions for this, but they are eye-wateringly expensive. Cameras (especially PTZ) run into the thousands, and they’re still pretty poor. And then… how to connect them?! USB? A dedicated machine? Where do we power it from, particularly in an open-plan office? Hmm.

It turns out there are some outstanding 4K cameras out there. They’re called security cameras. They are neat, unobtrusive and easily powered and connected with PoE over large distances that would make USB or HDMI sweat. Oh, and they cost under £200.

The catch? They aren’t webcams, and so all our favourite conferencing software doesn’t know how to use them.

There is of course off-the-shelf software for this. The options are typically Windows-bound, apparently of questionable quality and reliability, and costs at least hundreds of pounds in licenses. That’s an OK starting point, but can we do better? Is it really that hard to bridge an RTSP stream into Teams?

Nope!

So, here’s the four step plan to open-source success.

1. Provision a Linux desktop machine (virtual or physical). All you need is RDP to be honest.
2. Install V4L2 (Video 4 Linux) and FFmpeg.
3. Configure however many virtual video devices you require.
4. Run ffmpeg to stream each source (RTSP in this case) to each virtual video device.

Then just use those video devices as they are in Teams.

The commands?

# for Debian
sudo apt-get install v4l2loopback-dkms v4l2loopback-utils ffmpeg;
sudo modprobe v4l2loopback devices=2 video_nr=1,2 card_label="camera1","camera2";
sudo ffmpeg -re -rtsp_transport tcp -i rtsp://camera1:554/s0 -pix_fmt yuv420p -f v4l2 -vcodec rawvideo -vf scale=1280:720 /dev/video1 &
sudo ffmpeg -re -rtsp_transport tcp -i rtsp://camera2:554/s0 -pix_fmt yuv420p -f v4l2 -vcodec rawvideo -vf scale=1280:720 /dev/video2 &

If you’re wondering about the “-vf scale=1280:720”, that’s because (for Teams at least) it refuses to use the camera above that resolution. No, I don’t know why?!

The end result though: superb! RDP onto the machine to log into a Teams call (or any other provider that supports Linux or web-based calling) and enjoy seamless use of IP cameras as webcams.

I have CCTV deployed, including a couple of cameras internally. Occasionally I want to listen in to the kids while I’m outside, so the mobile app viewing a camera feed provides a handy facsimile of a baby monitor.

The thing is, I don’t want the video. I don’t need the video. I don’t want the bandwidth consumption of the (up to 4K) video. What I do want is the audio, only.

The cameras all output RTSP streams (which is how they bind to the NVR), so there must be a way.

Cue VLC running on a small VM.

It’s actually fairly simple (save for trial and error figuring out variations of codec that are properly supported for streaming on all devices and browsers). But, to save anybody else the hassle…

VLC

vlc ${rtsp_url_of_camera} --sout-keep --sout '#transcode{acodec=mp3,ab=128}:std{mux=mpeg1,access=http,mux=ogg,dst=:8080/camera.mp3},select="novideo"}' &

HTML

<!DOCTYPE html>
<html>
<body>

<audio controls autoplay src="http://vlc_machine:8080/camera.mp3" type="audio/mp3">
Your browser does not support the audio element.
</audio>

</body>
</html>

Navigate to that HTML page (or run it from localhost, etc.) and you get a low-bandwidth audio-only stream.