Raspberry PI + OLA_trigger + OMXPLayer ( DMX controlled video player )

[Andrew Frazer]

its a bit of a gooey mess, but it works..

Unforutnatly it doesn't work well.. OMXPlayer takes way too long to get "started" and its not consistent in how long it takes to get started either, so you can't even sent a premptive command.

Problem is not with OLA_trigger, just running omxplayer from the command line you can see the lag.

Any care to suggest a better media engine for the pi..

NB, this will be a great thing to add into our little OLA hardware trick..

[ewan colsell]

You need a player that can load the file into memory then start playing instantly when you press play.

You could look at freej,  which is a vj program for Linux.  I didn't use it for years though and I don't know if it's. Still maintained.

I think we would all like a gpl substitute for arkaos, whatchout etc.

Ewan.

--
open-l...@googlegroups.com  /  http://groups.google.com/group/open-lighting
To unsubscribe email open-lightin...@googlegroups.com

[Andrew Frazer]

well, what do you know.. Its still maintained, and theres even a port for debian.. 

[Santi]

Hi,

i'm developing an GPL Media Server now. I have implemented the MSEX
layer and now i can see the thumbnails in the MagicQ. The input of
lighting data is through OLA daemon and the grafic motor is with Pure
Data executing in background. It has a very simple GUI in Qt... The
svn version is working now, but buggy and the doc is in spanish only
at the moment. The packaged version 0.0.4 works, but without the GUI
and the MSEX. I've tried it in Ubuntu 12.04 Precise y Debian Wheezy.
Unfortunately, the full version takes a lot of resources.

http://code.google.com/p/puremediaserver/

The external wich comunicate with olad it's based in the flext headers
(http://grrrr.org/research/software/flext/), so it should compile for
the rapsberry, at least one external based in flext is reported
compiling and working fine. There are Pure Data debs for Rapsberry. I
can strip down the patch of pure data and let the minimal to optimize
resources if you want, and help with pure data, but i can not help
with the raps side.

The external compiled for Wheezy:

code.google.com/p/puremediaserver/downloads/detail?name=ola2pd_0.0.1.tar.gz

The sources are in:

svn checkout http://puremediaserver.googlecode.com/svn/trunk/externals/ola2pd
puremediaserver-read-only

Let me know if you like the Pure Data option.

Santi.

[Peter Stuge]

Andrew Frazer wrote:
> Unforutnatly it doesn't work well.. OMXPlayer takes way too long to get
> "started" and its not consistent in how long it takes to get started
> either, so you can't even sent a premptive command.

mplayer used to have a side channel for remote control. I've used
that in some setups, years ago.

VLC might be another good candidate for an engine which can be remote
controlled with little effort.

When doing pro video I always used DV and 1394 or SDI output, which
is of course much more lightweight than compressed formats.


//Peter

[ewan colsell]

Jaromil, the fantastic guy who wrote freej has been working on a really fantastic project called syncstarter. which may be relevant to what you want to do.

http://syncstarter.org/intro/

p.s. i'm checking out the latest version of freej right now.

ewan.

--
open-l...@googlegroups.com  /  http://groups.google.com/group/open-lighting
To unsubscribe email open-lightin...@googlegroups.com

--
http://www.ewancolsell.com/

[Lorenzo Fattori]

i'm also looking for something similar... controlling video with artnet (with my Chamsys) and play them with RPI connected to video projector...

[Andrew Frazer]

Ok, folks with a bit of messing and some help from Simon, i got a bit of a solution up and running that works well enough, its just a little untidy right now, but i'm sure can be tidied up.

Essentially i have a raspberry PI with the OLA install on it.    

- Updated to the latest builds (apt-get update etc )

- installed omxplayer ( the ola build was missing this but the current raspbian has it i understand )

This is what I needed to do; 

(1) Created a Fifo bufffer

mkfifo /tmp/cmd

(2) Created a tiny shell script to send "keystrokes" to omxplayer, via a redirect to the FIFO above.  We have to do this because the OLAtrigger configuration doe'snt allow the redirects

ola@raspberrypi ~ $ more control 

echo -n p > /tmp/cmd

(3) Set up a configuration for OLA_Trigger, like this..  This ones *very* simple you almost certainly want something more complex, but this is an example...

1   100 `/home/ola/control`

When channel 1, is value 100,  OLA_Trigger, will call the shell script  control….   

(3) Set up Universe 1 in OLA, so, it was receiving data via Art-net  and start OLA_Trigger

ola_trigger -u 1 triigger.conf

(4) I then stated omxplayer;

omxplayer -ohdmi mymedia.avi < /tmp/cmd       

The -o hdmi is so that audio goes out the hdmi port..   What will happen is omxplayer will sit and wait when you do this.. Think of it as a "load the tape".. 

When channel 1, on universe 1, is value 100,  ola_trigger starts things off, and a 'p' gets sent to omxplayer.. This is like a play pause cue.   Next time it gets a play command, it will almost instantaenolys start playing..

When the value hits 100 again,  ola_trigger will again send a 'p', and the media starts to play..

Initial tests are showing that its accurate enough to keep video in sync within a frame and for my application thats all ok…

I need to write this up into the wiki..  and make the entire thing a wee bit more user-friendly..  

[Peter Stuge]

Andrew Frazer wrote:
> (4) I then stated omxplayer;
>
> omxplayer -ohdmi mymedia.avi < /tmp/cmd
>
> The -o hdmi is so that audio goes out the hdmi port.. What will
> happen is omxplayer will sit and wait when you do this.. Think of
> it as a "load the tape"..

When you use a fifo like this the open() system call on the reading
end (bash does that before it executes omxplayer) blocks, until the
fifo has also been opened for writing, which your trigger script
does.

So the setup is in fact equivalent to just having the trigger script
start omxplayer.

You can verify this by giving the command to start omxplayer as above
and before running the trigger executing the following in a separate
SSH session into the system:

pidof omxplayer

I expect it to return empty output, meaning that no omxplayer exists
at that time.


Also, when the trigger script echo command has written "p\n" it
exits, and bash running the trigger script then closes the fifo,
which also closes the reading end of the fifo. So you can never
send more than one command to omxplayer.

I suggest rethinking this solution to make it reliable.

One way is to make a plugin(?) in olad which is aware of how fifos
function and can interact with them more correctly.

Another is a plugin which starts, monitors, and controls
subprocesses, so that omxplayer is started and controlled directly by
olad.

Another is to make a separate program to start, monitor, and control
subprocesses from outside olad, and which has a better remote control
facility than a fifo, which can then either be used by triggers or
preferably by a plugin.

In general you want to avoid any and all process creation because it
takes unneccessary time. It's nowhere near as catastrophically slow
as on Windows, but it can still be noticeable, and it's just
unneccessarily bad quality if you are doing anything synchronized.


//Peter

[Andrew Frazer]

Sorry Peter, this went way over my head. From what i've tested so far the method suggested gives
satisfactory results and i video consistently synced up..

>

> When you use a fifo like this the open() system call on the reading
> end (bash does that before it executes omxplayer) blocks, until the
> fifo has also been opened for writing, which your trigger script
> does.
>



> So the setup is in fact equivalent to just having the trigger script
> start omxplayer.
>
> You can verify this by giving the command to start omxplayer as above
> and before running the trigger executing the following in a separate
> SSH session into the system:
>


> pidof omxplayer
>

I'm not sure what 'pidof' is? I did check however and there are no omxplayer process's running at this point

> I expect it to return empty output, meaning that no omxplayer exists
> at that time.


> Also, when the trigger script echo command has written "p\n" it
> exits, and bash running the trigger script then closes the fifo,
> which also closes the reading end of the fifo. So you can never
> send more than one command to omxplayer.
>

Currnetly i can send multiple commands one after another and it works as expected. The ability to do this is pretty important as well. you might want to stop/start/pause/rewind, slow down etc etc..

> I suggest rethinking this solution to make it reliable.

> One way is to make a plugin(?) in olad which is aware of how fifos
> function and can interact with them more correctly.
>
> Another is a plugin which starts, monitors, and controls
> subprocesses, so that omxplayer is started and controlled directly by
> olad.
>


> Another is to make a separate program to start, monitor, and control
> subprocesses from outside olad, and which has a better remote control
> facility than a fifo, which can then either be used by triggers or
> preferably by a plugin.
>
> In general you want to avoid any and all process creation because it
> takes unneccessary time. It's nowhere near as catastrophically slow
> as on Windows, but it can still be noticeable, and it's just
> unneccessarily bad quality if you are doing anything synchronized.
>
>
> //Peter
>

[Peter Stuge]

Andrew Frazer wrote:
> Sorry Peter, this went way over my head.

I'm happy to clarify.

> From what i've tested so far the method suggested gives
> satisfactory results and i video consistently synced up..

Well I guess all is good then. :)

> > So the setup is in fact equivalent to just having the trigger script
> > start omxplayer.
> >
> > You can verify this by giving the command to start omxplayer as above
> > and before running the trigger executing the following in a separate
> > SSH session into the system:
> >
> > pidof omxplayer
>
> I'm not sure what 'pidof' is?

pidof is a command to print process ids for processes with the given name.

> I did check however and there are no omxplayer process's running at
> this point

Right, omxplayer starts only while the trigger script executes,
causing much more delay.

> > Also, when the trigger script echo command has written "p\n" it
> > exits, and bash running the trigger script then closes the fifo,
> > which also closes the reading end of the fifo. So you can never
> > send more than one command to omxplayer.
>
> Currnetly i can send multiple commands one after another and it
> works as expected.

That's surprising; the fifo closes once the first command has gone
through it, so omxplayer can't really read more than one command..

I wonder what is going on.

> The ability to do this is pretty important as well. you might want
> to stop/start/pause/rewind, slow down etc etc..

Exactly - that's why I think a more reliable solution would be really
good.


//Peter

[Jannis Achstetter]

Hi all,

Am 21.09.2012 09:25, schrieb Andrew Frazer:
> Any care to suggest a better media engine for the pi..

sorry to jump in a bit late on this thread but I had needed to set up a
concert in a theatre so I've been a little busy.

All the media players mentioned up to now don't support output via
OpenMAX as far as I understood. Of course you can control omxplayer via
simulated keyboard input (one thing that can be done with mplayer, too
and I've been doing just that last weekend :). The solution is quite
nice and has some advantages.

However, here's another option: GStreamer. While not liking it very much
personally, it does have some nice features including output via OpenMAX
and remote control options. The OpenMAX-part boils down to this thread:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=6852
and this GIT repo:
http://cgit.freedesktop.org/gstreamer/gst-openmax/

I didn't test this personally but some people in the mentioned thread
report success.

Writing the needed glue between OLA and GStreamer shouldn't be a problem.

Nevertheless, if the omxplayer and simulated key presses work fine for
you just keep on using that :)

Best regards,
Jannis

[Andrew Frazer]

Thats worth looking at ..

And interesting post from the raspberry Pi forum;;

There are a few gotchas when doing a wrapper around omxplayer that I found when doing my own (I used Java, but the same applies to most languages):
omxplayer outputs somethings to stdout, some to stderr. This means either your wrapper has to monitor both, or you use the shell to connect the two together (eg: 2>&1)
The response to +/- is output (in the source I have) on stdout. This means you won't see it too soon because stdout is BUFFERED and the stream is not flushed. I recompiled for stderr and its fine.
Sending key strokes into omxplayer (from a program, not a script) can suffer the same problems: be sure to flush the stream to get your keys out of your program!
omxplayer does the equivalent of stty -icanon -echo -echoe -min 1 (and perhaps a few more I have forgotten). Whether this gets in the way of pipes or named pipes I am not sure but it all worked better for me when I changed it to polling stdin with non-blocking input.
The output that -s generates can be rather overwhelming - about 150 times a second (on stdout) which means your script/program needs to process it fairly quickly. I recompiled to output just the position data to stderr about twice a second.
Having done these things I find it works reliably and I have ended up with a media control GUI similar to what to might see on VLC or QuickTime Player.

Good job omxplayer!

[Peter Stuge]

Andrew Frazer wrote:
> stdout is BUFFERED

Call setvbuf().


//Peter

[Jack Jewell]

hello

Has anybody found a better way of running a media server on the raspberry pi. i would like 2 layers or just one that fades would be nice. i am trying the ola_trigger but don't seem to be able to make it send commands on the cmd line can somebody give me an example of what i wold need to put in the ola triggers.conf file to run a shell script?

thanks

Jack 

[Santi]

El dom, 19-01-2014 a las 14:01 -0800, Jack Jewell escribió:

> i am trying the ola_trigger but don't seem to be able to make it send
> commands on the cmd line can somebody give me an example of what i
> wold need to put in the ola triggers.conf file to run a shell script?

Hello,

you have information about it in

http://www.openlighting.org/ola/advanced-topics/ola-dmx-trigger/
>
and

http://www.opendmx.net/index.php?title=Raspberry_Pi_Media_Player

Cheers.

[Jack Jewell]

Hello 

Thanks for the reply.

I am really new to the pi and am trying to learn i have been playing around can make it say hello but don't seem to be able to make it trigger a shell script can somebody tell me what i have don't wrong.

this is what i currently have

1 255 `echo sudo play.sh`

2 255 `echo hello`

Any help would be great full.

sorry to be a pain!

Thanks

Jack

[Hippy]

Could be as simple as replacing "echo" with "/bin/sh"?

--
The Open Lighting Group: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Peter Newman]

If you need sudo, you'd need to run the following:

 

sudo /bin/sh play.sh

 

Although if your script has a shebang (#!) line, you shouldn't need the /bin/sh bit.

 

I would avoid sudo if you can, or if not perhaps move the sudo to within the script and add the specific command you're running to /etc/sudoers with NOPASSWD. Otherwise it probably won't work as it will be waiting for you to enter your password when the trigger is run.

 

It would be great if you're willing to contribute what you make too, or do a writeup in the wiki.

 

PN

[Santi]

El lun, 03-02-2014 a las 17:43 -0800, Peter Newman escribió:
> If you need sudo, you'd need to run the following:
>
> sudo /bin/sh play.sh

Hello,

also i would include the path to the file to avoid mistakes:

sudo /bin/sh /home/user/scripts/play.sh

In a regular Linux, "sudo" is not needed to play a video file. Do you
need in rasp?

Cheers.

Santi.
>