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 :)

For some time know we have been working with the BBC and David Schleef to create a implementation of the Dirac codec in ANSI C. The homepage of this project is schrodinger.sf.net. Due to delays in getting the bitstream specification finalized things have taken longer than anticipated, but things are moving ahead at full speed now so we felt it was a good time to make our first ever release.

This release isn’t 100% spec compliant or as fast as we want it to be, but it do provide you with a full set of GStreamer plugins for encoding and decoding video and embedding the Dirac video into a valid Ogg file. Its basically a technology preview release making it easy for people to grab the code and compile it knowing that we did some basic testing on it to make sure it ‘works’ as opposed to grabbing a random snapshot from svn.

You can download this 0.2.0
release here

Over the next months we will do further releases which will gradually be closer and closer to the specificiation, faster and the library will also have a public API for people who wants to access it directly instead of through GStreamer. The 1.0 release will be 100% spec compliant and reasonably fast for common use.

Edward is planing a new release of Pitivi very soon so I have been helping him out with doing some testing. The target of this release is to allow you to transcode as many of your files as possible to Ogg Theora. We are building Pitivi step-by-step now with the roadmap being something like.

1. Play any file that Totem plays (previous release)
2. Transcode any of those files we play to Ogg Theora (this release)
3. Merge together multiple clips into one bigger movie (next release)
4. Basic transitions

There is of course a long todo list after that too, adding more and more advanced features, more output formats and so on and there is a lot of related bugfixing to make those items a reality. Like fixing the issues caused by those mobile phone and camera files we got yesterday. But our goal is that starting from the current release Pitivi will actually do something thats useful for many people, namely transcode their video clips into Ogg Theora. In some sense that todo list doesn’t look very ambitious, but there are a lot of bugs that gets found and needs fixing during this process. My thinking initially was that if we could decode it (for instance play it back with Totem) we could transcode it. This turned out to be a huge oversimplification. In the 1-to-1 file case this is mostly true, but since Pitivi’s goal is to handle many-to-1 in the end the design requires a higher level of perfection from the decoders in terms of how they handle seeking for instance. So far AVI, Windows Media, Matroska and Ogg files have transcoded fine for me. MPEG/Quicktime movies seems to lose either sound or video partway into the transcoding process, but those issues are being looked at and will be resolved with future GStreamer plugins releases.

Also in terms of getting gnonlin stable and bugfree there is now a good tag-team effort going on between Pitivi and Jokosher. The kind of issues that the Jokosher team runs into tend to be the same that Pitivi are or will be running into so with both them exercising it mightily a lot of bugs are found but also resolved. Also noticed a new batch of really sweet Joksher screenshots posted a little over a week ago. Reminds me that we need to get working on more Pitivi screenshots also :)

On a related note, Mike Smith commited the ALSA spdifsink to CVS today. This means that outputing AC3 through the spdif port on your soundcard should now work with GStreamer if your alsa driver has spdif support. Another feature in Totem we can now support :)

Also checking Jokosher webpage today I noticed that they don’t sport the cool GStreamer family web button. Anyone doing GStreamer based applications should be sure to sport this token of eliteness on your webpage :)

Edward is hard at work preparing a new release of the Pitivi non-linear editor. The goal of this release is to be able to transcode to Ogg anything you throw at it. Once that is done we have a solid base to build from and an application that does something genuinly useful for people.

One thing we want to make sure of is that we are able to handle all the videos created by mobile phones and digital cameras (non-dv cameras). So we ask that anyone who got such a device create a 5 second clip at transfer it to their system. If it plays in Totem (using GStreamer) or CVS Pitivi and you are able to seek in it then please just add a comment to this bugzilla entry stating the device that produced the clip. If it either doesn’t play or seeking is broken please attach the clip to that bug with a statement about what device captured it and what the problem is.

Update: Please attach a test video clip to that bug even if it works in Totem as there are cases where playback works, but we still hit problems when trying more advanced operations on the files.