Guacamayo media player distribution

Guacamayo is a new entrant in the field of Linux-based operating systems for multimedia devices. Most such distributions (e.g. LinHES or Mythbuntu) start with a desktop distribution and add media management, playback, and other features on top, but Guacamayo's creators Tomas Frydrych and Ross Burton are taking the opposite approach, starting with a minimal embedded system and adding only the software necessary to stream multimedia content. The result, they hope, will be a more stable base for building set-top boxes, network-connected speakers, and other nontraditional media platforms.

Frydrych said the impetus for the project was the popular Raspberry Pi device, which offers a low-cost board capable of HDMI output. Despite that inspiration, however, he builds Guacamayo against a different test platform, the pricier (but still lightweight) ZBox, a roughly WiFi-router-sized fanless desktop unit. Frydrych and Burton are both veterans of OpenedHand and Intel (which acquired the former in 2008), and Guacamayo builds on many of the projects created by OpenedHand over the years. It is based on the Yocto embedded Linux platform, uses the Clutter library for its GUI layer, and runs Media Explorer (MEX) as its "shell." For now, the emphasis is on Universal Plug-and-Play (UPnP) and Digital Living Network Alliance (DLNA, which is a consumer electronics compliance organization built on top of UPnP) compatibility through the Rygel library.

The first public release is version 0.2, which was code-named "See No Evil, Hear All You Want!" because it supported audio playback only (MEX support has been added subsequently). Burton posted a blog entry about the release on May 22, saying he used it successfully with a UPnP media storage device. In that configuration, Rygel presents the Guacamayo front-end as a UPnP "Media Renderer" that can be remotely controlled by any compliant UPnP or DLNA "Media Controller." In the same post, Burton said that Frydrych had tested the release running on a BeagleBoard being controlled over the network with a Android DLNA control application.

Sound off

Audio playback alone might not sound particularly exciting, but the next release should add video playback, which is where the system begins to get more interesting. The audio decoding and playback are handled by PulseAudio and GStreamer, both of which are standard system components on desktop Linux. But Guacamayo's video stack is intended to dispense with X Windows, window managers, and desktops entirely. MEX is a simple media browser and player built specifically for Clutter, but Guacamayo's Clutter will run with an OpenGL back-end. That will enable smooth graphics on Raspberry Pi and other such low-power boxes that have hardware-accelerated OpenGL support.

According to Burton, many of the GPUs in this generation of device are also supported (at least partially) by the video acceleration API (VA-API). GStreamer supports VA-API, therefore Clutter and MEX should be able to take advantage of it as well. On the other hand, Guacamayo can be built for a broad spectrum of hardware devices, some of which might be able to take full advantage of VA-API and some of which might not. Burton noted that his old ThinkPad can decode MPEG2 in hardware, but it can do the job just as easily in software. In contrast, a more recent Cedar Trail Atom netbook can decode the more complex H.264 codec at 1080p in hardware, but is incapable of decoding the same format in software fast enough to be watchable.

You can get another taste of the flexibility of the Guacamayo code from the build instructions. The project uses the Poky build system, and at the moment three build options are supported: the headless audio-only release, the video-enabled MEX target that runs directly in OpenGL, and an interim option that runs MEX on X11.

Despite how clean and simple the setup is — and there can be little denying that the stripped-down media playback environment of Guacamayo is simple — a few challenges remain. The first is video drivers. Both Burton and Frydrych observed that open source drivers for Intel video chips offer good support for OpenGL (and in particular the EGL interface used by Guacamayo), but that other chipmakers are spottier. Frydrych said that the BeagleBoard drivers "have issues" and "took far more effort than should be necessary", while Burton said that he thought the Nouveau drivers for Nvidia hardware worked well. Still, Frydrych said that he felt that "the OpenGL(ES) route is good enough to bank on", since the chipmakers are aware that they need working OpenGL ES drivers in order to compete in the marketplace. He has yet to see exactly how well the Raspberry Pi delivers on this point, he added, but if they "get it right" it could have a significant impact on the competition.

Another challenge is support for input devices and remote controls. The X-less builds use the kernel's evdev interface to capture input events, but without X there is no XInput2 subsystem to enable multi-touch, "multimedia keyboards" or other flashy input devices. Although Rygel gives Guacamayo automatic support for UPnP/DLNA remote controls, infrared is still the dominant flavor of remote control. Burton commented that DLNA and IR remotes are "orthogonal," but that Guacamayo needed to support them both.

Platforms versus products

I asked whether Guacamayo was focused squarely at do-it-yourself media devices, or if its creators hoped to see it powering consumer products some day. Frydrych replied that he would rather see Guacamayo grow into a Yocto-based platform that others found useful, and which could be tailored to more than one use case. In that regard, he approaches the project as a set of add-ons that enable Yocto to work on media-centric devices that it otherwise could not, rather than as a separate distribution. The key distinction, he said, is establishing a reliable QA process that makes the distribution maintainable. That is an area where Yocto excels, so it makes for the ideal base platform.

Where Guacamayo heads in the future is still up in the air; there is a general roadmap on the project's GitHub wiki, but Frydrych emphasizes that he is more interested enabling others to build a user experience than in dictating one of his own. "Yocto makes it possible to create a tailored Linux device in a very short period of time, taking care of the boring and tedious; Guacamayo should do the same for the multi-media device category."

For now the Rygel-driven streaming media interface of MEX is the only application on the roadmap. That may prove popular enough with users to spawn a following; after all the consumer device space is filled with streaming-only set-top boxes. But each generation of set-top box also adds more and more features (e.g., Boxee adding live TV tuning, or Roku adding USB storage and games). It will be interesting to see if future Guacamayo releases entice third-party developers to try something new, and how the project adapts. The X-less OpenGL environment is certainly different. Clutter has an OpenGL GUI toolkit called Mx (not to be confused with MEX), but Burton cautioned that Mx was lightweight in design and was not intended to provide a full application framework along the lines of Qt or GTK+. Both developers mentioned that if OpenGL alone proves not to be enough, they will target Wayland rather than X in future releases.

The truly interesting match-up will be to see how video-enabled Guacamayo stacks up against a Tizen set-top box. Despite both projects' interest in media playback devices, they approach the task from starkly different angles. Tizen is concerned (on the set-top front) with providing a complete development environment for consumer electronics manufacturers; the platform offers compatibility with desktop Linux and with the other flavors of Tizen device, and it wants to attract all sorts of independent application vendors. Guacamayo (at least at the moment) is targeting DIY devices first, with a limited application set on a minimal, embedded Linux base. Neither one is necessarily right or wrong, but that's what makes watching them entertaining.