KWinTV: Future Vision

Richard Moore has been
working diligently on a rewrite of
KWinTV, the KDE
TV-card application. The "new" KWinTV (screenshots:
Wizard - Scanning
; and Main window) will be based on QtVision, a
Qt/Embedded TV application written by
George Staikos.
He has some really great ideas for future development, such as a panel applet to display a small TV, a TV screensaver, a TV desktop background and teletext/videotex support. Even better, he
has asked the community for feedback on where to focus his efforts.


The KWinTV Rewrite

Richard Moore
March 19, 2002
(edited by Dre)


This document is an overview of the changes I have been making to the
rewrite of the KWinTV
code which George Staikos
(People page) added
to CVS last week. The rewrite is based on George's QtVision, a Qt/Embedded
TV application which is a basic but functional framework for using Video4Linux
with Qt.
As you will see, I have been pretty busy, so I tried to break things down
into manageable chunks. If you just want the raw data, then skip to the
bottom for links to the latest class documentation and the
ChangeLog. If you have any comments or suggestions please
email me
(People page).


I have been hacking at the newly imported KWinTV3 (Qtvision) code,
and the changes are becoming significant enough to warrant
some discussion. The main things I have done so far are as follows:

  • Ported the code to Qt/KDE 3.
  • Employed the XML GUI framework.
  • Split the old main window class into two, with the back end being a
    standalone QObject that can be reused.
  • Written a generic I/O framework for channel files.
  • Tried to make the code into a collection of reusable objects so that
    it can be split into a library for accessing TV devices and a
    collection of user interfaces that use the library.
  • Cleaned things up a bit.
  • Improved the scan wizard.
  • Added a bunch of kdoc comments to explain how things work to other
    developers (hint!).

Current Plans


  • At the moment I cannot actually use this app as PAL support seems to
    be broken, so obviously I plan to fix this.
  • There are still more code cleanups needed.
  • Write a channel editor.

Channel Wizard

There are a number of obvious improvements that can be made to the
channel wizard. At the moment the ones I am planning are:

  • Get the region data from V2 working using the XML region data
  • Extending the GUI to work with the region stuff.
  • Adding the ability to import old channel files.
  • Making the wizard look cooler.

Improved Code-Reuse

I would like to provide a range of ways this code can be used, the things
that I am tempted to work on at the moment are:

  • A KPart that can be embedded in Konqueror as a viewer for channel files.
  • A kicker applet and extension that contains a small TV.
  • A QWidget for displaying a TV.
  • A screensaver that shows a TV.
  • A hack that makes the desktop background a TV.
  • A DCOP interface to the Qt-Vision back-end.

Wouldn't It Be Nice If...

There are a number of things my ideal TV application would have:

  • An integrated TV listings viewer.
  • The ability to set alarms that trigger when a program is starting.
  • Teletext (videotex) support.
  • A good way to channel hop and find what is on.
  • Knowledge of the stations available in a given area, so that when
    you have found your channels you can just say 'this one is BBC 1' and
    the app will automatically assign the name, icons, a link to the
    website, listings etc.

Detailed Changes


I have made various cleanups to the code while I have been working on it,
partly to make it work nicely with my other changes, and partly just
to make it easier to work with. I have tried to add kdoc comments to the
part of the code I have worked on to make it easier to understand how it
all works. I have also added a build target that creates a ChangeLog
file from the log recorded by CVS using cvs2cl (see links) so people
can keep track of what is being worked on. To make this useful, please
try to give a decent explanation when you commit changes.

Main Window

I converted the QMainWindow of the embedded code into a KMainWindow
and ported it to use the XML GUI framework. In addition I have split the
code into two classes making the backend code and the application
shell independent. Finally, I have started re-adding some of the
features of the old KWinTV main window, with the aim of doing it all
cleanly this time.

Most of the basics are now in place and working, so it might even be
possible to use the app already. I have re-implemented the fullscreen,
hide all, and LCD channel number features of V2 as custom KActions,
this is much cleaner than the old code and it might be worth using
them in the next release of the V2 code too.

Channel File Handling

I have written a generic API for loading and saving channel files. The
framework is designed along the lines of KImageIO, and allows new
filters to be added as required. The code is independent of the
Video4Linux code, as shown by the command-line test_channelio tool
which converts between different channel formats.

The filters currently working are:

  • KWinTV 0.8.x channel format version 4 (Read-Only).
  • CSV format of the original Qt-Vision code (Read-Write).
  • A new XML channel format (Read-Write).

The only other formats I see a need for are the XawTV format and the
format used by the win32 TV app that came with my Haupage card.

Channel Wizard

The channel wizard in the embedded version of Qt-Vision could afford to
block the UI, but that is not acceptable here so I have rewritten it to
be non-blocking. I also made the actual scanning code stand-alone so
it should be possible to write a command line version etc. later.

I have started adding the ability to use the region the user is in to
speed up the scan. The data for a region is loaded from another XML
file (instead of being hard-coded C++ as in the old KWinTV) so it
should be easy to add new regions. You can test this using the
test_channelscannerregion tool. At the moment this code does not work
as there are problems converting the frequency data I have into
something the V4LDev class can understand.


Developer Documentation

I have put a copy of the
and the latest
kdoc output
on my website so you can take a look even if you do not want
to download the code.


The code is in the KDE cvs in the directory kdenonbeta/kwintv3/ which
be seen online
via WebCVS.


This is a great tool that builds a ChangeLog file by analyzing the
logs recorded by cvs.

The End


I dont want to see anything out of you until you have Xmelegance done!
I have been lusting over that thing now for months, dont make me come over there and force you to code ;)

Although the kickerapplet with my webcam on is tempting too... Time to check out the source and start hacking.

-ian reinhart geiser

By Ian Reinhart Geiser at Wed, 2002/03/20 - 6:00am

It's always good to see roadmaps for applications.

I hope it will remain a true KDE application though, instead of a KDE-enhanced Qt application which QtVision sounds like,

By Rob Kaper at Wed, 2002/03/20 - 6:00am

What is more impressive is the source backend though, unlike more RFCs we see on the list this one has a formitable amount of code allready there. Even some of the hardest parts are done. It looks like once the backend is complete implementing video frontends should be relitively painless.

just my 2c from the code here...
-ian reinhart geiser

By Ian Reinhart Geiser at Wed, 2002/03/20 - 6:00am

Wow! This is really impressive. This is the kind on thing I really didn't think we would see on Linux for some time - but this looks great!

Keep up the good work.

By AnCow at Wed, 2002/03/20 - 6:00am

Don't worry, Rob. It's going to be a true KDE app. I've already made that very clear, and I don't think anyone disagrees. The reason it was called QtVision was that I originally made it with qt-e. The design was "close" to what we wanted for the kwintv rewrite so we decided to use it for an experiment, to see how to evolved as we brought it up to the desired kwintv structure. So far it's going quite well, and within a month, we hope to use these pieces to assemble the new kwintv.

In addition, there are 3 other developers. Mortiz Wenk, original author of kwintv, has joined us and I expect we'll start seeing commits from him soon. Michael Reiher and Stefan Hellwig also expressed interest in working on this rewrite.

At least Michael and I have very little time until the beginning of May, so I expect that development will pick up to an even quicker pace then. Hopefully we can start releasing functional "betas" starting this summer.

By George Staikos at Wed, 2002/03/20 - 6:00am

Where can I find QtVision?
I like fbtv (framebuffer TV from xawtv package) and
would like to try out QtVision.

By Raphael Wegmann at Thu, 2002/03/21 - 6:00am

It's not a useful application, sorry. You could check out the code from kde cvs and revert back to the initial checkin, then build it inside qt-embedded. But basically it barely works. It only does grab+blt (no overlay) and it doesn't work well for scanning channels etc. I don't recommend wasting time trying to use it unless you want to finish developing it. :)

By George Staikos at Fri, 2002/03/22 - 6:00am

Looks nice, simple, and easy to use

By Anonymous at Wed, 2002/03/20 - 6:00am

very cool.
how can i get this to work with tv out?

By anony at Wed, 2002/03/20 - 6:00am

This is a TV-in, camera-in application. TV-out is a whole different game. Sorry...

By George Staikos at Thu, 2002/03/21 - 6:00am

A bit off-topic, it would be soooooo nice to be able to enable TV-out without restarting X. Can it be done somehow using a Nvidia card?


By Ciryon at Thu, 2002/03/21 - 6:00am

como configurare trabalhar com tv out ?

agradecia que me mandasse um tutorial

By rui at Sun, 2004/01/04 - 6:00am

It seems there is a small error in the links to screenshots. The 2 Channel Wizard links go to and the first one had to point to

By Andy Goossens at Thu, 2002/03/21 - 6:00am

fixed. thanks.

By Navindra Umanee at Thu, 2002/03/21 - 6:00am


does anyone of you know AleVT?
Not a KDE app, but it does everything I need
for VT support. Maybe you could take a look at the
features to get some ideas (or code?). It would be nice to
see its functionality in KWinTV...

Features I've come to appreciate:

- caching of pages, also for multi-pages
- clicking on the sub page number (e.g. 2/3)
allows you to request a certain subpage
either from the page cache or live
(it cycles through e.g. 1/3, 2/3, 3/3);
and it *stays* at that sub page
- if you click on any number that looks like a
page number you're taken to that page (think hyperlink)
- the mouse wheel is used for paging up and down
- page history (right mouse button goes back)
- top text support


By cm at Thu, 2002/03/21 - 6:00am

I suspect we will use something like this for our teletext/videotext/closed captioning support. I haven't tried it so I don't know exactly what it can do, but we'll be sure to look soon.

By George Staikos at Thu, 2002/03/21 - 6:00am

Dear All,

Can anyone help me to know the difference between teletext, videotext and closed captioning. And I also want to know the format and transmission of Super Teletext. Please help me.

Thanks And Regards,
Anand G.

By Anand at Thu, 2003/03/20 - 6:00am

Why is it called KWinTV and not just something like KTV? Isn't this kind of close to WinTV, a copyrighted program? Also the Win part just makes it sound like we are just copying some Windows based program.

Sorry to nitpick. Just my two cents.

By adam at Thu, 2002/03/21 - 6:00am

You would have to ask Moritz Wenk that. He wrote the original one. I think it was called "ktv" at one time too. I don't know....

I just took over maintenance for a while. :)

Regardless, I don't think Hauppauge would complain. For one, this is positive advertising for them since it makes their brand name more popular (and they do nothing on the linux front).

For two, KWinTV is a TV application that runs under KWin so I think we're ok too. :) But I'm not about to test something like this in court.

By George Staikos at Fri, 2002/03/22 - 6:00am

Good point, using "win" isn't a good idea. But why post an article over somenting like a name?

By Adam at Wed, 2002/03/27 - 6:00am

How about a program that with the help of a TV program listing would determine what shows you watch on a regular basis and then automaticly searches through up comming shows and notifies you when something you might be interested in watching is on.

By adam at Thu, 2002/03/21 - 6:00am

Well I don't think this functionality belongs inside kwintv, but I do want to have at least 2-3 different plugin points. I'm considering plugins for input (like IR remote), and for channels (listings, etc, and for other channel file formats). This would make an interesting plugin.

By George Staikos at Thu, 2002/03/21 - 6:00am

KWinTV is one of my favorite apps on KDE, implementing the mentioned features will make it a Killer app. It will be a murderous app when the device plug-in architecture allows for video streams to come from file (like Aktion,MPlayer) and also from WebCams and even better DV-out devices on firewire ports (like Kino). Is the framework flexible enough to handle this? (Rename the app to get rid of the Win as well as the TV bit and call it KScreamer!)

Does KDE have a generic codec repository, etc?

By Rob Olsthoorn at Thu, 2002/03/21 - 6:00am

You mean like digiguide (

I wouldn't want this bound to a TVcard app - it's part of my life scheduling
stuff! Being able to have the pop-ups change channel for you (if you wanted)
would be nice, I guess (and good for digital video recording, of course).

-- Peter

By Peter Jones at Sun, 2002/03/24 - 6:00am

nice work, best of luck in to future. you might consider taking a look at gstreamer at some point in time (sooner rather than later would probably be more useful :-) because some features would be really nice to have -- for instance, a togglebutton that would turn on 'capture' or recording for what's on the screen, etc. such changes would be relatively painless to implement with gstreamer. ronald bultje has done some interesting work with gst-record in gstreamer cvs -- -- while it's written in gtk, the backend stuff is toolkit-independent.

just a thought. best of luck with this project.


By andy wingo at Thu, 2002/03/21 - 6:00am

the best thing to do would be to see if arts can do it allready.

i know it can record audio allready, i also know that there are developers working on better video support. we dont need to keep re-inventing the wheel when we allready have a good start. afaik captureing the video is very easy with the v4l api, it is compressing the bugger into an mpeg or avi that is the painful part. i am sure one could use a pipe to an exsiting encoder to do this but i am not sure about the details.

-ian reinhart geiser

By Ian Reinhart Geiser at Thu, 2002/03/21 - 6:00am

We will definitely use some sort of backend for video capture. The old code made this somewhat difficult to do well, but we have a better design for the new code. I suspect we will again use plugins for this kind of thing, so that we could implement various backends such as gstreamer, ffmpeg (another much requested backend), arts, etc.

It doesn't make sense to write compression/encoding backends anymore. I think this much is pretty obvious.

As for storing stills, Qt does a nice job so I think we'll stick with that.

By George Staikos at Thu, 2002/03/21 - 6:00am

Hi George,

Just to offer a bit of perspective, GStreamer actually wouldn't be all that useful as an output plugin. It's more of a way to make an application; the v4l stuff would then be internal to the gstreamer pipeline. Your Qt widget would actually embed an XWindow provided by a gstreamer element for the video, and you could even output sound to artsd if you like. But there's no real way to insert video that your app already has internally to a gstreamer pipeline. It's better to keep it all in gstreamer in the first place.

Also, GStreamer doesn't offer any new codecs (other than i guess tarkin, which other projects haven't picked up yet -- it's not exactly usable at this point though :) -- it's a framework. we have elements for ffmpeg, mpeg1 and 2, open quicktime, dv, mjpeg, rtjpeg, everything supported by avifile, and that's just on the video side of things.

You could still offer the ability to choose output and encoding methods with GStreamer, rather easily i might add, but it should probably remain internal to a GStreamer pipeline.

best regards,

By andy wingo at Thu, 2002/03/21 - 6:00am

We will not be making an application that requires other applications in order to work. I dont' have gstreamer... and I don't want it. Why should I have to have it in order to use kwintv? V4L is all of a few thousand lines of code for full support anyways.

By George Staikos at Fri, 2002/03/22 - 6:00am

i'd have left the thread as is a while ago, but misconceptions keep popping up -- gstreamer is not an application.

it's a library that can be used to make applications. your situation is another example of the 'why should my app have to depend on anything at all' problem -- one just has to assess the advantages and disadvantages of lib dependencies versus wheel reinvention. i'm sure that your v4l stuff works great, that's not in doubt. gettting back to my initial post, i just said that if you wanted an extensible solution, for instance for easy pvr behavior, you might want to look at gstreamer. that's all.


By andy wingo at Fri, 2002/03/22 - 6:00am

you've expressed a preference for arts, which is of course fine. the technical, let's-not-reinvent-the-wheel part of your argument is, however invalid i think; it is gstreamer that has the wheel made, and arts that is remaking it. the storage and compression of the video stream is a solved problem, and you'll find that raw video requires much more metadata than pipes easily allow for.

choosing some other solution might be perfectly valid, but not for the reasons you have given, other than any existing integration of some other system with the app.

cheers, wingo.

By andy wingo at Thu, 2002/03/21 - 6:00am

Hey, my name here?

afaik captureing the video is very easy with the v4l api, it is compressing the bugger into an mpeg or avi that is the painful part

v4l capturing is easy :-). See the v4l API docs.

The point in video capturing is indeed the encoding to as many formats as wanted and all that. That's the hard part. That's why I chose to use gstreamer as my framework, because they offer a complete solution to this. You don't need to use gstreamer for capturing per sé, but it'd probably be a good idea to at least don't reinvent the wheel for encoding. I hope artsd (this will be your media framework?) or kWinTV will not try to reinvent a complete framework for capturing to as many formats as possible etc, that's exactly what gstreamer's core is trying to do (and they're doing a pretty good job). It's independent of Gtk, Gnome and everything else, so... I hope there can be cooperation, it'd definately be a good thing. Try looking at gstreamer, it's worth at least a read :-).

B.t.w., do you guys have a kwintv chat/mailinglist somewhere for discussions?

i am sure one could use a pipe to an exsiting encoder to do this but i am not sure about the details

That's hard. The more formats you're gonna support, the more annoyed you'll get because of the differences between the encoders and all the work required for this, which is exactly why you should give gstreamer a chance, it solves this problem.

About kWinTV as such: nice job, especially the device selection and channel detection part (from the shots I saw), exactly what I wanted gst-recorder to do as well (it's still under development, some parts are there, some aren't). That's how good applications are supposed to work!

By Ronald Bultje at Thu, 2002/03/21 - 6:00am

I've tried different programs to record video, but everything i found was not useable at all (too slow, no a/v-sync, lost frames, own fileformat, ...)
I've written an new prorgram for recording, encoding and converting Video in different Formats. It consists of a frontend for the captureing and a library for handling audio and video files. Io to fileformats and codecs are implemented as modules - new formats can be added very easy.

So if this is helpfull for this porject, you can get it at

By Christian Tusche at Thu, 2002/03/21 - 6:00am

that's what gstreamer does too ;-)

By Ronald Bultje at Thu, 2002/03/21 - 6:00am

If you want more information, you can look on these sites...

If you have questions about the rewrite, please forward them to the kwintv mailing list so that the other developers can see them too.


By George Staikos at Thu, 2002/03/21 - 6:00am

I'd like to see a nice OSD menue overlayed the tv-frame to select a channel or some options from KWinTV with a remote control. Every good tv-set has such a menue so why not KWinTV.

See the images on this site to understand what i mean:

Regards buhzi

By buhzi at Thu, 2002/03/21 - 6:00am

That's on our TODO list already.

By George Staikos at Fri, 2002/03/22 - 6:00am

personally only what I need to view television is window with TV.
No icons, no menus and i think there is no need for bar with minimize,maximize and close buttons :-)
It would be nice if there will be config where i can put coordinates where
tv have to be when starting.

By Milan Svoboda at Thu, 2002/03/21 - 6:00am

That's why we included the option to turn all the decorations on and off (there's a single 'hide all the fluff' option). Allowing you to specify the window position is possible already using the commandline switches, but I agree having this in the config file too makes sense.


By Richard Moore at Thu, 2002/03/21 - 6:00am

Does that option also turn off window manager's stuff? (bar with minimize, maximize, help, close buttons).


By Milan Svoboda at Fri, 2002/03/22 - 6:00am

Not at the moment, but there will be a way to do that eventually.


By Richard Moore at Fri, 2002/03/22 - 6:00am

I've been messing around with running programs in the desktop, as part of learning kde programming, and I found that this:

kstart --type Desktop kedit

will start kedit full screen in the desktop with no title bar. Replace kedit with kwintv I guess :)

By Roger Henderson at Sat, 2002/03/30 - 6:00am

This looks incredible. It looks like this could become the Linux killer application for TV. At least it looks as a central place.

And here are my concerns/whishlist (sorry, email defunct atm, I'd mail otherwise):

Please make sure you add support for MHP/DVB. This is a big thing in Europe !
At the moment digital cable and sattelite broadcasts are still on DVB but the standard (MHP, which includes DVB) is already final and first devices will appear.

There is excellent DVB card drivers for Linux available at as well as the latest versions of the DVB recorder VDR (which plays DVD and MP3&Co. as well). This company also gets sponsored by NOKIA (MediaTerminal, Linux STB) for doing the MHP Linux implementation.

Also related to these two companies is a NOKIA sponsored OpenSource development-framework for Linux on TVs.
I mention the latter, since it still is nice to use the TV cards TV out, but this time with an OSD done by Linux, yammi :-)
This will be the future in EU.

Also I see many projects coming up which allow for http-hosted TV programs. Not only the nations have different formats, the publishing TV Guides have their own formats also.

Also, data-retreival (VT and other) is different for analog and digital streams.

Thus I would recommend to make this application as modular as possible.

DCOP is very important ! It allows for many many good things.

A clever plugin architecture would allow for different backends to be installed to get the TV program.

It would allow for interfaces to 'at' and 'cron' as well as the different cideo disk recorders out there.

I for one have stored my TV program in a MySQL database which gets updated daily. I heard someone is working on an LDAP frontend to the TV program.

So it would be nice when the Channel and Program listers could iport data realtime from plugins/scripts/DCOP calls.

Also I would be happy to see not only the channel list being a kpart but also the 'screen' itself. Or did I overread it ?

By Jester at Fri, 2002/03/22 - 6:00am


While thinking about conversion routines... It would be very nice to be able to share channel list with zapping TV viewer...

By Pavel Machek at Fri, 2002/03/22 - 6:00am

Will it work on FreeBSD?

By fura at Sat, 2002/03/23 - 6:00am

Hello Richard & George,

Nice document, there are a lot of good ideas in it.
Same counts for the replies, a lot of good ideas.
Especially importing TV guide info from web sites
and setting alarms for your favorite TV programs
would be great. One thing I did not see mentioned
often is videorecorder functionality. I would like
it a lot if I could use my Linux box with TV card as
a full-featured videorecorder, which wakes up automatically
just before the to-be-recorded program starts.

Best regards,


By Eric Veltman at Sat, 2002/03/23 - 6:00am

what about support for nagra in kwintv?
or plugins to do that?

By fred at Sun, 2002/03/24 - 6:00am

I don't even have a TV card, but I do have a TV-out on my GeForce. Even if it is way too complicated to switch resolution (desktop size) in X I at least managed to get it working in no time. But - Xine and other players do not seem to sync to the TV correctly. Maybe it's the fault of the nvidia driver, all I know is that it is very disturbing.

My question to you is: does this KwinTV sync its drawing intelligently when using it in a multi monitor setup? Maybe it's X's job to do this but then it might still be possible to force good sync from the app.

I'd also like too see temporal filtering when "resizing" 24/25/30 fps video to 50/60/75/whatever hz output devices :) Even if syncing is perfect there is a very noticeable jitter when just flipping frames on a "nearest neighbor" basis. Linear interpolation should be good enough and not eat too much CPU. On fast computers you could probably update the picture at the speed of the monitor sync producing an extremely smooth output. On slower machines you could go down to every second refresh when there is a mismatch like 30->75 or 24->80 and still get an improvement.

Oh, another wish to all video player gurus: Please include an option to force software rendering (in RGB space)! Overlays on my card seem to have worse colors, and they also do not use the same calibration mechanism as normal graphics. I also experienced this same fenomena on my old computer - in Linux hardware overlays did not work making the video look much better than in windows!

By Johan at Mon, 2002/03/25 - 6:00am