[Gstreamer-openmax] [PATCH v3 1/3] Initial support for configuration file
Clark, Rob
rob at ti.com
Thu Mar 4 05:48:08 PST 2010
On Mar 4, 2010, at 7:28 AM, Felipe Contreras wrote:
> On Thu, Mar 04, 2010 at 12:04:50AM +0100, Rob Clark wrote:
>> not a comment on current patch (which looks fine to me, btw), but a
>> note about what I'm thinking for future evolution of config file..
>>
>> since we are using a GstStructure as the the config file syntax, it
>> would be really simple to start adding element specific fields. For
>> example, anything that subclasses GstOmxBaseVideoDec could have an
>> optional output-formats list. Like:
>>
>> ----
>> omx_h264dec,
>> type=GstOmxH264Dec,
>> library-name=libomxil-bellagio.so.0,
>> component-name=OMX.st.video_decoder.avc,
>> srcpad-formats=(fourcc){I420, YUY2, NV12},
>> rank=256;
>> ----
>>
>> or audio decoder could have fields for supported # of channels or
>> rates, etc, etc.
>>
>> It should be really easy to add an API to take an element and field
>> name as parameter, and return a GValue which could be dropped into the
>> caps.
>>
>> At that point, it might make sense to move the library and component
>> name strings out of the element.. I'm not sure. But that can come as
>> a later patch.
>
> I don't see what one thing has to do with the other. What an API to
> fetch fields from the config has to do with element properties?
Well, the could perhaps share a common API, and this way all config parameters could be handled basically the same way..
although you are right, there is no requirement to do it this way.. I'm only thinking out-loud (in email form) here..
BR,
-R
>
>> (Oh, and I want to make those library-name and component-name
>> properties as read-only too.. but also another patch)
>
> I already sent the patches for that.
>
> --
> Felipe Contreras
More information about the Gstreamer-openmax
mailing list