From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Alain VOLMAT <alain.volmat@st.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: MediaController support in LinuxDVB demux
Date: Thu, 03 Nov 2011 11:19:05 -0200 [thread overview]
Message-ID: <4EB294C9.90204@redhat.com> (raw)
In-Reply-To: <E27519AE45311C49887BE8C438E68FAA01010C61F5A6@SAFEX1MAIL1.st.com>
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
next prev parent reply other threads:[~2011-11-03 13:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 9:16 MediaController support in LinuxDVB demux Alain VOLMAT
2011-11-03 13:19 ` Mauro Carvalho Chehab [this message]
2011-11-03 14:05 ` Alain VOLMAT
2011-11-03 18:12 ` Mauro Carvalho Chehab
2011-11-04 9:57 ` Patrick Boettcher
2011-11-10 11:32 ` Alain VOLMAT
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EB294C9.90204@redhat.com \
--to=mchehab@redhat.com \
--cc=alain.volmat@st.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox