Hello,
just wanted to inform you, that I'm currently working on a Qt based client for Vomp-server.
It already logs into server, displays some lists and at the end I can play a MP3 file and hear the sound (sound I hear since 2 days).
As it is just a "technology is basically working" state, I'm not providing code, as public testing results are really not yet useful.
But in case someone is interested in helping getting the code further, then I would search for a place for sharing development/code (I would for sure prefer this site).
It is a "native" Qt implementation, so no code of vompclient is in detail used/copied.
Why Qt:
Longer story. In short I want to have something for Qt Embedded/Qtopia, so in future streaming clients with more RAM than within the MVP I can use the Qt environment for coding, i.e. the WebKit integration is my favorite.
But for the very moment it is just that we have a native Linux client on the normal desktop.
And I worked on KSpread in the past, so I'm used to the Qt way of doing things.
Technically:
It uses the Phonon integration, so it has some ups and downs.
Biggest up is that I don't need to think about demuxing something, the biggest down is at the moment that gstreamer (the Qt integrated Phonon backend) doesn't support the VDR format of MPEG files (live TV I still have to check). But xinelibs (should) support them, so running on KDE (4.x) should solve it.
Why native reprogramming:
I'm definetly impressed by the existing code. It is clean, efficient and effective.
But most of the vomp code handles low level stuff, where Qt offers also solutions. So in detail not much code needed to be reused or can be reused when I anyway program with Qt.
But I know, not all likes Qt...
If you want more info, just let me know.
Does this mean there is a future for Vomp with high definition video, albeit without the Hauppauge MediaMVP hardware? I much prefer the Vomp frontend to VDR's own OSD, but with the transition to high def I was resigned to giving up Vomp at sometime in the near future.
You might want to consider at an early stage what impact any development might have upon maintaining a front end system that can boot quickly from either a cold or standby state.
Good luck!
Quote from: stu-e on April 25, 2008, 12:23:56
Does this mean there is a future for Vomp with high definition video, albeit without the Hauppauge MediaMVP hardware? I much prefer the Vomp frontend to VDR's own OSD, but with the transition to high def I was resigned to giving up Vomp at sometime in the near future.
Just guesses /future outlook:
- Vompserver just delivers the mediastream to a client. If this is the case then the only limitation is the performance as this Qt implementation just forwards to the Phonon BE and libxine (AFAIK) supports already HD material. So for Desktop yes
- There will be a streamingclient available where we can do a Phonon similar BE for the hardware available. The NMT is now preliminary support by mvpmc, but I'm unsure about HD material. So there is an existing client already available that we have linux sources for. Details to be analysed and here we will need to do demuxing.
- General: Yes this is the whole purpose of my work: Getting a HD streaming client with additional features like webbrowsing, games, etc.
Quote
You might want to consider at an early stage what impact any development might have upon maintaining a front end system that can boot quickly from either a cold or standby state.
I don't think this has to do with the client software in general. This is rather the system setup. Loading/starting the client software just takes few seconds, a cold boot includes always loading the system. So total time starting is only affected by the system, not really the client software.
E.g. Starting the current MVP vomp client just takes about 2s, but the whole reboot with the system takes so long.
Quote from: muellerph on April 25, 2008, 10:51:43
Hello,
just wanted to inform you, that I'm currently working on a Qt based client for Vomp-server.
[...]
awesome!
for the time being i'm using "VDR Channel Chooser" in cooperation with VLC
under Linux.
i'm looking 4ward to your product!
cheers,
Harry
Update to current status (not that anybody thinks this is vaporware :P)
Yesterday I got the first recording video played in my application. For me this was milestone 3.
Details why it took so long:
At the end it was clear it is a bug in the phonon-gstreamer implementation, or better a not any longer supported function. During trying to find the issue, I cleaned up all the structures of my first version, so I'm now at a point where I can clearly look foreward.
Things done:
Login, menu, recordingslist, mediafilelist, play media (which is currently MP3 only, no JPeg yet), rudimentary play recording (just play, no stop, jump, etc.)
Things open:
Live-TV, channellist, timers (list and set), epg
i18n, config settings, overall look of the app, etc.
If anybody is interested in the code, I can post now. But would be good to have a host...
>If anybody is interested in the code, I can post now. But would be good to have a host...
*JUMP* *ME*
I'd like to see if there is a chance to get that thing running in MacOS.
Got a MacBook Pro and a Mac mini at hand, so i could give it a try.
Fab
Quote from: papablues on July 17, 2008, 22:56:57
>If anybody is interested in the code, I can post now. But would be good to have a host...
*JUMP* *ME*
I'd like to see if there is a chance to get that thing running in MacOS.
Got a MacBook Pro and a Mac mini at hand, so i could give it a try.
What a perfect match. I can test Windows and Linux, but don't have a Mac and I wondered if it will work on Mac as well (as the trolls said/promised).
I will cleanup a bit and send you the gzip package till it's clear where and how to host the code. Please send me your email address in a PN.
For the moment you will need to adjust the pro files manually as I don't have yet checked the details too much of setting it up in a general way. I just aligned it to work on my disti (Debian Experimental/Lenny).
And there is also the issue I had with the backend phonon-gstreamer. This didn't work at all and maybe therefore the issue is equal also with the MAC phonon-BE (it's the difference in having the data stream synchronous to the request call or asynchronous and phonon-gstreamer-BE only supports synchronous).
I know a workaround (some code to be exchanged), but that would mean having the datastream synchronous. Sadly, at the end gstreamer still cannot play the recordings (I tried with Totem) and so even if I support asynchronous for gstreamer, I still cannot use it. Only Xine-BE is playing recordings and also supports asynchronous data streams correctly (as defined in the docu).
In case gstreamer will support playing the recordings in future, I may switch to synchronous datastream, so no dependency on KDE on Linux, but it can also be possible that phonon-gstreamer will support in future asynchronous datastreams (I sent a bug/wish report to the trolls as well as an KDE dev).
Another issue:
Are you able to play the recordings on MAC with Quicktime (or whatever the MACplayer is) as they are stored by VDR?
If not, there is no chance to play recordings... Live-TV is different and cannot be tested before I implemented the functionality.
Quote from: muellerph on July 18, 2008, 07:51:28
Another issue:
Are you able to play the recordings on MAC with Quicktime (or whatever the MACplayer is) as they are stored by VDR?
If not, there is no chance to play recordings... Live-TV is different and cannot be tested before I implemented the functionality.
Perian Quicktime enhancement would be able to play it, but it does not recognize it's fileformat.
VLC of course does.
Please send me the code and we will see if i can get it to work ....
Hello,
I have Live-TV now working. Yeahhh :D ;D ;D :D
Working means:
Output of video and audio, but for sure it is not yet everything you can think about as a TV application.
Attached is a screenshot. I will remove it later again, when the app is more mature. Screenshot removed
I have also uploaded the sources to a repository: http://code.google.com/p/qtvomp/ (http://code.google.com/p/qtvomp/)
Papablues:
Next is now the change to a synchronuous class, so maybe with this approach you will get it to work on MacOS.
Update:
Live-TV, playing recordings and music files works now correctly and stable - you definetly can use it now already for comfortably watching live-tv.
Switching channels and going fullscreen is now supported too.
I consider this functionality stable and ready for alpha release.
Also the code doesn't have any hack anymore, so it is a clear basis for further development. Rough edges are still there, but only the beauty of the code is the issue.
What's still missing till a first alpha release is (in my opinion):
- OSD support
- EPG info in OSD and channel list
These are the functionality that I consider necessary for a broader testing. Implementing this functionality will just take some weeks from now on.
To be implemented after the fist alpha is:
- fancy design, beautiness, high WAF, ...
- EPG form
- Timers (setting/deleting)
- moving/deliting recordings
- storing configuration
- i18n
Bad news:
No platform is supported beside of Linux with Phonon-xine-backend.
Neither MacOs (papaBlues was so kind to test it with quicktime-backend w/o success) nor Windows (my tests with DS9-backend) didn't work so far for video. Audio files are working on all backends.
I still have hope for Windows with DS9, as I'm sure same issues with selecting the right graph applies here like with the current Windows client
Also for all platforms we may get results with the not yet released MPlayer and/or VLC backends.
But for the first alpha I now plan for Linux-xine-backend alone.
If you have any question or suggestion, just let me know.
You can get the code from the project homepage - see my previous post.
Philipp
Philipp: Good work. I'm interested to see it working...
Firstly, when I run it, it broadcasts for the server, but doesn't acknowledge any responses. IPTraf shows that responses are returning from the VDR server.
Anyway, supplying the -s switch with my server address makes it connect. It gets the channel list and recordings lists fine, however, on starting a live channel or recording I get the message:
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
I have the debian package phonon-backend-xine installed with debian version number: 4:4.1.0-2.
Any ideas?
Quote from: Chris on August 25, 2008, 17:14:36
Firstly, when I run it, it broadcasts for the server, but doesn't acknowledge any responses. IPTraf shows that responses are returning from the VDR server.
Are you running it on the same machine as a vdr instance is running? In this case, I know I had issues as the port was occupied, but didn't try to solve it (yet).
Otherwise I changed the way the server is search 3 weeks ago, made a short test and thought it is working (which may not be the general case).
Quote
Anyway, supplying the -s switch with my server address makes it connect. It gets the channel list and recordings lists fine,
Good: In case you provide images in the ../bin/images/logos/ dir from http://www.mcnutt.org/duncan/vdr/ you also get nice looking channel logos :-)
Quote
however, on starting a live channel or recording I get the message:
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
I have the debian package phonon-backend-xine installed with debian version number: 4:4.1.0-2.
Do you run KDE 4.1 completely or just qt and phonon packages?
I can remember that the qt + phonon were missing something from normal KDE 4.1 packages. I need to recheck then again what exactly when I'm at home.
In case KDE4.1 is installed: Are you able to run the files with Dragonplayer?
In case w/o KDE4.1: Then you should at least be able to play sound with gstreamer-backend defined/installed. Does this work?
________________________
Update: I think the relevant packages were kde4libs, kdebase-runtime.
maybe also kdebase-workspace, but I fear this removes kde3 then.
So the basic environment to run KDE 4 programs.
Reason:
phonon-xine uses still some very minor functionality of kde4. These will be / are currently removed for next release of Phonon (which maybe KDE 4.2 or Qt 4.5, whichever comes first).
Quote from: muellerph on August 25, 2008, 18:05:20
Quote from: Chris on August 25, 2008, 17:14:36
Firstly, when I run it, it broadcasts for the server, but doesn't acknowledge any responses. IPTraf shows that responses are returning from the VDR server.
Are you running it on the same machine as a vdr instance is running? In this case, I know I had issues as the port was occupied, but didn't try to solve it (yet).
Otherwise I changed the way the server is search 3 weeks ago, made a short test and thought it is working (which may not be the general case).
Vomp clients may run on the same host as VDR server with the following Vomp server patch for udpreplier.c
ds.send(ds.getFromIPA(),ds.getFromPort(), serverName, strlen(serverName));
instead of:
ds.send(ds.getFromIPA(),3024, serverName, strlen(serverName));
The patch returns response to the source UDP address of the request for Vomp servers instead of always using 3024.
Quote from: AndersF on August 26, 2008, 10:22:32
Quote from: muellerph on August 25, 2008, 18:05:20
Quote from: Chris on August 25, 2008, 17:14:36
Firstly, when I run it, it broadcasts for the server, but doesn't acknowledge any responses. IPTraf shows that responses are returning from the VDR server.
Are you running it on the same machine as a vdr instance is running? In this case, I know I had issues as the port was occupied, but didn't try to solve it (yet).
Otherwise I changed the way the server is search 3 weeks ago, made a short test and thought it is working (which may not be the general case).
Vomp clients may run on the same host as VDR server with the following Vomp server patch for udpreplier.c
ds.send(ds.getFromIPA(),ds.getFromPort(), serverName, strlen(serverName));
instead of:
ds.send(ds.getFromIPA(),3024, serverName, strlen(serverName));
The patch returns response to the source UDP address of the request for Vomp servers instead of always using 3024.
Untested, but out of Qt Docu:
In vdrfindserver.cpp line 27
instead of
m_udpSocket->bind( 3024 );
using
m_udpSocket->bind( 3024, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint );
May also do the trick.
Is it then working? (I can only check when I'm back at home)
I'm running Ubuntu and get the following compilation error:
Does anyone have a clue?
g++ -c -pipe -fpermissive -g -D_REENTRANT -Wall -W -DQT_SHARED -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/usr/include/phonon -I/usr/include/qt4/QtNetwork -I../build/src -I. -o ../build/src/dlgaudioplayer.o dlgaudioplayer.cpp
In file included from vdr.h:31,
from vdrthread.h:25,
from dlgaudioplayer.h:35,
from dlgaudioplayer.cpp:22:
ringbuffer.h:339:23: warning: no newline at end of file
dlgaudioplayer.cpp: In member function \u2018void DLGAudioPlayer::setupActions()\u2019:
dlgaudioplayer.cpp:175: error: \u2018SP_MediaPlay\u2019 is not a member of \u2018QStyle\u2019
dlgaudioplayer.cpp:178: error: \u2018SP_MediaPause\u2019 is not a member of \u2018QStyle\u2019
dlgaudioplayer.cpp:181: error: \u2018SP_MediaStop\u2019 is not a member of \u2018QStyle\u2019
dlgaudioplayer.cpp:184: error: \u2018SP_MediaSkipForward\u2019 is not a member of \u2018QStyle\u2019
dlgaudioplayer.cpp:186: error: \u2018SP_MediaSkipBackward\u2019 is not a member of \u2018QStyle\u2019
I'm also unsure, but what google told me about "is not a member of" shows a lot of time mixed systems.
May it be possible that you have a Qt version <4.4 somewhere on your system? Phonon was introduced in Qt4.4.
___________
Update:
I'm rather sure you have something like Qt 4.4 and KDE 4.0 installed (or some similar old stuff lying around).
In between KDE 4.0 and Qt 4.4 the Phonon library was "moved" from KDE to Qt, or at least it is a new version.
It seems you now try to compile the Qt 4.4 phonon library with libraries/hearders from KDE 4.0, so newer Qt with older KDE.
This may explain the error message that the "MediaPlay" is not a member of QStyle.
Just a new screenshot of the channel selection with EPG entries.
Hi Philipp..
I just spent a while trying to upgrade kde packages to 4.1 on Debian sid, though I still can't get qtvomp to actually start a recording or live. I wasn't expecting this, but I get different results depending on whether I am logged into gnome or kde. This is from gnome:
main: argument passed to app: "-s"
main: server IP address set to: "10.0.0.1"
MainWindow::MainWindow called
VDRThread::run started - init VDR
VDRThread::run started - entering event loop
VDRThread::eventLoopReady called
WidgetPlayVideo::initWidgetPlayVideo called
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
Phonon::createPath: Cannot connect Phonon::MediaObject(no objectName) to Phonon::AudioOutput(no objectName).
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
Phonon::createPath: Cannot connect Phonon::MediaObject(no objectName) to WidgetVideo(no objectName).
WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
VDRThread::waitForEventLoop started
VDRThread::waitForEventLoop ended
MainWindow::MainWindow done
VDR::requestLogin: "10.0.0.1"
VDR::readLogin: Time offset of server: 0
From KDE it gets further...
main: argument passed to app: "-s"
main: server IP address set to: "10.0.0.1"
MainWindow::MainWindow called
VDRThread::run started
VDRThread::eventLoopReady called
WidgetPlayVideo::initWidgetPlayVideo called
QtVomp(5612) Phonon::KdePlatformPlugin::createBackend: using backend: "Xine"
VDRThread::vdr called
VDRThread::waitForEventLoop started
VDRThread::waitForEventLoop ended
VDRThread::initVDR called
VDR::requestLogin: "10.0.0.1"
MainWindow::MainWindow done
VDR::readLogin: Time offset of server: 0
MainWindow::displayRecordings: was called
MainWindow::displayRecordings: load recordings
VDR::getRecordingsList: "10.0.0.1"
VDR::readRecordingsList: totalSpace: 186600 freeSpace: 93329 percent: 50
MainWindow:updateRecordings: size = 98
WidgetPlayVideo::playRecording: was called
WidgetPlayVideo::playRecording: make instance of stream for entry "Reaper" with path: "/200gb/vdr/Reaper/2008-09-09.23.00.99.99.rec"
VDRThread::vdr called
VDRThread::waitForEventLoop started
VDRThread::waitForEventLoop ended
VDRThread::initVDR called
VDR::sendKeepAlive time: QTime("15:34:39")
VDR::sendKeepAlive time: QTime("15:34:41")
but the result is the same, no video window.
Dragonplayer can play one of my vdr files.
Any ideas?
Hi Chris,
thanks for testing.
This all look strange to me and before I now go into wild guesses, I think it's time to play with some other installations on my own.
Hi Chris,
this was a regression of my previous upload. Fixed in trunk.
Please try again.
But Gnome I fear still wont work.
I assume some environmental things, like QTDIR, etc.