A Raspberry Pi 4 Video Streaming Backpack

Were you aware that there’s a market for backpack-housed live streaming video systems, and that they can cost as much as $1600? Apparently these things are popular with social media moguls who want to stream themselves living their fabulous lives to people sitting at home watching on YouTube or Twitch. But believing that even slack jawed yokels like us should have access to the same technology, [Speedify Labs] has been working on less expensive DIY alternative based on the Raspberry Pi 4.

Now you’ll note we didn’t use the term “cheap” to describe this build. As detailed here, it’s still going to cost you around $600. You could always swap out the Sony AS-300 camera and Elgato Cam Link capture device with cheaper versions, but the goal of this project was to deliver high quality HD video that’s comparable to what the professional rigs are capable of, so those kinds of concessions were avoided.

Whatever video source your audience and budget are comfortable with, it eventually gets fed into the Raspberry Pi 4 which uses an ffmpeg one-liner to encode the video and ultimately push it out as 720p at 24 FPS, which [Speedify Labs] says seems to be about as good as the Pi can do. The operator is able to start and stop the stream at will using a Circuit Playground Express and a Python script.

Of course, the trick to all of this is getting the video stream uploaded over potentially flaky mobile networks. But as you might have guessed, that’s where [Speedify Labs] gets to flex their eponymous product: a VPN with software channel bonding that allows you to combine multiple Internet connections for higher bandwidth and reliability. With their software, the Pi is able to stream the video through two mobile phones connected to it over USB. As demonstrated in the video below, the setup was able to maintain the stream even as they walked in and out of buildings.

Our very own [Lewin Day] wrote about his experiments with streaming video over 4G on the Raspberry Pi which might be of interest to anyone looking to take their show on the road. Though if you want to get serious it would be worth taking a look at the impressive mobile streaming rig that [Jenny List] saw at the BornHack 2019 hacker camp in Denmark.

33 thoughts on “A Raspberry Pi 4 Video Streaming Backpack

  1. wait, you do all of this, and then you still connect 2 ! smartphones to it ? each phone on its own is probably more powerfull than the pi, has a camera build in and if it is a dual sim phone, can handle 2 networks. just use one good phone and carry a backpack of powerbanks…

    1. The cameras in even expensive phones will be inferior to even a (recent) POS camera, let alone a DSLR. there’s basic physics which is difficult to overcome (though the iPhone 11 is trying!).
      But yes, your comments on the pi vs phones are spot on. The phones also likely have dedicated hardware to compress the video stream, which would probably give a better quality / bitrate ratio.

      1. of course you can get better cameras, but in this case the pi output is just 720p. even if the camera was better, the advantage would be lost in the end. also you might be able to hook up the better camera to the phone too. but in the end, who cares. it’s not like this footage will end up on the big screen. most of the stuff people stream will be watched by kids on other their phones. also the (android) phone basically runs linux, if there is not already an optimized all-in-one streaming app, you can even run ffmpeg on the (rooted) phone itself, if there is no dedicated hardware.

        1. You still loose out starting with inferior cameras. Compressing a good image will give a much better result than streaming at native pixel counts. And no amount of pixels in the phone cameras can make up for the small ccd (which means poorer low light) or the small fixed lens that doesn’t let you set up the shot angles you want.

          As for Pi vs Phone, the gpu on the pi is much the same as on many phones, so with the right hardware accelerated compression is should be around as good. Though I can’t see the point in using a pi and phones – just put mobile modems on the Pi or use the phones.. No need to have two computers working on one computer task in the way where if either fail the whole thing fails..

          1. The redundancy in phones is independent of the main computer. While the R Pi is a single point of failure, in the field, losing a network connection is far more common, so having phones that are on different networks is a huge advantage. This is how LiveU works, but it uses four cell modems instead of two, to connect to up to four data networks simultaneously. I imagine this project as built would work just as well with four phones (or four cell modems) as with two, so upgrading is trivial. It also can be upgraded to 5G, 6G, or 7G, similarly. I personally would use mobile modems instead of phones (i.e., USB-connected modems), since phones connect through WiFi, which can be a problem if you’re in an area where the WiFi bands are heavily used.

        2. Believe it or not, 720p is still a pretty common standard for streaming video. Especially for systems like this. You don’t want to be trying to push 1080p, and forget 4k down a system like this. Reliability is generally more important than anything for many of the uses of a backpack like this. You don’t want your stream drop out because of some network congestion.

          1. As someone who hacked something up similar to this with a Pi3 and a repurposed HDMI extender (search LKV373 I think… The “new” version of this spit out H.264 over UDP), I fully agree.

            Bitrate limits meant I often had to run 540p or less, but 540p downscaled from a GOOD camera is still vastly superior in low-light to almost any smartphone video in similar light.

            The Pi4’s USB3 means that you can feasibly use an Elgato Camlink instead of the Lenkeng hack. (Pi3 still had to transcode the video to a lower bitrate…)

          2. I have made similar setup and with 1080p and 720 p – https://www.undergroundnews.dk/index.php/item/98-praktisk-mini-live-streaming-setup (page is in danish) but will try to replace rtmp with SRT also I used the OMX -enable-omx –enable-omx-rpi with h264_omx from ffmpeg.

            I have not made any nice GUI – I just used vnc on my phone to connect to rpi4 on a shared internet (shared on the same phone) and via the browser in the rpi started a stream on facebook and and youtube – the i executed the ffmpeg.

            But I need a fan to cool the rpi – anyway I will try to use SRT later.

        3. “Better cameras” doesn’t just mean resolution. There are better lenses, there are more sensitive sensors, there is better audio, and much more. Cell phone cameras are just crap. They love selling people on the camera resolution, because to most people, that’s about their limit when it comes to camera knowledge, and it’s really easy to up the resolution on a camera, at the cost of many other important factors.

          1. Burst image stacking (see Google’s HDR+ paper from 2016) has narrowed the gap for stills significantly (which is why the perception of smartphone cameras as crap has lessened), but that can’t be applied to video.

            Also the gap widens again if you burst-stack a larger-sensored camera, a la Tim Brooks’ work.

    2. The big advantage of the two phones is the bonding, that allows the system to use the two connections like one, faster connection. If one provider drops out for a reason, then there is still one connection available. Believe it or not, there is more to it than plugging in two phones. also, i would imagine a couple of wireless modem dongles would also work for this purpose, would be cheaper and may have options for external antennas.
      Plus, having the option of a HDMI input into the system, you aren’t limited to just one camera. I’m sure you can think of things like having a low powered vision switcher change between several cameras or other input devices.

  2. I have been playing around with the idea of making a streaming backpack myself. I was looking into going with a nvidia jetson nano with a B101 HDMI to CSI-2 bridge for hdmi input. That should hopefully be powerful enough to encode 1080p 30fps in x265. Then connect a few modems to it and have it stream to my computer at home, and there decode it, add some overlays etc, then stream it to twitch/youtube/mixer etc. That way you will get the best quality for the bandwidth.

  3. >720p at 24 FPS, which [Speedify Labs] says seems to be about as good as the Pi can do
    >vcodec libx264

    why not “vcodec h264_omx”? will use hardware encoder at minimal cpu usage and no heat

  4. A couple of important facts left out of the article:
    1) Fully HALF of that $600 is the camera, and LiveU doesn’t include a camera. So “cheap” WOULD have been a good description.
    2) The bonding of multiple cellular connections is managed by routing the signal through Speedify’s VPN, which is a subscription service. Without this, or if Speedify were to suddenly drop support, you’d be out of luck, at least as far as the bonded connections go.

    1. Its possible just to record the data from the camera – only maybe a ssd solution and if you have a old videocam with tape it only then its nice solution. On a real video cam you also have XLR for audio input that you dont have on a phone. You can compare the solution with a Terradek Vidiu but you can improve it with other protocols like SRT or maybe UDP streamning maybe NDI – you don have any good zoom on must mobile cams so it usefull to play with rpi or simular solutions for portable streamning – you don’t need speedyfi other solutions exist.

  5. Hello,

    I would like to use same config : Raspberry Pi 4 + CAM LINK.
    ffmpeg send me an error message :Cannot find a proper format for codec ‘h264’ (id 27), pixel format ‘none’ (id -1)

    Could you help me ?

    Thank you !

Leave a Reply to mathmanCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.