macOS M1: Issues loading BridJ in webcam-capture even though webcam-capture-driver-native doesn't need it.

[msgilligan]

See:

• Remove WebcamDefaultDriver from core webcam-capture module. sarxos/webcam-capture#888
• macOS M1: current master branch fails trying to load BridJ. sarxos/webcam-capture#889

This is an upstream issue, but I thought it would be helpful to note it here. (We should push for sarxos/webcam-capture#888 upstream and/or create a fork)

[eduramiba]

It's strange, I did not find any problem with Bridj given that the correct driver is set up very early in the program. But I agree with the 2 referenced issues, no default driver should be bundled with the core jar. And bridj should be removed altogether.

[msgilligan]

Even setting the driver very early there was a call to BridJ to determine the OS which was causing a failure at class initialization time due to no aarch64 native lib for Mac.

[eduramiba]

Oh I see, thanks for sharing that information! I could only test it with Intel x64 Mac

[eduramiba]

It will be difficult to introduce changes to https://github.com/sarxos/webcam-capture, maybe I can have a fork and create a pull request until they accept the changes.

[msgilligan]

Yes, I made a fork of sarxos (and BridJ) a few years ago. I'm planning on updating it.

[eduramiba]

I removed the default driver, bridj, bundled natives and many things from my fork in order to use it for my app without problems. You might find it useful.

I was looking at the code of webcam-capture but I was surprised by how many things it does. Not sure at this point if it's better to update the library or create a new very lightweight library that does only the fundamentals:

• Simple abstraction to support different drivers for different OS (only good linux support missing with my driver).
• List devices with their supported formats.
• Grab frames from devices as BufferedImage or ByteBuffer + update FXImage.

Everything else looks unnecessary. Maybe a way to notify connected/disconnected cameras. But that's it.

Also, there should be no reason to use OpenCV driver, for example, or any other driver, now that we have drivers that use OS native APIs. Actually I created them because I found out that none of the drivers reported a correct list of supported resolutions, device ids or worked correctly and with acceptable performance.

Maybe the raspberry pi one is necessary too.

[msgilligan]

I removed the default driver, bridj, bundled natives and many things from my fork in order to use it for my app without problems. You might find it useful.

I will check it out!

Not sure at this point if it's better to update the library or create a new very lightweight library

That'a a good question.

Also, there should be no reason to use OpenCV driver, for example, or any other driver,

I'm not sure what the use cases are, but there might be some.

Maybe the raspberry pi one is necessary too.

sarxos/webcam-capture has 2.1k stars and 1.1k forks on Github. Although it's getting out-of-date and is seemingly under-maintained, it remains very popular. My thoughts are that we should submit patches to it and see if they are accepted while also providing an updated fork as an alternative until the patches are merged.

Even if we decide to create a "new very lightweight library", it might be a good idea to make it API compatible with (or with easy migration from) sarxos/webcam-capture.

@johanvos what do you think?

[msgilligan]

I took a quick look at the fork and I noticed you deleted the entire webcam-capture-drivers folder/subproject.

I see the reasons for doing this:

1. The drivers are not needed if using your new native drivers (unless Linux or maybe Raspberry Pi is needed)
2. Maintaining just the build (let alone managing bug reports, pull-requests, etc) for the drivers is a significant effort.
3. Even with a working build, pulling all the dependencies for the drivers, and doing a full compile slows things down.

However, all we really need is for the dependencies/binaries for BridJ and IMAJ to be removed from the core webcam-capture module. And, if we decide to merge upstream leaving the webcam-capture-drivers might be what is preferred by the existing maintainers and community.

So the answer to whether to remove the webcam-capture-drivers is related to the question of whether this is going to be a permanent fork or a new project, or whether this is something that can be accepted and maintained upstream.

[eduramiba]

For the moment I was only making it work for my app, I agree that a proper fix for the upstream should not remove as many things, at least in a first PR

[johanvos]

@johanvos what do you think?

I would still separate the drivers from the processing. I am personally mainly interested in the drivers itself, which are typically small files with C-code, but then with a Java API (which should only need 2 or 3 methods imho).
If I understand it correctly, the drivers are in this repository as binaries, but it would be good to see how they are built. And then I would separate the Java driver (with the 2 or 3 methods) from everything else. Most of the (pre-)processing part can be done in a number of different ways, and for developers who need just the Java driver (and native implementations), a 10K jar is probably more convenient than a larger lib with dependencies.
On the other hand, people who want much more functionality can benefit from all what's in here, and that is great. But by separating it, you give users the choice.

[eduramiba]

I just released version 1.1.0, which reduces dependencies and eventually will use the same driver for all OS (Mac still not stable in the new backend: https://github.com/eduramiba/lib-cnokhwa)
Also, the artifact is available with a classifier (without-natives) that does not package the natives in the jar.