On Sun, Dec 21, 2003 at 10:47:19PM +0100, Andreas Oberritter wrote:
On Sat, 2003-12-20 at 19:04, Emard wrote:
The memcpy() issue should not be too hard to resolve, just never copy
more than a complete section and reset the crc seed appropriatly. The
performance impact should be negligible.
Alright, that's simple if it helps, I can just limit the memcpy range
to each one complete section with crc reset inbetween them.
Yes, thanks. Just send me a patch and I'll report whether it works.
I'll try to make it, it's not so simple as I thought on the first
glance but some hack should be possible. Please note that this code
will break the nice structure of unfolding encapsulation layers in
their natural order; it has to early analyze certain encapsulated
data, skipping layer that actually should have been analyzed later!
As result, the memcopy range limiter code will bloat in the similar
type of cumbersome code in the sections that we just recently got rid
off.
(I wonder could we simplify crc troubles and just ignore crc)
*g* don't you think that's kind of an oversimplification? No - get
serious, the CRC32 check is required in noisy environments like DVB-T
since sections can get spread out over multiple TS packets. If the FEC
drops a packet then the section data will be corrupted and must be
discarded. When a crc32 checked section arrives in userspace it must be
definitely valid - otherwise you could not use them for robust firmware
updates, DSMCC and MHP downloads etc.