Tim Janik had a post about never rejecting a feature request, which got me thinking about an issue in the GStreamer bugzilla. We have a gazillion requests for support for every weird audio or video format under the sun. With weird formats I am talking about things like gameboy audio, NES audio, computer game video formats and things like that.

So these kind of requests seldom comes with patches and I tried asking for such a few times. They are also not something you don’t generally get anyone interested in helping out with, as people who just want to help out on GStreamer prefer working on something that a large numbers of users might actually enjoy, as opposed to something only the 5 person linux-based gameboy audio format community might get a thrill from ;)

So my opinion is that such features will only ever enter GStreamer if the bugreporter is interested in doing it him/herself. And if that not the case they are just ‘bugzilla clutter’.

So we are left with a situation where we have tons of stuff ‘cluttering’ bugzilla, yet it feels a bit bad closing them as they are valid feature requests and of course you can ignore the bugs by excluding enchancements from your bug search for instance (although that also filters out the more realistic feature enhancements).

Now I realize of course that the lack of gameboy audio format support makes GStreamer useless for people like Linus, and that we are fucking idiots for not diverting resources from for instance improving VoiP support over to work on supporting such formats, but in the meantime I a trying to figure out a usefull way to deal with these bug reports :)

Noticed on freshmeat today that GStreamer is about 6 years old now. And we celebrate that by doing the first release the new 0.10 stable series.
The amount of work gone into this release is staggering, but it feels mighty good. Sure there are still things missing, like decoders and demuxers for some formats, but all in all the framework is ready now. Worked on a release announcement which turned out pretty sweet, next step world domination!

Sun finally released the Opera DRM sourcecode the other day which is part of their Open Media Commons effort launched some time ago. It is interesting in the sense that its a major DRM effort with a complete implementation available.

In that regard I think its prudent to mention that we are currently working on DRM support for GStreamer at Fluendo currently. The goal is to have a framework for using various DRM systems with the GStreamer framework without interfering with the way GStreamer currently works. Opera DRM is one system we are looking into implementing support for as a proof of concept. Since its free software it fits well with our goal of releasing our DRM integration stuff as free software too (although it will allow for closed source modules to be made for things like Windows Media DRM and Fairplay for instance).

The DRM work has included a lot of thinking on our part about the implications and I think its safe to say that we love DRM as little as everyone else. On the other hand we have also seen that a lot of doors get closed on us, GStreamer and GNU/Linux due to lack of DRM support, which means people in those cases go with a Windows based solution instead. Which of course is no win for free software.

On the other side there is the question on how far you should go in trying to accomodate people too and I am sure many in the community feels that any sort of DRM support is going too far.

For me personally it comes down to a evaluation of what we can achieve and what position we are operating from. Personally I doubt technology providers will be able to dictate this, or rather if we say no then someone else will say yes (ie. Microsoft). The only group out there with the power to shut down DRM are the consumers, they need to revolt at the idea and stop buying music and movies which are using DRM. What we as a technology provider can do is try to move DRM usage in favour of the more userfriendly and fair systems.

In some ways I hope we will be able to do with DRM what we hope to accomplish with our streaming hosting platform. People come to us and ask for WMA or MP3 streaming, and we are able to give them that, but we also give them Ogg streaming as part of the package. In that way we help make sure more and more content is available as Ogg streams and through that help solve part of the chicken-egg problem that is there in regards to widespread adoption of Ogg.

Of course all that said, we are running a business at Fluendo and making money is of course one of our main objectives (companies who don’t have that objective tend not to be around for long for some reason), so I am not claiming we are altruism incorporated. But we do try to do morally ‘the right thing’ in the way we operate and do right by the community we sprung from. So I hope we do not anger the community to much by our current work.

It also have to be said that there are some technology landscape level changing agreements being part of this. I am not able to say anything more about that at this point, but we should be able to make some announcements about it during the first half of next year. Hopefully when its announced people will agree that we did the right cost/benefit calculation.

So Wim decided to go lethal on our list of undocumented API’s in GStreamer core. Today it reads:

100% symbol docs coverage (1449 symbols documented, 0 symbols incomplete, 2 not documented)

Pretty sweet :)

We got something else working today and as you can see the reaction is quite extreme.

Ok, my last mention that there probably wouldn’t be DVD support in the next version of GStreamer/Totem/GNOME seems to have made quite a few people worried. Got comments about it to my previous blog and also comments about it on IRC.

Anyway, what is needed for DVD support with GStreamer 0.10 is simply some people coming into #gstreamer on irc.freenode.net or contacting the mailing list saying that want to work on this and asking what plugins needs porting. Currently dvdread, libcss, dvdnav and dvdsubdec are the plugins I know about. Updating these plugins from the GStreamer 0.8 API’s to the GStreamer 0.9 API’s. The GStreamer team have been working a lot on improving the API and development documentation for this release and there are even porting help in the plugins writers guide.

That said both Martin Soto and Tim Muller stated that they are planning and working on it and try to have it ready for GNOME 2.14. Martin is already working on getting the mpeg/dvd demuxer ported and fixed which is an important first step. So with these two and hopefully more joining in, we will not only have DVD support in 2.14 it will work even better than in 2.12.

So Edgard Lima have done an initial port of the Tremor/iVorbis plugin to GStreamer 0.9. Today I tested it on the Nokia 770. It played my testfile back with a CPU usage between 30% and 40% percent.

Still quite a few bugs though, like support for playing a streamed file, and also being able to use the lowmem Tremor version which should reduce resource usage.

Also borks out at playing for a while. Not sure why yet, could be related to the power saving stuff.

Pipeline used for testing is : gst-launch-0.9 gnomevfssrc location=”http://192.168.1.70/u2.ogg” ! tremor ! audioconvert ! esdsink

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.