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 🙂
💺 Blog 
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.
With GStreamer both the backend and the underlying framework are actively developed.
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
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.
BUT
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.
These are the small things that makes the difference.
Your blog posts are very interesting, thank you.
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 freedesktop.org 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: http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/gst-plugins-ugly-plugins-plugin-mad.html
… 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…
Yeah right…. hardware problem when the only misbehaving software is GStreamer…. lamest excuse for broken software ever.
I also tried GStreamer from two entirely different repos. Same result.
If GStreamer was actually stable, its developers would kill the leading zero in the version number.
Check the Phoronox forums. Many people have problems with GStreamer there.
If it works for you: Fine. I’m happy for you. Really.
Maybe GStreamer works well for 70% of all users. It would still be the majority — by far. Still 30% would have problems with it. I’m one of those and I have yet to hear about large-scale problems with VLC on a codec-basis.
http://www.gstreamer.net/data/doc/gstreamer/head/faq/html/chapter-developing.html#developing-versioning
What app do you use to screencast? ffmpeg?(I never managed to make it record the playback of my system, what options you use?)
http://verb3k.wordpress.com/2010/01/26/how-to-do-proper-screencasts-on-linux/
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. 🙂
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?
It is not interacting with the package manager, that is the beauty of it 😉
http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstpbutilsinstallplugins.html
What basically happens is that a helper application is called with the codec that is needed and that helper then takes care of the distribution specific work. So it is absolutely transparent. As long as a gstreamer-codec-install script/binary/executable is provided it will work.
There are many gstreamer packages base , ugly etc etc…i only have the base installed…how can it install the ugly package if it doesnt interact with the packagemanager?
I mean in your case I think kpackagekit is doing the job isn’t it?
That is up to gstreamer-codec-installer. Either it manually maps the plugin names manually to packages or resolves them based on a pre-generated database… Endless options there really.
AFAIK PackageKit (incombination with its aptcc backend) generates a cache for this whenever the package cache itself gets updated.
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.
Thanks!!!!
🙂
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?
Most likely.
Thank you.
We should also later expand this to all files, not just media
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.
Well, there is still VLC 🙂
I am not very much into JACKd, so I cannot really give advise, but possibly pulseaudio also helps with that a bit.
Jack support used to be in the gst-plugins-bad collection, and 5 days ago was migrated to gst-plugins-good.
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=a197901b82c22db9d8441eadba8063151c994b22
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/jack
Hope this is of use.