08.03.10
Grilo session at GUADEC – slides
For those interested, you can find the slides of my presentation on Grilo here.
06.11.10
Grilo at LinuxTag
If you are in Berlin for LinuxTag and you are interested in Grilo or you are simply curious about it you probably want to attend my presentation: ‘Seamless Integration of Multimedia Services’ tomorrow at 4:00pm in room Berlin II.
05.10.10
Grilo 0.1.5 is out
Juan released version 0.1.5 last Friday, the most important updates are:
- The new Vimeo plugin, thanks to Joaquim Rocha
- The Youtube plugin is now using libgdata
There are also a bunch of bugfixes and other minor improvements. For details check the announcements on the mailing list, here and here.
04.19.10
Grilo at GUADEC
This weekend I got a confirmation from the GUADEC organization that my talk “Grilo: Feeding applications with multimedia content” has been accepted. That’s great news, I am really looking forward to delivering this presentation and get feedback from other GNOME hackers about what we are doing. See you all in The Hague in July!
04.06.10
Moving Grilo to GNOME servers
Grilo is now hosted by GNOME, thanks to Olav Vitters, Ray Wang and Paul Cutler for their help and support with this!
This means:
- Source code has been moved from Gitorious to GNOME.
- We have a mailing list
- We will get Bugzilla support soon
For more details on Grilo and related resources check the project description page on live.gnome.org.
03.12.10
Grilo and Rygel
After knowing about Grilo, Bastien proposed to use it as a helper library to implement Rygel’s MediaServer D-Bus API spec. This D-Bus API specifies how content providers can expose content over D-Bus that Rygel can consume and then export to the UPnP world. Although this spec was developed for Rygel in particular, it aims to be generic enough so other applications could use it to consume content over D-Bus directly.
The idea is to decouple providers and consumers, this way one does not have to worry about the language they are written in and providers don’t have to be loaded in the consumer’s address space, instead they are communicated through D-Bus.
So, what could be Grilo’s role in this context? As you know, Grilo is a pluggable framework that provides a single, high-level API to consume contents from various sources (Youtube, Jamendo, SHOUTcast, etc) which are implemented as plugins for the framework. As such, the role of Grilo would be that of a content provider. Juan has been working on a daemon that would use Grilo to get access to all the content exposed by the framework and expose it over D-Bus according to Rygel’s MediaServer spec. This will enable Rygel (or any other application), to get access to all this content over D-Bus.
As of today, I think only Rygel has implemented the consumer side of this API, but the idea is that in the future other applications like Totem or Rhythmbox would have plugins to consume it too. Also, since Rygel is a UPnP server, and it is feeding on Grilo through this D-Bus interface, it is also exposing Grilo’s contents to the UPnP world, so any UPnP client should be able to access these contents over UPnP thanks to Rygel. Totem for example, has a UPnP plugin already, and because of that it can consume the contents from Grilo through Rygel even when it does not implement the consumer API of the MediaServer spec.
If you are interested in more details check Juan’s post here. There you will also find a screencast showcasing a Grilo-powered daemon that’s exposing content from various of its plugins over D-Bus, then Rygel feeding on that and exposing them over UPnP, and finally Totem consuming all the content though its UPnP plugin. Of course, you may ask why wouldn’t Totem feed on D-Bus directly, well just because it has the UPnP plugin already and not the D-Bus one, but it will come 
.
Talking about that, another thing that Bastien proposed and on which we will be working too, is a set of helper libraries to ease development of content producers and consumers. On the producer side (backends) the idea would be to hide all the D-Bus stuff and provide a clean, easy to use interface for exposing content to the bus (for those not wanting to deal with D-Bus directly), and on the consumer side (frontends), we could do the same and maybe add some extra bonus stuff, like widgets to manipulate available sources and the like.
03.01.10
Grilo on Totem
In my last post I mentioned I was working on a Totem plugin based on Grilo, last week I put some more effort on that and I got a beta version, you can check out some pics below:
Browsing and playing videos from Youtube
Browseable sources
Searching images on flickr
Searching Guadec videos on Youtube
Browsing content from Jamendo
I have also recorded an ogv video showing the plugin at work in more detail, you can check it out here.
Also, I uploaded the code to gitorious if you feel curious about it. If you want to build the plugin from the sources check the HACKING file on the repository. Also, I suggest you build Grilo from the sources as well or wait for the release 0.1.3 which should be coming out later today.
Now to the more interesting part, the good thing about Grilo is not just the plugins, it is the fact that you can interact with them with a common API. As a matter of a fact, I could now add more plugins to Grilo and those would show up in Totem without having to code anything extra, not a single line on Totem or its Grilo plugin, it would just work: you would be able to browse the new plugins if they are browseable in the Browse view and/or you would be able to search them if they are searchable in the Search view, etc.
The plugin is not really finished, it can still use some extra work, particularly in these areas:
- Localization support.
- Proper user interface definition with GtkBuilder.
- Settings persistence with GConf.
- Usability tweaks
- Review memory management, fix memory leaks, etc
- More testing and general debugging.
but all in all, it is good enough already for others to try and give feedback, so if you have any, please drop me a comment! 
That’s all for now, I am looking forward to seeing this on the upstream Totem at some point in the future, so if some Totem developer is reading this, please let me know how you feel about that.
02.24.10
Updates on Grilo
Some updates on Grilo since my announcement post (in chronological order):
- Juan is packaging Grilo, check details here.
- We have bindings for Vala thanks to Víctor Jáquez.
- Grilo 0.1.2 is released, check this post for details.
- We have a plugin ranking system now. This is used when you request Grilo to resolve metadata for a particular media object and there are various plugins capable of doing so (imaging for example that you have two plugins for resolving the album art or the lyrics, etc).
- We have set up a PPA for Grilo on Launchpad, details here.
- I am working on a Totem plugin, so far I got a first prototype working and I can use Grilo sources from Totem enabling me to browse and play content from all the Grilo plugins. Now I need to focus on adding a few more features and configuration options.
02.10.10
Grilo
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…