Again, this depends on the hardware.
The current API V4 proposition basically treats each filter as if it
is a streaming device. For software filters this is no problem except
that DMA is probably out of the question. Some hardware only has two
recording devices which can do direct DMA of multiplexed sub-streams.
Here, it could make sense to have extra devices. Or you also use
the demux device and let special requests fail.
I think Michael is right in that the design of the pid/TS filters
is not optimal because it mixes different stuff in one ioctl.
It would be possible to do the following:
- get rid DVB_DMX_OUT_MEMORY
- add DVB_DMX_SET_DECODING_FILTER to drive the special "decoder filters";
for hardware which has no special filters these would just use
a GP filter
- keep DVB_DMX_SET_PID_FILTER for GP filters only (one PID per fd,
add DVB_DMX_PAYLOAD_ONLY and DVB_DMX_TS_HEADER_ONLY)
- add DVB_DMX_SET_RECORDING_FILTER in conjunction with
DVB_DMX_ADD/DEL_RECORDING_PID for special purpose recording filters;
some hardware would just use GP filters internally; this
would also get rid of the DVB_DMX_EVENT_LOGGING flag
If you want to record and decode a PID at the same time you would
need to open two fds to set the DECODING_FILTER and RECORDING_FILTER
for the same PID.