Kiss GStreamer Video Player

As part of the GStreamer invasion of KDE, Ronald Bultje has implemented Kiss, a simple version of a Totem-like video player for KDE with a GStreamer-backend (screenshot). I took a look at the source code and it looks fairly simple -- it's actually 23K worth of well-separated code in all, with the other 2.8M being makefile/configure overhead. Even if one doesn't understand the GStreamer parts, you could probably copy and paste them into your own KDE application. (Incidentally, this application seems to have been made with KDevelop, for those of you who need inspiration.)

Dot Categories: 

Comments

by gerd (not verified)

Why cut and past when it is just fine?

What's wrong with Kdevelop?

by Navindra Umanee (not verified)

1. Maybe because you want to reuse the code?
2. Who said there was anything wrong with KDevelop?

by KOffice fan (not verified)

Wait a second, 23 K of code and 28 000 K of overhead? What the hell?

by Zaheer (not verified)

I think u mean 2800 KB of overhead

by Navindra Umanee (not verified)

The price of source code portability, I suppose? Ever wonder how all that "./configure; make; make install" magic happens? *shrugs*

It's been like this for a while, try looking at the source code for Ky, for instance.

by Morty (not verified)

The 2800k overhead are lots of configure and makefile magic implemented in a generic way to cover most, if not all and then some ways to get the build to work on different systems. You could write the configure and makefiles from scratch and the resulting overhead would become negligible, but the time you end up using maintaining and debugging the buildsystem for different targets are time you could spend writing code for the application. Or you could remove unneeded parts from the generic configure/makefile's, but the cost are again time. You trade size of the source tree against development time, since this has no effect on the compiled app it's a good solution.

by Roberto Alsina (not verified)

Weird. A PyQt app works on just as many systems and has about 500 bytes of overhead (the setup.py script). C/C++ really is lame in this area.

by Morty (not verified)

Hey, this is not a fair comparison. And since you usually have to write 2-10 times the lines of code in C/C++ compared to Python to do the same thing, it's not fair at all:-)

by Shulai (not verified)

But if PyQt binding uses autoconf/automake (I don't remember, I'm not a Python fan) then it have that large overhead itself, so indirectly you still have it.
Not to mention the overhead in the build system of KDEBase/Libs/...

Probably the only solution could be a "runtime" for configure, so most of its stuff is on its own package and not in the source tarballs. But there are a lot of people (not me) claiming HD/RAM/BW are cheap and wanting for self-contained packages, so I'm not sure how such idea could be taken.

by Roberto Alsina (not verified)

No, sorry, you can't make both arguments.

Yes, PyQt (and Python) have some overhead like that. But a PyQt app doesn't.

If you want to make the argument that it does, then you can't make the argument about the "runtime" because what python gives you is exactly that (distutils) :-)

by Morty (not verified)

You are going too far, the point was about applications not the whole framework. Folowing your reasoning you forgot to mention the buildsystem for X, the compilers and the kernel, and that's ridiculous. The requirements for installing an application either binary or from source, are that the needed infrastructure are in place, library's etc. Anything concerning install of those have no bearing on this case, as they are already installed.

Based on the quality they now have I consider the Python, Ruby and Javascript packages from kdebindings as an integral part of KDE, and I rate it as a bug if they are not included in the distribution.

by Spy Hunter (not verified)

That's because PyQt needs python to be installed already. Automake/Autoconf relies on only a few tools which are preinstalled on almost every Unix system (like HP/UX, Solaris, AIX). However these tools are implemented differently on each Unix, so Automake/Autoconf has to bend over backwards to be compatible with everybody. Plus it has the capability to check several hundred compatibility issues that are different between Unixes (plus your own checks that you define) so that your source code can be compatible. Python is the same everywhere so PyQt does none of that. It would be nice if C was the same everywhere too, but for historical reasons every Unix is different. Luckily Automake/Autoconf are here and do the compatibility work for you, at the price of a couple of MB of automatically-generated files. It is a good trade-off.

by Roberto Alsina (not verified)

The auto* files are hardly autogenerated. Every line of your configure file was written by someone as a macro. Also, pretty much noone understands the things, so if you need to test for, say, libmikmod, you just don't, and it seems to be portable, but isn't.

As for auto* requiring only a few tools... well, that's their problem. The way they are written sucks.

Mind you, I have nothing better to offer, except maybe publishing programs in ways that force platform vendors to wake up and offer a decent platform to work on, but that's just wishful thinking.

Python being the same everywhere is a python *plus* as a platform. C and C++, as a platform, don't have it. There comes my point about C and C++ being lame in that area.

by Roberto Alsina (not verified)

BTW: here's how you test for PyQt on a setup.py:

try:
import qt
except ImportError:
print "You need to install PyQt"

by Air (not verified)

Of course "The auto* files are hardly autogenerated", is python autogenerated? The executables of your c(++) code. They ARE autogenrated, after you manually give some command. So first define autogerated, but then still this is a silly discussion, because you are making a comparrsion between two different things that are made for different goals. When c++ was invented phyton was just a snake I guess. So many people know c++, so its a waste of time, for a lot of them (they can make good money with this knowledge) to learn python. So python is newer, so it SHOULD be better. Else it was a lame job too invent it at the first place. Too give all those good c++ programmers a more easy job by publishing and share there great ideas and work with everybody on a lot of different systems, designed for a lot of different tasks, auto* was made. Very handy, with unfortanatly a lot of overhead. Owh my .... Lets start a disgussion about it. because. WE python guys don't have this overhead. Whoopsy we are much better. Well in that area. okay you made your useless point. A ferrary IS faster but cannot transport the milk from hunderd cows. Whow the milk tank is slow, but hey it CAN transport a lot of milk. Thats why they are both there. So if you compare those two completlye different things, compare them fully, test them, write a report and publish it :) Or just code good programs :).

Well anyway, it stays fun to make all this stupid replies :).

Auke

by Bryan Feeney (not verified)

Will anyone be creating C++/Qt bindings to GStreamer for KDE 4, similar to what's happened with D-BUS? Judging by Gnome its a powerful backend, but it doesn't seem to mesh perfectly with KDE style code.

Also, does anyone know why is the author using greater than and less than instead of plain old equals when querying the GStreamer state? I'm not saying this is wrong, I've just never used GStreamer before and I'm curious to know what's going on there.

by Ronald S. Bultje (not verified)

The greater thans are there for no real reason. You could replace them with equals and it'd work just as well (state changes are guaranteed to be one-level at a time). I guess I use greater thans to make the purpose of the code (as in: checking a state shift) somewhat more clear.

by koos (not verified)

Wow, could be a nice starting point for kmplayer having a gstreamer backend too ... only get seg faults in KissWindow::open... ah I should use the File dialog (silly me, the mac menubar).. hmm no video only sound (mplayer says
[mpeg4 @ 0x84857a8]looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag).

Btw. anyone know if debian's gstreamer-0.8 from testing is crippled or not (eg. can it play avi and such) This is what I have
$ apt-show-versions |grepgstreamer
libgstreamer-plugins0.8-0/testing uptodate 0.8.5-1
gstreamer0.8-a52dec/testing uptodate 0.8.5-1
gstreamer0.8-oss/testing uptodate 0.8.5-1
gstreamer0.8-hermes/testing uptodate 0.8.5-1
gstreamer0.8-alsa/testing uptodate 0.8.5-1
gstreamer0.8-vorbis/testing uptodate 0.8.5-1
gstreamer0.8-sdl/testing uptodate 0.8.5-1
gstreamer0.8-dv/testing uptodate 0.8.5-1
gstreamer0.8-dvd/testing uptodate 0.8.5-1
gstreamer0.8-esd/testing uptodate 0.8.5-1
gstreamer0.8-mpeg2dec/testing uptodate 0.8.5-1
gstreamer0.8-jpeg/testing uptodate 0.8.5-1
gstreamer0.8-doc/testing uptodate 0.8.7-1
gstreamer0.8-speex/testing uptodate 0.8.5-1
gstreamer0.8-swfdec/testing uptodate 0.8.5-1
gstreamer0.8-mikmod/testing uptodate 0.8.5-1
gstreamer0.8-flac/testing uptodate 0.8.5-1
libgstreamer-gconf0.8-0/testing uptodate 0.8.5-1
libgstreamer0.8-dev/testing uptodate 0.8.7-1
gstreamer0.8-jack/testing uptodate 0.8.5-1
gstreamer0.8-cdparanoia/testing uptodate 0.8.5-1
gstreamer0.8-x/testing uptodate 0.8.5-1
gstreamer0.8-sid/testing uptodate 0.8.5-1
gstreamer0.8-caca/testing uptodate 0.8.5-1
gstreamer0.8-gsm/testing uptodate 0.8.5-1
gstreamer0.8-plugin-apps/testing uptodate 0.8.5-1
gstreamer0.8-plugins/testing uptodate 0.8.5-1
libgstreamer-gconf0.8-dev/testing uptodate 0.8.5-1
gstreamer0.8-gnomevfs/testing uptodate 0.8.5-1
libgstreamer0.8-0/testing uptodate 0.8.7-1
libgstreamer-plugins0.8-dev/testing uptodate 0.8.5-1
gstreamer0.8-misc/testing uptodate 0.8.5-1
gstreamer0.8-artsd/testing uptodate 0.8.5-1
gstreamer0.8-aa/testing uptodate 0.8.5-1
gstreamer0.8-festival/testing uptodate 0.8.5-1
gstreamer0.8-tools/testing uptodate 0.8.7-1
gstreamer0.8-mad/testing uptodate 0.8.5-1
gstreamer0.8-audiofile/testing uptodate 0.8.5-1
gstreamer0.8-theora/testing uptodate 0.8.5-1

by Ronald S. Bultje (not verified)

Hi Koos, you want to use at least gst-plugins 0.8.6 (as the website also mentions). 0.8.5 will work for audio, and with a small hack it'll work for video too, but I don't want those hacks in example code. ;-). The hack is that you need a different property for getting the video size in 0.8.5 than in 0.8.6. With current code and 0.8.5, Kiss will always claim that the video is 0x0 pixels, and thus not show the video window (user experience: no video). For playback of divx, you will additionally want gst-ffmpeg. This package is not yet available in Debian's main archives, but it's available in several unofficial repositories. Ask the debian people for details. RPMs for both gst-plugins-0.8.6 and gst-ffmpeg are available all over the internet.

If you want to add a backend to kmplayer, please do. I'll try to help if I can.

by koos (not verified)

Got it working now for a MPEG-PS stream w/ 0.8.6 debian/unstable. Does crash on exit but that's for kmplayer no problem :-) FFMpeg can wait .. Did need to resize the window a bit for the video actually stayed, but I had that with Xine too.
Give me a few days and I'll have something to start with.

by mikeyd (not verified)

It would be nice if kaffeine added this functionality as well. It already has multiple backends (xine/arts/netscape) so adding another plugin should be easier than with kmplayer.

by standsolid (not verified)

While I'm a fan of Kaffeine and not as much KMPlayer, this is totally inaccruate. Just read the first line on their page

http://www.xs4all.nl/~jjvrieze/kmplayer.html

It supports multiple backends (MPlayer/Xine/ffmpeg/ffserver/VDR) -- I think even more than Kaffeine.

-//--- standsolid --->>

by gnumdk (not verified)

Kaffeine support kmplayer kpart so ... :)

by mikeyd (not verified)

Ok, you're right. It didn't have them last time I looked - but then neither did kaffeine at that time.

by koos (not verified)

Easier is hard to measure, no? For me it's obviously easier to add it to kmplayer. Actually it already works, but only for a local file.

by Florian (not verified)

More and more applications arise that use a the backend (GStreamer, NMM, ...) directly and in its own way.
It think its time for a KDE standard way, a abstraction layer, so that there are not too many KDE application which are fixed on one backend. Me, for example would prefer using NMM.
The abstraction layer should be agnostic of the multimedia backend used.

Just my two €-Cents...
Florian

by Anonymous (not verified)

If you would have read any off the kdemultimedia discussion or summaries of the last week you would know that such a layer for basic audio functionality is planned.

by Florian (not verified)

I know that its planned.
But planning is just the first step. What I wanted to say it that they need to hurry with planning.

by mikeyd (not verified)

But not for complicated audio funcionality. The layer that will exist will be suitable for things like the track playing preview thingy in K3b, and possibly also in juk. It won't be suitable for a dedicated media player. For that gstreamer looks (to me) to be the best option, but what would be nice is an option "approved" by kde. (of course gstreamer has the approval of the, ah, "other people")

by Florian (not verified)

I think the major disadvantage of GStreamer is the missing network transparency, which is included in NMM.

by Christian Schaller (not verified)

True, but the time needed to add network transparency to GStreamer would be smaller (15 days of work to design and implement NMM style or better network transparency was our estimate when we discussed it last) than the time needed to create all the GStreamer plugins etc. for NMM.

by Ronald S. Bultje (not verified)

Seriously, does a video player need a network-transparent multimedia backend? Are you seriously going to play this video in a distributed network fashion?

by Florian (not verified)

I am not talking about the backend for this specific player but the standard backend used for all KDE applications.

by ac (not verified)

KDE is often deployed on thin-clients. The applications run on the server and display on the thin-client. It wouldn't do to play Kiss on the server and have the sound play *on the server*. The sound has to play on the client.

by ... (not verified)

The A is before the D, retard, first, get gstreamer working well with the KDE enviroment and ask for network transparency later.

by Salsa King (not verified)

yeah, its called gstreamer.

by mETz (not verified)

people make you think that but it's not really the case (yet).

by MrPeacock (not verified)

configure script doesn't insert the CXXFLAGS for gstreamer and kde include paths.

by Ronald S. Bultje (not verified)

Correct, it sets CPPFLAGS instead. Requires automake >= 1.7, though, won't work with 1.6 (which you appear to be using). I've disted using 1.7, so you shouldn't see that unless you re-ran make -f Makefile.cvs.

by Brandybuck (not verified)

Now if only GStreamer wouldn't crash and burn on startup, I could try some of these new KDE applications. But since the aRTs based apps work just fine, I don't feel any pressing need to debug GStreamer...

by koos (not verified)

Exactly what I was thinking every time I tried gstreamer and lets wait until it's robust first. But this is a nice gift to at least start with it. Remember xine was also a crashing beast not long ago.

by Bastien Nocera (not verified)

I mean, if Totem had as many feature as this example application, nobody, not even me, would use it.

by Navindra Umanee (not verified)

I think got that description from the original link submission to this site, and I guess Ronald himself described it as Totem-like at some point, although he did say "simple version". Sorry. :)

by Davide Ferrari (not verified)

Well, I don't think that the classic Gnome app has got so much more features then this code example app

by Bastien Nocera (not verified)

Find me any movie player other than Totem that has a telestrator mode!

by Distro Whore (not verified)

Is it your mission to troll other news sites and bash anything that can play video?

by Bastien Nocera (not verified)

Where did you see bashing? Buy goggles.

by ac (not verified)

Your hostility is uncalled for and out of line, if I may say so.

by Ian Monroe (not verified)

Another KISS video player is codeine http://www.kde-apps.org/content/show.php?content=17161

It uses Xine as its backend.

I still just use CLI mplayer. 9 times out of 10 any GUI just gets in the way for me, though I usually use something like kmplayer for DVDs.

by daniel (not verified)

i'm trying to compile the kiss project but the configure script keeps failing

its says i dont have gstreamer version 0.8 or higher although i installed gstreamer 0.10.

what could be the problem?