Johannes Stezenbach wrote:
Hi,
thanks for your answer. I feel I'm getting closer, but
I still haven't figured it out completely ;-/
So, some more questions:
On Tue, May 23, 2006, christophpfister@xxxxxxxxxxx wrote:
Those params are *all* needed for tuning (except the pad of course). Most
of them should be self-explanatory. Just a note to the following ones:
+ enum dvbfe_obc_mode obc_mode;
Needed to indicate in which mode the transponder is sending. But don't worry,
this information is provided (see below).
Where does it come from? Is it the value of the
backwards_compatibility_indicator from
the S2 satellite delivery system descriptor?
Yes.
I don't get the description in EN 300 468, which says
"set according to EN 302 307", but EN 302 307 doesn't
mention this flag at all...
(EN 302 307 contains a description of
"Backwards Compatible modes (optional)" in annex F,
however it's not obvious how it works and what
the relationship to the S2 descriptor is.)
In Backward Compatibility mode you need to select the HP/LP stream.
select the HP/LP stream (via sismis)
From a device point of view ..
SIS/MIS (1 bit): describes whether there is a single input stream or
multiple input streams. If SIS/
MIS = multiple input stream, then the second byte is the input stream
identifier (ISI), otherwise
the second byte is reserved.
+ enum dvbfe_sismis_flag sismis;
+ __u8 stream_id;
If we set sismis to DVBFE_SISMIS_SINGLE, we have to specify which stream
should be read. If sismis is set to DVBFE_SISMIS_MULTIPLE the stream_id is
not used.
-- How to retrieve needed values --
The same way we do it for dvb-x / atsc right now. There is an initial tuning
file containing the values for a first tune.
Further channel data is retrieved from s2_satellite_delivery_system_descriptor.
I don't want to upset you, but this answer is a bit lame -- I'll try to
explain below why it doesn't further my understanding of the matter.
Additionally the app has to set _only_ those fields:
+ enum dvbfe_sismis_flag sismis;
+ __u8 stream_id;
Normally this is DVBFE_SISMIS_MULTIPLE as long as the app doesn't need special
behaviour.
If the transmitter broadcasts MIS, I have to set a stream_id
(otherwise I'd get a garbage mix of multiple TS, right?).
Do I then have to set the sismis to DVBFE_SISMIS_MULTIPLE
(because it's MIS) or DVBFE_SISMIS_SINGLE (because I want
to filter out just one of them)?
You mean just to use Input Stream Identifier alone, If stream_id > 0,
Multiple streams ?
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.
-- Usage of this api --
- how to do service scan for DVB-S2
Should be clear now. First do initial tune with the initial tuning file,
then get service data from the s2_satellite_delivery_system_descriptor.
- what changes are necessary for channels.conf
Well that shouldn't matter at this stage, otherwise we have the "chicken
and egg" problem. But I think it's obvious: We add the params for modulation,
fec, obc_mode and rolloff to channels.conf.
OK, these questions were not very clear. Let me rephrase:
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)
According to EN 300 468 the relevant fields which are of are
scrambling_sequence_selector (1 bit)
A value of 0 specifies that the default DVB-S2 physical layer scrambling
sequence of index n= 0 is used. A value of 1 means that the default
scrambling sequence is not used and the sequence index n will be
conveyed in the scrambling_sequence_index_field.
Now the device specs say p 39,
7.1.7 Physical layer descrambler and FEC interface
Descrambling
The descrambler applies the zeroth Gold code sequence to descramble the
incoming
sample stream starting with the sample immediately after the
physical-layer header field.
Two shifted and disjointed sequences of the Gold sequence are used as in
the DVB-S2
specification to determine if the incoming sample is rotated 0, 90, 180,
or -90 degrees.
EN 302 307 5.5.4 physical layer scrambling
Prior to modulation, each PLFRAME, excluding the PLHEADER, shall be
randomized for energy dispersal by multiplying the (IQ) samples by a
complex randomization sequence.
The scrambling code sequences shall be constructed by combining two real
m-sequences (generated by means of two generator polynomials of degree
18) into a complex sequence. The resulting sequences thus constitute
segments of a set of Gold sequences.
(After Figure 15)
In case of broadcasting services, n=0 shall be used as default sequence,
to avoid manual receiver setting or synchronization delays.
So indeed the device supports descrambling with an index n=0.
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.
multiple_input_stream_flag (1 bit)
backwards_compatibility_indicator (1 bit)
These two we just discussed , just above.
The stream filter is handled on the device by forcing the MATYPE
register. The descrambled header (MATYPE) is found in the MATSTR register.
Now, you think that every time you select a different MODCOD, the device
has to tune, but then the device could as well check whether it is
already tuned to the same parameters. But this is device specific, of
course.
EN 300 468 says: "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."
What does this mean?
- NBC-BS == "normative broadcast mode"?
Yes
- S2 descriptor only for BC or non-BS modes?
BC.
------------------------------------------------
OK, after reading through some parts of EN 302 307 and
EN 300 468 for the umpteenth time, here's how I currently
think it *might* work. Yeah, I'm still not sure, and there
are still holes for you to fill in, and hopefully you can
correct my mistakes:
1. DVB-S2 as used today: DVB-S2 is broadcast on dedicated
transponders in NBC mode; thus no S2 descriptor is
necessary, it is always SIS.
In NBC mode, it doesn't use the sismis flag, since there is no s2
descriptor.
But, TR 102 376, table 10 says
Broadcast Profile: Multiple Transport Streams (optional)
Interactive Profile: Multiple Transport Streams (optional)
Interactive Service Receivers shall implement CCM and Single Transport
Stream
DSNG Profile: Multiple Transport Streams (optional)
Professional Profile: Multiple Transport Streams (optional)
In S2 NBC mode, i believe TR 102 376, 6.2.1 applies, which is handled by
the device does this internally itself as the user sets the valid
MODCOD. since it changes on a frame by frame basis. IT does TDM
according to EN 302 307 page 66, Figure H.4, the MERGER does TDM
http://demo.astra-net.com/dvb-s2/
The information on the ASTRA demo confirms that, AFAICS.
(NBC means an old DVB-S receiver cannot receive it.)
DVB-S2 is broadcast in 2 ways.
(1) Backwards Compatible modes (optional)
(2) Non Backwards Compatible mode
Ideally all broadcasters should do a migration process.
Backwards-compatible modes
The large number of DVB-S receivers already installed makes it very
difficult for many established broadcasters to think of an abrupt change
of technology in favour of DVB-S2 – especially where there is a receiver
subsidy and for free-to-air public services. In such scenarios,
backwards-compatibility may be required in the migration period,
allowing legacy DVB-S receivers to continue operating, while providing
additional capacity and services to new, advanced receivers. At the end
of the migration process, when the complete receiver population has
migrated to DVB-S2, the transmitted signal could be modified to the
non-backward compatible mode, thus exploiting the full potential of
DVB-S2. Optional backwards-compatible (BC) modes have therefore been
defined in DVB-S2, intended to send two Transport Streams on a single
satellite channel. The first (High Priority, HP) stream is compatible
with DVB-S receivers (according to EN 300 421 [3]) as well as with
DVB-S2 receivers,
while the second (Low Priority, LP) stream is compatible with DVB-S2
receivers only.
Now,
There are some disadvantages to BC (Backwards Compatibility)
Backwards-compatible systems however suffer from two disadvantages:
• Compatibility will cause the overall performance to fall short of that
achievable by non backwards-compatible systems.
• There will be some performance penalty in the behaviour of existing
QPSK receivers. Note that some operators are reluctant to accept even a
slight performance penalty, as this increases service call-outs and churn.
Since now, broadcasters want to take advantage of the new features, but
yet they want to cut down operational costs (transponder bandwidth is
paid monthly. Receiver cost is a small amount compared to that, in the
fact that bandwidth costs are recurring)
Due to these reasons, Broadcaster's most of the prefer to go for NBC.
Advantage they get benefits from STB vendors too, as this pushes the
sales for new STB's immediately.
It all finally ends in revenue. :)
2. BC modes might be used, where a DVB-S and a DVB-S2
transmission are mixed together on the same transponder;
old DVB-S receivers will just see the DVB-S stream,
but DVB-S2 receivers can select either the DVB-S
or the DVB-S2 stream;
- an S2 descriptor must be present
Yes
- 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
- do you select the HP/LP stream by passing the
backwards_compatibility_indicator? Or rather
by using DVBFE_DELSYS_DVBS vs. DVBFE_DELSYS_DVBS2?
Or even by setting the stream_id?
Or something else?
(if (obc_mode && sismis))
select LP
The device will need the Input stream identifier as well.
3. DVB-S2 also allows multiple streams in NBC-BS mode (I think)
(e.g. two TS with different levels of error protection
on the same transponder)
EN 302 307 H.3 says,
The DVB-S2 system may deliver services over multiple Transport Streams,
providing error protection per MUX (VCM mode) A typical application is
broadcasting of a highly protected MUX for SDTV, and of a less protected
MUX for HDTV.
TR 102 376 6.2.1
Independent framing Issues
In ACM or VCM applications, MODCOD may change on a frame by frame basis,
therefore some PL frames may use MODCOD configurations that some
receivers cannot demodulate.
- contradicting EN 300 468 one needs the stream_id
from the S2 descriptor to select one of them
Already explained this above, the one discussed just down is different
from the earlier one.
- are there multiple S2 descriptors for this
frequency, one for each stream_id?
from http://www.ebu.ch/trev_300-morello.pdf
The DVB-S2 system may be used in “single-carrier-per-transponder” or in
“multi-carriers-per-transponder”
(FDM) configurations.
TR 102 376 6.1.2 Multiple (Generic or Transport) Streams
There are 2 solutions possible
(1) IP datagrams can be encapsulated in Transport Streams (Multi
protocol Encapsulation MPE) according to EN 301 192
(2) IP datagrams can be fragmented and encapsulated in variable or fixed
length layer 2 packets or directly mapped in the transmitted TDM stream.
MPE or other encapsulation protocols can be assumed.
but as we said discussed earlier, No MPE and or other stuff is worked
upon such as the ACM modes and friends which are used in the other 3
modes of operation eventhough, the Multiple streams in NBC mode mean
Professional applications, and Broadcast Applications, but these use
VCM, ie, MODCOD info to handle them, as it changes on a frame by frame
(TDM).
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
