Felix Domke wrote: >>Ralph Metzler wrote: >>I also don't think the elsewhere mentioned SET_SOURCE call or API 4 >>would help much. Or is there support for multi-standard tuners or >>for the case that 2 specific tuners cannot be used at the same time? >>You could e.g. only allow front0/1 as source for demux0 and front2/3 >>for demux1 and otherwise return -EINVAL but then all the software >>out there would have to "scan" all possible combinations first. >> >> >Well, DMX_SET_SOURCE is of course only to select the demux source... > >In general, policies about "what can be combined" are very hard to >describe in binary. For example, most hardware-filters still have >problems filtering AV-streams to both memory and a hardware decoder >(without doing twopass, if available). Then, often a hardware decoder >can only be fed from demux0. Some other can filter to memory only in PES >format (when decoding). Or this case, where only one of two (virtual) >frontends can be used at once. > >One could either completely virtualize everything (having one powerful >demux which can do everything, until all hardware resources are used, >then switching to software filtering to allow arbitrary filtering, >possibly including building PES-streams for the decoder in software etc. >- awful), or build machine-specific stuff in the application which can >handle this (for example, record from a second demux if first demux is >used to decode). > >In the case of the frontends, i see the following additional possibilities: > - Provide 4 virtual adapters(!), each to cover a specific DVB-S/-T >combination. Every adapter would contain 2 frontends with fixed types. >The application then should use only one of the 4 adapters, but could >use both frontends. Would keep best compatibility, but is obvious a bad >choice as for 3 (physical) frontends, you would need 8 adapters and so on. > > Ok, and what about an adapter that has two frontends, one with is 8VSB, and another which can be 8VSB or QAM-64/256? > - Have a module switch (or better, /proc-setting) which switches the >tuner types, then have two frontends. Disadvantage is that you need to >switch the type first in a non-standard way, but provided that >application which don't know about this special situation can't use all >of them anyway, i don't think this matters much. > - Have a frontend extension to "switch personality". As there aren't >much of these frontends (and to be honest, i still don't see THAT big >advantage of building such frontends), i don't think this would make sense. > >I vote for the /proc-setting. Applications which know about it can use >it properly, other ones can only use pre-selected fe types. > >I doubt that it's easier to teach applications that some of the >frontends are "offline" than to implement the type-switch. > >Felix > > Why burden each application with the necessity to grok this sort of limitation? Why not embed it into libraries as part of the user-side API? -Philip
