Well uuh , thank you for your reply rel , I appreciate
... NOW sorry to say this but what you suggested is no good for me , I'm used to working in my computer all day long and while I don't look at the images , I DO zap between the sounds alot , all of them with no preferences , progdvb does this for me so I'll stick with it ... dvbdream has a lot of qualities over progdvb from the little test I've done but failing to implement a simple feature as enough audio pids is a big drawback .
As for this feature being hard on the performance you know certainly better than me , but I'm skeptical you see , I mean 90% of channels have only 1 audio stream , 5% might have 2 pids in them and another 3% might have between 3 and 16 audio pids ... so you're left with maybe 2% of channels that have over 16 pids , now mind you I don't know any channel that has over 32 audio pids so why don't you just set the maximum pids at that (at least as a workaround for real number of pids) ... I fail to see how this can hit the performance as statistically (even if you have a poor implementation) if ALL channels that are above 16 pids were actually channels that have 32 pids (which is not true) you will end up with 2% more processor units consumed . THAT is hardly a performance hit .
Besides programmatically 16 is a "bastardized" number if you ask me , I mean how do you get your 16 ? that's 4bits of data (2^4=16) , 4bits of data is a nybble and there is no such definition in high languages , so unless you're using ASM or bit shifting to make you calculations which I highly doubt , whether you're using a for loop to get the pids and whether you're storing them in arrays, collections, linked lists, classes or whatever ... YOU HAD to set all these at least as a byte (though many would disregard optimization and set it as an int or uint) and certainly not a nybble which you can't , so again whether you're doing a [for (byte i=0, i<=16,i++)] or a [for (byte i=0, i<=32,i++)] the performance hit is so small , it's negligeable ... unless you're targeting the PC-IBM 286Mhz
... I'm not even going to go in the muddy terrain of 32bits and 64bits registers which is what we all have now as I'm getting very off-topic here .
AGAIN you know better than me the implementation you're using , I'm only stating the obvious non sense of saying that you can't double the processor ticks in 2% of the overall processor use because of performance requirements and my point is that 16 is no magical number , 32 is better suited as it covers almost all channels (without the need to delete anything) and at a very very very very low performance cost ... Other than that : MERRY CHRISTMAS TO YOU
ETA : The reason I went looking for other alternatives to progdvb in the first place is that the new version LIMITS the audio pids unless you buy the pro version
ETA : So meanwhile I'm sticking with an old version of progdvb which works just fine.
Login
Register
FAQ
Search
no need for a DB at all. (anything else than native processing of an array would make it slower)