[vdr] Re: dxr3/vdr problem

[Kai Moeller <moeller.ki@gmx.de>]

On Friday 28 February 2003 14:58, Rantanen Teemu wrote:
> > From: Stefan Schluenss [mailto:Stefan.Schluenss@gmx.de]
> >
> > Malcom is using DVB-T if i remember correctly and the currently
> > implemented
> > DVB-T systems seems to be more in an experimental state than in
> > production state ;-)
>
> I'd rather say that transport errors are more likely to happen on DVB-T
> then on DVB-C (should 'never' happen) or on DVB-S (can happen on bad
> weather).
>
> > The question is who (driver/vdr/dxr3-plugin) has to take care of corrupt
> > data ?! In Kai's opinion the data has to be checked and rejected inside
> > the
> > driver and such corrcupt data should never reach upper layers (the dxr3-
> > plugin).
>
> Considering that full error checking is somewhat complex operation (correct
> me if I'm wrong), I'd rather see that amount of code and CPU time not in
> kernel, but in user space.
>

Sorry, but I think you're wrong. The FEC mechanisms are defined in the DVB 
standards and hopefully implemented within the hardware/firmware of the DVB 
card. The TS packets, VDR receives from the driver, all have a 
transport_error_indicator bit which should be set to '1' when there is at 
least 1 uncorrectable bit error (see ISO/IEC 13818-1).

=> So actually it should be quite easy to detect defect TS packets.
PES packets (the Dxr3Plugin receives PES) don't have such an error bit (PES is 
used for transmissions where bit errors are unlikely). The only errors the 
plugin is able to detect are weird entries within the PES header (and we 
already added some more checks on request) but these are not the only errors 
which may crash your system.

Regards,

Kai



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