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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
