Words from the inside

of Igalia

MAFW, what’s up?

| 5 Comments

Some weeks ago, Maemo 5 Beta 2 SDK was announced. Eleven weeks passed since the first version. During this time, we have been working hard in MAFW, the multimedia framework that comes in Maemo 5. Most of the work we did consisted of bugfixing and improving the framework, while keeping as much as possible the current API.

What are the main differences in MAFW between Beta 1 and Beta 2? Basically bugfixes and improvements, but other changes happened too. Let’s summarize the changes in the new versions of mafw, mafw-shared, mafw-tracker-source, mafw-upnp-source, mafw-iradio-source, mafw-gst-renderer and mafw-test-gui:

  • Volume is now managed through PulseAudio.
  • The uPnP source now can handle uPnP servers with transcoding support (like Rygel). Thus, mafw-upnp-source is able to provide all the links from a specific uPnP item, and mafw-gst-renderer will use the link that can be played.
  • Added new metadata keys.
  • Added new error codes.
  • Added a new function to get the current media’s object ID and its metadata from the renderer (mafw_renderer_get_current_metadata). So far, the way to get metadata from an object ID was through the source’s API. But sometimes renderers are able to find new information while they are playing. An example is when playing an internet stream. This information was sent at the same time it was discovered, but now this new function allows to query it at any moment.
  • Added a new function to get metadata from several media’s object ID at the same time (mafw_source_get_metadatas).  In previous releases, mafw_source_get_metadata function was provided to get metadata from a single object ID; if several metadatas for several objects were needed, we had to invoke mafw_source_get_metadata several times. As it is quite common trying to get metadata from several object IDs, we have added a new function that works like mafw_source_get_metadata, but allows to specify several objects instead just one.
  • Sources can now notify clients when they are updating. Imagine that suddenly, thousands of multimedia clips are available. Sources can take a while until all this clips are available to be used (for exampe, after copying them). In our case, mafw-tracker-source uses tracker to index all the clips, and tracker could take a while to index all the new clips. How a source can notify the client that it is updating its content (or specifically in the case of mafw-tracker-source, that tracker is indexing the new elements)? We have added a new signal to sources, updating, that it is used to notify when the source is updating. It does it by telling the percentage of completeness, how may elements has been processed, how many items remain to be processed, and the estimated time to finish the update. Besides this new signal, a new function has been provided, mafw_source_get_update_progress, which can be used to ask at any moment if a source is updating. All these new functions are meant to those sources that can take some time to update their content; therefore, not all sources uses this signal (right now, only mafw-tracker-source use it).
  • Extended MAFW_METADATA_KEY_CHILDCOUNT. This is, perhaps the only break in the API. Browsing in MAFW sources is thought to be hierarchical. In the case of mafw-tracker-source, for example, below Music category are Playlists, Songs, Genres, Artists and Albums. When entering in Genres category, a list of all available genres are shown. At the same time, browsing through one of the genres, the list of all artists for that genre are obtained. Following one of those artists, we would get the list of albums for that artist and genre. And finally, browsing through a specific genre, artist and album, the list of all clips for that genre, artist and album will be obtained. MAFW_METADATA_KEY_CHILDCOUNT listed the number of elements in a branch. For example, the value of this key for the Genres category was the number of available genres, while the value for a specific genre was the number of artists in that genre, and its value for an artist got the number of albums for that artist in that genre. But how to get the number of albums of a specific genre? So far, it was not possible to do it in a direct way, and workarounds were needed. But we changed this childcount key, so it now uses a parameter to tell at which level are we interested. Thus, for example, when requesting metadata from a specific genre, MAFW_METADATA_KEY_CHILDCOUNT_1 is the number of artists in that genre, MAFW_METADATA_KEY_CHILDCOUNT_2 is the number of albums in that genre, and MAFW_METADATA_KEY_CHILDCOUNT_3 is the number of clips in that genre. Up to 9 levels are provided in MAFW, but the user can use the macro MAFW_METADATA_KEY_CHILDCOUNT to build the level she wants. Of course, it’s up to the source to be able to resolve the value for that level. It’s worth to mention that this is a compatibility breakage, as in previous versions MAFW_METADATA_KEY_CHILDCOUNT was a proper metadata key, but now it’s a macro to build new keys. Therefore, applications based in previous MAFW releases that were using this key must update to use the equivalent one, MAFW_METADATA_KEY_CHILDCOUNT_1.

As it can be seen, few changes happened, and most of the work was targeted to fix bugs and to improve the framework. We tried to keep the same functionality as possible. This helps people trying to implement their own player, providing a stable platform were to develop. So give it a try and implement your own player or utility for Maemo 5!

5 thoughts on “MAFW, what’s up?

  1. Will MAFW be replaced by Phonon in Maemo 6/Harmattan?

  2. The multimedia stack in Harmattan is basically an evolution from the same stack in Fremantle, with some Qt adaptation in MAFW. Phonon is not used.

    See also Stefan Kost’s slides in the Desktop Summit to know more about the Maemo multimedia stack: http://www.buzztard.org/files/guadec2009_multimedia_in_your_pocket.pdf

  3. Hi Juan, you say “So give it a try and implement your own player or utility for Maemo 5″. This is the point…who would try to code his onw multimedia player before the official Fremantle media player is out?

    Usually a developer codes a new mediaplayer if the official one is not opensource and if it misses some funcionality, but at this moment no one in the community can know how the final media player will be…

    For example: will be able to scrobble to Last.Fm? Will be able to share its music with DAAP or UPnP like Rhythmbox does? Will support plugins? Will be able to play .ogg files? Ecc….

    I know we can use “imagination” and think: well… if MAFW is the main multimedia framework, is it possible that the official client will be based on it, and since MAFW supports plugins… we can implement all this stuff.

    In this case it would be better to convince people to write MAFW plugins insted of coding their own multimedia player.

    What do you think about?

    • Of course, writting MAFW plugins is better than writting your own mediaplayer. I totally agree with you. But you can do both of them. Learning the new API or porting other mediaplayers available in Diablo are a good reason to implement “things” on top of MAFW (and by “things” I mean mediaplayers or any other client you can imagine).

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>