Feature Request: An OMXPlayer API to use the player in other programming languages

[jbaiter]

I'm currently thinking about rewriting my Python wrapper around omxplayer. This time I would like to use the omxplayer functions directly from Python, without using a workaround like parsing omxplayer's stdout with regular expressions, which is slow and error-prone.
Ideally, one would be able to use a libomxplayer.so dynamic library, that provides a single class OMXPlayer, which exposes all of the functionality of the CLI program via methods. I.e. one would call loadFile to load a file, loadSubtitle to select a subtitle stream or file, play to start playback, etc.
My C++-Fu is barely existant (I'm currently teaching myself C++11, but am making rather slow progress), but I spent a few train rides studying the omxplayer source code, and to me it looks like this would not be a too difficult task for someone more well versed in C++ and the omxplayer codebase. My (probably rather naive) understanding is, that one would "just" need to refactor omxplayer.cpp to use one more layer of abstraction (the above mentioned OMXPlayer object) instead of making the calls to the lower-level API directly.
This would help me tremendously, as I could then just use Python's ctypes library to call the library functions directly, instead of going the current pexpect/stdout+regex route.

[popcornmix]

Not something I'm planning, but I agree it's a straightforward plumbing job that would split omxplayer into an appliction part (dealing with command line options and key presses, and printout), and a library part (implementing openfile, seek, play, pause, getstatus etc).

[torarin]

I started this work, but, in the process, got caught up in fixing the various omxplayer bugs I encountered, so I never finished it. I don't have time to do so in the near future, but if anyone wants to look at it, it is here: https://github.com/torarin/omxplayer/tree/fixes

[foufee]

I'm using the OMXTexture and the Qt QML stuff in https://github.com/carlonluca/pi/, and have discovered there is a leak somewhere (and it can be demonstrated with OMXPlayer too). If you change media about 97 times (repeatable thankfully), it will hang.
The stuff in https://github.com/carlonluca/pi/ and my fork (which is a Qt QML plugin) https://github.com/foufee/pi is close to working and is a shared library.

[digitalman2112]

If appropriate, I would be willing to offer a small bounty for the timely creation of an API (as detailed by @jbaiter) that I could easily call from python / pygame. I need this both for a personal project which will be used to instruct kids on the pygame framework, where accelerated video playback would be a huge feature.

[gstein]

@jbaiter I am interested in the same thing! I got started on this over the past couple days. First up was to get omxplayer building natively on my RPi/Raspbian without a lot of hassle. You can see the completed work at gstein/omxplayer. Next up is to separate omxplayer into "playing bits" and "UI bits". I was thinking of an API much like you describe: let the underlying code to all the heavy lifting, and just have Python do the high-level management.

omxplayer has a lot of C++ layered over the underlying libraries, which I would prefer to leave behind. Plain C libraries are easier for high-level language to wrap, and libav is written in C anyways. So... I'm mostly looking at a shim that will solve the 90% problem.

(more background at http://prng.blogspot.com/2013/04/building-omxplayer-on-raspberry-pi.html)

[lazy404]

I think some api to control omxplayer using a socket will suffice for most of these use cases.

[gstein]

My intent is to provide an API to perform just the video function. A layer on top of that can provide/manage the socket.

(I intend to do that in Python, but it is very easy to imagine C-based code for the same)

[popcornmix]

popcornmix#10