Ralph Metzler wrote:
Florian Schirmer writes:you could write single-threaded code that sleeps using blocking read() on a single filedescriptor instead calling of calling select() for multiple ones...
> - Will add filters.
> - All output will be routed to the same fd. > - Some restrictions apply: Only filters of the same type (TS or PES or SEC)
> are allowed.
Is it that useful to have multi PID filters for PES and section data?
passing the entire filterset at once instead of allocating filters one by one makes locking much easier, too...It also would be easier to handle multi PID filter hardware if all PIDs are allocated at once. Otherwise the driver will have to do lots of bookkeeping, especially if it has to decide what kind of hardware filter (single PID, or other) to use.
> - Num must be unique (or should be set by the demux?)
> - Merging in section support is not necessesary but makes sense (IMHO)
> - dmx_decoder_t can be split into just a single type of every decoder and
> then adding a new uint32_t dec_num; field. Dunno what is more reasonable.
> - Internally each filter still maps into a single feed. So there is no need
> to fiddle around with any device driver. (Hopefully :)
For hardware with special multi-PID TS filters it won't be that easy.
At least internally we will have to handle single and multi PID
filters separately. Otherwise, the lower driver layers have no way to know which filters belong together higher up.
We also need to expand the kernel demux API to handle this and also
direct DMA into the higher level buffers.
Here multi-PID section and PES filters also would make problems.
what kind of problems do you have in your mind? Holger -- Info: To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.