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

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

I have a few questions about the dvb drivers/devices that perhaps
someone can answer.

When receiving from one of the transponders on asiasat2 I have no
problems at at all.  While running vdr and also running dvbtune -m I
see:
...
Signal=53116, Verror=0, SNR=43860dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=53427, Verror=0, SNR=43815dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=52821, Verror=0, SNR=43836dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=53090, Verror=0, SNR=43758dB, BlockErrors=0, (S|L|C|V|SY|)

On another transponder I see:
Signal=41268, Verror=65357, SNR=37605dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=41267, Verror=65291, SNR=37608dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40916, Verror=65494, SNR=37554dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40953, Verror=65381, SNR=37479dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40660, Verror=65349, SNR=37548dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40977, Verror=65315, SNR=37539dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40976, Verror=65434, SNR=37560dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40665, Verror=65419, SNR=37575dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=40946, Verror=65478, SNR=37641dB, BlockErrors=0, (S|L|C|V|SY|)

This second transponder always gives high levels of Verror.  For parts
of the day the Verror will be around 20000 and the service seems to work
and my dxr3 won't freeze.  At other times it is up around 65000 and
things don't work and the dxr3 will eventually freeze (requiring either
a vdr restart or sometimes a machine restart)

My questions:
1.  Whis is this Verror?  What is its units? It understand it is related
to BER but how?  I understand it is a 16bit number so it would seem my
values are high.
2.  Why the difference between these two services?  I thought it may be
symbol rate (the first is 20400 while the second is 28125).  I have been
assuming that my problems are RF related but is this perhaps some kind
of problem due to a high load on a low end machine?

On Wed, 2003-03-05 at 22:48, Johannes Stezenbach wrote:
> On Wed, Mar 05, 2003 at 08:47:26AM +0100, Marcus Metzler wrote:
> > Malcolm Caldwell writes:
> >  > 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.
> > 
> > All the error correction required and possible for the DVB
> > signal is already done by the frontend. Any remaining errors cannot be
> > fixed on the transport stream level.
> > It would not make sense to check the MPEG stream on the ES level
> > inside the driver. It is the task of the MPEG decoder to fix or ignore
> > these problems. E.g. the hardware MPEG decoder of the av7110 already does
> > these things which are often necessary for MPEG streams received from a
> > error prone source. The dxr3 decoder is probably a little more picky
> > because it was not developed for decoding a broken stream.
> 
> If a TS packet has errors that cannot be corrected by FEC the
> frontends (depending on configuration) force the
> transport_error_indicator bit in the TS header to 1.
> 
> VDR could use this information to do "error processing", i.e. try
> to fix the PES packet that the TS packet belongs to (provided
> the PID field in the TS is still intact or can be guessed), at least
> by ensuring consistent "length" fields.
> 
> I don't know if t is practical in software, but hardware specs always talk
> about "error concealment" in their feature lists. E.g. the video MPEG decoder
> can use data from the previous frame to fill in the gaps. So it would be
> better to drop erronous data than to feed crap to the decoder, but
> you can't just drop the TS (or even the PES) packet, you would have to
> unpack the ES to the slice level and repack it with filled-in data.
> 
> The dxr3 never sees the transport_error_indicator, so it can't do it.
> It shouldn't crash, though.
> 
> Regards,
> Johannes
> 



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