Last RTSP step taken

Wim just commited some changes to gst-plugins-base which finally enables RTSP playback in playbin. That means that Totem etc., will be able to automatically play any RTSP stream we have RTP depayloaders for (and our list of RTP depayloaders is starting to get quite long). One of the one’s still not complete is Real support as can be seen in this bug report. So while we have good plugins for decoding Real format in GStreamer now the network support is still missing someone to take it the last mile (ie. replace the code of uncertain origin in the current patch). Hopefully Lutz will take this upon himself. Also a little work is needed to ensure we handle the Real RTSP extensions properly. Other formats like MPEG formats, Xiph formats and Microsoft formats should work with this commit although I am not sure if we have a RTP depayloader for Windows Media ready apart from Fluendo’s commercial one.

Easy codec install

Another set of changes comitted over the last few days was Tim’s work on enabling the easy codec install stuff that was decided upon during the UDS conference. With these API additions writing helper applications that integrate with vendor specific applications to ease codec installation will be much easier to do. Ubuntu already is well underway implementing it and I also noticed a ‘codec buddy’ being listed for Fedora Core 7. Tim will also write an application integrating with the Fluendo webshop using this system.

gnomedesktop.org

Decided to beef up my involvement with gnomedesktop.org a couple of days ago. Blogging has taken over some of the functions of a news site like gnomedesktop, but I still think it could provide a useful resource for GNOME users. So I will try to add more stories and keep the moderation empty again.

Jokosher on Solaris

Thanks to our friends at Sun we have a SPARC box running Solaris in the office which we use for various development. Yesterday Jan was trying to figure out why gst-python had problems under Solaris. This patch and the problem was solved so Jan moved on to trying to run Jokosher on Solaris. The application started, but Jan was not able to to get it to do much. What hindering Jokosher on Solaris seems to have two major components, one was our Solaris install lacking HAL which Jokosher needs and which newer versions of Solaris has, the other was some hardcodings of the GStreamer ALSA plugin in Jokosher. Jokosher switching to autoaudiosink should solve part of that and if we put together an autoaudiosrc plugin Jokosher should in theory be able to run well under Solaris also. Anyway if we manage to have Jokosher work without any changes on both Solaris and Linux there should be nothing stopping us from getting it running under Windows and MacOS X as well without further changes (apart from audio source plugins for GStreamer for those architectures). An audiosrc plugin is incoming from Sebastian Moutte soon so maybe Jokosher 0.3 will be available for both Linux, Solaris and Windows.

Comment on Diva

Michael Dominic posted a blog entry on the state of Diva. One of the major announcements he did was that he was looking into moving from GStreamer to MLT.

I usually try avoiding commenting on such decisions and instead let time decide wether they are wise or not, as making a comment on such things easily just cause bad feelings. Of course sometimes the need to make a comment overrides such concerns :)

One thing that Michael forgot to mention in his blog entry was that almost from the begining most of the GStreamer developers disagreed with the design choices he made in terms of Diva’s usage of GStreamer. Multiple times we tried to say that the Gnonlin approach was what we recommended and would be working towards enabling for these kind of applications. Michael disagreed and instead tried various alternative routes, which is why I feel somewhat unhappy about his claims about GStreamer in his blog. The rapid progress of Jokosher I feel validates our claims about Gnonlin to a large degree and I hope with our renewed effort into Pitivi we will have a 100% comparable application to Diva to prove our point with.

Edward added a reply to Michael’s blog pointing out some of the issues involved here, but one thing I want to expand upon and that is the issue of framework readiness. It is impossible to develop a framework such as GStreamer in isolation as there are always usecases and trouble areas that get lost or design decisions who seem clever from the framework point of view but which is a complete fuck up from the application developers point of view. This is a big part of the reason why GStreamer have taken so long to get to where it is today. Every time a new application type started using the framework we discovered that there where basic assumptions made in the core which simply didn’t hold true. This do make life for application developers a bit frustrating as they can get sucked into long periods of having to work on the framework and fixing bugs there instead of moving their application forward. I think people such as Stefan Kost with his Buzztard project and Edward Hervey with his Pitivi project can testify to that. The same is probably even true for the Totem and Rhythmbox projects who where among the early adopters of GStreamer. But thanks to the dedication and continous feedback of our application development community we have managed to ramp up the framework and also managed to keep the design pretty sane through it all.

I think this process is true for any major software project and I think no matter what multimedia framework Diva ends up using it will run into problems and deficiencies in the framework. The only framework which is sure to provide an application with all the features you could want working perfectly ‘today’ is one which already have applications using them sporting all the features you want. Which is why most music player developers for instance are pretty happy with GStreamer today, as there already are fully working high featured music players using the framework.

So on the GStreamer side applications such as Pitivi, Jokosher and Buzztard and Flumotion will continue to push the framework forward and resolve bugs and missing features as we find them. And while all the work going into for instance enabling DVD’s under GStreamer might feel like a unwanted distraction for a video editor developer I am pretty sure the long term effect of being able to easily import video from DVD’s directly into the editor will be a highly welcomed feature by the users.

I wish Michael good luck with Diva and trying out MLT, but I am pretty sure he will find that life there is just as painful, just with different set of bugs and missing features.

One year of GStreamer 0.10

Andy Wingo reminded me that the 5th of December last year we did the first release of GStreamer 0.10. So Tuesday was actually our 1 year aniversary of GStreamer 0.10. We felt it was a major milestone for GStreamer, turning a corner in stability and usefullness. That said the move wasn’t completely without its detractors as the 0.10 branch did have some regressions compared to the 0.8 one. Now one year later I think its safe to say that GStreamer 0.10 has been a gigantic success. The number of developers contributing or using GStreamer have mushroomed and the status of the GStreamer project is much improved. There are still a few feature regressions left in GStreamer 0.10 compared to 0.8, DVD playback being the most noted example, but I think that is overshadowed by the improved capabilities of the framework and the much improved stability provided by the new framework.

The fact that we don’t try to ‘jury-rig’ new feature in place, but instead take the time to do them properly seems to win us more friends than having ‘all’ features available in a flaky manner.

Not everything is perfect though, we know for instance that some of our demuxers are still not perfect and applications like Pitivi and Jokosher breaking new ground are hitting new bugs. But the good thing is that unlike the 0.8 experience, with 0.10 we feel that when we fix bugs they stay fixed, instead of playing bugzilla whack-a-mole like we did with 0.8. For every day we see bugs getting fixed or new plugins getting made, all bringing us closer to give the community the media experience they deserve.

So congratulations to the rest of the GStreamer community with 1 year of GStreamer 0.10 rocking hard!

The return of a GStreamer Legend

Edward got his first major patch for Pitivi yesterday. Cool thing was that it was from an old GStreamer hero who we hadn’t heard from in a long while, namely Richard Boulton. Richard is one of the few people who I think pre-dates my own involvement in regards to GStreamer apart from Wim and Erik. Welcome back Richard :)

What Richard provided for Pitivi was the save/load Project feature which is critical going forward where Pitivi is reaching a level of usability that makes saving and tweaking projects become a real priority. Cool stuff.

Novell bashing at Groklaw

Have to say I agree with Jono on the latest Novell bashing story on Groklaw. It feels more like an attempt at smearing than anything else. As anyone who have followed OpenOffice for the last years would have known, Ximian and later Novell always maintained a large set of changes for OpenOffice due to the process of getting them approved and merged upstream being long and painful. A lot of nice stuff like the GTK+ support and a much improved icon set created by TigerT and Jimmac is the heritage of this effort. Michael Meeks has probably pulled in more people to help out with OpenOffice than anyone else in addition to the incredible work he personally have done on OpenOffice. This is just a few of the contributions done by first Ximian and later Novell to OpenOffice.org. Starting to accuse them now of forking is just childish.

PJ, it is fair to critisize the Novell & MS deal, but please try to keep things at a intelligent level, more postings like that one and you lose all the cred you built up over the last few years.

Details on Texas Instruments and GStreamer

So I blogged about Texas Instruments work around GStreamer yesterday. Today I found this article about GStreamer and Texas Instruments on EETimes.com. Lots of lovely quotes in the article like:

Since GStreamer is a very popular and well-known framework, which has become a standard in digital video development, the ability to access the capabilities of the DSP from within this environment saves programmers from the need to learn the proprietary DSP programming language.

Yes, you heard it here first, GStreamer has become a standard for digital video development.

Decodebin2 has landed

Ok the wait is over, the new Decodebin element has landed in GStreamer. It will be part of the new GStreamer core and base release next week. It will not be used by default for this version though, instead you have to set the USE_DECODEBIN2=true Environment variable to have playbin use it instead of the old decodebin. Once it gotten some testing during this release it will be the default in the release afterwards.

So what new features do this bring? Well for the end user nothing will change overnight, but for developers it opens the path to fixing things like Chained Ogg playback, DVD handling and non-raw media output (for instance outputing AC3 to your S/PDIF port). A big thanks to Edward for fixing this.

Jack and GStreamer

Paul Davies of JACK Audio fame popped up on GStreamer-devel list last week asking about GStreamer JACK support. The discussion on both the mailing list and on IRC has since been about when to pull and when to push :). Anyway Wim decided to do take a stab at a JACK sink for GStreamer and its scheduled to hit CVS tonight.Update: It hit bugzilla today :)

Pitivi UI mockups

Mentioned some time ago that Edward and Christoph had worked out some mockups about how the ‘simple’ view in Pitivi should work and look. As many of you might beware of we are aiming for a two view model in Pitivi, with a simple view which should allow anyone to do some basic editing and an advanced view meant for the more technical user who wants more detailed controlled of the timeline.

Edward Hervey blogged about these mockups last week after they are not cleaned up and commented. Be sure to check them out, we don’t know exactly when we will get to implement them all, but they do show the direction we are heading with Pitivi.

Jokosher roadmap

Another must read blog is Stuart Langridge, hacker extraordinaire on Jokosher and Jackfield. He had a recent blog entry discussing the outcome of the Jokosher 1.0 planing meeting with links and information on what the Jokosher community priorities are going forward. Be sure to check it out.

Cool Jokosher review/podcast

Dann Washko did a little podcast/audio review of Jokosher as part of the series of podcasts they do at Twatech.org. The cool part is that he records the little podcast with Jokosher. Some bugs and issues where found (partly as this was pre 0.2 Jokosher), but it is great to see and hear the excitment and use people are putting Jokosher too. Of course Dann by doing this made sure his bugs and experiences is getting top attention from the Jokosher devs now :)

TestingGst-editor

So I decided to take a look at the new Gst-Editor that was developed as part of the Google Summer of Code. Took me a little time to locate the homepage of goocanvas and the homepage of pygoocanvas which the new editor depends on, but after a little googling I had it all put together. Even built packages of both for FC6. Here is a little screenshot of the new editor in action:

gst editor image

The application looks nice but it is a bit more like a proof of concept than a truly useful application at this point. As the screenshot shows it can create and run 1-to-1 pipelines only currently, which makes using it to prototype and test pipelines for applications like Jokosher or Pitivi impossible. As you see from the screenshot I tried to make a pipeline for transcoding a file to Ogg/Vorbis/Dirac, but I was unable to hook the audio part of the pipeline inn as the decodebin and oggmuxer only accepted one connection. But hopefully we can get the project moving forward again and make it a truly useful development tool. An a big plus point was that unlike the old editor for 0.8 it didn’t crash for me when testing it :)