[linux-dvb] Re: Which CRC-code is used in TS of DVB?

[Gregor Lawatscheck <gpel@mpex.net>]

At 23:26 26/05/2003, you wrote:
> The decoder does not get the TS.
AFAIK there is no CRC in the TS but in the PES header? I haven't checked 
this, so I could be wrong.

Nevertheless: 
http://www.linuxtv.org/mailinglists/linux-dvb/2002/11-2002/msg00176.html is 
interesting, from Oct Nov 2002 where Holger speaks about CRC32 checking 
being broken in the av7110 firmware. Is this still the case and would that 
explain, why broken streams reliably manage to confuse and crash the decoder?

> There are also other instances between
> tuner and decoder which handle the TS or demuxed stream and can fail
> because of a broken stream. And think of a soft-player. It increases
> CPU-load dramatically if a soft-player has to handle bitstream error.
>
> Holger told that CRC32 is implemented in the driver, it just has to be
> activated.
>
> And before you talk about dropping packets, again, please read my
> explanation of CRC on VDR-ML.
Didn't see it in time - there's a lot of traffic on the vdr list. Yes, 
correcting via CRC32 sounds good  -- too good to be true?

Because as Holger writes:
>It's implemented. Set the DMX_CHECK_CRC flag in the 
dmx_sct_filter_params >struct if you want only receive sections that passed 
the CRC32 check.

Now that sounds like it'll drop sections that didn't pass CRC32, doesn't 
it? I'm not aware CRC32 corrects anything. I personally just fear CRC32 
errors, for example in archives etc. To me it's a checksum: According to 
http://www.cyberdyne-software.com/crc32.html CRC = "cyclic redundancy 
check(sum)". What do you do when the checksum fails? "Invert[ing] the wrong 
bits" is certainly beyond me.

If what you write be true - then it'd actually be grand but it's contrary 
to what Holger says about "receiv[ing] sections that passed the CRC32 check":
>>Smart CRC-codes like CRC32 can detect nearly every bit-error AND it's
POSITION in the bitstream. This way the decoder can simply invert the
wrong bits and you get the original, valid bitstream. This is of course
better than giving a broken bitstream to a hardware and say "Hey, this
is broken data, just see how you can handle".<< [quote from Rene on vdr ML]

I actually thought the CRC32 was good exactly for the latter reason - error 
detection - passing it to the decoder with the notice: "hey, by the way, 
this data is broken, handle with care". I'd like to believe otherwise. It'd 
be a great benefit to everyone if CRC32 from a budget card could be used to 
correct bitstream errors.  I thought FEC (forward error correction) was for 
error correction of the bitstream - and surely that's done even for the 
budget cards... 


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