I'm using https://github.com/showmewebcam/showmewebcam, which is a prebuilt image with a (more) finely tuned uvc-gadget implementation and lower CPU usage when idle (I've added a few tweaks to it myself). It also boots _very_ fast.
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)
Oh hey, it's an actually good example of using an external buildroot tree. Often vendors will ship the whole of buildroot from about 4 years ago with their patches on top (of course, with no source control so you have to diff it yourself to extract their changes)
I love this! I've been using mine as a webcam for a couple months now (among other side-projects). You need a different lens though.
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.
I wouldn't call the 6mm 'fisheye', not on the tiny sensor on the HQ camera. Accounting for the crop factor, it's similar to a 35mm lens on a 35mm camera. Wide-angle, for sure, but not 'fisheye'.
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.
Do you have any examples of this? I've been interested in building this Pi camera using a lens with a shallow depth of field, but it's very hard to figure out a lens to get that will work with the Pi, look right if mounted from around 2 to 3 feet away, and have a decent quality picture.
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.
>it's very hard to figure out a lens to get that will work with the Pi, look right if mounted from around 2 to 3 feet 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:
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.
If you really just want that bokeh, it's going to be much easier and look a lot better with a DSLR air mirrorless. I typically use my Sony a6000 with a 30mm f/1.4 lens at f/2.0. You won't be able to get the same kind of background separation using the tiny sensor on the HQ camera.
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.
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.
> 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.
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 don't believe he's using the lens without some kind of post processing.
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:
I am bad at evaluating what's a good video or not.
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 ?)
Does anyone know of a raspberry pi (or similar) webcam system that can upload an encrypted video stream to a server? Preferably a (any) plain file host rather than hosting some custom service, but I'm interested in either option.
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...
A lot of UVC webcams will output MJPEG, basically a sequence of pre-compressed JPEG frames, which would relieve pressure from the Pi's CPU.
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.
Doesn't http progressive download (over https) achieve this? I could be wrong, but I think if you just configure nginx with SSL and have the webcam dump to some sort of a raw file format, you should be able to download the file and since you're using SSL now it's encrypted. It won't be a true streaming server, but should be close enough.
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.
This doesn't satisfy either requirement: "encrypted video stream" most importantly, but also "[using a] plain file host rather than hosting some custom service" since a plain file host won't pull my https stream, I'll need to setup another service to do that. Or did I misunderstand what you meant? Either way, thanks for helping think of solutions!
Depends what you mean by "plain file host". To some that means a server I control that has a simple file share configuration. To others that means Google Drive. In the case of the former just mount the storage securely on the pi and save "locally" to it. Could be as simple as mounting the remote server via sshfs and selecting that mount directory to save the file.
In the case of the latter usually a similar concept but depends on the service/protocol.
> Could be as simple as mounting the remote server via sshfs
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?
I'm not sure I follow how sshfs is unencrypted, it's literally just "I have a server with ssh/sftp enabled and I'm going to mount it's storage that way". Most certainly encrypted.
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.
encrypted video stream? you mean to encrypt the stream itself?
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
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×.)
The CPU horsepower may be a limiting factor, but your best best for putting it together from common raspbian/debian software pieces would be using ffmpeg as an RTSP video stream server, and a separate way of encrypting the network traffic end to end (openvpn, wireguard, a more traditional ipsec tunnel, mounting a remote mount-point over sshfs and continually writing small temporary files to the destination, etc). Then at the destination end, have your choice of RTSP client/stream-receiving software pulling the video feed.
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.
ZoneMinder doesn't do encryption, not sure if it would allow adding in gpg as a plugin somewhere.
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! :)
> Transcoding the video would be a plus and can't happen remotely due to encryption.
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.
> Unless the remote system (where the video is being received) is untrustworthy
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 :)
Pretty cool. Recently, I made a Raspberry Pi webcam myself as a replacement to my laptop camera, following Max Braun's tutorial and using the (considerably cheaper) Camera Board v2. Although it takes about thirty seconds to boot up, and I've yet to design a mount, it just works with everything.
It's just about the same. The real advantage of making a standalone webcam for me was because my laptop's camera is just above the keyboard and unusable in most scenarios.
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 ?
The Pi can be powered from the same data port so that it only needs one cable. If you're comparing this project to an off-the-shelf USB webcam, also consider that a Raspberry Pi makes for a very hackable base (for example, I'm planning on wiring up an LED ring to it sometime soon).
"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 really, really wish I hadn't gotten rid of my old iSight years ago (sold it on eBay)—I loved (and still love) the design of that camera... it's like a lens that's a camera.
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.
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:
The first of these variables (dirty_expire_centiseconds) controls how long written data can sit in the page cache before it's considered "expired" and queued to be written to disk; it defaults to 30 seconds. The value of dirty_writeback_centiseconds (5 seconds, default) controls how often the pdflush process wakes up to actually flush expired data to disk. Lowering these values will cause the system to flush data to disk more aggressively, with a cost in the form of reduced performance.
I bought a beaten up Sony NEX camera with PMCA(discontinued Android app market feature, not to be confused with other PlayMemories features) while ago, and turned out there’s already an app on GitHub to start telnet over Wi-Fi with root.
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.
How is the quality compared to a decent webcam (like a Logitech C920), assuming regular lighting?
BTW 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."
In the video, I specifically highlighted the C920 at 0:50 or so (compare that—in the same lighting conditions—to the footage at the start of the video).
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...
You can just select a different mic input? Or desolder it if it's a security concern?
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..!)
OBS would really kill a Pi if you tried doing anything too complicated. It can do screen capture, and maybe a few simple scenes, but things like multiple sources/compositing are too taxing on the SoC right now.
How feasible would it be to have the device wireless? I understand you can host a cctv like option but what about selecting a device as a webcam that’s not plugged in but served over WiFi? (Sorry if that’s not well worded)
Surprisingly so, I use uv4l¹ for capturing 720p60 and 1080p30 and it has worked well, though I don't know if this method would work in your use case, since all it gives is a raw h264 stream over http, and a browser preview into it.
this is great, and im super into it, but i do find it kind of funny how the other post the author mentioned was “super vague”, whereas somehow installing ansible and blindly installing a random playbook is any more explicative. (for me it’s fine because i’m always happy to read the code— i’m not complaining)
really glad to see a quality comparison; definitely gonna try this with my pi zero w i have lying around.
The main comparison here is that IMO, if you've never encountered UVC-gadget, OTG configuration, dtparams, etc., then seeing/auditing an Ansible playbook that can reproducibly set up a Pi over and over is a lot simpler than reading through about 20 different steps of instructions that are setting up serial interfaces and the like.
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).
For between $22 to $72, you can put together a cracked/used iPhone 5S ($50 to free), a MS2109 HDMI capture ($7), and a lightning to HDMI adapter ($15), CameraVision app (free), and obtain a much, much higher quality video, incl. autofocus.
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)