[linux-dvb] Re: Why no more than 3 PID filters

["Delaunay Christophe" <christophe.delaunay@thomson.net>]

Hi Johannes,

Many thanks for your reply in which I read :

>Delaunay Christophe wrote:
>> Since I wanted to play several services from the same transport stream
>> to different socket, I tried to use "dmx_pes_filter"s, (one per PID I
>> want to play).

>Look at dvb-apps/test/test_dvr.c.

This app is just fine for playing a single service.

>Note that the current API is somewhat limited in that all DMX_OUT_TS_TAP
>packets go to a single dvr device, hence you must post-demux in software
>if you want to stream different programs to a different socket.

And that's why I could not figure out how to use it as is. These is probably the source of my mistake.

Here is what I tried to do in order to work around this.

First, my idea was to patch the demux in such a way that it could send data to a buffer, exactly as it does when we define a PES filter with the "DMX_OUT_TAP" but the data in the buffer would be full TS packet, like if we use "DMX_OUT_TS_TAP".

First, I tried to add a new value in the dmx_output_t enum defined in "linuxtv-dvb-1.1.1/linux/include/linux/dvb/dmx.h". I named "DMX_OUT_TS_BUF".

Then, I tried to modify two functions in "linuxtv-dvb-1.1.1/linux/drivers/media/dvb/dvb-core/dmx_dev.c".

The first one is "dvb_dmxdev_ts_callback". At line 399 of the file, I could read :

	if ( dmxdevfilter->params.pes.output == DMX_OUT_TAP )

I replaced it with the two following ones :

	if ( dmxdevfilter->params.pes.output == DMX_OUT_TAP
		|| dmxdevfilter->params.pes.output == DMX_OUT_TS_BUF )

This way, I thought next statements, which assigns the buffer to which the demux will send its data, would be executed either for a regular "DMX_OUT_TAP" output type or for my own "DMX_OUT_TS_BUF" output type.

In fact, it is. I can notice it within my application.

The second function I modified is "dvb_dmxdev_filter_start".

At line 653, in a switch on "filter->type", case "DMXDEV_TYPE_PES", I can read

		if ( otype == DMX_OUT_TS_TAP )

I replaced this line with the two following ones :

		if ( otype == DMX_OUT_TS_TAP
			|| otype == DMX_OUT_TS_BUF )

This way, I thought that the "ts_type |= TS_PACKET" statement would be executed either if the output type is the regular "DMX_OUT_TS_TAP" defined in the API, or if the output type is my own "DMX_OUT_TS_BUF".

In fact, it is also.

These are the only two files I modified before recompiling the driver and running the "insmod.sh load" command.

Now, when I open one, two or three demux filters with an output type of "DMX_OUT_TS_BUF", I can "read()" full TS packets from their respective file descriptors.

I can then open a fourth demux filter, perform the ioctl which sets its parameters and starts it, but when I then try to "read()" from its file descriptor, I am back with a "Bad file descriptor" error.

Of course, I know this is not so clean but (1) it was for test purposes only and (2) I really can't figure out how such minor modifications would so deeply interact with the overall behaviour of the driver. What happens that I did not take into account ?

>The V4 API attempts to improve on this (but the public prototype driver
>is no necessarily functional).

Please, how does it manage to propose an equivalent behaviour ?

Many thanks. Have a nice day. Chris