[linux-dvb] Re: AW: Re: API changes (was: C/A routing Question)

[Johannes Stezenbach <js@convergence.de>]

Florian Schirmer wrote:
> typedef enum
> {
> 	DMX_FMT_TS,
> 	DMX_FMT_PES,
> 	DMX_FMT_SEC,
> 	DMX_FMT_PES_HDR,

I'm still not convinced what this would be good for.

> 	DMX_FMT_STC,

And this one does not make sense. PES packets (optionally) have a
PTS. This is fed to a PLL to recover a stable clock (the STC),
currently by settting a filter with DMX_PES_PCR and DMX_OUT_DECODER.
There's special hardware for clock recovery (to remove jitter etc.),
and it's often associated with the demux.
The STC is then used by the MPEG decoder for synchronization.
Or, in case of subtitles, by userspace programs.

> 	DMX_FMT_ES,
> 	...
> } dmx_format_t;
> 
> typedef enum
> {
> 	DMX_DEC_NONE,
> 	DMX_DEC_VIDEO0,
> 	DMX_DEC_VIDEO1,
> 	DMX_DEC_VIDEO2,
> 	DMX_DEC_AUDIO0,
> 	DMX_DEC_AUDIO1,
> 	DMX_DEC_AUDIO2,
> 	DMX_DEC_PCR0,
> 	DMX_DEC_PCR1,
> 	DMX_DEC_PCR2,
> 	...
> } dmx_decoder_t;
> 
> struct dmx_filter_params
> {
> 	uint32_t num;

s/num/id/
unique per demux file descriptor

> 	uint16_t pid;
> 	uint32_t fe_map;
> #define FE_ALL 0
> #define FE_MEM 1
> #define FE_HW1 2
> #define FE_HW2 4
> #define FE_HW2 8
> 	dmx_format_t format;
> 	dmx_decoder_t decoder;
> 	dmx_filter_t sec_filter;
> 	uint32_t sec_timeout;
> 	uint32_t sec_flags;
> #define DMX_CHECK_CRC 1
> #define DMX_ONESHOT 2
> #define DMX_IMMEDIATE_START 4

I never used DMX_START and filters without DMX_IMMEDIATE_START.
Do we need it or should we drop DMX_START/DMX_STOP in favour of
DMX_ADD/DEL_FILTER? Or would DMX_STOP mean "stop all filters"?
Or even "clear all filters"?

> }

> - Num must be unique (or should be set by the demux?)

Let the app do the book-keeping and choose its own ids.
If we would set all filters in one ioctl we could use an array
and just use the array index as id. But with the more dynamic
DMX_ADD/DEL_FILTER concept the driver won't have a "natural" id.

> - dmx_decoder_t can be split into just a single type of every decoder and
> then adding a new uint32_t dec_num; field. Dunno what is more reasonable.

I don't like the dmx_decoder_t at all.

IMHO one should be able to say "I want data passed to userspace, please
allocate buffers for that", or "data will go to the MPEG decoder or the
HDD directly".

Data could go to both MPEG decoder and HDD. The demux should assign
a logical output_channel_id to the filter, and the MPEG decoder
would support a VIDEO/AUDIO_SET_SOURCE ioctl to connect the two.
If we eventually support direct to HDD stream recording this
would connect via the same mechanism.


> - I've added an fe_map in favour to a SELECT_SOURCE IOCTL. Makes more sense
> i think. Now you can select the fe on the fly.

I don't like it.
The problem here is that (depends on the hardware) the demux
can only process a limited number of input streams out of a larger
selection. If you need to switch the input routing it affects
all other filters of the same demux device.

That why a seperate DMX_SELECT_SOURCE is IMHO better.

Then we have input routing, filter specificaton and output routing
logically separated in the API. Just like when you draw a diagram of
you STB on paper you have sperate boxes for FE, demux, MPEG, HDD, ...
and then you connect them as appropriate. You roll it all in
one mega ioctl.


Regards,
Johannes


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