aRts/KDE Video Roadmap Meeting

Tuesday, 15 January 2002  |  Nstevens

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 irc.kde.org
http://www.openprojects.net/
How:kSirc in kdenetwork
(or KVirc if you insist)

Comments:

or... - dmalloc - 2002-01-15

or .. Irssi, IrcII, BitchX, Xchat etc etc etc *grin*

Re: or... - Shift - 2002-01-15

Or mIrc.... Ok I ---> [] ;-)

Re: or... - Neil Stevens - 2002-01-15

Anyone using mirc will be kicked and banned. :-)

Re: or... - Evan "JabberWokky" E. - 2002-01-15

I doubt it - I just moved, and was stuck on a Windows machine for a week (my roommate's with a modem) while I waited for DSL. Luckily nobody kicked or banned me in any *nix dev channel for using mIRC. Maybe you're a wee bit less open? -- Evan

Re: or... - Erik Hensema - 2002-01-15

Maybe you are some newbie who doesn't understand a smiley?

Re: or... - Evan "JabberWokky" E. - 2002-01-15

Yes. Yes, I am a newbie. Excellent perceptive skills and cunning repartee, sir. -- Evan

Re: or... - anonymous - 2002-01-15

People like you should be shot in the head.

Re: or... - ac - 2002-01-15

... or be forced to use mirc. :)

Re: or... - cylab - 2002-01-15

Nobody should ever be shot in the head! seriously!

Re: or... - stephan - 2002-01-15

>People like you should be shot in the head. Don't tell me - you are that Israeli guy, aren't you? Thank god you probably don't know who the poster really is. Please don't bring such attitudes into this forum.

Re: or... - domi - 2002-01-15

BitchX rules !

Keep talking about the Audio, please. - J - 2002-01-15

I'm not sure if I am alone in this comment or not. But, my experience, KDE 2.1.1 to 2.2.2 with artsd has been very disappointing to say the least. I have a Tecra 8100 laptop 600 MHz (256M Ram) that esound and regular linux sound works great on. Plugging in artsd, though, creates the most *nasty* choppy sound on the planet. I moved around kernels between 2.2.x to 2.4.7 to 2.4.9 to 2.4.17 and still get the same results. I changed all the bitrate crap, adjusted how much CPU usage and tweaked about everything except my hair before I just gave up. I also have an i810 600MHz with 256M Ram as well. It improves the artsd server a little bit, but I still get the occasional snap,crackle,pop. I'd like to use noatun, but XMMS is so much better. 90% of the noatun's problem is artsd, 10% is speed. Please improve artsd! I am an avid KDE fan and would like to be as pure as I can to help with bettering this desktop.

Re: Keep talking about the Audio, please. - Neil Stevens - 2002-01-15

hm, as the bottom of the page here just said: "The trick is not to dream of adding a feature, but simply to do it." -- Stefan Westerfeld

Re: Keep talking about the Audio, please. - Stuart Herring - 2002-01-15

Have you tried using the preemptive kernel patch? I've not had much of a problem with artsd as a general rule, and would only get the occansional choppyness when really stressing out the machine (Starting oracle and booting windows under VMWare at the same time) But the preemptive kernel patch has removed even those problems, and I can use artsd quite happily with a response time of 40ms. I also don't use Noatun, as I prefer XMMS's playlist, but I do use the artsd output plugin for XMMs....and I play mp3s all day without problem.

Re: Keep talking about the Audio, please. - J - 2002-01-15

Yes I've used preemptive. The only thing I haven't done is move to ALSA. I will try that when 2.4.18 comes out.

Re: Keep talking about the Audio, please. - not me - 2002-01-15

Are you using the sound drivers in the linux kernel, or drivers from the ALSA project? In my experience, ALSA drivers are higher quality. If you aren't using ALSA, try that. That solved some problems I was having with aRts.

Re: Keep talking about the Audio, please. - Andrea - 2002-01-15

That worked for me too, in particular for my i815 integrated sound card on my laptop, but I got improvements also on the AC97 one on my desktop... ALSA is definitely better...

Re: Keep talking about the Audio, please. - not me - 2002-01-16

Yes, reading the rest of this thread I think that many people's problems are caused by the bad sound drivers included with the Linux kernel. Those drivers work OK for some things but aRts seems to just kill them. I read somewhere that aRts uses unusual features of the sound drivers that most other programs don't use, which would explain why for example esound works. Hopefully the 2.5.x kernel series in development now will make the switch to ALSA so that when 2.6.x is out Linux will finally have large numbers of high quality native sound drivers.

Re: Keep talking about the Audio, please. - Sven Geier - 2002-04-19

In re: "Hopefully the 2.5.x kernel series in development now will make the switch to ALSA" ALSA has been integrated to the official Linux 2.5 tree. The initial merge is in patch-2.5.5-pre1, which included the 0.9.0beta9 packages

Re: Keep talking about the Audio, please. - Chakie - 2002-01-15

I used Noatun a while when 2.0 was new, but it was quite sueless for me. Any normal desktop activity caused it to skip, and it crashed too often. I tried packages of KDE (Mandrake at the time), manually compiled, and CVS releases. Now I use the Debian Woody packages, and it still isn't stable, so I'm back to xmms land. :( If I was technical enough I could submit bug reports, but nobody wants to see "I played some music and it died" in a report. I also don't know why it should take so long to load, i.e. several times longer than xmms, and use so much memory. I think Noatun/arts will be good when it works, and I'll keep trying it regularly, but for now I've removed it from all file associations etc.

Re: Keep talking about the Audio, please. - AC - 2002-01-15

Try to increase the size of the audio buffer (in KControl/SoundServer/SoundIO).

Re: Keep talking about the Audio, please. - Chakie - 2002-01-15

Oh, that has been done. Without it I couldn't even move a window without skipping. :) There were some other settings I fiddled with too, and some helped a bit.

Re: Keep talking about the Audio, please. - Rumcajs - 2002-01-15

For me It also skips when I move window ( having gcc, knode and a few konquerors running on my K6/400 128MB, especially at linking stage ). Hey people, stop complaining ! Artsd/noatrun is quite good - I find xmms worse ( I didn't try to change default settings ).

Re: Keep talking about the Audio, please. - Buggy - 2002-01-15

"manually compiled, and CVS releases" ... "If I was technical enough I could submit bug reports" If you can checkout stuf from CVS, build and install it, I think you are more than capable of a useful bug report!

Re: Keep talking about the Audio, please. - Carg - 2002-01-16

Noatun was introduced in KDE 2.1.

Re: Keep talking about the Audio, please. - BS - 2002-01-15

I've tried all versions of Noatun till kde 2.2.2, but the sound is extremely choppy, and continued heavy use of resources. Using xmms with artsd plugin makes xmms also produce choppy sound. The only way seems to be toi disable arts from autostarting, and then using xmms directly with oss drivers, for decent sound. I think as an end user, i would prefer if noatun would first play audio files atleast as well as xmms, and then we should look at video playback.

Re: Keep talking about the Audio, please. - luci - 2002-01-15

I completelly agree! I found esd (e sound daemon) much faster than artsd with xmms, but unfortunatelly i use mandrake 8.1 and have problems to get esd running (sometimes - it depends on weather? - i get luck to start esd, but i don't know how...). it always tells me: --- esd: Failed to fix mode of /tmp/.esd to 1777. Try -trust to force esd to start. esd: Esound sound daemon unable to create unix domain socket: /tmp/.esd/socket The socket is not accessible by esd. Exiting... --- ...even if i tryied everything possible to do with the =socket file in /tmp/.esd. i never had such problems with esd under redhat 7.1 but i'm too lazy to switch back, so i have to use that slow artsd when i want to hear few simultaneous sounds in my KDE 2.2.1 (i have got a poor amdk6/233, 128mb ram). arts works, but is really slow for me...

Re: Keep talking about the Audio, please. - Ill Logik - 2002-01-15

su <passwd> chown -cR <your login name>.audio /tmp/.esd/

Re: Keep talking about the Audio, please. - luci - 2002-01-15

thnx! it helped with esd -d /dev/sound/dsp command. but i have another problem... is it possible to run esd (artsd) available for more than just one user? luci

Re: Keep talking about the Audio, please. - KBoyte - 2002-09-20

If you want ESD available globally, try this (I got it straight from the freshmeat page) 1. In your startup file (I use /etc/rc.d/rc.local -> Peanut Linux; yours may vary) add: /usr/local/bin/esd & sleep 1 /usr/local/bin/esdctl unlock 2. In /etc/profile, add: export LD_PRELOAD="/usr/local/libesddsp.so /usr/local/lib/libesd.so" Make sure the paths are correct...this is for my Peanut Linux setup (Slackware-derivative) using Esd 0.2.29 with default install path. Run /etc/rc.d/rc.M (or your equivalent) to restart the default runlevel and login again. If you hear the beeps and get no errors when starting X, everything should be OK.

Re: Keep talking about the Audio, please. - standsolid - 2002-11-11

is there any way to start artsd in esd, like how i would start esd as $ artsdsp esd can i edit some kde startscript to make arts flow to esd?

Re: Keep talking about the Audio, please. - ik - 2002-01-15

"do it yourself" uhm, if arts wants more developers it needs decent docs. last time i checked it wasn't so.

Re: Keep talking about the Audio, please. - richard june - 2002-01-17

What about network audio? I've never gotten that to work, else I would use arts. I would much prefer to actually get sound in KDE *and* be able to stream audio from another system...

aRts Performance on low end machines? - Stephan - 2002-01-15

My experience with arts on my machine at home(SuSE 7.3, K6-200, 96MB) hasn't been very good. While it works as expected it uses way too much CPU. Running xmms and playing an mp3 uses half of the CPU. Killing artsd and using just OSS for playback needs only 3% CPU. Because of this it's not possible to use noatun for MPEG-Movies with sound because there is almost no CPU-power left for the movie itself. Everything is needed by artsd. So I just disabled artsd and use xmms and xine for audio/video and the performance problem has gone away. I wonder if anybody knows where this overhead comes from...and if there is a solution?!

Re: aRts Performance on low end machines? - Tim Jansen - 2002-01-15

Without knowing Arts' performance characteristics I would blame it on the IPC/MCOP stuff and/or conversion on the server side. As xmms is not a native arts app it must send all the sound data to arts, arts will (maybe) convert it to whatever format the sournd card requires and only then they you hear that. With a native arts app this can be done differently, you can do everything inside arts and only pass control commands (open file/start/stop/forward) from the app to arts. Then there should be no noticable difference in performance between a traditional app and an arts-based. For video the app would probably give a window id to arts and arts would put the video in the window for the app. bye...

Re: aRts Performance on low end machines? - Stephan - 2002-01-15

As XMMS has an arts output plugin I consider it to be a native aRts app. Also the performance is about the same for the combination Noatun/artsd and XMMS/artsd. I would like to try Noatun with direct output to OSS or ALSA but AFAIK this is not possible(?!).

Re: aRts Performance on low end machines? - Tim Jansen - 2002-01-15

The arts output plugin doesn't make any difference since the decoding is still done in XMMS's process, not in artsd.

Re: aRts Performance on low end machines? - Sean Russell - 2002-01-16

This doesn't make any difference. artsd sucks up the CPU using the KDE media player noatun. And while noatun works on my laptop, it hangs on my desktop (with a gen-u-wine SB Awe 32 audio card... can you get more standard than that?). This, with KDE 2.2.2. Every once in a while I try artsd, but usually I have it disabled it and just use XMMS. I'd be more willing to mess with it if it wasn't such a CPU hog.

Re: aRts Performance on low end machines? - lanbo - 2002-01-15

I thoought I was the only one having problems with arts... It takes all my CPU (I have 1Ghz clock speed). I also use XMMS because it works better and consumes less CPU in my case. The strange thing is that it must work on the arts developers computers... Maybe they did some configuration changes and forgot telling to other people?

Re: aRts Performance on low end machines? - Macolu - 2002-01-15

I've installed KDE 2.2.2 on several computers with several sound cards (always using OSS), and I've never had any problem using artsd.... And I'm not a developer :-)

Re: aRts Performance on low end machines? - lanbo - 2002-01-16

just use bash: top

Re: aRts Performance on low end machines? - Aaron J. Seigo - 2002-01-15

i too used to feel that aRts was the most beta-ish software in KDE during the KDE2 run. aRts would routinely crash and it wasn't very efficient. in short, it sucked on my system here (which got me into an argument or two with Neil and Charles on IRC ;). it did get better but never got Great. then KDE3 devel started and the first thing i noticed when i jumped back to CVS HEAD when things settled down a bit was that aRts didn't crash anymore. and it was noticeably more efficient. i'm not sure if it was the move to the GSL code or if my luck has simply changed, but i'm quite happy with aRts now. it doesn't feel / behave like it is a beta release anymore =)

Re: aRts Performance on low end machines? - not me - 2002-01-16

That's great news! aRts really has been one of the weaker parts of KDE, which is a shame since it has so much potential. The problems with sound skips and CPU usage have really held it down. Hopefully in KDE3 aRts will mature into the multimedia framework to end all multimedia frameworks!

Re: aRts Performance on low end machines? - AC - 2002-01-16

Same goes for me. But with the TOSS driver in kde3 it doesn't take more cpu than xmms for ogg even with freereverb or mplayer for mpeg. ~0.1% cpu for both. No CPU usage what so ever when it's idle i had to dissable the autosuspend to avoid crashes but how needs it now :)

A look at what's available outside KDE - Phil Ozen - 2002-01-15

As a user, I always try to look what's available outside KDE. Today, in the Linux VIDEO arena, we have very good projects around. There's another multimedia framework "Gstreamer" and 2 video players that support most formats: "mplayer" & "Xine" (other projects like "Ogle DVD player" & "VideoLan" & "AVI file" support limited formats). How KDE can take advantage from these available multimedia ressources ? For good video support in KDE, we need: 1) aRts framework to be able to stream video 2) a good video player 3) a set of libraries to decode (and encode ?) video streams. For item 1, aRts will be a much better video framework due to its new core (made in collaboration with Tim Janik of BEAST project: http://beast.gtk.org/). For item 2, two choices are possible: Choice a) To continue to use Noatun and improve its video support. Today, mplayer and Xine are the best but Mplayer got many developpers and is growing very fast. It can be a good model for Noatun to evoluate as a good Video player. Choice b) To use Noatun for audio & use another (or others) player for video. Today, it's what happened with aKtion. We can do the same and convert Mplayer or Xine into PlayObject. This solution is fast but aRts is only used for the sound & video output. The meaning of aRts as a framework is useless then. For item 3, two choices are possible: Choice a) To continue with "mpeglib" from Martin Vogt. I think it's THE weakness of aRts since it's done by one man only and is monolithic. Choice b) To accept libraries from other projects through plugins. This is the method used by Gstreamer: they re-use existing libraries by interfacing them to Gstreamer network. They don't create libraries themselves and focus on the framework instead. Both aRts (http://www.arts-project.org/) & Gstreamer (http://gstreamer.net/) are very similar: a framework on which you can plug modules & a graphical tool is available to do it. ARts can benefit from Gstreamer by re-using its plugins (which are a lot). However, I don't know how difficult it is (maybe a common plugin API between Gstreamer & aRts ?) I hope these ideas can help. Thanks KDE multimedia developpers.

Re: A look at what's available outside KDE - Nick Betcher - 2002-01-15

Hello people! Noatun doesn't decode your hax0r 31337 MP3s. aRts does. Noatun doesn't play movies, aRts does. Noatun doesn't decode. Noatun doesn't have codecs. Noatun doesn't take your CPU. Noatun doesn't skip, and last but not least, Noatun doesn't play ANYTHING! aRts does! If you want to play a Quicktime video in Noatun, you just tell aRts how to do it, recompile it, re-load it. Noatun will play it then because all Noatun does is talks to the server (aRts). _ARTSD_ uses mpeglib. This isn't about Noatun, this is about aRts. Read the post: "aRts/KDE Video Roadmap Meeting" NOT "aRts/Noatun". </rant> --Nick Betcher

Re: A look at what's available outside KDE - Tim Jansen - 2002-01-15

2a) Pure players like Xine, mplayers and all the others won't get you anywhere. Well, almost, you can use them for playback of files which may be the most important use case, but not more. They usually have *very* inflexible plugin mechanisms, optimized for playback of files. Among other things, they usually lack (without wanting to criticize a specific player): - the support of encoding (think of video conferencing, video mails, video editing, tv recording) - the support for decoding without realtime (video editing, re-encoding) - 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) - the support for filters These players are ok as an interim solution, but in the end they will be wasted effort. The good thing is that, partially because of their popularity, many people have written codecs that can easily be rewritten for a better framework. 3b) GStreamer is fine, but uses this ugly GObject framework that makes it hardly usable for most sane people :)

Re: A look at what's available outside KDE - ealm - 2002-01-15

umm.... > they usually lack (without wanting to criticize a specific player): > - the support of encoding (think of video conferencing, video mails, video editing, tv recording) > - the support for decoding without realtime (video editing, re-encoding) > - 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) > - the support for filters mplayer's got ALL of those features...

Re: A look at what's available outside KDE - Evan "JabberWokky" E. - 2002-01-15

:: mplayer's got ALL of those features... Both MPlayer and VideoLAN. Both of which are GUI independant projects that use plugins for the entire front end. Both of which, like aRts, are designed to work with any WM or Environment, and have a good solid base of plugins to read everything from DVDs to DivX ;-) files. -- Evan

Re: A look at what's available outside KDE - Tim Jansen - 2002-01-15

Actually mplayer does not even have a real plugin-structure, it is a huge cut&pasted hack that's illegal to distribute in binary form because of its mix of licenses. It's very good at what it does, but almost everything is hardcoded. Decoding is done in a huge switch statement, you cannot just edit a filter without editing the mplayer core and recompile it. It's completely unusable for implementing, say, a new video editing or conferencing tool.

Re: A look at what's available outside KDE - Andrea Albarelli - 2002-01-15

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

Re: A look at what's available outside KDE - Tim Jansen - 2002-01-15

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

Re: A look at what's available outside KDE - Neil Stevens - 2002-01-16

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.

More on GStreamer - Neil Stevens - 2002-01-16

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.

Re: More on GStreamer - Phil Ozen - 2002-01-16

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 http://www.arts-project.org/, 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." (see http://lists.kde.org/?l=kde-multimedia&m=97794476604838&w=2) "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." (see http://lists.kde.org/?l=kde-multimedia&m=97811984816016&w=2) 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.

aRts room for improvement - Neil Stevens - 2002-01-20

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.

Re: aRts room for improvement - Phil Ozen - 2002-01-21

Yes, I agree, it's a big blocking point. To grow, a project needs new blood. Obviously, the same kind of web site as "Gstreamer.net" 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

I still want sound with several voices - Christian Schuglitsch - 2002-01-15

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

Re: I still want sound with several voices - hoink - 2002-01-15

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

Re: I still want sound with several voices - Tim Jansen - 2002-01-15

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.

Re: I still want sound with several voices - Christian - 2002-01-16

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.

I am just a dirty end user, but..... - LD - 2002-01-16

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!

Re: I am just a dirty end user, but..... - not me - 2002-01-16

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.

Re: I am just a dirty end user, but..... - LD - 2002-01-17

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!

movie player - Andreas - 2002-01-16

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

Re: movie player - hrhr - 2002-01-16

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 .

Re: movie player - Milifying - 2002-01-28

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 ?