On Mon, May 22, 2006, Klaus Schmidinger wrote: > Johannes Stezenbach wrote: > >... > >I also say it again: I am deeply dissatisfied that none > >of the people you mentioned at the bottom of > >http://linuxtv.org/pipermail/linux-dvb/2006-May/010076.html > >seem to care enough to participate in the discussion. > >(Not to mention that app developers also don't > >seem to care -- after all these are the ones who'll have > >to deal with the new API.) > > > >Maybe we should just put the API change off for now. :-( > > Well, as an application developer (VDR) I'd like to be able to > support DVB-S2, but I guess my knowledge about all this is too > limited to understand what this heated debate is all about. > > I always thought that DVB-S2 is just "DVB-S with a new modulation", IMHO the current use of DVB-S2 is just that, i.e. basically the difference between the satellite_delivery_descriptor as defined in EN 300 468 version 1.5.1 vs. 1.7.1. (So it's actually not just a new modulation but also the new roll-off factor.) Current use of DVB-S2 to my knowledge is Premiere HD on Astra 19.2E. If someone know other *current* uses of DVB-S2 please speak up. > so I would expect a new driver version that supports DVB-S2 to > just implement that new modulation and still call it "DVB-S". > This "...2" thing is IMHO just to make things clear to customers, > so they know that their old boxes can't handle it. From an application's > point of view it's still DVB-S, just with another modulation. For the immediate needs of DVB-S2 it might be sufficient to just treat it as DVB-S, i.e. you tune to the right frequency with the right symbol rate and the demod hw will do the rest automatically (since the other parameters are part of physical layer or baseband signalling). But I could be wrong in my interpretation of the standard here... It would also be possible to just add "modulation" and "rolloff" fields to struct dvb_qpsk_parameters, and use bit 31 of the symbol rate to indicate their validity (for backwards binary compatibility). (Ugly, but little hassle.) However, the goal is also to: - support dual-mode frontends (e.g. DVB-T/DVB-C combos) - support DVB-H (it seems there is no way to squeeze all DVB-H parameters into struct dvb_frontend_parameters, but I know next to nothing about DVB-H so I could be wrong) - be extensible for: - maybe support advanced DVB-S2 use (DSNG etc.) once we figured out how it works in practise - be able to query DVB-S2 (and others) modulation parameters etc. from the demod (e.g. also DVB-T/DVB-H cell ids) - maye other stuff like ARIB / ISDB-T > I wouldn't even mind if the old and new driver weren't binary > compatible. I'd just write into the release notes of VDR that > as of version soandso VDR requires driver version XXX. I predict you'd get a load of "my vdr doesn't work with my kernel" type of bug reports. Maybe for VDR breaking compatibility is not such a huge problem, but for something with many build dependencies like mplayer or xine it would be unacceptable. One mplayer or xine binary must work on any kernel. Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
