Phonon 4.4.3 & A Magic Glow

Since I got promoted to Lieutenant of Phonon, I have the honor of presenting a new release to you…

Phonon – the magical, terrific and powerful multi media abstraction layer used by Qt and KDE – is now available in version 4.4.3.

As the version number suggests, this release only brings minor improvements, but also a new experimental feature. This release has seen some important improvements to the PulseAudio support, which should make it more reliable and make for an all in all better user experience. Most backends also got a good deal of fixes and improvements, most notable the GStreamer backend grew the ability to navigate through DVD menus.

Last, but not least, Casian Andrei got his truly amazing Google Summer of Code Project on integrating a capturing API into Phonon merged. It currently resides in the the phononexperimental library, but I have great hopes that it will become part of Phonon proper sooner than later :)

I hope everyone has a great experience with Phonon 4.4.3.

Magic Glow

While I am blogging, I’d also like to write a bit about future plans for Phonon.

At this point it is time to tell you, dear reader, how I even came to contribute to Phonon – I wanted to write a good looking video player for KDE (using QML for some parts), and came to realize that Phonon does not support QML, so I went on to improve phonon-vlc and eventually ended up as co-maintainer of Phonon itself. So, obvious enough making Phonon work with QML/QtGraphicsScenes is one of the major todos for me right now, I also have a working prototype for the GStreamer backend already

Videos:

Further more we have plenty of good things waiting in the experimental part of Phonon, waiting for the final cut (like direct access to video frames, which is actually what the QGraphicsScene support builds upon).

Improvements and bugfixes to the backends are of course always work in progress and I hope to see a lot more engagement in those (rumor has it Fedora and Kubuntu consider using the GStreamer backend, surely they would help with bugfixes there? ;)).

Exciting times ahead in Phonon land. I can’t wait! :D

About these ads

29 thoughts on “Phonon 4.4.3 & A Magic Glow”

  1. Is there any plans regarding QtGstreamer when it comes to phonon or is there even any advantage of using it instead of plain Gstreamer?

    1. There was some discussion about this a while back.

      While it would provide more readable code (and thus more hackable one), it comes at the price of reliability and memory usage, since QtGstreamer would be another level of abstraction that can have bugs and since it adds QObjects around things which are then encapsulated in other objects for Phonon. So we concluded that there is not enough advantage from it.

      That is not to say that I would not love to use it anyway because on easily gets a headache from the Gst-C code ;)

      1. A small correction: QtGStreamer wrapper classes are not QObjects, strictly speaking. But the rest of your analysis is quite on target: every time you add an intermediate layer there is some overhead, and one has to compare this with the maintainership cost. Nowadays I think the C++ overhead is not really important, and KDE is a good proof of that. :) An example: if I were to code a string class in C I would probably not make it as efficient as QString, even with the overhead of objects and inheritance, simply because I am not as smart as the people that implemented QString, for sure. But you are right, nothing beats going straight to C as far as optimal usage of resources is concerned, at least in theory.

        When using QtGStreamer you would get some things for free, like the ability to watch the bus and connect Glib signals from GStreamer elements directly to methods in your C++ classes (much like signals-slots) instead of having to deal with callbacks. This makes maintenance easier, so it is a good fit for more advanced multimedia applications that can not be built with higher level abstraction layers like QML or Phonon. But for something like a Phonon backend it is indeed better to go to the C API directly, as we probably do not want another cyclic dependency that requires Qt in order to build Qt.

  2. Its great to hear phonon is being developed. To be honest, for me the word phonon is associated with time spent not too well, fighting with conflicts between qt-phonon and kde-phonon, trying to get phonon-vlc to work etc.

    Right now I’m listening to my music in a console window, using mplayer. amarok plays, but remains silent when doing so.

    You’re doing important work, thank you!

    1. The qt-phonon vs. kde-phonon issue should be resolved in Qt >= 4.7, since it is now possible to use an external Phonon build with Qt.
      Phonon-vlc has indeed some build issues at times, but that is mostly because it is such a young backend and code is moving fast (sometimes too fast I guess :))
      So that should resolve the issues at hand.

      About having no sound… two thoughts a) another software is locking the audio device (e.g. pulseaudio?) b) the framework is missing a codec for the file.

  3. What’s the recommended backend for Phonon on Linux now? I use gstreamer on one of my pc’s, and it works, although it is not great, and Xine has some limitations I don’t really like. Is VLC up-to-par?

    1. Well, there is not really a recommended backend, since each is as limited as the underlying framework is (or not). I have heard good things about VLC (git master) lately, maybe you should give that a try. Also, if Fedora and/or Kubuntu really switch to the gst backend as default it surely will become better (it was a bit neglected in the past since about every distro used xine – except for what Nokia contributed, since they use the gst backend as default). Other than that we try to keep all backends at the same level of functionality and reliability.
      I recommended trying all and see what works best *for you*.

  4. Hi,

    Nice to see that phonon is making progress, but is there any chance to have basic features that a normal user like me expect ? I mean, 4 years of phonon and still no support for external subtitles for example (.srt, .sub,…). So I can’t use any phonon based player because i have lot of files with subtitles.

    Anyway, thanks for your work.

    1. Subtitle support has been talked about for as long as Phonon exists, so I must assume it is not that easy a thing to implement. I personally did not look at it in depth though. It is on my radar, but other things currently rate higher, so I can not make any promises. But since Phonon got a very powerful team these days I would expect that sooner or later someone will look into this :) – hoping sooner rather than later

          1. This patch is problematic due to missing some important features – settings of font size (!), font family, screen position, not autoloading of subs with name partially different from video file name (e.g. name.english.srt x name.avi). Or problem with all new phonon players not implementing menu items for manual loading of subtitles or code page settings.

  5. When will html5 videos work with good old Konqueror? :)))) It’s a bit sad that pioneer of free web needs proprietary plugins to view youtube in this age :'( It’s supposed to be up to Phonon am I right?

    1. This is really up to the KHTML rendering engine, to Phonon it would just be another media stream. Though to be completely honest, the work I wrote about, regarding QGraphicsScene is probably going to make things easier for the KHTML developers (same for QtWebKit for that matter).

      Actually I just tried it on KDE 4.5.3 and it seems to do basic video/audio tags just fine. http://people.ubuntu.com/~apachelogger/html5/

  6. Hi,

    in the future I’d like to use Phonon to capture video frames from a webcam and display them in Marble, turning it into an augmented reality geobrowser. For this, I’d like to access individual frames w/o the need of a Phonon::VideoWidget. Can I conclude from your statement “like direct access to video frames” that this will be possible in the future?

      1. Is it already working? There was (I think it is not supported anymore, not sure) a really interesting project called quasar http://vir.homelinux.org/blog/archives/119-Phonon-+-Quasar.html
        It used a frame grabber to return frames on opengl textures. It would be great to have this feature back, as with it, the gpu could be used to process individual frames. With previous versions of phonon it didn’t work.

        > The qt-phonon vs. kde-phonon issue should be resolved in Qt >= 4.7, since it is now possible to use an external Phonon build with Qt.

        Is there any instructions on how to do this? Or even how to build and use new phonon developments? I am very interested on trying it and help as much as I can, but at this time it is a mess for me on everything related to multimedia on kde/qt with phonon, qtmobility, qtmultimedia, qtgstreamer… It would be great on some instructions on how to setup a development environment for phonon..

        Thank you very much for all your work!!

        1. Quasar actually uses videodataoutput I believe. VideoDataOutput really just acks instead of a VideoWidget and instead of telling the framework to do overlay paintaing, it requests each frame from the framework and then forwards it to the consumer using the frameReadySignal(). VDO is also used in my QML/QGraphicsScene stuff.

          About Qt with Phonon: if i am not mistaken you just build Qt without Phonon and then build Phonon and Phonon (being a plugin to Qt) will then be available to Qt and KDE, I am not entirely sure though. Possibly Google knows more.

          Development envrionment for phonon is easy… Qt, cmake, then just try to build with cmake and cmake tells you what you need to get the individual stuff working (actually I think for phonon without backends you just need Qt, cmake and automoc).

  7. Sorry if this is not the place to ask but what means phonon will support pulseaudio AFAIK pulseaudio is what communicates to the devices, not a multimedia codec package, so phonon with use pulseaudio with what, gstreamer?

  8. Hi. I am compiling phonon from source from the master repo. I am installing as a normal user (and so to my $HOME) but still phonon seems to want to install some files to /usr. Namely /usr/share/qt4/mkspecs/modules/qt_phonon.pri.

    Is this just me? Is this behaviour intended?
    Anyway, thanks for your work.

    1. Well, yes, technically. The thing is, this file needs to be in the Qt path to be picked up by Qt, so that is technically is correct behaviour. However, I see the problem with it when phonon is installed in $HOME. If you could report a bug about it, I can get someone to look into it.

  9. Thank you for fixing and taking care of the GStreamer and Phonon.

    Why you don’t talk a bit about your new media player (cuppa is the name?)?
    It seems to be a nice looking player, something missing in KDE/linux. Personally I like the new QickTime X, but it is only for Mac OS X. It is very nice.
    The only one that is nice for KDE is Bakaar (from kde-apps) but it lack many features (some of them because of Phonon?).

    After ~3 years of KDE 4 release and Phonon, I think Phonon didn’t succeed. Why did Qt make QtMobility and QtMultimedia?
    Phonon has many bugs and missing features, many backends but non stable (working) multi OS backend, lack of subtitles support, no option to get data for analyzers and visualizations, gap-less playback (that is the backend responsibility?), and much more that are easy to find if it doesn’t work.

    Wouldn’t a direct GStreamer (or the new QtGStreamer wrapper) access be much more friendly with every one?

    1. “Why you don’t talk a bit about your new media player (cuppa is the name?)?”
      Because there is not yet anything to talk about ;) What is to be seen in the video is an interface that Kubuntu’s main artist originally created as mockup.

      “After ~3 years of KDE 4 release and Phonon, I think Phonon didn’t succeed.”
      I strongly disagree.
      The phonon description:
      <>
      Phonon certainly provides a very easy to use API for KDE developers and leaves users (and distributors alike) with the choice of backend. Now of course not every backend is equally stable or capable, but that is only natural, after all, their respective frameworks are also not equally stable and capable. The whole idea behind Phonon is that there is no truly perfect multimedia framework, and attaching oneself (as developer or user) to one of them might turn out to be a bad idea, as we have seen in KDE 2/3 with the arts daemon. That is not to say that there are no problems, however we have implementations coming for visualization (currently part of the experimental branch, until we are happy with the API), analyzers can already be done, gap-less playback is actually dependent on the backend if I am not mistaken.
      As for the general lack of features. We have great interaction with the Amarok team and try to accommodate their needs as quickly as possible.
      Now, one of the large topics always has been subtitle support. As I stated in another comment I am not really qualified to comment on this since I did not look into these matters, but what strikes me as a general problem is that no large KDE video player is working with us to identify and meet what they need. For example Kaffeine is still not using Phonon, I presume because something was missing. Now instead of resolving this for the benifit of everyoneby enhancing Phonon to meet their requirements, they chose the easy way out and hard depend on xine. That sort of thing does not bring Kaffeine or Phonon forward. In fact it is a problem for Kaffeine IMHO – on Kubuntu, if they choose to use phonon-gstreamer I doubt they would ever consider Kaffeine to become default player again, since it uses a completely different multimedia framework than every other application.
      As with so many things it is about going the extra mile…

      “Why did Qt make QtMobility and QtMultimedia?”
      QtMobility is for mobile devices. QtMultimediaKit is in existance because it provides lower level access to multimedia than Phonon, whether that is reason enough to create a new framework rather than enhancing the existing one is yet to be decided.

      “Wouldn’t a direct GStreamer (or the new QtGStreamer wrapper) access be much more friendly with every one?”
      Sure, if you do not need your application to work on Windows or OSX without much hassle, then either of those is as good a choice as Phonon. Initially I came to join free software via Amarok, and even in Amarok we had like 4 different playback engines, because really no multimedia system really cuts the cheese. But really, the strongest argument against using a system directly is portability. If one does not need it, or if one wants to implements an own abstraction that is tuned towards the specific needs at hand, then using any framework directly is a very viable option.

      It is not like Phonon is meant to be the messiah of multimedia, it has a very specific target and I feel that it fills that very well at this point. Of course now we can go beyond the original target and do things like providing low level access to the playback data.

        1. Phonon is limited on paper too, because it is meant to be. I can send you the appropriate designs that show exactly in which regards phonon was meant to be limited and in which it is meant to be super scalable. Additionally if you wish I can recommend some good books on software designs, I am sure it will all be much clearer after having read one or two of those.

  10. Thank you for the answer apachelogger!

    Currently the GStreamer backend for phonon works (for me) right for audio, but for video I need to use a non-phonon player, because it is to super basic for a video player (in contrast to VLC or SMPlayer). That is why for me, Phonon, as of today has not succeed, and it would have been easier to use e.g. GStreamer directly. As I remember the problem was the uncertainty if the API would be stable for the KDE 4 life. But now so many GTK+ (and non GTK+) apps use it with no problems (AFAIK).

    I thought GStreamer crossplatform use is not problematic. Recently Clementine (the Amarok 1.4 fork to Qt 4; minus KDElibs dependencies) has made use of GStreamer, and it works also in Windows and Mac OS X. I don’t know if they had mayor problems with it, but as far as I have read from them, it solved many issues.

    looking forward the new media player! :)

    1. I could, I do not really see the need for it though. Everything worth saying is already there in the second comment. Also due to backwards compability this is a no-brainer, right now we could not ditch phonon, and discussing things that might be in 3 years, or more, is next to useless.

  11. Does any combination of phonon and its backends support crossfading? I asked this on the amarok forums but their fingers pointed in the direction of phonon and its backends saying it is not their fault…
    It’s sad to say but after all this time there still seems to be no way to smoothly change between two songs using phonon. For me as a DJ that likes to use KDE and amarok this means I still stick with kde 3.5 and amarok 1.4 on my machines :(

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s