Phonon Loves Codecs

As the Phonon team is hard at work to prepare for the release of Phonon 4.4.4, the GStreamer backend has seen some awesome improvements these past few days.

Not only will it be the second backend to support the experimental video capturing features introduced with Phonon 4.4.3 but has also seen tremendous improvements with regards to stability. But most importantly of all it got improved codec installation support.

If you ever found yourself looking for a way to play that mov video a friend sent you, then you will love Phonon GStreamer 4.4.4. Whenever it can not play a file because a media plugin is missing, it will now try to get it semi-automatically. Check out the screencast:

This gives user experience quite a boost, so I am most certain that Linux distributions will pick this up and integrate it nicely with their package management systems.

In the video KPackageKit is handling the plugin lookup and installation, so both Fedora and Kubuntu should have this awesome feature in their next releases.

Have fun πŸ™‚

37 thoughts on “Phonon Loves Codecs

  1. What significant advantage does Phonon Gstreamer Backend have over the Xine Backend? It seems both Fedora and Kubuntu are considering moving to Phonon Gstreamer going forward I just wanted to know what the draw backs and advantages of such a move.

      • Ok, but the same goes for VLC, right?

        (I’m sorry, but like many others, I have had so many bad experience with GStreamer that I won’t trust it for the next 2-3 years, however great it suddenly becomes)

        • Of course, I only compared to Xine πŸ˜‰
          Ultimately my personal target is to have the GStreamer and VLC backends at high quality and leave it to distributors to decided what they feel is best for their target audience.

      • I’ve always liked Xine and therefore, the Xine-backend. Hopefully Xine itself will keep developing, even if slowly, and not be abandoned by distributions, etc :\

  2. shouldn’t the entire (or more of it) procedure be invisible ?
    wanting to play a movie or an audio file, can’t it just work? without having to approve this and OK that..

    • That entirely depeneds on the actual implementation. Phonon just calls an application with a set of arguments and waits for it to terminate at some point. So, technically it can absolutely be done without any user input whatsoever.
      Say there are phony packages around for one reason or another, and installing a codec package actually brings the package tree in such a state of inconsistency that half the system must be removed. I personally would hope that an application asks me before ripping my system apart πŸ™‚

      This is however really up to the implementation. I hope that answers the question.

  3. Cheers. :>

    I’m confused though. Which Phonon backend is considered to be the best working of the bunch, at present? Are there differences in features, like an interface to Amarok’s equalizer? Is there a “preferred choice”, as it were?

    In addition to the Xine backend that’s default in Kubuntu, I remember reading blog posts about the VLC backend reaching a usable state. Maybe I’m overthinking stuff but I’d just like to know the state of the Phonon backend union.

    • As of Monday the official rating for the git versions of the backends is as follows: GStreamer > VLC > Xine. There are multiple reasons for that, but most importantly that Xine is practically unmaintained and the VLC backend still lacks some features, like it does not have an equalizer (that however is also a bit of a design problem because you will observe that it does not work with GStreamer in Amarok either, because of a bug in Amarok which should have been prevented to begin with).

      When I say official rating I mean the initial preference with which Phonon will choose a backend if all three of them are installed.

      • No, GStreamer actually sucks (its devs haven’t released 1.0 for a reason). Whether it’s plain GStreamer or acting as a back-end.
        For me GS never worked right — often not playing files that should be supported (large chunk of my MP3 collection and some Vorbis files as well). VLC has no problems with those files and back in the day, when I was still a Mac user, iTunes/QuickTime had no problems either (even the Vorbis files, when I had XiphQT installed!).

        From the discussions I followed GS is only the recommended Phonon back-end because QtWebKit requires it and putting two back-ends on live CDs would “waste” CD space.
        While I seriously appreciate work on FOSS, to me it would seem more logical to make QtWebKit work with any Phonon back-end instead of hacking Phonon-GS which — in the end — will still use sub-standard GStreamer 0.x.
        Maybe one day, when the GS project gets 1.0 out of the door, will GS be mature but until then I recommend VLC.

        • What would the reason be for which they have not released 1.0? I take it you reported bugs about the not playing issue? Phonon does not create live CDs!? Nor do we particularly care what other Qt projects choose to use.

          GStreamer is currently rated highest because it is actively developed upstream and within Phonon, the backend implementation is around for a long time and supports all our features. Additionally GStreamer is a project and as such is more spread on the Linux desktop than the other multimedia frameworks we currently have around, making it a solid choice for Phonon on Linux.

          • I don’t report bugs on software I don’t use (using Phonon-VLC ever since it entered openSUSE’s repos, before that Phonon-Xine was better), esp. when it’s closed source (GS’s MP3 decoder is proprietary). And what kind of bug report would β€ždoesn’t play my filesβ€œ be anyway? It’s not like it prints an error message or anything. It’ll be closed as NEEDINFO (which I can’t provide) and that’ll be it.
            When I encounter VLC bugs (which is very seldom) I report them.

          • I am sure that a decoder based on libmad, which is GPL, could be distributed as closed source without violating the GPL:

            … or maybe not?

            Also GStreamer provides an incredible flood of debug information actually.
            With Phonon-GStreamer from git all you need is something like
            export PHONON_GST_GST_DEBUG=10
            that will print so much debugging that it is entirely possible that your PC would lock up. So I wonder if a bug would be closed as NEEDSINFO because one simply cannot get it, or because one is not willing to.

          • GStreamer’s MP3 plugin that is offered by Linux distributors is proprietary because it’s the “legal” way to do.

            And no, I won’t debug GStreamer. I don’t see any reason why I should when at the same time VLC is working beautifully.

            Hey, if you want to work on GStreamer: Fine. I am always applauding all work on FOSS, whether I personally use it or not.
            I still think developing a Phonon interface to QtWebKit would be the more sensible way to go and leave the choice to the users.
            Btw, if you’re trying to tell me that your sudden support for GStreamer (just a while ago VLC was the great thing….) is not influenced by your work on Kubuntu and the decision to focus on GStreamer because QtWebKit mandates it anyway, I simply won’t believe you.

          • If you are using proprietary software when there is a free alternative, that is your problem, nothing is stopping you from building the mad plugin yourself. Even with the proprietary plugin GStreamer is plenty debugable as its particular architecture provides close insight of what is going in and what is going out of the plugin, making it for those people who actually have access to the plugin’s code, incredibly easy to find out what is, or could be, going wrong. But since you do not want to help them improve the software all this does not help and for that matter no improvement will take place which essentially provides the means for your argument being valid for many years to come. Certainly you see the problem with saying something is crap and then not being willing to contribute to changing that, which is a bit of a silly chain of conditions as the not giving feedback prevents an improvement and the missing improvement then is making it possible to rant about the software for much longer. Of course I recon that complaining about something that is not changing because one is not doing anything about the not changing part is a lot more fun than actually sitting down for a couple of minutes to help move things along, just like using a solution that already works is a lot more fun than creating a new one. I guess that is also the reason why we all still use Windows. In the end it probably all comes down to being exclusive. Being exclusive by using this and not that, being exclusive by being part of a vocal minority, being exclusive by working on GStreamer software, which evidently is mutually exclusive with working on any other multimedia software, that is why I started work on a mobile vlc player, although I now need to stop working on Phonon and GStreamer due to the mutually exclusiveness.

            What also contributes to exclusiveness is doubting someone’s word and spreading FUD, so here is an exclusive warning: do not spread FUD and suggestions about my motivations. Kthxbai

        • the 0.x or 1.x is only a version number. Did you see Chrome 9? Linux 2.6.36? Why is it not version 3? K3b 0.12.17? It was stable for many people then. Mac OS X 10.6? The 10.x is more than a decade old. GStreamer 0.10.31, What is the problem with that?
          Seriously, what are you talking about?
          Maybe you have a hardware problem, or in your distribution.

          GStreamer work fine for many millions. Do you know GNOME uses it? Palm, Nokia…

  4. Some month ago I thought that VLC will become the default recommended backend and now it’s gstreamer… But in the end, I don’t care, I never had problem with “plain” gstreamer and my only interest is to finally see 1 full featured and well maintened backend.
    And I’m really happy to see an increase of commit rate in git lately and also about the roadmap for the 4.5 release, nice features to come πŸ™‚
    Thanks for your work and to the phonon team πŸ™‚

    • Well, it is not like this could not change. VLC has advantages of its own and we are going to make it at least an as good choice as GStreamer, because we want a brilliant crossplatform backend and VLC of all the available options works on most platforms in best quality. πŸ™‚

  5. When installing other gstreamer packages isnt your system interacting with the package manager?
    How is this a gstreamer feature and not the package manager feature, is this independent of package manager? I am using Arch pacman, will this feature be as transparent in Arch?

  6. Man I’m loving this! I’m sooo glad KDE chose to go the Phonon route with 4.x. It provide so much flexibility and agility, while allowing us multimedia app developers to focus on delivering great apps instead of worrying about picking which codecs to support, etc.


  7. I recently switched back to phonon-xine after I identified phonon-gstreamer as the cause of my Amarok problems (it couldn’t play any of my music files).
    Will this update fix that problem?

  8. My main concern about GStreamer is poor jackd support. My soundcard is a firewire soundcard and has jackd drivers but no alsa driver so no jackd support = no sound for me. While GStreamer has jackd support (in the bad plugins) last time I checked there were a lot of issues the GStreamer devs were either unwilling or unable to put energy into making things work.

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s