problem with ffmpeg on pi arm build

[v.f.b...@gmail.com]

Hi,

So close to having everything working now, but one last hurdle I'd like to iron out. I've built ffmpeg on the pi, enabled a few formats making sure to include libv4l2. All builds OK and this output looks good:

ffmpeg -list_formats all -f v4l2 -i /dev/video0
ffmpeg version 2.8 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.6 (Debian 4.6.3-14+rpi1)
  configuration: --arch=armel --target-os=linux --enable-gpl --enable-libv4l2 --enable-shared --enable-x11grab --enable-libopenjpeg --enable-librtmp --enable-libpulse --enable-version3 --enable-runtime-cpudetect
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :     yuv420p :   4:2:0, planar, YUV : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :     yuyv422 :  4:2:2, packed, YUYV : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :       rgb24 :           RGB24 (LE) : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Compressed:       mjpeg :                 JPEG : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Compressed:        h264 :                 H264 : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Compressed:       mjpeg :                MJPEG : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       : Unsupported :  4:2:2, packed, YVYU : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       : Unsupported :  4:2:2, packed, VYUY : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :     uyvy422 :  4:2:2, packed, UYVY : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :        nv12 :  4:2:0, planar, NV12 : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :       bgr24 :           RGB24 (BE) : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :     yuv420p :   4:2:0, planar, YVU : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       : Unsupported :  4:2:0, planar, NV21 : {16-2592, 2}x{16-1944, 2}
[video4linux2,v4l2 @ 0x1bf71d0] Raw       :        bgr0 :           RGB32 (BE) : {16-2592, 2}x{16-1944, 2}
/dev/video0: Immediate exit requested

On my ubuntu PC I don't seem to even need to call grabber.setFormat but on the Pi I get
     [java] org.bytedeco.javacv.FrameGrabber$Exception: avformat_open_input() error -1052488119: Could not open input "/dev/video0". (Has setFormat() been called?)
     [java]     at org.bytedeco.javacv.FFmpegFrameGrabber.startUnsafe(FFmpegFrameGrabber.java:432)
     [java]     at org.bytedeco.javacv.FFmpegFrameGrabber.start(FFmpegFrameGrabber.java:380)
if I haven't. So, I try grabber.setFormat("video4linux2"); (and I've tried a few variations on it too), but I get:
     [java] org.bytedeco.javacv.FrameGrabber$Exception: av_find_input_format() error: Could not find input format "video4linux2".
     [java]     at org.bytedeco.javacv.FFmpegFrameGrabber.startUnsafe(FFmpegFrameGrabber.java:404)
     [java]     at org.bytedeco.javacv.FFmpegFrameGrabber.start(FFmpegFrameGrabber.java:380)

I can't figure out if this is something to do with the ffmpeg setup I've got compiled, or somewhere else? Code works fine if I just swap back to OpenCVFrameGrabber. I wonder if I'm either missing a build step somewhere or compiled ffmpeg wrong, or some kind of format mismatch?

Any ideas?

Thanks!

[Samuel Audet]

On 10/08/2015 06:48 AM, v.f.b...@gmail.com wrote:
> I can't figure out if this is something to do with the ffmpeg setup I've
> got compiled, or somewhere else? Code works fine if I just swap back to
> OpenCVFrameGrabber. I wonder if I'm either missing a build step
> somewhere or compiled ffmpeg wrong, or some kind of format mismatch?
>
> Any ideas?

It looks like either some permission problem, or a bug in FFmpeg. Try
with the ffmpeg command line tool, with the latest version of FFmpeg,
and if that still doesn't work, please report it upstream as a bug. Thanks!

Samuel

[v.f.b...@gmail.com]

Hi,

Blast from the past on this one, have revisited this as I've been playing around with the pi camera a bit more and wanted to experiment.

Does javacpp-presets build OK normally against the latest ffmpeg? I checked out latest version, built as below:
ffmpeg version N-78309-gf862ff7 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.8 (Raspbian 4.8.2-21~rpi3rpi1)
  configuration: --enable-libfreetype --enable-gpl --enable-nonfree --enable-libx264 --enable-libass --bindir=/usr/local/bin
  libavutil      55. 17.100 / 55. 17.100
  libavcodec     57. 24.101 / 57. 24.101
  libavformat    57. 24.100 / 57. 24.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 28.100 /  6. 28.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100

But building the ffmpeg project, I get
[ERROR] Failed to execute JavaCPP Builder: Could not parse "libavutil/audioconvert.h": File does not exist

And if I try to hack that out, I get a load of errors right at the end
[ERROR] /home/pi/javacpp-presets/ffmpeg/src/main/java/org/bytedeco/javacpp/swscale.java:[201,29] cannot find symbol
[ERROR] symbol:   class av_warn_unused_result
[ERROR] location: class org.bytedeco.javacpp.swscale

Which kinda looks like they've changed library / definitions in ffmpeg that are now out of sync with javacpp-presets? Or I'm missing something?

[Samuel Audet]

Welcome back! Unfortunately, the build script still doesn't contain a
linux-arm entry:
https://github.com/bytedeco/javacpp-presets/issues/139

If you would like to make a contribution, it would be most welcome!
Simply do something similar to what was done for OpenCV:
https://github.com/bytedeco/javacpp-presets/pull/116

Samuel

[v.f.b...@gmail.com]

OK, makes sense if it'll be useful for more people than just me.

For javacpp-presets, I've updated cppbuild.sh to build ffmpeg OK on the Pi now (the opencv kinda works, I think at the moment its setup for cross compilation rather than native on the pi? needs a small change to work but then builds fine too).

I'm missing something building javacv though - I had to hack out the dependencies on other libs in pom.xml, but even then when I try to use the built jars, I get  cannot find symbol for FFmpegFrameGrabber. I'm sure I've had that before though, maybe I just need to clean up the build and start it all off again from scratch. Also needed to update the javacv pom.xml to look for ffmpeg 2.8.5

[Samuel Audet]

Sounds good! Send a pull request when it's working! Thanks

We need to update the pom.xml file of JavaCV yes.

If we can do everything by cross compiling, I think that's better. It
takes a long time to build things on a Raspberry Pi, and it's easier for
Maven anyway if we can make builds for linux-arm the same way we can do
the ones for Android. It would also work better on a CI server. We
wouldn't need to emulate an ARM processor or anything.

Samuel

[v.f.b...@gmail.com]

Ah yeah I see the cross compile benefit then, I guess most people just want a working jar.

I'm just finishing up the pi built one, it actually looks pretty good, one weird problem, Loader.sizeof(CvContour.class); is giving a null, seems a few people had that before but I cant figure out why that would crop up now?  Loader.load(CvContour.class) gives /tmp/javacpp1121309847061/libjniopencv_core.so so it looks like its there?

Once that build works I'll slot in the cross compiled jars and test, hopefully all good then will send a pull

[v.f.b...@gmail.com]

Actually, maybe a not an issue on my side? I wonder if something broke when the openCV version changed from 3.0 to 3.1? Here's the tests I've done that make me think something is out of sync:

Checked out head of javacpp, cpp-presets and javacv, built on Ubuntu x64, and I get the same error message when calling Loader.sizeof(CvContour.class)
Checked out 1.1 versions of those libs, no error
Looks like if I just keep cpp-presets building against opencv3.0 I get a working build.

Checking the opencv.jar build, 3.0 just has:
 4622 Tue Feb 09 13:18:38 GMT 2016 org/bytedeco/javacpp/opencv_core$CvContour.class

But 3.1 has:
   759 Tue Feb 09 14:51:44 GMT 2016 org/bytedeco/javacpp/opencv_imgproc$CvContourScanner.class
  4654 Tue Feb 09 14:51:44 GMT 2016 org/bytedeco/javacpp/opencv_core$CvContour.class

But, still present in both, so I'm a bit lost why Loader.size is failing? For what its worth, the stack is
     [java] Exception in thread "main" java.lang.NullPointerException
     [java]     at org.bytedeco.javacpp.Loader.sizeof(Loader.java:757)
     [java]     at edu.bath.faceRecog.FaceRecogBSF.run(Unknown Source)
     [java]     at edu.bath.faceRecog.FaceRecogBSF.main(Unknown Source)

Though I think should be easy to reproduce just by calling Loader.sizeof(CvContour.class). Will just use opencv3.0 for the moment

[v.f.b...@gmail.com]

OK got a workaround.. with the 1.1 build, the loader.sizeof returns 128. Building 1.2-snapshot, if I hardcode that value in, by good luck it seems the lib size hasn't changed much and it works fine.

I did alot of diff's between the two builds and they look really alike from what I can see. Loader.sizeof(CvPoint.class) and Loader.sizeof(CvSeq.class) both return correct values, so its something specific to CvContour.class I guess.

I'm gonna leave it there for the moment but I guess there's something lurking that will break for me in later builds. I want to get the pi build going properly first, and then try to figure why the performance isn't so great (maybe I need to retrain the recognition, but even on my laptop things slow up loads when detecting faces, so it'll be painful on the pi).

[Samuel Audet]

Hi,

Sorry for the late reply. I found what the problem was. Fixed here:
https://github.com/bytedeco/javacpp/commit/66057e6a211346f28d28105422a3f2626dfd90bc
Basically, CvContour doesn't get used anywhere in opencv_core anymore,
so it wasn't getting lined up for the calls to sizeof(). I've added a
line so that all classes with allocators are indexed anyway. Should work
for all POD structs. :)

As for the speed, well, OpenCV isn't exactly fast for face detection,
but try to use the same parameters as in the Demo class.

Samuel

[v.f.b...@gmail.com]

Ah cool! I got the speed improved a bit too, I was still using some older 2.X openCV stuff, seems some of the newer approaches are better.

So, possibly the last question on this, I've got what I think is a cppbuild.sh working for cross compiling ffmpeg for linux-arm (so there's a opencv-linux-arm.jar and ffmpeg-linux-arm.jar), but I'm not sure how to get javacv to use this in a cross-compile way? As I'm not sure -Dplatform=linux-arm -Dplatform.compiler=arm-linux-gnueabi-g++ flags are picked up there at all? Or is the theory that you'd still build javacv on the target device?

[Samuel Audet]

On 02/13/2016 11:45 PM, v.f.b...@gmail.com wrote:
> Ah cool! I got the speed improved a bit too, I was still using some older
> 2.X openCV stuff, seems some of the newer approaches are better.
>
> So, possibly the last question on this, I've got what I think is a
> cppbuild.sh working for cross compiling ffmpeg for linux-arm (so there's a
> opencv-linux-arm.jar and ffmpeg-linux-arm.jar), but I'm not sure how to get
> javacv to use this in a cross-compile way? As I'm not sure
> -Dplatform=linux-arm -Dplatform.compiler=arm-linux-gnueabi-g++ flags are
> picked up there at all? Or is the theory that you'd still build javacv on
> the target device?

Yes the properties are picked up, but I've renamed them to
"javacpp.platform", "javacpp.platform.compiler", etc in a recent commit,
to avoid potential name clashes with other plugins.

On the target device though, it should automatically use "linux-arm" as
platform name. I'm not sure if that's possible for ARM processors with
Maven though... The solution (found in the parent pom.xml of
javacpp-presets) is pretty hackish already and it just barely works on x86.

Samuel

[v.f.b...@gmail.com]

Hm. I tried those properties for building javacv as:
mvn install -Pffmpeg -Djavacpp.platform=linux-arm -Djavacpp.platform.compiler=arm-linux-gnueabi-g++

But it still just seems to look to build an x86_64 setup.

I also tried just putting the cross compiled jars onto the Pi to test they worked at least, but I get no jniopencv_core in java.library.path. I get the feeling I really need to use the whole build from the cross compile setup maybe.

I can send a pull request for the ffmpeg cross-compile cppbuild.sh if its any help, but unfortunately I can't really test whether its actually working in this current state. The version built natively on the Pi works without any problems for what its worth. 

[Samuel Audet]

Like I said, it's a bit hackish... It's only going to work properly this
way if all of the dependencies for the javacv module are available for
that platform (which can just be empty JAR files). Obviously we can
remove dependencies from the pom.xml file to more easily experiments...

Samuel

[v.f.b...@gmail.com]

Hmm.. I just kinda wonder if its easier / more reliable to put a native build into cppbuild then instead of cross compile? Sure, its not as quick, but its maybe 2 hours to build the whole lot, rather than confusing people if hacked solutions don't always work? Or maybe add something like linux-arm-cross if people want to try that / pick up for where its got to?

For what its worth, the performance isn't that different - I get 3fps using the opencv grabber, and 4fps using ffmpeg. When doing face detection both return about 1fps (thats at 1024x768). But there might be more tweaks possible with ffmpeg I guess.

[Samuel Audet]

I'll leave it up to you which way you want to put in the build script! I
don't have a lot of experience with linux-arm platforms, so please
experiment. I welcome any contributions in that direction. I'm just very
happy to have someone actually working on it. :) But eventually, on a
build server, it will be a cross compiler...

BTW, I figured out what was wrong with the javacpp.platform property:
https://github.com/bytedeco/javacpp-presets/commit/24d9a626aa08466b22c9cd652a3da21fbe5d6a68
It should now work as expected, at least with Maven 3.3...

Samuel

[Vin Baines]

OK.. might actually be getting quite close now on the cross compiled one. If I build javacv with:

mvn install -Pffmpeg -Djavacpp.platform=linux-arm -Djavacpp.platform.compiler=arm-linux-gnueabi-g++ -Dplatform=linux-arm -Dplatform.compiler=arm-linux-gnueabi-g++ -Dmaven.test.skip=true

I get a javacv-bin.zip containing linux-arm jars for opencv and ffmpeg, and no x86_64 which is a good sign (building it on an x86_64 host).

But... I have to build it with the tests skipped, or I get:
testOpenCVFrameConverter(org.bytedeco.javacv.FrameConverterTest)  Time elapsed: 0.07 sec  <<< ERROR!
java.lang.UnsatisfiedLinkError: no jniopencv_core in java.library.path
....
Tests in error:
  FrameConverterTest.testOpenCVFrameConverter:139 » UnsatisfiedLink no jniopencv...

I was being optimistic thinking, maybe running arm .so libs on a different arch was the problem, but I get the same problem on the arm pi when trying to use these new jars:
     [java] Exception in thread "main" java.lang.UnsatisfiedLinkError: no jniopencv_core in java.library.path
     [java]     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
     [java]     at java.lang.Runtime.loadLibrary0(Runtime.java:870)

But, I can see that lib does exist:
pi@picam ~/bsf/faceRecog/dist $ jar tvf opencv-linux-arm.jar | grep jniopencv_core
1971648 Sat Feb 20 15:50:46 GMT 2016 org/bytedeco/javacpp/linux-arm/libjniopencv_core.so

For comparison, this is the version built on the pi which does work:
pi@picam ~/bsf/faceRecog/lib $ jar tvf opencv-linux-arm.jar | grep jniopencv_core
1998335 Sat Feb 13 18:41:12 GMT 2016 org/bytedeco/javacpp/linux-arm/libjniopencv_core.so

Pretty similar file size.. java.library.path is specified in my ant project, and seems to work OK for the natively built javacv.

Wondered if you've seen anything similar, or how you think the javacv build step should be done?

Seems pretty close though!!

[v.f.b...@gmail.com]

Actually.. might be something to do with the floating point - think the pi is expecting hard float compiled with arm-linux-gnueabihf , but then I'm getting some other errors I need to figure out

[v.f.b...@gmail.com]

Nearly there. Put in a pull request for the 1st half, updating javacpp with a linux-armhf platform and a quick way of detecting it, works at least on pi2 with oracle sdk, might not get the same result with openjdk but I think its fail-safe anyway. Hope that looks OK to you. I just don't want to mess up any existing users of linux-arm stuff with different build flags.

Have a cross compiled build working from my dev machine, but when trying it on a clean build machine I'm getting an error I thought I'd fixed, so the pull request for javacpp-presets is still coming.

Also had to remove the dependencies in javacv pom.xml for the other (non ffmpeg,opencv) libs. But after that, it built ok on an ubuntu x86_64 host for a linux-armhf pi2 target, same performance as the native built version but builds in about 10 minutes rather than 2-3 hours.

[v.f.b...@gmail.com]

OK pull request in for cpp-presets too. Was missing pkg-config on my clean build setup. Apart from the issue of missing dependencies in javacv pom.xml it all builds fine now

[Samuel Audet]

Hi,

Sorry for the late reply, but thanks a lot for the pull requests! It
looks great, and as you know, I've merged them in.

As for the missing dependencies, the best way I've found to deal with
this in Maven is to prepare empty artifacts. Like, videoinput isn't
available on either Linux or OS X, but there are (empty)
videoinput-linux-x86_64.jar and videoinput-macosx-x86_64.jar artifacts.

To achieve that, we can, for example, make sure that "linux-arm" isn't
listed in `@Platform(value=...)` or is listed in `@Platform(not=...)` of
the presets, and then we usually get a successful build with zero files.

Samuel

[v.f.b...@gmail.com]

Is that in the java code of individual projects? e.g. for flycapture, ./org/bytedeco/javacpp/presets/FlyCapture2.java - if so is it just one per project, and those are the def's I'd need to change? Would be nice to get it building cleanly all the way through, would open up the door to CI check-in to Maven I think.

Pi 3 was just released today too, 1.2ghz quad core and 64bit now, could be a very interesting platform as I was getting about 4fps on the pi2, at a guess of performance increase of 2.5x the pi2 its getting pretty close to a more realtime (well, 15fps) image processing. Looks like I need to setup another build config :)

[Samuel Audet]

Yes, it's just one file or two sometimes.

2016/02/29 18:21 <v.f.b...@gmail.com>:

--

---
You received this message because you are subscribed to the Google Groups "javacv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javacv+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v.f.b...@gmail.com]

Getting close to having everything sorted now - I guess last step would be to have the compiled jars added into Maven automatically once the build is complete.

I'm sure you mentioned about it but I can't find it anywhere, what should I do for that, some permissions for a maven account needed?

[Samuel Audet]

You first need to create a JIRA account as explained here:
http://central.sonatype.org/pages/ossrh-guide.html

And then let me know the name of your account, and we'll be able to give you access to upload new binaries :) Thanks!

Samuel

2016/03/07 19:17 <v.f.b...@gmail.com>:

[v.f.b...@gmail.com]

OK think thats done - username is vinnieb

Planning on changing the build to be generic arm6 at the moment, which should mean it'll run across all Pi devices.

I had a quick look at the repository, you just upload main releases right, no snapshots? So for the next tag we should be good to upload arm6 libs hopefully! One thing I'm not clear on too but meant to check/test, you upload a big 100+mb release with all the jars for multiple platforms.. how should I work the arm ones, just add specific platform jars for say opencv and ffmpeg, and they'd be picked up OK by your build? Or some other approach?

[v.f.b...@gmail.com]

Euff.. sorry one more.. I'm not having much luck with squashing, I seem to be going round in circles. At https://github.com/bytedeco/javacpp-presets/compare/master...vb216:master I seem to have made one squashed commit eventually, (https://github.com/bytedeco/javacpp-presets/commit/fcb9ee12d40dd45a0b02cbbfbec9df6866aac158) which has got the pom changes taken out, flycapture compiling fine, and what I think should be better arm6 settings that might work on pi1/pi zero as well as pi2/pi3. But, I can't figure how to pull request just that commit?

On Tuesday, 8 March 2016 09:45:19 UTC, Samuel Audet wrote:

[Samuel Audet]

Great! I sent a request to give you permission to deploy new artifacts:
https://issues.sonatype.org/browse/OSSRH-21140

I and others upload SNAPSHOTs sometimes, yes, they are here:
https://oss.sonatype.org/content/repositories/snapshots/org/bytedeco/

So, please start by uploading SNAPSHOTs any time you want: We can delete
those if you make a mistake. :) We cannot delete releases.

I've been providing a large archive containing everything for the
benefit of users that prefer to install JAR files manually. But it
doesn't need to be released exactly as the same time as the artifacts,
so on a new release you can upload your builds, and when everything is
in place, we can create the ZIP archive from my builds + your builds.

But eventually, I'd like to have a couple of build servers running that
do everything automatically :)

Samuel

[Samuel Audet]

Oh, wait a minute, you didn't create your pull request from a branch. So
you're going to need to find the last commit from the main repo, (check
"git log"), and do a "git reset sha-of-that-commit". Then your pull
request should show no commits at all, and you will be free to make new
commits, or not, as you wish. :)

Samuel

[v.f.b...@gmail.com]

Awesome, that looks better now. I'll do a couple more checks when the commit looks OK to you/is in,  and then try to get the builds uploaded :)

[v.f.b...@gmail.com]

Latest pull requests for javacpp and javacpp-presets have been tested on pi1 using arm6 and pi3 on arm7. There's a noticeable drop off in frame rate, this new build runs at about 3 frames a second using either ffmpeg or opencv grabber, compared to the arm7 build that would get around 6 frames a second. But, I thought it'd be a nice start to get a generic pi build in and working, then look at tweaks on the compile later. I don't want to pollute the build files with too much stuff, but the only way I can currently think of doing it is dropping the linux-armhf and replace with linux-armv6 and linux-armv7 ? Then its down to the user to get the right libs. But seems worth it for 2x performance improvement (possibly more with better flags for the pi3).

[Samuel Audet]

You have a pull request here so let's continue the discussion there:
https://github.com/bytedeco/javacpp/pull/91

[Tobias B]

Has this been solved? I still get this ecxeption when trying to connect to the raspberry pi camera with the FFmpegFrameGrabber: 

org.bytedeco.javacv.FFmpegFrameGrabber$Exception: avformat_open_input() error -16: Could not open input "/dev/video0". (Has setFormat() been called?) (For more details, make sure FFmpegLogCallback.set() has been called.)

[Samuel Audet]

Yes, that works now. Errno 16 means there's some issue with the kernel or your hardware. It's not a problem with your application.

Samuel

--

---
You received this message because you are subscribed to the Google Groups "javacv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javacv+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/javacv/fa996120-5807-4c57-b11e-ec58101fe5ffn%40googlegroups.com.

[Tobias B]

It is a fresh installation of raspbian buster on a raspberry pi 3b. The camera works fine. I don't think there's any hardware error. Also the application is just the sample application from https://github.com/bytedeco/javacv

The only change I made was replacing 

FrameGrabber grabber = FrameGrabber.createDefault(0);

with

FrameGrabber grabber = FFmpegFrameGrabber.createDefault("/dev/video0");

I also tried adding

grabber.setFormat("video4linux2");

Nothing worked.. Do I need to install anything additionally on the raspbi? I just took a big jar (about 800mb) that was generated by including the gradle dependency.

[Samuel Audet]

Well, we also need to make sure we're trying to capture in a resolution and pixel format supported by the camera.

We can easily check this information using the ffmpeg program:

https://trac.ffmpeg.org/wiki/Capture/Webcam