Play video controlling speed and direction



I would like to use a Raspberry Pi 3 for an video interactive installation. I would to control the speed, and the playing direction ( backward, forward ).
I am using 720p video, and i would like to obtain 100 image / sec both way.

I used before an macbook pro, in which I made an ofApp, with a simple ofVideoPlayer, using setPaused(), nextFrame() and previousFrame(). It was working good, even with a really high video framerate.

But now this is the raspberry pi.
With ofxOMXVideoPlayer, I can obtain 100 frame/sec but only forward. The ofxOMXPlayerEngine contain a rewind function, but doesn’t seems to work.

The native ofVideoPlayer, this is worst, the app go down to 20fps, just reading the video with a normal speed, and decrease extremely fast when a try to change ofVideoPlayer.setSpeed().
Even the function nextFrame() and previousFrame() are not really working. I am using ofVideoPlayer.setPixelFormat(OF_PIXELS_NATIVE) already.

I try also to change the video memory from 128 to 256.

Do you think the raspberry is able to do it ?


The add-on ofxOmxplayer is really the way to go if you want to have fast video, but it does not seem to support backward step as it does for forward step.

The source Omxplayer support a function called setposition which refer to the absolute frame of the video, but this function does not seem’s to be implemented (or documented) in the ofxOMXplayer.

Did you try to input a negative value in the stepFrame function to go backward?

Maybe one way would be to use the seekToTimeInSeconds function.


Hi gllmar and everybody’s around

ofxOMXplayer::stepFrame( int ) doesn’t accept negative value
ofxOMXplayer::seekToTimeInSeconds( int ) is actually creating a new instance of the player, and read the video from this starting point. But the video can’t be paused to have an effective effect. Plus, re-creating an instance of the player is a freezing operation, and doesn’t allow to have a real time application.

I am thinking of loading image/texture on GPU, instead of loading a video. Then show the images one by one, in the order i want. Does it seems ok ?


It is I think a really good idea. but you will lose the GPU decoding so 720p at 100 fps won’t be easy.

Starting with the example/graphic/imageSequenceExample

You will face the problem that the raspberry pi does not have enough ram to allocate a lot of video frame. The example load all the images in the data/plops folder and those image a really small. Try this example with a small bunch of images from your source to find out the fps and the limits of the Pi.

Then it would be rational to implement dynamic loading of the images on another thread from the add-on ofxThreadedImageLoader
in the folder examples/addons/threadedImageLoaderExample

this way, your main thread won’t get stuck with the loading of the images that will happen in background.

You’ll probably have to remove the farthest images of the memory if you don’t want the pi to crash.

there is a thread in the openframeworks forum about this subject, here it is maybe it help.


Maybe I’m wrong, but why use omxplayer, when GStreamer manage the openmax chip ( hardware decoding)?

You can directly use ofVideoPlayer


Using ofVideoPlayer even if it is supposed to be openmax enabled is really really slow on RPI.
OfxOMXplayer still get better performances, not clear why…


Apparently The installation is include in the

I should try ofomxplayer, but it is heavy to compilate.


I am having exactly the same problem.
One possible solution I am considering is having two videos
one is the normal version the other is reversed,
then I can decide which one plays and I can control the speed,
then when I need to play reversed I would find which frame I am in,
move the reversed video to the right frame (total frames - forward video curr. frame)
switch to the other video
the problem with ofxOMXPlayer is that I have not found a way to just jump to a specific frame.
seekToTimeInSeconds does not help because it reloads the whole movie (which would not be so terrible) but also messes up looping for some reasons I still have to understand.

Has anybody had better luck?


Playing backward a h264 will probably kill your FPS since it is time based compression.

The 2 videos approach seem’s like a good way to go if h264 is selected.

I’ve recently tested the native ofVideoPlayer on the raspberry pi and managed to get a decent frame rate (similar to omxplayer) by applying what is written in this post

with these ifdef, it also compile on Xcode so I can prototype on my laptop and deploy on the raspberry pi.

in main.cpp

#include "ofMain.h"
#include "ofApp.h"

int main( ){

 //   ofRunApp(new ofApp);
    // <-------- setup the GL context

    //Apply these GL settings for raspberry pi
    ofGLESWindowSettings settings;
    // this kicks off the running of my app
	// pass in width and height too:
	ofRunApp(new ofApp());


in my setup function (where videoPlayer is a ofVideoPlayer instance) :

// no YUV-RGB cpu bounded conversion on the pi

The key here is to use the programable renderer to bypass a YUV to RGB conversion that was happening on the cpu.
This way, a shader kicks in and does that job on the gpu.

I use Arch on the raspberry pi, I don’t know if raspbian has the required version of gstreamer.
arch on raspberry pi ->

Hope it helps

Include ofxOMXPlayer on Raspberry Pi, not on regular Linux, addons.make

very interesting glimar, thanks a lot, will take a look at it!


The two videos solution sounds nice actually, I am just afraid of the “jumping” part, which can be long and freezing the entire app.
I finally used ofxImageSequence, which works really well and really fluid, on the Pi. The limitation is the RAM … about 1000 images in HD720, so about 41sec of real vid :frowning:


Hi conila, interesting. Yes I am afraid of the jump, I will try this week and see what happens.
In your solution did you do any further loading and unloading on the sequence or did you just stick with a 41 seconds animation?
Is you code on github? I would be interested in having a look at it.



Hi Sergio
in ofxImageSequence, you have a function :
which allows you to load jpeg files from a separate thread, and this works pretty well ( in my memories ).
Here is my repo
In which, you have

  • ImageSeqFromOsc ( directly changed from ofxImageSequence example )

  • ( read serial from Arduino and send OSC message to ImageSeqFromOsc

  • Arduino, with the arduino sketch.