Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

Vomp media player

Started by avvdr, March 14, 2007, 15:52:25

Previous topic - Next topic


Hi all (esp. Chris),
I like vomp a lot - great work!
I use it now heavily and found it lacks media player functionality (anyway works much better then mediamvp oder mvpmc...).
So I started to work on adding media player functionality.
Currently I got the picture display working (was prio 1 for me). So I would like to share this with you - and to start discussion about some further work.
I've prepared the patches against todays cvs for client and server. Should I post them here? (about 150k).
- aa - they include WOL too (I use this heavily)...
@Chris: What do you think - would you like to integrate this into the project? I saw there is heavy progress in CVS - so I got my last snap about 2 weeks ago and I needed some time to merge everything...
I would be happy to put the staff into CVS...
Maybe some short Ideas about further work:
My prio 1 would be the audio (mp3) player - but I saw that there is ongoing work in the player area - so difficult to manage this.
I attach at least my readme that contains some descriptions and an overview about the functionality.



your help to the project is greatly appreciated!
can't wait to see the results.
(but will wait patiently ;))



Hi all,
hmm - zipped patches are small enough - so I post them here.
If there is anybody out to try this...
Just apply the timer (see readme...) and _media patch (-p1) to the client sources, the server patch to the current cvs server part, check the makefile (still used -3 script for devenv).
I run the server on a Suse 10.2 - Suse vdr package (that is vdr-1.4.5-2.1) compiles against /usr/lib/vdr..
Maybe I will try to build a dongle out of it (not my major focus, I boot and mount from a DS101j NAS - so no real need for a dongle, the NFS works well for me).

Feedback is welcome...



Hi avvdr,

yes, yes, yes.
How I would love to have this functionality already last Sunday, when my parents were visiting us and showing pictures of their last travel. This would have been a wow effect  ;D

Anyway, because of lack of time (family and work), I couldn't jump into working on the same functionality. But from time to time I can spend time to think how to do it.
The issue I see, is that JPEGs (i.e. the one from the newest cameras) are getting bigger and bigger. Sooner or later these will become so big that the memory at the MVP is getting the limiting factore. It may crash or not display the picture. Wifes won't accept this  ;)

So my idea would be to have the scaling as well as rotating on the server. This would have several benefits:
1. The memory in the MVP is no issue anymore, as the jpeg for the MVP is now already very small

2. Assuming the server is at least as fast as the MVP processor, the whole thing get's much faster, as at least the transfer through the network is then much faster. I assume everybody has a server at least as fast as the MVP. How to get tumbnails displayed on the MVP is horror I assume, just because of the network alone.

3. You could use the memory at the server for caching, let it be the thumbnail view or even the scaled pictures. If it is going to be perfect when it could even scale already the comming pictures, while you are currently watching on the MVP on.
Memory on the server is a no brainer for me, as it could use the hd as well for storing the thumbnails, etc.

4. You could easily integrate also EXIF information (i.e. rotation info). For sure you could do it on the MVP as well, but in case everygthing is on the server, the server could do it too.

I know this is against a idea of having everything done on the MVP, but for pictures I definetly see big advantages when we do the active part on the server.



Good morning everybody,

I'm really looking forward having such a great mediaplayer-functionality on my mvp! :-)
The description of the picture-module sounds advanced and elaborate.
I would agree to muellerph - it seems to be be fastest way to pre-scale and pre-cache the pictures/thumbnails on the server. We must keep in mind the different resolutions of PAL/NTSC.

Chris mentioned i while ago that a problem of adding more and more media-functionality on the mvp is the limited space in the dongle/on the mvp - is this still critical?



QuoteChris mentioned i while ago that a problem of adding more and more media-functionality on the mvp is the limited space in the dongle/on the mvp - is this still critical?
Sure, this is still a problem, the people from mvpmc are currently at the limit and have problems to add more features.



I remember Chris saying that there would be problems with resources in extending VOMP. I had the idea of making the various functions modular / plugin with the ability to download a plugin from a server. This way you could unload the MP3 player to load the Picture viewer. Of course we probably want music to accompany the pictures :-). I wrote a proof of concept MP3 player for the MVP which proved to be rather simpler than I expected. Just chucking an MP3 file at the dsp produces sounds and adding sending a second file straight after the first resulted in apparently seemless replay (e.g. two tracks from a continuous concept album).
I am frustrated at the moment because I can not compile the latest vompserver. I still use VDR 1.2.6 which the latest vompserver does not compile against. I would love to try out your code and am looking forward to being able to do so.


Quote from: MartenR on March 15, 2007, 18:57:17
QuoteChris mentioned i while ago that a problem of adding more and more media-functionality on the mvp is the limited space in the dongle/on the mvp - is this still critical?
Sure, this is still a problem, the people from mvpmc are currently at the limit and have problems to add more features.
Yes, but they also have a huge functionality built into their software. For me they do much too much on the MVP.

They have a complete UPnP client. Also what I have seen so far is that they scale the pictures on the mvp (which I would avoid as stated above).
So they have lot's of libraries and are now facing the memory limits. Now they try to make it modular too as riban proposed.

I personally don't have the needs for a full UPnP client and all the other stuff they are doing - connecting to different kind of servers (mythtv, slimserver, flac, replaytv, etc.), having a VLC client built in, sshd support, ....
A simple way to display pictures and play sound directly from a VDR server is fine with me. I have no other media servers in my network and don't plan to do so.

A lean VOMP client with customized media functionality is enough for me. So in case we limit the functionality to customized VDR-Vomp-protocol, there should not be the same issue as mvpmc is having now.

But this is for sure only my requirement, others may also want these functionalities.


Hi all,
OK - now I managed to build a dongle.
You can found all the files at

Some technical remarks:
1. thumbnails - not there until now - hmm they seem to be difficult to handle:
  - no big performance on server (VDR runs on small machines...)
  - lots of data to be transfered to the client if done there (and even perf issue)
  - maybe there is a way to extract embedded thumbnails from the JPEG (like e.g. xnview does) - would be about 6-20k per thumb
For me thumbs are not that important - I have my pictures sorted by month (and sometimes subdirs) - it would also be possible to create slide shows on the server e.g. by using links (hmm - didn't really handle softlinks well - probably they work but will get the time of the link..).
2. resources on the mvp: I tried to keep them low. I moved away from a complete buffer for the picture (jpeg lib allows for row based buffers). And I transfer the pics chunk by chunk (app. 256k each in the moment). So no real problem currently. After that I scale down during decompression (at max 8 - what jpeg lib allows) - this seems to be OK for our pics of 10MPx (Jpeg about 3.xxMBytes). - Disadvantage is that we don't have "smoother" scaling that better fits to the screen. But the needed computing power this way seem to remain nearly the same for 3MPx and 10MPx pictures (the 2 cameras we have).
From a quick look in the moment the transfer times are already at about 2s for big pics - this will be the first idea of an improvement (just put the transfer in a separate thread in parallel to decompress/draw). And here we could save time by a server based handling (I guess downscaling without real decompression would be fast). But maybe I could also find a solution for server based decompress and scale (anyway a decompressed image would still remain at > 1MB ->1s transfer...).
And the pixel drawing itself is not that fast (rest of the time) - the decompression seems to be quite fast. Maybe I will find some points to optimize this..
At the end the loading times are quite long in the moment (1-~4s) - but during a slide show this is not that big problem (from my point of view) - for navigation or rotation it's a bit annoing...

In any case I would like to get some feedback about the functions...

In the moment my major concern would be to get things integrated into CVS - otherwise it will become difficult to maintain the stuff (especially due to the changes in the surface handling - they go a little bit through many of the GUI classes).



Your download site needs authorization with username and password at the moment


after reading the thread - a lot of interesting ideas...
I will try to set up a list of things to do with prio.
Could you send me your MP3 POC - maybe this way it would be fairly easy to at least create a first very basic mp3 player - just a new media handler view, a thread for getting the data ...
I'm not that familiar with MP3 - so if somebody knows a bit about it I would be interested in infos how to pic up the current playtime we are in (at the end I guess we should have all the great functions like time display, FF, B, skip,...) .

AA - authorization - forgot to upload the new .htaccess - should work now.



Hello all,
after the interesting hints here, I just managed to also got a very basic audio player up and running.
You can find the downloads again at
Any feedback is highly welcome.

Did you already think about integrating the stuff into cvs?



Thanks, thanks, thanks.
I have just enjoyed now 2h sitting with my wide on the sofa and watching the photos from the server. No crash or similar things. Worked like a charm.

Thanks also for providing the binaries as well.
I have the C't installation and in order to use the binaries I had to update to Etch (which I wanted to do anyway). I know it's because of the new GCC version...

I have pictures of a 1M and a 10M camera. For sure the 1M pictures were rather instantly available (1,5s) and the 10M needed 4-5s.

Just 1 thing at the moment:
Would be good in the file selection view directories could be differentiated easier than at the moment.


nice to here that it works...
Do you have any suggestions how to improve the selection?
For me it works quite well - I'v got my photos orgnaized by a dir for each month (biggest has app. 850 photos).
Of course it would be helpfull to have thumbnails - but this will surely contradict the performance issue.
If anybody has some ideas how to improve selection based on the textual representation - I guess this could be implemented easily.

In the moment my prio list is like this:
1. make the audio player a little better (status display like recordings, faster stop responses,..)
2. make the audio player being "undockable" - i.e. put him in the background to be able to play music while watching photos
3. improve picture loading speed( separate thread, maybe at least prescaling on server)
4. colour mapping tunig - on my TV the colours are really shifted to red - (mainly for the OSD, not for the mpeg) - I guess this could depend on the factors when computing the colours...
n. watch mpg's
At least I gues I need some contact with Chris to discuss some of the player issues...



avvdr ... I have sent you a large email to process :)