[Gstreamer-openmax] Support for hardware codecs

[Clark, Rob]

On Feb 22, 2010, at 10:15 AM, Stefan Kost wrote:

> 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:
>>> 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.


well, it isn't really a cache.. more of a config file.  At a minimum consisting of the data in the table in gstomx.c.

maybe registry is a bad word for it in the GStreamer context, because the main registry is not really a config file, and more of a cache.  

btw, after looking at gst_plugin_{get,set}_cache_data, I have a real simple idea to avoid writing a new parser.  (Not that an .ini style parser would be hard.  But it just seems ugly to have multiple different parsers in gst of different formats of data.)

instead, just re-use the parsing in GstStructure.  So, if we didn't add any new requirements beyond what is currently in gstomx.c component table, then I'd propose something like:

-----8<----------8<-----
omx_mp3dec, library=libOMX_Core.so, component=OMX.TI.AUDIO.DECODE, role=audio_decode.dsp.mp3;
omx_aacdec, library=libOMX_Core.so, component=OMX.TI.AUDIO.DECODE, role=audio_decode.dsp.aac;
....
----->8---------->8-----

to get the GType corresponding to component name, it could use dlsym(RTLD_SELF, "gst_" + component_name + "_get_type")


I'd propose that in g_omx_core_init(), to check:

  cache_valid = TRUE;
  if (config file is newer/different timestamp from before) {
     g_object_unref (element_table);
     cache_valid = FALSE;
  }

  if (!element_table) {
    if (is in gst registry cache && cache_valid) {
      element_table = gst_plugin_get_cache_data (plugin);
    } else {
      ... parse config file using gst_structure_from_string() and populate element_table ...
      gst_plugin_set_cache_data (plugin, element_table);
    }
  }

this way, at runtime it would detect config file changes, as long as they happened before the element is created

can a GstStructure recursively contain elements that are GstStructures?

BR,
-R


>> 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?
>>