Ok, so some more 770 work done today. We solved the issue keeping Real video from working with some nice fixes both to the realvideo plugin and to sdlvideosink. Both sdlvideosink and ximagesink works on the 770 I have now discovered using gstreamer 0.9 CVS.

Edgard did some great work adding fullscreen support to the sdlvideosink so that we hopefully at some point can do fullscreen videoplayback on the 770 using sdl.

Some issues did pop up though, like our need to get the quality of service framework implemented for 0.9/0.10 so we can properly start dropping frames when the CPU limit is hit. Luckily getting that in place is planned for the next few months.

After getting hold of a image suited to my old 770 model I was able to flash the system and continue experiementing with GStreamer 0.9 and the 770/Maemo. GStreamer 0.9 is doing well compared to 0.8. By running this simple pipeline ‘gst-launch-0.9 fakesrc silent=1 num_buffers=10000 ! fakesink silent=1’ I was able to have it complete between 20% to 50% faster than the same pipeline do using GStreamer 0.8 on the device, depending on how big I set the num_buffer value.

Edgard, Wim and Tim did some good hacking on the sdlvideosink fixing some issues with it, but I am still not able to get it to display video on the device. I think the CPU overhead is way to high. Also tried playing a vorbis file, which didn’t work, but I will try again when we get the ivorbis plugin ported to GStreamer 0.9.

Next step is trying to get Windows Media Audio playing on the device.

Starting learning to use Scratchbox yesterday and I have to say its pretty nice. Developing for the Nokia 770/Maemo using it was easy to get going. Today already I was able to have GStreamer 0.9 installed and was playing a Real media file streamed over http from my own laptop and played back using GStreamer and Fluendo’s soon to be released Real Media plugin for GStreamer. Cool stuff. Pipeline used was this one:

gst-launch-0.9 gnomevfssrc location=http://192.168.1.70:/kelly.rm ! rmdemux ! realaudiodec ! esdsink

Tried to get video output working also, the closest I got was trying to play a .fli file with Zeenix’s fli decoder and sdlvideosink. Got a black SDL box onto the 770 screen,but no actual moving image.

As part of trying to fix the issue of getting SDL output working I tried updating the device to latest development snapshot. But that seems to work very badly for me, seems the interface is extremely slow or unresponsive so that I can’t input anything with the stylus. Probably caused by me having an early prototype of the device, but still a bit frustrating.

So with the new release today GStreamer 0.9 is in a temporary API freeze. It will last for a full month before there is short thaw before the hard freeze before 0.10. So if you want to start porting to 0.10 this is a good time to do it as the API will not change under you for the next month and the changes occuring during the thaw will probably be mild (beautiful play on words there).

The new baseclass setup in 0.9 is very nice, in 0.8 it was a constant problem that people fixed something in for instance alsasink, but they didn’t bother fixing it for osssink, sunaudiosink or esdsink for example. Which meant that you got different milage with different plugins for different tasks. This can of course still happen, but with the new baseclasses the chance is much smaller and whenever new functionality is added to the baseclass all the plugins built on top of it have it too.

Thomas caused quite a stir with his venting on NetworkManager (which I am using btw), my biggest irritation currently is that the gaim tab keeps on blinking on the panel even when I have maxized the chat window and seen the message, only way to get it to stop blinking is either reply, switch message or close the window. If they could make it stop blinking after receiving messages I would be very greatful.

Caleb did some major librsvg hacking this weekend. With his latest commit the infrastructure in in place in librsvg for full animation and DOM1 support. Your kicking ass Caleb!

We have some technically good solutions available now in terms of Vorbis, Theora an Dirac. The codecs produce good quality audio and video and is slowly but surely seeing increased uptake. Yet the uptake could be even speedier, but there are some things that needs to be done:

a) RTP support – we are already working on that through the Xiph RTP project. Essential for our codecs to be used in VOIP and multicast scenarios.
b) Profiles – define profiles for various usage like its done for MPEG. For many vendors having standarised profiles, like mobile and main, is essential before they will consider using our codecs.
c) Surround sound – Vorbis can theoretically do multichannel audio, but not very efficiently. Work should probably be done to create a vorbis variation which can compete more head on with AC3 and DTS. Any community members interested in working on this?
d) Content sites – in an email exchange with someone working in the content industry about formats I suggested using Ogg for distributing trailers. The person I talked with agreed (although it wasn’t his decision to make), but said that the main reason they didn’t distribute trailers in Ogg format was simply because none of the major trailer sites requested it. Maybe something that Google could help out with?
e) Tools – I mentioned this before and it is still an core issue, we need more and better tools available for creating/handling content. This is an area where I see a lot of movement, both with the work we are doing here at Fluendo with our work GStreamer, Flumotion and Pitivi, but also from other members of the community with efforts such as DIVA and Thoggen.

Fluendo joins the GNOME Foundation

So together with Imendio and OpenedHand we announced joining the GNOME Foundation today. We have discussed it a lot back and forth for some time, but in the end the fact that GNOME is using GStreamer made us decide it was in our interest to join. A big thanks to David Neary for his relentless work to make this happen.

Community hiring

From time to time and think about the community and the effect the increasing level on hiring have on it. Mostly in a purely practical context. It is clear to me that the ever increasing rate at which people in the GNOME and GStreamer communities are getting hired is a long term win, but can cause a lot of short term problems. Especially in the case when people get hired to work on something else than they have been doing up to the point of getting hired. Let me take one example. Two people I would love to be able to hire to Fluendo at some point are Dom Lachowicz and Caleb Moore. The reason for this is that I know they are both top of the line hackers based on my experience with them in regards to librsvg which they co-maintain. Hiring them to work for Fluendo would of course mean they would be working on projects directly related to our business, which at least at this point do not include much SVG. Also from experience I know that when people do start working fulltime on free software they tend to work less on it in their free time. Partly because they tend to do long hours, partly cause the hacking on free software itch gets fully satisfied as part of the workday. So while having Caleb and Dom work for Fluendo would be a net win for free software in general, as they would work on free software projects of immediate importance to Fluendo, it would be a net loss for librsvg, which would find itself without any active maintainers suddenly.

Over time someone else would probably come along and take over the project, but it could mean a long period of time where an important project for the community goes without any new development or bugfixes.

One example where something like this did happen, was Rhythmbox, where Walters got hired by Red Hat. After that he simply didn’t have that much time and energy to hack on Rhythmbox anymore, although the total ammount of time he spent on free software development probably increased greatly, but most of it went into projects of more immediate importance to Red Hat.

Anyway, so whats my point apart from pointing out the obvious. Not sure actually :) The issue I have been pondering is if there is any way we can make transition periods like these shorter and smoother somehow. Hiring is good for projects like GNOME and GStreamer overall and good for the people getting job of course, but they do increase the turnover rate quite a lot on the individual project level which do and can cause some pain.

Return to the land of the free(zing)

So I am going back to Norway for a week on vacation and to celebrate my oldest sisters 30th birthday. Looking forward to it although I was told it was about 5 degrees Celsius in Oslo atm.