Uri Shkolnik wrote: >> From: Andreas Oberritter <obi@xxxxxxxxxxx> >> While your statements about non-TS based standards make >> sense, those >> standards would require further work to be covered by a >> future API. In >> this special case, however, we're discussing correct >> usage of the >> current (TS based) demux API. > > Regarding the diversity mode - Need to be kept flexible, a device can switch mode (between using a given set of tuners as input for single content or use each tuner for different content) > > Regarding Non-TS - I must disagree, there are several posts on this ML that contradict your assumptions, and (much) more important, CMMB after two months of service has much bigger deployment than DVB-H, DVB-T2 and DVB-S2 putting together. T-DMB (DAB) also has much bigger audience. Maybe my phrasing was unclear. "Future API" shall mean any API not covered by Linux 2.6 _now_. I.e. "future API" is any of S2API or multiproto or whatever extension will eventually be merged into the upstream kernel in the future. What we are discussing here is an implementation detail for a driver using the _current_ API (unless someone thinks that the API needs to be changed to support the two tuners of the HVR4000). Please keep your suggestions for yet unimplemented transmission methods in a seperate thread. Regards, Andreas _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
