GStreamer 0.10 Released

Saturday, 10 December 2005  |  Criddell

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:

win32 codecs - anonymous - 2005-12-10

I read somewhere about support for win32 codecs in gstreamer, but don't know the URL anymore. Did someone know this URL? Thanks :)

Re: win32 codecs - Jan Schmidt - 2005-12-10

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

Re: win32 codecs - Jan Schmidt - 2005-12-10

Actually, I take that back - http://cvs.sourceforge.net/viewcvs.py/pitfdll/pitfdll/ChangeLog?rev=1.20&view=log says differently (about having been ported to 0.10)

Re: win32 codecs - anonymous - 2005-12-10

thank you!! :)

speaking of amarok - Patcito - 2005-12-10

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?

Re: speaking of amarok - Mark Kretschmann - 2005-12-10

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.

Re: speaking of amarok - charles - 2005-12-10

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.

Re: speaking of amarok - John Doe - 2005-12-10

I hope you have filed bugreports about that so that people have a chance to fix it for the next version.

Re: speaking of amarok - rinse - 2005-12-10

Last time I checked, Xine was the default for amaroK

Re: speaking of amarok - Ian Monroe - 2005-12-11

Yep, xine has a higher plugin priority then gstreamer (so if you have both installed, xine will be used).

Re: speaking of amarok - LuckySandal - 2005-12-10

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.

Re: speaking of amarok - mikeyd - 2005-12-11

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.

Network Transparancy? - John M. - 2005-12-10

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?)

Re: Network Transparancy? - Jörg Bakker - 2005-12-12

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.

KDE wishlist - manes - 2005-12-10

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

Re: KDE wishlist - Mark Kretschmann - 2005-12-10

Classical thread hijacking :)

Re: KDE wishlist - Corbin - 2005-12-10

"- 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.

Re: KDE wishlist - Odysseus - 2005-12-10

"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.

Re: KDE wishlist - genneth - 2005-12-10

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.

Re: KDE wishlist - Odysseus - 2005-12-11

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.

Re: KDE wishlist - Reply - 2005-12-12

"rather than to a Gnome project..." ... which Tango is not.

Re: KDE wishlist - Anonymous - 2005-12-12

> ... 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.

Re: KDE wishlist - ryan - 2005-12-12

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.

Re: KDE wishlist - Corbin - 2005-12-10

I thought that Tango was the name of the standard, and also included an icon set and stuff.

Re: KDE wishlist - James Richard Tyrer - 2005-12-10

Tango is an icon and desktop theme project. http://tango-project.org/Standard_Icon_Naming_Specification

Re: KDE wishlist - Mitra - 2005-12-10

"- 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?

Re: KDE wishlist - mabinogi - 2005-12-11

> 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).

Re: KDE wishlist - a.c. - 2005-12-11

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) .

Re: KDE wishlist - Morty - 2005-12-12

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:-)

Re: KDE wishlist - Carlo - 2005-12-12

> 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?

Re: KDE wishlist - Charles - 2006-09-18

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.

Yippee! - Robert - 2005-12-10

GStreamer has saved me on a number of occasions when I've had to knock up custom gst-launch pipelines.

Nice marketing campaign! - Marc - 2005-12-10

But Xine just works (even without the merketing blabla like "..the best just got better").

Re: Nice marketing campaign! - Flavio - 2005-12-10

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.

Re: Nice marketing campaign! - what? changelogs ony for final?? - 2005-12-10

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

Re: Nice marketing campaign! - Morty - 2005-12-10

Have any of you tried amaroK with NMM? How does it compared functionality and performance wise to Xine/GStreamer/aRts?

Re: Nice marketing campaign! - Christian - 2005-12-11

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/

Re: Nice marketing campaign! - Robert - 2005-12-12

Xine is just a playback engine. Gstreamer is an entire multimedia framework.

Kaffeine compatibility - One kde user - 2005-12-10

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?

Re: Kaffeine compatibility - Corbin - 2005-12-10

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)

Re: Kaffeine compatibility - Ian Monroe - 2005-12-11

GStreamer 0.10 isn't source compatible with apps written for gstreamer 0.8.

Thanks for paying attention - ac - 2005-12-10

My apologizes but I don't want the GNOME stuff to be part of KDE due to my personal political opinion.

Re: Thanks for paying attention - St. Kevin - 2005-12-10

KDE is about software, not about politics. GStreamer is not GNOME specific, although it is the default MM framework in GNOME.

Re: Thanks for paying attention - Ian Monroe - 2005-12-11

ac is being ironic ;)

Re: Thanks for paying attention - Brandybuck - 2005-12-12

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!

Re: Thanks for paying attention - Susi - 2005-12-13

Glib isn't Gnome, like GStreamer isn't Gnome. There are even commandline tools using glib. btw. Parts of KDE already depands on glib.

Re: Thanks for paying attention - cl - 2005-12-13

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.

Re: Thanks for paying attention - ac - 2005-12-14

.. but it's still GNOME!

Re: Thanks for paying attention - SR - 2005-12-15

No. Glib and GTK are not part of GNOME, just as Qt is not part of KDE.

Re: Thanks for paying attention - Empty Head - 2005-12-10

Yeah so do I, not because of your 'personal political opinion' but because Mondays never fall on Tuesdays (and vice versa).

Re: Thanks for paying attention - k - 2005-12-10

I agree. Please keep glib out of KDE! Glib is EVIL!

Re: Thanks for paying attention - reihal - 2005-12-11

This could be a clever way to konvert some of those evil gnomesters to see the light.

Re: Thanks for paying attention - Odysseus - 2005-12-11

Well, you won't have to, that's the beauty of the new KDE-MM api, you get to choose your back-end, KDE4 won't dictate it to you. John.

Re: Thanks for paying attention - ryan - 2005-12-12

pray tell, how on EARTH is gnome political?? posterchild for kde's reputation as the desktop of choice for the socially inept.

High latency? - Tormak - 2005-12-10

I've just noticed that when I'm using amaroK with gstreamer I get a lot of skips when I'm playing music and doing normal things like switching desktops even if there is not much running in the other desktop (1 or 2 konsoles). I'm using the stock kubuntu kernel which is fully preemptible. Anyone know of anything else I can do to get rid of these skips or is it just gstreamer?

Re: High latency? - Martin - 2005-12-10

Try the Suse-kernel - they have some nice desktop-patches in it.

Re: High latency? - Dolio - 2005-12-10

Which audio engine are you using? In the past (0.8 and before), whenever I've used the alsasink output plugin, it's been terrible. It takes nearly 100% of the cpu time, and any other activity causes skips. In fact, I'm totally unable to play video acceptably with alsasink, because there aren't enough cpu resources left to decode the video fast enough (and this is on an Athlon64). If you can, try switching to osssink (which can still use alsa in actuality, since alsa emulates the oss interface). That's always solved cpu use/skipping issues with gstreamer for me. Maybe 0.10 has fixed the alsasink issues, though. It would certainly be nice.

Re: High latency? - Tormak - 2005-12-10

Yes I think I am using the alsasink. I'll try switch to the oss sink and see how it goes. Thanks for the tip!

Re: High latency? - Tormak - 2005-12-12

Switched to osssink but still have skipping problems (though not as bad as w/ alsasink).

Re: High latency? - Tormak - 2005-12-20

I just discovered an engine that doesn't skip at all. ARTS.

Re: High latency? - Matthias - 2006-02-04

On my setup (kubuntu with KDE 3.5.1) gstreamer+arts crashes amarok. gstreamer+alsa and gstreamer+oss suffer from extremely heavy skipping. The xine and the arts engines both cause amarok to crash. Not a happy situation. :-(

GStreamer == DRM - ac - 2005-12-10

They plan to add support for DRM... http://blogs.gnome.org/view/uraeus/2005/12/3/0 Please, keep KDE free from GStreamer.

Re: GStreamer == DRM - Charles de Miramon - 2005-12-10

It looks like Fluendo are adding DRM to their streaming server solution. Who can blame them to create a products that there paying customers might want. Looking at their website, it does not seem that Fluendo has (yet) a lot of paying customers. If they are not realistic, they will burn their investment money quickly. My problem with GStreamer is the same that was mentionned by other posters, I have never been able to have it play any sound on my desktop. Maybe the new version is changing this problem. Maybe I have not tried hard enough because xine and arts are good enough for me. But having something that work out of the box, with an easy interface for parametering, and that will not cause tons of frustrated emails on support mailing list should be a key point when deciding which multimedia platform we adopt as default.

Re: GStreamer == DRM - aac - 2005-12-13

So if you ask any paying customer: "do you want DRM support?" you think they'll answer "yes"? I think they'll ask you WTF you're talking about. So then you ask: "Do you want companies to decide what music you may listen, how you may listen to it, and where, thus limiting your freedom?" you think they'll answer "yes"? I think no one wants DRM, except the people that get rich from it. Which is around 0.0005% of the world's population. Don't think those 0.0005% knows what's best for us, and don't call them the paying customers. In the end, the consumers will have to pay.

Re: GStreamer == DRM - Bausi - 2005-12-11

For heaven's sake! If you don't have any technical clue, please STFU! They're planning to do some plugins which implement DRM for DRM-using media files (encrypted wmv crap). There will be no DRM in the core, there will still be all the "normal" plugins. No one is forcing any kind of DRM on you if you don't want it. That's why they are plugins!

Re: GStreamer == DRM - pinky - 2005-12-11

>They're planning to do some plugins which implement DRM for DRM-using media files (encrypted wmv crap). i think it depends on what kind of DRM is implemented. If it is just a "decrypting-function" to allow people with drm files to enter their password/key to play the file than i think it is ok, because it enable people to use theri files. But if it is a kind of DRM with forbid some kind of uses, i don't want to see it in any GNU/Linux application! For example i don't want a pdf reader wo tells me that i can't print the pdf-file and i don't want a mm-framework wo tells me that i can listen only 3 times to a media-file!

Re: GStreamer == DRM - ac - 2005-12-11

If a Linux (or a media framework, or whatever) supported some kind of DRM, companies will start using it. And we all know that companies' interests are not the same than users' interests. That's the problem, plain and simple. I don't blame GStreamer for supporting that -- their "corporate" backends (Nokia, Sun, ...) are throwing at them big money. I blame who wants to support GStreamer. Anyway, if after more than 6 years of development the GStreamer developers have not been able to make a stable (i.e. not crashing) release (or even match the functionality of Xine), I think the future is bright: GStreamer will hardly be a success. The incompetent GStreamer developers are our strongest allies.

Re: GStreamer == DRM - pinky - 2005-12-11

i hope you don't use kpdf, because it has also DRM functionality! Don't get me wrong. I'm absolutely with you and your argumentation. But i don't understand why people talk about it in context with a mm-framwork which will maybe be the default in the future and forget DRM which is actually in KDE (e.g. kpdf)!

Re: GStreamer == DRM - superstoned - 2005-12-11

this KPDF drm can be turned on an of at compile time, and i don't think many distributions will deliver it on. it is a feature, because some ppl wanted it - but you have to explicitly enable it.

Re: GStreamer == DRM - Reply - 2005-12-12

And that's the case with Gstreamer, you don't get DRM unless you specifically install the plugins, which are not even a part of gstreamer.

Re: GStreamer == DRM - Anonymous - 2005-12-12

That's not the problem. The problem is that now, "thanks" to GStreamer, Linux is a DRM-enabled platform. I have yet to see DRMs that actually benefit the user and not the companies. If Fluendo wants to put DRM in because their "sponsors" like Nokia and Sun want to do that, that's fine -- we'll have the proof that GStreamer is not a user-oriented project but a money-oriented project. And, while Gnome will have no choice but use GStreamer since Fluendo is on the advisory board (or whatever they call it), I think we can be smart enough to leave that crap out of KDE.

Re: GStreamer == DRM - superstoned - 2005-12-12

as long as the DRM doesn't restrict the user more than 'before' (eg it allows playing formats otherwise unavailable) it's no problem. but if the DRM restricts certain things other plugins allow (for example), its a bad thing. imho we should just wait and see...

Poor troll - Dan - 2005-12-12

Seriously, you're an idiot and/or a poor troll. You have just said: - kpdf is fine because "KPDF drm can be turned on an of at compile time" - but GStreamer is not, even though the DRM support is an optional plugin, and as a result "Linux is a DRM-enabled platform". Did you know that GCC could be used to write DRM software that might make Linux DRM-enabled platform? Oh no, best find another compiler. Seriously, do you blame every application author that provides plugin functionality for the plug-ins produced by third-parties? None of us like DRM, but your point is irrelevant. Nice try to find a problem where there is none.

Re: GStreamer == DRM - Shadowpillar - 2006-01-01

amen. To all those who are bitching and moaning about DRM, here's the funny bit, the linux kernel supports DRM and TCPM. I suppose we should rip that out of the kernel so we can all stick it to the man! YEAH, WE'D BE SO HARDCORE, BECAUSE OUR SYSTEM OF CHOICE CANT RUN ON THE "MAINSTREAM" SYSTEMS. WE'RE REBELS. Seriously, gimme a break, DRM has too much interest vested in it to be just cast aside, might as well have some support ready so when it does become the status quo, you can proudly say linux can run on a DRM platform or gstreamer can play those pesky drm'd wmv's. Stop being such fundies, you're worse than the religious nutcases. I dont like DRM, but it's inevitable, no matter how much power is vested against it, there are too many interests within the companies that MAKE the industry and all its standards. With the attitude of "ew, evil corporations made it! dont support it" linux will quickly fall behind. Funny how all the "good" corporations are the ones who give linux some recognition, despite how underhanded they could be (IBM anyone?) but in the end they see a cheap platform for their hardware to run on without any proprietary shit they have to pay for to develop drivers for. In the end, just stop bitching about DRM, it in itself isnt evil, what it can be used for can be evil, which is why having DRM support in OSS is good, since we can play the game against the assholes who would like to think that you should use something or watch something when THEY want you to.

Re: GStreamer == DRM - Nathanael Nerode - 2007-03-14

DRM simply does not work. If a movie can be watched it can be copied. Period. If a DRM decryption module is made open source, then any half-competent programmer can remove all the DRM restrictions and use the decrypter to transform the movie into an unencrypted format. If the module is not open source, it requires a highly competent programmer, but that's the only difference. Some of the ridiculously complicated crap being implemented in hardware will make this a slightly more complicated problem, but still trivial for the expert programmer to defeat. That's worth remembering.

Re: GStreamer == DRM - ch - 2005-12-12

if you dont have DRM files , your dont have DRM - if you have DRM file and a license , you would be glad to play it. !!!!

GStreamer with Slackware - NO no no no - fast_rizwaan - 2005-12-10

Never had a good luck to play with gstreamer, all applications which uses gstreamer 0.9 crashes like kaffeine, amarok, kmplayer. I wish you luck with GStreamer, perhaps it will replace arts with its cross-platform capabilities. I want any sound and/or video application to be able to play simultaneously without bothering with sound engine, ala alsa.

Re: GStreamer with Slackware - NO no no no - Mark Hannessen - 2005-12-11

well, alsa has actually done this quite nice. if your hardware supports hardware mixing you can play as many sounds as you like at a time even when playing songs with both oss and alsa api's. I had a soundblaster live in my previous pc, and that card supported it, I don't know about other cards. if your hardware doesn't support it you can still use software mixing by putting the following lines in /etc/asound.conf pcm.!output { type dmix ipc_key 1234 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 8192 rate 48000 } } pcm.!input { type dsnoop ipc_key 1234 slave { pcm "hw:0,0" period_time 0 period_size 1024 rate 48000 } } pcm.!duplex { type asym playback.pcm "output" capture.pcm "input" } pcm.!default { type plug slave.pcm "duplex" } pcm.!dsp0 { type plug slave.pcm "duplex" } ctl.!mixer0 { type hw card 0 } I found it somewhere on the internet and use it on my laptop that can't do hardware mixing. it works quite good for me..) this will allow any number of alsa sound streams to play at the same time. I wasn't able to play using both oss and alsa api's at the same time but at least it let's you play multiple alsa streams at the same time. most programs seem to support alsa nowadays so this becomes less and less of a problem.

Re: GStreamer with Slackware - NO no no no - ac - 2005-12-12

"Iwant any sound and/or video application to be able to play simultaneously without bothering with sound engine, ala alsa." Keep in mind that arts, gstreamer and others not only serve as sound server, but also as backend to play the different file formats for the applications you use. For instance, amaroK, kaffeine, noatun, juk can't play ogg-files, nor can Alsa. So you still need gstreamer, xine, arts or another backend that plays the file and sends the output to e.g. Alsa

Nope... - Zack - 2005-12-11

I hope that I can build my KDE 4 from the sources with the option to disable it. I wouldn't like to have DRM o gstreamer... Why we should aceppt that? Then, we can fork Gstreamer! - Would be such a nice ideia...

Re: Nope... - Christian - 2005-12-11

The DRM stuff will be done as an add-on package. So you (or your distribution) will make the choice of wether to install it. You can of course also de-install the DRM stuff also, but then you will not be able to playback DRM'ed audio and video files (unless there are some open source libraries which are able to crack them).

Re: Nope... - Zack - 2005-12-11

In that case, I hope that the distros makes the packages this way, usually, The distros makes separeted plug-in packages (E.g:Debian with gstreamer...), So I hope, that you're right and that they continue, besides, I hope that DRM doesn't become a dependence package for KDE Multimedia system. So we can continue with no freedom problems...

Re: Nope... - pinky - 2005-12-11

you are a kde-developer, right? So why you are against a DRM modul for gstreamer if KDE already using a pdf viewer with DRM integration? For me that makes no sense, gstreamer is (maybe) the feature but KDE has already today a "DRM problem". IMHO you (== the KDE and kpdf devs) should solve the present before complaining about a possible future.

Re: Nope... - Morty - 2005-12-11

You mean in KPdf like, Settings->Configure KPdf->General and uncheck Obey DRM limitations. You see, noting to be solved. Bad troll.

Re: Nope... - pinky - 2005-12-11

not everyone who hadn't known this option is a troll!

Re: Nope... - superstoned - 2005-12-11

no, but this comment doesn't have much to do with the topic (some are afraid gstreamer will limit its users and make things impossible. this is NOT the option in Kpdf - it has to be turned on on compile-time, and can then still be turned off in the config...

Re: Nope... - Dan - 2005-12-12

So essentially it's no different from choosing not to compile the Fluendo plug-in at compile-time? After all, for the majority of end-users, the decisions whether to include DRM support in KPdf, GStreamer etc. will be have already been made by the maintainers of their distribution of choice. People's irrational fear of gstreamer is about as sensible as being terrified that KPdf will prevent you from reading your PDFs in the future.

Re: Nope... - Morty - 2005-12-12

In this case you are totally wrong, since they work completely opposite. If you choose to not use the GStreamer DRM plug-in you will no longer have access to DRM enabled content. While you in KPdf you can turn it off and have unrestricted access to DRM enabled content. Rather a big difference.

Re: Nope... - Red - 2005-12-17

That's about DRM itself, nothing to do with GStreamer. "If you choose to not use the GStreamer DRM plug-in you will no longer have access to DRM enabled content"... and if you choose to use xine or any other engine that doesn't support DRM then you will no longer have access to DRM enabled content, and without even the option of installing a plug-in. Gstreamer DRM support simply gives you an extra option (freedom) that you have not with others.

Double Standards - The Grum - 2005-12-12

Disclaimer: Due to the high volume of "Gnome is evil" posts, I'll add that I use both KDE and Gnome and I have no real preference. Ok, you can get KPDF to ignore DRM limitations. That is great :) Why is this acceptable, yet GStreamer using an *optional* plug-in to allow playback of DRM'ed files unacceptable? I really dont see the problem here. If you are unlucky enough to have DRM'ed media, install the plug-in and enjoy. If not, you dont need the plug-in. DRM playback is needed if we want more people to jump ship from Windows. Joe Sixpack will want to play the songs he bought off iTunes, so we should have the option to do this. Note the word *option*. The moment DRM becomes part of gstreamer core, Ill stop using it.

Re: Double Standards - Sam Denison - 2006-01-25

If you're talking about getting people to jump ship from Windows, it's not going to be Joe Sixpack we get first, it would be wonderful if it was, but it's going to be the curious and disenchanted. Do you think that people will switch based on cost? When they've already had to pay for their OS with their machine. Will they switch because it's easier to use? Unlikely. Among other reasons, switchers - the disenchanted - probably aren't that interested in having the same kind of restrictions imposed upon them. When I first heard about this, and I appreciate that I'm a little behind here, I was hoping that this framework / plugin facility was going to be similar to the way that DeCSS is used, it can't easily be included with distributions but it can be distributed in an 'underground manner', so that we can still use our stupidly restricted content that we can't buy in another format. If I ripped a DVD to play on my Tapwave Zodiac, I don't care for it to still be restricted, thanks. Similarly, if I *had* to buy an album using iTunes or <WMAShop> the first thing I'd need to do would be remove the restrictions, anyone would want to given the choice. Supporting DRM in FOSS is removing that choice. I appreciate the Wine analogy, but no-one really believes that the existence of open source software is threatened because software makers don't port to it. Maybe Adobe Photoshop is a million times better than GIMP, but there's always GIMP. If the only way to listen to music is on restricted devices because even free systems support it, then... that's the end. Of course, there's no open source clones of pieces of art like music albums! The fears with DRM are that an incredible amount of our culture (media- images, audio, video, software I guess) will only be available in restricted ways. DRM won't go away if we support it. I'm fed up with people sending me WMA and WMV media, not because it's a pain to install the codecs for it, but because it's a bit wrong to use things like that if everyone can't partake. Presumably lots of people would like to just give up and install the binaries for the codecs, which is fair enough for them. Would it not be better to reserve some sort of inclination for ... Look, what I mean is, lets not pander to restrictions, lets have a framework instead called SWITCH (perhaps it can stand for something) that is illegal and uses every power we have available to convert documents, audio and video in any format into unencrypted, clean formats, hopefully lossless. Convert WMV to MPEG2 or even something un-patented. Lose some quality, but hey - web clips suck anyway. Shouldn't have used WMV in the first place. Clean out someones iTunes collection to FLAC so they can keep what they've paid for on their free system, or play it on their non-iPod. Remove the restrictions by whatever means, don't support them.

Re: Nope... - Aaron J. Seigo - 2005-12-11

> you are a kde-developer, right? i think you may be thinking of a different zack. =) as for drm in kpdf, we have resolved it: it's optional.

Already decided - Brandybuck - 2005-12-12

It sounds as if GStreamer has already been decided and approved for KDE 4.0. Is this true? Since it is dependent on Glib 2.0, is there any pressure on GNOME to keep the Glib ABI stable? p.s. The GStreamer page says that it is also dependent upon glibc. As a non-Linux user, I'm hoping that was a typo.

Re: Already decided - Morty - 2005-12-12

The plan is to make KDE4 independent of multimediaframework through KDEMM, making it possible to switch between aRts, NMM, GStreamer or whatever. As for glibc, it's the standard C libraries. It's rather hard to find any C code not depending on it. So my guess it's not a typo:-)

Re: Already decided - ac - 2005-12-13

he said glib and not glibc!

Re: Already decided - cm - 2005-12-13

Read again: "The GStreamer page says that it is also dependent upon glibc."

Re: Already decided - Brandybuck - 2005-12-13

"glibc" is GNU libc, and as far as I am aware, is only present in Linux (and Hurd) systems. Any code that uses glibc's non-standard extensions will be problematic on non-linux systems. Hence my concern. I am hoping this is a typo. If not, and GStreamer becomes a KDE dependency, then I will have to start hunting around for another desktop.

Re: Already decided - Morty - 2005-12-13

Then it will depend on whether or not GStreamer uses glibc's non-standard extensions. It's supposed to run on BSD, so perhaps not. Besides GStremer will not become a KDE dependency, read the part about KDEMM again:-)

Re: Already decided - Reply - 2005-12-15

Glibc is also used by GNU/kFreeBSD (the GNU system with the FreeBSD kernel). Gstreamer works with other C libraries, like FreeBSD.

DRM discussion - penny - 2005-12-13

by all this DRM discussion, some people have mentioned the kdpf drm implementation. Does someone knows a source were i can get a pdf with some DRM restrictions? I just would like to see the DRM options of kpdf in action. Maybe someone could even create a small test pdf with some drm? Thanks!

Xine is GPL, so all DRM _must_ be Open Source - vladc6*yahoo*com - 2005-12-13

Stick with Xine because it is GPL and all its plugins (including DRM-infested ones) would _have_ be open source. That means anybody can remove the DRM portion and be left with a fully-functional plugin. The same cannot be said about GStreamer, which is LGPL and whose DRM plugins will most likely be proprietary, closed-source, and controlled of the big media corporations. The only way to keep DRM's nasty claws off KDE is to ensure that users can change the code, and the only way to do that is to chose a tool that is GPL. Other GPL'ed alternatives include MPlayer and VLC, although I'm not sure how they compare to Xine. Could someone who has worked with these backends comment on whose architecture is best thought-out and whose code is cleanest/easiest to maintain?

Re: Xine is GPL, so all DRM _must_ be Open Source - superstoned - 2005-12-13

i agree on this GPL/LGPL point. i prefer the GPL over the LGPL, just because of this. glad Qt is GPL (or proprietary, but in that case the company has to pay so it benefits the FOSS community anyway)...

Re: Xine is GPL, so all DRM _must_ be Open Source - Rick - 2005-12-15

Nobody cares about you GPL fascists.

Re: Xine is GPL, so all DRM _must_ be Open Source - ac - 2005-12-15

It's not about GPL, it's about DRM. GPL is just a tool to circumvent DRM. Then again maybe you are a DRM fascist and this is exactly what you don't want.