Hacker News Reader

Comment by lostapathy | Hacker News Reader

It amazes me, really, that for as popular as this use case seems to be there isn't a simple, well-packaged way to stream a camera off a pi.

I've been trying to get this working lately and nothing works "well". Motion is popular, but is limited to mjpeg rather than h.264. uv4l is closed source and not up to date with current OS versions. None of the various cvlc incantations to do better actually seem to work on my pi zero w, etc.

View on HN

I’d like to plug my project, APStreamline for just this use case (https://github.com/shortstheory/APStreamline). It supports network adaptive streaming which adjusts the resolution and bitrate of the H264 video streamed from the Pi camera depending on the quality of your network connection. You can then use an RTSP player such as VLC to view the video stream. It works great with other types of cameras too!

Took a look at your GitHub link, looks like you put in quite a lot of work.

Looks very interesting.

When you say "works great with other types of cameras", could you explain? You've tested with other cameras and could you tell us which?

Thank you! The list of cameras for which I have added special support are:

* Logitech C920

* Raspberry Pi Camera

* e-Con AR0521

* ZED2 Depth camera (in V4L2 mode)

In case your camera is not one of the above, APStreamline falls back to requesting an MJPG stream from the camera and then encoding it to H264 that using the x264enc software encoder. The software encoder has good quality but it requires more CPU power.

Can this stream h264 directly from a Logitech C920 rather than decoding then encoding?

Yes! This uses the H264 stream encoded by the C920 so you will be able to get an HD stream even on low powered devices such as the Raspberry Pi.

Thanks for the in-depth reply.

Is there some process you setup on Github for others if we test with our own cameras and let you know?

A pull request?

Yeah wasn't sure if they had a process to it outside of pull requests. As in some other channel or method for hardware. But you're right, pull requests it is they said.

Yes, the way to test your own camera is to connect it to your computer and launch APStreamline. As the sibling comment suggested, feel free to add a GitHub issue if you want your camera to be supported. In case you want to DIY support for your camera, the steps here https://arnavdhamija.com/2020/10/29/apstreamline-v2/ have an outline of what to do.

Will do thank you

This is sadly 'just' homekit, but I was pretty impressed with the polish of the solution:

https://hochgatterer.me/hkcam/

I agree on the comment for rtsp though. Most solutions have multiple seconds of latency which is a bit suboptional.

This is really nice.

> I've been trying to get this working lately and nothing works "well". Motion is popular, but is limited to mjpeg rather than h.264. uv4l is closed source and not up to date with current OS versions. None of the various cvlc incantations to do better actually seem to work on my pi zero w, etc.

Since you use motion, I suppose you want to have some kind of detection going on.

I was toying with 2 pi0+cam and one pi4 some weeks ago.

Here's my conclusion (I should write a blog post about it):

- use a pi0+camera dedicated to live streaming ; that's the one you want to connect to to see what's going on (fixed IP, RTSP stream)

- use another pi0+camera or add an IR sensor to the first pi0, in the same spot, to detect motion events (either through motion installed on the pi or the IR sensor)

- use a third connected pi4 for continuous recording of the live stream (in chunks of 5 minutes) to HDD/SSD and/or recording of the live feed once a motion is triggered (you can use motion hooks to trigger API on this pi from the pi0)

- you could also simply do motion detection on the pi4 but you are at the mercy of artifacts in the stream and they WILL trigger motion detection ; that's why you want to do motion detection closest to the source

Motion introduces too much latency to use as a two-ine-one "detect and live stream" (MJPEG conversion takes a lot of CPU clock and adds artifacts).

Most motionEyeOS tutorials I read are PoC that makes you install motionEyeOS on every pi and use the motion MJPEG stream instead of an h264 feed from the camera. It also introduces a lot of CPU bottlenecks and unreliable network connectivity.

I found that motion web UI is now enough for live streaming of what motion "sees" but motionEyeOS helps understanding many of motion options. It's especially useful to draw masks. And then you move on to building your own infrastructure with those bricks (http API, live streaming, hl264 streaming, etc.).

It seem this setup get close to the Jetson Nano 2Gb price range ($59), which from my experience is order of magnitude faster than rpi 4 for computer vision/video processing tasks. Is there any advantage of using Motion over nvidia-deepstream?

I don't know much about nvidia-deepstream. Motion is a stand alone and ready to use program that can take multiple streams, detect frame to frame differences with different settings. Nvidia-deepstream seems to be an SDK that requires more specific AI/ML knowledge to set up motion detection.

Check out rpos (https://github.com/BreeeZe/rpos), it turns your Pi into a compliant enough Onvif camera that you can use for NVRs.

Both rpos and piipcam serve h.264 RTSP streams that you can pull into OBS and turn into a virtual webcam.

I ended up running

  raspivid -l -o tcp://0.0.0.0:3333 --mode 2 -b 3000000 -t 0 --drc off --flush

looped in a screen session on the rpi (running raspbian), and

  mpv --profile=low-latency tcp://192.168.1.100:3333/

on the client whenever I wanted to see the camera. It wasn't polished, but it got the job done. It died probably due to SD card flakiness, and then I had to move the camera anyway. Next incarnation will be nfsroot.

Gstreamer? I've used it in the past, both professionally and personally, to generate rtsp/rtp and it worked great.

I second this, using gst-launch, you can run a gstreamer pipeline in one line in the terminal that generates a hardware h264-encoded stream that you can tune to any bitrate. Something like this:

  gst-launch-1.0 rtpbin name=rtpbin rpicamsrc preview=0 bitrate=4000000 do-timestamp=1 ! 'video/x-h264, width=1920, height=1080, framerate=30/1,profile=high' ! h264parse ! rtph264pay config-interval=1 pt=96 ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink host=YOUR_IP port=YOUR_PORT rtpbin.send_rtcp_src_0 sync=false async=false

Gstreamer should include rpicamsrc directly nowadays for your convenience.

This is the comment I was scrolling for. GStreamer is awesome.

I'd be love to hear more about how you did it! I found streaming (and restreaming) RTP fairly straightforward but annoying to setup with gst-launch (there seems to be no simple option to get an SDP file out, apparently you are meant to lovingly handcraft one from the debug log).

But I couldn't figure out how to stream RTSP, especially not in a way that would preserve NTP timestamp information when restreaming (for synchronization with other streams). There is gst-rtsp-server, but as far as I can tell the idea is that you use it as a library to build your own custom server code.

Is there a simple way I was missing?

Same, have been looking for a slightly different use case: Using RPi as a video capture card that takes an HDMI input and outputs H.264. Even better would have been to implement it as a UVC device that can be plugged in as a video source.

I was surprised that gamers haven't implemented this yet as a DIY Elgato project.

There are several entire companies whose core product is a security camera that cannot get a security camera to work "well". At least 50% of it is making the user experience smooth and loading times extremely low. You would think that the product managers are responsible for this would take responsibility for it and make sure it works perfectly. However, there are very few great product managers out there. Most of them fail miserably and end up giving even the good product managers a bad reputation. At the end of the day, the guy who wrote this could possibly be just a single poor plonker in his mom's basement who never stood a chance against the most discriminating of users like us.

RPi Cam is very good: https://elinux.org/RPi-Cam-Web-Interface

But it only works with the pi webcam, not with usb cameras

It's not that "well-packaged" but last time I tried it, JSMpeg worked nicely when streaming from an RPi3. It has very low latency (~70ms), reasonable quality/bitrate (MPEG1, rather than MJPEG) and is viewable in any browser.

https://github.com/phoboslab/jsmpeg#example-setup-for-stream...

Is it that there is no way to “just” run a small custom built daemon script on a Linux box, not just in terms of camera apps but in general?

Like I have this 10 line bash script, that I want it to run for a few years, with no maintenance, that don’t get corrupted from power loss, or lock up from memory leaks, that auto restarts when necessary, but not bring down network either.

And it requires 10+ years of experience in managing and developing on GNU/Linux, a few notable certificates maybe, a bit of embedded background being a plus, to do it right enough, in about 0.25-1.0 man-month.

I’ve tried something like that on Alpine Linux, and it didn’t work always. Mostly due to proficiency issues on me, but it definitely was unnecessarily hard.

There are fancier modern things but https://cr.yp.to/daemontools.html still works great for keeping a simple script running.

If I had to do that, I'd go for a read-only rootfs (which IIRC the latest raspbian/raspi-config version supports to set up for you) combined with a systemd unit file that takes care of auto restarts.

The only thing I don't know how to deal with is a memory leak but as long as it's an easy simple script and no Java app, there should not be anything running that could leak memory.

Something like that ?

    [Unit]
    Description=auto start script
    After=multi-user.target
    [Service]
    Type=simple
    ExecStart=/home/pi/script.sh
    User=pi
    WorkingDirectory=/home/pi
    Restart=on-failure
    [Install]
    WantedBy=multi-user.target

There's a significant amount of parts to put together, software wise, but you can build a strong streaming solution with gstreamer or ffmpeg. I've done so and shipped hundreds of devices. It was not a trivial amount of work. We eventually transitioned to a purpose built dedicated camera solution however. If you're capturing sound, you will also have challenges as the BCM2xxx family has..... interesting audio hardware, especially if you want to reduce your BOM and integrate PDM microphones.

Can ffmpeg work? I've used it with IP cameras before with much success.

MotionEyeOS consistently crashes for me on raspberry pi zeroes. It's just not stable enough. I suppose it's the transcoding to mjpeg that's too heavy. But I'll try some of the alternatives mentioned here.

> limited to mjpeg rather than h.264

In fact I had a hope it can stream h.265 to save bandwidth. I've heard it was supposed to have hardware h.265 encoding.

The hardware supports h.265 decode but not encode.

What about Raspberry Pi 4?

I should have been more specific: the 4 supports h.265 decode but not encode, none of the other Pi hardware has either.

https://github.com/BreeeZe/rpos

Just wait until you try to include audio in the stream...

Reply on news.ycombinator.com