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