[linux-dvb] Re: Section Filters

[Ralph Metzler <rjkm@convergence.de>]

Johannes Stezenbach writes:
 > Rolf Hakenes wrote:
 > (edited for proper quoting)
 > 
 > > Johannes Stezenbach wrote:
 > > >
 > > > Here's what's missing from the documentation of the demux device
 > > > of the new API:
 > > >
 > > > --------
 > > > The dmxFilter structure defines a section filter, i.e. a bit pattern
 > > > and a mask for the first bytes of a section. The filter comprises
 > > > 16 bytes covering byte 0 and bytes 3..17 in a section, thus excluding
 > > > bytes 1 and 2 (the length field of a section).
 > > >
 > > > The mask states which bits to be used for filtering, and the filter
 > > > states the actual value of these bits. Only the value of the bits
 > > > where the corresponding mask bit is 1 will be checked.
 > > > --------
 > > >
 > > > Byte 0 in the filter is the table id.
 > 
 > > many thanks for your additional documentation, but after experimenting a
 > > bit with this type of filter you described I found, that not only byte 1
 > > and 2 are uncovered by the filter, but byte 3 and 4 are ignored as well.
 > > Therefore byte 2 of the filter array means the section number and byte 1
 > > contains current/next indicator at bit position 0. Is this
 > > interpretation correct, or am I tricked by a strange behaviour of the
 > > datastream ?
 > 
 > I just quoted from the docs, without having tested it myself.
 > 
 > Byte 1 and 2 of the section contain the section_syntax_indicator (1 bit)
 > and the section_length (12 bits). You cannot include those in your filter
 > (it wouldn't make much sense, anyway).
 > 
 > The meaning of byte 3...x depends on the actual table type (which
 > corresponds to the table id). For tables which follow the common
 > section syntax (section_syntax_indicator == 1), bytes 3+4 from the section
 > (aka table_id_extended) are most important. If the filter does not
 > allow filtering on them, it clearly is a bug.

Yes, there seems to  be a bug.
The mixup came from the strange conventions that the demux device
leaves out byte 1 and 2, the kernel demux API does not but the API of
the cards firmware wants them left out again.
I forgot to cut those 2 bytes out in StartHWFilter() in dvb.c.

Here are the relevant fixed lines:

static int 
StartHWFilter(dvb_demux_filter_t *dvbdmxfilter)
{
        dvb_demux_feed_t *dvbdmxfeed=dvbdmxfilter->feed;
        struct dvb_struct *dvb=
                (struct dvb_struct *) dvbdmxfeed->demux->priv;
        u16 buf[20];
        int ret, i;
        u16 handle;
        u16 mode=0x5020;
        
        if (dvbdmxfilter->type==DMX_TYPE_SEC) {
                buf[4]=(dvbdmxfilter->filter.filter_value[0]<<8)|
                        dvbdmxfilter->filter.filter_mask[0];
                for (i=3; i<18; i++)
                        buf[i+4-2]=(dvbdmxfilter->filter.filter_value[i]<<8)|
                                    dvbdmxfilter->filter.filter_mask[i];
                mode=4;
        } else

...

}

I did not make a patch out of it because of the different driver
versions. I also did not test this yet.
Please put this in the driver and tell me if it fixes your problem.

The bug should not affect the budget card driver since here filtering
is done in software. But it would interest me if anybody made
intensive use of those and how they perform.
I'll write a general network driver based on the kernel demux API 
during the next week which should then work on both cards.

Ralph


--- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.