LWN: Comments on "Access to complex video devices with libcamera"

Access to complex video devices with libcamera

lamby — Thu, 01 Aug 2019 15:48:37 +0000

As someone who regularly passes "--device=$(find /dev/video* -print -quit)" to fswebcam… thanks. :)

Access to complex video devices with libcamera

swilmet — Thu, 01 Aug 2019 10:41:22 +0000

Are those cameras used through the same Linux kernel APIs/subsystems?

Access to complex video devices with libcamera

swilmet — Thu, 01 Aug 2019 10:39:10 +0000

I also think that libinput is a quite good comparison as an analogous project. A good description of why libinput exists:
https://who-t.blogspot.com/2018/07/why-its-not-good-idea-...

In the talk/article:

> libcamera was started with the intent of being "the Mesa of the camera stack"; its purpose is to make it easy for applications to interface with camera devices.

I would be interested to know more about this comparison to Mesa, the libcamera website doesn't mention Mesa. What do libcamera and Mesa have in common?

Access to complex video devices with libcamera

loose11 — Wed, 31 Jul 2019 14:55:26 +0000

>> Gig-E has the GenICam standard, but it's not supported by all cameras.

Some camera manufactures claiming that they implemented the standard. I had a issue with GenICam, where the standard was "implemented" but they made some hidden calls for specific parameters in there library. At the end, they were overriding my parameters.

Access to complex video devices with libcamera

Kamiccolo — Mon, 29 Jul 2019 12:55:09 +0000

After following libcamera for a while with quite an interest, just saw the following line on the documentation (which was quite a downer):
> Other types of camera, including analog cameras, depth cameras, thermal cameras, external digital picture or movie cameras, are out of scope for this project.

Access to complex video devices with libcamera

flussence — Sat, 27 Jul 2019 05:49:50 +0000

If this could do for video inputs what libinput did for HID devices, that'd be wonderful. I know quite a few people who have no choice but to keep win32 around because it's the only way to get their off-brand (or sometimes brand) HDMI-to-USB3 or whatever device to function.

Access to complex video devices with libcamera

guus — Fri, 26 Jul 2019 19:01:59 +0000

GigE is definitely natively supported on Linux; there are multiple free (at least as in beer) SDKs that support it. USB-3 Vision is just dc1394 over USB, and is supported by libdc1394. The two most annoying experiences I've had while working with numerous scientific/machine vision cameras are:

1. Cameras and/or framegrabbers requiring firmware to be loaded before they work.
2. Cameras using a proprietary protocol for configuring parameters like exposure time, frame rate and so on.

UVC and DC1394 are very nice because they at least have a standard way of setting parameters that almost all cameras use. Gig-E has the GenICam standard, but it's not supported by all cameras.

For USB webcams, setting parameters is trivial nowadays, but actually getting the stream of images is getting more and more complex. The reason is that high end cameras are getting better resolution and framerates, yet are still bound by USB bandwidth limitations. So while early cameras sent simple YUV or JPEG-compressed images, now we have cameras that can actually send a H.264 stream. Videochat applications might want to get the H.264 stream because they can then send it out over the Internet without having to recompress anything.

Access to complex video devices with libcamera

creemj — Fri, 26 Jul 2019 04:12:53 +0000

While xkcd:827 is often trotted out when someone proposes new interfaces or standards, in this case I am not so sure it is apt. There is a real problem with camera interfaces and the multiple standards: v4l2, libdc1394, gig-e (not natively supported on Linux), camera-link (though this is pretty much obsolete now), USB-3 protocols (often requiring closed propriety software), and I am sure there are more. If you want to write software that can support all (or even most cameras, particularly machine vision cameras) then you have to support multiple protocols. So I this as one space where a library that manages all these protocols and provides one unified interface to access cameras would be a very significant advance.

Access to complex video devices with libcamera

andy_shev — Thu, 25 Jul 2019 22:35:12 +0000

While idea is good, I can’t get rid of picturing https://xkcd.com/927/ in my mind.