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@xxxxxxxxxxx/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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
