Domain: gstreamer.net
Stories and comments across the archive that link to gstreamer.net.
Comments · 55
-
Re:QuickTime as well
How about Gstreamer? I believe Slashdot has reported on this a few times already.
-
Re:KDE: one of the most successful OSS projects
KDE comes with so many other good programs as well, like KNode (News reader) and KMail (lightweight email program)... Does GNOME have any comparable programs?
Errr... yes! Pan is probably the best free newsreader for any platform, Evolution is an incredibly well-integrated mail, calender and addressbook program, and Balsa is a very decent more lightweight mail reader. For office programs, Gnumeric is way more advanced than KSpread, Guppi (still in CVS) is one of the only serious free graphical data analysis tools, GnuCash is very polished, and Dia rocks. Graphically, Sodipodi is shaping up very nicely, gPhoto rules, and the GIMP integrates better with a GNOME environment than with KDE. And then there's XMMS (the best mp3/ogg/mpeg/divx Linux player), Grip (the best CD player/ripper combo) and GStreamer for multemedia; there's GnomeICU, Gabber, Gaim and X-Chat for messaging; there's Gnapster for file-sharing; and there's more useful utilities (e.g. Bug Buddy), system utilities (e.g. Red Carpet), and panel applets than you could shake a stick at. And I know I've missed out quite a few more (Gnome-DB, Oregano and Dr. Genius have just spring to mind - and, yes, Galeon, which rocks and is now my primary browser). In other words, GNOME is hardly short on applications.
If anything, I've often found it to be the other way round. While Konqueror rules, and KWord is much better featured than AbiWord (though I personally dislike the interface), I think where KDE usually excels is in the underlying desktop core, rather than the applications. But that's just my opinion.
PS Sorry for ranting. -
My current project
1) Buying up as many ATI All-In-Wonder Pros PCI's that I can.
2) Drop as 'em into a box and try and get XFree86 4 to span over all the outputs.
3) Modify xawtv (if needed) so that so you can see the inputs from a diffrent card in each session of xawtv.
4) Get TV-out working. Plug each card into a TV (I have a bunch I've been collecting for this).
Presto! Videowall!
Next we need a mpeg2 encoder board to record stuff. And more PCI slots
:)I'd want to watch CNN, MTV, ZDNET, SCI-FI, and the Comedy channel all the time.
:)Idealy I'd write my own software for viewing using gstreamer, but we'll see...
-- -
GStreamer and distributed processing
GStreamer is a project I and another person are currently working on pretty much full time (I'm between jobs and he's on vacation) at the moment. It's been around for a bit over a year, and has grown considerably since in that time. It's a pipeline-based architecture somewhat similar to M$'s DirectShow, allowing arbitrary graphs of plugin filters, processing just about any kind of streamable media you can think of.
This lends itself quite a bit to distributed processing, since you simply (for now) code up an element pair that will enable you to join two pipelines over the network, via TCP or somesuch. Eventually we plan to have CORBA interfaces wrapped around everything, which while slowing down data tranfers, has the potential to make everything even easier.
A release is planned for the beginning of next year (midnight, Jan 1st, Millennium Release), which should provide people with a stable enough API to start writing apps with it. There are still going to be some major changes like a shift to GObject (currently uses GtkObject, so it's tied to X, bleagh), and some major feature enhancements like the graphical pipeline editor. Changes to the system should affect plugin writers mostly, as the "user-level" API should remain basically the same.
The two of us are interested in audio and video respectively. I want to build a live mixing system, he wants to build an NLE. The two have much overlap even ignoring the GStreamer core, so things should get interesting. There are some other people with some pretty cool ideas that we'll try to incorporate, one of which is distributed processing.
Anyone interested in this project should head over to http://www.gstreamer.net/ and sign onto the mailing list (gstreamer-devel). We'll be busy coding through the end of the year, but we welcome anyone who would like to use the system. The scheduling system is currently being re-written for the 4th or 5th (and hopefully last) time, so anyone with specific use cases can help the process along by enumerating them to make sure the scheduler can deal with even the most bizarre cases.
As far as VST and other plugins, there's a project called LADSPA that's building a plugin interface similar to VST. Quite a few plugins are already available, including FreeVerb. The problem with VST is that it embeds the Windows-based GUI into the plugin. This might be shimmed with libwine or something, but is a tough problem. If someone would liket o tackle that, please, step right up, we'll help you as much as we possibly can.
-
GStreamer and distributed processing
GStreamer is a project I and another person are currently working on pretty much full time (I'm between jobs and he's on vacation) at the moment. It's been around for a bit over a year, and has grown considerably since in that time. It's a pipeline-based architecture somewhat similar to M$'s DirectShow, allowing arbitrary graphs of plugin filters, processing just about any kind of streamable media you can think of.
This lends itself quite a bit to distributed processing, since you simply (for now) code up an element pair that will enable you to join two pipelines over the network, via TCP or somesuch. Eventually we plan to have CORBA interfaces wrapped around everything, which while slowing down data tranfers, has the potential to make everything even easier.
A release is planned for the beginning of next year (midnight, Jan 1st, Millennium Release), which should provide people with a stable enough API to start writing apps with it. There are still going to be some major changes like a shift to GObject (currently uses GtkObject, so it's tied to X, bleagh), and some major feature enhancements like the graphical pipeline editor. Changes to the system should affect plugin writers mostly, as the "user-level" API should remain basically the same.
The two of us are interested in audio and video respectively. I want to build a live mixing system, he wants to build an NLE. The two have much overlap even ignoring the GStreamer core, so things should get interesting. There are some other people with some pretty cool ideas that we'll try to incorporate, one of which is distributed processing.
Anyone interested in this project should head over to http://www.gstreamer.net/ and sign onto the mailing list (gstreamer-devel). We'll be busy coding through the end of the year, but we welcome anyone who would like to use the system. The scheduling system is currently being re-written for the 4th or 5th (and hopefully last) time, so anyone with specific use cases can help the process along by enumerating them to make sure the scheduler can deal with even the most bizarre cases.
As far as VST and other plugins, there's a project called LADSPA that's building a plugin interface similar to VST. Quite a few plugins are already available, including FreeVerb. The problem with VST is that it embeds the Windows-based GUI into the plugin. This might be shimmed with libwine or something, but is a tough problem. If someone would liket o tackle that, please, step right up, we'll help you as much as we possibly can.