Slashdot Mirror
The Full Story on GStreamer
JigSaw writes "Gnome's Christian Schaller has written an intro/status document on GStreamer, the next generation multimedia development framework for Unix. Christian explains what it is, why it is important, its use in both the desktop and server side, its use on embedded Linux, Gnome and even KDE. He also discusses its current competition and the plans for the future."
There was one snippet of news buried in the last page that I think is pretty big:
:)
"Another interesting development is that we currently got a team of about 7 french students who are going to make a GStreamer-based non-linear video editor as the final year project."
7 students running a final year project suggests it ought to be good, so does that mean we might finally have some really high quality video editing software other than Cinelerra? If so, that's brilliant!
I like the fact that GStreamer support is now filtering even into non-GNOME apps like Juk (in KDE). Good stuff
The BeOS had the Media Kit and it was great, allowed for cool stuff easily done on apps. Check Cortex for example: http://www.bebits.com/search?search=cortex and its surrounded plugins.
The "pipeline" he describes is somewhat similar to what you can do with VST plugins in Windows. E.G., you could hook up a microphone, then attach some distortion filters and eventually terminate the pipeline at some output device. All in all, this is a great article in my opinion. For the technically inclined, there are much more in-depth docs here, including all the gory API details.
Buy some computer games!
Video playback I could resize on the fly!
Call me lazy, but I hate putting in all those switches for mplayer.
Pretty Pictures!
I'm surprised that KDE users would use something that started w/ a "G" instead of a "K"....and vice versa ;-)
I mean, seriously, guys. How can you hope for any product recognition at all if it doesn't even have a name. GStreamer is not bad for Unix, after all they could have just called it "xyzzy" or "foo" or "ogg vorbis" or "xmms", but you gotta take product names seriously, otherwise the public will always perceive your products as pieces of shit hacked together in a haste. Which, to tell the truth, is what most of the stuff on freshmeat and sourceforge is.
KDE was cooked up in the same country that started both World Wars, embraced philosophies of destruction and hate (such as Nazism and Fascism), and spawned evil murderous maniacs such as Adolf Hitler.
By using KDE you are implicitly endorsing these hatemongering people and their genocidal dogmas.
A true patriot uses GNOME, written in the land of the free and the home of the brave. By using Gnome you are re-affirming your American ideals and supporting the open doctrine of truth, liberty, and justice for all.
So, the choice is yours: Do you use Gnome or are you a terrorist?
The article wasn't clear if Gstream addresses this problem, but one of the things I've been looking for is X-server based audio. I have a variety of types of systems and try to run or two desktops. Since Windows and Mac won't remote natively, they're the ones I'm currently stuck with, and my unix systems, being capable of it, are off in another room somewhere and I get to them using a local X-server or ssh. But that means no Unix multimedia, because no audio.
And here I believed the rabid zealots that told me in no uncertain terms that Linux was a viable multimedia platform... 3 years ago. 3 years ago Linux wouldn't detect most soundcards.
OT really, but you guys should think more before blathering it up in the trenches. Coming back with a zany "we have that, fucker" and pointing people to a page for a project maintained by a kid in Romania barely out of alpha that's been abandoned for 2 years as an alternative to a mature, stable commercial application is not my idea of "we have that". The computer is not just a browser, office suite and MP3 player.
-1 TROLL
One of my terminal windows looks this:
killall gst-thumbnail
killall gst-thumbnail
killall gst-thumbnail
killall gst-thumbnail
killall gst-thumbnail
KDE has a runaway process killer. Why doesnt gnome?
Speaking as someone who works for a large corporation (and one of the world's most profitable companies) I would say student code is substantially better than corporate code.
A correct use of the possessive pronoun a whopping three times! Congrats submitter!
X is noisy enough, let's not audio.
*shudder*
Besides X doesn't do remote all that well, it's too chatty. Use something like Timbuk Pro or VNC which are much more effecient.
I'm not a Kreskin, but none of those links is a link,
But where are the places where GStreamer innovates over the DirectShow APIs? The basic concept seems to be the same. DirectShow even has a filter graph editor which GStreamer's stream editor is eerily reminiscent of.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
This really has come a long way from when I checked it out a while back.
.doc decode filter and a grep, then to a .csv. All file conversion could be handled by the environment, rather than individual programs, which is messy and inconsistent.
It's a fantastic idea, although it's been around for a while. But being able to apply different filters to an audio stream is really cool. It's unix pipes for audio.
What would be great is if gnome standardized a bunch of filters like this for everything. Imagine being able to apply a tar and then a gzip filter in this manner. Or perhaps a
Gstreamer is a big step in the right direction. Way to go guys.
If moderation could change anything, it would be illegal.
I wonder what will happen when MPlayerG2 comes out from an incubator. Will the two projects simply compete, or will they work out some way to integrate/support each other?
Before everyone jumps all over me and thinks I'm being facetious, I don't mean applying tar and gzip via the command line, but rather with a GUI interface, as in the article. :-)
If moderation could change anything, it would be illegal.
Your joke is out of date, these days SCO owns the copyright
You think mom and pop, or even corperate customers for that matter, know or care what DCOM, DDC, or OLE stand for or mean? Guess that means that Windows will never be taken seriously...
Frameworks are only used by developers, they can call them whatever the heck they want.
In fact, there is little out there to compete with GStreamer, at least on Linux. The nearest equivalent would be DirectShow on Windows which has nowhere as nice an architecture.
You're probably thinking that GStreamer duplicates Xine and MPlayer (though mplayer isn't really a library). To a certain extent it does - they all allow you to play back files, however GStreamer allows you to do a whole lot more.
Having said that, at the moment XineLib is more robust than GStreamer is, but the competition actually is spurring them forwards.
Substitute audio for video when necessary.
Different developers, same itch, same not-built-here syndrome, same wheel.
In addition, Gstreamer doesn't work for most people I know, and nobody is working towards a fix. Just look at all the untouched Gstreamer bugs in Gnome's bugzilla.
The install instructions for RedHat (using apt-get) are wrong and have been broken for well over a year (there is no gstreamer-universe), if you install the RPMs gstreamer won't work because it was built WITHOUT the Hermes library which is REQUIRED and the Hermes library wasn't included with the RPMs!
The source doesn't compile for many people.
And the developers, instead of fixing these problems, have now moved on to the 0.7 branch.
We will never have a working version of Gstreamer.
This is not a new library, you know... And it's got the attention of the gnome and kde developpers.
Although the main integration isn't planned until 4.0, the upcoming 3.2 will support gstreamer in JuK, the new music player for KDE. It will replace the slow and buggy noatun. Ive tried it, and its really quite good. Its one of the reasons why KDE 3.2 will rock.
Thats good mods.
Slap him down, even though he's right.
Beatiful Swedish supermodel would like to date Slashdot regulars. Must be +4: Interesting and +5: Funny, please no weirdos and Mac zealots.
You don't know what you're talking about. GLib and GObject don't even depend on X, let alone a widget toolkit. GTK is built upon these libraries, but to say GStreamer depends on a widget toolkit is flat out wrong.
Gstreamer needs glib to run. So what? :)
Innovation for innovation's sake is a waste of time.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
She is right. The BeOS' Media Kit was not free software.
flaming skull heads
you must check out LADSPA they're beautiful
so beautiful
I die
All the coding effort and mindshare is going into the short-term solution of basic media players instead of the framework. And since the players are ahead, they get more volunteer help, so they get farther ahead... and the framework never gets done.
GStreamer does not depend on GTK. The only dependence is on glib. I've yet to see anyone make any rational argument against a glib dependency in KDE. glib is just an extension to the C library, and no more a GNOME technology than libxml or libpng.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Your post is just trolling. You seem to have miss a lot of episodes and forget a lot of times where Eugenia took KDE's side (like in the UserLinux debate).
FYI, Eugenia does not use BeOS (or Zeta) at all anymore. She (says) mostly uses Mac OS X or XP and sometimes Slackware and FreeBSD.
As in pd.
OK, I'm a bit overstating, and installing gtk+ on a system is not generally very such a big pb.
However, when exactly have you installed glib without the full gtk+ ? Sorry, but glib, gobject, gdk and gtk ARE a common package (and developed as is : same developers, same version numbers, same CVS) in most if not all distros.
Ergo, a dependency on glib is, for now and practically speaking, a dependency on GTK+. Thus, on a widget toolkit.
GTK+ is not built on glib and gobject : they belong to GTK+.
The problem isnt core glib (which arts and some koffice filters already uses), but the extention gobject.
GObject contains the "GNOME" event-loop and object system, and is what makes integrating GNOME and KDE applications hard.
For KDE to use GStreamer, we would need to have two event-systems and two object-systems and a patch to translate between them. Or in other words an invitation to crap.
Don't be silly, glib isn't a widget library. It has nothing to do with widgets or grahpics. It's a powerful library that facilitates easy portability and convenience in C.
*sighs*
I used to work as an open-source developer with the helix engine (still do, in fact), and didn't find the licensing to be that much of a turn-off. It's kinda like the NPL, or the GPL with the special rights for the Licensor outlined in section 3.
You can read the Helix license mentioned in the article here: RPSL
Check out Helix Player
glib does not depend on anything but standard C (glibc).
Copy & Paste gives you this:
GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality as
an event loop, threads, dynamic loading, and an object system.
still reading?
..read the headline quickly and saw "G-Stringer?"
Drill baby drill - on Mars
Isn't this similar to JACK? From what I gather, GStreamer extends it to video, also.
Even that piece of shit known as Adobe Premiere -- which Cinelerra trys and fails to immitate -- is lightyears ahead. If you want to get into the billions of lightyears ahead, then compare to FinalCutPro or Vegas Video (which was recently bought from SoundForge by Sony Pictures).
Linux has a loooooooooooooooong way to come in this department, and that's no troll.
Libxml2 can and is installed without gnome.
Glib isn't. Glib is part of GTK+.
Would you say the same with pango ?
Ergo, a dependency on glib is, for now and practically speaking, a dependency on GTK+. Thus, on a widget toolkit.
That is like saying that libc first came with UNIX, and thus using any of the standard C libraries is thus a dependence on UNIX. Thus on a operating system.
GTK+ is not built on glib and gobject : they belong to GTK+.
You can assert whatever you want. That doesn't make it true. glib is a seperate library and doesn't hurt gstreamer in the least to use it.
No you get glib seperately.2 .2.3.tar.bz2
ftp://ftp.gtk.org/pub/gtk/v2.2/glib-
It depends on glibc.
Then what else is a computer, to Joe Average Windows User?
And who in the hell was saying that "Linux is a viable multimedia platform" three years ago?
--grendel drago
Laws do not persuade just because they threaten. --Seneca
Just as glib only depends on glibc (on linux).
Pango only depends on
glib
And one of the four backends
Native Windows.
Core X windowing system.
Client side Xft library.
Direct rendering using the freetype library.
So it doesnt even depend on X.
Yeah. Lets all have this be like direct show on windows - its so flexible yet theres not a single app you can take friggin screen shots with.
xine for me thanks.
glib, gobject, gdk and gtk ARE a common package ... in most if not all distros
/usr/lib/libglib-2.0.so.0 /lib/tls/libc.so.6 (0x002f1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x004c8000)
/usr/lib/libgmcop.so.1.0.0 /usr/lib/libmcop.so.1 (0x009e9000) /usr/lib/libgobject-2.0.so.0 (0x0015b000) /usr/lib/libgmodule-2.0.so.0 (0x00111000) /lib/libdl.so.2 (0x00425000) /usr/lib/libgthread-2.0.so.0 (0x00c68000) /usr/lib/libglib-2.0.so.0 (0x00224000) /usr/lib/libstdc++.so.5 (0x0082d000) /lib/tls/libm.so.6 (0x002f2000) /lib/tls/libc.so.6 (0x0044a000) /lib/libgcc_s.so.1 (0x00fb0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00c2d000) /lib/tls/libpthread.so.0 (0x00ef0000)
Which? I've never used one. At least Debian, SuSE and Red Hat/Fedora package them separately, and those are the major dists.
GTK+ is not built on glib and gobject : they belong to GTK+.
You're just wrong there. Many projects use glib and its gobject, and have no runtime dependency on gtk+. I, myself, have developed projects in C using glib on systems that do not have gtk+ installed.
Observe that glib is not linked to gtk+ on a Fedora system:
[gordon@wanderlust:~]$ ldd
libc.so.6 =>
Further, observe that KDE's "arts" includes libgmcop which uses glib and not gtk+:
[gordon@wanderlust:~]$ ldd
libmcop.so.1 =>
libgobject-2.0.so.0 =>
libgmodule-2.0.so.0 =>
libdl.so.2 =>
libgthread-2.0.so.0 =>
libglib-2.0.so.0 =>
libstdc++.so.5 =>
libm.so.6 =>
libc.so.6 =>
libgcc_s.so.1 =>
libpthread.so.0 =>
I have glib but not GTK installed in my system right now. apt-get install libglib-2.0 does it just fine. glib and gtk are separate packages (regardless of their developers), and I have yet to run across a distro that combines them.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
You don't know what you're talking about here. It's time to give up.
My only political goal is to see to it that no political party achieves its goals.
Sorry but GStreamer is far from being usable on either GNOME or KDE. While the idea of it is a nice one the development process on the otherhand is lagging behind.
GStreamer exists for over 4 years now and it still doesn't have a stable API nor is it working properly in GNOME. Not to say that it's just half implemented. Things like Sound-Juicer do not work seriously, Rhythmbox tendency to crash every now and then, Totem still prefers libXine, the new mixer which recently made its way into gnome-media still doesn't work even when using GStreamer as backend.
While Gstreamer is configured to run alsa9 sink and do work whenever it wants, the shitty mixer tool has problems accessing the mixer since it only uses the OSS backend of the Alsa sink.
Well GStreamer needs another 4 years to be usable. It's to early to talk about it.
I don't know, I've renounced all techmology...
Rainbow Jeremy
btw, Can anybody comment on wether Gstreamer uses the glib event loop, or does it just use G_object?
Your friendly OSNEWS summary service.
-- Bryan
OK, I'm going to take advantage of your post to inquire about this stuff. My question is only sorta on-topic for this story, but it is inspired by it (and by this sub-thread).
I'm a Linux audio user, not a programmer. I use JACK primarily because JACK is required to use Rosegarden4 (MIDI sequencer), which I use with my soundcard's onboard synth as a composition tool, to play with tunes before trying them out with the band I'm in. And I understand that it's necessary to use Ardour effectively, which I'd like to do when I can afford a soundcard that makes it worthwhile, like the RME Hammerfall or whatever.
But I don't really know what I'm doing with JACK -- when I run it, it's by typing in a command that I know works, but which I don't really understand -- and your response here highlighted for me some of my confusion. So here I go.
1. What the hell is a signal graph (re: your response above)? Of what I've read about JACK, that's the first time I've seen that expression? Or by "signal graph" do you simply mean "a graphical environment for stringing together a sequence of signal processing modules into an overall application"?
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
3. What do you mean by "with Gstreamer the whole graph is in-process"? Are you saying that you use the graphical signal path editor to create an application out of modules, but when you're done it links (in the post-compilation sense) the modules together into a single executable which has the capability described by the network? Because otherwise -- if the modules do their work independently and pass data between each other -- that sounds like processes talking to processes, just like with JACK. What am I missing?
4. My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
I guess another "point" to JACK is to provide a common interface . . .that way, applications and modules don't have to know how to talk to all the possible other apps/modules out there someone might wanna combine them with; rather, they just all have to know how to talk to jackd. And that makes sense, and sounds like it'd be a good thing, for inter-process communication. But why is that a good thing for output? Isn't the whole point (or, a whole point, anyway) of having sound drivers to have a unifirm output interface? How does outputting to jackd to output to the ALSA driver any better than just outputting directly to the ALSA driver?
Well, that's enough to start with. If you (or anyone else) can provide insight, much thanks. I've read online docs about JACK and ALSA, and the Gstreamer summary linked to in this article, but am obviously still quite confused.
how much before someone comes up with something akin to VST instruments? would it belong here? I do think so...
VST 2.0 instruments ROCK (pun not intended)
13-4=54/6
You are wasting your time trying to explain the concept of dependency trees to KDE fanatics. Have you seen KDE code... libraries are such as pain in the ass to C++ frameworks that KDE has just shoveled everything in to a couple of monster packages and everything depends on everything else (and esp. on Qt, even when not needed)... it's a fucking nightmare.
Good design and basic software engineering are two things the KDE project lacks in great quantities.
I am JACK's primary author. I hope I can explain some of the basics to you.
1. What the hell is a signal graph (re: your response above)? Of what I've read about JACK, that's the first time I've seen that expression? Or by "signal graph" do you simply mean "a graphical environment for stringing together a sequence of signal processing modules into an overall application"?
When audio programmers talk about a signal graph, they are using the term to refer to a rather abstract conceptualization of what is happening in software (sometimes in hardware). The model is of a series of "nodes" each of which processes a signal in some way. Each node is connected to one or more other nodes, for input and/or output. You can build a very simple graph, such as some kind of node that reads from a disk file and sends output to another node that delivers it to an audio interface. Or you can build incredibly complex graphs in which the signal is routed all over the place, possibly even including through feedback loops.
JACK is merely one of many systems that use the model of a signal graph internally; GStreamer is another.
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
Gstreamer is really a toolbox to be used by a SINGLE program to construct processing pathways (aka "signal graphs"). It offers no facilities (other than connections to JACK) that allow MULTIPLE processes to route data among themselves.
As to what a JACK client does with the data it receives - that is entirely up to the client. We have some clients that stream to an icecast server, other people are working on UDP and RTP-based networking, others write data to disk etc. But JACK knows nothing about this, its entirely internally to each JACK client.
3. What do you mean by "with Gstreamer the whole graph is in-process"? Are you saying that you use the graphical signal path editor to create an application out of modules, but when you're done it links (in the post-compilation sense) the modules together into a single executable which has the capability described by the network? Because otherwise -- if the modules do their work independently and pass data between each other -- that sounds like processes talking to processes, just like with JACK. What am I missing?
As I mentioned above, Gstreamer is used by a SINGLE application to build processing pathways. It is of no use whatsoever in building multiprocess pathways, other than its connection to JACK.
4. My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
For a situation involving only one process (such as rosegarden), its certainly possible for direct access to provide marginally lower latencies than with JACK. But when I say "marginal", I really mean it. On a modern CPU, and with the right kernel, you can basically JACK as low as your audio interface can handle. The reason that JACK's design matters for latency is 2-fold. First of all, it imposes the correct model of int
"GStreamer is that of a pipeline system which your media streams through"
;)?
Linux programs are filters in pipelines with data streaming through them. GStreamer is a special case for media. "Programming" GStreamer is executed through a pipeline viewer, a flowchart for GStreamer components. How about a general purpose flowchart programing tool for Linux?
Perl, for example, is internally compiled into a graph of primitives. How about a program that parses Perl into graphs, enforces Perl graph grammar in a GUI, and reconstitutes Perl code for saving? The three tier form has Perl code for data, Perl graphs in the "business", and flowcharts as presentation. Is there such a thing? For Python? Ruby (hint
--
make install -not war
aRts was supposed to be a sound server for KDE. GStreamer is far from that, it's a multimedia framework - that's one level higher. aRts failed to be a proper sound server, precisely because it was designed to be - guess what: a realtime softsynth. JACK, on the other hand, IS a soundserver.
Just a few things to add to Paul's post.
.so that the JACK server would load at runtime. I don't know if this ever materialized. These would make JACK resemble Gstreamer a bit more.
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
I think your confusion here is that you are confusing drivers with clients. A driver is an integral part of the JACK server that is responsible for providing a time source (so that the whole JACK system can run exactly in sync with a sound card). It can also provide ports like a client, but unlike a client it runs in-process, as part of the JACK server. There can only be one driver per JACK server process. Clients, on the other hand, are separate processes that talk to the JACK server using pipes and shared memory, and there can be many of them.
There was talk at one point of making it possible to create in-process clients. They would exist as an
3. What do you mean by "with Gstreamer the whole graph is in-process"?
Imagine you are drawing a picture of sources and sinks and connections between them. With Gstreamer that whole picture, the whole network of data all lives inside one single application (one process). With JACK, each node of the network is a separate process, except the driver.
My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
If the only goal was low-latency for a single application talking to a sound card, then indeed JACK would not be necessary. But an even more fundamental goal of JACK is that applications be able to work together. JACK aims to provide the lowest possible latency, while also providing sample-accurate synchronization, for this inter-application communication.
Yes, it is exciting to hear that people would start working on a non-linear video editor.
I don't expect their student project to be anything useable, but if they get excited about it and continue work for a few years after their studies, who knows? Maybe a competition to Avid and Final Cut Pro could emerge?
Of course, this has only a chance if they complement their programmer team with a few professional editors and have a very serious look at the 2 current NLEs (and at Pro Tools, the sound editor).
As far as I am aware OpenBeOS & Syllable both have media toolkits which are comparable in design to GStreamer. The fact that GStreamer is still considered "Next Generation" in Linux multimedia simply reflects the sad state of affairs of multimedia on Linux currently.
The last step is the important one.
It's called mplayer. Extremely fast, extremely light and unbloated, and Just Works(tm). No need to download DivX/QuickTime/whatever codecs - it Just Works(tm). Even WMP can't compare to that.
Fast forward? Press the Right arrow key, or the Up arrow key.
Full screen? Press F.
Pause? Press space (just like in WMP 6.4) or P.
All very simple, all very, very intuitive. Unlike WMP, where you have to get out of full screen, move your hands from the keyboard to the mouse, and then try to point a menu item to do anything.
Mplayer is far better and easier to use than WMP. I even made it my prefferred media player on Win32.
Paul, I would like to use this thread to ask your opinion on a subject : would you think jack is suitable for processing video ?
I know, they are two completely different subjects, but as I think Ardour does video, how hard/useful would you think extending LADSPA / Jack to video could be ?
So, basically... Gstreamer + Jack elements = World Domination(TM)?
What about MAS the Media Application Server for X, which is on track to be a standard part of X?
OH MY GOD!
They suspended goatse.cx!!!
Run for your tinfoil hats, the world is coming to an end..!
Sorry, wrong.
MAS makes JACK irrelevant.
MAS is the official X11 sound server and it supports network transparency. JACK has slightly better latency but the vast majority of users don't require that. JACK's huge down fall are two fold; no network support, no major partner affiliation.
Don't underestimate the power of being an X11R6 standard. MAS will be on every Linux distro (and possibly other UNIX's?) within a year. It'll be good riddance to esound and aRts!
Yes.
MAS is the offical X11 sound server. It is network transparent and it should be multi platform. Cool stuff.
tried mplayer. it had skinning. so i uninstalled it.
It would be fairly easy to extend Jack to work on video. It would just require someone writing a new data type.
I don't know what the basic data type of video work is. In audio, it's unsigned long numbers. LADSPA works on those. If someone changed it to work on whatever video uses, then LADSPA could be used too. Someone would have to get the video editors to support Jack and LADSPA though.
Ardour doesn't support video yet. It does has a feature to support animatics, which is almost video, but not what you're thinking of.
Then don't enable the GUI. It's that simple.
All that's left is a window with *only* the video in it, without annoying controls -- simple, intuitive, to-the-point.
The following may b true - we
thought of developing an algorithm stronger
than the today's encryption algorithm in the
final year and ended with
more paper work as needed for the prj
submission and an algorithm almost very
easy to be decrypted by 2 systems(that was not
bad, but our aim was to come up with one
that cant be entered into by using atleast
10 computers). Reason - we had less time besides
our exam and other college fun schedules.
Hope these French students come up their
obstacles and give us the ripe fruit of success !
all the best students !!
I wouldn't get too excited about final-year student projects.
They are usually evaluated according to their adherence to software development methodologies, rather than the actual quality of the end product. To that end, students spend more time making the paperwork good rather than the code good. Whilst this is a necessary part of building really big projects, it's not an optimal method of building small projects by inexperienced part-timers who often have only a very partial understanding of the problem domain.
regards,
karthik bala guru