On Sun, May 07, 2006, Manu Abraham wrote:
> Johannes Stezenbach wrote:
> >- it is wrong to believe that only the roll off factor is
> > relevant for the frontend, and other MATYPE bits are for the demux;
> > i.e. the frontend will do frame synchronization, needs to know
> > about ACM/CCM, and will output only one stream for MIS transmissions
> >
> MIS is optional for Broadcast Applications, Interactive Applications,
> DSNG applications and Professional Applications. These are the profiles
> supported by DVB-S2
>
> Was looking at VCM applications only, rather ACM/CCM applications.
>
> ok, what about adding the parameters like this then ..
>
> enum fe_stream_type {
> FE_TRANSPORT,
> FE_GENERIC_PACKET,
> FE_GENERIC_CONTINUOUS,
> FE_STREAM_RESERVED
> };
>
> enum fe_stream {
> FE_SINGLE_TS,
> FE_MULTIPLE_TS
> };
>
> enum fe_coding {
> FE_ADAPTIVE,
> FE_CONSTANT
> }
>
> enum fe_istream_sync_indicator {
> FE_ISSYI_ACTIVE,
> FE_ISSYI_INACTIVE
> };
>
> enum fe_nullpacket_deletion {
> FE_NPD_ACTIVE,
> FE_NPD_INACTIVE
> };
>
> enum fe_rolloff {
> FE_ROLLOFF_35,
> FE_ROLLOFF_25,
> FE_ROLLOFF_20,
> FE_ROLLOFF_RESERVED
> };
>
> enum slicing_policy {
> FE_SLICING_BREAK,
> FE_SLICING_NO_TIMEOUT,
> FE_SLICING_NO_PADDING,
> FE_SLICING_NO_DUMMY
> };
>
> and add all these enumerations into the dvbs2 struct
I think this is too much.
What we need _now_ is the roll-off factor, which is announced
in the EN 300 468 satellite delivery system descriptor.
However, if your hardware is giving you the 16-bit MATYPE
field, and you can even optionally set it, it might be useful
to have an __u16 matype in the API, at least for FE_GET_PARAMS.
I'm not sure, however...
> >Certainly the demux would have to be changed for the case where
> >the demod does not output 188-byte MPEG-2 TS packets. But I
> >don't think any bits of the two-byte MATYPE field are of
> >any direct relevance to the demux. They are all for
> >use by the demod.
> >
>
> I was of the thought that the SYNC words and the stream lengths are for
> the demux.
> TR 102 376 v1.1.1 (2005-02) 6.2.2
Sure, the demux needs to know the format of the frontend output.
But first the demod needs to know how to synchronize to the stream
itself.
But, heck, the standard is not very verbose, it isn't clear
to me which bits of MATYPE you need to set before you are able
to receive a stream, and which parts are read from the stream
once you receive it. :-(
> >>>>>I don't fully understand the DVB-S2 spec yet, but I think
> >>>>>the way to select the stream is by using an 8bit
> >>>>>input_stream_identifier.
> >>>>>
> >>>>>
> >>>>H.3 describes it. 8 bits isn;t needed, anyway boiling down to the
> >>>>demod, that doesn't happen, it is a simple knob to select between the
> >>>>streams.
> >>>>
> >
> >Actually Appendix F is the backwards-compatible HP/LP mode.
> >
>
> going down ..
>
> >However, the discription doesn't make it clear how to
> >
>
>
> +struct dvbs2_params {
> + __u32 symbol_rate;
> +
> + enum fe_modulations modulation;
> + enum fe_fecrates fecrate;
> + enum fe_stream streamtype;
> + enum fe_fecrates coderate_HP;
> + enum fe_fecrates coderate_LP;
> +};
>
>
> I think it speaks for itself. Isn't it descriptive ? Or is more comments
> needed ?
> If it needs more comments can add in.
What I meant is: "the description _in EN 302 307_ doesn't make it
clear"...
Johannes
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
