[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic