/Kretz/blog/

Christian Schaller just blogged about it: Fluendo will join the work on the Phonon-GStreamer backend which Tim Beaulen started a few weeks ago. This is great news as that will surely bring the best GStreamer backend possible to KDE4.

I'm very sad that I have to keep from working on KDE/Phonon too much these days. But I really have to get done with university at some point. And working on KDE doesn't help my studies.

On another note my laptop is out of service for now as its harddisk is broken and Samsung's guarantee becomes void when I change the hdd myself. So I'm waiting for them to pick it up, exchange the hdd and send it back... no KDE compiling for now (which helps studying for Uni ).

Today the weather was too good to stay inside (and that's me saying that ). So Flora and I went to Ziegelhausen and hiked up the Hahnberg. We hoped to be able to see the Neckarvalley from the top of the mountain, but there were trees everywhere. Nevertheless it was just great.

We took some pictures: Image Gallery

One of the things I've been working on a lot lately is to make KIO work seamlessly with Phonon. The idea is that you can throw any URL at a MediaObject and it will work even if the mediaframework used by the backend doesn't support the given protocol. A protocol that isn't supported by Xine, for example, is sftp://. MediaObject handles those URLs by first trying whether the backend will play the URL without further help, if that doesn't work it asks the backend to create a ByteStream object which provides an interface for streaming the media data using QByteArrays. It then sets up a KIO::FileJob (the new one that supports seeking) or KIO::TransferJob if the protocol doesn't support seeking and connects the data and flow control signals accordingly.

Phonon-NMM was the first backend to implement the ByteStream interface and supports non-seeking transfers so far (it was written when KIO was not able to seek at all). Phonon-Xine is the second to follow, this time also with seeking support. Implementing this class for Xine was a major headache because of the undocumented threading issues - with both the KIO transfer and the xinelib calls being asynchronous (the latter was not expected from the documentation) there are so many things that you can do wrong...