There are some changes in vdr 1.7.3 and therefore vompserver will not compile.
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:
--- 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
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?
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
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?
I personaly want wait with the adaption until its is clear, that the recording format is fixed in the development branch.
Marten
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?
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
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!!!!
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
@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...
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!
Quote from: MartenR on April 18, 2009, 14:45:18
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).
Quote from: MartenR on April 18, 2009, 14:45:18
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!
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
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! :-)
Quote from: MartenR on April 23, 2009, 18:02:44
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?
QuoteWould 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.
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 Demuxer* demuxer in class Player, which for non-PES should change to DemuxerTS* demuxer .
Would you suggest a friend class to player, playerTS? That would really be a LARGE replication of code...
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
Ok, thanks, will do that!
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 :
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...
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 ?
QuoteInsert 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:
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
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.
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
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.
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?
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
Quote from: MartenR on April 26, 2009, 08:36:26
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 (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
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..
QuoteWould 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
Adapting it for demuxerts would be weird, because the pts information is contained in the pes stream...
Quote from: MartenR on April 26, 2009, 08:36:26
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 .....
Quotes 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 .....
This is a normal problem, if vomp version number changes, that server and client must have the same version..
Since a new protocoll is necessary for the new vdr version, you should supply the new version of the vomp protocoll also for the old vdr version.
Thus you just say on vdr<1.7, that you have only pes recoridngs and so on. This shoulöd be possible since vdr>1.7.2 have also old pes recordings.
So you have a new vomp protocoll version for old vdr and new vdr and the user have just to use the same new version on client side and server side regardless of the vdr.
We have had this protocoll changes almost every release and we did it always like this.
Marten
Ok, then I will not introduce any more hassle with protcol version numbers etc.; BUT as we are changing protocol now, would it be a good idea to introduce some new fields that are already present in VDR but are not used in vomp, like:
-preferred menu language
-preferred audio languages
-preferred subtitle languages
-timer margins (now a setup item in vompclient, but could be simply copied from VDR).
since it makes no sense to have these variables setup differently from VDR.... What do you think? And if you agree, where would be the best place in de protocol to send this data (somewhere in the "connected, loading config" part of the conversation).
P.S.: I record my progress in the original 7 point problem post, somewhere back in this thread...
Well, other fields are fine, but I think you should code them after your TS stuff works to introduce not to much sources of error.
Comments to
7) No idea, may be they boardcast in a different way, since I do not know exactly your way you treat the PAt/PMT and figure out the pids,I can only guess: PAT/PMT with options your parser cannot handle, pes ids doubled. If you can I would suggest debugging with the Windows version. (Most mpeg decoder do not like debuggers, so please a MessageBox in the code you wanted to debug, place a breakpoint afterwards. Start the programm without debugger, wait for MessageBox, attach to process, press the button and debug for a while).
1) The current time is displayed, using player->getCurrentFrameNum() (using demuxer->getFrameNumFromPTS), so you have to track down, if all members are properly set, which are used in this function, maybe no pts set (no pts_map in demuxerts compared demuxervdr). For the fastforward, check if the getnextiframe command is properly handled on server and cleint side. Is navigation working with marks?
Marten
Quote from: dingo35 on April 27, 2009, 12:22:25
Ok, then I will not introduce any more hassle with protcol version numbers etc.; BUT as we are changing protocol now, would it be a good idea to introduce some new fields that are already present in VDR but are not used in vomp, like:
-preferred menu language
-preferred audio languages
-preferred subtitle languages
-timer margins (now a setup item in vompclient, but could be simply copied from VDR).
since it makes no sense to have these variables setup differently from VDR.... What do you think? And if you agree, where would be the best place in de protocol to send this data (somewhere in the "connected, loading config" part of the conversation).
I have a headless server, so I'm not using VDR settings and/or having easy access to change the vdr values.
So whatever you want to add, please have it accessible via Vomp as well.
And only the defaults are taken from vdr settings.
For the language it may be useful in rare cases to have it differently by client. E.g. you a have an au pair women or are living in a shared flat with different students.
Best place is when loading menu languages as is today.
Quote from: muellerph on April 28, 2009, 08:09:19
I have a headless server, so I'm not using VDR settings and/or having easy access to change the vdr values.
The parameters mentioned are only setup once in VDR, they rarely change. Access is easy, even on a headless server, just bring your vdr process down and edit your setup.conf ...
But I'll leave it as it is, just wanted to propose an improvement. If it isn't percepted that way, it's useless...
Quote from: dingo35 on April 28, 2009, 09:11:29
But I'll leave it as it is, just wanted to propose an improvement. If it isn't percepted that way, it's useless...
Hello Dingo,
sorry if I was giving you the impression of harsh wordings.
Such improvements are for sure welcome, I just wanted to add my 2 cents.
Quote from: MartenR on April 28, 2009, 07:07:13
Well, other fields are fine, but I think you should code them after your TS stuff works to introduce not to much sources of error.
Comments to
7) No idea, may be they boardcast in a different way, since I do not know exactly your way you treat the PAt/PMT and figure out the pids,I can only guess: PAT/PMT with options your parser cannot handle, pes ids doubled. If you can I would suggest debugging with the Windows version. (Most mpeg decoder do not like debuggers, so please a MessageBox in the code you wanted to debug, place a breakpoint afterwards. Start the programm without debugger, wait for MessageBox, attach to process, press the button and debug for a while).
1) The current time is displayed, using player->getCurrentFrameNum() (using demuxer->getFrameNumFromPTS), so you have to track down, if all members are properly set, which are used in this function, maybe no pts set (no pts_map in demuxerts compared demuxervdr). For the fastforward, check if the getnextiframe command is properly handled on server and cleint side. Is navigation working with marks?
Marten
7) is solved, problem was in scanForVideo; now only ts-radio does not work
1) navigation with marks is working ok, ffwd works fine but no update of picture, at normal play the time counter is not updated. I'll look into getnextiframe...
I am trying to get the client to compile under windows, so that I can move to vdr-1.7.5 and not have to switch back all the time to vdr-1.7.0 because all my windows clients are incompatible; I have followed these instructions: http://forum.loggytronic.com/index.php?topic=327.0 (http://forum.loggytronic.com/index.php?topic=327.0),
but this leads to missing header files (arpa/inet.h ,features.h, sys/cdefs.h, etc.) . I copied some of these files from unix /usr/include to windows VC9 include directory, but that really doesn't feel good...
What's the easiest way to build a windows vomp client, preferable without the result needing runtime libraries?
Quote(arpa/inet.h ,features.h, sys/cdefs.h, etc.)
This seems to be linux specific stuff.
Are you still using Yaris as basis? It includes patches, which include no adaption to windows.
Use cvs as basis, there everything should be ported, if it was cvs, tell me, so that I can try to port it.
Marten
I'm still on Yaris version, will try the cvs version on windows first, to check if problem on my development environment or on Yaris version....
Thx for the pointer, Marten. Let me know when your vdr-1.7.5 version has arrived, I'll post my work so you can comment/improve on it....
Let me know when your vdr-1.7.5 version has arrived,
It is already there, but I have problems with the s2api driver and my kernel I had to resolve, so it is not really working in the moment, will take some time....
So now its done. I can now switch between 1.6 and 1.7.
So if there are still problems I can join development next weekend, if you send me a patch based on cvs, or changed files.
Marten
Hi Marten,
I am attaching my work in the form of two patches against current cvs (both server and client). The current issues are:
1) in ts-mode, no picture update when fast forward or fast rewind, no update of time-counter in the display
I have replicated a lot of code, and added modified versions of ScanForVideo and Stripaudio, but that doesn't seem to do the trick.
If this problem is solved, the code should be rescanned (I could do that) to make sure no unnecessary code is replicated, in search for the solution.
You will see this code marked by "HANS" and "Do I need this?" kind of remarks.
Also I haven't bothered to look at the best solution for DemuxerTS and DemuxerVDR, where portions of code are now replicated that should better be shared. Perhaps DemuxerTS should be made a derivative of DemuxerVDR?
2) no AC3 yet;
3) subtitles or telext are not processed yet;
4) multipid audio works partly; the screen shows correct audio-languages, only somehow, after choosing the new language, the sound disappears. Playing around with setAudioChannel, setAudioStream and setAID didn't solve the trick.
I managed to get it working on the vomp-Yaris client, but not sure whether the modifications there are wanted in cvs code...
5) replaying of ts-radio recordings does not work
Also, in the server version part of the code is my "resume" patch; this patch makes vomp compatible with the VDR resume mechanism (see the thread on vdr-portal for exact description); it uses less code, and, sorry to say, better code, than cvs version, since it uses lot of VDR-routines. So please insert the _whole_ patch in cvs, so that my work does not disappear in the next version....
Also I am glad to say I managed to setup the windows compile environment, and both cvs and patched cvs compile fine; I have not tested extensively under windows, but it seems to be ok...
1) no update of time-counter in the display
Solved, in processTS all parsepacktdetails have to be replaced with parsetsdetails.
More, to follow..
Marten
Great Marten, I am currently looking at my next hurdle to go to vdr-1.7.5 : noad is not being able to process ts-streams. I am looking to integrating noad in vdr in the form of a plugin, so it can be much more efficient.
Only problem is that H264 streams are not being processed in vdr, but only in backends (xine or vdrpau), so even a new plugin will not be able to handle HD streams...
1) no picture update when fast forward or fast rewind,
solved, stripaudio needs to be adapted for TS: (switched from static to virtual)
UINT DemuxerTS::stripAudio(UCHAR* buf, UINT len) //it has to be adapted
{
//This function strips all TS Headers and non video payload
UINT readpos=0;
UINT writepos=0;
PESPacket destpaket;
bool started=true;
while (readpos < len ) {
if (buf[readpos] != TS_SIG) {readpos++; continue;}
UINT oldreadpos=readpos;
int datalen = TS_SIZE - 4;
int pid = ( (buf[readpos+1] & 0x1F) << 8 ) | buf[readpos+2];
UCHAR payload = buf[readpos+1] & 0x40;
if (buf[readpos+3] & 0x20) { // Adaptation field is present
datalen -= (buf[readpos+4] + 1);
}
if (datalen < 0) {// Error in stream TODO log this
return 0;
}
if (datalen == 0) {// Null packet
readpos=oldreadpos+TS_SIZE;
continue;
}
readpos += (TS_SIZE - datalen);
UINT towrite=min(datalen,len-readpos);
if (pid == vID) {
if (payload) {
if (started) {
parsePacketDetails(destpaket);
memcpy(buf+writepos,destpaket.getData(),destpaket.getSize());
writepos+=destpaket.getSize();
}
destpaket.init(PESTYPE_VID0);
readpos += 6; towrite -= 6;
started=true;
}
if (started) {
if (!destpaket.write(buf+readpos,towrite)) {
parsePacketDetails(destpaket);
memcpy(buf+writepos,destpaket.getData(),destpaket.getSize());
writepos+=destpaket.getSize();
destpaket.truncate();
destpaket.write((UCHAR*)"\200\000\000", 3);
destpaket.write(buf+readpos,towrite);
}
}
}
readpos=oldreadpos+TS_SIZE;
}
parsePacketDetails(destpaket);
memcpy(buf+writepos,destpaket.getData(),destpaket.getSize());
writepos+=destpaket.getSize();
return writepos;
} This should be enough for today...
QuoteI am looking to integrating noad in vdr in the form of a plugin, so it can be much more efficient.
Using noad as a plugin, introduces the risk, that a crash of noad affects the whole vdr.
QuoteOnly problem is that H264 streams are not being processed in vdr, but only in backends (xine or vdrpau), so even a new plugin will not be able to handle HD streams...
Noad never used the decoders of vdr for the analysation, it has in fact inbuild code, that partly analyses and decodes audio and video, so that a detection is possible. For h264 I think a complete rewrite willl be necessary.
Marten
Great work, Marten!
Quote from: MartenR on May 09, 2009, 18:37:00
Using noad as a plugin, introduces the risk, that a crash of noad affects the whole vdr.
That's true, but:
1) analyzing my system, noad has crashed (=segfaulted) on my system exactly 0 times the last month
2) using VDR's routines greatly diminishes further chances of crashing of noad
Perhaps detection of H264 streams is not that difficult, there is also some kind of "independent frame" there, that vdr can identify....
Quote2) no AC3 yet;
3) subtitles or telext are not processed yet;
4) multipid audio works partly; the screen shows correct audio-languages, only somehow, after choosing the new language, the sound disappears. Playing around with setAudioChannel, setAudioStream and setAID didn't solve the trick.
I managed to get it working on the vomp-Yaris client, but not sure whether the modifications there are wanted in cvs code...
Also solved, now the solution affected many files, so I will post a final patch after the last issues are solved.
I just needed to use the methods in case of a TS recording used before for live TV, thus I just changed the PAT/PMT code to supply a Channel object describing the current pids and pass them to the audioselector and copy the live tv audio selector code to the player object.
Next weekend I will be away, thus the weekend after the next weekend I will solve the last issues and hopefully supply a final patch.
Marten
Ok, great!
And here are the patches against current cvs, based on dingo35 patch.
I needed to rewrite some code in demuxerts to solve all issues.
Server side mainly the same as dingos but a compiler issue with 1.6 was solved.
I have to admit that teletext and dvb subtitles are untested due to a lack of transimission including subtitles, but they should work somehow...
All testing was done on windows, but this was all on abstract code, so it should run on mvp as well.
Enjoy, I will send it to Chris for cvs inclusion.
Marten
Hi,
many thanks to dingo35 and MartenR for their work, that vomp dev goes further......
Walter
Good work guys! How do we get it included into a Yaris version?
Quote from: MartenR on May 21, 2009, 11:15:36
And here are the patches against current cvs, based on dingo35 patch.
I needed to rewrite some code in demuxerts to solve all issues.
Server side mainly the same as dingos but a compiler issue with 1.6 was solved.
I have to admit that teletext and dvb subtitles are untested due to a lack of transimission including subtitles, but they should work somehow...
All testing was done on windows, but this was all on abstract code, so it should run on mvp as well.
Enjoy, I will send it to Chris for cvs inclusion.
Marten
Hi,
on the clientside it fails with:
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o player.o player.cc
player.cc: In member function `int Player::init(bool)':
player.cc:73: warning: declaration of 'isPesRecording' shadows a member of 'this'
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o playerradio.o playerradio.cc
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o vfeed.o vfeed.cc
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o afeed.o afeed.cc
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o demuxer.o demuxer.cc
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o demuxervdr.o demuxervdr.cc
/usr/local/src/vomp/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Wshadow -D_GNU_SOURCE -I../jpeg/jpeg-6b -c -o demuxerts.o demuxerts.cc
demuxerts.cc: In member function `virtual int DemuxerTS::findPTS(UCHAR*, int, ULLONG*)':
demuxerts.cc:194: warning: converting to non-pointer type `int' from NULL
demuxerts.cc:194: warning: unused variable 'pos'
demuxerts.cc:202: warning: unused variable 'framelength'
demuxerts.cc: In member function `int DemuxerTS::processTS(UCHAR*)':
demuxerts.cc:363: warning: converting to non-pointer type `int' from NULL
demuxerts.cc:449: warning: comparison between signed and unsigned integer expressions
demuxerts.cc:450: warning: comparison between signed and unsigned integer expressions
demuxerts.cc:454: error: name lookup of `i' changed for new ISO `for' scoping
demuxerts.cc:449: error: using obsolete binding at `i'
demuxerts.cc:454: warning: comparison between signed and unsigned integer expressions
demuxerts.cc:455: warning: comparison between signed and unsigned integer expressions
demuxerts.cc: In static member function `static bool DemuxerTS::scanForVideo(UCHAR*, UINT)':
demuxerts.cc:746: warning: unused variable 'pos'
On serverside with vdr-1.7.2
g++ -O3 -Wall -pipe -fomit-frame-pointer -march=core2 -msse4.1 -fPIC -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vompserver"' -DVOMPSERVER -I/usr/local/src/dvb/DVB/linux/include -I../../../include -I/usr/local/src/dvb/DVB/linux/include -o vompclientrrproc.o vompclientrrproc.c
vompclientrrproc.c: In member function 'int VompClientRRProc::processStartStreamingRecording()':
vompclientrrproc.c:1128: error: 'class cRecording' has no member named 'IsPesRecording'
make: *** [vompclientrrproc.o] Fehler 1
Any Ideas?
Thanks,
Walter
Hmm,
first I hate, the fact, that every compiler interprets c/c++ in a different way.
On the client side, it seems that gcc interprets declaration different then msvc++.
Remove the
"int" in
for(int i
and put a line before for statemaent into the code:
int i;
For the serverside, here is a updated patch attached. (Btw, it seems, that you are compiling against 1.6 or <1.7.3,, so no need for the patches?)
Marten
The patch was nonsense, it has to be true....
Marten
That did it! :)
Many thanks,
Walter
Do these patches apply to current cvs because I'm getting an undefined symbol error when I come to make plugins in my vdr source directory?
Just a wild stab but has it got anything to do with bool ResumeIDLock? Comparing newserverpatch2 patch with the Yaris 07_rec_resume_vdr patch, this bool is declared as extern in vompclientrrproc.h and declared again in vompclientrrproc.c, yet in Yaris it is declared as static in vompclientrrproc.h only.
My C coding skills aren't that strong. Please could anyone comment on this?
Stu-e
No, the extern declaration in vompclientrrproc.h and redeclaration in vompclientrrproc.c is correct; the static declaration in the Yaris_rec_resume_vdr patch caused an undefined symbol error.
Perhaps a make clean-plugins; make plugins solves the problem? Check in your PLUGINS/lib directory whether the new *vompserver*so file is actually built there.
The symbol error actually occurred when I ran vdr:
vdr: ./PLUGINS/lib/libvdr-vompserver.so.1.7.7: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
I tried a fresh cvs download, applied newserverpatch2.patch and got the same error.
make clean-plugins;make plugins did not help either.
The vompserver lib is in the PLUGINS/lib directory as it says in the error message.
Googling the symbol gives reports of the same error with streamdev plugin, but I was not able to get any more detail than that.
I'm using gcc 4.3.2 and an unpatched vdr 1.7.7
Stu-e
This points to cIndexFile::Get ; you could check whether this routine has changed in vdr-1.7.7; try compiling vdr-1.7.5, and/or compare source code changes...
Same error with vdr-1.7.5:
vdr: ./PLUGINS/lib/libvdr-vompserver.so.1.7.5: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
Stu-e
I got it working after simply renaming Make.config.template to Make.config in the vdr source directory.
This was suggested by Thomas Gunther on the vdr mailing list. He quoted a bit of vdr history that perhaps the Vompserver plugin's authors should take note of:
From HISTORY of VDR-1.7.4:
- Added "DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE"
to Make.config.template (thanks to Johann Friedrichs for pointing this out).
Plugin authors should add this line to their Makefile or Make.config if they use
file access functions that need special versions for 64 bit offsets.
I'm really grateful for the work you put in getting support for >vdr-1.7.3.
Many thanks
dingo35, Marten, thanks for your efforts on the VDR 1.7 development patches, good work!
As for the Yaris version, thanks once again to Walter for all your work. I do think we can sort something out about getting the two versions closer together.
I am going to make a release of the code as it stands soon, just to attempt to draw a line in the sand and have a new base to work from.
stu-e: I have added that to the server Makefile, thanks for pointing it out.