MeBox's current status is: vaporware.
MeBox

More info:

What is MeBox?

(Note: Most of what is described on these pages (with the exception of kaa.canvas and vf_overlay) is obsolete and has been replaced by new design and code. See the Kaa Project.

MeBox (concatenation of the words "Media Box") is a pet project of mine to implement home theatre PC software under Linux. Yes, another one. I suffer hopelessly from NIH syndrome, and this may end up being another one of those projects that gets shelved after I lose interest.

I am writing MeBox in Python, and of course I have the same lofty goals that all other HTPC software has. "Why don't you just use Freevo?" you ask. Indeed, I do use Freevo, and it's very nice software. I started MeBox mostly as an experiment to test the feasibility of an idea I had: using MPlayer as a platform, rather than a helper application.

MPlayer has a video filter called bmovl which allows another process to overlay images onto MPlayer's frame buffer. This filter was written by Per Wigren a while ago to enable Freevo to have custom OSD. That's when I thought, "Why limit it to OSD? Why not draw menus too? In fact, why not build the whole app using bmovl? That way we could have cool animated backgrounds a la TiVo." Unfortunately, bmovl simply wasn't designed for that. It scaled neither in performance nor features to support complex displays with cool transition effects.

So that's when I wrote bmovl2. (Note: bmovl2 is deprecated by vf_overlay, but that has also fell out of maintenance.) bmovl2 does the same kinds of things as bmovl, only it's designed with a little more smarts and a lot more performance (assembly optimized blending, receiving RGBA or YV12 bitmaps via shared memory, etc.). If bmovl2 would serve as the basis for all of MeBox's interface, it had to be efficient. I had no idea if it would work, but after some weeks of hacking and tuning and getting advice on mplayer-dev, I was happy the the results.

Then I began hacking on support code I knew I would need for MeBox: a VFS layer with metadata support (not unlike Freevo's vfs), built from the ground up with responsiveness and performance in mind; a python wrapper for Imlib2 since PIL or pygame wouldn't cut it; canvas system that uses bmovl2; a widget set that uses the canvas (not finished); and, most recently, time shifting support for my ivtv card, which required more patches for MPlayer.

The good news is that even if I do end up shelving MeBox, a lot of this code can be reused in other applications like Freevo. If bmovl2 ever gets merged into MPlayer, or Freevo uses the time shifting code (or ideas from it), then the MeBox experiment was a success.

Future Plans

Much of what I've written so far is either support code (like the canvas system) or a blob of spaghetti mess that tests the support code. What is available for download is intended for curious hackers only. But as I have the time and the inclination to work on MeBox, I'll begin adding features that scratch my own personal itches, notably:

One of the main benefits of layering everything on top of MPlayer is that we aren't tied to any specific output display, such as X11. This means that MeBox can display on any output device that MPlayer can. Unfortunately, MeBox is extremely demanding of MPlayer, and much of what it does requires patching MPlayer's code, which, in some cases (like live tv support) is a bit scary, since MPlayer's code is, well, disgusting. (Have a look at mplayer.c.)

One direction I'll want to investigate is GStreamer. MeBox's main requirement is bmovl2, and anything that can speak the bmovl2 protocol should be able to serve as a platform to MeBox. Much of the bmovl2 code isn't MPlayer-specific, so in theory it could be ported to GStreamer, Xine, Ogle, etc.


The nonsense written above can be blamed on Jason Tackaberry (tack@urandom.ca).

Powered by His Noodly Appendage.