omxplayer shared object

[skinkie]

For one of my open source broadcasting projects I wanted to integrate omxplayer with my playout system. The problems with starting omxplayer using system(...) were obvious: gapless support was nowhere to be found and it is virtually impossible to control the binary from another C program.

I started to hack a wrapper around the code in omxplayer.cpp giving;

int playerInit(char *filename);
void playerPlay();
int playerLoop();
void playerClose();

At this point is truly a hack. The shared library works as a charm, I am able to preroll a video so I can start it when I please. Some things should still be done the start of the video isn't as seamless as I want. As you can see from the calls above, the shared object would only allow one video stream to be loaded and played at a given time. I think I can do better.

There are some less obvious things that I need to figure out such as why it is required to setup a new_termios? Removing that code means no video playout. I have now moved all variables to the global scope, it must be possible to prune some, init the library once and have multiple players around. Sounds doable, help appreciated.

Lots of text needs some patch: http://stefan.konink.de/contrib/omx/

[StevenHickson]

Actually you can control the binary using mkfifo for the input/output to omxplayer if you want. Though having a wrapper/lib is probably a good idea for other c++ projects.

[skinkie]

My main problem is that when I start to do major refactoring of the code, that all of a sudden no output is showed anymore on the screen. Which makes the exercise a pretty hairy one. I'm considering to keeping omxplayer 'in tact' for now until someone else wants to reach out. It probably saves a significant amount of time when backporting fixes.

I think I make a tiny patch that pauses the player after load, so I can in fact 'cue' a file and send over a pipe the command to resume playing.