51–60 of 86 posts
I have used this https://github.com/jacksonliam/mjpg-streamer for a number of years to great success. However a word of warning: Wifi streaming video can really degrade your wifi for other devices. especially if the streaming device is at the edge of the range of the wifi. Ethernet streaming is really the way forward.
I have used this https://github.com/jacksonliam/mjpg-streamer for a number of years to great success. However a word of warning: Wifi streaming video can really degrade your wifi for other devices. especially if the streaming device is at the edge of the range of the wifi. Ethernet streaming is really the way forward.
Why not dedicate a WiFi channel to the video then? WiFi routers are inexpensive.
I've done a TON of work in this for reasons and can tell you that streaming over 2.4Ghz especially is an anti-pattern unless you're dealing with super low-quality streams and/or only dealing with 1-2 devices. Even 5Ghz can get froggy with traffic contention. Working against a 15fps 1080p stream on 5Ghz is actually how I test streams with poor health and unpredictable behavior. Throw streaming over TCP into the mix and oof.
Also throwing another network component into the mix may not work for most folks.
---
PS: Before someone yells at me for saying "TCP streaming" because "clearly UDP is the right tool for the job!": nope. TCP is the use-case.
Is it possible to make an IP camera appear on the other end as /dev/videoX with near zero latency? Even with LAN ping times of 200ms of latency with IP cameras, sometimes as much as 1000ms, and can't figure out a good solution.
I have to imagine that's mostly due to encoding, right? I wonder what the cheapest format to get a hw encoder for is.
It's a neat project, but doesn't having to connect my computer to the zero's wifi-hotspot mean I can't actually use my own network since I would not be routing my connection through a zero. That would then make this kind of device kind of useless unless I have a dedicated device to watch the stream from? Or am I missing something?
Accessing the cameras then is no different than accessing anything behind NAT on a home network. The AP can have holes punched for port forwarding to the cameras, some kind of dyndns solution could be used to give them a persistent name if the AP's public network address is dynamic. There are other solutions in this space as well...
My preference however is to not punch any holes and not bother with supporting external connections at this layer. Instead I have the cameras establish and maintain ssh connections w/reverse tunnels on an external server having a static IP on the internet. Those reverse tunnels only listen on localhost ports at the server, requiring a locally executed process to reach the camera tunnels. In the case of my server's configuration, that basically requires logging into the server via ssh to reach the camera tunnels. For an authorized user with ssh access to the server, it's trivial to access the tunnels with a web browser by establishing a SOCKS proxy via ssh and configuring a web browser to use it.
I've ~reproduced this setup for some friends/family members, using extremely cheap VPS instances strictly for terminating the ssh tunnels and providing a self-signed cert https proxy w/basic auth to reach the camera tunnels more conveniently using a smartphone's browser. It seems to work fine for them once they get the self-signed cert permanently accepted in their phone's browser, and is more convenient since they're not IT people and won't be running an ssh client anytime soon. The main problem that's come up is reconfiguring their cameras wifi when they upgrade their home network. They forget about the cameras wifi dependency, and by the time they discover the problem it's too late and we're talking usb2serial GPIO console to reconfigure wpa_supplicant time.
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…
Does anyone know if any of these projects capture the h.264 stream encoded inside the webcam? I would be interested in setting up something like the nest paid subscription but on a local server (meaning record 100% of the video and build a nice interface to navigate it. No "detection of movement" kind of thing involved unless for tagging).
I'm working on an open-source NVR: https://github.com/scottlamb/moonfire-nvr that is secure, will run on a Raspberry Pi 4, and has a good recording schema. I wouldn't describe the UI as nice yet, but I'd welcome help in making it so!
There are some other open source NVRs (I see someone mentioned Shinobi). Probably a couple reasonably-priced commercial software options (people like Blue Iris, but it's Windows-only). Some commercial NAS devices have NVR support (eg Synology). Dedicated NVRs from manufacturers like Dahua/Hikvision (but my experience is they're awful). YMMV.
I use Raspberry Piz to do the camera work for my robots. But I have a web interface. http://robot247.io/robot/pibot I think overall these devices are amazing for lifting video from one place to another. One day though, i will work on getting h.264 working.
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…
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.).