Plex Media Center for OS X Leopard

It’s been hell trying to get anything done lately. A friend is in town getting married and we’ve been partaking in all the wedding activities, which involve an ungodly amount of high quality alcohol. And we all all know how alcohol and coding don’t mix.

Anyway, better late than never. We’ve decided to push the version number up a bit more than usual, to reflect the major changes in this version:

• NEW: Work has been completed on the Mach5 Ruby script, which processes Mach-O library files and performs mapping on symbols (so that printf calls __wrap_printf, for example). This enables the XBMC virtual file system to work. I’ve processed all the libraries, so we should be good to go. What this means in practical terms is that things like reading images over SMB shares should now work.
• NEW: Relying also on Mach5 is Python scripting support, new to this release. I will note first and foremost that Python support is unstable, and crashes a lot. This is a known problem with the Linux port of XBMC too, and I consider it a high priority issue. However, Python is stable enough for you to play a few games of Tetris, or even view some Apple Movie Trailers (remember that 5-channel AAC support is lacking).
• UPDATED: I’ve updated ffmpeg to the latest trunk, and added a few XBMC patches that were missing. Certain MKV files that wouldn’t play at all or would crash will now work.
• UPDATED: The XBMC code is near trunk as well; I’m missing a bunch of changes that went in the day or two, because I haven’t had a chance to test things out.
• FIX: Bug #141 has been fixed (XBMC crashes when changing aspect ratio with the “z” key).
• FIX: Bug #106 has been fixed (Initial graphics glitch when playing a movie). Thanks to d4rk for helping me out with this fix.
• FIX: The skin hang-on-exit problem (which I worked around) was actually fixed by charlydoes. Unfortunately I’ve noticed that Python can cause a similar problem.
• FIX: Bug #135 has been fixed (Playing Apple Lossless files in Library mode doesn’t work).

There is also a known issue in this version with loading RAW files. I worked for a while today trying to work around it, to no avail. Essentially, the problem is that the performance reading the RAW files (which appear to be read byte by byte) is extremely bad through XBMC’s VFS layer. I tried to enable some file buffering, but I wasn’t able to get it to work.

This photo of Barley illustrates how I feel after the last week…

XBMC is participating in the most excellent Google Summer of Code this year. You can see a list of some ideas for projects over here and discuss in the forum. There are a few days left for submitting applications, so if you’re interested, by all means go for it! This would be a fun project for a student to work on and get paid for doing so.

I fixed a few more issues with Python, and now Apple Movies Trailers work! Browsing, playing, it all works. I did need to replace some of the Python libraries in the downloaded script with the OS X version. This raises the issue of how to support downloading scripts for different platforms, when the scripts need binary components.

The good news is that I’ve made substantial progress in getting Python to work in OSXBMC. The bad news? I’m now addicted to the Tetris script and likely won’t get much more work done this weekend.

There are still some issues to be figured out, but hopefully I’ll be able to make a release this coming week with Python enabled.

(This also means that the Mach-O processor that wraps some stdio/stdlib calls seems to be working, which means that the full power of XBMC’s virtual file system should work once I run the processor on all the libraries. Which means thumbnails over SMB and probably lot of other things.)

Now I have to get back to Tetris.

Why so quiet lately? I’ve been working on a tool that processing Mach-O shared libraries and remaps symbols, so that libraries that we load inside OSXBMC call our own versions of some functions. This is needed in order to make paths and virtual file system behavior work (e.g. so that ImageLib can be told to open “smb://…..”).

Having this working will not only allow scripts to work (with correct paths, especially), but will also fix a number of problems people have reported like “Thumbnails don’t work over SMB shares”. At least, that’s the theory.

I’ve gotten things near working to the point where the resulting libraries appear to be valid, and hooked functions are getting called, but now I’m running into some other issues. If you’d like to take a peek at the code for the Mach-O processor, it’s here.

I had a bit of time to patch a few holes, so hopefully this will fix some issues with the last release. This version is also built with the new XCode 3.1 compilers, although I wasn’t brave enough to try gcc-4.2.1. Pick it up in the usual place.

• NEW: I hacked on CxImage some more, and now we extract thumbnails directly out of the RAW files if we can. This means that browsing though directories of RAW files is now extremely fast. The embedded thumbnails are also resized and rotated appropriately.
• FIX: A merge got messed up, and the exit-on-hang (with Aeon skin, mostly?) returned. The skin unloading is again disabled, so exiting should never hang.
• NEW: I updated to the latest code, and so D4rk’s event server is now included. This means that someone could now work on building support for the PS3 remote (using this, perhaps?), as well as maybe move the Apple Remote code out into a daemon so that pressing the Menu button starts XBMC. The daemon could be written in Obj-C or Python (or any other language, of course).
• FIX: Scrapers have also been updated. If you have problems, hit the C key, select “Set Content” and then select Settings to make sure the scraper preferences are up to date and compatible with the new scrapers.
• NEW: Added the fancy disc image background that Fredrik made for us to the DMG. Thanks!

This is Barkley out on his first kayaking trip. The canoe tipped, we were all thrown into the ocean, and Barkley swam over to Anna and took away her life jacket. I’m so not kidding.

My dad has been in town for the last week, hence the lack of updates. I need a few days to take care of things that have fallen by the wayside, and then I’ll hop back in the fray. Apologies to those waiting for replies to posts and emails.

If you want to build the source yourself, you should be able to replicate my latest build now. If you’re interested in helping out, let me know, as I have plenty of tasks I could use help with.

A few quick changes, so that I can go off and enjoy the weekend…the release can be downloaded here.

• NEW: Improved handling of situations where display refresh rate < video frame rate. Allows doing things like watching 60 FPS videos on a 24 Hz display (although this doesn’t work perfectly yet). It also improves how 24p content displays in 24p mode. (N.B. the mode on your display should really be 23.976 Hz. It doesn’t sound like a big difference but it accumulates). Thanks to elupus for pointing me in the right direction.
• NEW: RAW thumbnails are now built using the embedded JPEG (when present), so previewing directories of RAWs is now really quick.
• FIX: I was seeing occasional crashes when using FTP, due to an apparent incorrect ordering of libcurl operations. I’ve also increased the idle time from 5 seconds to 30, because when browsing, the connection would tend to close and need to be reestablished. It could probably be longer.
• FIX: The hang in library mode has been fixed.
• FIX: TV and movie scrapers have been updated and should now work.
• FIX: Don’t default to digital audio mode anymore, as we don’t need to now that we do mix-down.

And one again, here’s Barkley, who has agreed to sponsor all future releases. He thinks that the ball in the mirror is a duplicate and he’s trying to figure out how to get them both.

After reading John’s excellent post over here, I got to thinking about 1080p content (or “difficult” content, really) and how we might be able to better handle it. To begin, let’s go over the numbers:

• A typical uncompressed 1080p frame takes up 3 MB (megabytes). This is full resolution for the Y plane, and subsampled U and V planes.
• This means that a single second of uncompressed video (24p) takes up almost 73 MB.

That’s a huge amount of bandwidth, compared to the compressed video. An episode of Lost I’m watching right now is hovering around 8 Mbps, which is 1 MB/sec. This is a pretty impressive compression ratio, and there also a few possibly interesting takeaways from it:

• Streaming uncompressed 1080p content over Gigabit Ethernet is theoretically possible, but only just barely.
• Streaming uncompressed 1080p content off a typical hard drive is theoretically possible, but again, only just barely and only in “best case scenarios”.

Most of the problems we run into playing 1080p video content have to do with two the combination of two things:

1. The existence of bursts of high bit-rate frame sequences (some only a second or two long, some 10s of seconds).
2. The fact that we do real-time decoding, so if a frame is late, we drop it.

So here are some random ideas that were running through my head as I woke up this morning:

• Decode buffer: Disk buffers work to smooth out arrival jitter in data from the disk, so we don’t we have a decode buffer to smooth out arrival jitter in the decoded frames? That way, if we run into a frame sequence where we would get behind, we can simply empty frames from the decode buffer. Since the CPU is usually ahead, we could simply decode as fast as we can, and accumulate some number of pre-decoded frames (in RAM). To keep 2 seconds of decoded frames would cost about 150MB of RAM, which is chump change these days. And even if we pre-filled the buffer before playing, the pre-roll delay would only be increased by at *most* 2 seconds.
• Grid computing: Harness the power of your idle computers and have them decoding frames for you. The problem is the extreme bandwidth of the decoded frames, as mentioned. But perhaps apply some high quality MPEG-2 compression, and it becomes much more manageable. Presumably they could decode sequences between keyframes.
• Sidecar Preprocessing: Since MPEG-2 is easier to decompress, why not simply run a preprocessor over H.264 files? Any spots that are higher than a specified bitrate would be pre-decoded, encoded to high quality MPEG-2, and then stored in a “sidecar”, alongside the original media. Imagine “Planet.Earth.01.mkv” and then “Planet.Earth.01.mkv.sidecar.00:02:01-00:02:40.mpeg2″ (assuming the sidecars start and end on second boundaries). The sidecar format could be anything appropriate, and it wouldn’t have to store audio or other metadata (e.g. subtitles). Best of all, they could be whacked at any point or recomputed.

EDIT: Of course, the sidecar media could also just be lower bit-rate H.264, that way ffmpeg wouldn’t need to be any the wiser.

Hope you’re all having a great weekend.