Menu
▾
▴
gstreamer-openmax
|
From: Stephen M. W. <ste...@xa...> - 2009-04-01 14:56:39
|
I have a number of hardware codecs for various boards from various vendors and I'm trying to integrate them nicely with gst-openmax. The recent refactoring that split the components into a table is great, but I need to be able to do it from a config file so that I can use the soft codecs from bellagio for some things on some target platforms and the vendor-supplied hard codecs for other things on other platforms. I also need to specify the use of AllocateBuffer vs. UseBuffer on a per-component basis from that same configuration file. Is there any plan in the very near future to implement this? I don't want to duplicate any effort. -- Stephen M. Webb ste...@xa... www.xandros.com |
|
From: giulio u. <giu...@gm...> - 2009-04-01 15:14:23
|
Hi Stephen,
I presume you are talking about the components split in
Bellagio OpenMAX. For this reason I've added in cc the related mailing
list.
There is actually no plan in Bellagio to implement some mechanism to
compile together free and proprietary components. The idea is to
compile what is needed separately and put all the needed components
libraries in some common locations, that can be registered with
omxregister-bellagio command. This command supports multiple
locations, so it can be used easily with different types of
components.
Each component is already provided with automake files, for a cross
platform compilation.
Regarding your second point I'm not sure to have taken your issue. You
need to specify if a component support both UseBuffer and
AllocateBuffer? Or that can support only one of the calls?
Regards,
Giulio Urlini
On Wed, Apr 1, 2009 at 3:57 PM, Stephen M. Webb <ste...@xa...> wrote:
> I have a number of hardware codecs for various boards from various vendors and
> I'm trying to integrate them nicely with gst-openmax. The recent refactoring
> that split the components into a table is great, but I need to be able to do
> it from a config file so that I can use the soft codecs from bellagio for
> some things on some target platforms and the vendor-supplied hard codecs for
> other things on other platforms. I also need to specify the use of
> AllocateBuffer vs. UseBuffer on a per-component basis from that same
> configuration file.
>
> Is there any plan in the very near future to implement this? I don't want to
> duplicate any effort.
>
> --
> Stephen M. Webb
> ste...@xa...
> www.xandros.com
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gstreamer-openmax mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
>
|
|
From: Felipe C. <fel...@gm...> - 2009-04-01 15:15:43
|
On Wed, Apr 1, 2009 at 4:57 PM, Stephen M. Webb <ste...@xa...> wrote: > I have a number of hardware codecs for various boards from various vendors and > I'm trying to integrate them nicely with gst-openmax. The recent refactoring > that split the components into a table is great, but I need to be able to do > it from a config file so that I can use the soft codecs from bellagio for > some things on some target platforms and the vendor-supplied hard codecs for > other things on other platforms. I also need to specify the use of > AllocateBuffer vs. UseBuffer on a per-component basis from that same > configuration file. Yeah, that's the next step, I plan to implement something like: ./configure MAPPING=maemo Would that fit your use case? And yeah, I also would want to specify allocate vs use on a per-component basis, as well as the share_*_buffer hacks. > Is there any plan in the very near future to implement this? I don't want to > duplicate any effort. I am planning to do that soon, but of course I would not get mad if you beat me to it :) Cheers. -- Felipe Contreras |
|
From: Stephen M. W. <ste...@xa...> - 2009-04-01 15:45:25
|
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. -- Stephen M. Webb ste...@xa... www.xandros.com |
|
From: Felipe C. <fel...@gm...> - 2009-04-01 16:21:50
|
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 -- Felipe Contreras |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 14:32:31
|
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. 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? * 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 |
|
From: Stephen M. W. <ste...@xa...> - 2010-02-22 16:35:11
|
On 22/02/10 09:32, Clark, Rob wrote: > > 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? Our requirements are definitely limited to plugin_init() time. > Anything else? Another thing that came up recently was the ability to specify some OpenMAX parameters with default values on a per-plugin basis. Even better, some way to specify rules for different parameters values to handle cases such as the WMVFileType setting for the TI video decoder. -- Stephen M. Webb Xandros ste...@xa... www.xandros.com |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 17:06:09
|
On Feb 22, 2010, at 10:47 AM, Stephen M. Webb wrote: > On 22/02/10 09:32, Clark, Rob wrote: >> >> 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? > > Our requirements are definitely limited to plugin_init() time. > >> Anything else? > > Another thing that came up recently was the ability to specify some OpenMAX > parameters with default values on a per-plugin basis. Even better, some way > to specify rules for different parameters values to handle cases such as the > WMVFileType setting for the TI video decoder. would it be sufficient to (a) expose more setting via properties, and (b) have some generic (not specific to gst-openmax) way to config default values for element's properties BR, -R > > -- > Stephen M. Webb > Xandros > ste...@xa... > www.xandros.com |
|
From: Stephen M. W. <ste...@xa...> - 2010-02-23 14:33:34
|
On 22/02/10 12:05, Clark, Rob wrote: > On Feb 22, 2010, at 10:47 AM, Stephen M. Webb wrote: > > > > Another thing that came up recently was the ability to specify some > > OpenMAX parameters with default values on a per-plugin basis. Even > > better, some way to specify rules for different parameters values to > > handle cases such as the WMVFileType setting for the TI video decoder. > > would it be sufficient to (a) expose more setting via properties, and (b) > have some generic (not specific to gst-openmax) way to config default > values for element's properties What I would want is some way to expose more properties via gst-openmax, at runtime. I use gst-openmax to integrate various hardware codecs from different vendors, each one with a different set of properties that may need to be tweaked. The more I can keep generic and as a single binary, the happier I am. And the easier it will be to push everything upstream. Because of the need for compile-time differentiation, I currently end up building everything multiple times, once for each hardware platform. That gives a fine end result but sure makes my life more difficult. -- Stephen M. Webb Xandros ste...@xa... www.xandros.com |
|
From: Felipe C. <fel...@gm...> - 2010-02-23 20:09:20
|
On Tue, Feb 23, 2010 at 4:45 PM, Stephen M. Webb <ste...@xa...> wrote: > On 22/02/10 12:05, Clark, Rob wrote: >> On Feb 22, 2010, at 10:47 AM, Stephen M. Webb wrote: >> > >> > Another thing that came up recently was the ability to specify some >> > OpenMAX parameters with default values on a per-plugin basis. Even >> > better, some way to specify rules for different parameters values to >> > handle cases such as the WMVFileType setting for the TI video decoder. >> >> would it be sufficient to (a) expose more setting via properties, and (b) >> have some generic (not specific to gst-openmax) way to config default >> values for element's properties > > What I would want is some way to expose more properties via gst-openmax, at > runtime. I use gst-openmax to integrate various hardware codecs from > different vendors, each one with a different set of properties that may need > to be tweaked. The more I can keep generic and as a single binary, the > happier I am. And the easier it will be to push everything upstream. I'm not sure exactly what properties you might need. The only one I'm aware of is TI's "OMX.TI.VideoDecode.Param.WMVFileType" which is needed because the spec is missing something similar. And this one cannot be properly set with a configuration file, it has to be set programatically based on the fourcc/fomat caps. Other than that it might make sense to add a quirks list that can be configurable. I've tried to send patches to TI to fix their implementation but I don't think that's ever going to happen. Other implementations might make similar mistakes... not sure. > Because of the need for compile-time differentiation, I currently end up > building everything multiple times, once for each hardware platform. That > gives a fine end result but sure makes my life more difficult. Yeah, that's definitely not ideal but it would be nice to know exactly what are the differences each platform needs so that we know how to build a binary that works on all those platforms with a proper configuration file. I'm only aware of bellagio (doesn't need any quirks), TI (needs quirks at least for video components), and I know a bit about Android's OpenCore, but haven't yet managed to get anything done with that. Cheers. -- Felipe Contreras |
|
From: Stephen M. W. <ste...@xa...> - 2010-02-23 22:04:03
|
On 23/02/10 15:09, Felipe Contreras wrote: > On Tue, Feb 23, 2010 at 4:45 PM, Stephen M. Webb <ste...@xa...> wrote: > > > > What I would want is some way to expose more properties via gst-openmax, > > at runtime. I use gst-openmax to integrate various hardware codecs from > > different vendors, each one with a different set of properties that may > > need to be tweaked. The more I can keep generic and as a single binary, > > the happier I am. And the easier it will be to push everything upstream. > > I'm not sure exactly what properties you might need. The only one I'm > aware of is TI's "OMX.TI.VideoDecode.Param.WMVFileType" which is > needed because the spec is missing something similar. And this one > cannot be properly set with a configuration file, it has to be set > programatically based on the fourcc/fomat caps. I have one hardware vendor who does the same thing with WVC1 vs. WMV3 formats, only uses a different parameter name. They also have a parameter to enable the use of hardware buffering -- effectively tunnelling, only tunnelled from their video decoder to the gstreamer-based video renderer. Evidently there are other parameters but their documentation is, ah, terse. I think what I would really like to be able to do is to be able to set OpenMAX parameters via GStreamer properties, not through a config file. As long as the gst-openmax layer is configured to load the right component (introspection or configuration), if I can query and set OpenMAX parameters via GStreamer properties I could move most of the hardware-specific settings into my player software. Hmm, I will think about this. It doesn't sound too hard.... > Yeah, that's definitely not ideal but it would be nice to know exactly > what are the differences each platform needs so that we know how to > build a binary that works on all those platforms with a proper > configuration file. Among the things I have to configure are the OMX_ALLOCATE_ON settings and the fourcc caps supported by the video decoders. -- Stephen M. Webb Xandros ste...@xa... www.xandros.com |
|
From: Rob C. <ro...@ti...> - 2010-02-24 01:02:47
|
On Feb 23, 2010, at 4:16 PM, Stephen M. Webb wrote: > On 23/02/10 15:09, Felipe Contreras wrote: >> On Tue, Feb 23, 2010 at 4:45 PM, Stephen M. Webb <ste...@xa...> > wrote: >>> >>> What I would want is some way to expose more properties via gst-openmax, >>> at runtime. I use gst-openmax to integrate various hardware codecs from >>> different vendors, each one with a different set of properties that may >>> need to be tweaked. The more I can keep generic and as a single binary, >>> the happier I am. And the easier it will be to push everything upstream. >> >> I'm not sure exactly what properties you might need. The only one I'm >> aware of is TI's "OMX.TI.VideoDecode.Param.WMVFileType" which is >> needed because the spec is missing something similar. And this one >> cannot be properly set with a configuration file, it has to be set >> programatically based on the fourcc/fomat caps. > > I have one hardware vendor who does the same thing with WVC1 vs. WMV3 formats, > only uses a different parameter name. They also have a parameter to enable > the use of hardware buffering -- effectively tunnelling, only tunnelled from > their video decoder to the gstreamer-based video renderer. Evidently there > are other parameters but their documentation is, ah, terse. > > I think what I would really like to be able to do is to be able to set OpenMAX > parameters via GStreamer properties, not through a config file. As long as > the gst-openmax layer is configured to load the right component > (introspection or configuration), if I can query and set OpenMAX parameters > via GStreamer properties I could move most of the hardware-specific settings > into my player software. > > Hmm, I will think about this. It doesn't sound too hard.... > >> Yeah, that's definitely not ideal but it would be nice to know exactly >> what are the differences each platform needs so that we know how to >> build a binary that works on all those platforms with a proper >> configuration file. > > Among the things I have to configure are the OMX_ALLOCATE_ON settings and the > fourcc caps supported by the video decoders. > buffer mode per port (use vs allocate, and whether buffer sharing is enabled) would be nice.. For supported color formats, I did experiment with a trick of trying a SetParam with each different color format and seeing for which ones it returned an error code. Of course an introspection API for OMX would be more ideal. But assuming your OMX implementation wasn't *too* horrible, that could be an option.. BR, -R |
|
From: Felipe C. <fel...@gm...> - 2010-02-24 13:22:37
|
On Wed, Feb 24, 2010 at 12:16 AM, Stephen M. Webb <ste...@xa...> wrote: > On 23/02/10 15:09, Felipe Contreras wrote: >> On Tue, Feb 23, 2010 at 4:45 PM, Stephen M. Webb <ste...@xa...> > wrote: >> > >> > What I would want is some way to expose more properties via gst-openmax, >> > at runtime. I use gst-openmax to integrate various hardware codecs from >> > different vendors, each one with a different set of properties that may >> > need to be tweaked. The more I can keep generic and as a single binary, >> > the happier I am. And the easier it will be to push everything upstream. >> >> I'm not sure exactly what properties you might need. The only one I'm >> aware of is TI's "OMX.TI.VideoDecode.Param.WMVFileType" which is >> needed because the spec is missing something similar. And this one >> cannot be properly set with a configuration file, it has to be set >> programatically based on the fourcc/fomat caps. > > I have one hardware vendor who does the same thing with WVC1 vs. WMV3 formats, > only uses a different parameter name. They also have a parameter to enable > the use of hardware buffering -- effectively tunnelling, only tunnelled from > their video decoder to the gstreamer-based video renderer. Evidently there > are other parameters but their documentation is, ah, terse. I'm not sure how we can fix this WVC1 vs WMV3 issue since the property names and the values are going to be different no matter what. The best we can do is try to align on a non-vendor-specific extension. I will also try to fill a bug report in Khronos's bugzilla. I'm not sure about that tunneling stuff... it's not integrated on gst-omx yet and it looks like it might require quite big changes. > I think what I would really like to be able to do is to be able to set OpenMAX > parameters via GStreamer properties, not through a config file. As long as > the gst-openmax layer is configured to load the right component > (introspection or configuration), if I can query and set OpenMAX parameters > via GStreamer properties I could move most of the hardware-specific settings > into my player software. We could add some functions to access omx parameters directly through a gst-omx interface. That shouldn't be that difficult. But ideally we want all applications to be able to use the omx stuff transparently, not just the ones that know how to use the gst-omx interface smartly. >> Yeah, that's definitely not ideal but it would be nice to know exactly >> what are the differences each platform needs so that we know how to >> build a binary that works on all those platforms with a proper >> configuration file. > > Among the things I have to configure are the OMX_ALLOCATE_ON settings and the > fourcc caps supported by the video decoders. We could also specify the caps that each element supports, and yeah, allocate/use would make sense, along with the share_*_buffer hacks. Cheers. -- Felipe Contreras |
|
From: Tim-Philipp M. <t....@ze...> - 2010-02-22 14:44:33
|
On Mon, 2010-02-22 at 08:32 -0600, Clark, Rob wrote: > On implementation side, what are your thoughts about using libxml2? It > seems a bit overkill, but it is already a dependency of gstreamer > core. For what it's worth, this dependency only exists for the serialisation/deserialisation API that no one really uses (not least because we don't recommend that) and which only works partially anyway. On many embedded systems GStreamer will likely be built with --disable-loadsave and hence without the libxml2 dependency. Cheers -Tim |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 15:29:28
|
On Feb 22, 2010, at 8:44 AM, Tim-Philipp Müller wrote: > On Mon, 2010-02-22 at 08:32 -0600, Clark, Rob wrote: > >> On implementation side, what are your thoughts about using libxml2? It >> seems a bit overkill, but it is already a dependency of gstreamer >> core. > > For what it's worth, this dependency only exists for the > serialisation/deserialisation API that no one really uses (not least > because we don't recommend that) and which only works partially anyway. > > On many embedded systems GStreamer will likely be built with > --disable-loadsave and hence without the libxml2 dependency. GstFileIndex? does anyone use that? That said, I don't mind doing something like a simple ini file syntax or some other similar syntax. Especially if the preference is to reduce dependency on libxml2. But if the dependency would be there anyways, might as well reuse it. BR, -R |
|
From: Felipe C. <fel...@gm...> - 2010-02-22 15:37:32
|
On Mon, Feb 22, 2010 at 5:29 PM, Clark, Rob <ro...@ti...> wrote: > That said, I don't mind doing something like a simple ini file syntax or some other similar syntax. Especially if the preference is to reduce dependency on libxml2. But if the dependency would be there anyways, might as well reuse it. I don't think there's any need for a complicated structure, so XML is overkill, specially if some systems don't have libxml2. Moreover I would like the file to be human readable; some people might like to modify it (for testing purposes or whatever). Personally I would write a simpler parser, but if anyone has better ideas/patches, I'm open for them. Cheers. -- Felipe Contreras |
|
From: Stefan K. <en...@ho...> - 2010-02-22 16:15:20
|
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® 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 > |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 16:58:25
|
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 <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. 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? >> |
|
From: Clark, R. <ro...@ti...> - 2010-02-23 02:42:51
|
On Feb 22, 2010, at 9:37 AM, Felipe Contreras wrote:
> On Mon, Feb 22, 2010 at 5:29 PM, Clark, Rob <ro...@ti...> wrote:
>> That said, I don't mind doing something like a simple ini file syntax or some other similar syntax. Especially if the preference is to reduce dependency on libxml2. But if the dependency would be there anyways, might as well reuse it.
>
> I don't think there's any need for a complicated structure, so XML is
> overkill, specially if some systems don't have libxml2. Moreover I
> would like the file to be human readable; some people might like to
> modify it (for testing purposes or whatever).
>
> Personally I would write a simpler parser, but if anyone has better
> ideas/patches, I'm open for them.
Ok, attached is a work-in-progress for what I'm thinking.. the basic idea is that the config file is just a list of GstStructure's, so no parser needed, just gst_structure_from_string(). These get stored within a parent GstStructure (so could be cached w/ gst_plugin_{get,set}_cache_data(), although that is not implemented yet. The config file looks like:
-----8<----------8<-----
omx_mp3dec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.mp3, rank=256;
omx_aacdec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.aac, rank=256;
omx_volume, library-name=libomxil-bellagio.so.0, component-name=OMX.st.volume.component, rank=0;
...
----->8---------->8-----
(the component-role field is optional, others are mandatory)
I left for now the library-name/component-name/component-role properties in the base src/filter/sink elements. But now they are just read-only properties, showing what is configured via the config file. I think this is useful to see in output of gst-inspect, diagrams generated from .dot files of the pipeline, etc.
Right now I have a small default config, in case no config file is found.. but I could go either way on this, either making it complete or removing it altogether. Anyone have any preference about whether the config file should just override a complete default table, or whether the config file should be mandatory?
The patch won't apply as-is on the gst-openmax tree from freedesktop.org (in our tree we've added component-role and some other stuff), but I'm just sending it as an RFC. If people like the idea, I'll rebase it on current master from fd.o (after cleaning up a couple of quick-n-dirty aspects of the patch).
I've pushed the patch here, if this is an easier way for you to review:
http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1
and since the patch seems to be too big and caused my original email to bounce, here it the link to the patch:
http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1.patch
BR,
-R
|
|
From: Felipe C. <fel...@gm...> - 2010-02-24 12:45:00
|
On Tue, Feb 23, 2010 at 4:42 AM, Clark, Rob <ro...@ti...> wrote:
> Ok, attached is a work-in-progress for what I'm thinking.. the basic idea is that the config file is just a list of GstStructure's, so no parser needed, just gst_structure_from_string(). These get stored within a parent GstStructure (so could be cached w/ gst_plugin_{get,set}_cache_data(), although that is not implemented yet. The config file looks like:
>
> -----8<----------8<-----
> omx_mp3dec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.mp3, rank=256;
> omx_aacdec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.aac, rank=256;
> omx_volume, library-name=libomxil-bellagio.so.0, component-name=OMX.st.volume.component, rank=0;
> ...
> ----->8---------->8-----
We most probably will add more stuff so I think each element should
span more than one line.
> (the component-role field is optional, others are mandatory)
I think rank should also be optional.
> I left for now the library-name/component-name/component-role properties in the base src/filter/sink elements. But now they are just read-only properties, showing what is configured via the config file. I think this is useful to see in output of gst-inspect, diagrams generated from .dot files of the pipeline, etc.
>
> Right now I have a small default config, in case no config file is found.. but I could go either way on this, either making it complete or removing it altogether. Anyone have any preference about whether the config file should just override a complete default table, or whether the config file should be mandatory?
>
> The patch won't apply as-is on the gst-openmax tree from freedesktop.org (in our tree we've added component-role and some other stuff), but I'm just sending it as an RFC. If people like the idea, I'll rebase it on current master from fd.o (after cleaning up a couple of quick-n-dirty aspects of the patch).
>
> I've pushed the patch here, if this is an easier way for you to review:
>
> http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1
>
> and since the patch seems to be too big and caused my original email to bounce, here it the link to the patch:
You didn't give me enough time to moderate it :) The patch doesn't
look too big, I wonder why it was deferred.
Anyway, the only important comment I have for now is that I think the
type should also be configurable (you can use g_type_from_name())
I'm thinking something like:
---
omx_mp3dec_ti:
type: GstOmxMp3Dec
library-name: libOMX_Core.so.0
component-name: OMX.TI.AUDIO.DECODE
component-role: audio_decode.dsp.mp3
rank: 256
omx_mp3dec_nokia:
type: GstOmxMp3Dec
library-name: libomxil_bellagio.so.0
component-name: OMX.nokia.audio_decode.mp3
rank: 128
---
Oh, and I think the default configuration should be in a separate file.
Cheers.
--
Felipe Contreras
|
|
From: Rob C. <ro...@ti...> - 2010-02-24 14:10:07
|
On Feb 24, 2010, at 6:41 AM, Felipe Contreras wrote:
> On Tue, Feb 23, 2010 at 4:42 AM, Clark, Rob <ro...@ti...> wrote:
>> Ok, attached is a work-in-progress for what I'm thinking.. the basic idea is that the config file is just a list of GstStructure's, so no parser needed, just gst_structure_from_string(). These get stored within a parent GstStructure (so could be cached w/ gst_plugin_{get,set}_cache_data(), although that is not implemented yet. The config file looks like:
>>
>> -----8<----------8<-----
>> omx_mp3dec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.mp3, rank=256;
>> omx_aacdec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.aac, rank=256;
>> omx_volume, library-name=libomxil-bellagio.so.0, component-name=OMX.st.volume.component, rank=0;
>> ...
>> ----->8---------->8-----
>
> We most probably will add more stuff so I think each element should
> span more than one line.
>
>> (the component-role field is optional, others are mandatory)
>
> I think rank should also be optional.
ok, should default rank=GST_RANK_NONE?
>
>> I left for now the library-name/component-name/component-role properties in the base src/filter/sink elements. But now they are just read-only properties, showing what is configured via the config file. I think this is useful to see in output of gst-inspect, diagrams generated from .dot files of the pipeline, etc.
>>
>> Right now I have a small default config, in case no config file is found.. but I could go either way on this, either making it complete or removing it altogether. Anyone have any preference about whether the config file should just override a complete default table, or whether the config file should be mandatory?
>>
>> The patch won't apply as-is on the gst-openmax tree from freedesktop.org (in our tree we've added component-role and some other stuff), but I'm just sending it as an RFC. If people like the idea, I'll rebase it on current master from fd.o (after cleaning up a couple of quick-n-dirty aspects of the patch).
>>
>> I've pushed the patch here, if this is an easier way for you to review:
>>
>> http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1
>>
>> and since the patch seems to be too big and caused my original email to bounce, here it the link to the patch:
>
> You didn't give me enough time to moderate it :) The patch doesn't
> look too big, I wonder why it was deferred.
sorry, I think it was just over the threshold..
I'll be more patient next time ;-)
> Anyway, the only important comment I have for now is that I think the
> type should also be configurable (you can use g_type_from_name())
>
> I'm thinking something like:
>
> ---
> omx_mp3dec_ti:
> type: GstOmxMp3Dec
> library-name: libOMX_Core.so.0
> component-name: OMX.TI.AUDIO.DECODE
> component-role: audio_decode.dsp.mp3
> rank: 256
>
> omx_mp3dec_nokia:
> type: GstOmxMp3Dec
> library-name: libomxil_bellagio.so.0
> component-name: OMX.nokia.audio_decode.mp3
> rank: 128
> ---
ok, that seems reasonable.. are you ok w/ basically same thing in GstStructure syntax:
omx_mp3dec_ti,
type=GstOmxMp3Dec,
library-name=libOMX_Core.so.0,
component-name=OMX.TI.AUDIO.DECODE,
component-role=audio_decode.dsp.mp3,
rank=256;
omx_mp3dec_nokia,
type=GstOmxMp3Dec,
library-name=libomxil_bellagio.so.0,
component-name=OMX.nokia.audio_decode.mp3,
rank=128;
note, w/ GstStructure, we can easily add parameters later if we want:
omx_h264dec_ti,
type=GstOmxH264Dec,
library-name=libOMX_Core.so,
component-name=OMX.TI.DUCATI1.VIDEO.H264D,
src-formats=(fourcc){NV12,YUYV},
rank=256;
>
> Oh, and I think the default configuration should be in a separate file.
ok, I'll do that.. expect an updated patch, rebased on latest gst-openmax master so you can more easily apply the patch and try it out
BR,
-R
|
|
From: Felipe C. <fel...@gm...> - 2010-02-24 16:20:01
|
On Wed, Feb 24, 2010 at 4:10 PM, Rob Clark <ro...@ti...> wrote: > On Feb 24, 2010, at 6:41 AM, Felipe Contreras wrote: >> I think rank should also be optional. > > ok, should default rank=GST_RANK_NONE? That was my idea, yeah. >> Anyway, the only important comment I have for now is that I think the >> type should also be configurable (you can use g_type_from_name()) >> >> I'm thinking something like: >> >> --- >> omx_mp3dec_ti: >> type: GstOmxMp3Dec >> library-name: libOMX_Core.so.0 >> component-name: OMX.TI.AUDIO.DECODE >> component-role: audio_decode.dsp.mp3 >> rank: 256 >> >> omx_mp3dec_nokia: >> type: GstOmxMp3Dec >> library-name: libomxil_bellagio.so.0 >> component-name: OMX.nokia.audio_decode.mp3 >> rank: 128 >> --- > > ok, that seems reasonable.. are you ok w/ basically same thing in GstStructure syntax: > > omx_mp3dec_ti, > type=GstOmxMp3Dec, > library-name=libOMX_Core.so.0, > component-name=OMX.TI.AUDIO.DECODE, > component-role=audio_decode.dsp.mp3, > rank=256; > > omx_mp3dec_nokia, > type=GstOmxMp3Dec, > library-name=libomxil_bellagio.so.0, > component-name=OMX.nokia.audio_decode.mp3, > rank=128; Yeah, whatever is easier. >> Oh, and I think the default configuration should be in a separate file. > > ok, I'll do that.. expect an updated patch, rebased on latest gst-openmax master so you can more easily apply the patch and try it out Cool :) -- Felipe Contreras |
|
From: Clark, R. <ro...@ti...> - 2010-02-25 02:02:10
|
On Feb 24, 2010, at 10:19 AM, Felipe Contreras wrote: > On Wed, Feb 24, 2010 at 4:10 PM, Rob Clark <ro...@ti...> wrote: >> On Feb 24, 2010, at 6:41 AM, Felipe Contreras wrote: >>> I think rank should also be optional. >> >> ok, should default rank=GST_RANK_NONE? > > That was my idea, yeah. > >>> Anyway, the only important comment I have for now is that I think the >>> type should also be configurable (you can use g_type_from_name()) >>> >>> I'm thinking something like: >>> >>> --- >>> omx_mp3dec_ti: >>> type: GstOmxMp3Dec >>> library-name: libOMX_Core.so.0 >>> component-name: OMX.TI.AUDIO.DECODE >>> component-role: audio_decode.dsp.mp3 >>> rank: 256 >>> >>> omx_mp3dec_nokia: >>> type: GstOmxMp3Dec >>> library-name: libomxil_bellagio.so.0 >>> component-name: OMX.nokia.audio_decode.mp3 >>> rank: 128 >>> --- >> >> ok, that seems reasonable.. are you ok w/ basically same thing in GstStructure syntax: >> >> omx_mp3dec_ti, >> type=GstOmxMp3Dec, >> library-name=libOMX_Core.so.0, >> component-name=OMX.TI.AUDIO.DECODE, >> component-role=audio_decode.dsp.mp3, >> rank=256; >> >> omx_mp3dec_nokia, >> type=GstOmxMp3Dec, >> library-name=libomxil_bellagio.so.0, >> component-name=OMX.nokia.audio_decode.mp3, >> rank=128; > > Yeah, whatever is easier. ok, what I ended up doing, in order to accommodate multiple elements with different names and different component-name and/or library-name but same gst-openmax class was to dynamically generate subclasses of the gst-openmax class.. so for example you'll end up with a class called omx_mp3dec_ti and omx_mp3dec_nokia which both subclass GstOmxMp3Dec. This approach seems to work pretty well, you can have as many different elements using the same code but different OMX components as you want: http://gitorious.org/robclark-gstreamer/gst-openmax/commit/e91b1e643ceac35f04b6649af0532d12219e33d7 http://gitorious.org/robclark-gstreamer/gst-openmax/commit/e91b1e643ceac35f04b6649af0532d12219e33d7.patch I'll send the patch email separately to the list (I'm not sure if it will be big enough that you'll have to moderate) There is one preceding patch to fix some issues building on 64bit host (since I found it easier to build and test on my laptop than on the target board). BR, -R > >>> Oh, and I think the default configuration should be in a separate file. >> >> ok, I'll do that.. expect an updated patch, rebased on latest gst-openmax master so you can more easily apply the patch and try it out > > Cool :) > > -- > Felipe Contreras |
|
From: Felipe C. <fel...@gm...> - 2010-02-26 12:54:08
|
On Thu, Feb 25, 2010 at 3:30 AM, Clark, Rob <ro...@ti...> wrote: > I'll send the patch email separately to the list (I'm not sure if it will be big enough that you'll have to moderate) Apparently the limit was 40K. I've increased it to 500K. Cheers. -- Felipe Contreras |
Thanks for helping keep SourceForge clean.
X