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
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.
vdr mailing list