[linux-dvb] DVB-S2 API vs. HVR4000: When?
js at linuxtv.org
Sat Nov 3 00:24:09 CET 2007
On Sat, Nov 03, 2007, Manu Abraham wrote:
> If you see H.2 and H.3, the difference is between CCM and VCM
> (Note: that both are cases of multiple "TS's")
> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP
> stream selection in some fashion combined with the merger/slicer
> where stream id is used.
What makes you think there is HP/LP involved? All H.2 says
is that two DVB-T streams are transmitted using one
DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
could then transmit them on two different frequencies in
(Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
they are not hierarchical because you can't get that
bitrate in DVB-T hierarchical mode. But even if it were DVB-T
hierarchical mode it has nothing to do with DVB-S2
backwards compatible mode hierarchical modulation.)
> It is a combination of both, rather than a simple stream id.
> (In this case Rolloff=0.20, Pilots do not exist) in this case the
> QPSK stream is with FEC 5/6
> H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar
> to H.2 exception that (In this case Rolloff=0.25, Pilots do exist)
> in this case the QPSK stream is with FEC 3/4 and the 16APSK stream
> is with FEC 3/4
> H.2 is playing with the DVB-S signal level (saturating a transponder)
> where as H.3 is using differential protection. It is not very clear how
> both of these are distinguished from each other.
The thing is that you don't need to distinguish them in the
demod API at all. DVB-S2 allows changing modulation parameters
with every PLFRAME (for VCM), and the only way this can work is
if the demod can figure them out by itself. This works because
the PLHEADER is sent with a fixed coding and modulation which
is independent from the rest of the PLFRAME.
That's why you don't have to worry about the details of the
transmission parameters, and why they don't exist in the
EN 300 468 S2 satellite delivery system descriptor.
(Those details are interesting for the broadcaster, of course,
who needs to optimize throughput vs. receiption performance.)
> Also, on the demod other than the MIS flag (according to the specs)
> there is another bitfield to select the HP/LP stream, which makes it a
> bit even more confusing. There exists some clarity, but again there are
> some clouds which hinder how it looks.
> I am not really very clear on handling this. We will get more clarifications
> the coming days.
HP/LP is only used for backwards compatible (to DVB-S) mode, as
one of two options. A DVB-S receiver will only see the HP stream,
the DVB-S2 signal will appear as additional noise to it.
OTOH a DVB-S2 receiver can choose between HP and LP.
I don't know how this is implemented in DVB-S2 demods, it could be
a selection bit in a register, or the demod could output the LP stream
in DVB-S2 mode and the HP stream in DVB-S mode.
That's how I think it works.
More information about the linux-dvb