Hi Klaus,
I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still present in version 1.7.3 but the behaviour is worst because it segfaults.
First I found out that 2 lines where added in the ParsePmt method.
Data += Data[0] + 1; // this is the first packet
Length -= Data[0] + 1;
At the moment I don't know exactly what is the meaning of this 2 operations. The second line can result in a negative Length which is the reason of the segfault. Could you kindly explain the offset drift? In a single section PMT (99.9% of the time) Data[0] is always equal to 0 and we skip the first byte. Length is reduced by 1. I a multiple section stream Data[0] can be above 188. Trying to skip more than a section is not possible in the actual context.
I have done a quick and dirty hack to prevent the segfault:
--- remux.c_ori 2009-01-16 21:05:46.000000000 +0100 +++ remux.c 2009-01-17 13:34:17.000000000 +0100 @@ -361,6 +361,7 @@ if (pmtSize == 0) { Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1; + if ( Length < 0 ) Length = 0; if (SectionLength(Data, Length) > Length) { if (Length <= int(sizeof(pmt))) { memcpy(pmt, Data, Length);
the second step will be to have the parsing of multiple section allowed. At the moment when the data size exceed the section size (max 4096), PMT cannot be parsed.
[2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: PMT section length too big (4176 byte)! [2222] ERROR: can't parse PMT
Regards,
Alex
Hi,
On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote
I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still present in version 1.7.3 but the behaviour is worst because it segfaults.
First I found out that 2 lines where added in the ParsePmt method.
Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1;At the moment I don't know exactly what is the meaning of this 2 operations.
These lines are for handling the SI pointer field. Data[0] is the pointer field, which contains the byte offset to the actual data (usually 0). "+ 1" for the pointer field itself.
The order of the two statements need to be reversed. First fix the length, then the data pointer:
Length -= Data[0] + 1; Data += Data[0] + 1;
Cheers, Frank
I have already tested the inversion. Reducing the length and after moving to the new offset. This change does not solve the issue. The Length variable can still decrease to a negative value.
What happen when the byte offset is greater than 188?
On Mon, 19 Jan 2009 11:20:45 +0100, Alexw wrote
I have already tested the inversion. Reducing the length and after moving to the new offset. This change does not solve the issue. The Length variable can still decrease to a negative value.
What happen when the byte offset is greater than 188?
Then the packet was broken and shouldn't have been processed at all. By definition the pointer field is the number of bytes to skip in *this* TS packet. As the pointer field is not covered by a CRC check, it could be wrong. So you're right, it should be checked. Note that this does not only affect cRemux::ParsePmt() but also cRemux::ParsePat().
Regards, Frank
Yes Frank you are right. The problem is coming from bad CRC in the PMT (and the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails, bad PMT data should be skipped.
@Klaus: will you look at this enhancement before rolling out 1.7.4?
On Mon, 19 Jan 2009 13:32:07 +0100, Alexw wrote
Yes Frank you are right. The problem is coming from bad CRC in the PMT (and the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails, bad PMT data should be skipped.
Bad CRC is caught by CheckCRCAndParse(). What I had in mind is a wrong value in the pointer field itself (e.g. due to bad weather conditions). In ParsePat() something like
if (Data[0] + 1 >= Length) return;
should be sufficient. The same check is fine for ParsePmt(), but I'd additionally suggest to pass the TS PUSI field as third parameter. Otherwise it would not be possible to distinguish the first fragment from fragments following a broken one.
if (PUSI) // this is the first packet if (Data[0] + 1 >= Length) return; ... else if (pmtSize == 0) // fragment of broken packet - ignore return; else // this is a following packet, so we add it to the pmt storage ...
Cheers, Frank
Hi,
I did check the TS stream with dvbsnoop and it is not containing corrupted TS packets.
Apparently VDR is able to parse the PMT the first time the data buffer is used. Then, it seems to loose the sync inside the payload.
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
http://alexw.org.lu/upload/pmt.pid.132.ts
Regards,
Alex
I did check the TS stream with dvbsnoop and it is not containing corrupted TS packets.
Apparently VDR is able to parse the PMT the first time the data buffer is used. Then, it seems to loose the sync inside the payload.
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
Could this patch help with vdr-1.7.3?
http://article.gmane.org/gmane.linux.vdr/39097
Mika
Hi Mika,
I have already applied the mentioned patch ;-) But unfortunately it does not solve the issue.
Cheers,
Alex
On 20.01.2009 16:01, Frank Schmirler wrote:
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file).
Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example.
So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found...
Klaus
On Dienstag, 20. Januar 2009, Klaus Schmidinger wrote:
VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file).
Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example.
So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found...
How about just using the original PMT pid?
Matthias
On Tue, Jan 20, 2009 at 04:11:17PM +0100, Klaus Schmidinger wrote:
On 20.01.2009 16:01, Frank Schmirler wrote:
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file).
Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example.
I confirm, we ran into this special situation.
So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found...
Too difficult because a low repetition rate PID can be ommitted by the collector. (DTD pid for example)
Why not taking the real PMT pid to create the pseudo PID for the PAT? At the moment I do not really understand why this mechanism is needed in transfer mode.
Alex
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger wrote:
On 20.01.2009 16:01, Frank Schmirler wrote:
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file).
Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example.
So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found...
Hm - why don't you use the PID of the original PMT?
CU Oliver
On 20.01.2009 22:18, Oliver Endriss wrote:
Klaus Schmidinger wrote:
On 20.01.2009 16:01, Frank Schmirler wrote:
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file).
Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example.
So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found...
Hm - why don't you use the PID of the original PMT?
Because I don't have it ;-) It would be yet another parameter that needs to be stored in the channels.conf.
I'll do it the way I mentioned, just need to give the cPatPmtGenerator the channel in the constructor so that it can choose a PMT pid that is different than any of the channel's other pids.
Klaus
Hi. I've just made the switch to S2API and vdr-1.7.4 and it seems to work quite well both with xineliboutput (with vdpau) and streamdev now. The thing I'm missing is teletext subtitles and I don't know how hard it would be to update it for ts. Has anyone started on this? What countries other than Sweden and Finland use teletext subtitles frequently? I understand that it is not one of your (Klaus) top priorities, but do you have access to any channels that use it? Otherwise it's probably even lower on the priorities list. One feature request for VDR: a setup option to record all pids, including all audio and teletext pids. That way I guess it would be easier to develop a plugin for it (and I'd be happy to send you some recordings). /Magnus H
On 26.02.2009 12:08, Magnus Hörlin wrote:
Hi. I've just made the switch to S2API and vdr-1.7.4 and it seems to work quite well both with xineliboutput (with vdpau) and streamdev now. The thing I'm missing is teletext subtitles and I don't know how hard it would be to update it for ts. Has anyone started on this? What countries other than Sweden and Finland use teletext subtitles frequently? I understand that it is not one of your (Klaus) top priorities, but do you have access to any channels that use it? Otherwise it's probably even lower on the priorities list.
I believe the German ZDF channel broadcasts both ttxt and DVB subtitles.
One feature request for VDR: a setup option to record all pids, including all audio and teletext pids. That way I guess it would be easier to develop a plugin for it (and I'd be happy to send you some recordings).
It already records all audio pids. I wouldn't want to record the ttxt pid just because of a few bytes for subtitles. Here's a copy of a message I just sent to Rolf Ahrenberg privately, after he sent me a suggested patch to record the ttxt pid:
---------------------------------------------------------------------- ...teletext subtitles are a thing from the past, the normal way of broadcasting subtitles should be DVB subtitles. I hardly think a DVD player would be able to handle teletext subtitles (or am I wrong here?).
I would prefer a solution where the teletext subtitles are converted into DVB subtitles during recording (and also during live viewing). Then the rest of VDR would only have to handle one single subtitle format.
I suggest you first write a class that accepts a teletext TS data stream and outputs a DVB subtitle TS stream. Then we can see how this can be inserted into the recording chain and during live viewing. Something like
class cTtxtToDvbSubtitles { ... public: cTtxtToDvbSubtitles(int Page); // the teletext page containing the subtitles void PutTtxtTs(uchar *Data, int Length); // put a single TS packet of ttxt data // into the converter uchar *GetDvbTs(int &Length); // get one or more TS packets containing a complete // DVB subtitle page ... };
What we also need is a way of detecting whether there are any ttxt subtitles, and on which page they are broadcast (haven't looked into the DVB standard about this yet, but I believe every broadcaster uses a different page).
Once we have these facilities, this could well go into the core VDR. ----------------------------------------------------------------------
Klaus
On 28.02.2009 11:42, Klaus Schmidinger wrote:
What we also need is a way of detecting whether there are any ttxt subtitles, and on which page they are broadcast (haven't looked into the DVB standard about this yet, but I believe every broadcaster uses a different page).
The teletext standard defines a teletext subtitle flag that any subtitle page should have set. Specifically, its the C6 flag, placed at byte 11 bit 8 of line 0 of the teletext page. (see cTxtReceiver::DecodeTXT of OSDTeletext on how to get that flag.)
However, I don't know how consequently this flag is used. The C5 (Newsflash) flag also sets a transparent background, and could be used alternatively. Other transparent pages could also falsely set the C6 flag. It also may be a good idea to interpret different teletext pages as different subtitles, in case a channel has more than one subtitle page.
Cheers,
Udo
En/na Klaus Schmidinger ha escrit:
...teletext subtitles are a thing from the past, the normal way of broadcasting subtitles should be DVB subtitles. I hardly think a DVD player would be able to handle teletext subtitles (or am I wrong here?).
While I agree that dvb subtitles are usually better than teletext subtitles, there are cases when it isn't so. For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext and dvb subtitles, but the dvb subtitles are ~6 seconds early, so they're unusable. Btw, a 20€ dvb-t set-top box handles teletext subtitles just fine.
Bye
On 28.02.2009 15:54, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
...teletext subtitles are a thing from the past, the normal way of broadcasting subtitles should be DVB subtitles. I hardly think a DVD player would be able to handle teletext subtitles (or am I wrong here?).
While I agree that dvb subtitles are usually better than teletext subtitles, there are cases when it isn't so. For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext and dvb subtitles, but the dvb subtitles are ~6 seconds early, so they're unusable.
Have you ever inquired why they don't fix this?
Klaus
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 15:54, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
...teletext subtitles are a thing from the past, the normal way of broadcasting subtitles should be DVB subtitles. I hardly think a DVD player would be able to handle teletext subtitles (or am I wrong here?).
While I agree that dvb subtitles are usually better than teletext subtitles, there are cases when it isn't so. For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext and dvb subtitles, but the dvb subtitles are ~6 seconds early, so they're unusable.
Have you ever inquired why they don't fix this?
No, I'm using teletex subtitles instead ;-) I'm not supposed to be receiving uk channels (in theory the beam is focused on the uk), so I cannot really complain. Besides, I'm not knowledgeable enough to be sure it's their problem or vdr problem (after all, if it didn't work with the freeview set-top boxes, they'd surely fix it, wouldn't they?) OTOH I never had problems with dvb subtitles on the bbc channels (other than vdr not recognizing they're there in recordings, while they automatically show in live view).
Bye
On 28.02.2009 16:38, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 15:54, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
...teletext subtitles are a thing from the past, the normal way of broadcasting subtitles should be DVB subtitles. I hardly think a DVD player would be able to handle teletext subtitles (or am I wrong here?).
While I agree that dvb subtitles are usually better than teletext subtitles, there are cases when it isn't so. For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext and dvb subtitles, but the dvb subtitles are ~6 seconds early, so they're unusable.
Have you ever inquired why they don't fix this?
No, I'm using teletex subtitles instead ;-) I'm not supposed to be receiving uk channels (in theory the beam is focused on the uk), so I cannot really complain. Besides, I'm not knowledgeable enough to be sure it's their problem or vdr problem (after all, if it didn't work with the freeview set-top boxes, they'd surely fix it, wouldn't they?) OTOH I never had problems with dvb subtitles on the bbc channels (other than vdr not recognizing they're there in recordings, while they automatically show in live view).
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
Klaus
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Klaus
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Strange, I see them a little bit early right now (not much) but it's worse with recordings. Maybe it's just Poirot, but I swear I have to use teletext subtitles with those recordings.
Bye
En/na Luca Olivetti ha escrit:
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Strange, I see them a little bit early right now (not much) but it's worse with recordings. Maybe it's just Poirot, but I swear I have to use teletext subtitles with those recordings.
I uploaded a short (14M bytes) clip with the subtitles out of sync. http://personales.ya.com/ventoso/poirot.tar
Bye
On Sat, 28 Feb 2009 19:29:07 +0100 Luca Olivetti luca@ventoso.org wrote:
[Subtitles out of sync]
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Strange, I see them a little bit early right now (not much) but it's worse with recordings. Maybe it's just Poirot, but I swear I have to use teletext subtitles with those recordings.
What sort of output device are you using? Maybe xine or whatever your decoder is has a problem that Klaus' hardware decoder doesn't?
I've also noticed that A/V sync problems are much more likely and/or severe with recordings than live TV. Maybe the switch to TS recording will correct that. Additionally, it seems to me that old programmes, especially films, are the most prone to A/V sync problems.
En/na Tony Houghton ha escrit:
On Sat, 28 Feb 2009 19:29:07 +0100 Luca Olivetti luca@ventoso.org wrote:
[Subtitles out of sync]
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Strange, I see them a little bit early right now (not much) but it's worse with recordings. Maybe it's just Poirot, but I swear I have to use teletext subtitles with those recordings.
What sort of output device are you using? Maybe xine or whatever your decoder is has a problem that Klaus' hardware decoder doesn't?
I thought of that (I'm using both xine and a dxr3), but that's the only channel where I have dvb subtitles out of sync. In fact, with networked xine, teletext subtitles are usually quite bad in recordings (that's the reason at the time I patched the plugin to delay them), while I never had problems with dvb subtitles (except for the above mentioned itv3).
I've also noticed that A/V sync problems are much more likely and/or severe with recordings than live TV. Maybe the switch to TS recording will correct that. Additionally, it seems to me that old programmes, especially films, are the most prone to A/V sync problems.
No, I don't have any problem with A/V sync.
Bye
En/na Luca Olivetti ha escrit:
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a look at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Strange, I see them a little bit early right now (not much) but it's worse with recordings. Maybe it's just Poirot, but I swear I have to use teletext subtitles with those recordings.
Definitely it's Poirot: today recording has no dvb subtitles at all (though they're advertised), but the teletext subtitles are there. Guess I'll have to look Sherlock Holmes instead ;-)
Bye
Hi,
juste a note to say that we also have teletext subtitles in France. I have tried vdr 1.7.4 which works perfectly except for the ttxt subs. I have to hold my final migration to 1.7.4 until I get ttxtsubs working again ...
Regards
2009/3/2 Luca Olivetti luca@ventoso.org
En/na Luca Olivetti ha escrit:
En/na Klaus Schmidinger ha escrit:
On 28.02.2009 18:35, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Please send me the channels.conf line of itv3 - I'd like to take a
look
at this myself.
ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
Just took a look, and they are perfectly in sync.
Strange, I see them a little bit early right now (not much) but it's worse with recordings. Maybe it's just Poirot, but I swear I have to use teletext subtitles with those recordings.
Definitely it's Poirot: today recording has no dvb subtitles at all (though they're advertised), but the teletext subtitles are there. Guess I'll have to look Sherlock Holmes instead ;-)
Bye
Luca
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after 1.7.5? /Magnus H
Magnus Hörlin schrieb:
Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after 1.7.5? /Magnus H
Brilliant Idea. That will boost the sales numbers to the limits :)
SCNR Peter
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
ROTFL
Peter Evertz schrieb:
Magnus Hörlin schrieb:
Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after 1.7.5? /Magnus H
Brilliant Idea. That will boost the sales numbers to the limits :)
SCNR Peter
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Mon, Mar 16, 2009 at 6:05 AM, Peter Evertz leo2@pec.homeip.net wrote:
Magnus Hörlin schrieb:
Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after 1.7.5? /Magnus H
Brilliant Idea. That will boost the sales numbers to the limits :)
lol! One of the best posts I've seen in a while! ;)
oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537)
Thanks for having spotted that.
Cheers,
Alex
On Tue, Jan 20, 2009 at 04:01:17PM +0100, Frank Schmirler wrote:
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
Cheers, Frank
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Frank, good shot. VDR is trying to parse PID 132 as if it was a PMT !!!
I have added a log message inside device.c and I have found that patPmtParser.PmtPid() returns pid 132 as PMT. The error can be localized in the patPmtParser.PmtPid function. It is a good progress.
PAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0 isNITPid = 0 service id = 132, pid = 132 [5832] PMT PID = 132 PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0 pcr = 120 stream type = 02, pid = 120 stream type = 04, pid = 130 'fra' stream type = 04, pid = 131 'eng' stream type = 04, pid = 133 'deu' stream type = 06, pid = 132 AC3 'fra' [5846] PMT PID = 132 [5846] PMT PID = 132 [5846] PMT PID = 132 [5846] ERROR: can't parse PMT
On 19.01.2009 11:06, Frank Schmirler wrote:
Hi,
On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote
I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still present in version 1.7.3 but the behaviour is worst because it segfaults.
First I found out that 2 lines where added in the ParsePmt method.
Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1;At the moment I don't know exactly what is the meaning of this 2 operations.
These lines are for handling the SI pointer field. Data[0] is the pointer field, which contains the byte offset to the actual data (usually 0). "+ 1" for the pointer field itself.
The order of the two statements need to be reversed. First fix the length, then the data pointer:
Length -= Data[0] + 1; Data += Data[0] + 1;
Mea culpa! It was correct in Frank's original patch, but for some silly reason I swapped these two lines when adopting the patch. Sorry about that...
Will fix it in 1.7.4.
Klaus
-
Alexw -
alexw＠undercover.mine.nu
-
Frank Schmirler -
Gilles Vieira -
gimli -
Klaus Schmidinger -
Luca Olivetti -
Magnus Hörlin -
Matthias Schwarzott -
Mika Laitio -
Oliver Endriss -
Peter Evertz -
Tony Houghton -
Udo Richter -
VDR User