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 agree. Please keep glib out of KDE! Glib is EVIL!
This could be a clever way to konvert some of those evil gnomesters to see the light.
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.
pray tell, how on EARTH is gnome political??
posterchild for kde's reputation as the desktop of choice for the socially inept.
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?
Try the Suse-kernel - they have some nice desktop-patches in it.
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.
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!
Switched to osssink but still have skipping problems (though not as bad as w/ alsasink).
I just discovered an engine that doesn't skip at all. ARTS.
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. :-(
They plan to add support for DRM...
http://blogs.gnome.org/view/uraeus/2005/12/3/0
Please, keep KDE free from GStreamer.
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.
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.
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!
>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!
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.
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)!
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.
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.
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.
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...
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.
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.
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.
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. !!!!
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.
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.
"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
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...
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).
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...
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.
You mean in KPdf like, Settings->Configure KPdf->General and uncheck Obey DRM limitations. You see, noting to be solved. Bad troll.
not everyone who hadn't known this option is a troll!
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...
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.
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.
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.
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.
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 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.
> 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.
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.
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:-)
he said glib and not glibc!
Read again: "The GStreamer page says that it is also dependent upon glibc."
"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.
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:-)
Glibc is also used by GNU/kFreeBSD (the GNU system with the FreeBSD kernel).
Gstreamer works with other C libraries, like FreeBSD.
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!