Plex Media Center for OS X Leopard

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.

I’m pretty drunk, so there’s a good chance that I’ll screw up this release, but I’ll give it a good run. This is mostly a bug-fix release, with a few new features thrown in for good measure. I also updated to the very latest ffmpeg and XBMC code, which will hopefully only improve things.

Here are the changes in this release:

• FIX: I re-enabled the pixel shader for “advanced” OpenGL cards, which was mistakenly left disabled in the last release due to the X3100 debugging. Nobody even noticed, so it’s likely you won’t notice it being on again, but feel free to pretend like everything suddenly got a whole lot faster or better looking.
• FIX: Crash on exit that was due to you naughty users having Python scripts in the scripts folder. I know who you are.
• FIX: FLAC files should now play, as I fixed the linkage on the FLAC library.
• FIX: Make sure the “Application Support” directory is there before trying to create the XBMC directory inside it. For those of you with really virgin Macs.
• NEW: Down-mixing of AC3 and DTS. Finally, those of you having to sit there in silence watching your movies at high speed, perhaps having to suffer through a loved one nagging you over your shoulder. Set your output mode to analog, turn up the volume, and ignore that loved one. (P.S. Those of you anime fiends with 5-channel AAC, sorry people, no such luck. Post a link to a sample video with that sound format and I’ll try to look into it.)
• NEW: Support for 4:2:2 MPEG video. This corresponds to the “30secondfergie.mpg” clip, for those of you in the know. Thanks to d4rk and elupus for the final tip on how to scale down the chroma planes. I also updated the libmpeg2 library to the latest and greatest, which adds SSE2 decoding acceleration, and probably lots of bug-fixes. There is still a problem thumbnailing certain MPEG videos. It seems to be a bug in libmpeg2, but I haven’t had time to track it down further.
• NEW: Preliminary support for Xbox 360 wireless controllers. I have one, and I’ve modified the keymap.xml file for basic support. I’m using the drivers found here, and they seem to work pretty well, except for a few small issues (and I want to get idle mode working so that the system shuts down the controller). I’m looking for a volunteer to finish up the keymap. It’s going to be a pretty sweet option for controlling XBMC, especially once I get MAME integrated.
• FIX: Exiting with certain skins caused a hang, which was deadly and downright rude in fullscreen mode. Being unable to quickly find the bug, I’ve simply disabled skin unloading upon exit. The pros: No more hangs. The cons: Lack of “final” animation. The pros: It exits much more quickly. So go ahead and try to have a problem exiting. I double doggy dare you.
• FIX: Watching a movie and then switching to fullscreen mode with the ‘\’ key could result in vertical sync being disabled, which led to video tearing and hair-tearing posts on the forum and blog.
• NEW: I updated CxImage to version 6.0 (used in displaying photos). Besides incorporating years of fixes and enhancements, the one thing I was excited about was RAW support. However, there are a few downsides I’ve found: It takes forever to thumbnail RAW files, and the thumbnails are corrupted (ha!). However, it will actually display RAW images properly in a slideshow. N.B. To enable RAW display, you’ll need an advancedsettings.xml file that looks like this.
• FIX: When switching between fullscreen and windowed mode, the fonts would get kind of messed up, in that their sizes were wrong. d4rk explained what was going on, and I fixed it.
• NEW: Lots of improvements on the scrapers (which load movie/TV show information) from others on the XBMC team. Hopefully they work for you.

One more thing, on the topic of “skiploopfilter”. I did a bunch of experimenting, and I’ve come to the conclusion that it may not be worth the effort. First, let me share some numbers with you; these are all playing the infamous “bird scene” from Planet Earth.

NO: 449 dropped, 159% CPU usage.
ALL: 443 dropped, 147% CPU usage.
BIDIR: 449 dropped, 157% CPU usage.

As you can see, there’s really not much difference. My theory is that the CABAC patch that is applied to ffmpeg, which does prediction+idct+deblock in a separate thread from decoding, already improves things to the extent that deblocking is really not the bottleneck.

Yes, I know, I need to check in my changes. Now that I’m all synced up, I’ll work on that tomorrow. I promise.

I’m working on getting a new release out the door, hopefully within the next day or two. The main focus is bug-fixes, but it will also include a highly desired feature: AC3 and DTS down-mixing. After the release, I will move to (finally) get synced up and checked in, and then work on getting Python working.

The big change in this release (or perhaps the one which will make the most people happy) is the fix for the “pink screen” issue affecting GMA X3100 video hardware. It turns out that there is a serious bug (apparently one of many!) in the OS X driver which completely breaks support for the negation of constants in shaders. I had to modify the output of the NVidia compiler to make sure that constants were never negated (the constants are the things like “c[0].x”). I can’t even tell you how serious a bug this is. Just imagine if this were the case in a C++ compiler… Many thanks to d4rk for showing me how to get the shader compiling in the first place.

Here the the other changes in this release:

• NEW: Support for using the scroll wheel with the mouse.
• FIX: International character sets (and funky characters in English) now work. Go Spanish! Non Western European characters probably work too with that Unicode font. N.B. There is still a problem when displaying *filesystem* entries; I’m working on it.
• FIX: Don’t dim the screen when the screensaver kicks in unless we’re in full-screen mode. It’s scary and makes people think their LCD is dying.
• NEW: Make ‘Done’ the default key selected in the virtual keyboard. It really makes keyboard entry much more natural. Thanks to ScottTFrazer for the suggestion!
• NEW: All standard output logging has been moved to the /var/tmp/xbmc.log file. This means that (a) I will never ask you to run from the terminal again and (b) I’ll be asking you for that file a lot more.
• FIX: The audio output is no longer stuck in digital mode.
• NEW: Support for mounting SMB filesystems using the OS’ support for it. This was introduced by vulkanr in this change. It seems to work well, but if the SMB share is inaccessible, XBMC hangs on start for quite a while waiting for the mount to timeout. Let me know which options provides better performance.
• FIX: Store mediasources.xml in the Application Support/XBMC directory, instead inside the application bundle. You’ll have to move yours there if you want to maintain settings.
• FIX: There was a naming conflict between the SMB client code and some other library I can’t remember, which was causing the application to crash quite a bit when using SMB.
• FIX: The infamous hang-or-crash-on-exit bug has been nailed. I double-dare any of you to hang XBMC on exit!
• NOTE: Make sure your vertical sync is enabled (set to Always Enabled). People were complaining of video issues and tearing. It’s in Settings -> Appearance -> Screen.
• NOTE: I’ve been able to play FLAC files without a problem. I’m not sure why people (or only a couple of people?) are unable to play them.

The surprise feature in this release is basic support for the Apple Remote. It’s very basic and will be enhanced much more, but here is what’s supported for now:

• Left, Right, Up, Down: As expected, and no support for volume (isn’t everyone using their receiver remote for this anyway?)
• Play/pause: As expected.
• Menu: Up one level.
• Double-click Play brings up context menu.
• When in full-screen video, the menu button brings up the menu, and holding down the menu button stops and returns you to the browser.

Really simple, but hopefully useful, and also hopefully it doesn’t break people who are using Remote Buddy.

As usual, enjoy the release, brought to you by Barkley and my sweet wife, who have both been really supportive of all my late nights.

I need to clean up some code and then I’ll make a release later on tonight (and check in my changes, sorry it’s been so long). It turned out to be a blatant bug in the fragment shader runtime or assembler, which I have worked around. More details later.

Very strange…there appears to be something fundamentally wrong or different with the X3100, as best I can tell from my extremely limited experience with such things. Which probably means I’m completely wrong.

D4rk helped me get set up compiling my own fragment programs (thank you!). The approach I took is what I always do, which is get the working code on one end, the non-working code on the other, and then move towards the middle until you find out what breaks.

I took out all the matrix multiplication, and just started with some basic transformations to see what worked. While rgb.r = 1.164 * yuv.r; produced the expected pixel color rgb.r = 1.164 * (yuv.r - 16.0/256.0) + 1.596 * (yuv.b - 128.0/256.0); doesn’t (at least according to my Numbers spreadsheet). So tomorrow I’ll do some more back and forth to see if I can figure out why the second formula isn’t working. (Note that it DOES work on an NVidia card). Doing debugging where the only way to output debugging information is through 0-1 values in pixel color components has given me new respect for people who work in that field.