Re: [PATCH] Re: [PATCH] Multi protocol support (stage #1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>On Thu, May 25, 2006, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>> >EN 302 307 annex F talks about high and low priority streams
>> >and hierarchical modulation. A previous version of
>> >the API proposal consequently contained a way to select
>> >the HP/LP stream. Has this been identified as unnecessary?
>>
>> Annex F Backwards Compatible modes (optional)
>> says,
>>
>> Hierarchial modulation, where two HP and LP Transport streams are 
>> synchronously combined at modulation symbol level on an asymmetric 8PSK
>
>> constellation.
>>
>> NOTE 1: Hierarchial modes are also used in EN 300 744
>>
>> Now the device specs says, p 128, TSULSTKM
>> [6] LOWP_EN
>>
>> Low priority Enable (1 bit)
>>
>> p 129, TSSTATUS
>> [5] LOW_PRIORITY
>>
>> Low priority is engaged (1 bit)
>>
>> This we can use
>>
>> (if (obc_mode && sismis))
>> select LP
>>
>> The device will need the Input stream identifier as well. If stream_id
>=
>> 0 is not a valid stream, we can even omit the sismis flag. But i am not
>
>> very sure of this whether 0 is a valid for a stream or not. IMHO, it 
>> would be better if we have these two separated as it is right now, ie,
>
>> STREAM_ID and SISMIS.
>>
>> I don't understand why we should use FE_HIERARCHY_XX. Since this is in
>
>> obc_mode and EN 300 468 says that way and it maps according to that. It
>
>> looks exactly that way.
>> 
>> I don't see anywhere else where it says anything else otherwise.
>
>See my reply to Christoph.

Should be clear now ...

>
>
>> >Assuming VDR only cares about broadcast services (TV + radio),
>> >is the s2_satellite_delivery_system_descriptor relevant
>> >for VDR? All of it or just parts? And why?
>> >
>>
>> Most of it. (It is not specific to VDR .. we wouldn't be making the API
>
>> VDR dependent rather rather application independent .. ;-) Some people
>
>> say it has to platform independent too .. :-D)
>
>Well, VDR doesn't care about MPE, so it doesn't care about
>the dvb_net API...
>Similarly, if e.g. the scrambling_sequence_index would only
>be relevant for IP-via-DVB applications, VDR wouldn't need
>to care about it, altough it might be part of the DVB API.
>
>According to my current understanding, all parts of
>the S2 descriptor might be relevant to receive NBC-BS in
>MIS or BC-BS mode, except for the scrambling_sequence_index,
>where I have no idea what it is good for.
>
>(I guess the scrambling_sequence_index might be used
>for better seperation of two seperate DVB-S2 signals transmitted
>on adjacent channels; can anyone shed a light on it? Is it
>used for BS at all???)

S2 descriptor used only for backward compatible mode. In NBC-BS it isn't
provided: "This descriptor is only required if DVB-S2 is not used in normative
broadcast mode (NBC-BS). In normative broadcast mode the satellite_delivery_system_descriptor
is sufficient."

Well, I'm not able to say anything about the scrambling thing right now ...

>
>
>> In the implementation,
>>
>> I can't see how i can set another scrambling_sequence_index. IMHO this
>
>> field should be added only when new devices that make use of this field
>
>> comes up.
>
>Hm.
>
>> http://demo.astra-net.com/dvb-s2/
>
>This page doesn't show much to me -- does it work only in IE?
>
>
>> >   - are there *multiple* S1 descriptors in the NIT for
>> >     this frequency, one with modulation_system S1 and
>> >     one for S2?
>>
>> This i can tell you once i have parsed the stream. For this i have to

>> get the device running. It is now a chicken and egg problem.
>>
>> As far as i understood, there is only one for S1 and one for S2 in BC,
>
>> and just S1 in NBC
>
>Well, assuming any old DVB-S receiver will only succeed to recognize
>a transponder in a channel scan when there is:
>
>- exactly one S1 descriptor
>- and the S1 descriptor contains only values which are valid
>  according to the old EN 300 468 version 1.5.1
>
>-> a DVB-S2 receiver will have to rely on that S1 descriptor
>   plus one S2 descriptor (where my guess is that the
>   backwards_compatibility_indicator will be set if
>   hierarchical modulation is used, but not when
>   layered modulation is used)

For NBC-BS only S1 descriptor is used.

>
>-> this would mean that modulation and fec are the same
>   for DVB-S and DVB-S2
>   (however, thanks to the MODCOD field in the DVB-S2
>   PLHEADER it would probably work with different
>   mod/fec, too, as the demod can figure it out automatically)

Yes, But another rolloff may be used (in v1.5.1 there are reserved values
at #modulation which are used now).

>
>(Indeed, I believe the modulation and fec fields in
>struct dvbs2_params are not necessary -- the values
>can change on a per-frame basis anyway, says the spec.)

They are necessary! It's possible that the transmitters sends more than one
stream (with VCM / TDM), but you have to specifiy the modcod for the stream
you want to receive.

>
>
>For NBC-BS in MIS mode however, I think two or more
>S2 descriptors are needed, one for each stream_id.

There can't be any NBC-BS in MIS mode (see above).

>
>A channel scan and the channels.conf file must thus
>be prepared to handle this.
>IOW, it is not sufficient to add parsing of the S2 descriptor
>to dvbscan, because dvbscan assumes that there is
>only one set of parameters per *frequency*. There
>is more work necessary. For BC-BS and for MIS
>dvbscan would also have to FE_SET_PARAMS multiple
>times to can all streams.

It has to scan LP and HP streams if available (but this case is detectable).
But IMHO this question is independent from the API thread and shouldn't be
discussed here. There will be changes to the initial tuning file and the
channels.conf file of course.

>
>
>Johannes

Christoph


_______________________________________________

linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux