Hi Again, Here are some more thoughts/concerns that I have with the V4 API.
1) What is the functionality of the "DVB_DMX_SET_SECTION_FILTER" ioctl? When you open an fd on a demux device and then issue this ioctl, can you then call this same ioctl again to allocate more than one section filter on the same pid and same fd? If you issue this ioctl on an already instantiated section filter, does the existing filter get closed down and then reopened with the new section filter spec? Requirements: After discussion with application developers internally and externally it has been understood that there are 3 requirements for adding section filters. a) The ability to add more than one section filter with the same PID to a single fd. In this case, the middleware software will have to perform the actual separation of the tables by looking at the table id. This is straightforward from some h/w perspectives where you cannot physically setup more than one feed with the same PID value. In this case, you would have a single feed with multiple section filter specs attached and all matches would be dumped into an internal hardware buffer and copied to a kernel buffer which a user process would read. b) The ability to add more than one section filter with the same PID to separate fds. In this case, the middleware will be able to setup separate "threads" for each fd to monitor whether that section filter was available. This is equivalent to the V3 API. To answer point 1) with these requirements would mean that you could add more than one section filter with the same PID on the same fd. If you wanted more than one section filter with the same PID but separate fds, you would simply open the demux device that number of times to obtain the separate fds (same as V3 API). c) The ability to dynamically add section filters to an already running filter. This would follow on from a) where you could add more section filter specs with the same PID to an existing fd. Complicated I agree, but we are having to implement this anyway on our current project : ( 2) The issue of STARTING and STOPPING a filter has cropped up again. It would definitely be easier to discard these ioctls as you wouldn't have to worry about the state of a filter. However, current thinking is it would be beneficial to have these ioctls anyway as it is used in software that we have today and other customer's software. We have found on our h/w that it is quicker to stop a running filter, change the filter spec and start it again compare with closing the fd down, opening a new fd and setting it up with the filter spec. The actual setting up the filter for the first time is time consuming in terms of allocating memory, setting up h/w registers, irq's etc. I am having to implement these horrible ioctl's in my current demux implementation for backward compatibility as well as satisfying customers needs. I would particularly be interested to hear from our Toshiba friends to see whether they use the START/STOP ioctls as well or whether we can discard them. 3) Are we allowed to use the ioctl "DVB_DMX_SET_TS_DECODER_FEED" on an already instantiated/running decoder filter/feed to change the filter spec? In this case, the conception would be for the filter to be stopped internally, registers reset and the new filter spec. applied before the filter is restarted. If not, does it simply return -EBUSY? The same question also goes for the ioctl "DVB_DMX_SET_PID_FILTER". That's all 4 now, Rob : ) -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
