[linux-dvb] Re: V4 Demux API Q's

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> Johannes Stezenbach wrote:
> >
> > If the decoder is not currently connected the associated decoder-filters
> > cannot be in use, thus DVB_XXX_SET_SOURCE will always succeed (at least
> > wrt filter allocation). If the decoder is already connected
> > DVB_XXX_SET_SOURCE will just change the decoder filter settings.
> 
> > Or did I miss something?
> 
> Shouldn't the statement "If the decoder is already connected
> DVB_XXX_SET_SOURCE will change the decoder filter settings." above be
> referring to "DVB_DMX_SET_TS_DECODER_FEED" instead?

What I meant to say was: "If the decoder is already connected
DVB_XXX_SET_SOURCE allows one to connect to a different
decoder filter". Of course one can change the PIDs on-the-fly
by just calling DVB_DMX_SET_TS_DECODER_FEED.


> > Capabilities are not clearly defined yet. Maybe you could just tell me
> > which way you'd like it best?
> 
> I would prefer to have the section/recording/general purpose PID filters
> all grouped together under one definition such as
> DVB_DMX_CAP_NUM_PID_FILTERS.  Then, DVB_DMX_CAP_NUM_SECTION_FILTERS would
> refer to the number of section blocks that the hardware/software could
> provide.  It might be better to rename this definition to make it more
> clear, such as DVB_DMX_CAP_NUM_SECTION_BLOCKS.
> 
> I would also add DVB_DMX_CAP_NUM_TELETEXT_FILTERS and
> DVB_DMX_CAP_NUM_SUBTITLE_FILTERS for h/w that supported these to keep
> things consistent.
> 
> Hope this helps ; )

It helps some. But: It's not clear whether section filters need
PID filters (hw dependent), so it's hard for applications to interpret
these number correctly. Also, for a lot of hardware the number of
available section filters depends on the filter length and the
use of not-equal-filters. So, while it's still useful to have
the capabilites it is difficult to make them really hardware
independent.


> Yup, that's OK.  What about the cases DVB_DMX_OUTPUT_DUPES and
> DVB_DMX_OUTPUT_ERRPKTS - would it make sense to keep these global flags or
> per pid flags or ignore them completely?

Hm, I think these are ofter per-PID, but I don't know if recording
filter hw supports them, too. I think it's best to ignore them
as I doubt that applications would make use of them.


Johannes


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