[linux-dvb] Re: Bug in software demux still in 2.6.10

[Johannes Stezenbach <js@linuxtv.org>]

On Tue, Jan 04, 2005 at 11:19:28PM +0100, emard@softhome.net wrote:
> On Tue, Jan 04, 2005 at 02:56:21PM +0100, Wolfgang Wegner wrote:
> > - some people (including a friend of mine) have problems when using a
> >   second, budget, card to feed a full-featured card. This seems to
> >   be especially a problem with DVB-T and even more when the card takes
> >   long time to lock (maybe with some short, instable locks in between),
> >   at least this is what that friend of mine found out.
> >   In case of a problem, the ARM firmware locks and gets command timeout
> >   errors.
> 
> This is not (only) a software demux problem, which run on budget and 
> feeds the card with ARM. ARM crash likes to happen if the ARM is fed 
> by any garbled data that looks like original data but has errors inside, 
> therefore dvb-s having clean signal crash ARM 'rarely' (mine crashes 
> every 30 minutes) while dvb-t owners see that crash more often.
> 
> Software demux can rarify the problem by strengthening the data
> consistecy chekings, but can't help from ARM crashes. Even if you 
> have some magic filter application that analyzes garbled stream,
> cuts off errors, re-packs the rest of valid data and feeds this
> to ARM card, you would still have few bugs in ARM/firmware remaining
> to be fixed before crash-free situation is achieved.

Problem is that the av7110 does not really support playback
from memory. The code that implements it (probably written by
Technotrend) uses raw violence to make it work anyway.
I (and others who have access to the firmware source) have not
been able to find any errors in that code that could
cause a crash.

When decoding from TS the av7110 sees the transport_error_indicator
or countinuity counter errors, and can take appropriate measures.
With PES playback that possibility simply does not exist, so the
PES data has to be error-free. IMHO the video decoder should still
never crash, but you'd have to complain to TI about that.

The counter measure is not just a demux problem, one must unpack the
video PES and perform error checking at slice level (i.e. drop all
damaged slices from the PES). The firmware cannot do that, this must be
done where the error information is still present, i.e. in VDR.

> > Most of the problem reports are from DVB-T useres, maybe because they
> > all _have to_ use a second card as a primary data source because there
> > are not many FF-DVB-T-cards out there. Furthermore, due to the low symbol
> > rate, DVB-T unavoidably needs longer lock times.
> 
> Longer lock times = greater amount of garbled data until the lock sets on
> = higher frequency of ARM bugs

vdr doesn't feed data when there is no lock, but long lock times
indicate bad signal (or fe driver bugs ;-/ ).

BTW, my cinergyT2 locks faster than my Siemens DVB-C.

Johannes