Grilo: present and future


Published on

This talk will focus on Grilo, a framework which purpose is to provide media application developers with proper tools to access online and offline multimedia. More specifically, Grilo provides:

- A single, high-level API that abstracts the differences among various media content providers, allowing application developers to browse and search content from various services and sources with little work on the application side.

- A collection of plugins for accessing content from 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.

Today, Grilo is already being used by various GNOME applications, such as Totem, Rhythmbox or MediaExplorer and it will have even more relevance in the future of the platform, where it is expected to be a key component of the new multimedia applications.

During this talk we will look at the current version of Grilo, and we will cover the new features that are coming for the 0.2 release: new API aimed to be extensible, new capabilities for filtering, a new design of plugins architecture, support for declarative plugin development, and, of course, the new plugins.

Talk from GUADEC 2012.

Published in: Technology, Art & Photos
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Why Grilo exists What is exactly Grilo, and his components What is coming for the next releases of Grilo
  • Let's figure out we are implementing a multimedia application Roughly speaking, we need to fetch content and play it Let's see what happens when we have the media to play
  • When trying to play a content there are different combinations of options Content can be inside different containers Content can use different codecs The hardware to render the content can have different properties: different sizes, resolutions, some of them can have accelerated hardware, etc. So how to handle all this mess? More important, how to allow the application working even new codecs appears in the future?
  • The solution that most people use is Gstreamer It's a pluggable framework that isolates all those details from the application, so it doesn't need to deal with them Each plugin is in charge of solving one of those details So if a new codec is added, just implementing the proper plugin the application will able to play it
  • What happens with the fetch? Until some years ago, everything was stored locally Hard disks, USB pendrives, memory cards All these storages shares the same structure: they are a filesystem So using a filesystem API like syscalls, GIO, or other, you can fetch the content to play But this was until some years ago.
  • Now, everything is connected Content can be everywhere: YouTube, flickr, jamendo, etc. Each place uses their own protocol and API But users want to play the content anyway in their devices How is this done? A good example is to look how the TV manufacturers does with their smart TVs
  • As it can be seen, basically each service is a different application, with their own dependencies, and user experience There is no single application to access all the service in a consistent way Looking carefully one of those applications, besides the libraries to implement the UI and to play the content, they use specific libraries to access the content of the service If the application want to support other service, it needs to use the libraries specific for this new service The API is different for each library. But if you think about it, there are common structures in all this services For instance, most services allows to search, which means sending a text and getting the results. The difference is how the application needs to send the text, and how the results are encoded So it would be great to follow the same approach as Gstreamer, and have a system where all these differences are hidden, and have a common API to access the services
  • This is Grilo: a pluggable framework that allows application to discover content and fetch it New sources of information can be added by adding new plugins to the system So now our multimedia application can use the same API to access different services, making it simple and reusable
  • Let's see the main components in Grilo Basically, Grilo is composed of several sources that provide the multimedia content containing the information requested by users (titles, artists, albums, urls, so forth) User uses the registry to know the available sources and also what information can be requested, which are the metadata keys
  • Sources provides the content This is the extensible part: plugins can be added as dynamic libraries, which can be loaded and can create one or more sources There are two types of sources Media sources provide new content like audio, video or images Metadata sources extend existent content (coming from any media source) with new information
  • We can see here examples of those sources We have media sources which provide content from YouTube, Jamendo o UpnP servers. Each source is provided by its own plugin. Note that upnp plugin provides multiple sources, each for one server. So when a new server comes up a new source representing it is created, and when it goes away the source disappears There are also a coumple of metadata sources, one for Gravatar and another for thumbnails for music
  • Grilo: present and future

    1. 1. Grilo: present and future Juan A. Suárez Romero <>
    2. 2. Outline● Why Grilo?● What is Grilo?● Next coming
    3. 3. Playing ContentFetch Multimedia Play application
    4. 4. Playing Content Format? ogg, mkv, aviFetch Multimedia Codec? mp3, h264, theora application
    5. 5. Playing ContentFetch Multimedia Gstreamer . application Plugins
    6. 6. Fetching ContentGVFS/GIO/POSIX Multimedia Gstreamer . application Plugins
    7. 7. Fetching ContentOnline/offline contentDifferent protocolsDifferent APIs Multimedia Gstreamer . application Plugins
    8. 8. Fetching Content
    9. 9. Fetching Content Grilo Multimedia Gstreamer . .Plugins application Plugins
    10. 10. Grilo Key Components Plugin registers Registry registers Metadata Metadata Metadata enriches Key Metadata Source 1..* Source Source Data contains Low level API Media Media Media Media provides 1..* Source Source Source High level API Audio Video Image BoxProvided by plugins
    11. 11. Grilo Sources● Provides the multimedia content● Plugins – Dynamic loaded libraries – Each plugin provides one or more sources● Two types of sources: – Media Sources – Metadata Sources
    12. 12. Grilo Sources GrlMediaSource GrlMetadataSourceGrlYoutubeSource GrlJamendoSource GrlUpnpSource GrlUpnpSource GrlGravatarSource GrlLasfmSource
    13. 13. Grilo Sources● Source can declare new metadata keys● Trade-off between application and plugin developers● Operations – Media source: browse, search, metadata, remove, store, notify changes – Metadata source: resolve, store specific metadata
    14. 14. Grilo Sources ● Cooperation between sources (full resolution) search (tracker, “offspring”, search (tracker, “offspring”, url, lyrics, lyrics url, lyrics, title, thumbnail, thumbnail title, thumbnail, Media Source album) album, artist) artist Application Grilo core API GrlTrackerMedia send creates GrlMedia GrlMedia GrlMediaMetadata Source Metadata Source lyrics thumbnail GrlLyricsSource GrlLastfmSource
    15. 15. Whats coming?
    16. 16. XML Plugins
    17. 17. Caps/Opts● How to filter results? – Filter by type – Filter by specific key● Problems – Support in sources – Too many parameters in function signature
    18. 18. Caps/Optssearch (GrlMediaSource *source,  const gchar *text,  const GList *keys,  guint skip,  guint count,  GrlMetadataResolutionFlags *flags,  GrlMediaSourceResultCb callback,  gpointer user_data);
    19. 19. Caps/Opts● Capabilities (GrlCaps) – Defines what the source can do – Currently, different types of filtering ● Filter by media type ● Filter by key ● Filter by range – Extend for other capabilities ● Sorting
    20. 20. Caps/Opts● Options (GrlOperationOptions) – Defines what the application want to do – Matches the source capabilities – Simplifies the function signature search (GrlMediaSource *source, const gchar *text, const GList *keys, GrlOperationOptions *options, GrlMediaSourceResultCb callback, gpointer user_data);
    21. 21. Plugins Hierarchy GrlMediaPluginGrlMetadataSource GrlLastfmAlbumartSource GrlMediasource GrlJamendoSource
    22. 22. Plugins Hierarchy 1..*GrlPlugin GrlSource GrlMetadataSource GrlMediasource GrlLastfmAlbumartSource GrlJamendoSource
    23. 23. Plugins Hierarchy 1..*GrlPlugin GrlSource GrlLastfmAlbumartSource GrlJamendoSource
    24. 24. Improved full resolution algorithm● Several metadata sources solving the same key – If one fails, try the next one● Dependency not provided by media source – Chain the resolution
    25. 25. Resources● Wiki –● Source code – git:// – git://● IRC – #grilo at● Mailing list –
    26. 26. Credits● Television Icon by The Noun Project (CC Attribution)● Icon Mobile Phone by Jean Victor Balin● Hard Disk Icon by Mazenl77 (CC Attribution)● Memory Card Icon by Custom Icon Design Studio● Vimeo, Flickr, Jamendo, YouTube and UpnP logos under copyright of their own brands● Option by rofltosh (CC BY-NC 2.0)● Hold on by Andrew Pescod (CC BY-NC-SA 2.0)● Train by Andifeelfine (CC BY-NC-ND 2.0)