[EMAIL PROTECTED] wrote: > > 1. Open up an fd on the demux device and use the DVB_DMX_ADD_PID_FILTER > ioctl passing in the PIDs of the video,audio and subtitle streams of BBC1. > Immediately the PID filters will be activated and start filtering data to > the h/w buffers. In this instance, the DVB_DMX_SET_PID_FILTER ioctl isn't > used, but we should still have it to cater for individual streams on > individual fds. Right?
DVB_DMX_SET_PID_FILTER will always have to be used for setting output_format. But see my other Mail. > 3. The user decides that BBC2 is not worth recording now, but insanely > decides to record BBC3. Unbelievable what British users are up to ;-) > Q: What about BBC2 data left in the circular buffer after the > DVB_DMX_DEL_PID_FILTER is issued? We can't flush the global circular > buffer otherwise we lose the data relevant to BBC1. Should the > DVB_DMX_DEL_PID_FILTER then wait until all the data in the buffer is > consumed before actually stopping/removing the filter? No. If you have a single threaded program there would be no way to consume the data if DEL would wait (unless it is consumed inside the driver). > Right, I have spoken with our app developers and they don't seem to have > any issues regarding this one-for-all setup and run ioctl > (DVB_DMX_ADD_PID_FILTER). However, for some strange reason some of our > customers do setup filters without running and then issue the START ioctl. > They claim they get faster channel changes, but I can't comment on this as > I haven't seen their s/w. I doubt this will make a noticable difference. Frontend handling and video/audio PID caching are much more important. > I don't mind which way we go as long as the requirements are met - which I > believe they are. Good. Can you have a look at the filter flags and tell me if your requirements are met there, too? Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
