Attending the GStreamer Conference 2017

This weekend I’ll be in Node5 (Prague) presenting our Media Source Extensions platform implementation work in WebKit using GStreamer.

The Media Source Extensions HTML5 specification allows JavaScript to generate media streams for playback and lets the web page have more control on complex use cases such as adaptive streaming.

My plan for the talk is to start with a brief introduction about the motivation and basic usage of MSE. Next I’ll show a design overview of the WebKit implementation of the spec. Then we’ll go through the iterative evolution of the GStreamer platform-specific parts, as well as its implementation quirks and challenges faced during the development. The talk continues with a demo, some clues about the future work and a final round of questions.

Our recent MSE work has been on desktop WebKitGTK+ (the WebKit version powering the Epiphany, aka: GNOME Web), but we also have MSE working on WPE and optimized for a Raspberry Pi 2. We will be showing it in the Igalia booth, in case you want to see it working live.

I’ll be also attending the GStreamer Hackfest the days before. There I plan to work on webm support in MSE, focusing on any issue in the Matroska demuxer or the vp9/opus/vorbis decoders breaking our use cases.

See you there!

UPDATE 2017-10-22:

The talk slides are available at https://eocanha.org/talks/gstconf2017/gstconf-2017-mse.pdf and the video is available at https://gstconf.ubicast.tv/videos/media-source-extension-on-webkit (the rest of the talks here).

Libertexto 1.0 has been released

After months of collaborative work of a multidisciplinary team directed by Rafael Ibáñez and with the participation of Igalia, version 1.0 of Libertexto project is finally out.

Libertexto is a Mozilla Firefox extension that allows the user to perform typical text comprehension tasks on electronic documents in the same way they’re performed on printed documents. Such tasks include highlighting, annotation, tagging, multimedia content linking, organization and exporting. The extension comes in two flavours: a lightweight version that only supports HTML pages and a full version that also supports PDF documents.

There aren’t many open source tools able to annotate PDF documents out there, so I’m convinced that Libertexto will satisfy a growing demand for this feature. To accomplish the goal, some customizations have been developed on top of Evince 2.28.0 to make it able to communicate with the Firefox extension and to manage the document annotations both in Windows and in GNU/Linux. Evince is embedded into Firefox by a custom plugin that is responsible for launching it and preparing the environment for the window embedding. For the curious readers, more technical details about the embedding process can be found in a previous post about Libertexto.

With this contribution, we expect all the reader community in the Spanish speaking world (the only language available by now) to have a new and powerful tool for text comprehension and commenting. Enjoy it!

UPDATE 7/3/2011:

At some point all the code sould be put together for proper download, but by now it’s scattered among different locations: The source code of the Firefox extension itself can be got by unzipping the XPI file. The source code of the modifications done over Evince can be got from gitorious and the source code of the PDF plugin can be got from here.

UPDATE 3/6/2011:

The new Libertexto 1.1 version is ready for download at libertexto.org. It corrects some compatibility problems with Firefox 4 in Linux, WinXP, Vista and Win7. If it seems that the install doesn’t work directly from the link, just download the file to the desktop and then drag&drop it to Firefox. An experimental version newer than 1.1 is also available in /dev/libertexto/libertexto.xpi. It fixes a bug that prevents the extension to work when the user account name had more than 8 characters, due to a path length limitation in Firefox on Windows.

Meiga 0.4.0 “end of the year” release

I didn’t want to finish the year without devoting some time to Meiga, so I took advantage of Christmas holidays and prepared a new release with some long awaited features that make it a more serious tool:

  • Dynamic port change
  • SSL support
  • Persistent settings storage
  • Password protection

Latest information, including the source code, install instructions and previous versions can be found in the project website: http://meiga.igalia.com

Happy new year!

Libertexto: integrating Evince into Firefox

These months I’ve been collaborating in Libertexto development. Libertexto, a project coordinated by Rafael Ibáñez, will be a Firefox extension whose goal is to allow the user to do some text comprehension tasks (highlight, add annotations and create bookmarks) and concept mapping tasks (manage a tree of “lexias” or units with semantic content) on HTML and PDF documents.

Multiplatform

So far, I’ve mainly been involved in the task of integrating Evince into Firefox. The goal was not only to provide support for PDF document viewing, but also to adapt Evince to manage the communication with the Firefox extension and to provide the required functionalities and GUI interaction. The fact that Libertexto has to work both in Linux (Ubuntu Jaunty) and Windows made the task more challenging and had an important influence in the design decissions.

libertexto_windows

The plugin

The main idea was to write a plugin registered to visualize documents having the “application/pdf” mime type, using Evince for that, and interact with the XUL/Javascript code to coordinate everything. The npsimple (check my npsimple backup link) example was very valuable to learn how to code a multiplatform basic plugin implementing the Netscape Plugin API (NPAPI). These first testings (with the help of Dependency walker) showed me that the plugin code would only load if compiled with the same compiler used to build Firefox. That means forgetting Cygwin, MinGW32 and other Windows platform free stuff and compile using Visual C++, getting the headers from the Mozilla SDK.

Communications: first try

Once I had a plugin that did nothing, I looked for ways to communicate it with Firefox. I tried some XPCOM examples and debug tools without much luck, so I finally decide to use alternative ways of communication when I needed to.

Compiler restrictions

At this point I focused in compiling Evince for Windows. I chose Evince 2.28.0 because it had been already compiled for Windows by Hib Eris. I found him in the #evince IRC channel and he pointed me to the Ubuntu PPA he had used to cross compile for Windows using MinGW32. He also confirmed to me that mixing MinGW32 compiled apps with MSVC compiled apps is a problem because MinGW32 compilations are dependant on msvcrt.dll, while recent MSVC compilations depend on msvcrt80.dll or msvcrt90.dll. That explains why I couldn’t compile the plugin with the MinGW32 toolchain from Windows. Forget also about converting Evince itself into a plugin (implementing NPAPI), because it won’t load. There’s currently no easy solution, but to compile everything with MSVC (not tried before) or keep applications split.

Embedding the window

After having compiled Evince and all its dependencies for both operating systems I modified the plugin to start Evince each time a new document was loaded. Next step was to find a way to embed Evince in Firefox, because having it as an independent window was not an option. The plugin was given a window ID (XID in X11, HWND in Windows), so I modified Evince to receive it as an extra parameter and use gtk_window_reparent() to “hijack” the window that Firefox provided. Of course, using Mozplugger is much easier, but it’s not supported in Windows, so I had to do it by hand. After some tweaking and having to disable DBUS support to get exactly one process per document (in Linux), it worked in both systems. In Windows I ended up with refresh and focus problems, but I didn’t go further.

Communications: second try

At this point, the key was to have a reliable communication system between Evince and the plugin. DBUS would have been good for Linux, but would bring too much problems in Windows (everything should be installed or work from the Firefox extension bundle and I’d need a way to use DBUS from javascript). Standard IPC methods (eg: shared memory) would be a problem too, because I hadn’t managed to successfully develop XPCOM components that could access low level C functions to use that IPC methods. However, there’s one thing that always work: plain old HTTP requests. They are supported in the Firefox side using XMLHttpRequest and in the Evince side using libsoup-2.4. I had experience using libsoup in Meiga, so it wasn’t difficult for me to set up a bidirectional realtime communication middleware using the AJAX paradigm.

The initial port handshake is a bit tricky, though. Remember that there’s no way for the Firefox extension, the plugin and Evince to talk to each other before this handshake. The process is as follows:

  1. The user opens a URL containing a PDF, so the PDF plugin is invoked. If the plugin is in Linux and detects that libertexto hasn’t been installed in /usr/local/libertexto-0.0.5 yet, it triggers the install script and waits until the process is completed. Then continues.
  2. Using dll/so API calls on the first load, the plugin gets the path where nplibertexto.dll/.so is installed (eg: /home/user/.mozilla/firefox/ky712h81.default/extensions/libertexto-0.0.5@libresoft.es/platform/Linux_x86-gcc3). From that path it gets the extension path (...libertexto-0.0.5@libresoft.es) and builds the xid directory path (...libertexto-0.0.5@libresoft.es/xid)
  3. The plugin gets the URL and the downloaded file name through NPAPI. It then launches Evince (fixed location in Linux, variable location under the extension dir in Windows) with the following parameters: evince --xid 0x6800001 --libertexto-path /home/user/.mozilla/firefox/ky712h81.default/extensions/libertexto-0.0.5@libresoft.es/xid /home/user/local_links.pdf.
  4. Evince opens the file, hijacks the window with handler 0x6800001 and starts a web server on a random port of 127.0.0.1 which will wait for incoming connections. Then the port number is written to a file named 0x6800001 in the xid directory.
  5. The plugin has been waiting up to 5 seconds and monitoring the xid directory for new files. When it finds a new one, reads it and inserts the (xid, process id, MD5 sum of the URL, port) into a children array for further use. Each time the children array changes, the file libertexto-0.0.5@libresoft.es/libertexto-docs is regenerated. That file has the URL MD5 sum and port, one line per document.
  6. The file is available as resource://libertexto-docs/ to the Firefox extension and it’s monitored each 5 seconds using XMLHttpRequest (it can also read local files). That way, the extension keeps a table of open documents and their ports.
  7. Each time the extension detects a new entry in the table, it connects to the port using XMLHttpRequest on a special “receive” URL (eg: http://127.0.0.1:53162/receive) and reads and attends any pending messages that Evince would like to communicate. If there are no more messages, just keeps waiting for one to come. When one comes, the network dispatcher in the Libertexto extension attends it, closes the connection and restarts it to wait again. Evince code just enqueues outgoing messages and writes them when the extension (re)opens the connection.
  8. If it’s the extension who wants to send a message to Evince, a request is made to a “send” url (eg: http://127.0.0.1:53162/send?action=test&param1=value1&param2=value2). There’s also another network dispatcher in Evince that processes incoming messages and calls the corresponding function of EvApplication.
  9. When the document is closed, the plugin code is informed by NPAPI and just ensures that Evince is killed, the 0x6800001 xid file is removed and libertexto-docs is rebuilt.

Packaging

It was time to polish a little bit the building and packaging environment. Different binary sets for different platforms can be provided using the platform directory in the Firefox extension package. In Windows, there’s no problem in relocating a GNOME app where you want, as there’s specific code to locate the data and config dirs, but in Linux it has to be installed in a fixed location, so I prepared a very basic installation script for that platform to be executed by the plugin the first time that the user opens a document.

Functionalities

With the infrastructure ready, I started to hack on Evince and implement the required functionalities (and the related middleware messages in both sides):

  • Get the text directly selected by the user
  • Scroll to a specified position of a specified page in a document
  • Highlight some (preselected) text with the specified color
  • Set an “start of selection” internal mark
  • Set an “end of selection” internal mark and then select the text between the start and the end of selection
  • Show the “create new item” option in the context menu and pass that command to the Firefox extension
  • Overimpress an annotation with some arbitrary text
  • Overimpress some icons that would trigger some commands on the current items

For some of them, specially those related to text highlighting and annotations, the advice from Carlos García Campos was very helpful. Shell, view, document and backend layers, the pixbuf cache, the jobs system… Evince is a big project and I needed some time to get used and understand it, but it has a lot of things to learn. I enjoyed very much this development stage. 🙂

When all the PDF side functionalities were completed, I removed all the unneeded GUI options from Evince and adapted the Libertexto extension panel to produce and handle the required middleware messages needed to manage the user interaction.

libertexto_linux

The result

Although the project still lacks part of the control and HTML modules functionalities, I got Evince integration working in this nice prototype.

You can download it as: libertexto.xpi (UPDATE 3/3/2011: you might prefer to download the final Libertexto 1.0 version). Please note that this file will probably evolve, being overwritten with newer versions.

Until the whole project gets released, a shapshot of the Evince branch code is published in Gitorious for you to have a look.

Meiga 0.3.3 released

The two main features of this new 0.3.3 release of Meiga are the new redirection support for FON routers (Fonera v1) and memory optimizations for large files, so serving a video file of 1GB won’t eat up all your memory.

Apart from that, some bugs have been solved, the autotools config has been updated (thanks to Javier Jardón), a startup notification has been added (thanks to Rajeesh K Nambiar) and the file size is now passed to the browser, so you’re going to have now a decent progress bar.

As always, you can download it from http://meiga.igalia.com.

Shishen Sho compiled for N900

I’ve recalled about my old Shishen Sho game, originally developed for N810 (Maemo4) and I was wondering if it would compile for N900 (Maemo5). Well, after some minor corrections to make it work in a more recent version of Vala, it compiled. You can downloaded it here:

https://garage.maemo.org/frs/download.php/7573/shishensho_0.3.1-maemo5_armel.deb

Disclaimer: It’s compiled “as is”, with no adaption for sliding menus, no new hardware keys and no new fancy features. It just works and will let you have a good time while waiting for the bus.

Meiga 0.3.2 released

This new release doesn’t use GtkBuilder anymore, so the GUI problems caused by incompatibilities between GtkBuilder versions shouldn’t be noticed now.

Files are now iterated instead of being mapped into memory. This makes Meiga a little bit slower but allows execution on low memory machines, as suggested by Steven.

Meiga now also works in Karmic. Just use the Jaunty packages and they will work fine. You can get it from http://meiga.igalia.com.