Ralph Metzler wrote: > Michael Hunold writes: > > > > This is implicit behaviour and therefore bad design. There is only one > > mpeg decoder, so there is only one set of PIDs that can be set. Because > > of this, there should be one specialized "mpeg demux". > > While I do not agree that the AV filters belong directly to the > decoder it is true that they are linked closely to it. > Fact is, that while a special "mpeg demux" would fit closely to this > hardware (although the PID allocation dependency already hurts this a little bit) > on other hardware this can look very different. > Some does not have special filters but any general purpose PID filter > can be assigned to video/audio/pcr. If one filter is assigned to one > of those requests on other filters have to be denied. > That's where the current approach comes from which is no surprise > since NOKIA used the AV7110 which does it this way. > So, I think neither approach is perfect for all hardware and I > basically do not care if those PIDs are set in the demux device or the > decoder device. ... > > Take PID filters with the new proposed API for example: > > You can specify filters that simply don't make sense. You can set the > > filter type to DVB_DMX_FILTER_TYPE_VIDEO (mpeg decoder stuff), but > > specify DVB_DMX_FULL_TS (general purpose PID filter stuff). > > > > Please explain, why it makes sense to put this into one structure > > instead of clearly separating this? > > 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. How's that? > Does the current proposal allow setting section filters with different > PIDs on the same handle? No. > Regarding the special PID and section filter devices I do not see a > real difference compared to having them all in the demux device besides > inflating the number of devices. Me too ;-) Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
