LWN.net Logo

MeeGo beyond the mobile device

November 17, 2010

This article was contributed by Nathan Willis

The majority of the sessions (and indeed, attendees) at the MeeGo Conference in Dublin were focused on the handheld and netbook form factors, because the project emerged from the union of Intel's netbook-oriented Moblin and Nokia's handheld Maemo distributions. As a result it is easy to overlook the fact that the project has added several significantly different target platforms since its inception in February. The "connected TV" and "in-vehicle infotainment" (IVI) platforms share a few common factors with handheld devices, such as near-instant-on boot requirements and remote-management capabilities, but as Monday's talks explained, they also stretch the MeeGo software stack at almost every level, from non-PC hardware support, to different audio and video middleware, to different user interfaces and I/O devices.

Set-top Linux

[Dominique Le Foll]

Dominique Le Foll of Cambridge, UK-based Amino Communication presented two talks about his company's work on the connected TV user experience (UX) for MeeGo. Amino builds MeeGo-based set-top boxes for Europe and North America, generally tailored for television service providers. Le Foll's first talk was one of the Monday-morning keynotes, and focused on Amino's decision to build its products on a "full Linux distribution" rather than a stripped-down embedded Linux platform.

MeeGo's structure as a full distribution lowers the company's development costs, he said, because it permits the team to automatically stay compatible with upstream projects. In contrast, typical embedded distributions tend to use a reduced set of packages and libraries, and usually take the freeze-and-fork approach to what they do include, thus forcing the developers to spend time backporting bug fixes and major updates. In addition, he said, building the company's products — which includes custom applications written for each customer — takes less development time, because they can use the standard desktop Linux development tools, and easily build on top of desktop projects that are rarely included in embedded distributions, such as VoIP, video conferencing, and social networking.

Le Foll's second talk focused more in-depth on the MeeGo software stack and what it needs to become a ready-to-deploy set-top box platform. The five "required" services all set-top devices need to support, he said, are live, broadcast television (based on DVB or ATSC program delivery), Internet video, access to home content (including video, audio, and other media), video-on-demand (VOD) service, and third-party, easy-to-install "apps" of the kind currently popular on consumer smartphones. Each brings its share of challenges to the MeeGo platform.

Broadcast television and VOD services both require some security mechanism with which service providers can implement mandatory access control on specific content streams. This includes DRM and hardware-chain-of-trust as well software modules that can prevent unauthorized applications from accessing protected content or driving special-purpose hardware. Internet video requires, yes, Adobe Flash support — specifically Flash support capable of running on the lower-resource system-on-chip hardware typically used to build set-top boxes.

Access to home content entails seamless playback of a glut of different, often unpredictable video and audio formats, which Le Foll suggested would best be handled by a single unified media-playback application that is decoupled from the content sources. The player, he argued, should not need to know whether the video is coming in live from an antenna, being streamed over IPTV or RTP, or is stored on a network drive. Amino uses GStreamer in its products, and says that it is capable of playing all of the necessary codecs, including broadcast HDTV, but that it lacks a few critical pieces, such as hardware video acceleration and integrated multi-language and subtitle/caption support. Here again, he said, the real need is for a simple playback application that can play back European teletext, US-style closed captioning, and DVD subtitles, without caring which format the underlying source originated in.

Regarding the access control measures and Flash, Le Foll was considering MeeGo set-top boxes as commercial products, of course, to be built by OS-integrators like Amino and sold and deployed by cable companies, satellite TV providers, IPTV distributors, and other content service providers. Do-it-yourself types with an aversion to Flash and no interest in DRM might bristle at the thought of adding them to a Linux distribution, but they would be under no obligation to make use of them, a point which Le Foll clarified in response to an audience question.

On top of the low-level media support, he added, there are several "invisible" things that MeeGo needs to add in order to be a robust connected-TV platform. These include support for remote software updates, automatic backup-and-recovery, and other management tasks that would be infeasible to require non-technical users to perform on their own, and difficult to execute with an infrared remote control. In many countries, he continued, there are legal certification requirements for set-top boxes that entail technical features, such as interfacing with the local emergency broadcast services. Support for infrared remotes is another area in which MeeGo needs significant development, he added, a feature that touches on both hardware drivers and the user interface. Set-top box products demand IR remotes and easy-to-decipher interfaces that can be used from ten feet ("or three meters") away on the couch. Though touch-screen support and gesture interfaces are all the rage in mobile MeeGo device development, he said, they are useless in the set-top environment.

Perhaps the most interesting feature in Le Foll's list of five required services is support for end user "apps." This, he explained, is the most oft-requested feature of the television service providers, who have watched the success of Apple's App Store on the iPhone with envy. In recent years, service providers have tried a number of means to dissuade customers from switching services, including (most recently) "bundling" television service with phone service and Internet access, and all have failed. They are now looking to differentiating their service from the competition with apps on set-top boxes, Le Foll said, which makes MeeGo positioned exceptionally well to meet their needs. For open source developers, this opens up the possibility of developing MeeGo applications for handsets and netbooks that will also run, unaltered, on the next generation of set-top boxes.

Vehicular MeeGo

Another challenging difference in the set-top box environment that Le Foll touched on in his talks is that netbooks and handhelds are essentially single-user devices — while the TV and home theater are shared by the entire household. This distinction has an effect on all sorts of applications, from privacy concerns to customization issues, that developers need to consider when porting their code to the new environment.

[Rudolph Streif]

The same is true of the IVI platform; not only can one vehicle be driven by many members of a household, but an IVI system often needs to consider many users at once. The driver may be using navigation, passengers in the back seat watching rear-seat-entertainment (RSE) consoles each displaying different content, and yet the IVI system also needs to override all of the separate audio zones to sound an alert if the car's proximity sensor detects it is about to back into the curb.

Rudolf Streif from the Linux Foundation's MeeGo IVI Working Group, presented an overview of the MeeGo IVI platform on Monday afternoon, including the missing pieces needed to build MeeGo into a solid IVI base. In addition to multi-zone audio and video, an IVI system also needs to support split-screen and layered video — for example to permit alerts or hands-free phone call messages to pop-up as higher-priority overlays on top of an existing video layer. But the human-machine-interface (HMI) layer in a vehicle system also has to cope with a different set of user input devices, such as physical buttons and knobs on dash units and steering wheels, and simple integration with consumer electronic devices like MP3 players and phones.

The hardware layer also needs to support a variety of device buses used to connect data sensors (speed, fuel level, etc.). There are several industry standards in wide deployment, Streif said, including Controller Area Network (CAN) and Media Oriented Systems Transport (MOST). Supporting them in open source is challenging, he added, because many car-makers have implemented their own brand-specific variations of the standard, and some (like MOST) are not freely or publicly available. For application developers, of course, MeeGo would also need to provide a bus-neutral common API to access this sensor data and (where applicable) to control vehicle hardware.

There are several areas of the middleware stack where MeeGo — and even Linux and open source in general — currently fall short. One (mentioned in Streif's talk and also raised in the IVI birds-of-a-feather session held later that afternoon) is voice control, specifically speech recognition and speech synthesis. There are few open source projects tackling these tasks, and most of those are academic in nature and not easily-integrated with upstream projects. Because hands-free phone operation is critical (even a legal requirement in many areas), there is a need for good acoustic echo cancellation and noise suppression, neither of which is currently well-supported in an open source project.

IVI devices are even more sensitive to fast boot times and fast application start-up than are entertainment devices, plus they must be prepared to cope with unregulated DC power from batteries and shut down safely and quickly when power is cut off. Like the situation with entertainment devices, most end users are not prepared to or interested in performing system updates, so remote management is a must. But unlike set-top boxes or even phones, car IVI systems are generally designed to have a ten-year lifespan. That poses a challenge not only for hardware makers, but for the MeeGo project itself and its application compliance program.

The IVI Working Group includes a diverse group of collaborators, include silicon vendors like Intel, car makers and Tier 1 automotive suppliers, industry consortia like GENIVI, and automotive software developers like Pelagicore AB. Involvement by the existing MeeGo development community has been slow to build, owing in no small part to the long product development cycle of the auto industry, but Streif and other members of the project were actively seeking input and participation from community members.

Where else can MeeGo go

At first blush, vehicle computing and set-top boxes sound like a radical departure from MeeGo's portable-device beginnings. Listening to the talks, however, it becomes clear that in both cases, there is an industry that up until now had been dominated by traditional embedded systems — and often proprietary operating systems and software stacks — which sees the success of Linux in smartphones and wants to emulate it. Open source software on smartphones took decades to arrive; at the very least the opportunity presented by MeeGo on the set-top box and IVI fronts is one where open source software can make a strong showing from the beginning. Beyond that, it may allow free software advocates to push back on some issues like closed and royalty-bearing standards that currently inhibit development.

The first big bullet point made in all of Monday morning's keynotes was that MeeGo is designed to present a unified Linux-based stack for the embedded market, averting the fragmentation that dogged early Linux smartphone development. That is clearly welcome news to the device makers. But the second big bullet point was that MeeGo presents a unified Linux distribution that is compatible with upstream projects and desktop distributions — which ought to be welcome news to open source developers. Le Foll and Streif both discussed examples of how industry product vendors (television service providers and car-makers, respectively) were eager to get on board with the mobile application craze; having those platforms be compatible with Linux desktops is a clear win. Don't think that it stops there, either — although there were no talks on the program about them, more MeeGo platforms kept cropping up in the middle of people's sessions, including everything from desktop video-phones to digital signage.


(Log in to post comments)

MeeGo beyond the mobile device

Posted Nov 18, 2010 2:30 UTC (Thu) by martinfick (subscriber, #4455) [Link]

> Open source software on smartphones took decades to arrive;

Hmm, I didn't know that smartphones were even around for a decade, let alone decades?

MeeGo beyond the mobile device

Posted Nov 18, 2010 21:10 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

It depends on your definition of smartphone. I tend to think that smartphones must support installation of new applications, in which case I think the earliest is the Nokia 9210 from 2001. However Wikipedia's entry on smartphones has a broader definition and examples from the 90s.

MeeGo beyond the mobile device

Posted Nov 19, 2010 2:35 UTC (Fri) by martinfick (subscriber, #4455) [Link]

That WP article reads like an article on the PC written in 1981, perhaps citing mainframes and the apple ][ as part of the long PC history. I think that it is a stretch to call anything a smart phone unless it could browse the web. Anything else is a PDA/phone combo or feature phone. It might be time to rewrite that article. :)

MeeGo beyond the mobile device

Posted Nov 23, 2010 11:19 UTC (Tue) by nicolas@jungers (✭ supporter ✭, #7579) [Link]

My Handspring with the gsm module was able to browse the net in 2001. I had also a ssh client and various net utilities. It was of course a dial-up connection, but a connection nevertheless.

MeeGo beyond the mobile device

Posted Nov 24, 2010 0:53 UTC (Wed) by martinfick (subscriber, #4455) [Link]

Do you mean access the net or browse the web? I had a handspring around that time. I do not recall a webrowser app being available. IP connectivity does not imply browsing.

Even if you did, is would still make the original decades (plural) statement hard to stomach.

MeeGo beyond the mobile device

Posted Nov 18, 2010 4:12 UTC (Thu) by Ford_Prefect (subscriber, #36934) [Link]

> there is a need for good acoustic echo cancellation and noise suppression

At least there's some progress being made on this front. PulseAudio recently got support for acoustic echo cancellation - http://blogs.gnome.org/uraeus/2010/10/07/echo-cancellatio...

MeeGo beyond the mobile device

Posted Nov 18, 2010 11:22 UTC (Thu) by ortalo (subscriber, #4654) [Link]

Amusing article patch:
Access to home content, *also* "require some security mechanism with which" device owners "can implement mandatory access control on specific content".
This does not include DRM, but I'd be delighted to see it include software modules (or even hardware-chain-of-trust) that can prevent unauthorized third parties from accessing personal content or driving general-purpose hardware.

I wonder why device builders do not focus more on end users concerns.

MeeGo beyond the mobile device

Posted Nov 23, 2010 21:32 UTC (Tue) by n8willis (editor, #43041) [Link]

Not to be too cynical, but my prediction would be that the moment someone in the video entertainment industry demonstrably makes a single dime by putting "end users concerns" front and center, the race will be on.

Nate
PS - which I *do* predict is bound to happen some day; once companies saw other companies making money selling un-encrypted audio files, a glut of competing businesses started to do it, too.

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds