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

["Haber, Thomas" <THaber@tee.toshiba.de>]

Johannes Stezenbach wrote:
> 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
> 

I think connecting elements in the current api is a major problem.
Posix does not provide a mechanism to do this, but in a streaming media 
environment this is pretty needed!
We have device elements like decoders that we currently refer by a fixed id.
The id is implicitly linked to a device (I don't like this).
And we have elements like filters that starts their life after opening 
a device. Handles to use for identifying is not a good idea from my 
point of view cause differnt handles may refer to the same element.

So my poor proposal: 

typedef enum {
    DVB_STREAM_PES,                                        
    DVB_STREAM_ES,                                         
    DVB_STREAM_TS,                                          
    DVB_STREAM_PS,                                        
    DVB_STREAM_xxx                                         
} dvb_stream_format_t;

defines the type of a stream.

typedef enum {
    DVB_SOURCE_DEVICE,                                     
    DVB_SOURCE_WRITE                                     
} dvb_source_type_t;

says if we want to use write on the handle or if we want to connect it to a source.
In this scenario we allways connect elements from the sink to the source.

struct dvb_stream_source { 
      dvb_source_type_t source_type;                 
       union { 
              dvb_stream_format_t stream_format;              
              unsigned int        element_id;                      
	} u; 
};

is used to set the source.
So in the video decoder you say VIDEO_SET_SOURCE with the filter id inside.
You may do the same in the demux to connect to the frontend. 

 
We get the element id by 

  DMX_GET_ELEMENT_ID
  VIDEO_GET_ELEMENT_ID
  FE_GET_ELEMENT_ID
   ...

Remains the question how we refer to the demux (the demux itself) and to its filters.
I think the readwrite handle (only one) should be used for the demux itself. It can be used for writing TS to it.
The ReadOnly ones should reflect the filters where we may want to read from (section data,..).
SET_SOURCE is only possible on the readwrite handle.


Best Regards,

Thomas

 

. 

  


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