vomp and vdr >1.7.3

[MartenR]

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?

The problem would be, that you than have to parse the data to distingish between ac3 and mpeg audio (as example). Also, if you have multiple audio tracks, it might be, that they have for certain tv stations the pes id, so the easy solution will not work every time.
A PAT PMT parser would be the best, I will try to get some information about the pat pmt and then say where the best place in the demuxer is.

Marten

P.S: It seems that the vdrdevel debian packages are in progress, I can join as soon they are released.

[dingo35]

Ok, I have just played my first TS stream, it is just a simple method, I have fixed the VPID and the APID to the known pids of my test-stream, and changed the demuxer in player.cc to DemuxerTS, and that works (although markers and jumping through the stream do not work), but there is picture and sound...

How would you suggest to change the

Code Select Expand

Demuxer*  demuxer in class Player, which for non-PES should change to

Code Select Expand

DemuxerTS* demuxer .

Would you suggest a friend class to player, playerTS? That would really be a LARGE replication of code...

[MartenR]

You do not have to change Demuxer* to DemuxerTS*, since DemuxerTS is a child of Demuxer*, just add a bool isTS to player class, and there where you need it use an "if" and a typecast to DemuxerTS* .
Test also several stations from different broadcasters, if it works without PAT/PMT.

Marten

[dingo35]

Ok, thanks, will do that!

[dingo35]

Hi Marten, hope you are enjoying this as much as I do and that you don't get bored by my questions...

I have succeeded in the typecasting stuff, I introduced a bool variable in player class called "IsPesRecording" (I'm keeping as close to VDR naming as I can).
My problem: where to set this variable?

Currently I set it in  VVideoRec::go :

Code Select Expand

void VVideoRec::go(bool resume, bool startUsingJumpPlay, ULONG jumpPlayPosition)
{
  ULONG startFrameNum;
  if (resume)
    startFrameNum = myRec->recInfo->resumePoint;
  else if (startUsingJumpPlay)
    startFrameNum = jumpPlayPosition;
  else
    startFrameNum = 0;

  Log::getInstance()->log("VVideoRec", Log::DEBUG, "Starting stream: %s at frame: %lu", myRec->getFileName(), startFrameNum);
  ULONG lengthFrames = 0;
  bool IsPesRecording;
  ULLONG lengthBytes = vdr->streamRecording(myRec->getFileName(), &lengthFrames, &IsPesRecording);
  if (lengthBytes)
  {
    player->setLengthBytes(lengthBytes);
    player->setLengthFrames(lengthFrames);
    player->setStartFrame(startFrameNum);
    player->setIsPesRecording(IsPesRecording);
    player->play();


but now the player is initialized BEFORE this boolean is SET (the first line is a log statement in player::init, the second to last reports the setting of the boolean...

Code Select Expand

11:19:19.230787 [debug]  32 HANS - HANS: IsPesRecording 18
11:19:19.233986 [debug]  32 Demuxer - Reset called
11:19:19.234510 [debug]  32 Demuxer - Flush called
11:19:19.309379 [debug]  32 VDR - RR sleep - opcode 12
11:19:19.310461 [debug]  37 VDR - Rxd a response packet, requestID=24, len=2
11:19:19.311147 [debug]  32 VDR - RR unsleep
11:19:19.311844 [debug]  32 VDR - RR sleep - opcode 12
11:19:19.312706 [debug]  37 VDR - Rxd a response packet, requestID=25, len=3
11:19:19.313623 [debug]  32 VDR - RR unsleep
11:19:19.314160 [debug]  32 VVideoRec - SM: 180 EM: 600
11:19:19.381707 [debug]  32 VDR - RR sleep - opcode 12
11:19:19.382814 [debug]  37 VDR - Rxd a response packet, requestID=26, len=4
11:19:19.383499 [debug]  32 VDR - RR unsleep
11:19:19.383994 [debug]  32 VVideoRec - Do WSS: 0
11:19:19.450397 [debug]  32 BoxStack - Locked for add
11:19:19.450921 [debug]  32 BoxStack - Unlocked for add
11:19:19.451388 [debug]  32 BoxStack - Locked for update
11:19:19.557009 [debug]  32 BoxStack - Unlocked for update
11:19:19.557554 [debug]  32 VVideoRec - Starting stream: /media/video0/According_to_Jim/komedie_-_30'/2009-04-16.18.32.8-0.rec at frame: 850
11:19:19.558287 [debug]  32 VDR - RR sleep - opcode 9
11:19:19.600081 [debug]  37 VDR - Rxd a response packet, requestID=27, len=13
11:19:19.600786 [debug]  32 VDR - RR unsleep
11:19:19.601280 [debug]  32 VDR - VDR said length is: 962228744 64464, IsPesRecording 0
11:19:19.601790 [debug]  32 Player - Player has received length bytes of 962228744
11:19:19.602277 [debug]  32 Player - Player has received length frames of 64464
11:19:19.602751 [debug]  32 Player - Player has received IsPesRecording 0
11:19:19.603227 [debug]  32 Player - LOCKED


Any suggestion on where to put the setIsPesRecording ?

[MartenR]

Insert Quote
Hi Marten, hope you are enjoying this as much as I do and that you don't get bored by my questions...

No, problem, when in my cable network in the far future  HDTV boardcast from ARD and ZDF start, I will be using vdr >1.7.5, too. So I am interested in this step, too.


Ok, it was a bad idea to put the pes information in the startstreaming method, it seems to be better to put it in the recording information, so in getRecordingsList. Then you can add an option to the init method of player or set it just before init:

Code Select Expand

VVideoRec::VVideoRec(Recording* rec)
{
  boxstack = BoxStack::getInstance();
  vdr = VDR::getInstance();
  video = Video::getInstance();
  timers = Timers::getInstance();
  vas = NULL;
  vsummary = NULL;



  videoMode = video->getMode();
  myRec = rec;

  player = new Player(Command::getInstance(), this, this);
  player->init(myrecording->IsPesRecording());

  playing = false;

code]

Marten

[dingo35]

Ok, I got it working now, it plays TS and PES streams, small PAT/PMT decoder built in. I have the following questions/problems to make it more mature for the next release:

1) in ts-mode, no fast forward, fast rewind, - 60 sec or + 60 sec works. I am not aware of changes in PTS/frame numbering, any idea why this isn't working with the DemuxerTS (which was of course designed for live TV, but did inherit its seeking functions from Demuxer, right?
EDIT With replication of a lot of code, -60sec + 60 works; BUT:
- no picture update when fast forward or fast rewind
- no update of time-counter in the display

2) in ts-mode, no marks are shown
EDIT silly me, this is not a vompserver problem; NOAD does not work (yet) on ts streams. Marks, if place by hand, are visible...
SOLVED.

3) no AC3 yet; not sure how to test that (is MVP able to play AC3 sound, it seems so if I look at the rest of the code?) Any special settings in VDR or MVP needed?

4) subtitles or telext are not processed (not sure what to do with them...)

5) not sure whether the handling with multiple audio pids is ok, are there any multipid audio channels on which to test?
EDIT: multipid audio now works, only somehow, after choosing the new language, the next time the yellow bar is still positioned on the old language. Only after moving the bar a new language is chosen.
PARTLY SOLVED

6) I only take the first program number from the PAT, it doesnt make sense to look for other program numbers since this is a vdr recording of only one channel, right?
SOLVED: seems to be ok!

7) replaying of ts-radio recordings does not work
EDIT: Also some tv recordings do not work also! ;
EDIT2: The tv-recordings were marked radio incorrectly; playing tv-recordings is solved ts-radio unsolved.

[MartenR]

First, I will answer all question in one post, which are easy to answer.

3) Works only under windows.

4) do you use the cvs version as basis (I hope so ), look into processTS the case for subID and tID are for teletext and subtitles.

5) arte would be easy german and french (some times same audio with subtitles) or euronews is also transmitted with several audio tracks, also ARD and ZDF have sometimes programme with audio-descriptions. ( Hope you get some of these channels...)

6) sounds good

7) this is handled by a different player class, I think first video should work radio would be easy in comparison to video.

Marten

[MartenR]

1) One problem might be that the "ULONG DemuxerVDR::getFrameNumFromPTS(", which is important for seeking has no equivalent in DemuxerTS, as well as setframenum, setpaketnum ... . I think seek should be fine. Also only navigation to I frames shoud be done.
So fast forward might not work if non I frames are used for navigation because for old pes recordings only i frames were indexed and B or P frames may lead to problems in the decoder in ff worward and backward.

2) weird I see no chnages int vdr which can cause this.

[dingo35]

Thanks Marten, I will look into 1-7 with the help of your answers.

On your question on 4), cvs, sorry, I wasn't aware that cvs was "alive" (please don't take that as an insult, because it says more about me than about the cvs !), since I have been using the "Yaris" versions for a long time now.

Would this not be a good moment to bring those two versions back together? I am willing to put effort into that, since I think it is silly to maintain two forks...
I can only think of two reasons to keep separate forks alive:
1) one of the forks doesn't maintain technical quality of the other
2) forks differ on opinion on needed functionality

I think both cvs and Yaris fork have proven to deliver excellent quality code, so 1) is probably not valid; and 2) can be solved easily by parametrizing functionality that not everybody wants.

@Marten & @HondansX, what do you think is necessary to put those forks back together?

[MartenR]

Well the point about the cvs should be addressed to Chris, he is the main author. (Chris can you say something about it.)
For me the cvs version was always fine, since Chris assured, when importing code, a minimum quality in code and the big changes in code, where always made in the cvs. (like change from pes live tv to ts live tv) but may be not so visible to the end user.
Also some of the changes moved from the other version to the cvs version, so for an adaption of the ts  stuff the cvs version should be used as basis. (I believe that the portions of code  you changed have more less the status of the 0.3.0 even in the yaris version, so make a diff of the changed files to 0.3.0 and then patch the cvs and everything should be fine.)

Also I understand the yaris version as a collection of possible patch against the current version, which may go into cvs. So far as I now, the was every almost every main relase an adapted yaris version, so I do not regard it as a fork. 

Marten

[hondansx]

Also I understand the yaris version as a collection of possible patch against the current version, which may go into cvs. So far as I now, the was every almost every main relase an adapted yaris version, so I do not regard it as a fork. 

Marten

Absolutly right. 
They can be found easily here: http://yaris.dyndns.org/vomp/0.3.0/Patches
As an advantage between official vompreleases, everybody has the possibilty to test newer dongles, without the need of
an dev environment.


In hope some or all patches will find a way into CVS some day.
Walter

[dingo35]

Ok, great to hear that, I already was preparing for a major rework....

The "some day" part disturbs me a bit, why are the patches not in cvs yet?

A great number of them are already tested for a _LONG_ time, so that is no excuse...

Now back to the technique: when putting a getFrameNumPTS in demuxerTS, like in demuxerVDR, I get lost in all those demuxers. They all are derived from class Demuxer.

Would it not be wise to move all getFrameNumPTS and belonging pts_map stuff to Demuxer, so all demuxers can used it? Or this unwanted, because for some demuxers this should be not available?

As you notice, object inheritance is my "learning issue", so I take great care on this..

[MartenR]

Would it not be wise to move all getFrameNumPTS and belonging pts_map stuff to Demuxer, so all demuxers can used it? Or this unwanted, because for some demuxers this should be not available?

I think the reason was that this was only used before in DemuxerVDR and now we need it also in demuxerts, but I think for demuxermedia it has little use.
Also I do not know, if you have to adapt it a bit for the demuxerts...

Marten

[dingo35]

Adapting it for demuxerts would be weird, because the pts information is contained in the pes stream...

Well the point about the cvs should be addressed to Chris, he is the main author. (Chris can you say something about it.)

With the risk of tipping on anyone's toes: cvs is two months old... which for my is ancient. Would this be a good point in time to ask Chris for cvs-access for some proven active and experienced developers in the vomp-community like Marten and/or hondans (not asking for myself, I'm not experienced enough for that)?


Is it somehow possible for the client to test on which protcol-version the vompserver is using that it is connected to? In vompserver, I have a lot of "if VDRVERSNUM" 's which check on whether we are on vdr-1.7.3 + ; if it is (compiletime), but you don't want that on the client side; since the protocol has changed (slightly), the new client should be aware of which protocol version is used by vompserver.
Second best would be to check for vompserver-version (run-time), and assume when it is >0.3.0 that new protocol is used; this then would go wrong for people using  new vompserver on < vdr-1.7.2 .....