[Gstreamer-openmax] Support for hardware codecs
ensonic at hora-obscura.de
Mon Feb 22 08:15:45 PST 2010
Clark, Rob wrote:
> On Apr 1, 2009, at 11:21 AM, Felipe Contreras wrote:
>> On Wed, Apr 1, 2009 at 6:45 PM, Stephen M. Webb <stephenw at xandros.com> wrote:
>>> On 01/04/09 11:15, Felipe Contreras wrote:
>>>> Yeah, that's the next step, I plan to implement something like:
>>>> ./configure MAPPING=maemo
>>>> Would that fit your use case?
>>> No, configuring at compile time won't help, I need to configure at runtime. I
>>> want to be able to distribute a single gstreamer-openmax library binary
>>> package for, say, Cortex-A8 and be able to configure it at runtime (well,
>>> install time) for the actual hardware it's running on, say OMAP3, i.MX51, or
>>> QSD8x50. Just for example.
>>>> I am planning to do that soon, but of course I would not get mad if
>>>> you beat me to it :)
>>> I was hoping you'd say you were just about to check in the changes. I will
>>> now frown and grumble and see what I can come up with.
>> Ah, I see.
>> Well, there's definitely plans on that, but it's pretty low on my
>> priority list =/
>> My idea was to create a gst-openmax registry, with this API:
> I was starting to think again about gst-openmax registry..
> On implementation side, what are your thoughts about using libxml2? It seems a bit overkill, but it is already a dependency of gstreamer core.
Please no xml for a registry cache. Maybe you can sketch the data first
and then we can discuss the file format.
> On requirements side, do you think any of following are needed:
> * Detect changes in registry at runtime? Or just check if file has changed at plugin_init() time?
runtime changes should be possible. Hopefully the gstomx registry can be
chained to gst_update_registry().
> * Dynamic class instances.. Ie. be able to introduce new OMX components without creating a new GstOmx subclass? (Hypothetically you could put template caps and compression format in registry.. although I think it would be only extremelly simple cases where you could avoid writing any code.)
> * multiple different OMX components filling same role? (Ie. different MP3 decoder components.) Again, I don't really see immediately how this could work, but I'm just brainstorming here.
> Anything else?
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> Gstreamer-openmax mailing list
> Gstreamer-openmax at lists.sourceforge.net
More information about the Gstreamer-openmax