Antognolli's blog

LinuxCon Brazil presentation

2011-12-07T02:00:00Z

Recently I attended at LinuxCon Brazil, did a presentation and still had the chance to attend to some interesting talks.

The presentation was given together with Bruno Dilly, about EFL focused on embedded devices. Besides some previous similar talks about EFL, this one was more interesting and quite different, since we didn’t talk much about how to write a program using it, but instead focused on its advantages, presented some real use cases and tried to show off where one can take more advantages from these libraries.

You can see the presentation slides online on Bruno Dilly’s post, or get the slides here.

Overall the event was very interesting, with some nice keynotes and presentations. Two of them that draw my attention were Eugeni Dodonov’s talk about the Linux Graphical Stack, and Daniel Frye’s keynote about the 10+ years of Linux at IBM, which exposed how IBM’s LTC (Linux Technology Center) started trying to contribute with Linux, what they did wrong and how they fixed it.

In addition to our talk, 2 more guys from ProFUSION were presenting their talks: Lucas DeMarchi did a talk about how to become an open source developer and Gustavo Barbieri presented two talks: “Tips and Tricks to Develop Software for CE product on Low-End Hardware” and “Demystifying HTML5” with Sulamita Garcia (Intel).

That’s all for now, and hopefully there will be more presentations coming on next events.

Emotion backend: generic

2011-09-27T03:00:00Z

Emotion is the EFL library that handles audio and video playback. It had only two backends: gstreamer and xine. But recently, Zodiac Aerospace asked ProFUSION to integrate a VLC backend that was being developed originally by Hugo Camboulive. After analyzing his current work, we figured out that it could be used to integrate not only VLC, but other players. The end result of this work is a generic backend and a brand new vlc plugin for it.

This generic backend executes a separated player (its plugin) in another process. It receives the bytes to be drawn on the Emotion object through a shared memory, and communicates/controls the player through a pipe. The pipe file descriptors to be used are sent to the player through command line arguments, leaving the standard input/output free to be used if necessary.

The player must receive and send commands defined on a common file called Emotion_Generic_Plugin.h, which can be included for easier implementation. However, there’s no need for the player to link against Emotion.

How does it work?

When the module is initialized for an emotion object, it starts another process that runs the specified player. The player command line is specified using:

emotion_object_module_option_set(object, "player", <command_to_player>);

A player using libvlc is being provided now, and the generic module internally checks if the command given was “vlc”, in which case it will use this provided emotion-vlc player.

When a file is set to this object, Emotion sends the file name to the player, and expects an answer that will tell that the player already decoded a bit of the file, and the video size is already set on the module, so it can allocate a shared memory with correct size.

The module then allocates the memory, sends a message to the player and expects an answer. After this last answer, the “open_done” signal is sent and the module knows that it is ready for playing. Commands issued before the module being ready are now applied (and play is resumed if necessary).

During this setup stage, info about the file set will be stored in the module, so commands like meta data get, length get and so will be available to sync calls like emotion_object_play_length_get().

The playback phase occurs by VLC writing the decoded video data on a shared memory buffer, which will be used by Emotion to display the decoded frame. A triple buffering mechanism is used to avoid tearing, and also ensures that no blocking happens on Emotion when the player is writing the pixels on the buffer.

If the player dies for any reason, a “decode_stop” signal is sent, allowing the program to call play again, and in that case it will be restarted. The playback should start from the same point it was before the player crashed (if the player supports seek on the current media format).

This last point is the main advantage of the generic backend, allowing the program to recover from a player crash. Similar plugins can be implemented using gstreamer and xine, isolating the decode from the program UI using a separated process.

If you have any questions about this backend, please feel free to ask =).

Post number 1!

2011-09-26T03:00:00Z

Well, I’m finally putting my blog online, and hope to have some interesting stuff to post here. I’ll be probably talking a lot about work that I’m doing on EFL, and sometimes on [WebKit] too. And since I’ve been lately also doing some stuff in the game development area, you can also expect some posts on this topic too.

This blog is also powered by nanoc, so I’m probably going to share some thoughts and code for this awesome framework. Although it’s very simple now, I should improve it a little in the near future (but not too much). And at least I plan to publish the template used for this blog, that could be a good start for anyone wanting to start a blog with nanoc with the setup already done. This way maybe I also receive some critics on the way that I implemented things, and can change it to something better.