From kde-multimedia Wed Jun 26 12:34:38 2002 From: Tim Jansen Date: Wed, 26 Jun 2002 12:34:38 +0000 To: kde-multimedia Subject: Re: KDE/aRts strategy meeting X-MARC-Message: https://marc.info/?l=kde-multimedia&m=102509496600687 On Wednesday 26 June 2002 02:32, Neil Stevens wrote: > > IMVHO this could also be taken as an opportunity to look at one of the > > existing sound servers (like JACK(jackit.sf.net)) and maybe a different > > media framework (like a C++-wrapped gstreamer.sf.net). > Why? What benefit does this give users of KDE to throw away something > that works, rewrite media apps to support the replacement, and lose the > benefits of C++ (at least for the aRts->GStreamer) switch? Some random and unordered points: 1. The obvious problem with the current situation is that (unless I missed= =20 something) we're several man-years away from having a workable and=20 competitive video framework for anything but playback. 2. You do not need to rewrite anything unless you need video capabilities.= =20 Arts is ok for sound/music and does not even have competition in the synthi= =20 use case. It "only" lacks video capabilities.=20 3. My interest in a video framework is as a library user. I want to write a= =20 video codec that is integrated in some multiplexed, multi-codec format like= =20 AVI with minimum effort. And I want to write apps record&playback that vide= o.=20 I also want the perspective that there will be apps like video editors in t= he=20 future that can use my codec without requiring me to port it first. 4. Since the last multimedia meeting I havent seen any progress that would= =20 suggest that there will be a competitive video framework in the next 2 year= s.=20 The Xine system seems to work well and will make many users happy, without= =20 any doubt, but is not enough for many applications (i remember reading that= =20 the Xine guys want to overhaul the core for the next major xine release and= =20 it would be interesting to know what it planned though, possibly it is=20 another contender) 5. Losing the benefits of C++ is relative. If I need to decide whether I wa= nt=20 to write my media-related code in pure C, or spend the next years of my lif= e=20 writing and maintaining on a new C++-based video framework, it is quite=20 obvious to me which solution is less pain.=20 6. Writing a C++ wrapper for a C-based framework is always MUCH less work t= han=20 writing a new framework 7. There is at least one effort to create a media framework which is alread= y=20 very far. Given the amount of work that is neccessary to do something like= =20 this, duplicating their work sounds a little bit like writing a new kernel= =20 because Linux does not have a C++ API.=20 8. Are the other frameworks perfect? Certainly not. Would I prefer a perfec= t,=20 C++ friendly, Arts integrated framework with MCOP support and so on? Yes. D= o=20 I see another solution to get what want in the next 2 years? No. 9. Even assuming that there is a fully functional and complete, C++ friendl= y=20 video framework with all codecs, input and output plugins that you would=20 need, there is another problem: compatibility. For obvious reasons it would= =20 be desirable that codec authors can write their codec just once and it woul= d=20 run on all desktop environments. The current situation is rather cruel:=20 everybody makes up their own API (like libavi, ogg/vorbis, libmpeg2,=20 ffmpeg...), and people write wrappers. Because this is not always possible= =20 some seem to start forking the original codecs and import them into their=20 source tree... if a vendor want to support linux they either just release=20 their windows code (On2) or they make up their own API and just drop the th= e=20 library without any app that supports it (DiVX 5). Creating another framewo= rk=20 does certainly not improve the situation. Settling on a de-facto standard=20 probably would. bye... _______________________________________________ kde-multimedia mailing list kde-multimedia@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia