Em Fri, 1 Dec 2017 12:38:14 +0100 pieterg <piet...@gmx.com> escreveu:
> Hi, > > The recent removal of DMX_SET_SOURCE > > https://github.com/torvalds/linux/commit/13adefbe9e566c6db91579e4ce17f1e5193d6f2c > > and earlier removal of the set_source callback > > https://github.com/torvalds/linux/commit/1e92bbe08ad9fc0d5ec05174c176a9bc54921733 > > leads to the question how the situation of having multiple frontends on > a single dvb adapter should be handled nowadays. > Suppose the routing is flexible, any demux could be sourced by any frontend. > In the past, this has been achieved by using the set_source callback, > allowing userspace to configure the routing by using the DMX_SET_SOURCE > ioctl. > > The connect_frontend / disconnect_frontend callbacks are currently only > called for the memory frontend, so it seems no longer possible to select > hardware frontends. > How do you guys see this, what does the standard dictate in this case? > Should we assume a 1:1 mapping between frontendN:demuxN and forbid > dynamic routing? Or am I overlooking something? > > In my opinion, supporting dynamic routing would be an advantage. > Especially when the number of (hardware) demuxes is smaller than the > number of (hardware) frontends. The best way to support dynamic routing is via the media controller API. the DVB core already creates media controller entities for the existing hardware, but the links for the non-trivial case (e. g. there's no 1:1 mapping) should be created by the driver. The big advantage of using the media controller is that you could dynamically setup the pipeline, not only between frontend and demux, but also with some other hardware. For example, with that, you could easily add a CI module at the pipeline, for an scrambled channel, or remove it, when the channel doesn't require, or when it is required to store a movie scrambled (that's usually required for embedded systems). At reproduction, a pipeline with the CI descrambler could be used. Thanks, Mauro
