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@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
