[vdr] Re: dxr3/vdr problem

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

On Sunday 02 March 2003 22:56, Rantanen Teemu wrote:
> > 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

Then there is a problem in the hardware/firmware/driver.

> 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?

Actually my understanding is that the TS continuity_counter is not designed 
for error detection but to transmit duplicate frames and to identify these 
duplicate frames. If one of these frames is defect you can simply use the 
duplicate ... just a simple FEC mechanism.

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

The CRC (actually it is more than a simple CRC) is added to the TS packet 188 
bytes + 16 bytes. These 16 bytes are used to do the error correction and then 
they are stripped away. If the error correction detects uncorrecteable errors 
the transport_error_indicator bit should be set. How these errors have to be 
communicated and handled afterwards is not discussed within the standard.
This is the problem of the individual system. 

The standard says about the TS stream and the PS stream:

"The Transport Stream is designed for use in environments where errors are 
likely, such as storage or transmission in lossy or noisy media." (ISO/IEC 
13818-1, Introduction)

and 

"The Program Stream is a stream definition which is tailored for communication 
or storing one program of coded data and other data in environments where 
errors are very unlikely, and where processing of system coding, e.g. by 
software, is a major consideration."  (ISO/IEC 13818-1, 0.2 Program Stream)."

So from that I think it is not the job of the Dxr3Plugin to find the bit 
errors. There should be a channel to indicate which parts of the PES packets 
are potentialy defect. With this information we can implement a simple 
handling of defect frames. E.g.: To simply skip defect frames or to stop 
displaying as long as the error probability is greater than a certain level 
(which would be better than let the dxr3 driver / firmware crash).

For this we would need a working error detection of course.

Regards,

Kai




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