Florian Schirmer wrote:
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?
just a known bug. Somebody has to enable and test the crc32 code in dvb_demux.c again...


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 {

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?
no, looks fine for now. (Remembers me to the Mesa and DirectFB achitecture - even this would be reason enough to like it;)

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.

Reply via email to