Raspberry Pi Webcam
github.com
github.com
Works great, although you do have to fine-tune the settings for your environment (which you can do by editing a camera.txt file on the SD card or using a serial TTY via USB)
(edit: typos)
The 6mm fisheye lens is crappy and the distortion is terrible. The 16mm lens is higher quality but the zoom makes it difficult to use as a webcam.
I bought the 6mm M12 portrait lens from https://commonlands.com/products/portrait-6mm-m12-lens which works much better. Being M12 it's not the best form factor, but it has a rectilinear picture and the framing is what you want for a webcam.
https://www.reddit.com/r/RASPBERRY_PI_PROJECTS/comments/gnww...
It works well as a macro camera for super close up pictures, but otherwise it's pretty terrible when compared to my other lenses.
I don't know which lens Jeff used in his video, I would have to rewatch it and I'm not inclined to do that. If he used the 6mm lens he would have likely cropped the image or used post-processing to remove the distortion.
Processing the image is a solution, but it has tradeoffs and I'm not sure how easy it is to do it in real-time on a rapsberry pi zero.
He uses the "official" 6mm lens.
I use it daily for video and I just loaded it up and re-checked - I don't see distortion like in that reddit posted image. I see something very similar to the examples in Jeff's video. I highly doubt he'd have post-processed the video, that would be extremely misleading. In the context of similarly priced webcams that are available to buy in 2020, I find it very usable and not at all terrible. But I do appreciate it's all subjective.
I think you need to take a closer look at your lens, perhaps you bought a different model. I'm not the only one complaining about the poor quality of the official 6mm lens:
https://www.raspberrypi.org/forums/viewtopic.php?t=272658&st...
Every picture and video I've taken with my 6mm lens has this distortion clearly visible.
I agree it's not amazing as a lens, but it's passable and cheap. Certainly better than the tiny webcam lenses on the majority of sub-$80 MSRP webcams.
I also have a Tamron 8mm f/1.4 C mount lens that is a bit sharper, and also renders things a little nicer, though it's a little tighter framing. Not bad if you can put the camera back a few feet, but would be cramped in a tight space.
After spending a bunch of time researching, I got this feeling if I pursue this project I'll end up with hundreds of dollars of bad lenses and just wish I would have bought a real DSLR or mirrorless camera that connects via USB.
I bought a Tamron 1.4 8mm lens that gives a similar effect to what my Sigma 30mm E mount lens gives at f/4 or so, if it's positioned about 2' away.
This is why I purchased a Commonlands lens instead of a variety of others (including Arducam). The owner has gone through the trouble of taking a consistent photo of the imatest pattern for each lens they are selling, i.e. this:
https://cdn.shopify.com/s/files/1/0273/9273/7398/products/ce...
and measuring the amount of distortion and listing it as part of the specs.
That gave me a really good idea what the picture was going to be like before I purchased the lens, and the product I received accurately reflects what was shown in the image.
It also showed me that even a small amount of distortion (2%) was too much for my use case.
Would you the “official” 8mp raspberry pi cam (2.1) is worse than a dell laptop webcam ? (as in: not worth my time reusing one to have a movable camera for zoom calls ?)
I want to have an off-site backup of the security cam but preferably only access my camera data myself. That's what I'm always missing in these projects. There are dozens, perhaps hundreds of raspberry pi (security) camera setup tutorials and scripts with motion detection and all sorts of features, but I haven't found any that implement any sort of encryption, if they do uploading at all...
In the case of the latter usually a similar concept but depends on the service/protocol.
Right but that's not encrypted and requires me to maintain another server. With unattended upgrades it isn't much, but it adds up if you have ten other things already running and you're actually trying to downsize this time commitment (mainly for the major version upgrades which take days out of holidays every few years, upgrading and re-testing everything again, sometimes fixing dependency issues, reinstalling things...).
Storage can be an "as a service" thing these days, indeed Google Drive / OVH NAS / hosted NextCloud / HiDrive / etc. is what I meant, basically anything that could interface with a pi in a way that it uploads the encrypted stream, so you capture whoever unplugs it -- at least that's how I imagine a regular security camera would work. But then, the only things I find online start at 4 figures and none of them are open source so who knows what encryption (if any) they really apply... Is there really no one on this planet running open source encrypted cameras, are all these systems that consumers use (some of whom are hackers) 100% proprietary, plaintext, or only stored on-site?
If you mean the individual video files post upload then it's probably easier to just encrypt the drive on your storage server rather than every individual file you upload to it.
raspbian has support and packages for everything you could do with openvpn on a normal debian system, so you can totally build a point to point openvpn tunnel for traffic if that will suit your needs.
if all you want to do is upload image files you can script it with ssh public/private key auth and something like rsync/sftp/scp
Yes.
And indeed Debian (raspbian) has a ton of components that I can string together, but it doesn't appear entirely trivial to make a low-powered system encode (h264 is expensive by itself) and encrypt a video stream of a decent frame rate and resolution and upload it to a standard file host, all close to realtime (perhaps up to ~4 seconds delay, that should be fast enough even if the intruder knows about the cam (Kerckhoff's principle) and immediately moves to pull the plug).
I don't think it can be done with entirely off-the-shelf components actually, it probably requires quite a bit of glue to make the components work together, cleanup files (locally and remotely), etc., but I'd be happy to be told I'm wrong :)
Edit: did you edit this in?
> if all you want to do is upload image files
Well kinda, but multiple images per second and preferably with some delta algorithm so they're not 100k×86400×fps = something on the order of 50GiB/day. A h264-compressed stream is an order of magnitude smaller. (Sunrise is the worst, increases the stream size by ~3×.)
https://www.google.com/search?client=firefox-b-d&q=ffmpeg+rt...
https://github.com/aler9/rtsp-simple-server
https://news.mistserver.org/news/71/An+introduction+to+encod...
Some of the back end software pieces to do it are not very dissimilar from a typical 'zoneminder' install on amd64 debian. Yeah I edited that in after I forgot to include it before hitting the post button...
on something like a raspberry pi 3b+ or 4 you might get good results by using a video frame rate around 5fps. Or even if you went down to 2-3fps that would be functionally equivalent to a constant stream of still images, depending on what the stream is needed for. If it were a security camera that needs to see peoples' faces the frame rate could be too low, a moving person might pass through the frame without any good shots of their face.
If you have lots of network bandwidth you can do a great deal with ffmpeg by not transcoding the video from the format it's acquired from, which is very helpful on systems with limited CPU power.
https://news.mistserver.org/news/71/An+introduction+to+encod...
Network bandwidth is generally not metered on home connections, so that's indeed not an issue, but storage isn't infinite. Transcoding the video would be a plus and can't happen remotely due to encryption. Raw mjpeg is also an option though, storage isn't that expensive (or throw more CPU at the encoding system; a raspberry pi is just an example).
> encrypting the network traffic end to end
but the video stream? The idea is that the storage server (Google, for that matter) doesn't need access to my video stream. Not sure if end to end encryption is too much to ask but I did figure since it's 2020, it should be doable.
Thanks for your responses by the way, it's helpful to have a second pair of eyes on finding a simple solution. Since there doesn't appear to be one, I will start experimenting with some ideas, feeding ffmpeg to gpg and checking cpu vs. compression ratio etc. Next step will be seeing which protocol to use for local + remote writing of the encrypted file (not sure if sshfs does incremental writes / appends). Let's see how hard this is! :)
why couldn't it? Unless the remote system (where the video is being received) is untrustworthy. In my scenario I was describing network traffic encryption, for a theoretical where the entire network between the video-sending and video-receiving linux systems could be 'hostile', but not encryption of the video itself, I was assuming that the location where the video is being sent to is trustworthy.
If the video needs to go to a remote storage location where you want files to be written to disk, but nobody else to be able to read them, that's a somewhat more rare problem to solve. Possibly something involving a virtual machine with a dm-crypt/LUKS implementation for FDE.
Well, that's part of the threat model. There is no need to trust the remote end fully, especially since I'm hoping that I can host at Google / OVH / Hetzner / whatever. I trust them as a backup and not to collude with a burglar, but why give them plaintext data?
... To answer my own question, not adding encryption makes life easy I suppose... but that's not very satisfactory imo :)
Adding SSL to Apache works, assuming you're using Apache.
Edit - This is the closest I can think of, but you'll need to modify it to encrypt the files before upload.
You may need to have the client send a byte range header with each request to ensure you always start near the end of the stream so it's closer to realtime.
One of the use-cases is:
> Capture audio/video from a camera directly into an encrypted media file.
I've never used it and have no idea of the quality.
With some work I suspect you could combine tools like ffmpeg, tar, GPG (with private key stored off-site), and rsync to: 1. capture and extract JPEG frames, 2. bundle them up in roughly equal 1MB-ish tarballs (to prevent leaking information about how compressible the frames were), 3. encrypt them, 4. store locally in case the network fails, and 5. ship them off to be reassembed later.
Either pipe it all through the shell (if possible) or maybe use a RAM disk as a scratch space, and beware of swapping or disable it altogether.
I'm not super familiar with GPG, but bonus points if it can generate a new random symmetric key for each bundle. That way if someone steals the device, they can only decrypt a few of the most recent frames using whatever key is still in RAM.
Depending on your setup you could restream (as in reencapsulate) your RTSP stream to HLS and and restream it through ffmpeg to another container at the end of the chain.
Considering the pi needs to be powered over one USB port and the other USB port is used for data that makes two wire hanging around: ts that really better than an USB webcam then ?
Great, I didn't know that. I happen to have two pi0+camera that I now know how to recycle :).
"what if I told you I am recording this on a professional quality webcam that"
nah mate, it looks like ass, Apple Air FaceTime levels of ass. Besides if it was any good you wouldnt switch back to your fancy gear for the rest of the video ;-)
I just happened to have watched this earlier today.
https://github.com/maxbbraun/pisight
Of course, this one has a better lens than the pisight, and uses the high quality camera module also
> Powering down the Pi
If you want, and you still have WiFi enabled, or the Pi is otherwise connected to your network, you can log into it via SSH and run sudo shutdown now to power it off cleanly.
But I like living on the edge... it's not like the thing is writing a ton of data to the microSD card. When I'm finished using it as a webcam, I just unplug it. Simple as that.
If, for some strange reason, it did end up getting corrupted, I could just re-run this automation to set it up again. No big deal! I haven't had that happen yet, though.
################
If you want to do this you can tune ext4fs to flush writes to disk more often, which does have a small impact on disk performance (a moot point on something using a microsd card for a / partition, really, and on the anemic cpu performance of a pi zero w).
if you google "ext4fs power loss flush writes" you'll find some other references to making an ext4 system slightly more resilient to being abruptly powered off.
https://lwn.net/Articles/322823/
One possible solution is, of course, to just run ext3. Another is to shorten the system's writeback time, which is stored in a couple of sysctl variables:
/proc/sys/vm/dirty_expire_centisecs
/proc/sys/vm/dirty_writeback_centisecs
The camera seems to use standard gadget modules to handle USB connections, but Kernel seems to predate gadget UVC driver, and the main image sensor is not operating as a V4L2 device.
If anyone could get a UVC module to compile and load, and use Sony API to pipe video from, that’ll let users skip the HDMI part when using it as webcam.
https://superuser.com/questions/870768/can-i-use-my-dslr-as-...
sudo modprobe v4l2loopback devices=1 exclusive_caps=1 card_label="porphyracam"
gphoto2 --stdout --capture-movie | ffmpeg -i - -vcodec rawvideo -pix_fmt yuv420p -f v4l2 /dev/video0BTW I noticed this towards the end, which probably doesn't matter if you're using this only for video calls: "The upstream repository providing the uvc-gadget application currently defaults to 720p resolution, which is great for most use cases. You can stream at 1080p, though the Pi Zero and older Pis may drop frames at that resolution. Follow this issue for progress making resolution more easily configurable."
Note that the default viewing angle of the C920 is a bit wider than the 6mm lens on the Pi.
The C920 viewing angle is a bit wide for me, actually, so I have it mounted on a 12" monopod attached to the wall behind my monitor.
EDIT: In the video, your Pi camera looks sharper than the C920, and the depth of field is shallower. Your skin colour looks comparatively flat in front of the C920. I think I have a Pi Zero gathering dust somewhere, so maybe...
It's not that difficult, speaking as someone with three left hands when it comes to soldering (or drawing for that matter) and next to zero experience with hardware/electronics. Recently took out the camera board from a webcam and added an LED: that consisted of removing a few screws, wiggling some plastic clips until it came apart, and finally a bit of yolo soldering an LED from an old keychain light onto the + and - pins of the USB connector. It's almost certainly the wrong voltage but it works. I also removed a speaker from an annoying toy: undo a screw, wiggle, identify speaker (activate the toy a few times), and just hold the soldering iron's tip to the pins until it comes off. With a 5 minute internet video on how melting solder works, I'd be fairly confident that my mom can desolder a microphone without damaging the webcam. (She'd just need more confidence in herself..!)
Would it be possible to insert ffmpeg in between the camera and the output to usb? It'd be fun to throw some weird post processing in there.
It'd be nice if there were some docs about how this works and how to hack it.
Key thing with tools like OBS is you want a dedicated CPU. It's not super-CPU hungry, but it can stall if your CPU is otherwise, erm, occupied.
But you can get it to run—see: https://obsproject.com/forum/threads/obs-raspberry-pi-build-...
1. Something to stream the video over the network (like https://github.com/mpromonet/v4l2rtspserver).
2. A 'driver' for your desktop operating system that can take the stream and present it as a (virtual) webcam.
¹ http://www.davidhunt.ie/raspberry-pi-high-quality-camera-set...
really glad to see a quality comparison; definitely gonna try this with my pi zero w i have lying around.
In the former case, you have something that many of us who are more intimate with code could follow along with and tweak. In the latter, it's something that still requires a little knowledge, but IMO a lot less to get started.
Something like https://github.com/showmewebcam/showmewebcam takes it a step further, but obfuscates some of the code more (IMO) by bundling it in an image that is generated with some build scripts (though that might be the direction I move my project eventually... people don't seem to care as much about trust and auditability nowadays).