[linux-dvb] Re: [vdr] Re: dxr3/vdr problem

[Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>]

(Kai - I home you don't mind - I think this discussion might receive
better response on the dvb email list.)

This thread started when I wrote that I was having problems trying to
run vdr with a budget card using a dxr3 as the output.  I don't think I
am the only one.

The problem is I have a poor quality signal (due to various factors
including weather).

These errors get through the dvb driver to vdr and on to the the dxr3. 
The dxr3 device crashes - sometimes requiring a restart of vdr to reopen
the device etc, sometimes requiring a reboot.  Others have reported
having to reload the dxr3 drivers.  (although reloading the dxr3 drivers
has never worked for me - but thats OT)  My system only ever runs a few
hours before crashing.

Kai argues that the dvb drivers should not be passing frames with errors
through to applications.  Given that there is FEC etc in the dvb spec
this may be so - I don't know.  I also don't know if a budget card is
capable of doing this.

What do people here think?

On Mon, 2003-03-03 at 00:38, Kai Moeller wrote:
> 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 linux-dvb" as subject.