Processing on Raspberry Pi (video)

tomj

we're working on configuring the Pi (raspbian linux) as an embedded media player, with Arduino to handle the bit-fiddling stuff (switches sensors pots etc). have Processing installed and running OK. we have two Pi test machines, each is having a different video problem. i'm an experienced programmer and linux geek.

i have two test videos, one MP4 and one .MOV, both play fine on the Pi using omxplayer, command line or within an xterm in blackbox (X window manager).

however, the simple play-video sketch (below) fails, on machine #1 with errors below. i suspect this is a video format/codec issue; how does Processing decode video? where are the codecs? are MP4 and (MOV is suspect) good choices? I assumed that MPEG4 would be the format of choice (tl;dnr MPEG4 codec on raspbian) but maybe not. as i type this i increasingly assume the problem is my lack of knowledge on how Processing decodes video....

VIDEO PLAYER TEST CODE

import processing.video.*;
Movie M;

void setup() {
  size(640, 480);
  M= new Movie(this, "/home/pi/TEST.MOV");  
  M.loop();
}

void draw() {
  M.read();
  image (M, 0, 0);
}

ERRORS...

in debug window and shell stderr or stdout:

Listening for transport dt_socket at address: 8305
A library relies on native code that's not available.
Or only works properly when the sketch is run as a 64-bit  application.

in the Processing application's brown frame:

A library used by this sketch is not installed properly.

highlighting the line containing "new Movie (this, "

i get the same results with test.mp4 and TEST.MOV.

used this to install processing: http://cagewebdev.com/index.php/raspberry-pi-running-processing-on-your-raspi/

codeanticode

Processing uses gstreamer for video playback, is gstreamer installed on raspbian linux?

joshbailz

How is processing running on the pi? i got it working but it was very very slow........

tomj

joshbailz: oh, it's slow. i'm an old *nix user and found the default raspbian window manager appallingly slow, so i wiped and reinstalled minus the default graphical system, then added xorg and blackbox [window manager] which is much lighter-load. the "desktop" paradigm is totally inappropriate for the Pi; too too top-heavy. with blackbox on X -- the Pi is like *nix computing ca. 1996!

anyway. codeanticode: i never bothered to learn how Processing did media (i'm a hardware and system person) but obviously i need to figure it out. i'll install gstreamer (and rtfm) thanks for the hint.

tomj

(i take it back re: 1996. my 1993 floppy-compiled, 486DX, 2MB RAM, 386/BSD *nix machine was vastly faster than the Pi.)

i got gstreamer and alsa up and working, so now gst123 will play mp4 video from an xterm. however, it only displays a dozen or so frames, eg. severe "stutter" over the 30 second video duration. clearly not acceptable. (omxplayer has no such problem). this could be config etc still so i'm not [fatally] worried about this yet.

but none of this affects the java video codec issue that Processing has. i did some half-fast apt-cache searches but it looks like i will have to [GASP] actually do some research on how video in Processing works.

tomj

http://wiki.processing.org/w/Video_Issues

sadly, no official news.

scruss

tomj, are you running the Oracle JVM? It makes a huge difference to the speed of Processing on the Raspberry Pi:

sudo apt-get install oracle-java7-jdk

codeanticode

hi, in order to have good playback performance with gstreamer on the raspberry pi seems that you have to install the gst-omx module, that takes advantage of hardware acceleration for the decoding:

http://wiki.matthiasbock.net/index.php/Hardware-accelerated_video_playback_on_the_Raspberry_Pi

About how video in Processing works, as I mentioned it relies on gstreamer for playing movie files and grabbing frames from capture devices. Because gstreamer is a native library written in C, Processing uses a Java binding to be able to call to gstreamer.

metehanemlik

what is a problem? How do I resolve ?

A library relies on native code that's not available.
Or only works properly when the sketch is run as a 64-bit  application.