The GStreamer developers have just released version 0.10 of the GStreamer multimedia framework into the wild, and their coders' fingers will never be the same. "Thread-safety, RTP/VoIP support, automatic registry maintenance, twice the performance, and a whole lot more...the best just got better. A highly flexible, cross-platform, and GUI-independent multimedia framework, GStreamer takes your media, chews it up, and spits it out into aural and visual paradise. Especially targeted at GNU/Linux and Unix operating systems, the GStreamer team has been working with certain members of the KDE community for a long time. With this release we have a stable, extendable and robust multimedia solution." In conjunction with KDE MM, GStreamer is one of the possible multimedia frameworks that will be available for KDE 4.
Please read the release announcement to get an overview of what is new and improved in the 0.10 series. The input and feedback of the KDE community would be much appreciated as the GStreamer developers continue their breakneck pace towards the holy grail of GStreamer 1.0.
GStreamer is a generic multimedia framework based around the concept of
media pipelines linking elements, providing support for all manner of
things. In GStreamer you'll find plug-ins supporting multimedia file
formats, firewire and USB cameras, sound cards, windowing systems,
transcoding, networking, audio and video transformations and much more.
Mark Kretschmann, project lead of the amaroK music player said "I am looking forward to porting amaroK over to GStreamer 0.10. Many of the problems our users experienced with the 0.8 version seem to be addressed in GStreamer 0.10, especially the responsiveness issues we faced. So to make it short, GStreamer 0.10 is gonna be a blast, I'm totally into it!"
Aaron J. Seigo commented on behalf of KDE e.V., "multimedia is a central theme for desktop computing, so making meaningful strides towards open source media solutions that provide what application developers as well as users need is critical. Recognising how non-trivial software that addresses this problem space in a portable and open manner is, and given that several KDE applications provide GStreamer support already today, we are happy to see the milestones that are being met by the GStreamer project. The future of multimedia in Open Source just keeps looking better and better. Congratulations on a successful release!"
Comments
I read somewhere about support for win32 codecs in gstreamer, but don't know the URL anymore.
Did someone know this URL?
Thanks :)
The project is called pitfdll (http://ronald.bitfreak.net/pitfdll.php).
I don't think it's been ported to GStreamer 0.10 yet though
Actually, I take that back - http://cvs.sourceforge.net/viewcvs.py/pitfdll/pitfdll/ChangeLog?rev=1.20... says differently (about having been ported to 0.10)
thank you!! :)
I use amarok with Xine engine cause it's much faster on my old CPU, is the new gstreamer as fast and light than xine?
Possibly, yeah. Note that the GStreamer engine in current amaroK versions (> 1.3.1) has also become quite performant. But we hope it's gonna be even faster with 0.10, no doubt.
I beg to disagree. In my experience, GStreamer has been unusable while attempting to play streaming media even in the latest AmaroK! It will buffer up to 100% and re-buffer again and again till for ever! I have always relied on the Xine engine which has never dissappointed me in any way. This has made me wonder why it is bundled with Amarok by default yet it's deficient in the streaming department, leaving out Xine which just works.
I hope you have filed bugreports about that so that people have a chance to fix it for the next version.
Last time I checked, Xine was the default for amaroK
Yep, xine has a higher plugin priority then gstreamer (so if you have both installed, xine will be used).
I want to say I had the exact same experience with streaming audio. Its two seconds of audio, one second of silence. Definately not usable. Hopefully this version will be better.
I've found that just isn't the case, it uses maybe 50% CPU on my 800mhz duron just to play an mp3, wheras xine and especially arts hardly need any.
For me, the timing for this release was pretty coincidental. I was doing some web searches during some free time today looking into what multimedia backends could be used with remote X applications. At first NMM seemed to be a pretty good fit, but they don't really support amd64. Someone patched it to build on that platform, but they state that it doesnt work over the network from amd64->x86.
It looks like gstreamer has a tcp src/sink. I'll probably be testing it soon.
Has anyone had any success with gstreamer or any other audio backend for remote X applications? (over ssh?)
Xine with esd backend works out best for me, right now. As I exclusively use thinclients at home, I have to rely on networked multimedia heavily and did try several alternatives (nas, gstreamer + esd, nmm, even OpenSSI with a remote /dev/dsp).
This applies to audio only, video is a different story (synchronized audio+video, 100MBit LAN not enough for streaming decoded video). NMM should do the trick here, in the future.
If you have limited bandwidth (ssh?), you should try NMM, as decoding is done there at the audio sink.
Okay: my KDE desktop wishlist
- real Multimedia support for video and audio plus editing tools
- grammar checker
- desktop search framework and proper metadata
- unified freedesktop registry namespace (elektra??)
- cross desktop icon theming
Classical thread hijacking :)
"- real Multimedia support for video and audio plus editing tools"
Do you mean Real audio support? If yes then thats already available (may need the win32codecs, or to install the native realplayer/helix). There are some video editing tools on kde-apps.org (not sure how good they are, and not sure if there are any good audio editing tools). What exactly do you mean by 'tools'? (like for cutting scenes and adding special effects? or just like transcoding from one format to another and editing tags?)
"- grammar checker"
Don't hold your breath for a /good/ one (expect focus follows mind before that).
"- desktop search framework and proper metadata"
Kat+Tenior framework will provide exactly that (Tenior is using Kat as the base engine instead of making its own)
"- unified freedesktop registry namespace (elektra??)"
If you mean a unified configuration system for desktop applications, then thats possible since I remember people working on a crossdesktop configuration standard (though again don't hold your breath for elektra, 'registries' aren't that popular, especially since the best known registry makes everyone cry)
"- cross desktop icon theming"
The Tango naming standard (which Oxygen ix following IIRC) should solve that issue.
"The Tango naming standard (which Oxygen ix following IIRC) should solve that issue."
Actually, that's the freedesktop.org icon naming standard that Tango has chosen to use and which KDE4 was probably going to use anyway. It bugs me slightly that Tango has grabbed such a mindshare for supposedly taking the lead on this.
John.
Don't be -- it helps no one if KDE got a bigger mindshare on the idea -- the contributors know who they are, and everyone that cares know who they are. By having FD.o push it without any hint of desktop bias helps to get the gnome and xfce, openbox, enlightenment, etc people involved and supporting it, and that will benefit everyone.
That's exactly what I meant, the spec is an FD.o project, so the credit and focus should go to FD.o, rather than to a Gnome project...
John.
"rather than to a Gnome project..."
... which Tango is not.
> ... which Tango is not.
Look at this page: http://tango-project.org/The_People
Can you tell me which developer works on KDE? Answer: none.
Can you tell me which developer works on XFCE? Answer: none.
Can you tell me which developer works on E17? Answer: none.
Can you tell me which developer works on GNOME? Answer: all.
Looking at that page the answer is that only one of those people is acutally a devloper of any sort, and there are only 4 who have a GNOME history.
But hey, thanks for coming out and adding to the FUD.
I thought that Tango was the name of the standard, and also included an icon set and stuff.
Tango is an icon and desktop theme project.
http://tango-project.org/Standard_Icon_Naming_Specification
"- unified freedesktop registry namespace (elektra??)"
If you mean a unified configuration system for desktop applications, then thats possible since I remember people working on a crossdesktop configuration standard (though again don't hold your breath for elektra, 'registries' aren't that popular, especially since the best known registry makes everyone cry)
OpenLDAP anyone?
> OpenLDAP anyone?
That really would make me cry.
I have no problem with a registry concept for configuration, but OpenLDAP would be massive overkill - at least for local configuration.
I can see where it would be useful for roaming profiles, but even in that case you'd want to copy all the configuration to a local cache on login, and then store the changes on logout. (Or maybe on a finer-grained level - at app startup and shutdown).
Actually, it would be useful to have a plug-able arch (think PAM). Personally, I would like to see my data separated from config files. I hate the fact that I have to do a bit of work to get somebodies data into a new KDE archs (I find it better to start with the defaults) .
Actually I think KConfig is supposed to be backend independent, but no other backend than the ini file one has been developed. If I remember correctly it should be possible to write backends that use things like LDAP, PAM or SQL. Try searching kde-core-devel, there was some discussion a while back(Well, 2-3 years or something:-)
> Kat+Tenior framework will provide exactly that (Tenior is using Kat as the base engine instead of making its own)
The approach is insufficient. The "engine" should not be desktop dependent, but a daemon, able to contact other boxes as well (given the user has the right to search those). The GUI should just be the sugar. What does it help when I can search my local box, but not my data server, which doesn't run KDE at all?! Shall the data to be indexed go over NFS or SMB or what?
When I think about KDE, I see everything thick and big (thick borders, big buttons). I'd love to see everything thinner and more professional in KDE 4.
Charles.
GStreamer has saved me on a number of occasions when I've had to knock up custom gst-launch pipelines.
But Xine just works (even without the merketing blabla like "..the best just got better").
I agree with previous posts, Xine is currently the most functional multimedia engine. GStreamer is not as responsive and compiling it is not as easy. Anyway I hope it is now usable so I can keep the Kubuntu defaults for amaroK and Kaffeine. Anyway stop the marketing-speak.
Yeah. It's true. GStreamer with amarok on my 7.1 audio sounds like ... Xine is just much better. I'm not c++ developer but if Xine is similar framework to GStreamer please take Xine into new KDE
Have any of you tried amaroK with NMM? How does it compared functionality and performance wise to Xine/GStreamer/aRts?
Regarding your complaint about Changelogs only for final, there are full ChangeLogs for all the modules through the full 0.9.x development cycle.
You find them at - http://gstreamer.freedesktop.org/releases/
Xine is just a playback engine.
Gstreamer is an entire multimedia framework.
I have tried to compile last kaffeine version with gstreamer part (gstreamer 0.10) but, during the execution of the configure script it says "Gstreamer found" but finally it says that it won't compile the Gstreamer part (?).
Has anyone experienced the same problem?
My version of kaffeine has the gstreamer plugin and it doesn't seem to ever work for any video files, so just stick with Xine (IMHO Xine is far better than GStreamer)
GStreamer 0.10 isn't source compatible with apps written for gstreamer 0.8.
My apologizes but I don't want the GNOME stuff to be part of KDE due to my personal political opinion.
KDE is about software, not about politics.
GStreamer is not GNOME specific, although it is the default MM framework in GNOME.
ac is being ironic ;)
Yet it dependent upon Glib, which is a core GNOME library. It doesn't mean we have to use GNOME for KDE, but it does mean that it makes KDE somewhat dependent on GNOME's release quirks. If you thought rebuilding KDE everytime there was a new KDE release, just wait until you have to do it with every GNOME release!
Glib isn't Gnome, like GStreamer isn't Gnome. There are even commandline tools using glib.
btw. Parts of KDE already depands on glib.
To be more precise, glib was part of the GTK (the GIMP toolkit). Later it has been split off and is now low-level C library that is used by many C projects.
.. but it's still GNOME!
No. Glib and GTK are not part of GNOME, just as Qt is not part of KDE.
Yeah so do I, not because of your 'personal political opinion' but because Mondays never fall on Tuesdays (and vice versa).