Johannes Stezenbach wrote:
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.
But you seem to go against EN 300 468 as well. Looking at EN 300 468
Thare are others as well.
(So it's actually not just a new modulation but also
the new roll-off factor.)
Argh ! Rolloff is queried back from the Physical layer
Current use of DVB-S2 to my knowledge is Premiere HD on Astra 19.2E.
http://www.lyngsat.com/uslocal/Alaska.html?PHPSESSID=e86d014ecbd3495ed74fb3699e1fbf02
Eutelsat W3A (7.0E) - 10880.00 V - DVB-S2 - 17360 3/4 - Txp: A10
<http://en.kingofsat.net/tp.php?tp=1296> - Beam: Europe B
<http://en.kingofsat.net/beams.php?s=81&b=108>
<http://en.kingofsat.net/hdtv.php#>
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...
Well, if i were to say that if i were to be wrong at any point on some
argument, i wouldn't go about NACK'ing it altogether.
There can be many things that can run with , "i think" "it might" etc.
But that is not a solution.
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)
What about Tri mode and Quad mode devices ? DVB-T/Dvb-C is not the
complete world.
- 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)
Well i tried for it. Well many tried, you seemed to NACK all of them
down, but you say on one hand that you don't know much about DVB-S2 , on
the other hand you NACK any changes.
- maye other stuff like ARIB / ISDB-T
Well we should implement the useful ones first rather than implementing
the ones that aren't used at all
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
