Manu Abraham wrote: > Hi Johannes, > > Johannes Stezenbach wrote: >> On Sat, Nov 03, 2007, Manu Abraham wrote: >>> When Johannes stated: handling multiple streams is as simple as setting >>> a stream id, well it is not that i blame him, the specs look that way. >>> There >>> are couple of ways the same thing is done for example. You apply a >>> wrong one and the API is screwed and you have to bear that brunt for >>> a long time to come. >> Hey, if you know more than I do then please explain it to me. >> >> Until proven wrong I continue to believe that there isn't any more >> magic to handling multi stream mode than choosing one of them >> by writing the stream id into the appropriate demod register. > > ;-) of course. I have learned it the hard way, that proving a person > wrong can be disastrous. > > Nevertheless i will explain my understanding, eventhough not a > great one. :) > > 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. > > 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 >
Also, i forgot to mention one more thing, 16APSK is denoted as 4 + 12 APSK, (for the demod) not sure why either. > 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. > > 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. > > Manu > _______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
