[vdr] Re: dxr3/vdr problem

[Rantanen Teemu <teemu.rantanen@tekla.com>]

> From: Kai Moeller [mailto:moeller.ki@gmx.de]
> > 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).

My DVB card has given me zero TS packet errors ever (or at least as long
I've had that test in my driver). You can check TS continuity errors, but
they can reveal 15/16 errors at best (=~94%). If you get an error, then
what?

> => 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.

I did read some of the DVB documentation I had at hand, but I haven't
examined PES packets or PS data very carefully. If there isn't any CRC or
similar somewhere, I'm not sure you can detect transport errors without very
high level AI. Perhaps that is also why you get artifacts on commercial DVB
boxes.


					Teemu



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