Usually running 'sudo ldconfig' will sort this out, once the shared library directory is added in the right ld.so.conf file (for example /etc/ld.so.conf)
I wish v4l2loopback was included in the kernel. I've wasted far too much time messing about with DKMS in the past that I now avoid any out-of-tree modules if I can avoid it. And with Secure Boot they become untenable.
I've been wondering for a while and can't find an answer to this:
SD to USB adapters exist, but is it possible to hook up an SD-to-USB cable and have a driver present a virtual sd disk to the camera but write the video directly to your computer RAM via USB?
That seems pretty roundabout, when you have solutions like the Elgato CamLink that just takes an HDMI input from your camera and shows up as a completely standard USB Video Class device to the OS.
My DSLR camera has a mini HDMI out that you can use out of the box, doesn't require the camera to be in recording mode or such. It simply gives you the live video feed -- rather than having it write to SD card, having software on your computer decode the video & show the last frame there.
The only option I think (it's been a while) I had to vaguely enable is to have it not show the normal camera UI over HDMI, but that was a simple setting.
Having hardware emulate a SD card sounds like a niche product, if anything, whereas the only item I needed for my camera was a mini-HDMI to HDMI cable.
The elgato is doing something completely straightforward — video output to video input, done. With only a few details, it’s almost like a regular webcam where the controller is in the usb plug rather than the webcam’s body.
The SD thing has all sorts of nastiness to it.
First, you won’t have a standard usb video input, so you’re going to need to do a bunch of awkward driver work to get applications to consume the video feed.
Second, you’ll have to deal with the lag and jittery video that you get because the camera will almost certainly buffer writes.
Then you have to figure out how to get the controller in the SD reader to understand the incoming writes, which it was most certainly not designed to do.
Wi-Fi-enabled SD cards that automatically inspect the filesystem and upload your photos to the internet or a computer already exist, it shouldn't be impossible to modify the firmware to upload MP4 files in a streaming fashion, assuming they have the bandwidth.
SD interface is a bit complicated to set up for average hackers, on top of buffering issues. Likewise there are some cameras with PCIe derived interfaces for memory cards, but those aren’t actively being hacked either.
Nice post, but that's way too much work to be worth it. You really want your camera and mic setup to just work rather than having to tell someone to wait 10 minutes to call because you need to reload your kernel module.
What work? That seems very comparable to any moderately nice webcam: Install software once, then forget about it. The "setup" for something like skype is then just selecting the cam from a drop down menu.
An argument I could see is having to get out the camera, put it onto a tripod, connecting power, ... etc.. Though that is only an issue if you cannot just leave everything set up.
People who do stuff that requires tinkering always seem to be spending ten minutes here and there at unpredictable times fixing stuff.
This seems like it should work very well. But... it's hard to imagine there not being some issues.
If nothing else, it will be an issue if you need to quickly do a clean reinstall, every customized thing is an extra few minutes of work, wheras a hack-less plug and play system is almost trivial to remake from scratch.
This could be amazing for a specialized application like a photo booth, but I'm not so sure about just regular desktop use.
As it appears to be necessary: \s, it was a lighthearted statement about how software is almost never "forget about it" and breaks on updates in unexpected ways.
It handled via dkms so it's rebuilt automatically everytime you update your kernel. Then it's loaded on boot, no insmod/modprobe needed. I'm not sure what the issue is.
Maybe this particular dkms doesn't have the issue, but the ones I've used breaks when the internal kernal APIs changes and the external module isn't updated yet.
I've never found that with dkms provided by the official repos, which this is. Also I've got personal experience maintaining a fleet of these for video ingesters, using that exact dkms packaged module.
Because the HN commenting guidelines contain paragraphs such as these, many users including myself feel comments like that deserve downvotes, because we think the site will be better with less of them:
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> Eschew flamebait. Avoid unrelated controversies, generic tangents, and internet tropes.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
But... it's just downvotes! I'm sending a polite signal, losing a bit of a digital karma score shouldn't be painful :) Please downvote me any time I comment something you think shouldn't be commented on HN!
I aree it is a lot of work but you set this one once and the kernel can be loaded at boot time.
I wouldn't do that for general visio conferencing as sound is much more important than video but for someone producing video content it is definitely worth it.
To be honest, it's not really about Linux and reloading kernel modules. Fairly early on in the pandemic, I setup my Canon EOS as a webcam on my Mac. I immediately had a problem with an agency trying to record video of me with that setup. And it was generally a certain hassle to turn the camera on, get it focused properly (older model that doesn't continuously keep focus on video), etc.
I went back to just using my Logitech 920. People probably can't mostly tell the difference given regular network glitches and so forth.
First you have to spend a few minutes searching your bash backlog for the exact modprobe command, then you realize you updated your kernel so you have to recompile and resign it, then you have to fiddle with your video inputs but the gui is somehow out of sync with the actual setting. Then run a test before joining the call. And then the other person has the window under their browser and never looks at your video.
My experience of this general approach with a Sony α6100: high and inconsistent latency (mostly 150–200ms, but sometimes towards 400ms), low resolution (1024×576), largely not hot-swappable (most apps required that the video device be created before their process began, and trying to read from it without also starting the stream would often poison things in some way, and various actions would make the pieces just stop working together until you restart all relevant processes), and interacts poorly with other similar things (e.g. I failed to get it to combine with OBS’s virtual camera output: no matter what I did, even with creating multiple devices and attempting to control which thing wrote to which, they’d still get tangled so that neither was of any use). Still, the image quality is good, considerably better than most webcams.
(It’s valuable to understand how this approach works: it’s using PTP, which supports roughly the commands “list the files you have” and “give me the file IMG0001.JPG”, and roughly thirty times a second it asks “give me the file ‹what the camera can currently see›.jpg”, and the video stream is that stream of JPEGs. Basically, this whole thing is a dreadful hack.)
By contrast, the cheap USB HDMI capture card I subsequently purchased (branded Simplecom DA315, but if you’ve looked into this stuff you’ll immediately recognise it as ODM hardware sold under a million brands) supports higher resolutions, normal latency (vastly lower), is hot-swappable, and doesn’t interfere with anything else trying to use v4l2loopback. Colour is not quite right, so I adjust it a bit on my camera. (This was something that surprised me when I first looked at HDMI capture cards: it seems that they’re all wrong, in differing amounts and directions. I do not understand why they can’t just be correct.) And there’s an aspect ratio problem where apps that request a lower resolution end up with the 16:9 image squashed to 4:3 with black bars added to the side. Not sure if this is a bug in the HDMI capture card firmware, Linux driver, or something else. As a demonstration of this, Google Meet in Firefox will get squished by default, but if I manually change its send resolution from auto (360p, I think) to 720p, it gets unsquished.
I also tried a similar setup (with gphoto2 getting the stream of jpegs, ffmpeg, loopback device) but the deal breakers for me we're:
- high latency: in the half-second range, consistently out of sync with the audio
- bulkiness: I had to place the camera on the side of the screen rather than on top, so I consistently looked away from the camera
With that experience I didn't find it worth to upgrade the setup (with mini HDMI cable, capture card, power supply) and ended up buying a crappy webcam instead
I did this but a kind of showstopper was the fully opened aperture in liveview mode that lead to a very shallow depth of field. With my 30mm lens we are talking about centimeters (inches). I never figured a way around this.
Last I played with it - on OSX; you could set the camera to M and adjust settings directly. I still left it wide open for that buttery buttery f/1.2 background during standup.
I'm curious if this is any more consistent than the webcam software that Canon provided for Windows and Mac. I tried the Mac implementation briefly, but found it to be _extremely_ glitchy (even with hard-wired power).
Not a Canon EOS user, but typically there are accessories called "dummy batteries" that take the shape of a standard battery, but is actually used by connecting to the AC socket. This way, the camera can be powered on constantly so long as the venue with the AC doesn't have a power outage.
I actually came across an Eos “webcam kit” at Walmart in-store that came with a USB cable and the AC adapter. Pricey at ~$90, but they did sell it like that.
Since all EOS R series camera's can charge their battery perfectly fine when connected to a USB-C PD charger the only thing that adapter 'fixes' is the software lock Canon placed on the camera which causes it to stop charging from USB when turned on. Smells like a software-defined business model to me...
It really makes a better picture. Zoom / Meet / Teams / etc does compress a ton, but a big part of the horrendous video quality are webcams.
Another, potentially cheaper way to replace a webcam is to use the main (rear) camera of an old cell phone.
Digital photography, especially using tiny sensors, is computational photography. Webcams are too cheap to have reasonable processing power internally and webcam companies don’t have the budget to create high quality post processing software for the host computer.
Shallow depth of field also means that the video codec only has to concentrate on encoding detail in the [narrow] focal plane. In my experience, the results are stunning (50mm f/1.2L @f/2.0 and diffused LED video lights), and the combination of the well-lit in-focus elements in the image (transmitted by good glass) with the deeply and naturally blurred background would suggest that increasing the number of pixels in the image from ~ 1024x640 to ~ 1920x1080 would probably be far less noticeable than the numbers might suggest.
There’s a bunch of advantages even with bad video from meet or zoom.
Big sensor + nicer fast lenses means you require a lot less light. Nice fast glass means you can blur out the background optically without all the artefacts introduced by software background removal. If you use a zoom lens, you have a tonne of control over the framing.
I feed it into OBS and can get 1080p easily on a 5D MKII, a camera that's now more than 15 years old. Better quality than any dedicated webcam I've seen.
I thought you needed a 5DmkIII to get 1080p, because the 5DmkII has USB2.0 and is limited to a 200Mbps transfer speed (using MJPEG). And the HDMI resolution is much lower than that.
With a setup like this, I imagine that the camera is far enough from the center of the monitor to make having "eye contact" impossible. Any solution to this problem?
It works with a lot of DSLRs, it doesn't require you to do any of these steps, and it captures the output. The only thing it doesn't do is then map that to an output for other applications to pick up.
There is an open request for this, but it seems to be out of scope for the application.
It is fine. I have been using an "old" canon EOS 1000 for a few years now. But I use an HDMI capture card with magic lantern running on the camera to get a clean HDMI feed.
Magic lantern to remove shutter speed and other menu overlays from the hdmi feed, might also enable long duration HDMI output without the camera going to sleep.
I use a Canon R6 as a webcam. I noticed it gets reasonably hot after long meetings so I avoid it day to day. It is great, though, for client meetings because they always notice the quality of the image and ask how do I get that nice out of focus background :)
I've used a bunch of DSLRs w/ live preview active for extended periods w/o any issues. It's solid state, so the affect should be negligible assuming you're not directly exposing it to a lot of direct UV light or something like that. For me (used to run a photo automation company), the main wear factor on Canon DSLRs are mirror and shutter actuations (after about 50K-100K actuations, the mirror will tend to detach - this is repairable via CPS), however in preview mode, you aren't going to have any of that mechanical stress.
Sensors getting hot - specially in older cameras - is a well-known problem. Lp doesnt stress the sensor enough (low fps, partially off), but filming video will.
Picture-taking wise DSLR is not any different than e.g. webcam (aside from form factor) - it is just a sensor with electronics to read, process and transmit/store data.
The only thing that differentiates an SLR is the shutter/mirror mechanism, which is mechanical part and lifetime is roughly proportional to a number of "uses".
It's still enclosed in a dust-free environment. I'd say unless you shine laser beams directly at the sensor, or point it directly at the sun all day it'll be fine for many years.
Also, some (or most / all?) cameras will close the shutter curtain when disabled. Presumably you would enable the camera only when you need it.
I've always needed an LD_PRELOAD to launch whatever, eg
maybe someone will chime in because they know better than me about all the details here.