Messages

I think vomp is working correctly, but there TV manufactures, who think that normal 4:3 should be stretched to 16:9 (most costumers don't want black bars) and they only zoom up letterboxed material (my neighbors tv behaves likes this).

Marten

Indeed there is an effort to create a Windows version. But it is MartenR who is doing that. I am just slowly editing things to make porting vomp possible. As with anything there are no guarantees... Marten, could you comment on how well you think it is going? And what you think the probability of success is?

Well, if just ported the gui and the remote control and the gui works relatively well at the moment, the complete OSD stuff  with Direct3D9 works well.

But this is not the hardest tasks, the hardest task will be the integration with DirectShow and their especially the synching and the real time clock and handling stop pause and fast forward.
At the moment I think  the probability will be 60%, that it will work.
But we just at the begging and as Chris wrote there are no guarantees.

Also I think that it will take a lot of time, that I' ll have finished the porting.

Marten

Well, just ignore too big changes in the jumping PTS.  Look on sourceforge at Project guliverkli, then in subversion at file
/trunk/guliverkli/src/filters/parser/basesplitter/BaseSplitter.cpp

Function CBaseSplitterOutputPin::DeliverPacket, it is from a windows demuxer, who can also handle DVB TS Streams. You see if the change between to PTS of two  successive PES Packets is too big, it  just subtracts these Jump in the PTS.  REFERENCE_TIME is  pts*10000/90, see /trunk/guliverkli/src/filters/parser/basesplitter/BaseSplitterFileEx.cpp function Read .

In this way playback of transport streams is synchronized, maybe you get a timecode from this. Maybe you can store also for every second  or every  I-frame  (I think one second accuracy or per I frame is enough for the progress bar) the pts together with the framenumber from cIndex and than if you get the pts from the hardware look into the array, which framenumber it is.

The pts and dts on DVB transmission are on most channels not continous. All DVB player application look with there is a big jump in the dts pts and, if there is a big jump, they correct the PTS and DTS appropriate.
This is why vdr uses internally the frame number in the cIndex class for calculating the current timestamp.
Why didn't you use for getting the length of the recording at the server side a call to cIndex member function last, which returns the total frame number and divide it by 25 (PAL) or 30 (NTSC) to get the totallength in seconds.


Marten

Maybe the vomp client code can be encapsulated into a DirectShow filter, which pushes the video data to mpeg decoder filter, which every software dvd player installs on your system...

Just a little idea... I had already before for streamdev VTP protocoll...


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

Thanks, JMFR I have added these lines into the constructor and now it works for me, too. Up to now no more problems.

Marten

Hallo,
are you sure that line 38 is right, my editor displays the line 38 in constructor destructor, Nevertheless I added the two lines in connectto after the first return 0;
And the 10MBit-Problem is still present.
But I think your Idea to do similar things in the mvp is not a bad idea.

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