Re: [Gstreamer-openmax] Support for hardware codecs

[Stefan K. <en...@ho...>]

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 <ste...@xa...> 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:
>> http://bugzilla.gnome.org/show_bug.cgi?id=350477
>>     
>
>
> 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().

Stefan
>  * 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?
>
>
> BR,
> -R
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gstreamer-openmax mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
>