[HN Gopher] Piipcam - 1080P IP Camera on a Raspberry Pi Zero W
___________________________________________________________________
Piipcam - 1080P IP Camera on a Raspberry Pi Zero W
Author : mattcourant
Score : 153 points
Date : 2020-11-01 13:35 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pedrocr wrote:
| IP cameras need their Linksys moment. The hardware has advanced
| immensely but the software is terrible.
| arminiusreturns wrote:
| I highly reccomend Motion, check it out if you haven't. I've
| ripped out and replaced subpar proprietary vendor crap with it.
| (keep the cameras depending on model, ditch the included DVR
| systems)
|
| [1] https://motion-project.github.io/
| pedrocr wrote:
| I've used motion and it's fine as the DVR part with MJPEG
| cameras. Something else is needed for modern h264/h265/av1
| stuff. I've started coding on it a few times but have never
| gotten it functional. But my point is about the software that
| runs in the cameras themselves.
| squarefoot wrote:
| Motion is great, but most (all?) consumer IP cameras and
| DVRs/NVRs are Swiss cheese security wise, they routinely
| phone home or make connections with servers in China, some
| even contain hardcoded passwords etc. so that the only way to
| use them reliably would involve a firewall only accepting
| connections from trusted sources while preventing the cameras
| subnet to send anything to the outside world.
|
| What we need is some alternative firmware just like OpenWRT,
| but aimed at IP cameras. That would be a real challenge,
| therefore it is probably better to build the IP camera from
| ground up with security and trust in mind. The PineCube from
| Pine64 seems a really good step in this direction. Just like
| their PinePhone, being so hard to liberate an existing phone,
| it's actually easier to design and produce from scratch one
| that is really free and open and therefore trustworthy.
|
| Some interesting options also from Friendlyarm to make small
| Linux driven embedded boards with cameras. https://www.friend
| lyarm.com/index.php?route=product/product&...
| azinman2 wrote:
| Why isn't motion + motionEye + raspberry pi just that?
| KaiserPro wrote:
| 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.
| djmips wrote:
| Why not dedicate a WiFi channel to the video then? WiFi routers
| are inexpensive.
| folkhack wrote:
| Because it's still not a great solution.
|
| 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.
| mkarliner wrote:
| How do I create this from a stock Raspbian install?
| iampims wrote:
| The pi configuration is at:
| https://github.com/sepfy/piipcam/tree/master/bsp/meta-piipca...
|
| You'd have then to compile the source.
| ausjke wrote:
| 720p or 1080p wireless/wired/PoE IPCamera with FCC-certification
| has been on the market for a few years, at the price range of
| 30ish dollars, you can buy IPCamera modules for about $10 from
| vendors(mainly in China) and reprogram with your firmware as
| well.
|
| RPI-based camera is great to learn stuff, but to make a product-
| like devices, there are too many to choose on the market already,
| cheap and easy and most likely more robust.
|
| Isn't ip-camera a solved problem?
| mschuster91 wrote:
| > Isn't ip-camera a solved problem?
|
| Not if you care about:
|
| - image quality, most of these 10$ camera modules have
| "sensors" that only work halfway decent with good lighting and
| are little more than static noise at night
|
| - general build quality, expect issues with the power supply or
| at temperature extremes
|
| - security, there's no OpenWRT or equivalent for these, so even
| if you make your own firmware you're still responsible to keep
| it up to date yourself
|
| - no "advanced" features such as a back-up battery, durable (!)
| on board storage and a wireless fallback in case there is an
| attacker who simply cuts the cables
| ed25519FUUU wrote:
| Links? I'd love to just buy the modules and stick them on my
| own boards.
| mbrumlow wrote:
| 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.
| neurostimulant wrote:
| Very cool robot!
| pokot0 wrote:
| 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).
| scottlamb wrote:
| Typically cameras just output the H.264/H.265 stream(s) via
| rtsp, and optionally a video analytics metadata stream. The
| part that records video from one or more cameras can be
| separate and is called a network video recorder (NVR). This
| split allows you to store several cameras' stuff in one place
| that is better physically protected and in a better form factor
| for having a hard drive, access a bunch of cameras' data easily
| under one UI even if they're made by different manufacturers,
| etc.
|
| 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.
| ed25519FUUU wrote:
| You can run something local like Shinobi. That just requires
| any rtsp camera. It can even send you push notifications on a
| discord channel.
|
| https://shinobi.video/
| fimdomeio wrote:
| I believe you can do almost the same by just running a vlc
| command in the pi[1]. A complete disk image might be a bit
| overkill.
|
| [1] https://raspberrypi.stackexchange.com/questions/23182/how-
| to...
| diego_moita wrote:
| You can, but that solution uses a Raspberry Pi camera, not an
| USB one. They have completely different hardware interfaces.
| 542458 wrote:
| Are you sure? The image in the linked article shows a Pi zero
| with the Pi camera case (not USB).
| diego_moita wrote:
| Sorry, my fault. You are correct.
|
| I implemented a similar solution (with http-based
| streaming), but using Motion with an old USB camera. I
| assumed this solution would also use an USB camera.
|
| I still prefer the Motion solution. Streaming through http
| opens a lot more possibilities.
| lostapathy wrote:
| 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.
| shorts_theory wrote:
| 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!
| alphaomegacode wrote:
| 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?
| qwerty456127 wrote:
| > 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.
| opencl wrote:
| The hardware supports h.265 decode but not encode.
| qwerty456127 wrote:
| What about Raspberry Pi 4?
| opencl wrote:
| I should have been more specific: the 4 supports h.265
| decode but not encode, none of the other Pi hardware has
| either.
| joosters wrote:
| RPi Cam is very good: https://elinux.org/RPi-Cam-Web-Interface
|
| But it only works with the pi webcam, not with usb cameras
| 01100011 wrote:
| Gstreamer? I've used it in the past, both professionally and
| personally, to generate rtsp/rtp and it worked great.
| joefourier wrote:
| 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.
| phoboslab wrote:
| 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...
| pauldickwin wrote:
| 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.
| rb2k_ wrote:
| 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.
| numpad0 wrote:
| 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.
| stevepike wrote:
| There are fancier modern things but
| https://cr.yp.to/daemontools.html still works great for
| keeping a simple script running.
| johnchristopher wrote:
| 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
| mschuster91 wrote:
| 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.
| cptskippy wrote:
| 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.
| almog wrote:
| 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.
| mindslight wrote:
| 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.
| johnchristopher wrote:
| > 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.).
| colordrops wrote:
| Can ffmpeg work? I've used it with IP cameras before with much
| success.
| comboy wrote:
| https://github.com/BreeeZe/rpos
| fartcannon wrote:
| I've been using https://elinux.org/RPi-Cam-Web-Interface. It has
| an interesting motion detection and record function.
| diego_moita wrote:
| It does have a lot more functionality, but it doesn't support
| USB cameras. It only works with the Raspberry PI camera.
| julian_adams wrote:
| Yeah, I have experienced it too.
| gambiting wrote:
| I do distinctly remember someone changing some config files
| to make it work with a USB camera. Not exactly plug-and-play
| but it can be done.
| cptskippy wrote:
| There's a project call rpos that turns a Raspberry Pi into a
| Onvif Compliant-enough camera that most NVRs can use. Onvif uses
| RTSP streaming just like this.
|
| https://github.com/BreeeZe/rpos
|
| Either way, OBS supports RTSP so you can pull feeds in and
| surface them as a virtual webcam to the rest of your OS.
| tmzt wrote:
| This might be another option:
|
| https://wiki.pine64.org/index.php?title=PineCube
| dheera wrote:
| 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
| <2ms I routinely get >200ms of latency with IP cameras, sometimes
| as much as 1000ms, and can't figure out a good solution.
| xxpor wrote:
| I have to imagine that's mostly due to encoding, right? I
| wonder what the cheapest format to get a hw encoder for is.
| [deleted]
| 01100011 wrote:
| You need to tune the buffers on both the sender and the
| receiver, as well as choose a codec with low latency. It takes
| some work, but you should be able to get it below a second
| without too much trouble.
| omegote wrote:
| I think you could probably achieve that with v4l2loopback and
| ffmpeg. I've done something similar in the past and it works.
| daniellarusso wrote:
| In the past, w/ Axis cameras, I have enabled two streams, the
| high quality, high res. h.264 with high latency, and a lower
| resolution mjpeg stream with much lower latency.
| asutekku wrote:
| 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?
| coder543 wrote:
| I haven't looked at the project yet, but... your comment
| precludes the possibility of your computer having a wired
| ethernet connection to the internet.
|
| Then the camera could be placed anywhere as long as it can get
| power, and your computer could connect to both the camera and
| the internet.
|
| But, I don't understand why the project would really benefit
| from the Pi Zero hosting a wifi hotspot... it seems like it
| would be better for it to just join an existing wifi network.
| pengaru wrote:
| I use Pi Zero W camera kits for security cameras, and they just
| associate with their own dedicated wifi AP, which puts them
| behind a NAT firewall and routes to the internet in the usual
| fashion.
|
| 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.
| INTPenis wrote:
| That step should only be to test and configure the camera.
| While you're connected you login and configure your own wifi on
| it.
|
| Preferably that web tool should do it for you.
|
| Either way, a lot of consumer products have that one step.
| diego_moita wrote:
| This is the biggest issue I have, too.
|
| Motion[1] has a lot less resolution and it's video is not good.
| But, at least, I can access the video stream through http. That
| makes an huge difference when implementing a solution. For non-
| tech users you can just stick the camera's streaming webpage to
| a phone home screen and give instant access to the video
| stream.
|
| [1] https://motion-project.github.io/
| intricatedetail wrote:
| This is great but why people don't post something more complex
| than connecting two things together? No disrespect but even basic
| Lego set would have more than two parts.
___________________________________________________________________
(page generated 2020-11-01 23:00 UTC)