Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537) Thanks for having spotted that. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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
Re: [vdr] PMT in multiple TS packet bug
Hi Mika, I have already applied the mentioned patch ;-) But unfortunately it does not solve the issue. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
> 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 Could this patch help with vdr-1.7.3? http://article.gmane.org/gmane.linux.vdr/39097 Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] PMT in multiple TS packet bug
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.0 +0100
+++ remux.c 2009-01-17 13:34:17.0 +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.
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: PMT section length too big (4176 byte)!
[] ERROR: can't parse PMT
Regards,
Alex
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
