[linux-dvb] Re: Linux DVB API 4 Q's

[Rob.McConnell@Zarlink.Com]

Hi Guys,

Thanks for the prelim comments : )


> > As long as we have the capability to add multiple PID filters to an fd
for
> > a TS or PES output, then that should be OK (e.g. for recording to HDD).
> > For section filtering, I suppose it would make sense to have different
fds
> > for the same PID but different table id.  Is this the intention here?

> Both, one section filter for several PIDs and several filters on one
> PID, would be useful to have on one file descriptor in some special
> cases. But both make the demuxer more complicated and only move
> complexity from user space into the kernel. It is not too hard to
> implement but I would really like to throw it out again ...

As I understand the current API version 3 implementation allows you to
attach multiple section filters to a single fd, so I think we should keep
this in V4.  Can I ask in what cases would you have one section filter on
several PIDs?  I have never seen this requirement before, but maybe you
have come across this.

> > *** Now for the new Q's: ***
> >
> > A. If we want to route a TS/PS/PES off a DVD or HDD through a PID
filter,
> > then I guess we would have to setup the source type of the filter to be
> > "DVB_DMX_SOURCE_FRONTEND" with the correct "frontend_num". The same
goes
> > for an input from an external C/A modules or LVDS, etc.  Is this the
> > intention?  Does the term "front-end" really make sense?


> See the discussion about general input devices. I do not care if they
> are all called input or frontend but they should be treated equally.
> Normally the demuxes can choose one of the inputs of the whole demux
> block as source and you cannot bypass this. So, data should be
> written to a frontend/input device and not to a demux. If you can
> bypass this, then one could always make writing directly into
> the demux device possible just for this hardware.
> Or how do you handle the case if two demuxes are supposed to process
> the same data from memory?

OK, I just wanted to make sure that this was the correct method to use.  I
like the idea of having a separate logical demux device for each
simultaneous input source. : )

> Hmm, OK, so not all demods do directly hang on an input of the demux
> block. Either we use separate devices for demods (and other sources?)
> which can select targets and the input device sets sources, or we just
> let the input devices choose exactly one filter (i.e. CI).
> For anything more complicated you better invent a general Linux
multimedia
> device architecture with general sources, filters and targets and
> use it for sound, V4L, DVB, ...

What about leaving the demux device alone and allowing it to choose say
front_end x = C/A module input.  Then we
need a C/A device that can set it's source to say external demod #1.  In
this case, h/w that does have the ability to route an input TS from say an
external demod to a C/A module and then into the logical demux device  is
covered.  Also, h/w that does not have a C/A or C/I router will still
function the same i.e. demux selects the required front_end.

Thanks for the comments!

Rob : )







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