Processing, raspberry pi and camera

Processing for Pi
1

Hi everyone,

For my project on building a universal ambilight system, I need to access the data from a camera plug into my raspberry Pi.

at first I couldn’t even find a camera from processing with the video library so I looked for answers and found this command line:
sudo modprobe bcm2835-v4l2

Now processing is insulting me with that warning message:
No such Gstreamer factory: v4l2src

After more digging, I found out that 2 experimental libraries exist (on this page) and can fix the problem :

Before trying one of those solutions, since they are experimental, I would like to know if one of you would know a way to make it work with the official library?

Thanks :slight_smile:

2

Hi @jb4x,

See here about your v4l2src error: https://pi.processing.org/technical/#video-library-capture

The GL Video library was specifically written for the Raspberry Pi - you find it in the Processing Contribution Manager. Apart from this, there is also the current release of the “official” Video library, which I believe you are trying out right now, and an experimental pre-release version, which uses a much more modern GStreamer version - both developed by Andres.

1 Like
3

Thank you for your reply @gohai!

I followed the instructions of your link and try to execute this commande:
sudo aptitude install gstreamer0.10-plugins-good

Sadly, it’s back to were I was at the beginning: no camera found :frowning:

I think I’ll try your library, I did not see it was available from the library manager of processing. And it seems that it works almost the same as the “official” video library so I should not have big changes in my code (hopefully :smiley:).

Thanks again, and I’ll let you know how it goes :slight_smile:

4

A noteworthy feature that hasn’t been mirrored is the lacking of callbacks like movieEvent(). :disappointed:

Although both lack some kinda eosEvent() callback! :roll_eyes:

5

I remember you bringing this up before @GoToLoop - remind me: why would you want to use movieEvent?

6

@gohai, I don’t think it was me, I don’t need any movieEvent() callback for my use.

The most similar subect I opened I can think of is when I asked how to link a function to the press event of a button (of the controlP5 library) located in another class:

7

Sorry, this was indeed meant to go to @GoToLoop.

8

No problem :slight_smile:

9

I don’t like to have a boilerplate in draw() checking over & over whether a new frame is available() in order to call read(). :nauseated_face:

It also wastes CPU time on the main “Animation” Thread. Better leave that to Movie’s Thread. :wink:

Also lotsa Processing 3rd-party libraries got reflection callbacks, even official 1s like Serial & Net: :cowboy_hat_face:

  1. Serial / Libraries / Processing.org
  2. Network / Libraries / Processing.org

Given GL Video is a custom version of the Video library, the reflection callback code is pretty easy to port! :grinning:

As I had already mentioned, the Video library sorely lacks an EoS callback. :mask:

I’ve made a sketch which @Override the Movie::eosEvent() method so it calls back a sketch’s function: :clown_face:

But it’d be much nicer to have that feature builtin rather than relying on some hack! :robot:

10

@gohai,

I tried out your library on my raspberry with the simpleCapture exemple you have provided but I’m getting hard times displaying the camera feed.

I updated the /etc/modules file and after reboot, I can see the camera device as /dev/video0. So everything should be setup correctly.

When I run the sketch, the camera is found, the light of the camera turned on, but the render window stays black.

Any idea from where it can come from?

11

@GoToLoop The issue with callbacks is that you’re only allowed to draw to the screen during certain periods of the frame cycle. When you attempt to do so outside when you’re supposed to do so the sketch will generally crash. This is why I don’t do a MovieEvent - because it is safer to do so inside draw, and folks will most likely want to do some compositing (additional drawing) anyhow.

1 Like
12

@jb4x That’s odd. Are you using our modified Raspbian image? Did you perhaps change the graphics driver setting (away from the default “Legacy”)?

13

A feature should not be withheld just b/c it would be misused somehow! :speak_no_evil:

A callback isn’t a place to do heavy stuff after all; merely to reckon it’s happened. :flushed:

It is well known that we shouldn’t mutate the sketch’s canvas outside its “Animation Thread”. :warning:

Even though you’re “protecting” us from the “Animation Thread” crash in your custom GL Video library, folks are still gonna learn that from the other Processing 3rd-party libraries; so it’s moot!

14

I’ll re-install the rasbian image (I’ll take the one on pi.processing.org), cleanly re-do everything and see how it goes. I’ll let you know!

1 Like
15

@GoToLoop If you’re unable to draw in the callback, but merely set a flag, and act upon it in a future invocation of draw - how is this “better” than just directly checking available() inside draw and acting upon that?

I want users, especially beginners, to have a rewarding time using this library. I am not convinced that everyone would know about the concept of the “Animation Thread”, or what is - and what isn’t - a reasonable thing to do inside a callback handler.

And since I don’t see a real upside, I rather prevent people from shooting themselves in the foot with the tools I build. (But it’s open source, so you are of course welcome to build upon my work and prove me wrong.)

1 Like
16

Already gave the reason for that: :pouting_man:

I just find this:

void draw() {
  set(0, 0, myMovie);
}

void movieEvent(final Movie m) {
  m.read();
}

Better & cleaner than this:

void draw() {
  if (!myMovie.available())  return;
  myMovie.read();
  set(0, 0, myMovie);
}

Given movieEvent() is 100% optional, that’s no excuse to have it removed when you forked GL Video from the Video library!

And again, threaded callbacks exist everywhere in Processing’s 3rd-party lib ecosystem.

Given the Video library got that feature already, it’s pointless to fork yours just to put the callbacks back! :wink:

17

Just because something exists elsewhere doesn’t mean you have to copy it, if you think it is wrong. Please be considerate in the language you use, I don’t think I need to explain (or excuse) myself for any code I write or publish.

void movieEvent(final Movie m) {
  m.read();
  draw(m, 0, 0);
}

What would prevent someone from doing that (and have it explode at the least convenient time)?

Anyway, I think we’ve circled this issue enough here.

1 Like
18

Ok, so…

I re-installed raspbian using the image provided by pi.processing.org and I check that I was not using the KMS OpenGL driver but I still have the same problem: when I run the basic sketch, the camera is found, apparently it is turned on since I can see the LED but no image is displayed…

Can it be a power supply issue? I’m feeding the Pi with a 5.0V 2.1A and I know it should be 2.5A… ?

19

@jb4x Sorry, I don’t know what’s going on then. I’ll have to get my camera from the studio and test.

20

Is there a way to pass custom pipelines into either of these libraries? IIRC there’s a specific GStreamer element for the Pi camera. Might be worth trying

@GoToLoop the callback is actually a really bad part of the video API anyway, complicates things and reduces the possibility for performance improvements. I tried to replicate the API in PraxisLIVE and gave up for another mechanism - it doesn’t map well to the underlying library IMO.