[linux-dvb] DVB-S2 API vs. HVR4000: When?

Manu Abraham abraham.manu at gmail.com
Sat Nov 3 00:43:46 CET 2007

Johannes Stezenbach wrote:
> 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
> non-hierarchical mode.
> (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.

Most probably you are right, but i still do not feel comfortable, well will see
what the vendor has to say.


More information about the linux-dvb mailing list