Roberto Ragusa wrote:
There is something that doesn't look right:@@ -1434,9 +1437,9 @@ static int AddPID(struct adapter *adapte { adapter->pids[i] = pid; - if (AddHwPID(adapter, pid) < 0) + if (pid != 0x2000 || AddHwPID(adapter, pid) < 0) OpenWholeBandwidth(adapter); - + return 1; } }Shouldn't it be "pid == 0x2000"?
sounds plausible to me, I'll commit the patch with this modification.
It's up to you how you configure this when registering the demux. But you are right, 256 provide a little more headroom - I increased this number.On a general side, I think the current pid handling is not very smart: 1) we check 0x27 slots even if only two are occupied (easily fixable) 2) when we openwholebandwith we don't close it back; this consumes CPU time and causes interrupts and DMA transfers Other considerations: is there any specific reason 1) to have exactly 0x27 slots? 2) to advertize 32 pids max?
yes. Depending on the content it might make more sense to request section-, PES- or TS-filters.3) to have stream1/stream2/pcr/pmt/emm/ecm specific routines, given that it looks like they have no particular specialization, they're just generic filters?
4) to have different coding style than linux kernel? ("CheckPID" instead
of "check_pid")
Would patches on these issues welcome?