[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: KDE/aRts strategy meeting
From:       Tim Jansen <tjansen () gmx ! net>
Date:       2002-06-26 12:34:38
[Download RAW message or body]

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 
something) we're several man-years away from having a workable and 
competitive video framework for anything but playback.
2. You do not need to rewrite anything unless you need video capabilities. 
Arts is ok for sound/music and does not even have competition in the synthi 
use case. It "only" lacks video capabilities. 
3. My interest in a video framework is as a library user. I want to write a 
video codec that is integrated in some multiplexed, multi-codec format like 
AVI with minimum effort. And I want to write apps record&playback that video. 
I also want the perspective that there will be apps like video editors in the 
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 
suggest that there will be a competitive video framework in the next 2 years. 
The Xine system seems to work well and will make many users happy, without 
any doubt, but is not enough for many applications (i remember reading that 
the Xine guys want to overhaul the core for the next major xine release and 
it would be interesting to know what it planned though, possibly it is 
another contender)
5. Losing the benefits of C++ is relative. If I need to decide whether I want 
to write my media-related code in pure C, or spend the next years of my life 
writing and maintaining on a new C++-based video framework, it is quite 
obvious to me which solution is less pain. 
6. Writing a C++ wrapper for a C-based framework is always MUCH less work than 
writing a new framework
7. There is at least one effort to create a media framework which is already 
very far. Given the amount of work that is neccessary to do something like 
this, duplicating their work sounds a little bit like writing a new kernel 
because Linux does not have a C++ API. 
8. Are the other frameworks perfect? Certainly not. Would I prefer a perfect, 
C++ friendly, Arts integrated framework with MCOP support and so on? Yes. Do 
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++ friendly 
video framework with all codecs, input and output plugins that you would 
need, there is another problem: compatibility. For obvious reasons it would 
be desirable that codec authors can write their codec just once and it would 
run on all desktop environments. The current situation is rather cruel: 
everybody makes up their own API (like libavi, ogg/vorbis, libmpeg2, 
ffmpeg...), and people write wrappers. Because this is not always possible 
some seem to start forking the original codecs and import them into their 
source tree... if a vendor want to support linux they either just release 
their windows code (On2) or they make up their own API and just drop the the 
library without any app that supports it (DiVX 5). Creating another framework 
does certainly not improve the situation. Settling on a de-facto standard 
probably would.

bye...


_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]