After working for quite some time in MAFW for Maemo I thought it was about time we exported some of the ideas to other platforms, including the desktop, of course. For those who haven’t heard of MAFW yet, you can get a good description of it in the abstract of the talk I gave at GUADEC last year.

MAFW takes care of quite a few things related to high level multimedia development, but there is one in particular I find specially interesting, which is source abstraction. Basically, MAFW defines a set of interfaces for accessing media content providers (a.k.a. Youtube, UPnP servers, local media, radio streams, podcasts, etc). in a generic way (one API to rule them all), easing a lot the effort required on the application side to write modern media players that integrate many of these services.

MAFW was a step forward in this regard, but probably too tied to Maemo in general and to its Fremantle iteration and the N900 in particular. I think the ideas behind MAFW about media browsing are totally valid outside Maemo, however I find its implementation and design packed with Maemo specific (or even N900 specific) choices. I guess this is ok for Nokia since Maemo is its major priority when developing software, but for those willing to export these ideas to other contexts, like me, it is not good enough. And this is is why we have created Grilo.

Grilo is a framework focused on making media discovery and browsing easy for application developers which has been developed following some of the good ideas behind MAFW but with a broader target in mind and adding some extra interesting features as well. In few words, Grilo provides:

  • A single, high-level API that abstracts the differences among various media content providers, allowing application developers to integrate content from various services and sources easily.
  • A collection of plugins for accessing various media providers. Developers can share efforts and code by writing plugins for the framework that are application agnostic.
  • A flexible API that allows plugin developers to write plugins of various kinds.

At the moment, even though we are still starting the work, we have a bunch of plugins already available that provide support for various kinds of services:

  • Youtube
  • Jamendo
  • Flickr
  • Podcasts
  • UPnP

We also have a simple GTK+ test user interface that allows users to browse, search and query these plugins for available media, for those who want to get a grasp on how the framework can be used from an application. We also have a Last.FM album art plugin too.

Grilo is LGPL and its source code is available on Gitorious. We welcome interested users and developers to check it out and provide feedback, patches or new plugins. We are still in the early stages of the framework definition and we are looking forward to incorporate new ideas into it.

The advantages of having a framework like Grilo are easy to spot:

  • Less work on the application side. All the plugin development happens in the framework and application developers can focus on making good user interfaces. It is the same with GStreamer if you think about it, application developers do not have to write decoders to playback content any more, they get the decoders from GStreamer (the framework) and that eases a lot application development. Well, this is the same idea, but applied to media browsing and discovery instead of media playback.
  • Code reuse. There are many media player applications allowing users to access contents from various services. This is nice, but all this is done at the application level, which usually means that all that code cannot be directly reused in other projects. Because of that there are developers writing application specific plugins for all these services in various applications (Totem, Rhythmbox, Amarok, etc), replicating code that cannot be reused directly in other projects. If the plugins were developed on the framework side, all these developers could share efforts and write support for these services only once in the framework, making them available for all the applications using the framework for free. Every one wins.
  • Quick learning curve. Think about it, if you want to write a media player with support for various different media content providers, you would have to learn how to deal with each one of them independently: want to add Youtube videos? go and learn about Youtube data API, want to add music from Jamendo? go and learn about how Jamendo allows you to do that, want to provide access to your local media? Go and learn how Tracker APIs work for example, want to access UPnP servers? then go and learn about using GUPnP, and so forth… this is a lot to learn, and even more code to implement. The framework approach would ease all this, one would only have to learn only one API (the framework API) and that would enable application developers to access all these services through the framework plugins. These plugins act as adpaters for those into design patterns.

I guess this post is getting long enough for now, so I’ll stop here and write more about Grilo some other day…

11 thoughts on “Grilo”

  1. @iain

    I guess most of Grilo’s plugins could feed tracker somehow, so yes, that’s an option if Tracker goes that way. Still, I am not sure about the idea of Tracker storing/indexing Internet content as the way to go for most things but at any rate, I am looking forward to seeing how Tracker performs in that regard.

  2. Looks very promising, especially the high level API.

    I am working on a similar system (in python) with a scope that is a little bit broader than this one, but it’s still in a very early stage.

    It’s essentially it’s the same kind of high level API than Grilo plus a framework to make it possible to write plugins for web-based sources using a declarative syntax instead of actually having to code them. This framework takes many ideas from projects like Yahoo Pipes and Deri Pipes (and of course Gstreamer).

    I might be interested to try to integrate this latter part with Grilo, to make it easier to create plugins for many web based sources in a way that’s accessible to non-C programmers (or potentially to non-programmers as well).

    That said, is there any docs for Grilo ? Any public mailing list or IRC channel ?

  3. @Ugo

    That sounds interesting, I would like to check the feasibility of doing that.

    Right now we are still starting to setup the infrastructure to support Grilo (that is, mailing lists, bug tracker, public docs, etc), the first step was to move the code to Gitorious and let people know about the existence of the project. So right now we still don’t have a mailing list or IRC channel, but at least I will try to get a mailing list soonish and hopefully we will get the other stuff along the way a bit later.

    Still, you can contact me or Juan (the other main developer at the moment) by email using these addresses:

    Then we can help you out understanding how we could integrate that project of yours with Grilo.

    1. @Philip

      Yes, another mate of mine brought that up and I think it makes sense to use libgadata for this. We will probably do that at some point in the future.

  4. Well done, Iago!

    About tracker: miners should be used when it make sense to keep a local cache of the information e.g. references to _my_ flickr information, _my_ favourite youtube videos, and of course local content.

    Other information should not /can not be cached in local (like raw search in youtube or in a huge UPnP server). In those cases, they need to be handled in parallel (probably in different Grilo backends) and merged at Grillo’s level.

  5. shuerhaaken, Wow! A media-player in Vala, thats just awesome anyway but those screenshots look really good. I’ll try to try it out soon. 🙂

Comments are closed.