Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Andreas Oberritter wrote:
> Hello Andy,
> 
> Andy Walls wrote:
>> After investigation, my recommendation for fixing the problem is to
>> revert the patch that is causing the problem.

Well, the patch were already added on an upstream kernel, so just reverting it
will cause regressions.

If it is just aletv-dvb that broke, it seems better to fix it than to cause 
even more troubles by reverting two new ioctls.

>> The reason for this is not that fixing the patch is impossible.

Why? Where exactly the breakage happened?

>> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
>> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
>> demux0 device into multiple dynamically created anonymous dvr0 devices,
>> and that is the wrong thing to do.
> 
> why exactly do you think this is wrong?
> 
>> I understand the need for sending a single PID TS out to an open demux0
>> instance as described in this email:
>>
>> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
>>
>> even though it seems like a slight abuse of the demux0 device.
> 
> How so? It's all about reading demultiplexed packets, which is exactly
> what a demux is good for. There is btw. no other way for multiple
> readers to receive TS packets without implementing a second demux
> layer in a userspace daemon, which must then be used by all readers.
> This would needlessly create quite some overhead on high bandwidth
> services.
>> But sending multiple PIDs out in a TS to the open demux0 device instance
>> is just an awkward way to essentially dynamically create a dvrN device
>> associated with filter(s) set on an open demux0 instance.
> 
> Actually it makes dvrN obsolete, but it must of course be kept for
> backwards compatibility.
> 
>> It would be better, in my opinion, to figure out a way to properly
>> create and/or associate a dvrN device node with a collection of demuxN
>> filters.
> 
> Would this involve running mknod for every recording you start?
> 
>> Maybe just allow creation of a logical demux1 device and dvr1 device and
>> the use the DVB API calls as is on the new logical devices.
> 
> A demux device (and dvr respectively) represents a transport stream
> input. Hardware with multiple transport stream inputs (read: embedded
> set top boxes) already has multiple demux and dvr devices.


Andreas arguments makes sense to me.

 
>> I'm not a DVB apps programmer, so I don't know all the userspace needs
>> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
>> ioctl()s.
> 
> The need for such an interface was already pointed out and discussed
> back in 2006:
> http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html
> 
> As Honza noted, these ioctls are used by enigma2 and, in general, by
> software running on Dream Multimedia set top boxes. I'm sure, other
> projects are going to adopt this interface sooner or later. It is
> still quite new after all.


It seems too late for me to revert it. So, we need to figure out a way
to workaround it or to fix the applications that got broken by this change.

-- 

Cheers,
Mauro