Support for multiple section feeds with same PIDs

Support for multiple section feeds with same PIDs

[Hamad Kadmany]

Hello

Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c)

In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections
feeds allocated (allocate_section_feed) with same PID. From my experience,
applications might request allocating several section feeds using same PID
but with different filters (for example, in DVB standard, SDT and BAT tables
have same PID).

The current implementation only supports of having multiple filters on the
same section feed. 

Any special reason why it was implemented this way?

Thank you
Hamad

RE: Support for multiple section feeds with same PIDs

[Hamad Kadmany]

Hi,

Sorry to repeat the question, anyone has an idea on this? I appreciate your
feedback.

Thank you
Hamad

-----Original Message-----
From: linux-media-owner@vger.kernel.org
[mailto:linux-media-owner@vger.kernel.org] On Behalf Of Hamad Kadmany
Sent: Tuesday, November 29, 2011 10:05 AM
To: linux-media@vger.kernel.org
Subject: Support for multiple section feeds with same PIDs

Hello

Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c)

In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections
feeds allocated (allocate_section_feed) with same PID. From my experience,
applications might request allocating several section feeds using same PID
but with different filters (for example, in DVB standard, SDT and BAT tables
have same PID).

The current implementation only supports of having multiple filters on the
same section feed. 

Any special reason why it was implemented this way?

Thank you
Hamad

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Support for multiple section feeds with same PIDs

[Mauro Carvalho Chehab]

On 01-12-2011 04:23, Hamad Kadmany wrote:
> Hi,
>
> Sorry to repeat the question, anyone has an idea on this? I appreciate your
> feedback.
>
> Thank you
> Hamad
>
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org
> [mailto:linux-media-owner@vger.kernel.org] On Behalf Of Hamad Kadmany
> Sent: Tuesday, November 29, 2011 10:05 AM
> To: linux-media@vger.kernel.org
> Subject: Support for multiple section feeds with same PIDs
>
> Hello
>
> Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c)
>
> In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections
> feeds allocated (allocate_section_feed) with same PID. From my experience,
> applications might request allocating several section feeds using same PID
> but with different filters (for example, in DVB standard, SDT and BAT tables
> have same PID).
>
> The current implementation only supports of having multiple filters on the
> same section feed.
>
> Any special reason why it was implemented this way?

Eventually, you might be able to find some reason by digging into the patches
that introduced such feature. If this went before 2.6.12-rc2, you'll need to
take a look at the Linux history git trees or at the mercurial tree.

In any case, if you need to extend it to support multiple sections, just
propose a patch extending it, yet maintaining backward compatibility with the
existing behavior.

Regards,
Mauro.

>
> Thank you
> Hamad
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Support for multiple section feeds with same PIDs

[Andreas Oberritter]

Hello Hamad,

On 29.11.2011 09:05, Hamad Kadmany wrote:
> Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c)
> 
> In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections
> feeds allocated (allocate_section_feed) with same PID. From my experience,
> applications might request allocating several section feeds using same PID
> but with different filters (for example, in DVB standard, SDT and BAT tables
> have same PID).
> 
> The current implementation only supports of having multiple filters on the
> same section feed. 
> 
> Any special reason why it was implemented this way?

AFAIR, if you created more than one PID filter on the same PID, only one
filter would see data on most or all hardware back then. So if you have
multiple filters on the same PID, then the real filter you're setting
should be a merged version of those filters. If you use dvb_demux, it
will do the necessary post-processing for you.

This driver implements section filtering:
http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/dvb/drivers/media/dvb/avia/avia_gt_napi.c?rev=1.208&view=markup

Regards,
Andreas

RE: Support for multiple section feeds with same PIDs

[Hamad Kadmany]

Hello Andreas

So if I understand correctly due to HW limitations back then, if in
user-space we want to get data of two PSI tables that share the same PID, we
could only setup one section filter with that PID and the user-space needs
to do the extra filtering (to parse and separate the sections belonging to
each table)?

Regards,
Hamad

-----Original Message-----
From: linux-media-owner@vger.kernel.org
[mailto:linux-media-owner@vger.kernel.org] On Behalf Of Andreas Oberritter
Sent: Thursday, December 01, 2011 3:37 PM
To: Hamad Kadmany
Cc: linux-media@vger.kernel.org
Subject: Re: Support for multiple section feeds with same PIDs

Hello Hamad,

On 29.11.2011 09:05, Hamad Kadmany wrote:
> Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c)
> 
> In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections
> feeds allocated (allocate_section_feed) with same PID. From my experience,
> applications might request allocating several section feeds using same PID
> but with different filters (for example, in DVB standard, SDT and BAT
tables
> have same PID).
> 
> The current implementation only supports of having multiple filters on the
> same section feed. 
> 
> Any special reason why it was implemented this way?

AFAIR, if you created more than one PID filter on the same PID, only one
filter would see data on most or all hardware back then. So if you have
multiple filters on the same PID, then the real filter you're setting
should be a merged version of those filters. If you use dvb_demux, it
will do the necessary post-processing for you.

This driver implements section filtering:
http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/dvb/drivers/media/dv
b/avia/avia_gt_napi.c?rev=1.208&view=markup

Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Support for multiple section feeds with same PIDs

[Andreas Oberritter]

On 01.12.2011 14:55, Hamad Kadmany wrote:
> So if I understand correctly due to HW limitations back then, if in
> user-space we want to get data of two PSI tables that share the same PID, we
> could only setup one section filter with that PID and the user-space needs
> to do the extra filtering (to parse and separate the sections belonging to
> each table)?

No. dvb_demux will do the extra filtering. Userspace won't notice.

Regards,
Andreas

RE: Support for multiple section feeds with same PIDs

[Hamad Kadmany]

Hello Andreas

On 01.12.2011 15:58, Andreas Oberritter wrote:

> No. dvb_demux will do the extra filtering. Userspace won't notice.

Got it now, thanks. The one downside I see to this is that the feed will be
stopped momentarily (dvb_dmxdev_feed_stop) before new filter is allocated
that have the same PID.

Regards,
Hamad

Re: Support for multiple section feeds with same PIDs

[Andreas Oberritter]

On 01.12.2011 15:22, Hamad Kadmany wrote:
> Hello Andreas
> 
> On 01.12.2011 15:58, Andreas Oberritter wrote:
> 
>> No. dvb_demux will do the extra filtering. Userspace won't notice.
> 
> Got it now, thanks. The one downside I see to this is that the feed will be
> stopped momentarily (dvb_dmxdev_feed_stop) before new filter is allocated
> that have the same PID.

Yes. Feel free to enhance the demux API to your needs in order to fully
support the features of your hardware.

Regards,
Andreas

RE: Support for multiple section feeds with same PIDs

[Hamad Kadmany]

Hello Andreas
 
> On 01.12.2011 16:30, Andreas Oberritter wrote:

> Yes. Feel free to enhance the demux API to your needs in order to fully
> support the features of your hardware.

I have another question in that regard: Actually, multiple filter with same
PID is assumed to be possible in case we have one filter for TS packets (for
DVR device) and another for video PES (for playback). So it seems there's
such assumption in this regard but not for sections. Is my understanding
correct?

Regards,
Hamad

Re: Support for multiple section feeds with same PIDs

[Andreas Oberritter]

On 01.12.2011 16:57, Hamad Kadmany wrote:
> Hello Andreas
>  
>> On 01.12.2011 16:30, Andreas Oberritter wrote:
> 
>> Yes. Feel free to enhance the demux API to your needs in order to fully
>> support the features of your hardware.
> 
> I have another question in that regard: Actually, multiple filter with same
> PID is assumed to be possible in case we have one filter for TS packets (for
> DVR device) and another for video PES (for playback). So it seems there's
> such assumption in this regard but not for sections. Is my understanding
> correct?

The in-kernel software demux ("dvb_demux") receives TS packets and
strips off headers as requested in order to convert TS to PES or
sections. If you're implementing a driver, you can choose to either
extend the software demux by overwriting its
{allocate,release}_{ts,section}_feed function pointers or you can
replace the software demux completely, using your own functions.

That said, the software demux supports multiple filters of any type
simultaneously on the same PID, so whether it will work for you will
eventually depend on your implementation.

It's definitely easier to extend the sofware demux, but replacing it may
possibly allow you use your hardware more efficiently.

I think the av7110 driver also implements section filters, as a further
example.

Regards,
Andreas

[dvb] Problem registering demux0 device

[Hamad Kadmany]

Hi,

I'm implementing new adapter for DVB, I built a module to register the
adapter and demux/net devices. From the kernel log I see all actions are
performed fine and dvb_register_device (called by dvb_dmxdev_init) is called
successfully for net0/demux0/dvr0, however, demux0/dvr0 devices do not show
up, "ls /sys/class/dvb" shows only dvb0.net0 (and nothing appears under
/dev/dvb/ anyhow).

What could cause not having demux0/dvr0 registered? Note that net0 shows up
fine.

Appreciate your help.

Thanks
Hamad

Re: [dvb] Problem registering demux0 device

[Mauro Carvalho Chehab]

On 07-12-2011 09:30, Hamad Kadmany wrote:
> Hi,
>
> I'm implementing new adapter for DVB, I built a module to register the
> adapter and demux/net devices. From the kernel log I see all actions are
> performed fine and dvb_register_device (called by dvb_dmxdev_init) is called
> successfully for net0/demux0/dvr0, however, demux0/dvr0 devices do not show
> up, "ls /sys/class/dvb" shows only dvb0.net0 (and nothing appears under
> /dev/dvb/ anyhow).
>
> What could cause not having demux0/dvr0 registered? Note that net0 shows up
> fine.

It is hard to tell the exact problem without looking into the driver. Are you
handling the error codes returned by the register functions?

You can follow what's happening inside your driver by enabling tracepoints.
Here is one of the scripts I used when I need to know what functions are
called:

	#!/bin/bash
	cd /sys/kernel/debug/tracing

	echo disabling trace
	echo 0 > tracing_enabled
	echo getting funcs
	FUNC="`cat /sys/kernel/debug/tracing/available_filter_functions|grep -i drx`"

	echo setting functions
	echo $FUNC>set_ftrace_filter
	echo set trace type
	echo function_graph > current_tracer
	echo enabling trace
	echo 1 > tracing_enabled

(the above enables tracing only for functions with "drx" in the name - you'll
need to tailor it for your specific needs)

Of course, after finishing the device creation, you should disable the trace and
get its results with:

	#!/bin/bash
	cd /sys/kernel/debug/tracing
	echo 0 > tracing_enabled
	less trace

I suggest you to compare the trace for a device that is known to create all dvb
nodes with your driver. This may give you a good hint about what is missing on
your driver.

Regards,
Mauro

RE: [dvb] Problem registering demux0 device

[Hamad Kadmany]

On 07-12-2011 13:50, Mauro Carvalho Chehab wrote:
> It is hard to tell the exact problem without looking into the driver. Are you
> handling the error codes returned by the register functions?
>
> You can follow what's happening inside your driver by enabling tracepoints.
> Here is one of the scripts I used when I need to know what functions are
> called:
>
>	#!/bin/bash
>	cd /sys/kernel/debug/tracing
>
>	echo disabling trace
>	echo 0 > tracing_enabled
>	echo getting funcs
>	FUNC="`cat /sys/kernel/debug/tracing/available_filter_functions|grep -i drx`"
>
>	echo setting functions
>	echo $FUNC>set_ftrace_filter
>	echo set trace type
>	echo function_graph > current_tracer
>	echo enabling trace
>	echo 1 > tracing_enabled
>
> (the above enables tracing only for functions with "drx" in the name - you'll
> need to tailor it for your specific needs)

> Of course, after finishing the device creation, you should disable the trace and
> get its results with:
>
>	#!/bin/bash
>	cd /sys/kernel/debug/tracing
>	echo 0 > tracing_enabled
>	less trace
>
> I suggest you to compare the trace for a device that is known to create all dvb
> nodes with your driver. This may give you a good hint about what is missing on
> your driver.
>
> Regards,
> Mauro

I'm checking return error codes, no problems there, I also added traces within the register functions and they all run fine. Here's my code that registers the demux device (note that the net device works fine):

static struct dvb_demux demux;
static struct dmxdev dmxdev;
static struct dvb_net net;
static struct dmx_frontend fe_hw;
static struct dmx_frontend fe_mem;

static int test_start_feed(struct dvb_demux_feed *feed)
{
	printk(KERN_INFO "%s executed\n", __FUNCTION__);
	return 0;
}

static int test_stop_feed(struct dvb_demux_feed *feed)
{
	printk(KERN_INFO "%s executed\n", __FUNCTION__);
	return 0;
}

static int test_write_to_decoder(struct dvb_demux_feed *feed, const u8 *buf, size_t len)
{
	printk(KERN_INFO "%s executed\n", __FUNCTION__);
	return 0;
}
	
// initialization specific demux device
void test_demux_device_init(struct dvb_adapter* adapter)
{
	int result;

	printk(KERN_INFO "%s executed\n", __FUNCTION__);
	
	memset(&demux, 0, sizeof(struct dvb_demux));

	demux.dmx.capabilities = DMX_TS_FILTERING | 
					  DMX_PES_FILTERING |
					  DMX_SECTION_FILTERING | 
					  DMX_MEMORY_BASED_FILTERING |
					  DMX_CRC_CHECKING | 
					  DMX_TS_DESCRAMBLING;

	demux.priv = NULL;	
	demux.filternum = 31;
	demux.feednum = 31;
	demux.start_feed = test_start_feed;
	demux.stop_feed = test_stop_feed;
	demux.write_to_decoder = test_write_to_decoder;

	printk(KERN_INFO "%s call dvb_dmx_init\n", __FUNCTION__);
	
	if ((result = dvb_dmx_init(&demux)) < 0) 
	{
		printk(KERN_ERR "%s: dvb_dmx_init failed\n", __FUNCTION__);
		goto init_failed;
	}

	dmxdev.filternum = 31;
	dmxdev.demux = &demux.dmx;
	dmxdev.capabilities = 0;

	printk(KERN_INFO "%s call dvb_dmxdev_init\n", __FUNCTION__);
	
	if ((result = dvb_dmxdev_init(&dmxdev, adapter)) < 0) 
	{
		printk(KERN_ERR "%s: dvb_dmxdev_init failed (errno=%d)\n", __FUNCTION__, result);
		goto init_failed_dmx_release;
	}

	fe_hw.source = DMX_FRONTEND_0;

	printk(KERN_INFO "%s call add_frontend\n", __FUNCTION__);
	
	if ((result = demux.dmx.add_frontend(&demux.dmx, &fe_hw)) < 0) 
	{
		printk(KERN_ERR "%s: add_frontend (hw) failed (errno=%d)\n", __FUNCTION__, result);
		goto init_failed_dmxdev_release;
	}

	fe_mem.source = DMX_MEMORY_FE;

	if ((result = demux.dmx.add_frontend(&demux.dmx, &fe_mem)) < 0) 
	{
		printk(KERN_ERR "%s: add_frontend (mem) failed (errno=%d)\n", __FUNCTION__, result);
		goto init_failed_remove_hw_frontend;
	}

	if ((result = demux.dmx.connect_frontend(&demux.dmx, &fe_hw)) < 0) 
	{
		printk(KERN_ERR "%s: connect_frontend failed (errno=%d)\n", __FUNCTION__, result);
		goto init_failed_remove_mem_frontend;
	}
	
	if ((result = dvb_net_init(adapter, &net, &demux.dmx)) < 0) 
	{
		printk(KERN_ERR "%s: dvb_net_init failed (errno=%d)\n", __FUNCTION__, result);
		goto init_failed_disconnect_frontend;
	}
	
init_failed_disconnect_frontend:
	demux.dmx.disconnect_frontend(&demux.dmx);
init_failed_remove_mem_frontend:
	demux.dmx.remove_frontend(&demux.dmx, &fe_mem);
init_failed_remove_hw_frontend:
	demux.dmx.remove_frontend(&demux.dmx, &fe_hw);
init_failed_dmxdev_release:
	dvb_dmxdev_release(&dmxdev);
init_failed_dmx_release:
	dvb_dmx_release(&demux);
init_failed:
	return;
}
EXPORT_SYMBOL(test_demux_device_init);

// terminate specific demux device
void test_demux_device_terminate(struct dvb_adapter* adapter)
{
	dvb_net_release(&net);
	demux.dmx.close(&demux.dmx);
	demux.dmx.disconnect_frontend(&demux.dmx);
	demux.dmx.remove_frontend(&demux.dmx, &fe_mem);
	demux.dmx.remove_frontend(&demux.dmx, &fe_hw);
	dvb_dmxdev_release(&dmxdev);
	dvb_dmx_release(&demux);
}
EXPORT_SYMBOL(test_demux_device_terminate);

Thanks,
Hamad