[linux-dvb] Re: Alternative v4 demux API

[Johannes Stezenbach <js@convergence.de>]

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 ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.