Ok, it turned out my list of RTP projects using GStreamer was too short, there are at least two more projects in the GStreamer RTP real under development. The Xeris project have a GStreamer RTP setup using the ortp libary. And there is the Sofia project a console SIP client. Lots of good discussion on the mailing list going on where people try to coordinate the different efforts to get as much synergy effect as possible. Neat stuff.

Bloat and other madness

Jono’s article on O’Reilly caused quite a debate on lwn.net. The GNOME clock applet taking 10M of ram as proof that GNOME was bloated was brought up again. Ross Burton and Stef70 replied explaining why that number is misleading at why the actuall memory use of the applet is more something between 1M and 1.6M. Anyway I ended up chatting a little with Benoit Dejean the maintainer of GNOME System Monitor about it, thinking that even if maybe top and ps is out of our control we could at least make sure GNOME System monitor gives people better numbers. I mean if the numbers you present makes a lot of people draw the wrong conclusion then maybe the conclusion to draw from that is that you are presenting them the wrong numbers.

The problem seems to be that you can’t actually get the ‘real’ number due to the way the system works. And being the engineers we are providing users with an approximation number, (for instance by substracting SHARED memory from RESIDENT memory) violates everything most of us hold holy. So what we are left with are correct numbers which a large number of our users fails to understand/interpret correctly. On the other hand we are hesitant to provide an inaccurate number, but which still would give our users a number much closer to the number they want/expects. I hope someone manage to sort this out someday..

It is strange how things change. The GStreamer 0.8 to 0.9/0.10 change have little to do with RTP (although RTP also benefits from some of the improvements) yet where we had next to no RTP support in GStreamer 0.8 I think almost 40% of current GStreamer 0.9/0.10 development is originating in RTP related projects. There is of course the work we are doing at Fluendo in regards to adding RTP support to Flumotion, but there is also the work being done by the Farsight project which wants to add support for video conferencing interoperability with all the proprietary instant messaging clients, then there is the Tapioca VOIP project done by the guys at the Brazilian Instituto Nokia de Tecnologia. And there is of course the Maemo/770 VOIP work being done by Movial and Nokia in Helsinki. One things that is sure is that GStreamer 0.9/0.10 is becoming a RTP powerhouse :) Hopefully we can get started on the RTP implementations for Vorbis and Theora soon too, as Luca Barbato have being doing a good job of moving that effort forward.

Other news

Finally got my Vampyros Lesbos DVD, although I am noticing a sliver of scepticism among my co-workers for how good it really is. Guess they don’t appreciate quality in the same way I do.

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!