Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: V4 API proposal



Haber, Thomas wrote:
> 
> For sure section filtering is very special due to its 
> header filtering. PID and stream_id filtering seems to be 
> very common. 
> We could put the sub stream id together 
> with the stream_id in one word or we use the header filtering.
> 
> so we get :
> struct dmx_filter_params
> {
> 	uint16_t            id;
> 	uint32_t            flags;
> 
> 	dmx_input_t         input; -> remove
> 	dmx_output_t        output; -> remove !?
> 	dmx_pes_type_t      pes_type; -> needed ???
> };  
> 
> with
> 
> DMX_SET_FILTER
> 
> and 
> struct dmx_ext_filter_params
> {
> 	uint16_t            id;
> 	uint32_t            flags;
> 	dmx_header_filter_t header_filter;
> 
> 	dmx_input_t         input; -> remove
> 	dmx_output_t        output; -> remove !?
> 	dmx_pes_type_t      pes_type; -> needed ???
> };  
> 
> with
> 
> DMX_SET_EXT_FILTER ???
> 
> (Could be also used for PES ???)

Question: Is there hardware support for dmx_header_filter_t? If not we
should not add DMX_SET_EXT_FILTER to the API, let the application/middleware
do it. We could add DMX_PAYLOAD_ONLY (and DMX_HEADER_ONLY?) to the flags
for DMX_SET_FILTER, though (if it makes sense).

One other thing:
Currently the API makes no guarantee on data alignment when you read()
PES data from the demux. For sections, it is guaranteed that each read()
wil get exactly one section with the start of the section at the start
of the buffer, provided the buffer is large enough. If the buffer is too
small, consecutive read()s will get the remainder of the section.

We could try to do the same for PES filters, or shouldn't we?

(Currently middleware code that deals with PES filter output must search
for the PES packet start code manually; that sucks.)

Johannes


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



Home | Main Index | Thread Index