aRts/KDE Video Roadmap Meeting

All aRts and KDE developers (or would-be developers) are invited to an IRC meeting in order to draft a short- and long-term roadmap for the future of video in aRts and KDE. Why? aRts is a solid base, and it would be a shame not to build a good video system on top of that, taking the best from the already existing video projects.

When: Saturday, January 26, 2002
21:00 GMT / 22:00 CET / 13:00 PST / 16:00 EST

Where: #kde-multimedia on

How:kSirc in kdenetwork
(or KVirc if you insist)

Dot Categories: 


by Andrea Albarelli (not verified)

> - the support of encoding (think of video conferencing, video mails, video editing, tv recording)

mplayer can encode DivX using two different encoders and will sonn be able to
encode many other formats.
I use it every day to encode avi files from DVDs faster and with more control than FlaskMPEG

> - the support for decoding without realtime (video editing, re-encoding)

mplayer can decode any movie to png sequences or mpeg-PES with high quality and in batch processing

> - the support for push mechanisms (when you have data in a file or get it from a TCP connection pulling is ok; if a codec is embedded in a multiplexer or gets data from UDP/RTP/Multicasts/whatever the situation is very different)

I never tried, but the documentation say that mplayer can play from network streams ( i think only tcp ).

> - the support for filters

Do you mean output filters ?

by Tim Jansen (not verified)

>> - the support for filters
>> Do you mean output filters ?

No, putting a filter between two modules. For example you might want to increase the brightness of a video, so you connect a decoder-module to a brightness-filter and then the brightness-filter to an encoder-module. Filter's can be used for other things as well, like adding effects in a video editor or to detect motion in a video conferencing app. MPlayer doesn't have this kind of flexibility, there is no video pipeline that you can alter or even a common interface for codecs.

by Neil Stevens (not verified)

Good comments.

To address your three items:

1) Yes, one of the goals of the meeting is to make sure that KDE gets what is needed, preferably through aRts.

2) I consider Noatun a music player. I wrote Kaboodle (included in KDE 3 kdemultimedia) to be the single-shot generic media player you're reaching for. Converting an existing monolith to a Playobject would get us absolutely nowhere - it'll just be another mpeglib, as you seem to realize.

3) If mpeglib gets something, we'll take it, but we don't intend to wait around. There are projects out there that do a lot more than mpeglib does, and I think it'd be nice if the mm systems in KDE could be improved to be able to take advantage of them.

I have no interest in GStreamer. From what I've seen, it's just like aRts, only written in C, and with different levels of maturity for different parts. The key difference between the two is that aRts has had a lot more testing in a mass install userbase, so I'm more likely to trust aRts.

by Neil Stevens (not verified)

Unless it's possible to use GSTreamer without the glib event loop, I don't see how it can be possible at all to use GStreamer with KDE apps, as KDE apps already use the QApplication event loop.

by Phil Ozen (not verified)

Thanks Neil for your clarification.

I understand better the problems of integrating Gstreamer. I also agree with you concerning Gstreamer immaturity. There's a big gap between the existing plugins (over 100 claimed) and the usable ones.

Two other important comments:

a) When you look at aRts web site, it doesn't reflect that aRts is now a multimedia framework. Since it's the first place where potential developpers will go, this might mislead or discourage them. It might be the good time (...KDE3) to refresh the web site & find a dedicated Webmaster. This will also free Stefan Westerfeld. It's obviously better he codes aRts instead.

b) In the same way, the aRts documentation seems unclear to many & needs to be upgraded. I regularly read the KDE multimedia mailing lists and many times newcomers complain of the difficulty to understand aRts due to the lack of proper documentation. In fact, only Stefan Westerfeld has the knowledge. It would be good if this knowledge is made more accessible to others.

I remember that Eugene Kuznetsov (the author of AviFile )was wanting to join in December 2000 but he stopped after saying the following in the mailing list.

"I am new to this list. I've got a question about perspectives of your
architecture. Do you have any plans to implement streaming video in
aRts, making something that would not heavily depend on mpeglib? It
would make aRts more flexible and allow other developers to write
their own components."

"Code that does all actual work on parsing, decoding and drawing anything
is safely hidden beyond undocumented and obscure interfaces of mpeglib.
What's worse, it is unusable for anybody who does not want to completely
integrate into it."
"I know that I don't need mpeglib to implement Arts::PlayObject (already
done it in my project), but I don't like the idea of having two
incompatible video & audio renderers, audio/video syncers, etc.
For sure this would require much work, you'll need to define all
necessary interfaces, apply heavy changes to mpeglib, but I think that
it's worth it."

His remarks are pertinent but this is long time ago. Today, it's important to make aRts more easily interfacable with others projects (such as AviFile). This might need proper documentation & aRts internal changes.

I hope not to look presomptuous with my comments since I do nothing on the project. I only want to help with ideas that might interest you. Thanks again Neil for the job done.

by Neil Stevens (not verified)

Yes, aRts is undocumented. Stefan lacks time for that stuff. That's why arts-project *and* the docs are so behind.

The biggest problem I see getting a video framework going, will be getting people who know video to brave the challenge of working within aRts. I've already had one person tell me he's unlikely to help because aRts is such an undocumented web.

by Phil Ozen (not verified)

Yes, I agree, it's a big blocking point. To grow, a project needs new blood.

Obviously, the same kind of web site as "" wil attract a lot of newcomers. It's really well designed. As told previously, an "aRts-project" webmaster is top priority.

I hope to read a summary of the saturday IRC on "the dot" or next "Kernel cousin KDE".

Thanks Neil

by Christian Schug... (not verified)

I use the ac97-Soundchip and I switched off the artsd to enjoy the lokigames-sound and use xmms.
ANd artsd isn't that good when the cpu-usage is high.

But xmms blocks all system notifications and i get them all afterwards :-/
So I'm quite jallous (4 sound-reasons), when I see my brother with win me gaming.
The artsd was the only way to play several files simultaniously.

But I'm not always using KDE, perhaps it's more a thing for the alsa-project.

I just hate it, when my Mozilla hangs, until I stop xmms.

I'll try kde 3 soon.



try to use the artsd plugin for xmms. Maybe that solves the problem you have...


by Tim Jansen (not verified)

I nice solution to problems like this is to use a SoundBlaster Live with ALSA. The SBLive driver allows 32 processes to access the /dev/dsp file simultanously, so you don't have to suspend the sound server or use artsdsp.

by Christian (not verified)

I only have a via ac97-chip on my Asus a7v 133WA or a SB 128Pci :-/

I still wonder why noatun hasn't the nice features like kmp3.

That was so comfortable when you had to rename files or make an id3-tag.

Perhaps the kmedia-player will be a dvd-player with a lot of skins, dvd-menus and all other features soon.

what would be kind of neat would be a way to have a plug-in system that you could just drop into a specific folder. so even though there are Legal issues with DVD decoding there would be a way for someone to create an aRts plug-in of Decss and anyone could just install it without too much trouble, and if any other kinds of formats come out there could be an aRts plug-in or module made for it that any newbie could install. now like I said, I am just a dirty filthy no account end-user and have no idea how to program but, I do have a love of Linux and technology and want to see linux succeed. and I think somthing like that would be a boon to KDE, a real killer app/framework.

please don't beat me over the head, it's just an Idea (for bad or good) from a fellow Linux/KDE user. : )

thank's for reading my post!

by not me (not verified)

Well, that's kind of the idea behind a multimedia framework: let anyone write a plugin that can be installed with an RPM or whatever, and then all your multimedia applications can use that codec instantly. So if someone wrote a DeCSS plugin, and you installed its RPM, then all KDE applications would automatically be able to decode CSS-encrypted DVDs. Hopefully aRts will have the technology to do this right in KDE 3, and that's what this meeting is all about.

Ok, like I said I don't know much about the programming end of things I just love using Linux and if a suggestion is helpful in making Linux better and easier to use I will keep making them. I like fiddling around with Linux but I also like to have things "just work" too. KDE makes the "just work" part of Linux get better and better. so if KDE is trying to make aRts more user-friendly more power to them!

by Andreas (not verified)

I not a developer am a user so I will not comment how it should be done, I just say what I want as a user. I want kde to play movies simpel just by klicking on when. All well known format's should be supported. KDE should have it's own player well integrated with everything else in the desktop. Konq should list files with the icon of the first frame of the movie(that make's it very easy to see witch movie it is | Yes like win XP).

by hrhr (not verified)

no like in winXP that sucks , never do this :-( , perhaps we could make the forst frame wchich has
some picture on it , or just start to play the movie in the icon , that would be cool. my machine can handle
5-6 divx simulaniouly .

by Milifying (not verified)

There is a problem with those video-formats: they are all not open source and therefore most of the players only work on i386.
Since KDE claims to be cross plattform (KDE3 on alpha ? Any chance this time ?) implementing the Windows-Codec method used by mplayer & co ist not really a way to go, imho.
Besides, what if the use of those dlls is getting illegal ?