A long while ago, I contributed to the mozilla plugin in Totem. It worked somewhat, but I kept seeing weird crashes here and there. Unreproduceable crashes, with no clear indication of what’s wrong. Rather than to assume this is related to non-existing issues that I cannot fix and will thus not look at, I decided to have a closer look at the issue, collect facts about the crashes and fix it.
After some research, it appears that mozilla (firefox) unmaps plugins after use and remaps the shared libraries when they’re needed again. That is normal, right? Well, not for me, since this is generally not possible with GObject or glib. The issue is related to type registering and mainloop integration: the Totem mozilla plugin uses dbus-glib for interaction with a separate executable; dbus-glib registers some GTypes, and after a unmap/remap, it will re-register them (because the plugin links to dbus, and dbus is thus reloaded every time the plugin is recreated). However, they already exist in mozilla’s main type register (don’t forget mozilla uses gtk+!), and thus the whole thing collapses. Similarly, it appears dbus-glib does some glib mainloop integration tidbits, and after an unmap of the plugin, the glib-mainloop of mozilla will still call the no-longer existing memory areas in the plugin and this will cause pain and torture.
As a solution, I rewrote the dbus-glib pieces in the plugin to use raw DBus. Nice exercise as for how dbus works, also. The practical consequence of the above is that the mozilla plugin should be a lot more stable in the GNOME 2.14 series. So if you were experiencing odd crashes, regardless of the backend used (Xine or GStreamer), this may well be a good sign for you.
It’s not finished yet. The user experience can be improved a lot, still. I’m currently seeing popups on some sites using multiple media objects embedded in the webpage, telling me that the Xv device is already in use (by the first media object on the page). There’s probably similar issues with the sound device for some people. This needs fixing. Also, performance can definitely be improved, although that may also be related to my crappy download speed…
Contribution facts
It appears Andy misunderstood my comment. I’m not claiming that GStreamer was written by Fluendo. Rather, I’m noticing that most maintainance on GStreamer, nowadays, is done by Fluendo-employed persons. This claim requires data. GStreamer 0.9 core had 86% contributions of Fluendo-employed persons, GStreamer plugins base had 89% contributions from Fluendo-employed persons. The numbers are fairly similar across the other plugin modules. Interestingly, if we count the number of people affiliated with the Nokia 770 project (so this includes the Brazilian Nokia office, Movial, Fluendo and Nokia itself), it gets close to 100% for all modules. As a comparison, the numbers for the 0.8.x GStreamer series are somewhere along the 40%-60%.
What does this mean? It means Fluendo-employed people have been doing pretty much all the work for the currently stable GStreamer series, and they will probably be doing all the maintainance work on it in the near future. Cheers on that, keep up the good work. I hope you guys can fix the issues that I’m seeing, so that I’ll be able to enjoy the recent 0.10 series as much as you guys appear to do.
Script used for those figures is available here, you run it in the directory containing the trimmed ChangeLog of all contributions you want to analyze.
Wishes for 2006
I’ll take my girlfriend to go ice-skating in central park and buy her hot chocolate.
Or, in other words, she saw my homepage (with picture from central park) recently. ;-).