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

[Rob.McConnell@Zarlink.Com]

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

That's fine.  Ignore the crap I mentioned about left-over fds, I don't
think that matters from an API point of view.  I was having a think about
sharing the same decoder feed/filter fd with more than one A/V decoder,
thus each decoder being fed with the same source stream.  I think that the
API should be OK with this.

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

The h/w that I know breaks the section filters down into fixed size blocks.
If you want a longer filter length, then you use more of these fixed size
blocks from the "pile".  Having just the raw number of these blocks was
what I had envisaged.  Maybe there are other h/w architectures out there
that break this observation.

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

OK, we'll leave them out for now and maybe later add them in if anyone
needs them.

Cheers,

Rob : )






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