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. Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
