I just booked my travel and hotel to visit the Ubuntu Developer Conference in Copenhagen at the end of October, along with Michael Hasselmann and Mathias Hasselmann, all of us representing Openismus.
I think this will be my first UDS since UDS, Mountain View in 2006 and half a day at UDS, Prague in 2008. Lots has changed since then.
Here’s an update since my last status post in June.
Things have improved for Openismus even more though we are not complacent. Several proposals, including the ones I mentioned in that last blog post, have resulted in customer contracts. So we are now busy working on the Maliit input method system (virtual keyboard), Wayland, Rygel UPnP/DLNA and Evolution Data Server (EDS). We are even thinking of hiring another developer if we can find someone who is just right.
We are now established in the habit of creating proposals for customers, revising them, and shifting into implementation. We take our customer proposals seriously, making sure that the developers are the main authors and making sure that they don’t leave questions unanswered. If there’s something we might help your company with then we’d like the chance to convince you too.
Michael Hasselmann is now the main person negotiating new work for us and keeping some of that work on schedule. He has been very successful – a surprise to himself but not to us. We are calling him a Sales Engineer but that doesn’t really do his dedication justice.
Michael can travel much more than I could for the last few years. Right now he’s at the Automotive Linux Summit in the UK and tomorrow he will be at the X Developers Conference in Nürnberg with Jan Arne Petersen (where our interest is mostly in Wayland and input methods). On Monday and Tuesday he’ll visit me in the Munich office.
We have achieved this thanks, of course, to the hard work of our whole team at Openismus. They have fought hard so we can all keep doing worthwhile work that we enjoy. I am proud of them and glad to be part of this.
As I mentioned in March, Openismus is now down to a small core of super developers.
Jon Nordby and Michael Hasselmann are now fully involved in finding new projects, and traveling when I cannot. This month we were relieved to get the go-ahead on projects for two new customers, for work on the Maliit on-screen keyboard. Those are our first new customers since Nokia disappeared. Hopefully we can talk about them soon.
However, this is still not enough work for us to feel particularly safe. So we have spent some time on open source work that we hope will attract attention by customers who want more of the same. Don’t hesitate to contact me if you’d like our help.
Rygel currently provides a UPnP and DLNA Server, serving media to DLNA Players and Renderers such as TVs, smartphones, and speakers. It has achieved UPnP and DLNA Certification as a server in the Nokia N9 smartphone, thanks to work by Openismus and others.
But Rygel also already has some mature support for software that wishes to be a DLNA Player. With some work, this could let a GStreamer-based media player become a DLNA Player, able to play video, music, or pictures from DLNA Servers. We believe it could achieve DLNA certification as a Player. As a side-effect, this would add some (DLNA standardized) remote-control functionality to the media player.
This is work that Openismus would like to do for a customer. In fact, we’ve done some of it already, but we haven’t published it yet. The rest of this post describes what we’d like to do. UPDATE: Some of this is now done.
A DLNA Player is a device that can access media files on a DLNA server and plays them back.
A DLNA Player must implement a DLNA Controller (Known as a Control Point in UPnP terminology) that implements the “Browse” operation, to request data from the DLNA server, and must be able to play media in its own UI.
The user interface could either:
As inspiration, we can use code from the Helium (a UPnP control point) and Korva (a daemon used by PushUp) open source programs, We have tested both against the DLNA tool and they seem to pass quite well.
DLNA Servers provide media via HTTP streaming, so any GStreamer-based player can easily play that content via the souphttpsrc element. Rygel’s own (unfinished) Renderer (its playbin plugin – see below) uses this souphttpsrc element. (Note that souphttpsrc does not use SOAP, and use of SOAP is not required for basic playing. souphttpsrc’s name is based on its use of libsoup, which once also did SOAP, but now does not.)
DLNA Servers may additionally support RTSP as an alternative to HTTP, but GStreamer also has support for RTSP. Most DLNA Servers only support HTTP.
The Player must support some standard media codecs according to the DLNA Profile that it claims to support:
The minimum for “Home networked device” (meaning it is usually connected via Ethernet, is rather stationary and is powerful):
The minimum for “Mobile networked device” (meaning it is usually connected via Wi-Fi, can be carried around and is less powerful):
Most of the formats (MP3, MPEG2, AAC, H.264) have their own license and patent issues. MP3 could be covered by using the Fluendo plugin while MPEG2 and H.264 are usually covered by using a DSP-based implementation. Commercial software decoders without dubious copyright for MPEG2, H.264 and AAC used to be available e.g. from MainConcept, though of course not as GStreamer elements. Device vendors still need to make an agreement with the MPEG-LA if they are not already in that patent pool, depending on the predicted sales volume. The MPEG-LA usually doesn’t care what implementation is used, we believe.
DSP integration in GStreamer already exists for SOCs made by TI (The OMAP/DaVinci family). For TI there are two alternative techniques:
Instead of relying on vendor-specific implementations, the preferred way seems to be via OpenMAX. GStreamer elements for that are included in upstream and freely available.
The MainConcept software decoders basically have a function that takes a blob of encoded data and spits out a blob of decoded data. It should be relatively easy to get a basic GStreamer element going. A Demo SDK is only available upon request and after signing an NDA. As with most commercial software, getting bugs fixed in them is next to impossible.
A DLNA Player does not need to be a DLNA Renderer (which could be controlled by another Controller, such as a remote control, for instance to pause or to change color settings). However, we think it would be wise to implement DLNA Renderer, despite the extra work, because:
These are the DLNA Renderer services which could be used by a remote control DLNA Controller device:
Rygel already provides a simple Renderer via its “playbin” plugin, which uses GStreamer’s souphttpsrc and playbin2 elements. However, this currently just displays directly to the screen and runs out of process, so it would need to be refactored as a shared library (the code is already LGPL). This would avoid interprocess communication of media data, and allow direct manipulation of the playbin2 GStreamer element, for instance, to tell the playbin2 to use the media player’s own display sink.
This already provides the Renderer services needed by a Controller (see above). However, some work would be required to achieve certification.
The “Player” device class does not exist yet in UPnP. However, since February 2012 a DLNA Media Player (DMP) must have an UPnP certification. We are not sure yet exactly which UPnP certification is required but we assume that it is a UPNP-AV Controller certification with only the Server-side interaction tested. This would need clarification with DLNA.
UPnP certification requires use of the UPnP Certification Test Tool, which runs on Windows and is available to Basic UPnP members, though you need to be a UPnP Implementor member to go through the Certification process.
During UPnP certification the device must support Link-Local address generation. This is only necessary for the sake of the UPnP certification and does not need to be present in the actual device. NetworkManager seems to do either DHCP or Link-Local. For example to achieve this on the N9, we set a special gconf key to enable Auto IP fall-back only for testing. The production devices can’t do Auto-IP out-of-the box. This is of course not possible with DLNA as you have to send a production device, but one can request a “Auto-IP voucher” during device registration which removes the requirement. For a pure software certification this does not apply of course.
The Player’s interaction with a DLNA Server would be based on GUPnP, whose basic UPnP technologies, such as discovery, eventing, and message syntax have already been well tested during the Nokia N9’s DLNA Server development and certification.
As mentioned above, we have also informally tested Helium’s control point implementation against UPnP. The test run shows a pass in the basic plumbing and for all mandatory operations from the control point requirement documents (connection manager, content directory, control and AV transport).
UPnP testing is done in-house. A log file from the test tool together with a packet capture of the test run is then sent to the UPnP forum via its website. The UPnP forum checks the result and awards a certificate. Certification is usually bound to a device and free of charge. See http://upnp.org/sdcps-and-certification/certification/how-to-certify-a-device/
The test tool does its testing partly automatically, if the Player also supports Renderer (see above), and partly by requesting user interaction, either to use the Player’s UI, or to plug and unplug the network cable.
We have already informally tested the current version of Rygel’s Renderer (playbin) plugin, which we recommend that we use (see above).
The full test results are probably confidential according to the UPnP software license, so we probably cannot share them. However, we will summarize the results here:
The test result shows that we pass everything in the basic UPnP plumbing: discovery, eventing, syntax. We also pass every test that was marked as supported by our implementation. This includes all mandatory operations as defined in the relevant UPnP specification documents as well as the optional “Pause” operation.
Special attention must be paid to the required media formats. Most of them are proprietary and might need additional licenses. Those formats are:
The main issue will be with the HTTP implementation of whatever displays the media. For instance, if GStreamer is used, it needs to include the fix for Bug #676020.
DLNA Certification requires use of the DLNA testing software, which runs on Windows. Any company would need to become at least a DLNA Contributor member. The membership includes access to the DLNA guidelines (a hard copy can be bought by everyone for 500 USD).
The testing software does its testing partly automatically, if the Player also supports Renderer (see above), and partly by requesting user interaction, either to use the Player’s UI, or to plug and unplug the network cable.
DLNA testing is a two-step process. First a test run is conducted in-house. The device is registered and the results from this test are then sent to the DLNA which check if it’s “worthy” for certification. Then the device needs to be sent to a certification laboratory where the same tests are done according with the registration.
UPnP certification is a pre-requirement for DLNA certification. DLNA certification is usually bound to a device, but it’s possible to certify software. The only certified software so far is a controller, as far as we know.
In addition to testing against the certification software, DLNA quarterly offers so-called plug-fests, where members can test their implementations or devices against the devices of other members. Attendance to these is not free, of course, but the experience with the N9 showed that it really helps to sort out interoperability problems early in the process. Fees are usually 400 USD person and 500 USD early bird fee, 1000 USD normal fee per device class, not including accommodation. A special rate for a hotel near to the venue is usually available.
We have already informally tested the current version of Rygel’s Renderer (playbin) plugin, which we recommend that we use (see above).
The full test results are confidential according to the DLNA software license, so we cannot share them, but we can summarize them here.
Our initial test run shows two problems that prevent a proper test run as they shadow most of the real problems:
When we work around these problems temporarily, the result shows that we pass almost everything related to basic UPnP/DLNA functionality. This is hardly surprising because we have achieved certification for the Server functionality already, which shares code. The remaining bugs mostly deal with inconsistencies between the evented state variables and the values returned in explicit queries, and a missing function call that is optional in UPnP but apparently required in DLNA.
Openismus can do this. We can even get it through certification. Clearly we know how.
Please contact us if you’d like us to do this work for your company. We can quickly provide a full proposal with tasks and milestones.
I released stable Glom 1.22.0 a few days ago.
For easy installing, I also created a Glom 1.22 package for Ubuntu Precise, in the Openismus PPA. Ubuntu Precise normally has Glom 1.20. I wish there was some similar way to create packages for Fedora, or someone to do that for me.
Beside the multiple bug fixes, Glom 1.22 has a few new features:
Openismus has recently had to let some great developers, and good friends, go. We are now much smaller.
This is really sad because it took us a long time to find and train these people, and they would be massive assets if the future looked better. Although they will be greatly missed, I am at least reassured that they will have no problem finding new jobs. I do hope that they don’t settle for work that is anything but worthy of their experience and enthusiasm.
This downsizing happened because we are now finally losing the customer work we had from Nokia, as expected since their February 11th 2011 decision to kill MeeGo. Nokia are not our only customer, but they are by far our largest. That gave us the opportunity to diversify, and we tried, but without much success. That failure is mine. On the one hand, it’s unfortunate that we have been so dependent on one customer. But, on the other hand, we would never have been so big for so long without them. I would do the same again without regrets.
I view the last few years of Openismus very positively:
Personally, Openismus has allowed me to work part-time, so I can spend time with my children. My first child was born soon after the company was founded, and for the first year, I worked from home, contrary to the myth that founding a company means working all hours of the day and neglecting your family. The tech industry is excessively male, with little understanding for men who want to share in the work of child-rearing, so I’m glad I had the freedom to work part-time. I am highly motivated to keep this freedom.
This has been a disadvantage, of course. For instance, I strongly suspect that I could win more customer work by traveling more to conferences and to customers on site. That has given good results when I’ve managed to do it. But this is simply an impossibility for someone who needs to take care of kids. I think the custom of business travel might be one of the greatest obstacle to women reaching top executive positions. It’s one of many things that won’t improve until men are forced to share more of the burden.
So, Openismus goes on, with some uncertainty. Our specific expertise in the Maliit input methods, in the QtContacts and EDS contacts systems, and in DLNA via Rygel should be very attractive, but time will tell. If you need help with GTK+ or Qt on Linux, from people who really know how, and are not afraid to tell you how, then we are still here and still ready.
Over the last few months I have developed the habit of writing tests when fixing bugs in Glom. These run during “make check” or “make distcheck” so I can be sure that the bugs have not come back. (I know these tests should be smaller and even more numerous, but I can’t yet see a sensible way to break them up).
I had to do lots of build-system and code work to make this possible, because some code had to be moved out of the UI code, and many tests depend on a temporary local server instance. But now, it’s easy to add new tests and it feels so good.
When the tests succeed I have a feeling of confidence in the code, instead of a feeling of uncertainty. When they fail I feel glad that I had a chance to fix a regression before releasing a new version. I am surprised at how much more enjoyable this has made coding.
A few Openismus people will be at FOSDEM In Brussels this weekend. FOSDEM is always a great conference, but I can’t be there myself as my travel is generally limited by the need to take care of my kids.
Michael Hasselmann and Jon Nordby are both giving talks about the Maliit input method framework, as seen on the N9. We are eager to find customers who need our help to integrate and improve this only real choice for an open-source on-screen keyboard. So we hope that some people of influence take the opportunity to get to know the project and its excellent developers.
Jens Georg is also giving a talk about Rygel, used in the N9 to support UPnP and DLNA. For German speakers, there are already video and slides online of a recent talk that Jens did about Rygel in Berlin for Deutsche Telekom’s Developer Garden. I was amused to discover that DLNA had specified themselves into a situation where a minimum certified server and a minimum certified receiver were only able to share a small resolution JPEG format. Apparently it’s getting better, and Rygel can deal with it all.
Online Glom’s standard UI strings are now translated too, instead of just the strings that are in the .glom files. I added some initial translation files (mentioned here too) but I need people to translate them, please. Feel free to just email the file to me. I am tempted to add them to the desktop UI’s translations so I can copy them across.
I also changed it from using a lang= token in the URL to using GWT’s regular locale= query value, re-simplifying much of my previous Online Glom code to support translations.
Now that I see how each new translation adds another set of gwt-java-to-javascript permutations to the already-slow build, so it now builds 41 permutations, I might switch later from the Constants to the Messages technique for GWT translation, because I don’t think that string lookup will be a big performance problem.
Glom‘s files can contain translations for the various table names, fields, relationships, choices, layout groups, reports, etc. This lets multiple people use the same database UI in different languages. Glom doesn’t require programming, so the .glom files don’t use gettext. But Glom can export the translations to .po files so translators can use their familiar tools. This week I added some command line utilities to do that more easily, plus some make rules to use them on the Glom examples.
I can now type “make examples_export_po” to export .po files and “make examples_import_po” to read the improved translations back into the Glom example files.
I put the .po files in Glom’s git repository, hoping that people will translate them, and maybe add more .po files. I wonder if these could even show up on Glom’s l10n.gnome.org page. Update: They do show up there now, thanks to Claude Paroz, and we already have some translations.