From kde-devel Tue Aug 19 12:50:06 2003 From: Koos Vriezen Date: Tue, 19 Aug 2003 12:50:06 +0000 To: kde-devel Subject: Re: kplayer vs. kmplayer X-MARC-Message: https://marc.info/?l=kde-devel&m=106129723328623 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 <<