vomp and vdr >1.7.3

[hondansx]

There are some changes in vdr 1.7.3 and therefore vompserver will not compile.

Code: [Select]

recplayer.c: In member function ‘ULLONG RecPlayer::positionFromFrameNumber(ULONG)’:
recplayer.c:201: error: no matching function for call to ‘cIndexFile::Get(int, uchar*, int*, uchar*, int*)’
../../../include/vdr/recording.h:240: note: candidates are: bool cIndexFile::Get(int, uint16_t*, off_t*, bool*, int*)
../../../include/vdr/recording.h:242: note:                 int cIndexFile::Get(uint16_t, off_t)
recplayer.c: In member function ‘bool RecPlayer::getNextIFrame(ULONG, ULONG, ULLONG*, ULONG*, ULONG*)’:
recplayer.c:249: error: no matching function for call to ‘cIndexFile::GetNextIFrame(ULONG&, bool, uchar*, int*, int*)’
../../../include/vdr/recording.h:241: note: candidates are: int cIndexFile::GetNextIFrame(int, bool, uint16_t*, off_t*, int*, bool)

I made this changes and now it compiles:

Code: [Select]

--- vdr-1.7.2/PLUGINS/src/vompserver/recplayer.c        2008-03-26 15:59:47.000000000 +0100
+++ vdr-1.7.3/PLUGINS/src/vompserver/recplayer.c        2009-01-26 23:30:25.000000000 +0100
@@ -193,12 +193,12 @@
 {
   if (!indexFile) return 0;

-  uchar retFileNumber;
-  int retFileOffset;
-  uchar retPicType;
+  uint16_t retFileNumber;
+  off_t retFileOffset;
+  bool retIndependent;
   int retLength;

-  if (!indexFile->Get((int)frameNumber, &retFileNumber, &retFileOffset, &retPicType, &retLength))
+  if (!indexFile->Get((int)frameNumber, &retFileNumber, &retFileOffset, &retIndependent, &retLength))
   {
     return 0;
   }
@@ -240,8 +240,8 @@

   if (!indexFile) return false;

-  uchar waste1;
-  int waste2;
+  uint16_t waste1;
+  off_t waste2;

   int iframeLength;
   int indexReturnFrameNumber;

But for some reason, while playing a recording, the length is not shown correctly. 
Any help would be appreciated?

Bye,
Walter

[davep]

I haven't tried VDR 1.7.x yet, but the release notes for 1.7.3 mention that the structure of the index file has changed (to support larger files and more files per recording). Maybe VOMP's interpretation of the information is now wrong?

[MartenR]

With VDR 1.7.3 the format of recordings is changed to TS stream, therefore I expect vomp to not run at all and that massive changes are necesssary on the client.

Marten

[morfsta]

Well, a lot of things do work when it compiles with your patch - but FF doesn't (skip does) on old PES recordings. TS recordings don't play back at all - just get a "Error in Recording" message. Live TV works okay. It would be great if VOMP supported the new and upcoming development versions of VDR - is implementing TS streaming going to involve a lot of work?

[MartenR]

I personaly want wait with the adaption until its is clear, that the recording format is fixed in the development branch.



Marten

[dingo35]

Now, with vdr-1.7.5, Klaus has taken out the "TS-format can be changed" message; as cautious as he is, I think we can use it as a signal to start supporting vdr-1.7.5 ...

I have both server and client development environment, at the moment I am looking at the faulty Indexfile::Get and GetNextFrame functions, which give wrong timestamps when replaying an oldfashioned .vdr recording, and also make rewind and fast forward impossible.

The replaying of the TS functions is another cup of tea. Marten, or anyone else?

[MartenR]

Well, in the moment I have no vdr 1.7.x running, normally I am waiting until in etobis debian repository is at least a vdr-devel package ready. This is because I use my productive system for developing and I do not want to get into trouble with my family. (And I have DVB-T and cable thus no HDTV and thus minor motivation for implemntation in the moment)

But if you want to try to adapt it to vdr 1.7.x, I might be able to push you in the right direction. The TS implementation is not as hard as it sounds. Because vomp uses already a TS demuxer for live tv, so the "only" thing is:
1) To add to the recordings network command, information if it is a TS recording.
2) Use this information in the player for recordings to use the right demuxer (PES or TS)
3) Obtain pid information about the TS stream, I do not know if vdr provides commands for this or if we add to scan the TS for a table with pid information.

This is the rough sketch, if you want to try I can provide you if more details.


Marten

[dingo35]

Marten, you are a very wise man, not to get into trouble with your family :-) .

I have the same situation as yours, development on my productionn system, but I am able to switch very quickly between 1.7.0 and 1.7.5 on my production system, so this should be workable.

I would very much like to try to adapt vomp to vdr - 1.7.3 + , and I understand your rough sketch competely. I have experience with "scanning through vdr-source-code" to see which functions it provides, so that integration of vdr with its plugins is "optimal".

So if you can provide more details, please do...

PS I have attached a patch with which vompserver plays old PES recordings correctly, also length is ok now, marks are loaded correctly. NOTE THAT NEW TS RECORDINGS WILL NOT PLAY!!!!

[MartenR]

Ok, then I post the first details.
I will do it step by step, thus I will point you to the specific files and if it works or if you need more information.

First Step:
Modify vompclientrrproc.c:
I think processStartStreamingRecording needs to send additional  information about:
1) Type of recording
2) If TS, also the pids. You can do it like in processGetChannelPids().
But this can only be done, if the pids do not change, while replaying one single recording,(less work to do). if they do change this part of information should be submitted in every processGetBlock() (less work to do).  or if the pids can be obtained from the TS stream, they can be extracted in the demuxer (more work to do).

Maybe also a field, if it is an HDTV transmission to prevent vomp from playback or later under windws or other devices alllow HDTV playback....

Then you can do the same oin the client side in vdr.cc . Depending on your choices we can proceed with the player object.

Marten

 

[davep]

@dingo35:
There is a thread running on the VDR mailing list about modifying the vompserver for the latest VDR version, and a patch has been posted which is similar to, but not quite the same as yours.

http://toms-cafe.de/vdr/download/vompserver-0.3.0-1.7.3.diff

Maybe you guys should be talking...

[dingo35]

Thanks, I missed that thread... but ashame, ashame, the patch does not cover the main topic, the replay of TS recordings.

The patch is in fact a subset of mine, it only compiles against 1.7.5, but does not solve runtime PES problems (which are covered by my patch). I have no account on the mailinglist, so if anyone can point them to this thread...

@Marten, thanks, I'll dive into it!

[dingo35]

First Step:
Modify vompclientrrproc.c:
I think processStartStreamingRecording needs to send additional  information about:
1) Type of recording

Done (but of course that was easy).

2) If TS, also the pids. You can do it like in processGetChannelPids().

But this can only be done, if the pids do not change, while replaying one single recording,(less work to do). if they do change this part of information should be submitted in every processGetBlock() (less work to do).  or if the pids can be obtained from the TS stream, they can be extracted in the demuxer (more work to do).

I think I would go with the simplest option first... which would be to get the pids on the server side and send them to the client.

I have a problem extracting the pid's from the recording; I would like to use the patPmtParser functions of VDR (just like in the PlayTs function), but they reside within the device-class; I can't figure out how to bridge the gap between the recording and the device ... anybody any idea?

I have adapted the file-open functions, so the new ts-file naming of vdr is now complete. The HDTV flag probably should be like bool IsMpeg4 , and could be derived like in cPatFilter::Process .

To retrieve pids and MPEG4 flag, I would have to read the recording already in processStartStreamingRecording. Is there any function already suited to do this in vomp, or should I write my own fopen?

Thanks!

[MartenR]

I look into the code unfortunetely the information is not in the recordings objects of vdr. I think in this case you have to add the PAT PMT parser functionality of VDR to the demuxer of vomp ciient., since it seems, that the pids can change during the recording.
(sorry for the bad news.)

Marten

[morfsta]

Just a word of encouragement, good work dingo! Lack of TS support in vomp is the only reason why I can't upgrade my HDTV VDR to a later version, so I'm hoping that you're successful! :-)

[dingo35]

I look into the code unfortunetely the information is not in the recordings objects of vdr. I think in this case you have to add the PAT PMT parser functionality of VDR to the demuxer of vomp ciient., since it seems, that the pids can change during the recording.
(sorry for the bad news.)

Marten

In the last day I already grew accustomed to the idea that I would have to adapt the demuxer. Then we will also do the detection of MPEG4 there.

That means that in the next hour I will have completed your first "task", Marten, can you give me the next pointer?

Would it not be sufficient to strip off the 4 bytes of the TS header and the adaptation field, thus remaining the PES packet incl. header, at some smart point in the code, since vdr probably only records the relevant pids in the ts-stream? If so, what would be that smart point?