So Wim, Tim and myself are back from attending the Ubuntu Developers Summit in Mountainview, California. It was a great conference and it was good to see how the Ubuntu community works up close. While I did attend an earlier UDS in Mataro outside Barcelona for a few days this one was a very different experience as multimedia was at the top of the agenda.

The specification for easy codec installation will hopefully help move things forward in userfriendliness quite a bit. Tim wrote the GStreamer
part of with input and help from Wim during the conference. The whole spec is not really tied to Ubuntu so our hope is that the various distro’s will hook their own systems into it just like Ubuntu plans to. My thinking at this point is that we will also hook our commerical plugin offerings from Fluendo into this setup.

Another specification which got a lot of discussion was the audio jumble one where
basically PulseAudio was basically chosen as the way forward. The plans in this area coincides well with the plans of other distro’s as well for example the work and plans of Monty for Red Hat/Fedora. A topic that came up a bit both in the meetings and also in private conversations aftwards was about the relation between pulse audio and GStreamer and the ‘border’ between the two. In regards to the first the answer is pretty straight forward, GStreamer is no sound server and thanks to Lennart we have a good Pulse Audio GStreamer output plugin. When it comes to the ‘border’ I think the broad lines are drawn already, but the finer details will have to be measured out over time. My general answer when asked about it was that I thought Lennart wanted PulseAudio to do more than what we in the GStreamer camp would have it do, but since he was the one doing the coding on Pulseaudio and not us, it wasn’t our place to critisize his choices.

There where also some nice coding done during the conference. Wim implemented full RTP support for both Vorbis and Theora in GStreamer during the conference, meaning that we took a big step forward in being able to provide a free RTP based streaming solution. The next step in the process is to merge in the RTP branch into Flumotion head and get that working with the new RTP modules.

Wim also did a lot of work on Ogg trick modes during the conference and was able to play a vorbis file backwards before we left. Still some more work needed before this works perfectly and also for Theora, but having it supported in a free codec feels good as it has only been implemented in our commercial windows media codecs so far.

As Jono mentioned in his blog there was also quite a lot of buzz around Jokosher at UDS. The effort that has been put into helping out the Jokosher team with resolving bugs in GStreamer and Gnonlin I think is reaping great rewards through the great steps forward that Jokosher is taking. The work on Gnonlin will also yield great returns for Pitivi as most of the issues fixed would have popped up in Pitivi too. The plans for network instruments that where discussed in conjuction with the work done on telepathy was another highlight and something I think could be a real killer feature for both Jokosher and Telepathy.

There where of course many other important topics that was discussed and planned for during the summit. For my own part I found the great work done on improving Bluetooth support to be quite exiting. This was also an example of how Nokia’s increased involvement due to the Maemo and 770 projects continues to be a positive addition to the community and also shows how Nokia strives to be great community memembers be reaching out to the wider Linux/GNOME bluetooth community, like Marcel Holtmann who was present at the conference. The work that Marcel Holtmann is doing in this field is nothing short of amazing and will be a big step up from the current meager offerings of the gnome-bluetooth manager.

The conference also provided a opportunity to hang out with David Schleef again. We managed to squeeze in an evening in San Fransisco, seeing David’s abode, going out for some Japanese food and drinking some local brews and a nice bar called the Toronado. We have a new release of Schroedinger ready so I just need to update the webpage and send out a release announcement. Will get the MPEG Transport Stream muxer out at the same time.

Returned to Barcelona on Saturday, didn’t get much done for the remainder of the weekend apart from sleeping and catching up on the two episodes for Battlestar Galactica that I missed while away

We have decided to try to support as many of our plugins as possible on the Solaris platform in addition to GNU/Linux. Due to this I installed Solaris Express under vmware on my machine this week. I have to say that Sun is making great strides forward with Solaris as a developers workstation. Coming at this from someone who has been using Red Hat/Fedora for a long while, this Nevada build was the first Solaris install I could actually see myself using for more than Solaris specific testing. And I mentioned this before, GNOME seems snappier when running under Solaris for some reason, even when running it inside wmvare.

On my last blog entry I got a couple of questions about the status of DVD and Windows Media in GStreamer.

In gst-ffmpeg CVS it now supports WMV9, so as soon as the next release is out then WMV9 support will be available through that. Also as I have mentioned here Fluendo will launch our proprietary Windows Media plugins very soon now, maybe as early as next week.

In regards to DVD support, well with the new decodebin, which we hope to integrate within the next week or two, getting DVD support working should be much easier. That said someone would still need to do the work. At Fluendo we are due to contractual obligations not able to directly participate in the development of the open source DVD plugins, so we need external contributors to do this work. Anyone interested in helping out should talk to __tim on #gstreamer on irc.freenode.com for the details of what needs doing.

Thought I should do another Dirac update. The Schroedinger project is progressing nicely with the code currently being in bugfix and optimize mode. I hope to push out a release as soon as we have a couple of troublesome bugs fixed. We have sucessfully muxed Dirac into both Ogg and MPEG Transport Stream at this point and I am sure mappings for more formats will come.

Ours is not the only Dirac effort though, there is of course the reference/development version by the BBC and there is also a project to make a hardware implementation of Dirac by Peter Bleackley.

We are rapidly moving towards being able to start pushing Dirac with full force. The good thing at this point is that we have a lot more tools to start pushing Dirac with from day one. Like when we started pushing Theora there was a problem that people found they had few or no tools available to make Theora files, which caused even the strongest supporters of open formats to stumble. At this point hooking Dirac into tools such as Flumotion, Pitivi, Thoggen, Totem and many more is either a quick job or something that happens automatically, all thanks to having managed to build GStreamer and the eco-system around it.

DVB – I mentioned in an earlier blog Zaheer has been working hard on getting our DVB support up to scratch. Things are starting to come together know with a DVB signal being converted to Ogg on the fly and streamed using Flumotion. Some work remains before we can integrate DVB into applications like Elisa (and maybe even Totem?) but things are moving forward.

RTP – On the RTSP/RTP side progress is also being made. There is for instance a set of RTP paylaoders and depayloaders in CVS now for Vorbis. The plan is to also get a set for Theora in there.

Was very happy to see Texas Instruments announce their work
on integrating GStreamer with the OpenMax acceleration architecture. A big thanks to Texas Instruments for this contribution to GStreamer.

Fluendo hiring

On the topic of GStreamer and embedded systems. We are looking to hire another motivated coder to work on Elisa and join our crazy team here in Barcelona. Anyone interested please Philippe Normand at ‘philippe at fluendo d0t com’ or come into the #elisa channel on IRC channel on freenode. Skills we are looking for is experience with GStreamer, Python, Twisted, OpenGL and uPnP so if you know one or more of these be sure to get in touch.

So finally managed to put out the Elisa press release. It had been a good while since we last sent out a press release so it was good to get it out and hopefully get in the habitt of doing them more often.

Loic also put up some new pages on the Elisa Wiki describing the split-out of the Toolkit from the application. Very nice overview of what features are in the toolkit, how it works and where we are seeing it go forward. Also based on a discussion I had with Matthew Allum we added OpenGL ES as an explicit target for Elisa.

In other cool news so did Stuart ‘Young Whippersnapper’ Langridge put up a webpage for Jackfield. Jackfield for those you missed Stuart’s talk during GUADEC is a engine for running MacOSX Dashboard applets under GNOME. Be sure to check it out and send Stuart patches to make your favourite Dashboard applet work.

I know many of you have requested Vorbis support on the 770. Well the way we can make that happen is to demonstrate that there is a real interest in this. Nokia gathers statistics on what people report in their bugzilla and this is a big part of setting priorities going forward. So if you want Ogg Vorbis to be supported on the 770 device then please go to Maemo bugzilla and file a bug report requesting they add Vorbis support. I am going to do this myself this week, so please do so yourself and also tell anyone you know to do so too. If you don’t then you lose the right to complain about lack of Ogg Vorbis support on the 770.

Edward Hervey is organizing a gst-python centric hackfest here at GUADEC tomorrow at 12.00 in Carpa. (Originally scheduled for Friday).
Projects such as Pitivi the non-linear editor, Jokosher audio mixer/recorder, Elisa media center and the Flumotion streaming server will be there. So if you are interested in getting involved with any of these projects make sure to be there. Also if you have questions about writing GStreamer applications in Python in general experts like Edward, Jono Bacon, Stuart Langridge, Phillipe Normand and Loic will on call.

Been a while since I blogged the last time. Got sick which took my energy level down to 0. Still not fully recovered, but thanks to the wonders of modern medicine I can at least function quite well now.

Polypaudio (or what is now known as Pulse)

Got a few comments on my previous blog entry where I discussed Polypaudio (Pulse) (and also mentioned JACK). To start with JACK, as I tried to say in my previous entry, I simply think its the wrong tool for the job (the job in this case being a generic sound server for the desktop). JACK solves the problem of low latency access on your local for applications specifically written for it when used in combination with a special kernel. The desktop on the other hand is looking for a solution which mixes your sound streams if you have a cheap sound card, gives you some basic network transparency and sample caching.

In regards to Pulse vs Phonon, I don’t think comparing them makes sense. As for wether Pulse is an unecessary interfaces, well for many of us it is. If you are only playing back sounds on your local system and your soundcard handles multiple writes or you are using dmix then having a soundserver there doesn’t give you anything extra IMHO. The sound server usecase is mostly in the case of remote clients or as an alternative way of mixing sounds to using a kernel/alsa level solution like dmix. Personally I wouldn’t mind having a sound server there even if I strictly don’t need it if it didn’t get in the way. ESD do get in the way which is why I haven’t used it for the last 3-4 years. So I am not giving Pulse a ringing endorsement yet, haven’t used it enough to do such a thing, all I am saying is that its the most ‘plausible to suceed’ desktop sound server project in a long time.

GUADEC just one week away!

So GUADEC will fire up next weekend with the main event next week. Really looking forward to it! The teams here at Fluendo is working hard to have cool stuff to demo for Pitivi, Elisa and Flumotion.

On May 17th I posted a request for people to submit movies and clips from the mobile phones and digital cameras to our tracking bugzilla entry. Today Wim posted a comment to the bug saying that allmost all the bugs where fixed. I think people will have some problems still due to the AMR decoding library not being generally available. If you want AMR support under GStreamer you need to follow the instructions in the README in the ext/amrwb directory in gst-plugins-bad. We are of course aware that this is a bit of a pain, but luckily doing an AMR decoder/encoder is a ffmpeg SoC project this year.

There was one file submited using a Qualcomm codec which also is lacking open source implementation. As I pointed out in the bugzilla there is a free beer library available for supporting this on desktop systems, so if someone is interested in helping us create a GStreamer plugin for it that would be a good thing for those stuch which phones or cameras using this codec.

So there are no known bugs anymore in relation to these files there is only a unimplemented codec (QCELP) and a codec which you need to do some manual compilation to get support for (AMR).

We would still appreciate even more movie clips and camera model information. I am sure there are more phones and cameras out there producing more weird files. So if you got one of those please add it to the tracker bug report

Google Summer of Code

The SoC projects are now chosen and we got some nice projects approved. Particularly happy that the updated gst-editor application got approved. There was a very good application for MXF demuxing/muxing GStreamer plugins submitted under the Xiph.org banner, but unfortunatly Xiph.org didn’t get enough projects allocated to take on this project. Not getting that project through was the only thing I am feeling a bit bummed out about as it was a really well written and thought out application. A big thanks to Marko for applying.

Open Source and Strategy – A GUADEC story

With GUADEC approaching fast I have been thinking a bit about what we do at GUADEC and what have worked and not worked earlier years. One thing GUADEC has at times been good for is to help us set some strategies for going foward. I think the biggest singlest success story in this regard is the strategic decision taken during and after GUADEC 3 in 2002. At GUADEC 3 Jim Getty‘s did a talk called draining the swamp. In this talk he pointed out some of the problems we face today and how we need to be better at reaching out to others to solve them. This talk and the subsequent debate led to some major decisions getting taken in the GNOME community.(To be fair others, like Havoc Pennington, had brought up similar issues before and even worked on them, but I think GUADEC 3 and Jim’s talk was a turning point).

The strategic choices I think can be summed up as follows:

• We need to reach out to other projects and organisations and pull them closer
• We need to fix problems on the right level not try to fix them on our level
• Focus on getting things right on Linux while making sure the solutions we choose don’t permanently lock out other platforms
• Work on cross-desktop standards to avoid redundant efforts and increase interoperability
• It isn’t our way or the highway

I think on all these areas we succeeded and the world is a better place today for it. In terms of project outreach I think we succeeded in pulling projects such as Mozilla, OpenOffice, Eclipse and Xiph.org to name a few closer with the three first all now defaulting to our having GTK+/GNOME integration as their natural Linux integration point. True enough we didn’t have any real competition in some sense with anternatives either being license wise unacceptable or already on the way out, but a lot of personal initiatives where taken by people in and around the GNOME communty to engage with these projects and I think it has paid off. Adoption by commerical vendors such as vmware and Adobe is another example of how the choice to be more welcoming to ‘outsiders’ has worked out.

As for fixing the problems on the right level this was about renewed engagement with people in the kernel and X communities for instance and in some cases pushing projects to freedesktop. This also ties in with the linux focus point. Instead of creating a forest of abstraction layers to try to overcome the problems of varying platforms with or without certain features and functionality there was a decision to choose good solutions and help popularize them instead of letting lack uniformity hold us back or cause us to waste time and effort trying to support highly different systems. HAL is a good example here. GNOME decided to go for HAL even though it was a pure linux solution at the time. The design of HAL wasn’t made to be linux exclusive, but the implementation at the time was. Up to this point we had tried with varying levels of success of working around and abstracting this away at the GNOME level. With the current work done on porting HAL to Solaris and FreeBSD I do feel that this strategy is vindicated and HAL is providing us with a much better plug and play story than we ever had before. Lesson here is that if you try to be Jack of all trades you become master of none.

After GUADEC 3 GNOME people put a lot more emphasis on trying to push more things into freedesktop.org. There was some initial pushback with people crying about freedesktop being a cover operation to force GNOME technologies onto the world and so on, but I think today most people would agree that the steps taken with freedesktop have been good and if anything we have not managed to take enough steps.

It isn’t our way or the highway. I also think that it was about this time that GNOME developers starting coming to a true acceptance that there was nothing wrong with developing applications in other programming languages and frameworks. There was a lot of discussion about what it means to be a GNOME application, like can you be a GNOME application even if you don’t use library XYZ and so on. Today we have a thriving community of developers doing applications in C++, Python, Mono, Java, Ruby and many more. Some are using GTK+ or GTK+ bindings, while other integrate much more indirectly using toolkits such as SWT, Swing, wxWidgets, XUL and VCL. We still have an ongoing job to define what we expect of a GNOME application in a more neutral fashion, but long term there should be nothing stopping someone from even doing a GNOME application in Qt for instance. The philosophy being that if it looks, walks and talks like a duck, then it is a duck. You don’t need to disect it to prove it as a duck. This is software development not biology :).

There has been a lot of other strategic decisions made over the years too of course which have had smaller or bigger impact. The HIG and the 6 months development cycle to mention a few. Or in some sense we never made any strategic decisions, but GUADEC have always played a instrumental role to ensure developer buy-in for such things, and those ideas which have gotten enough buy-in have looking back become strategic decisions I guess that is the sort of thing which people coming from a non-free software background have trouble relating too

I don’t know what will be the strategic choices made or strongly influeced by this years GUADEC, but I will be there to find out and so should you