MediaController support in LinuxDVB demux

MediaController support in LinuxDVB demux

[Alain VOLMAT]

Hi

Last week we started the discussion about having a MediaController aware LinuxDVB demux and I would like to proceed on this discussion.
Then, the discussion rapidly moved to having the requirement for dynamic pads in order to be able to add / remove then in the same way as demux filters are created for each open of the demux device node.

I am not really sure dynamic pads is really a MUST for MC aware demux device. The demux entity could work with a predefined number of output pads, determined by the vendor, depending on the demux capacity of the device.
Of course it is probably better to have only pads when needed but it requires quite a lot of change to the overall MC framework and such modification could be done afterward, when the MC support for LinuxDVB is much better understood.

During last workshop, I think we agreed that a pad would represent a demux filter. 
My personal idea would be to have filters created via the demux device node and filters accessible via MC pads totally independent. 
Meaning that, just as current demux, it is possible to open the demux device node, create filter, set PIDs etc. Those filters have totally no relation with MC pads, filters created via the demux device node are just not accessible via MC pads.
As far as demux MC pads are concerned, it would be possible to link a pad to another entity pad (probably decoder or LinuxDVB CA) and thus create a new filter in the demux. By setting the demux MC pad format (not sure format is the proper term here), it would be possible to set for example the PID of a filter.
Internally of course all filters (MC filters and demux device node filters) are all together but they are only accessible via either the demux device node or the MC pad.

What are your thoughts about that ?

Regards,

Alain

Re: MediaController support in LinuxDVB demux

[Mauro Carvalho Chehab]

Em 03-11-2011 07:16, Alain VOLMAT escreveu:
> Hi
> 
> Last week we started the discussion about having a MediaController aware LinuxDVB demux and I would like to proceed on this discussion.
> Then, the discussion rapidly moved to having the requirement for dynamic pads in order to be able to add / remove then in the same way as demux filters are created for each open of the demux device node.
> 
> I am not really sure dynamic pads is really a MUST for MC aware demux device. The demux entity could work with a predefined number of output pads, determined by the vendor, depending on the demux capacity of the device.

It sounds like a plan to me.

> Of course it is probably better to have only pads when needed but it requires quite a lot of change to the overall MC framework and such modification could be done afterward, when the MC support for LinuxDVB is much better understood.

Changing the userspace API is something that should be done with care. E. g., we
should be sure that it won't break binary userspace compatibility if we change it
later.

> 
> During last workshop, I think we agreed that a pad would represent a demux filter. 
> My personal idea would be to have filters created via the demux device node and filters accessible via MC pads totally independent. 
> Meaning that, just as current demux, it is possible to open the demux device node, create filter, set PIDs etc. Those filters have totally no relation with MC pads, filters created via the demux device node are just not accessible via MC pads.
> As far as demux MC pads are concerned, it would be possible to link a pad to another entity pad (probably decoder or LinuxDVB CA) and thus create a new filter in the demux. By setting the demux MC pad format (not sure format is the proper term here), it would be possible to set for example the PID of a filter.
> Internally of course all filters (MC filters and demux device node filters) are all together but they are only accessible via either the demux device node or the MC pad.

We need to think a little more about that. In principle, it doesn't sound a good idea
to me to have filters mutually exclusive to one of the API's, but maybe there are
some implementation and/or API specific details that might force us to get on this
direction.

So, I'd say that we should try to write a patch for it first, trying to allow
setting it via both API's and then discuss about implementation-specific issues,
if this is not feasible, or would be very messy.
> 
> What are your thoughts about that ?
> 
> Regards,
> 
> Alain
> --
> 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: MediaController support in LinuxDVB demux

[Alain VOLMAT]

Hi Mauro

> > During last workshop, I think we agreed that a pad would represent a
> demux filter.
> > My personal idea would be to have filters created via the demux
> device node and filters accessible via MC pads totally independent.
> > Meaning that, just as current demux, it is possible to open the demux
> device node, create filter, set PIDs etc. Those filters have totally no
> relation with MC pads, filters created via the demux device node are
> just not accessible via MC pads.
> > As far as demux MC pads are concerned, it would be possible to link a
> pad to another entity pad (probably decoder or LinuxDVB CA) and thus
> create a new filter in the demux. By setting the demux MC pad format
> (not sure format is the proper term here), it would be possible to set
> for example the PID of a filter.
> > Internally of course all filters (MC filters and demux device node
> filters) are all together but they are only accessible via either the
> demux device node or the MC pad.
> 
> We need to think a little more about that. In principle, it doesn't
> sound a good idea
> to me to have filters mutually exclusive to one of the API's, but maybe
> there are
> some implementation and/or API specific details that might force us to
> get on this
> direction.

The reason why I propose to have mutex mutually exclusive is that I think it is hard to figure out the relation between a file handle and a PAD.
Meaning, you could open the demux device file, then create a filter and set a PID for instance but how would you figure out which pad is corresponding to the filter you've just created via the demux device file. Having MC filters and demux device node filter separately also help not to break existing LinuxDVB demux API.

> So, I'd say that we should try to write a patch for it first, trying to
> allow
> setting it via both API's and then discuss about implementation-
> specific issues,
> if this is not feasible, or would be very messy.

Currently, of drivers integrated in upstream linux, I guess that only the av7110 driver (too old right) is actually having the demux output pushed to something other than user land right ? (in this case the decoder). Implementing MC support for the kernel demux driver would be possible I think but probably not really meaningful since having pads wouldn't help much ...

Regards,

Alain

Re: MediaController support in LinuxDVB demux

[Mauro Carvalho Chehab]

Em 03-11-2011 12:05, Alain VOLMAT escreveu:
> Hi Mauro
> 
>>> During last workshop, I think we agreed that a pad would represent a
>> demux filter.
>>> My personal idea would be to have filters created via the demux
>> device node and filters accessible via MC pads totally independent.
>>> Meaning that, just as current demux, it is possible to open the demux
>> device node, create filter, set PIDs etc. Those filters have totally no
>> relation with MC pads, filters created via the demux device node are
>> just not accessible via MC pads.
>>> As far as demux MC pads are concerned, it would be possible to link a
>> pad to another entity pad (probably decoder or LinuxDVB CA) and thus
>> create a new filter in the demux. By setting the demux MC pad format
>> (not sure format is the proper term here), it would be possible to set
>> for example the PID of a filter.
>>> Internally of course all filters (MC filters and demux device node
>> filters) are all together but they are only accessible via either the
>> demux device node or the MC pad.
>>
>> We need to think a little more about that. In principle, it doesn't
>> sound a good idea
>> to me to have filters mutually exclusive to one of the API's, but maybe
>> there are
>> some implementation and/or API specific details that might force us to
>> get on this
>> direction.
> 
> The reason why I propose to have mutex mutually exclusive is that I think it is hard to figure out the relation between a file handle and a PAD.
> Meaning, you could open the demux device file, then create a filter and set a PID for instance but how would you figure out which pad is corresponding to the filter you've just created via the demux device file. Having MC filters and demux device node filter separately also help not to break existing LinuxDVB demux API.

On the other hand, we'll have troubles with existing applications if this is not implemented.
So, we'll need anyway to associate a PID filter with a DVBv5 call. At V4L, this will be solved
via v4l-utils. We probably need to discuss it better for DVB.


> 
>> So, I'd say that we should try to write a patch for it first, trying to
>> allow
>> setting it via both API's and then discuss about implementation-
>> specific issues,
>> if this is not feasible, or would be very messy.
> 
> Currently, of drivers integrated in upstream linux, I guess that only the av7110 driver (too old right) is actually having the demux output pushed to something other than user land right ? (in this case the decoder). Implementing MC support for the kernel demux driver would be possible I think but probably not really meaningful since having pads wouldn't help much ...

Yes, only av7110 uses it. Well, let's first add MC support to DVB. We can take care
of the details like that when we'll have something coded.

> Regards,
> 
> Alain
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{���bj)���w*\x1fjg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥

Re: MediaController support in LinuxDVB demux

[Patrick Boettcher]

Hi Alain,

On Thursday 03 November 2011 10:16:25 Alain VOLMAT wrote:
> Hi
> 
> Last week we started the discussion about having a MediaController
> aware LinuxDVB demux and I would like to proceed on this discussion.
> Then, the discussion rapidly moved to having the requirement for
> dynamic pads in order to be able to add / remove then in the same
> way as demux filters are created for each open of the demux device
> node.
> 
> I am not really sure dynamic pads is really a MUST for MC aware demux
> device. The demux entity could work with a predefined number of
> output pads, determined by the vendor, depending on the demux
> capacity of the device. Of course it is probably better to have only
> pads when needed but it requires quite a lot of change to the
> overall MC framework and such modification could be done afterward,
> when the MC support for LinuxDVB is much better understood.

I insert my comments and questions here, because the last words are 
reflecting my thoughts very well I think. I'm talking about "... when 
the MC support for LinuxDVB is much better understood":

I, for myself, haven't had yet the opportunity to look very closely to 
the MC-implementation in V4l until now. From what I understand it is 
flexible framework which enables precise abstractions of data-flows and 
data-routing between hard- and software components of a "multimedia"-
device.

Extending such a thing to LinuxDVB seems of course a good idea, because 
as of today we are missing some flexibility in this area. One problem 
for example I faced in the past was the correct (from user-space) 
support for multiple frontends which can either do diversity to improve 
reception quality or be standalone receivers (each frontend decodes the 
MPEG2-TS). 

I'm sure that there are other examples which are more common which 
express the need to have MC in DVB.

Would it be a problem for you to elaborate a little bit more around the 
why and how and what around MC in DVB? Before starting to implement it 
like Mauro suggested. Could you go more in detail for you actual problem 
(like what is missing in the current dvb-demux)? 

I think it is absolutely necessary to know more about the reasoning 
around MC - as it has a big potential - before any implementation.

Maybe there are some block-diagrams and presentations around somewhere. 
Until now I only saw this Email-thread and this: 
http://www.linuxtv.org/events.php (at the very bottom).

Thanks in advance.

best regards
--
Patrick Boettcher

Kernel Labs Inc.
http://www.kernellabs.com/

RE: MediaController support in LinuxDVB demux

[Alain VOLMAT]

Hi Patrick,

> Would it be a problem for you to elaborate a little bit more around 
> the why and how and what around MC in DVB? Before starting to 
> implement it like Mauro suggested. Could you go more in detail for you 
> actual problem (like what is missing in the current dvb-demux)?
> 
> I think it is absolutely necessary to know more about the reasoning 
> around MC - as it has a big potential - before any implementation.
> 
> Maybe there are some block-diagrams and presentations around somewhere.
> Until now I only saw this Email-thread and this:
> http://www.linuxtv.org/events.php (at the very bottom).

Unfortunately, the slides we presented last month in Prague are not available online.
In our SoCs, it is possible to create one or several PES filters from one or multiple demux devices. Those PES can then be either pulled to user space via the demux or dvr device node or tunneled in the kernel directly to audio and video decoders. (we have several audio or video decoders that we can use in parallel).
So what we end up with is several sets of demux/audio/video entry points in order to exercise our demux and decoders.

We also have to keep a relation between our decoders input (in LinuxDVB world) and output (in V4L2 worlds) since after decode, V4L2 capture, A/V sync, display stuff are done via the V4L2 world.

So at the end we now have stuff like
	demux0 ------ audio0
                |-- video0

	demux1 ------ audio1
                |-- video1

This mapping helps to "know" which audio/video decoder will be use when doing direct tunneling between demux and decoders. (in real nothing prevent the demux0 to be ordered to send stuff to audio1 also ... ).
We however have some use case where we need to demux/decode more than 2 PES/streams in parallel (ex: 2 audio/1 video in case of you have a video stream displayed on TV with 1 language sent to TV speakers and a second language sent to headsets let say). In such case the demux0->(audio0,video0) mapping is not enough and we need to have a way to say demux0 will send its data to yet another decoder that is not audio0 not video0.

MediaController for sure would allow us to do that by linking demux output pad (PES filter) with a decoder entity.

That said, actually MediaController is not the only solution here and we can actually think of something even more simple such as adding outputs in the dmx_output_t field of struct dmx_pes_filter_params. For example in our case we would have DMX_OUT_DECODER1, DMX_OUT_DECODER2, DMX_OUT_DECODER3 and so on. 

So my feeling is that the MediaController would most probably help in some cases in the LinuxDVB and also it seems to be good to be able to link all together within a same pipeline LinuxDVB FE/DEMUX and V4L2 decoders/planes and outputs (in our cases). That done it would allow to exercise the whole pipeline from a single place in the pipeline (V4L2 or LinuxDVB) while currently we have to configure and control LinuxDVB and V4L2 separately. However, for the very time being, the first solution that it would solve it the case described above.

Regards,

Alain