Florian Schirmer wrote:
just a known bug. Somebody has to enable and test the crc32 code in dvb_demux.c again...Hi,Some more questions, i stumbled on while digging trough the api: 1. soft-dmx doesn't check the crc of sections. Any reason for that?
2. acceleration hooks This is a quite complex question ;) Background: Our STB is capable of calculation the section crc itself. But it can only do that if the data is still in the queue and has not been pulled out into the dmxfeed->secbuf. To use the crc engine there are 2 possible solutions: A) Copy all the dvb api soft dmx functions and hack them to use the engine. This will result in lots of duplicate code. B) Add some acceleration hooks into the feed structure. For example:
I vote for (B).
struct dvb_accel {no, looks fine for now. (Remembers me to the Mesa and DirectFB achitecture - even this would be reason enough to like it;)
void priv;
u32 (*crc)(void *src, size_t count);
void (*memcpy)(void *dst, void *src, size_t count);
}
Struct dvb_dmx_feed {
[...]
struct dvb_accel accel;
[...]
}
allocate_feed() {
[...]
feed->accel.crc = dvb_crc;
feed->accel.memcpy = memcpy;
[...]
}
The api will initialize the accel functions with the normal
dvb_crc/memcpy functions. If the hardware is able to do crc itself it
can overwrite the handlers and benefit from its capabilties.
Oppinions? Any other ideas?
I would not encapsulate the function pointers into an extra struct, just call the members check_crc32 and memcpy and put them directly into the demux struct right beside write_to_decoder, these acceleration function pointers are associated with a demultiplexer not with a feed, right?
Holger
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
