General
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.
Comments:
Rich get back to work! - Ian Reinhart Geiser - 2002-03-20
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
Re: Rich get back to work! - Rob Kaper - 2002-03-20
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,
Re: Rich get back to work! - Ian Reinhart Geiser - 2002-03-20
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
Re: Rich get back to work! - AnCow - 2002-03-20
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.
Re: Rich get back to work! - George Staikos - 2002-03-20
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.
Re: Rich get back to work! - Raphael Wegmann - 2002-03-21
Where can I find QtVision?
I like fbtv (framebuffer TV from xawtv package) and
would like to try out QtVision.
Re: Rich get back to work! - George Staikos - 2002-03-22
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. :)
Good Job - Anonymous - 2002-03-20
Looks nice, simple, and easy to use
tv out? - anony - 2002-03-20
very cool.
how can i get this to work with tv out?
Re: tv out? - George Staikos - 2002-03-21
This is a TV-in, camera-in application. TV-out is a whole different game. Sorry...
Re: tv out? - Ciryon - 2002-03-21
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?
Ciryon
Re: tv out? - rui - 2004-01-04
como configurare trabalhar com tv out ?
agradecia que me mandasse um tutorial
Small mistake in the report - Andy Goossens - 2002-03-21
It seems there is a small error in the links to screenshots. The 2 Channel Wizard links go to http://www.kde.com/dot/kwintv/new-channel-wiz2.png and the first one had to point to http://www.kde.com/dot/kwintv/new-channel-wiz.png
Re: Small mistake in the report - Navindra Umanee - 2002-03-21
fixed. thanks.
Teletext/videotext features - cm - 2002-03-21
Hi,
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
Cheers,
cm.
Re: Teletext/videotext features - George Staikos - 2002-03-21
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.
Reg. Teletext - Anand - 2003-03-20
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.
Why KWinTV? - adam - 2002-03-21
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.
Re: Why KWinTV? - George Staikos - 2002-03-22
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.
Re: Why KWinTV? - Adam - 2002-03-27
Good point, using "win" isn't a good idea. But why post an article over somenting like a name?
mabey i've been smoking to much crack - adam - 2002-03-21
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.
Re: mabey i've been smoking to much crack - George Staikos - 2002-03-21
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.
Re: mabey i've been smoking to much crack - Rob Olsthoorn - 2002-03-21
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?
Re: mabey i've been smoking to much crack - Peter Jones - 2002-03-24
You mean like digiguide (www.digiguide.com)?
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
nice work :-) - andy wingo - 2002-03-21
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 -- http://gstreamer.net/cvs/ -- while it's written in gtk, the backend stuff is toolkit-independent.
just a thought. best of luck with this project.
wingo
ummmm.... no - Ian Reinhart Geiser - 2002-03-21
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
Re: ummmm.... no - George Staikos - 2002-03-21
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.
Re: ummmm.... no - andy wingo - 2002-03-21
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,
wingo.
Re: ummmm.... no - George Staikos - 2002-03-22
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.
Re: ummmm.... no - andy wingo - 2002-03-22
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.
wingo.
Re: ummmm.... no - andy wingo - 2002-03-21
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.
no? - Ronald Bultje - 2002-03-21
Hey, my name here?
[quote]
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
[/quote]
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?
[quote]
i am sure one could use a pipe to an exsiting encoder to do this but i am not sure about the details
[/quote]
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!
Re: no? - Christian Tusche - 2002-03-21
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
http://merkur.2y.net/av_convert
Re: no? - Ronald Bultje - 2002-03-21
that's what gstreamer does too ;-)
More information can be found here: - George Staikos - 2002-03-21
If you want more information, you can look on these sites...
<br><br>
<a href="http://www.kwintv.org/">http://www.kwintv.org/</a>
<br><br>
<a href="http://mail.kde.org/mailman/listinfo/kwintv/">http://mail.kde.org/mailman/listinfo/kwintv/</a>
<br><br>
If you have questions about the rewrite, please forward them to the kwintv mailing list so that the other developers can see them too.
<br><br>
Thanks!
What about OSD - menue for remote control via ir - buhzi - 2002-03-21
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:
http://www.cadsoft.de/people/kls/vdr/software.htm
Regards buhzi
Re: What about OSD - menue for remote control via ir - George Staikos - 2002-03-22
That's on our TODO list already.
only TV window - Milan Svoboda - 2002-03-21
Hi,
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.
Re: only TV window - Richard Moore - 2002-03-21
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.
Rich.
Re: only TV window - Milan Svoboda - 2002-03-22
Does that option also turn off window manager's stuff? (bar with minimize, maximize, help, close buttons).
Milan
Re: only TV window - Richard Moore - 2002-03-22
Not at the moment, but there will be a way to do that eventually.
Rich.
Re: only TV window - Roger Henderson - 2002-03-30
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 :)
Nice indeed but beware of this... - Jester - 2002-03-22
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 http://www.linuxtv.org 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 http://www.ost-dev.net 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 ?
zapping - Pavel Machek - 2002-03-22
Hi!
While thinking about conversion routines... It would be very nice to be able to share channel list with zapping TV viewer...
Pavel
FreeBSD - fura - 2002-03-23
Will it work on FreeBSD?
Videorecorder functionality - Eric Veltman - 2002-03-23
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,
Eric
Nagra support? - fred - 2002-03-24
what about support for nagra in kwintv?
or plugins to do that?
TV Sync - Johan - 2002-03-25
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!
