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

List:       kde-devel
Subject:    Re: kplayer vs. kmplayer
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2003-08-19 12:50:06
[Download RAW message or body]

On Mon, 18 Aug 2003, kiriuja wrote:

> Hi,
>
> I agree with Koos that the while the two players have some things in
> common, after all both are based on the same backend, they have taken
> different directions. Like Koos said, KPlayer is more geared towards
> the use as a standalone program. Indeed the goal is to have a full
> featured media player, although it does not prevent it from getting
> a KPart, as people keep asking for it all the time.

Feel free to strip whatever you need from kmplayer btw. For me it's also
easier to fix bugs in khtml when needed for it.

> Having a single program or at least a single middle tier, a shared
> library, is obviously a good idea, in principle, because it would
> help avoid duplicate effort. However, it is not clear whether the
> effort to make such a library would be more or less than the amount
> of duplicate effort it would help avoid.
>
> My experience shows that a lot of effort during the development
> has to be spent on working around various MPlayer bugs, so I think
> there is a fair amount of duplicate effort going on here, and having
> a single library would certainly save quite a bit of time.

Well, I didn't spend much time on this lately. Mainly because the
upcomming G2 libraries that will solve much of these (most troublesome is
mplayer compiled with native language support).
For that reason I've abstracted the player backend interface and was able
to add one for xine quite easily. Maybe add one for gstreamer? or others
but definitely G2 later. Having multible backends surely makes it
supporting more (and doing it with an out of process player will keep
kmplayer fast on startup and of course non-crashing).
So here is something to gain for kplayer, xine support (and that nice
dvdnav support).

 > Inside KPlayer there is a clear separation between user interface
> code and MPlayer interface code. The process classes are completely
> GUI-less, and they provide a few features that go beyond a simple
> wrapper around MPlayer's slave interface. For example, with the
> current MPlayer it is not at all easy to figure out the corrent
> time length of a media file. MPlayer's get_time_length/ANS_LENGTH
> feature is very far from being reasonably useful. KPlayer is able
> to correctly detect a file length with sub-second precision for
> most (local) file types. Other examples are subtitle autoloading
> and getting a list of available outputs and codecs. In general,

Interesting, maybe I strip something from kplayer :)

> KPlayer makes extensive use of MPlayer's output, and will do even
> more so in the future. I am sure KMPlayer's MPlayer interface has
> its own useful features. So a hypothetical library would have to
> have both sets of features, and if it is toolkit independent, it
> may also include features from other programs, mplayerplug-in is
> one example that comes to mind.

Maybe, but you will loose goodies like kprocess..

> I would be willing to help if someone were to undertake such a
> project, but I will not be able to do it myself. If and when we
> have a library like that within reasonable time, then I think
> we can talk about having a single program.

As long as we don't mind taking each others code, this might happen
automatically..

> As far as naming, it entirely depends on the goals of the program
> in question. When I was thinking about KPlayer becoming more than
> a player in the future, I thought about a name like KDE Media
> Center. But because the development resources are rather limited,
> the current plan is for KPlayer to be just a media player focusing
> on quality above all, so it will not be getting features like
> encoding or broadcasting in the foreseeable future, unless someone
> either implements them entirely on their own or gets some kind of
> KPlayer-KMPlayer integration project under way.

Yes, encoding or broadcasting are just attempts to make more use of the
movie_viewing/different_sources capabilities.
Last thing I want is to compete with noaton, I loose it anyhow (can't
peek in the soundserver). I'm not building yet another playlist impl. (but
of course use it if there were one in the kde libs). However kmplayer
does support the backend playing playlist files, only there is no user
feedback for it now. (and if a Xine/MPlayer developer is reading this,
please fix up .(s)ram/smil support :) )

FYI,
Currently for kmplayer their is a libkmplayercommon.so lib which provides
a KMediaPlayer (kdelibs/interfaces/kmediaplayer) implementation with
interfaces for the backend (KMPlayerProcess) and sources (KMPlayerSource).
On this these are build:
- libkmplayerpart.so is the kpart with the
  javascript/click_to_play/browserext/etc stuff.
- libkdeinit_kmplayer.so is the appl. with the sources for dvd/tv/vcd
  and broadcasting
- libkmplayerkofficepart.so plugin for koffice.

Koos
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]