VLC With Phonon Back-End Is Now Ready For Use

[next9]

Yeah i am sure you agree it sucks, you don't use it after all. I am sure that your agreement that it sucks doesn't equal a comment from your part...

LOL @trolls

I do not need to test GStreamer every day to be able to have some relevant experience, do I ?

I usually try GStreamer on qaurter-year / half-year basis, when I test some GNOME based distro like Fedora or Ubuntu. I usually test GNOME on my favourite distro too each new distro release. Just because I am curious. Then I use GNOME "centric" multimedia applications like Totem, Exaile, rythmbox, etc... And I am not satisfied with them.

I was excited of new Amarok 1.4 QT4 port called Clementine, but later my experience with this player became worse. Guess what... They change traditional Xine backend to GStreamer backend.

You should look around yourself. I am not the omly one who do not like this multimedia framework.

[next9]

Gstreamer IS a better solution. If KDE devs had their way in everything, we would remain in HAL for ever... GNOME, while conservative, makes better infrastructure choices...

So. If Gstreamer devs became idiots, or let their project go way KDE devs or users do not like, you expect Apps developers to rewrite GStreeamer backend to another backend for each of zillion applications? This is what you call better solution?

In this case when using GStreamer apps you become stuck with unappropriated solution, when using KDE/Phonon apps, you can use whatever you like, even GStreamer. After all I do not notice any difference between GSTreamer apps and apps using Phonon-GStreamer backend.

But maybe you like the way of "only one right component" (TM), so I would advise you Bill has a nice operating system for you.

[deanjo]

Most people use gstreamer.

most != best solution

There must be a reason...

[popper]

So. If Gstreamer devs became idiots, or let their project go way KDE devs or users do not like, you expect Apps developers to rewrite GStreeamer backend to another backend for each of zillion applications? This is what you call better solution?

In this case when using GStreamer apps you become stuck with unappropriated solution, when using KDE/Phonon apps, you can use whatever you like, even GStreamer. After all I do not notice any difference between GSTreamer apps and apps using Phonon-GStreamer backend.

But maybe you like the way of "only one right component" (TM), so I would advise you Bill has a nice operating system for you.

its not clear what your trying to say, but you don't seem to understand that ALL THESE 3rd party app's you mention are all indirectly using FFmpeg/libavcodec API/lib at the core weather you know it or not.

funny enough all the distro's you mention are all using older FFmpeg/libavcodec API/lib, even though the FFmpeg/libavcodec/x264 code bases chance with patches ,sometimes daily and at least weekly/fortnightly,

also its odd that that bill's OS apps can and do use the current and up to date FFmpeg/libavcodec/x264 code bases as and when their GIT masters get updated, so why cant your given distro's do the same and give you a far better base, clue stick, quartery/half yearly is way to slow and far behind the current upstream API codebases.

[pingufunkybeat]

You do realize that you say the current version of gstreamer sucks, based on your experience with a way old and unsupported version of Amarok and KDE?

No, actually, I said that I had problems with GStreamer a few years ago, and that I'm sure that they have been fixed in the meantime.

I have NEVER said that the CURRENT version of gstreamer sucks.

You really have problems with reading...

Yeah i noticed. That is why i said, your problems are with the backend, the backend sucks and is unmaintained, not gstreamer itself.

No, my problem is not with the phonon-gstreamer backend, since I have never actually used the phonon-gstreamer backend.

I've only used GStreamer alone, through Amarok, and it sucked. I don't know how it is today, it's probably better, but the choice is good.

Gstreamer IS a better solution.

It can't be the better solution, if it doesn't even attempt to do the same thing.

GStreamer is not comparable to phonon. Phonon is a higher-level API.

[pingufunkybeat]

if by "VLC's codecs" You actually mean all of libavcodec's codecs then fine.

Yes, that's what I mean. GStreamer, xine, mplayer, and VLC all use FFMpeg's libavcodec, and FFMpeg is doing much of the really hard work that makes these projects good.

Remember all these 2nd tear backend's are In fact using the FFmpeg/libavcodec API/lib SO go and help them fix any problems you have by simply writing a patch for FFmpeg/libavcodec ,actually subscribe to the FFmpeg/libavcodec mailing list and post these patches, and Make the 3rd party app dev's actually pull a current and up to date FFmpeg/libavcodec Directly instead of pissing about back porting Old versions of this fundamental FFmpeg/libavcodec API/Lib

I don't know why you think that I'm "pissing about back porting", whatever that means.

I think that FFMpeg is awesome, and I support them, even if I don't contribute code.

Did you confuse me with somebody else?

[pingufunkybeat]

If KDE devs had their way in everything, we would remain in HAL for ever...

KDE does not need HAL anymore.

And no software has to be rewritten. You just need to update Solid. Just like you can change your backend from gstreamer to vlc in ANY phonon-based app without rewriting anything.

That's why good APIs are important. GNOME people had to rewrite every piece of software which touched HAL. That's not good infrastructure.

I suggest that you stop writing about things you don't understand. Like software

[popper]

Yes, that's what I mean. GStreamer, xine, mplayer, and VLC all use FFMpeg's libavcodec, and FFMpeg is doing much of the really hard work that makes these projects good.


I don't know why you think that I'm "pissing about back porting", whatever that means.

I think that FFMpeg is awesome, and I support them, even if I don't contribute code.

Did you confuse me with somebody else?

No Not You as in just "YOU" pingufunkybeat, but rather You the/any person reading the thread capable of writing patches even if you are one of the google code-in students for instance learning C/assembly etc

http://www.google-melange.com/gci/program/show_ranking/google/gci2010

[next9]

its not clear what your trying to say...

That is because there too many types of apps:

1) KDE project KDE apps (original applications from KDE project, using Phonon)

2) third party KDE apps (third party KDE applications, using Phonon)

3) independent multimedia apps (using direct xine/vlc/mplayer/GStreamer backend)

4) standalone multimedia apps (they are backends on their own - VLC/Xine/Mplayer)

5) third party GNOME apps (third party GNOME applications, using GStreamer)

6) GNOME project GNOME apps (original applications from GNOME project, using GStreamer)


I know these categories are not accurate, but they show 3 ways. KDE apps use backend abstraction to write the multimedia framework backend once, still let user to choose backend. GNOME apps use GStreamer, thus amount of coding work is similar to KDE, but user is forced to use the only one (TM) backend. Indepemdent apps choose their way, maintaining direct backends to multimedia frameworks on their own.

According to this I see KDE apps approach and Independent apps approach best for user, since he can decide to use whatever backend he likes. I see KDE apps approach and GNOME apps approach most coding-efficient (good for developers) since the application backend support is written only once. But, GNOME-apps approach gives me no choice.

I do not understand, how could anybody call GStreamer approach the best solution, since the user have no choice to alter the backend, and If necessary you still have to add new backends writing them from scratch for each app.

[pingufunkybeat]

Anyway, for those who still haven't figured it out:

This is how you play an ogg/vorbis file using GStreamer directly: http://gstreamer.freedesktop.org/dat...ion-helloworld

This is how you play an ogg/vorbis file using phonon: http://techbase.kde.org/Development/...n/Introduction

That's what "high-level API" means. 4 lines instead of 100 lines. Phonon hides the unnecessary complexity from you, so even people who are not multimedia professionals can play a friggin' mp3. I mean, deleting pipeline objects by hand? g_main_loop_run( loop ) ?!? Just play the bloody thing!

Not everybody needs frame-accurate seeking, 1000 plugins and advanced postprocessing. People who do not need this use Phonon.