Topics

Hi,
attached is an executable with scraper support and vector based osd. (see http://forum.loggytronic.com/index.php?topic=753.0)
The legacy version has the old osd and should run also on XP, the improved version needs at least vista with plattform update.

Marten

Hi,
for all which are interested. I am currently working on adding tvscraper support and an enhanced ui experience to vomp.
For all who are interested in an early test, the stuff is in git for client and server under the branch scraper_support.

So far recording are ready.

Currently, only raspberry pi is targeted, later I will also rewrite the windows osd handling to also support it.

Marten

Just a warning the current firmware in raspbian breaks the playback of a lot of 1080i h264 channels and recordings.
So do not update, it you need to playback these files!
(See http://www.raspberrypi.org/phpBB3/viewtopic.php?f=35&t=21832&p=208820#p208820)

Marten

In order to be able to support more audio formats, I had to change the server side protocoll (changes are backward compatible to clients build using the old protocoll).
Apply the patch on the server side, in order to use vompclient for raspberry pi.

Marten

The current libcec in raspbian does not support hdmi cec for raspberry pi.
Attached are custom build debian packages, that you can install to have libcec support for the hdmi port of your raspberry pi.

Marten

Hi,
this is a series of polls, I will use to determine certain choices for raspberry pi porting.
I only use the poll only as recommendation.

So here is my first question, what Graphics subsystem should I use.
So far, I used a simple OpenGL system, which might be used later to get a 3D GUI.
I chose it because it seems it would be ideal for software decoding using shaders,
but  giving the current implementation the reason why I choose it do not exist.
In the moment, it is relatively slow and unaccelerated, so next steps for it require to make it accelerated.

The good thing about the pi is that several graphics layer exists and I can choose a different OSD rendering system then for video decoding.

So there exist two other options:
1) Dispmanx the native rendering system of the chip. It is capable of doing exactly the same amount of hardware accelaration, that the mediamvp did. So handling surfaces, but no accelarated drawing.
2) OpenVG, a very nice interface for handling vector accelerated drawing of lines and surfaces. Advantage, it is possible to run it on a higher resolution then the window system.
Making a HD OSD at different resolutions possible, without the need to implement for every resolution a new interface.

So I await your comments.

Marten

Hi,
maybe you have recognized, that vomp has now HDTV support in current cvs, this is mainly for windows in the moment. (Thanks to Carsten for testing).
I am searching for volunteers, who will test this HDTV feature on their machines using special vomp test builds I will provide the next days in this threads.
I need this to guarantee compatibility with a broad range of decoders and graphicscards.
So far recordings work and live TV may work.

A new vompserver is needed, which is incompatible with older versions.

Marten

Hallo,
after being almost done with hdtv recordings playback in the windows client. I need to find a way to simulate HDTV livetv. Does anyone here know a way to record a whole DVB transponder and to reinsert it into vdr in order to simulate a DVB hdtv boardcast?

Marten

Hi,
I am currently working on hdtv support in vomp. Unfortunetely, I am for the next time far away from my vdr and any DVB reception. But I have some sort of development setup inside a colinux for vomp.

But anyway I have at the moment on h264 recordings.
So I would like to ask my users, if someone can provide me with recordings in DVB HDTV for testing with:
* Only few minutes (50 MB -100 MB) in size
* Only the new ts recording format
* Prefered in german or english with anonying content, I will watch this files several hundred times.
* files transfer over megaupload or similar site... over PM.

It would be nice if someone can help me.

If someone wonders, when this will be finished, actually I do not know: I have to modify parts of the general vomp part and for the windows part, the composition mechanism has to be changed including support for the EVR and for additional directshow codecs.


Marten

Hi,
I have recognized that some newer PowerDVD versions under vista lack support for the VMR9, I will therefore add in the future support for VMR10.
But in the moment some PowerDVD version might not work under vista.

Marten

[Direct Show tasks]

Hi,
I want to outline in this topic, my todo list for the windows client, so that you can see in which direction the journey goes. (Excluded are of course changes to the common code, only changes to the windows specifics).

Direct Show tasks
As you might have already noticed, Vomp for windows is really slow, if you navigate inside a recording, if you do a fast forward etc. . This is because Vomp for Windows destroys and recreates all direct show filters at each state change.
I did this, because little errors in my implementation and compatibility issues will be catched up by recreating the objects, so it was for me a safe way to get not to many bug reports, while vomp for windows is in the wild for (alpha, beta) testing.
Of course this should be changed, but I will remove the recreation now stepwise, for each version that is published one recreation will be removed:

• First (version>=0.2.9) the recreation on fast forward will be removed.
• Second (version >=0.2.8 ) the recreation for navigation inside a recording something (like restart at) will be removed
• Third (version >=0.2.9)  you will be able to select your audio and video filter from a list

Settings

• Settings for the VMR9, like deinterlacing,brightness, contrast, hue, and saturation.
• Filtering setting, like nearest neighbor, linear or better
• Overscan, Aspect ratio correction for non 16:9 and 4:3 displays
• Adjusting audio output, SPDIF etc.
• Remember window settings, like fullscreen or always on top.
• Make some keyboard commands customizable (may affect mediamvp as well)(>0.2.7

GUI

• Add a palette to simulate remote control button with mouse interaction ?
• Add a icon ?

So that is it, features that will appear in 0.2.6 are excluded. However this list is subject to change without notice, as all guesses into the future.

Marten

Hi,
I have added a how to the vdr wiki, how to know which MPEG2 decoder filter is used or if a compatible filter is properly installed. All users with no video playback should read it and try it and post the results here. (To get a good compatibility list also a report of users with working video should post will be of high use)

http://www.linuxtv.org/vdrwiki/index.php/How_to_determine%2Cwhich_MPEG2-Decoder_Vomp_for_Windows_uses_or_if_I_have_an_compatible_MPEG2_decoder_filter_installed

First I wanted to put it here, but the forum refuses to post upload my pictures.

Marten

Hallo,
I just want to report, that the changes in the client fixed the 10 MBit issue for me (at least for 5 minutes), the patch in tcp.c on server side is not necessary any more.
If the problem returns after longer test, I will report this.

Thanks,

Marten

Hallo!
I want to report  the I have also the so called 10Mbit Problem. That means I can display the menu but playing recordings or live TV will not play or only play a few seconds and then I have a channel unavailable message...

My vdr server is on a combined 100MBit Switch and Router which is connected which a second 100 MBit Switch is connected with the mvps. This switch connects only with 10 MBit with the mvps, I don't know why.
So you see I have  the same setup and symptoms like the other people reporting this problem.

But I want to inform you about an interesting footnote, which may leads Chris faster to a solution of the problem.
I think you all know the mediamvp plugin for vdr by Dominic Morris. At the begining (with the same setup) I had a problem that a lot of recordings (those with higher bitrate more often than others) freezes all 20-30 seconds.

The solution was a modification of the sendbuffer of the video stream socket of the mediamvp plugin to a smaller value of 2000, which Dominic Morris changed after my request.
I suspect that not the tcp window size of the connection should be changed, the send buffer size should be changed.
@Chris, look at the mediamvp plugin  code into the file stream.c in the mvp directory, the #define WRITEBUFSIZE is the value, I'm talking about and the relevant code is in the stream_accept function.

I don't know if this is the solution of the problem, because I yet don't know enough about the code to change the buffer size myself (maybe this will change), but I hope this would push the quest for a solution into the right direction.

Marten