[linux-dvb] Re: Alternative v4 demux AP

[Rob.McConnell@Zarlink.Com]

Johannes Stezenbach wrote:

> 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

Agreed.

> - 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

Good.  Would we want to issue a AUDIO/VIDEO/PCR filter setup in 1 ioctl, or
would it be better to have individual ioctls for each of the streams?  What
if you want to change just the audio PID for another audio language, for
example?

> - 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)

Good, this is also how I envisaged it as well.  Question, does
DVB_DMX_TS_HEADER_ONLY provide both the header and adaptation fields?
Should we add a separate DVB_DMX_TS_ADAP_FIELD flag as well for extracting
private data or PCRs?

> - 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

So DVB_DMX_SET_RECORDING_FILTER would setup a single PID filter and
DVB_DMX_ADD_RECORDING_PID/DVB_DMX_DEL_RECORDING_PID would add/del a single
PID to/from the existing fd?

Then DVB_DMX_START/STOP would synchronise the group filtering - correct?

Yup, please remove the 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.

Note that not all h/w allows this capability.  You would need some way of
preventing the recording filter to be setup when a decoding filter is
active or vice versa.

> > 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 ;-)

This is inevitable, but I think my previous email helps to prove that we do
require this functionality.  Again, you can group filtering capability per
demux device/logical demux device together.

e.g. /dev/dvb/adapter0/demux0/pidfilter
     /dev/dvb/adapter0/demux0/secfilter
     /dev/dvb/adapter0/demux0/mpgfilter

     /dev/dvb/adapter0/demux1/pidfilter

In this case, demux0 can perform pid/section filtering as well as providing
PES streams for audio/video decoders.  Demux1 can only provide pid
filtering (no a/v path for the decoders).  Of course you would still need
the .../videoX and .../audioX devices.

Would you need to have the "dvb_dmx_output_format" struct included in the
new "dvb_dmx_decoding_filter" as I don't know of any A/V decoders that can
accept a TS packet input (only PES or ES)? Anyone know differently?

Regards,

Rob : )






-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.